Ingeniería De Requerimientos Ingeniería De Software

Indice
1.
Introducción
2.
La ingeniería de requerimientos y sus principales
actividades
3. Técnicas y
herramientas utilizadas en la ingeniería de
requerimientos
4. Análisis
comparativo de las técnicas de ingeniería de
requerimientos
5. Conclusiones Y
Recomendaciones
6. Referencias
Bibliográficas

1.
Introducción
En la actualidad, son
muchos los procesos de
desarrollo de
software que
existen. Con el pasar de los años, la Ingeniería de
Software ha introducido y popularizado una serie de
estándares para medir y certificar la calidad, tanto
del sistema a
desarrollar, como del proceso de
desarrollo en
sí. Se han publicado muchos libros y
artículos relacionados con este tema, con el modelado de
procesos del
negocio y la reingeniería. Un número creciente de
herramientas
automatizadas han surgido para ayudar a definir y aplicar un
proceso de
desarrollo de software efectivo. Hoy en
día la economía global
depende más de sistemas
automatizados que en épocas pasadas; esto ha llevado a los
equipos de desarrollo a enfrentarse con una nueva década
de procesos y estándares de calidad.

Sin embargo, ¿cómo explicamos la alta
incidencia de fallos en los proyectos de
software? ¿Por qué existen tantos proyectos de
software víctimas de retrasos, presupuestos
sobregirados y con problemas de
calidad? ¿Cómo podemos tener una producción o una economía de calidad,
cuando nuestras actividades diarias dependen de la calidad del
sistema?

Tal vez suene ilógico pero, a pesar de los
avances que ha dado la tecnología,
aún existen procesos de producción informales, parciales y en
algunos casos no confiables.

La Ingeniería de Requerimientos cumple un
papel
primordial en el proceso de producción de software, ya que
enfoca un área fundamental: la definición de lo que
se desea producir. Su principal tarea consiste en la
generación de especificaciones correctas que describan con
claridad, sin ambigüedades, en forma consistente y compacta,
el comportamiento
del sistema; de esta manera, se pretende minimizar los problemas
relacionados al desarrollo de sistemas.

La razón principal para escoger este tema se
fundamentó en la gran cantidad de proyectos de software
que no llegan a cumplir sus objetivos. En
nuestro país somos partícipes de este problema a
diario, en donde se ha vuelto común la compra de sistemas
extranjeros, para luego "personalizarlos" supuestamente a la
medida de las empresas.

Tal "personalización", la mayoría de las
veces, termina retrasando el proyecto en
meses, o incluso en años. La problemática del
año 2000 trajo como consecuencia una serie de cambios
apresurados en los sistemas existentes; cambios que, desde mi
punto de vista, no fueron bien planificados.

El reemplazo de plataformas y tecnologías
obsoletas, la compra de sistemas completamente nuevos, las
modificaciones de todos o de casi todos los programas que
forman un sistema, entre otras razones, llevan a desarrollar
proyectos en calendarios sumamente ajustados y en algunos casos
irreales; esto ocasiona que se omitan muchos pasos importantes en
el ciclo de vida
de desarrollo, entre estos, la definición de los
requerimientos.

Estudios realizados muestran que más del 53% de
los proyectos de software fracasan por no realizar un estudio
previo de requisitos. Otros factores como falta de
participación del usuario, requerimientos incompletos y el
cambio a los
requerimientos, también ocupan sitiales altos en los
motivos de fracasos.

Con este trabajo se pretende alcanzar los siguientes
objetivos:

• Resaltar la importancia que tiene la
  Ingeniería de Requerimientos dentro del ciclo de
  desarrollo.
• Dar a conocer las diferentes alternativas que existen
  para identificar requerimientos.
• Ayudar a comprender la diferencia que existe entre
  las diferentes técnicas
  utilizadas en la IR.
• Minimizar las dudas que se tiene sobre los casos de
  uso.
• Mostrar la utilización de herramientas
  CASE dentro de la administración de requisitos.

2. La ingeniería de
requerimientos y sus principales
actividades
¿Qué son
Requerimientos?
Normalmente, un tema de la Ingeniería de
Software tiene diferentes significados. De las muchas
definiciones que existen para requerimiento, ha
continuación se presenta la definición que aparece
en el glosario de la
IEEE .

(1) Una condición o necesidad de un usuario para
resolver un problema o alcanzar un objetivo. (2)
Una condición o capacidad que debe estar presente en un
sistema o componentes de sistema para satisfacer un contrato,
estándar, especificación u otro documento formal.
(3) Una representación documentada de una condición
o capacidad como en (1) o (2).

Los requerimientos puedes dividirse en requerimientos
funcionales y requerimientos no funcionales.
Los requerimientos funcionales definen las funciones que el
sistema será capaz de realizar. Describen las
transformaciones que el sistema realiza sobre las entradas para
producir salidas.
Los requerimientos no funcionales tienen que ver con características que de una u otra forma
puedan limitar el sistema, como por ejemplo, el rendimiento (en
tiempo y
espacio), interfaces de usuario, fiabilidad (robustez del
sistema, disponibilidad de equipo), mantenimiento,
seguridad,
portabilidad, estándares, etc.

Características de los requerimientos
Las características de un requerimiento son sus
propiedades principales. Un conjunto de requerimientos en
estado de
madurez, deben presentar una serie de características
tanto individualmente como en grupo. A
continuación se presentan las más importantes.
Necesario: Un requerimiento es necesario si su omisión
provoca una deficiencia en el sistema a construir, y
además su capacidad, características físicas
o factor de calidad no pueden ser reemplazados por otras
capacidades del producto o del
proceso.
Conciso: Un requerimiento es conciso si es fácil de leer y
entender. Su redacción debe ser simple y clara para
aquellos que vayan a consultarlo en un futuro.
Completo: Un requerimiento está completo si no necesita
ampliar detalles en su redacción, es decir, si se proporciona la
información suficiente para su
comprensión.
Consistente: Un requerimiento es consistente si no es
contradictorio con otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola
interpretación. El lenguaje
usado en su definición, no debe causar confusiones al
lector.
Verificable: Un requerimiento es verificable cuando puede ser
cuantificado de manera que permita hacer uso de los siguientes
métodos de
verificación: inspección, análisis, demostración o pruebas.

Dificultades para definir los requerimientos

• Los requerimientos no son obvios y vienen de muchas
  fuentes.
• Son difíciles de expresar en palabras (el
  lenguaje es
  ambiguo).
• Existen muchos tipos de requerimientos y diferentes
  niveles de detalle.
• La cantidad de requerimientos en un proyecto puede
  ser difícil de manejar.
• Nunca son iguales. Algunos son más
  difíciles, más riesgosos, más importantes
  o más estables que otros.
• Los requerimientos están relacionados unos con
  otros, y a su vez se relacionan con otras partes del
  proceso.
• Cada requerimiento tiene propiedades únicas y
  abarcan áreas funcionales
  específicas.
• Un requerimiento puede cambiar a lo largo del ciclo
  de desarrollo.
• Son difíciles de cuantificar, ya que cada
  conjunto de requerimientos es particular para cada
  proyecto.

Ingeniería de Requerimientos vs. Administración de Requerimientos
El proceso de recopilar, analizar y verificar las necesidades
del cliente para un
sistema es llamado Ingeniería de Requerimientos. La meta de la
ingeniería de requerimientos (IR) es entregar una
especificación de requisitos de software correcta y
completa.

A continuación se darán algunas
definiciones para ingeniería de requerimientos.
"Ingeniería de Requerimientos es la disciplina
para desarrollar una especificación completa, consistente
y no ambigua, la cual servirá como base para acuerdos
comunes entre todas las partes involucradas y en dónde se
describen las funciones que
realizará el sistema" Boehm 1979.

"Ingeniería de Requerimientos es el proceso por
el cual se transforman los requerimientos declarados por los
clientes , ya
sean hablados o escritos, a especificaciones precisas, no
ambiguas, consistentes y completas del comportamiento
del sistema, incluyendo funciones, interfaces, rendimiento y
limitaciones". STARTS Guide 1987.

"Es el proceso mediante el cual se intercambian
diferentes puntos de vista para recopilar y modelar lo que el
sistema va a realizar. Este proceso utiliza una
combinación de métodos,
herramientas y
actores, cuyo producto es un
modelo del
cual se genera un documento de requerimientos" Leite
1987.

"Ingeniería de requerimientos es un enfoque
sistémico para recolectar, organizar y documentar los
requerimientos del sistema; es también el proceso que
establece y mantiene acuerdos sobre los cambios de
requerimientos, entre los clientes y el
equipo del proyecto" Rational Software

Importancia de la Ingeniería de
Requerimientos
Los principales beneficios que se obtienen de la
Ingeniería de Requerimientos son:

• Permite gestionar las necesidades del proyecto en
  forma estructurada: Cada actividad de la IR consiste de una
  serie de pasos organizados y bien definidos.
• Mejora la capacidad de predecir cronogramas de
  proyectos, así como sus resultados: La IR proporciona un
  punto de partida para controles subsecuentes y actividades de
  mantenimiento, tales como estimación de
  costos,
  tiempo y
  recursos
  necesarios.
• Disminuye los costos y
  retrasos del proyecto: Muchos estudios han demostrado que
  reparar errores por un mal desarrollo no descubierto a tiempo,
  es sumamente caro; especialmente aquellas decisiones tomadas
  durante la RE.
• Mejora la calidad del software: La calidad en el
  software tiene que ver con cumplir un conjunto de
  requerimientos (funcionalidad, facilidad de uso, confiabilidad,
  desempeño, etc.).
• Mejora la
  comunicación entre equipos: La especificación
  de requerimientos representa una forma de consenso entre
  clientes y desarrolladores. Si este consenso no ocurre, el
  proyecto no será exitoso.
• Evita rechazos de usuarios finales: La
  ingeniería de requerimientos obliga al cliente a
  considerar sus requerimientos cuidadosamente y revisarlos
  dentro del marco del problema, por lo que se le involucra
  durante todo el desarrollo del proyecto.

Personal involucrado en la Ingeniería de
Requerimientos

Realmente, son muchas las personas involucradas en el
desarrollo de los requerimientos de un sistema. Es importante
saber que cada una de esas personas tienen diversos intereses y
juegan roles específicos dentro de la planificación del proyecto; el
conocimiento de cada papel
desempeñado, asegura que se involucren a las personas
correctas en las diferentes fases del ciclo de vida,
y en las diferentes actividades de la IR.

No conocer estos intereses puede ocasionar una comunicación poco efectiva entre clientes y
desarrolladores, que a la vez traería impactos negativos
tanto en tiempo como en presupuesto. Los
roles más importantes pueden clasificarse como
sigue:

• Usuario final: Son las personas que usarán el
  sistema desarrollado. Ellos están relacionados con la
  usabilidad, la disponibilidad y la fiabilidad del sistema;
  están familiarizados con los procesos específicos
  que debe realizar el software, dentro de los parámetros
  de su ambiente
  laboral.
  Serán quienes utilicen las interfaces y los manuales de
  usuario.
• Usuario Líder: Son los individuos que comprenden
  el ambiente del
  sistema o el dominio del
  problema en donde será empleado el software
  desarrollado. Ellos proporcionan al equipo técnico los
  detalles y requerimientos de las interfaces del
  sistema.
• Personal de Mantenimiento: Para proyectos que
  requieran un mantenimiento eventual, éstas personas son
  las responsables de la
  administración de cambios, de la
  implementación y resolución de anomalías.
  Su trabajo consiste en revisar y mejorar los procesos del
  producto ya finalizado.
• Analistas y programadores: Son los responsables del
  desarrollo del producto en sí; ellos interactúan
  directamente con el cliente.
• Personal de pruebas: Se
  encargan de elaborar y ejecutar el plan de pruebas
  para asegurar que las condiciones presentadas por el sistema
  son las adecuadas. Son quienes van a validar si los
  requerimientos satisfacen las necesidades del
  cliente.

Otras personas que pueden estar involucradas,
dependiendo de la magnitud del proyecto, pueden ser:
administradores de proyecto, documentadores, diseñadores
de base de datos,
entre otros.

Puntos a considerar durante la Ingeniería de
Requerimientos
Aunque la lista no está completa, se enumeran los puntos
más importantes.
Objetivos del negocio y ambiente de trabajo
Aunque los objetivos del negocio están definidos
frecuentemente en términos generales, son usados para
descomponer el trabajo en
tareas específicas. En ciertas situaciones IR se enfoca en
la descripción de las tareas y en el análisis de
sistemas similares. Esta información proporciona la base para
especificar el sistema que será construido; aunque
frecuentemente se añadan al sistema tareas que no encajan
con el ambiente de trabajo planificado.

El nuevo sistema cambiará el ambiente de trabajo,
sin embargo, es muy difícil anticipar los efectos actuales
sobre la
organización. Los cambios no ocurren solamente cuando
un nuevo software es implementado y puesto en producción;
también ocurren cuando cambia el ambiente que lo rodea
(nuevas soluciones a
problemas, nuevo equipo para instalar, etc.). La necesidad de
cambio es
sustentada por el enorme costo de
mantenimiento; aunque existen diversas razones que dificultan el
mantenimiento del software, la falta de atención a la IR es la
principal.

Frecuentemente la especificación inicial es
también la especificación final, lo que obstaculiza
la
comunicación y el proceso de aprendizaje de
las personas involucradas; esta es una de las razones por las
cuales existen sistemas inadecuados.

Punto de vista de los clientes

Muchos sistemas tienen diferentes tipos de clientes.
Cada grupo de
clientes tiene necesidades diferentes y, diferentes
requerimientos tienen diferentes grados de importancia para
ellos. Por otro lado, escasas veces tenemos que los clientes son
los mismos usuarios; trayendo como consecuencia que los clientes
soliciten procesos que causan conflictos con
los solicitados por el usuario.

Diferentes puntos de vistas también pueden tener
consecuencias negativas, tales como datos
redundantes, inconsistentes y ambiguos.

El tamaño y complejidad de los requerimientos
ocasiona desentendimiento, dificultad para enfocarse en un solo
aspecto a la vez y dificultad para visualizar relaciones
existentes entre requerimientos.

• Barreras de comunicación

La ingeniería de requerimientos depende de una
intensa comunicación entre clientes y analistas
de requerimientos; sin embargo, existen problemas que no pueden
ser resueltos mediante la comunicación.

Para remediar esto, se deben abordar nuevas
técnicas operacionales que ayuden a superar estas
barreras y así ganar experiencia dentro del marco del
sistema propuesto.

• Evolución e integración del sistema

Pocos sistemas son construidos desde cero. En la
práctica, los proyectos se derivan de sistemas ya
existentes. Por lo tanto, los analistas de requerimientos deben
comprender esos sistemas, que por lo general son una integración de componentes de varios
proveedores.

Para encontrar una solución a problemas de este
tipo, es muy importante hacer planeamientos entre los
requerimientos y la fase de diseño; esto minimizará la
cantidad de fallas directas en el código.

• Documentación de requerimientos

Los documentos de
ingeniería de requerimientos son largos. La
mayoría están compuestos de cientos o miles de
páginas; cada página contiene muchos detalles que
pueden tener efectos profundos en el resto del
sistema.

Normalmente, las personas se encuentran con
dificultades para comprender documentos de
este tamaño, sobre todo si lo leen cuidadosamente. Es
casi imposible leer un documento de especificación de
gran tamaño, pues difícilmente una persona puede
memorizar los detalles del documento. Esto causa problemas y
errores que no son detectados hasta después de haberse
construido el sistema.

Actividades de la Ingeniería de
Requerimientos

En el proceso de IR son esenciales diversas actividades.
En este documento serán presentadas secuencialmente, sin
embargo, en un proceso de ingeniería de requerimientos
efectivo, estas actividades son aplicadas de manera continua y en
orden variado.

Dependiendo del tamaño del proyecto y del
modelo de
proceso de software utilizado para el ciclo de desarrollo, las
actividades de la IR varían tanto en número como en
nombres. La tabla #1 muestra algunos
ejemplos de las actividades identificadas para cada
proceso.

A pesar de las diferentes interpretaciones que cada
desarrollador tenga sobre el conjunto de actividades mostradas en
la tabla anterior, podemos identificar y extraer cinco
actividades principales que son:

• Análisis del Problema
• Evaluación y Negociación
• Especificación
• Validación
• Evolución

A continuación se explicará
cada una de ellas, presentándolas en el orden en que deben
ser aplicadas para un nuevo proyecto.
Análisis del Problema
El objetivo de
esta actividad es entender las verdaderas necesidades del
negocio.
Antes de describir qué pasos deben cumplirse en esta
actividad, debemos tener una definición clara del
término "Problema".
"Un problema puede ser definido como la diferencia entre las
cosas como se perciben y las cosas como se desean" . Aquí
vemos nuevamente la importancia que tiene una buena
comunicación entre desarrolladores y clientes; de esta
comunicación con el cliente depende que entendamos sus
necesidades.

A través de la definición de problema,
podemos ver entonces que la actividad de "Análisis del
Problema" tiene por objetivo que se comprendan los problemas del
negocio, se evalúen las necesidades iniciales de todos los
involucrados en el proyecto y que se proponga una solución
de alto nivel para resolverlo.

Durante el análisis del problema, se realizan una
serie de pasos para garantizar un acuerdo entre los involucrados,
basados en los problemas reales del negocio.

Estos pasos son los siguientes

Comprender el problema que se está resolviendo:
Es importante determinar quién tiene el problema
realmente, considerar dicho problema desde una variedad de
perspectivas y explorar muchas soluciones
desde diferentes puntos de vista. Veamos la siguiente necesidad:
"El cliente se queja mucho por la enorme fila que debe formar
para realizar una transacción bancaria".

Perspectiva del cliente = Pérdida de tiempo
Perspectiva del banco = Posibles
pérdidas de clientes

Posibles soluciones pueden ser, determinar por
qué demoran los cajeros, colocar una nueva caja (implica
contratación de nuevos cajeros), abrir una nueva sucursal
(involucra personal nuevo y
estudio de
mercado), realizar transacciones por otros medios
(teléfono, internet, mediante cajeros
automáticos, autobancos, etc).

Como puede verse, múltiples soluciones aplican
para el mismo problema, sin embargo, sólo una de ellas
será la más factible. Las soluciones iniciales,
deben ser definidas tomando en cuanta tanto la perspectiva
técnica como la del negocio.

Construir un vocabulario común: Debe
confeccionarse un glosario en
dónde se definan todos los términos que tengan
significados comunes (sinónimos) y que serán
utilizados durante el proyecto. Por ejemplo, las palabras
pignoración, retención, valor en
suspenso, custodia, garantía, entre otras, son utilizadas
para referirse a la acción de dejar una prenda (puede ser
cualquier forma de ahorros) como garantía de una deuda
adquirida.

La creación de un glosario es sumamente
beneficiosa ya que reduce los términos ambiguos desde el
principio, ahorra tiempo, asegura que todos los participantes de
una reunión están en la misma página,
además de ser reutilizable en otros proyectos.

Identificar a los afectados por el sistema: Identificar
a todos los afectados evita que existan sorpresas a medida que
avanza el proyecto. Las necesidades de cada afectado, son
discutidas y sometidas a debate durante
de ingeniería de requerimientos, aunque esto no garantiza
que vaya a estar disponible toda la información necesaria
para especificar un sistema adecuado.

Para saber quiénes son las personas,
departamentos, organizaciones
internas o externas que se verán afectadas por el sistema,
debemos realizar algunas preguntas.

• ¿Quién usará el sistema que se
  va a construir?
• ¿Quién desarrollará el
  sistema?
• ¿Quién probará el
  sistema?
• ¿Quién documentará el
  sistema?
• ¿Quién dará soporte al
  sistema?
• ¿Quién dará mantenimiento al
  sistema?
• ¿Quién mercadeará,
  venderá, y/o distribuirá el sistema?
• ¿Quién se beneficiará por el
  retorno de inversión del sistema?

Como vemos, debe conocerse la opinión de todo
aquél que de una u otra forma está involucrado con
el sistema, ya sea directa o indirectamente.

Definir los límites y
restricciones del sistema: Este punto es importante pues debemos
saber lo que se está construyendo, y lo que no se
está construyendo, para así entender la estrategia del
producto a corto y largo plazo. Debe determinarse cualquier
restricción ambiental, presupuestaria, de tiempo,
técnica y de factibilidad que
limite el sistema que se va a construir.

Evaluación y negociación de los
requerimientos

La diversa gama de fuentes de las
cuales provienen los requerimientos, hacen necesaria una evaluación
de los mismos antes de definir si son adecuados para el cliente.
El término "adecuado" significa que ha sido percibido a un
nivel aceptable de riesgo tomando en
cuenta las factibilidades técnicas y económicas, a
la vez que se buscan resultados completos, correctos y sin
ambigüedades.

En esta etapa se pretende limitar las expectativas del
cliente apropiadamente, tomando como referencia los niveles de
abstracción y descomposición de cada problema
presentado.

Los principales pasos de esta actividad son:

Descubrir problemas potenciales: En este paso se asegura
que todas las características descritas en el punto 1.1
estén presentes en cada uno de los requerimientos, es
decir, se identifican aquellos requerimientos ambiguos,
incompletos, inconsistentes, etc.

Clasificar los requerimientos:

En este paso se busca identificar la importancia que
tiene un requerimiento en términos de
implementación. A esta característica se le conoce
como prioridad y debe ser usada para establecer la secuencia en
que ocurrirán las actividades de diseño
y prueba de cada requisito. La prioridad de cada requerimiento
dependerá de las necesidades que tenga el
negocio.

En base a la prioridad, cada requerimiento puede ser
clasificados como mandatorio, deseables o innecesarios. Un
requerimiento es mandatorio si afecta una operación
crítica del negocio. Si existe algún proceso que se
quiera incluir para mejorar los procesos actuales, estamos ante
un requerimiento deseable; y si se trata de un requerimiento
informativo o que puede esperar para fases posteriores, el
requerimiento es catalogado como innecesario.

Una vez hecha esta categorización de los
requerimientos, puedo tomar como estrategia
general el incluir los mandatorios, discutir los deseables y
descartar los innecesarios. Antes de decidir la inclusión
de un requerimiento, también debe analizarse su costo,
complejidad, y una cantidad de otros factores. Por ejemplo, si un
requerimiento fuera trivial de implementar, puede ser una buena
idea incluirlo por más que éste sea sólo
deseable.

Evaluar factibilidades y riesgos:
Involucra la evaluación de factibilidades técnicas
(¿pueden implementarse los requerimientos con la tecnología actual?);
factibilidades operacionales (¿puede ser el sistema
utilizado sin alterar el organigrama
actual?); factibilidades económicas (¿ha sido
aprobado por los clientes el presupuesto?).

En la actividad de evaluación y
negociación, se incrementa la comunicación entre el
equipo de desarrollo y los afectados. Para que los requerimientos
puedan ser comunicados de manera efectiva, hay una serie de
consideraciones que deben tenerse en cuenta; entre las
principales tenemos:

• Documentar todos los requerimientos a un nivel de
  detalle apropiado.
• Mostrar todos los requerimientos a los involucrados
  en el sistema.
• Analizar el impacto que causen los cambios a
  requerimientos antes de aceptarlos.
• Establecer las relaciones entre requerimientos que
  indiquen dependencias.
• Negociar con flexibilidad para que exista un
  beneficio mutuo.
• Enfocarse en intereses y no en
  posiciones.

Especificación de Requisitos de Software
(SRS)

La especificación de requisitos de software es la
actividad en la cual se genera el documento, con el mismo nombre,
que contiene una descripción completa de las necesidades y
funcionalidades del sistema que será desarrollado;
describe el alcance del sistema y la forma en como hará
sus funciones, definiendo los requerimientos funcionales y los no
funcionales.

En la SRS se definen todos los requerimientos de
hardware y
software, diagramas,
modelos de
sistemas y cualquier otra información que sirva de soporte
y guía para fases posteriores.

Es importante destacar que la especificación de
requisitos es el resultado final de las actividades de
análisis y evaluación de requerimientos; este
documento resultante será utilizado como fuente
básica de comunicación entre los clientes, usuarios
finales, analistas de sistema, personal de
pruebas, y todo aquel involucrado en la implementación del
sistema.

Los clientes y usuarios utilizan la SRS para comparar si
lo que se está proponiendo, coincide con las necesidades
de la empresa. Los
analistas y programadores la utilizan para determinar el producto
que debe desarrollarse. El personal de pruebas elaborará
las pruebas funcionales y de sistemas en base a este documento.
Para el administrador del
proyecto sirve como referencia y control de la
evolución del sistema.

La SRS posee las mismas características de los
requerimientos: completa, consistente, verificable, no ambigua,
factible, modificable, rastreable, precisa, entre otras. Para que
cada característica de la SRS sea considerada, cada uno de
los requerimientos debe cumplirlas; por ejemplo, para que una SRS
se considere verificable, cada requerimiento definido en ella
debe ser verificable; para que una SRS se considere modificable,
cada requerimiento debe ser modificable y así
sucesivamente. Las características de la SRS son
verificadas en la actividad de Validación, descrita en el
punto 3.4.

La estandarización de la SRS es fundamental pues
ayudará, entre otras cosas, a facilitar la lectura y
escritura de
la misma. Será un documento familiar para todos los
involucrados, además de asegurar que se cubren todos los
tópicos importantes.

Existen plantillas creadas para la SRS, sin embargo,
cada uno tiene la potestad de crear su propia plantilla. En el
anexo #1 se muestra una
plantilla completa para la especificación de
requisitos.

Validación de Requisitos

La validación es la actividad de la IR que
permite demostrar que los requerimientos definidos en el sistema
son los que realmente quiere el cliente; además revisa que
no se haya omitido ninguno, que no sean ambiguos, inconsistentes
o redundantes.

En este punto es necesario recordar que la SRS debe
estar libre de errores, por lo tanto, la validación
garantiza que todos los requerimientos presentes en el documento
de especificación sigan los estándares de
calidad.

No debe confundirse la actividad de evaluación de
requerimientos con la validación de requerimientos. La
evaluación verifica las propiedades de cada requerimiento,
mientras que la validación revisa el cumplimiento de las
características de la especificación de
requisitos.

Durante la actividad de validación pueden hacerse
preguntas en base a cada una de las características que se
desean revisar. A continuación se presentan varios
ejemplos:

• ¿Están incluidas todas las funciones
  requeridas por el cliente? (completa)
• ¿Existen conflictos
  en los requerimientos? (consistencia)
• ¿Tiene alguno de los requerimientos más
  de una interpretación? (no ambigua)
• ¿Está cada requerimiento claramente
  representado? (entendible)
• ¿Pueden los requerimientos ser implementados
  con la tecnología y el presupuesto disponible?
  (factible)
• ¿Está la SRS escrita en un lenguaje
  apropiado? (clara)
• ¿Existe facilidad para hacer cambios en los
  requerimientos? (modificable)
• ¿Está claramente definido el origen de
  cada requisito? (rastreable)
• ¿Pueden los requerimientos ser sometidos a
  medidas cuantitativas? (verificable)

La validación de requerimientos es importante
pues de ella depende que no existan elevados costos de
mantenimiento para el software desarrollado.

Evolución de los requerimientos

Los requerimientos son una manera de comprender mejor el
desarrollo de las necesidades de los usuarios y cómo los
objetivos de la organización pueden cambiar, por lo
tanto,

es esencial planear posibles cambios a los
requerimientos cuando el sistema sea desarrollado y utilizado. La
actividad de evolución es un proceso externo

que ocurre a lo largo del ciclo de vida del
proyecto.

Los requerimientos cambian por diferentes razones. Las
más frecuentes son:

• Porque al analizar el problema, no se hacen las
  preguntas correctas a las personas correctas.
• Porque cambió el problema que se estaba
  resolviendo.
• Porque los usuarios cambiaron su forma de pensar o
  sus percepciones.
• Porque cambió el ambiente de negocios.
• Porque cambió el mercado en
  el cual se desenvuelve el negocio.

Cambios a los requisitos involucra modificar el tiempo
en el que se va a implementar una característica en
particular, modificación que a la vez puede tener impacto
en otros requerimientos. Por esto, la administración de
cambios involucra actividades como establecer políticas,
guardar históricos de cada requerimiento, identificar
dependencias entre ellos y mantener un control de
versiones.

Tener versiones de los requerimientos es tan importante
como tener versiones del código, ya que evita tener
requerimientos emparchados en un proyecto

Entre algunos de los beneficios que proporciona el
control de versiones están:

• Prevenir cambios no autorizados.
• Guardar revisiones de los documentos de
  requerimientos.
• Recuperar versiones previas de los
  documentos.
• Administrar una estrategia de "releases".
• Prevenir la modificación simultánea a
  los requisitos.

En vista que las peticiones de cambios provienen de
muchas fuentes, las mismas deben ser enrutadas en un solo
proceso. Esto se hace con la finalidad de evitar problemas y
conseguir estabilidad en los requerimientos.