Especificación de requisitos
Los documentos de requisitos son diferentes en función a si son para clientes técnicos o clientes no conocedores.
El documento de requisitos tiene los siguientes requisitos:
Comunicación entre clientes, usuario y desarrolladores
Permitir iniciar la actividad de diseño
Soportar las actividades de pruebas del sistema
Controlar la evolución del sistema
Contenido
Propiedades y comportamientos de nuestro sistema
Restricciones de diseño y de producto
Propiedades emergentes del sistema
que No debe incluir
Como se deben escribir los requisitos
Se usan frases como Mi sistema tiene que, “El sistema debe”, “El sistema Hará”, “el sistema Habilitará”
Debe utilizarse lenguaje natural, este se puede complementar de diagramas y notaciones formales.
El cliente debe participar en el documento
Los requisitos se deben poner en positivo, salvo excepciones, como sistemas críticos en donde indicaremos que NO hará el sistema
Solo texto
Texto y técnicas
Solo técnicas
El documento de requisitos es la forma que tenemos de formar y guardar los requisitos.
Documentación Requisitos Usuario (DRU)
Plasmamos el problema que tiene el usuario. Definimos el problema en un proceso iterativo donde el usuario es el máximo responsable
Objetivo: Obtener definiciones de lo que el usuario espera del sistema
Entradas: Resultados de entrevistas, encuestas, estudios, ejercicios de prototipado
Salidas: Documento de requerimientos de usuario DRU, donde se describen todos los requerimientos con claridad y consistencia
Actividades
Especificar los requisitos del usuario
Describir los requisitos en términos de sus atributos
Organizar los requisitos en base a la categoría que pertenezcan
Revisar y comprobar las salidas de la fase
Atributros de los requisitos de usuario
Identificador: número necesidad: Como de necesario es
prioridad:Que prioridad tiene, alta, media o baja
estabilidad: Si es muy probable que cambien o no (Alta o baja), por ejemplo una función que depende de una ley tiene estabilidad baja al haber riesgo de que cambien las leyes
fuente: Quien ha dicho el requisito
claridad: Como de claro está
verificabilidad: Todos los requisitos deben poder realizarse
Documento de requisitos del software (ERS)
Fase de análisis del problema donde se adopta un método
Actividades
Especificar los requisitos del software
Describir los requisitos eb tñernminos de sus atributos, asegurando la completitud y consistencia
Organizar los requisitos en base a la categoría a la qu pertenezcan
Revisar y comprobar salidas de la fase
Atributos del documento de requisitos del software (ERS):
Identificador: número necesidad: Como de necesario es
prioridad:Que prioridad tiene, alta, media o baja
estabilidad: Si es muy probable que cambien o no (Alta o baja), por ejemplo una función que depende de una ley tiene estabilidad baja al haber riesgo de que cambien las leyes
fuente: Quien ha dicho el requisito
claridad: Como de claro está
verificabilidad: Todos los requisitos deben poder realizarse
Lectores/usuarios de la ERS
Clientes: para comprobar que satisface sus necesidades y para hacer cambios en los requisitos
gestores: Para preparar una oferta por el sistema y planificar el proceso de desarrollo
ingenieros de desarrollo: Para comprender el sistema a desarrollar
ingenieros de pruebas: Para elaborar pruebas de validación
ingenieros de mantenimiento: Para facilitar la comprensión del sistema y las relaciones entre sus partes
Diferencia entre ERS y DRU
El DRU esta en lenguaje más natural e incluye tal cual el problema a resolver, el ERS contiene los requisitos y como se va a solucionar el problema.
La diferencia entre ERS y DRU es que uno está más detallado de otro
La diferencia entre ambos es el nivel de detalle (EXAMEN), uno está más detallado que otro.
Características de una buena ERS (IEE-830)
No puede haber ambigüedad
Completa
No puede haber secciones To Be Determined (TBD)
Se describen todas las posibles respuestas a todas las posibles entradas
Páginas numeradas, figuras y tablas con referencias. El documento debe tener formato estandarizado
Correcto
Verificable
Consistencia
Realizables
Concisos
Independiente del diseño
Trazable
Modificable
Electrónicamente almacenado
Ejecutable/interpretable/Prototipable
Anotada por importancia relativa
Anotada por estabilidad relativa
Anotada por versión
No redundante
A un nivel de detalle adecuado
Precisa
Reutilizable
Trazada
Organizada
Con referencias Cruzadas
Estructura del Documento de Requisitos
Introducción
Proposición
Ámbito
Definiciones, Acrónimos, Abreviaturas
Referencias
Visión general del resto del documento
Descripción General
Perspectiva del producto
Funciones del producto
Características del usuario
Restricciones generales
Asunciones y Dependencias
Requisitos específicos: Todos los requisitos que tenemos clasificados con identificador único, referencia, entrada y salida.
Interfaces externas
Descripción detallada de entradas y salidas
Complementa descripciones de interfaz
Funciones
Requisitos de rendimiento/ejecución
Restricciones de diseño
Atributos de calidad del software
Otros Requisitos
Problemas que podemos tener en el documento de requisitos
Puede haber demasiados requisitos, de forma que los cambios se vuelven demasiado difíciles
Hay herramientas llamadas CARE que nos permiten gestionar una gran cantidad de requisitos
No consideración de requisitos obvios
Nivel de detalle: Tiene que haber un nivel de detalle adecuado para el cliente
Ubicación de los requisitos: Poner los requisitos donde corresponden
Etapas de la revisión
preparamos plan de revisión
Distribuimos los documentos a revisar
Preparación de la reunión
Realizar la reunión de revisión
Identificar defectos y acciones a realizar
Realizar correcciones que sean precisas
Herramientas para Revisiones
técnicas de validación