Análisis y Especificación de Requisitos

Ing. Noretsys Rodríguez

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.

Necesidadesdel Cliente

Documentode

Requisitos

Ingeniería deRequisitos

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.

Requisito

• Definición abstracta de lo que el sistema debe hacer

• Definición matemática y formal de las funciones del sistema

Abs

tracc

ión

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.

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.

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.

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 losRequisitos del sistema.

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.

Ingeniería de RequisitosEstudio de

FactibilidadAnálisis deRequisitos

Definición deRequisitos

EspecificaciónRequisitos

Reporte deFactibilidad Modelos

del Sistema

DocumentoRequisitos

Definición deRequisitos

EspecificaciónRequisitos

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 deRequisitos

Definición deRequisitos

Especificación deRequisitos

= +

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.

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.

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”.

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.

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.

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.

Actualización de RequisitosDocumento deRequisitos 1

Implementacióndel Sistema 1

Implementacióndel Sistema 2

Cambio en losRequisitos

Documento deRequisitos 1

Implementacióndel Sistema 1

Implementacióndel Sistema 2

Documento deRequisitos 2

Cambio en losRequisitos

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.