El documento describe el proceso de ingeniería de requisitos para el desarrollo de software. Explica que la ingeniería de requisitos incluye actividades como el análisis de requisitos, la definición de requisitos y la especificación de requisitos con el objetivo de definir formalmente las funciones y restricciones del sistema. También señala la importancia de validar los requisitos con los usuarios para asegurar que el sistema satisfaga realmente sus necesidades.

1. Análisis y Especificación de
Requisitos
Ing. Noretsys Rodríguez

2. Ingeniería de Requisitos
• Proceso mediante el cual se establecen los
servicios que el sistema debe brindar y las
restricciones que debe cumplir.
• Es un proceso sistemático para derivar la
definición del sistema a ser construido.
Necesidades
del Cliente
Documento
de
Requisitos
Ingeniería de
Requisitos

3. Contenido
• Requisitos Funcionales
– servicios o funciones ofrecidas.
• Requisitos No Funcionales
– otras cualidades del sistema (performance,
usabilidad, etc).
• Restricciones al Proceso de Desarrollo
– Tiempo y costo principalmente.

4. Requisito
• Definición abstracta de lo que
el sistema debe hacer
• Definición matemática y formal
de las funciones del sistema
Abstracción

5. Documento de Requisitos
• En la licitación de un gran proyecto de software,
– Debe definir las necesidades en forma suficientemente
abstracta para que la solución no esté predefinida.
– Los requisitos deben escribirse de modo que varios
contratistas puedan competir por el contrato,
ofreciendo quizás diferentes formas de lograr los
objetivos de la empresa.
– Una vez que la licitación es adjudicada, el contratista
debe escribir la definición del sistema para el cliente,
en más detalle, para que el cliente entienda y pueda
validar lo que el software finalmente hará.
– Ambos documentos pueden llamarse documento de
requisitos del sistema.

6. Diferentes Documentos
• Definición de Requisitos
(inicial)
– servicios y cualidades
que se espera del
sistema,
– restricciones de
operación,
– restricciones sobre la
ejecución del proyecto,
– lenguaje natural y
diagramas,
– la información la brinda
el cliente.
• Especificación de Requisitos
– detalle de los servicios, cualidades
y restricciones del sistema,
– lenguaje más formal y preciso,
– base del contrato entre
desarrolladores y cliente.
• Especificación del Software
– descripción abstracta del software,
– base para el diseño y la
implementación,
– agrega detalles técnicos.

7. Usuarios de los Requisitos
• Definición de Requisitos
– gerencia del cliente
– usuarios finales
– ingenieros del cliente
– gerencia de desarrollo
– arquitectos del sistema.
• Especificación de Requisitos
– usuarios finales
– ingenieros del cliente
– arquitectos del sistema
– desarrolladores.
• Especificación del Software
– ingenieros del cliente
– arquitectos del sistema
– diseñadores del sistema
– desarrolladores.

8. Requisitos Incompletos
• En sistemas grandes y complejos los requisitos nunca
están completos al iniciar el desarrollo del proyecto:
– se espera que la nueva solución mejore la situación actual
(sistema manual o anticuado); no se sabe bien en qué
dirección mejorar;
– usuarios múltiples y diversos con distintas necesidades y
prioridades; el sistema final será un compromiso;
– quien paga por el sistema no es habitualmente quien lo va a
usar; las restricciones de presupuesto se contraponen a las
necesidades de los usuarios.
Desarrollo incremental de los
Requisitos del sistema.

9. Ingeniería de Requisitos
• Conjunto de actividades que llevan a la definición y especificación
de requisitos:
– estudio de factibilidad,
– análisis de requisitos,
• obtener los requisitos observando el sistema actual, discutiendo con usuarios,
• desarrollo de modelos y prototipos del sistema,
– definición de requisitos,
• traducción del producto del análisis a un documento,
• documento orientado a múltiples lectores,
– especificación de requisitos,
• descripción detallada del sistema,
• base del contrato entre cliente y desarrolladores,
• en paralelo con el diseño.

10. Ingeniería de Requisitos
Estudio de
Factibilidad
Análisis de
Requisitos
Definición de
Requisitos
Especificación
Requisitos
Reporte de
Factibilidad
Modelos
del Sistema
Documento
Requisitos
Definición de
Requisitos
Especificación
Requisitos

11. Documento de Requisitos
• SRS: Software Requirements Specification
– declaración oficial de lo que hará el software.
• Qué es los que el sistema debe hacer?, sin indicar
cómo?.
• Debe ser suficientemente específico como para
poder relacionar los requisitos con la funcionalidad
del sistema final.
Documento de
Requisitos
Definición de
Requisitos
Especificación de
Requisitos
= +

12. Características del Documento
• El documento debe ser
completo y consistente:
– todas las funciones
deben ser incluidas,
– no debe haber conflictos.
• Debe ser fácilmente
modificable:
– errores,
– evolución de los
requerimientos.
• Características necesarias:
– solamente comportamiento
externo,
– restricciones a la
implementación,
– fácilmente modificable,
– útil como referencia para los
encargados del
mantenimiento del sistema,
– registro de reflexiones
acerca de futura evolución,
– respuestas aceptable a
eventos inesperados.

13. Por Capítulos
• Introducción
– descripción general,
– funcionalidad e interacción
con otros sistemas,
– inserción en la empresa/
organización.
• Glosario
– definición de términos.
• Modelos del Sistema
– diagramas de relación del
sistema con el ambiente.
• Definición de Requisitos
Funcionales
– servicios del sistema,
– ID, descripción (+ diagramas),
prioridad (alta, baja, media).
• Definición de Requisitos No
Funcionales (performance,
usabilidad, portabilidad, etc)
– características del sistema,
– ID, descripción (+ diagramas),
prioridad (alta, baja, media).
• Restricciones (al proceso y al
producto)… IDEM
• Evolución del Sistema
– cambios que se anticipan.
• Especificación de Requisitos
– detalle de la funcionalidad:
• funciones, datos, dinámica.

14. Validación del Documento
• El documento de requisitos expresa lo que el cliente
realmente necesita.
• Los errores se propagan al diseño y la implementación.
• La corrección es más cara cuanto más tarde se detecte
el error.
– 100 veces más caro corregir un error en los requisitos después
de entregado el sistema, que corregir el documento de
requerimientos en la fase de análisis.
• La validación debe hacerse con el cliente/usuario a
medida que se construye el documento de requisitos
– revisiones y “caminatas”.

15. Cualidades del Documento
• Validez:
– la funcionalidad especificada es
aceptada por todos los
usuarios.
• Consistencia:
– no existen conflictos entre los
requisitos.
• Completo:
– todas las funciones y
restricciones están incluidas.
• Realismo:
– requisitos realizables,
– mejoras esperables realistas.
• Verificable:
– los requisitos pueden ser
verificados.
• Comprensible:
– claridad de expresión.
• Rastreable:
– origen de los requisitos
(evolución).
• Adaptable:
– los cambios no afectan el
sistema completo.

16. Evolución de Requisitos
• La comprensión del sistema avanza a medida
que se analiza la definición de requisitos.
• El tiempo de desarrollo de grandes sistemas
puede ser varios años.
– El ambiente cambia y afecta los requisitos iniciales.
• Clases de requisitos:
– duraderos: relativos a actividades esenciales;
– volátiles: requisitos temporales propensos a cambiar.

17. Requisitos Volátiles
• Mutables:
– cambios en el ambiente organizacional.
• Emergentes:
– la comprensión profunda del sistema trae a la luz nuevos (o
cambios en los) requisitos.
• Consecuencias:
– la implantación del sistema trae nuevos requisitos (por ej.
restricciones).
• Compatibilidad:
– cambios en otros sistemas con los que se interactúa una
aplicación, generan nuevos requisitos.

18. Actualización de Requisitos
Documento de
Requisitos 1
Implementación
del Sistema 1
Implementación
del Sistema 2
Cambio en los
Requisitos
Documento de
Requisitos 1
Implementación
del Sistema 1
Implementación
del Sistema 2
Documento de
Requisitos 2
Cambio en los
Requisitos

19. Conclusiones
• Los requisitos son la base del contrato y la base del
proceso de desarrollo de software
• Requisitos incompletos o ambiguos sólo generan
problemas
• Hay que validar los requisitos, ojalá a través de un
prototipo
• Si los requisitos no están claros, no puedo ir a
ningún lado (ando si rumbo).
• Los requisitos sirven para demostrarle al cliente que
hemos terminado el proyecto.
• Los requisitos sirven como herramienta de
negociación.