Ingeniería de Requisitos

Propiedades de cada requisito

Técnicas de obtención de requisitos

• claro: en lenguaje preciso y simple
• conciso: describir una única propiedad
• consistente: no deben contradecirse
• no ambiguo: tener una única interpretación
• viable: realizable en un plazo y costo definido
• rastreable: durante todo el proceso
• verificable: criterio claro y comprobable
• cuantificable: medible
• priorizado

Definición de Requisito

Técnicas de obtención de requisitos

Pasivas: interacción poco frecuente con stakeholders

Activas: interacción continua entre las partes

SWEBOK v3.0 2014: propiedad que debe tener algo para resolver un problema de la vida real

Fin

• entrevistas
• juego de roles
• prototipos
• observación
• escenarios

• casos de uso
• análisis y modelado de procesos de negocio
• workflows
• cuestionarios
• checklists
• documentación
• viewpoints (de interesados)

IEEE Std. 610.12-1990: Condición o capacidad que debe ser alcanzada o poseer un sistema o componente del sistema para satisfacer un contrato, estándar, especificación u otros documentos formalmente impuestos

Propiedades del conjunto de requisitos

• realista
• completo
• correcto
• modificable
• rankeados por importancia

Proceso de la Ing. de Requisitos

Obtención

(elicitación)

Proceso dónde se obtiene de las partes interesadas, la información necesaria para desarrollar y documentar los requisitos

Que definen los requisitos ?

Validación

Análisis

Ayuda a asegurar que se están realizando los requisitos correctos. Validar que es lo que quiere el cliente.

Proceso dónde se clasifican y modelan los requisitos: modelar, clasificar, priorizar, negociar con el cliente

Beneficios de la ingeniería de requisitos

Lo que el sistema debe hacer y cuan bien debe desempeñarse.

linea base del doc.

de requisitos

• Proveer un documento base de qué es lo que debe hacer el producto de SW
• Reducir el esfuerzo requerido para producir el producto
• Proveer una base para estimar costo y cronograma
• Proveer linea base de capacidades a ser testeadas o bien verificados y validadas
• Facilitar la evolución, adaptación y migración futura de los elementos de SW

Especificación

Análisis de requisitos

Proceso de crear los documentos de especificación del software y del sistema; para ser utilizados en el diseño y mantenimiento del futuro software.

• Especificar las características funcionales y de capacidad del SW
• Establecer las interfaces
• Establecer criterios de calificación para las pruebas
• Proporcionar las especificaciones de seguridad

Clasificación

Priorización

Por fuente

relacionado a la trazabilidad, origen del requisito

Arquitectura de Software, diseño y asignación de requisitos

Por volatilidad: medida de cuanto puede cambiar un requisito

Esencial: el SW no será aceptable a menos que cumpla con estos requisitos

Condicional: tener estos requisitos daría un valor agregado al producto pero no lo harian inaceptable si no están presentes

Opcional: puede o no valer la pena contar con esta funcionalidad

• Durante el análisis de requisitos, es conveniente comenzar un diseño de alto nivel de la arquitectura
• Poner atención a los requisitos no funcionales
• Estar en permanente comunicación con el diseñador

• Mutable: cambia debido al entorno
• Emergente: la comprensión aumenta a lo largo del tiempo
• Consiguiente: cambios debido a nuevo HW o sistema
• Compatibilidad: debido a cambios de proceso

Por Tipo

• Funcional / no funcional
• Seguridad (relativo a los accidentes)
• Regulatorio
• Interfaz de Usuario

Modelado conceptual

Modelos dinámicos: describen el comportamiento del sistema

Negociación

• Diagramas de flujo de datos
• Diagramas de flujo de control
• Modelos de máquinas de estado
• Diagramas de rastreo de eventos

Modelos estáticos: describen la estructura del sistema

Mantener reuniones regulares para:

• Identificar los conflictos lo antes posible
• Abordar/poner fin a los conflictos de manera oportuna

Determinar que es viable dentro de las restricciones del proyecto

Establecer prioridades

Poder rastrear decisiones finales hasta el cliente

Gestión de Cambios de los requisitos

• Modelos de clases
• Personas o interacciones del usuario

Validación

El propósito de la validación es ayudar a asegurar que los requisitos realmente reflejan lo que el cliente espera.

• Los cambios son inevitables

Requisitos del sistema / software

• Es casi imposible reunir todos los requisitos al comienzo del proyecto

Revisión: comprobar que el documento no tiene errores, omisiones, conflictos o ambigüedades.

Prototipado: sumamente beneficioso en sistemas con mucha interacción con el usuario.

Validación de Modelos

Sistema: se enfocan en el sistema como un todo (pueden referirse al HW, SW, los procesos organizacionales u otros componentes del sistema)

Software: se derivan de los requisitos del sistema, solo se refieren al software, que debe hacer el SW dentro del sistema.

Gestión de Cambios

• Control del cambio
• Trazabilidad
• Control de versiones
• Seguimiento de estado

Documentos de Especificación

Del Sistema

Documentos de

Especificación

ConOps (Conceptual Operations): orientado al usuario, describe las características del sistema propuesto desde el punto de vista de los usuarios.

SysRS : Vehículo por el cual se comunican los requisitos del cliente al equipo técnico que diseñará y construirá el sistema para satisfacer los requisitos

Del Software

Especificación de Requisitos

SRS: Especificación de un producto, programa, o conjunto de programas de software particular, que desempeña ciertas funciones en un ambiente específico. (IEEE Std. 830-1998)

Ingeniería de Requisitos

Es la documentación de un conjunto de requisitos que es revisada y aprobada por el cliente y que proporciona orientación para las actividades de construcción del SW

Es la base para que clientes y contratistas / proveedores acuerden que hará y que no hará el producto.

Hay varios documentos propuesto por la IEEE, orientados al cliente o a desarrolladores; sobre el software o sobre el sistema.