Elicitación, Análisis, Especificación,

Validación y Gestión de Requerimientos

Ingeniería de Software
Índice
• Introducción
• ¿Qué es un requerimiento?
• ¿Que es un análisis de requerimiento?
• Aspectos de los requerimientos
• Características de un requerimiento
• Elicitación de requerimientos: Entrevista
• Análisis de requerimientos
• Especificación de requerimientos
• Tipos de requerimientos
• Usuarios de requerimientos
• Validación de requerimientos
Introducción
¿Qué es un Requerimiento?
Los requerimientos especifican qué es lo que el sistema debe
hacer (sus funciones) y sus propiedades esenciales y deseables.

Un requerimiento expresa el propósito del sistema sin

considerar como se va a implantar.

En otras palabras, los requerimientos identifican el

qué del sistema, mientras que el diseño establece el
cómo del sistema.
¿Qué es un Análisis de Requerimiento?
Es el conjunto de técnicas y procedimientos que nos
permiten conocer los elementos necesarios para definir un
proyecto de software.

El análisis de requerimientos proporciona una vía para que

los clientes y lo desarrolladores lleguen a un acuerdo sobre
lo que debe hacer el sistema. La especificación, producto de
este análisis proporciona las pautas a seguir a los
diseñadores del sistema.
¿Qué es un Análisis de Requerimiento?

“La carencia de buenos requerimientos ha sido la causa del

fracaso de proyectos con presupuestos de millones de dólares, ha
impedido el desarrollo productivo, y ha sido el mayor
contribuyente de los costes elevados del mantenimiento del
software” .

El Dr. Raymond Yeh en el prólogo de “Sistema y Software de Ingeniería de Requisitos”,

IEEE Computer Society Press Tutorial, editores, M. Dorfman, y H.R. Thayer, 1990
 Aspectos de los Requerimientos
Según el estándar internacional de Especificación de Requerimientos IEEE
830:1998 reemplazado por IEEE 29148:2011, los documentos de definición y
especificación de requerimientos deben contemplar los siguientes aspectos:

Ambiente físico

➢ ¿Dónde esta el equipo que el sistema necesita para funcionar?

➢ ¿Existe una localización o varias?
➢ ¿Hay restricciones ambientales como temperatura, humedad o
interferencia magnética?
 Aspectos de los Requerimientos

Interfaces

➢¿La entrada proviene de uno o más sistemas?

➢¿La salida va a uno o más sistemas?
➢¿Existe una manera preestablecida en que deben
formatearse los datos?
Aspectos de los Requerimientos

Usuarios y factores humanos

➢ ¿Quien usará el sistema?

➢ ¿Habrá varios tipos de usuario?
➢ ¿Cuál es el nivel de habilidad de cada tipo de usuario?
➢ ¿Qué clase de entrenamiento requerirá cada tipo de usuario?
➢ ¿Cuán fácil le será al usuario comprender y utilizar el sistema?
➢ ¿Cuán difícil le resultará al usuario hacer uso indebido del sistema?
Aspectos de los Requerimientos
Funcionalidad

➢ ¿Qué hará el sistema?

➢ ¿Cuándo lo hará?
➢ ¿Existen varios modos de operación?
➢ ¿Cómo y cuando puede cambiarse o mejorarse un sistema?
➢ ¿Existen restricciones de la velocidad de ejecución, tiempo de
respuesta o rendimiento?
Aspectos de los Requerimientos

Documentación

➢ ¿Cuánta documentación se requiere?

➢ ¿Debe estar en línea, en papel o en ambos?
➢ ¿A que audiencia está orientado cada tipo de información?
 Aspectos de los Requerimientos

Datos

➢ ¿Cuál será el formato de los datos, tanto para la entrada como para la
salida?
➢ ¿Cuán a menudo serán recibidos o enviados?
➢ ¿Cuán exactos deben ser?
➢ ¿Con qué grado de precisión deben hacerse los cálculos?
➢ ¿Cuántos datos fluyen a través del sistema?
➢ ¿Debe retenerse algún dato por algún período de tiempo?
Aspectos de los Requerimientos
Recursos
➢ ¿Qué recursos materiales, personales o de otro tipo se requieren para
construir, utilizar y mantener el sistema?
➢ ¿Qué habilidades deben tener los desarrolladores?
➢ ¿Cuánto espacio físico será ocupado por el sistema?
➢ ¿Cuáles son los requerimientos de energía, calefacción o
acondicionamiento de aire?
➢ ¿Existe un cronograma prescrito para el desarrollo?
➢ ¿Existe un límite sobre la cantidad de dinero a gastar en el desarrollo o en
hardware y software?
Aspectos de los Requerimientos

Seguridad

➢ ¿Debe controlarse el acceso al sistema o a la información?

➢ ¿Cómo se podrán aislar los datos de un usuario de los de otros?
➢ ¿Cómo podrán aislarse los programas de usuario de los otros programas y
del sistema operativo?
➢ ¿Con qué frecuencia deben hacerse copias de respaldo?
➢ ¿Las copias de respaldo deben almacenarse en un lugar diferente?
➢ ¿Deben tomarse precauciones contra el fuego, el daño provocado por agua
o el robo?
Aspectos de los Requerimientos
Aseguramiento de la calidad

➢ ¿Cuáles son los requerimientos para la confiabilidad, disponibilidad,

facilidad de mantenimiento, seguridad y demás atributos de calidad?
➢ ¿Cómo deben demostrarse las características del sistema a terceros?
➢ ¿El sistema debe detectar y aislar defectos?
➢ ¿Cuál es el promedio de tiempo prescrito entre fallas?
➢ ¿Existe un tiempo máximo permitido para la recuperación del sistema
después de una falla?
 Aspectos de los Requerimientos

➢ ¿El mantenimiento corregirá los errores, o incluirá también el

mejoramiento del sistema?
➢ ¿Qué medidas de eficiencia se aplicarán al uso de recursos y al tiempo
de respuesta?
➢ ¿Cuán fácil debe ser mover el sistema de una ubicación a otra o de un
tipo de computadora a otro?
Características de un Requerimiento
Las características de los requerimientos son mencionados en el estándar
IEEE830:

Deben ser correctos.

Tanto el cliente como el desarrollador deben revisarlos para asegurar que
no tienen errores.

Deben ser consistentes.

Dos requerimientos son inconsistentes cuando es imposible satisfacerlos
simultáneamente.
Características de un Requerimiento
Deben estar completos.
El conjunto de requerimientos está completo si todos los estados posibles,
cambios de estado, entradas, productos y restricciones están descritos en
alguno de los requerimientos.

Deben ser realistas.

Todos los requerimientos deben ser revisados para asegurar que son
posibles.
Características de un Requerimiento
Cada requerimiento describe algo que es necesario para el cliente.
Los requerimientos deben ser revisados para conservar sólo aquellos que inciden
directamente en la resolución del problema del cliente.

Deben ser verificables.

Se deben poder preparar pruebas que demuestren que se han cumplido los
requerimientos.

Deben ser rastreables.

Se puede rastrear cada función del sistema hasta el conjunto de requerimientos que
la establece.
Elicitación de Requerimientos
La entrevista

Es una forma de recoger información de otra persona a través

de una comunicación interpersonal que se lleva a cabo por
medio de una conversación estructurada.
Elicitación de Requerimientos
Fases de la entrevista:
Preparación:

✓Análisis de documentos de la empresa.

✓Selección de las personas a entrevistar a través del
análisis de perfil de las mismas.
✓Definir objetivo y contenido de la entrevista.
✓Planificar lugar y hora de la entrevista.
Elicitación de Requerimientos
Fases de la entrevista:
Realización:
✓ Apertura: Presentarse e informar al entrevistado sobre la razón de la
entrevista.
✓ Desarrollo: Cumplir las reglas del protocolo, hay que llegar a un acuerdo
sobre como se va a registrar la información obtenida.
✓ Terminación: Se termina recapitulando la entrevista agradeciendo el
esfuerzo y dejando abierta la posibilidad de volver a contactar para
aclarar conceptos o bien citándole para otra entrevista.
Elicitación de Requerimientos
Fases de la entrevista:
Análisis:

Consiste en leer las notas, pasarlas en limpio, reorganizar la

información, contrastarlas con otras entrevistas o fuentes de
información, evaluar como ha ido la entrevista.
Elicitación de Requerimientos
Tipos de entrevistas:
Las entrevistas pueden ser de dos tipos:

1. Entrevistas cerradas: donde los entrevistados responden a un

conjunto predefinido de preguntas.

2. Entrevistas abiertas: donde no hay un programa predefinido. El

equipo de la ingeniería de requerimientos examina una serie de
cuestiones con los involucrados con el sistema y, por lo tanto,
desarrolla una mejor comprensión de sus necesidades.

En la práctica, las entrevistas son una mezcla de estos dos tipos.

Elicitación de Requerimientos
Una manera de manejar las entrevistas:

Antes de la entrevista.

1. Enumerar y dar prioridad a los clientes que se entrevistarán.

2. Programar una entrevista con tiempos de inicio y
terminación fijos.
Elicitación de Requerimientos
En la entrevista

1. No ser pasivo, investigar y animar, persistir en entender

deseos y explorar necesidades.
2. Examinar casos de uso, flujos de datos y/o diagramas de
estado.
3. Tomar notas exhaustivas.
4. Programar una reunión de seguimiento.
 Elicitación de Requerimientos

Después de la entrevista.

1. Bosquejar la especificación de los requerimientos.

2. Enviar correos electrónicos a los clientes para obtener sus
comentarios.

No basta con hacer preguntas, es importante la forma en que se plantea la conversación y la relación que se
establece.
 Análisis de Requerimientos
El Análisis de Requerimientos es un proceso al cual Sommerville, llama “Ingeniería de
Requerimientos” cuya meta es crear y mantener un documento de requerimientos del
sistema.

Este proceso general consta de cuatro subprocesos:

➢ El estudio de viabilidad, que evalúa si el sistema es útil para el negocio.
➢ Obtención y análisis de requerimientos.
➢ Especificación de requerimientos: transformación de los requerimientos en
formularios estándar.
➢ Validación: verificar que los requerimientos realmente definen el sistema que
quiere el cliente.
Análisis de Requerimientos
Análisis de Requerimientos
Estudio de viabilidad.

Sommerville define el estudio de viabilidad como un estudio corto y orientado a

resolver las siguientes preguntas:

1. ¿El sistema contribuye a los objetivos generales de la organización o empresa?

2. ¿El sistema se puede implantar utilizando tecnología actual dentro de las
restricciones de tiempo y presupuesto?
3. ¿El sistema puede integrarse a otros sistemas existentes en la empresa?
Análisis de Requerimientos
Estudio de viabilidad.

El estudio de viabilidad no debe requerir más de dos o tres semanas.

El resultado de este estudio es un informe que recomiende si vale o no la

pena seguir con la ingeniería de requerimientos y el proceso de desarrollo
del sistema.

En el informe se pueden proponer cambios en el alcance, el presupuesto o

sugerir requerimientos adicionales de alto nivel.
Especificación de Requerimientos

La Especificación es un documento que define, de forma

completa, precisa y verificable, los requisitos, el diseño y el
comportamiento u otras características, de un sistema o
componente de un sistema.
 Especificación de Requerimientos

Una buena especificación de requerimientos debe procurar:

❖Separar funcionalidad de implementación.

Una especificación es una descripción de lo que se desea, en vez de
cómo se realiza. Esto en la práctica puede llegar a no suceder del todo,
sin embargo es un buen lineamiento a seguir.

❖Una especificación debe abarcar el entorno en el que el sistema opera.

Similarmente, el entorno en el que opera el sistema y con el que
interactúa debe ser especificado.
Especificación de Requerimientos

❖Debe ser modificable.

Ninguna especificación puede ser siempre totalmente completa. El

entorno en el que existe es demasiado complejo para ello. Una
especificación es un modelo, una abstracción, de alguna situación real
(o imaginada). Por tanto, será incompleta. Además, al ser formulada
existirán muchos niveles de detalle.
Especificación de Requerimientos
La especificación debe contener los requerimientos del sistema, la IEEE-830,
1998 divide los requerimientos en funcionales y no funcionales.
Los requerimientos funcionales describen una interacción entre el sistema
y su ambiente, describen cómo debe comportarse el sistema ante
determinado estímulo.
Los requerimientos funcionales de un sistema describen lo que el sistema
debe hacer.
Los requerimientos no funcionales ponen límites y restricciones al sistema.
Especificación de Requerimientos
Existen dos tipos de documentos de requerimientos:
Definición de los Requerimientos Dirigido
(lenguaje natural) al cliente

Especificación de requerimientos Dirigido

(lenguaje técnico) al desarrollador
 Métodos de comunicación
Los métodos de comunicación, también llamados Técnicas de Elicitación de
Información, son procesos mediante los cuales se consigue que los usuarios descubran
los requisitos que desean en la aplicación.

Las técnicas principales utilizadas son:

• Entrevistas
• Desarrollo conjunto de aplicaciones
• Prototipado
• Observación
• Estudio de la documentación existente en la empresa
• Tormenta de ideas: Reuniones de usuarios en las que en una primera fase se
sugieren toda clase de ideas por muy disparatadas que parezcan.
Tipos de Requerimientos

❖Restricciones globales.

❖Requerimientos Funcionales.

❖Requerimientos No-Funcionales.
Restricciones globales

Afectan a todo el producto y son determinadas por el usuario y los que

administran el proyecto/producto.

1. Propósito del sistema

2. El cliente
3. El usuario
4. Convenciones para la nomenclatura y las definiciones
5. Hechos relevantes
6. Restricciones del proyecto
7. Suposiciones
Requerimientos Funcionales

Los requerimientos funcionales definen qué debe hacer un

sistema.

• Alcance del sistema

Requerimientos No-Funcionales
Los requerimientos no funcionales definen cómo debe ser el sistema.

Apoyan a las funciones, son las propiedades que el producto debe tener:
◦ Apariencia y sensación
◦ Usabilidad
◦ Performance
◦ Operatividad
◦ Mantenibilidad
◦ Seguridad
◦ Requerimientos Políticas
◦ Requerimientos legales
Requerimientos Funcionales

➢Describir una acción que debe realizar el producto.

➢No escribir soluciones. Cada evento/caso de uso tiene muchos

requerimientos funcionales.

➢Algunos son parte también de otros eventos.

 Requerimientos Funcionales

➢Iniciar descomponiendo los casos de uso en pasos:

▪serie de pasos para completar el trabajo de un caso de uso.
▪Acciones que puede reconocer el usuario.
▪Posiblemente una interacción entre usuario y máquina.
▪número limitado de pasos.

➢Usar un formato para determinar qué tan completa está la especificación

de requerimientos.
Requerimientos Funcionales

➢ Identificación de los requerimientos: El darles un número único de

identificación permite recuperarlos y relacionarlos con mayor facilidad.

➢ Un requerimiento puede estar relacionado a varios eventos.

➢Utilizando los formatos para escribir requerimientos (pre-definidos por la

empresa), la información obtenida, las listas de eventos y casos de uso
conforman una vez terminadas la especificación de requerimientos.
Restricciones:
Restricciones globales son las propiedades que aplican a todo el producto
Esta parte de la especificación probablemente será escrita por la
administración del proyecto.
◦ Propósito del sistema
◦ El cliente para el producto
◦ Usuarios del producto
◦ Convenciones de nomenclatura y definiciones
◦ Hechos/datos relevantes
◦ Restricciones del proyecto
◦ Suposiciones
 Restricciones
Para las convenciones de nomenclatura se sugiere el uso de los diccionarios estándar
nacionales/internacionales para la industria.

Buenos nombres son fácilmente distinguibles y no requieren muchas explicación.

Cada nombre deberá tener una definición.

Deben definirse todas las abreviaturas, términos y siglas.

Restricciones
Hechos / datos relevantes: Están conformados por fuerzas, sistemas, actividades
del mundo externo que pueden tener efecto en el producto.

Se identifican cambios que deben tomarse en consideración.

Cambios probables en las fronteras del producto.

Cambios tecnológicos, a otros productos, en la estructura organizacional, al

sistema legal, políticas, etc.
 Restricciones del proyecto:

Tecnológicas, de presupuesto, tiempo, etc. razones por las que se restringe la

manera en que se crea el producto.

Siempre indagar el por qué de estas restricciones y anotar todas las restricciones
y sus razones para el producto.
Requerimientos No-Funcionales

◦ Describen las propiedades o características que el producto debe tener.

◦ Cada requerimiento funcional tiene asociados requerimientos no-funcionales.

◦ Algunos pueden afectar a nivel de eventos, otros a todo el producto.

 Requerimientos No-Funcionales

◦ Requerimientos no-funcionales:
◦ Apariencia y sensación: (Bosquejos)
◦ Usabilidad: Depende de la definición de los usuarios, cuantificable por los
criterios de evaluación.
◦ Performance: Requerimientos reales del performance, velocidad, precisión,
disponibilidad, seguridad, nivel de servicio, volúmenes de datos, etc.
◦ Operacional: Ambiente en el que el usuario operará el producto y productos
con los que colabora.
 Requerimientos no-funcionales

◦ Mantenibilidad: Tiempo esperado y tiempo permitido para realizar

cambios de mantenimiento, portabilidad.

◦ Seguridad: requerimientos para permitir el acceso, pruebas de integridad

para prevenir mal -uso no intencionado por usuarios autorizados,
auditorías para detectar mal-uso, recuperación después de un error,
prueba de integridad después de un hecho anormal. Considerar involucrar
a un experto en seguridad.
 Resumiendo…
Características de una BUENA especificación de requerimientos:

No ambigua.
Completa.
Fácil de verificar.
Consistente (coherente).
Clasificada por importancia o estabilidad.
Fácil de modificar.
Fácil identificación del origen y de las consecuencias de cada requisito.
De fácil utilización durante la fase de explotación y de mantenimiento.
 Resumiendo…
Los requerimientos deberían ser completos, consistentes y
correctos:

• Completos: Deberían incluir descripción de toda la funcionalidad

requerida.

• Consistentes: No deberían ser conflictivos o contradictorios.

• Correctos: No deberían tener errores.

Usuarios de un documento de requerimientos

• Especifican los requerimientos y los leen

Clientes para comprobar que cubren sus
necesidades. Los clientes especifican los
del sistema cambios a los requerimientos.

• Usan el documento de requerimientos

para planear una cotización para el sistema
Administradores y el proceso de desarrollo del sistema.
Usuarios de un documento de requerimientos

Ingenieros • Usan los requerimientos para

entender qué sistema debe
del sistema desarrollarse.

Ingenieros de • Usan los requerimientos para

prueba desarrollar pruebas de
del sistema validación para el sistema.
Usuarios de un documento de requerimientos

Ingenieros • Usan los requerimientos para

de comprender el sistema y las
mantenimiento relaciones entre sus
del sistema componentes.
Estructura de la plantilla especificación de requisitos Estándar IEEE 830
1. Introducción 3. Requisitos de usuario
1.1. Objetivo 3.1. Requisitos funcionales
1.2. Ámbito 3.2. Requisitos no funcionales
1.3. Histórico de revisiones 4. Requisitos de sistema
1.4. Lista de distribución 4.1. Actores
1.5. Definiciones, acrónimos y 4.2. Casos de uso
abreviaturas 5. Trazabilidad
1.6. Referencias 6. Anexo a: clientes web soportados
2. Descripción general 7. Anexo b: interfaces y lenguajes
2.1. Perspectiva del producto
2.2. Funciones del producto
2.3. Características de los usuarios
2.4. Restricciones
2.5. Asunciones y dependencias
2.6. Hechos relevantes
Escenarios
Los Escenarios son ejemplos de la vida real de cómo puede ser usado un
sistema.

Deben incluir
✓ Una descripción de la situación de partida;
✓ Una descripción del flujo normal de eventos;
✓ Una descripción de lo que puede ir mal;
✓ Información sobre otras actividades concurrentes;
✓ Una descripción del estado cuando el escenario acaba.

EL tipo de escenario más usado son los Casos de Uso.

 Escenarios

Ejemplo:

• El Sistema pide al Cliente un número de identificación personal (PIN).

• El Cliente introduce el PIN a través del teclado y acepta la entrada.
• El Sistema comprueba si el PIN es válido.
• El Sistema acepta la entrada y así finaliza el escenario.
 Verificación y Validación de Requerimientos

Prevenir la infiltración de requerimientos: los que entran al producto

después del proceso de análisis de requerimientos.

Prevenir la fuga de requerimientos: aquellos cuya fuente se desconoce.

Validación de Requerimientos
Los requerimientos deben ser validados para:
▪Asegurar que el ingeniero software los ha comprendido.
▪El documento de ERS es conforme a los estándares establecidos,
comprensible, consistente y completo.
▪Se trata de asegurar que el documento SRS define el software adecuado,
es decir, el que espera el usuario.
▪Las principales técnicas de validación:
▪Revisiones
▪Prototipado
▪Validación de Modelos
▪Pruebas de Aceptación
 Validación de Requerimientos
Comprobaciones a realizar:
➢Validez. El sistema provee las funciones que soportan mejor las necesidades
del cliente.
➢Consistencia. No existen conflictos entre los requerimientos.
➢Completitud. Están incluidas todas las funciones requeridas por el usuario.
➢Realismo. Los requerimientos pueden ser implementados con el presupuesto y
tecnologías disponibles.
➢Verificable. Los requerimientos pueden ser verificados.
Técnicas de Validación de Requerimientos

Revisiones [inspecciones]
◦ Un grupo de personas lee, analiza, discute el documento de SRS y las
formas de solucionar los problemas detectados.
◦ Deben participar representantes del cliente y los usuarios.
◦ Norma: IEEE Std 1028-1997, IEEE Standard for Software Reviews
Las inspecciones pueden ser formales (documento concluido) o
informales.
Técnicas de validación de Requerimientos

Revisiones
Se pueden usar Listas de Comprobación:
Unicidad
◦ ¿Está cada requerimiento identificado de forma unívoca?
Comprensibilidad
◦ ¿Se describen en el glosario los términos especializados o técnicos?
◦ ¿Es cada requisito autocontenido o se tienen que examinar otros requerimientos para
comprenderlo?
◦ ¿Hay contradicciones?
◦ ¿Están agrupados los requerimientos relacionados?
Técnicas de validación de Requerimientos

Trazabilidad
◦ ¿Está establecido adecuadamente el origen de cada requerimiento?

Adaptabilidad
◦ ¿Puede cambiarse un requerimientos sin impactar demasiado a los otros?
 Técnicas de validación de Requerimientos
Prototipos:

Selección del
Desarrollo de los Ejecución de Documentación
Encargado
Escenarios de los de
de Pruebas del
Prueba Escenarios Problemas
Prototipo

Documentar y Extender el Prototipo

Escribir el Manual de Usuario fuerza a un análisis detallado de los requerimientos y así

revelarse nuevos problemas
Gestión de Requerimientos

Los requisitos cambian:

◦ Cambio en la estrategia o prioridades del negocio
◦ Cambios tecnológicos
◦ Cambios en leyes o regulaciones

La Gestión de Requisitos consiste en gestionar

◦ Los cambios en los requerimientos acordados
◦ Las relaciones entre requerimientos
◦ Las dependencias entre el documento ERS y otros documentos
 Gestión de Requerimientos
Más del 50% de los requerimientos suelen cambiar durante la elaboración del
SRS y después, durante el desarrollo del software

La Gestión de Requisitos implica la recolección,

almacenamiento y mantenimiento de grandes cantidades de información.
Para ello existen herramientas CASE con:
• Base de Datos para almacenar requerimientos
• Facilidades de análisis y generación de documentos
• Facilidades de gestión de cambios
• Facilidades de Trazabilidad
Elicitación, Análisis, Especificación,
Validación y Gestión de Requerimientos

Ingeniería de Software