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

• Propiedades y comportamientos de nuestro sistema
• Restricciones de diseño y de producto
• Propiedades emergentes del sistema

que No debe incluir

• Información referente al proyecto
• Diseño
• Planes de garantía del producto
• Costes

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
  • Lo más usado
• Solo técnicas
  • No recomendables

El documento de requisitos es la forma que tenemos de formar y guardar los requisitos.

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

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

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.

• No puede haber ambigüedad
  • Un requisito ambigüo se presta a distintas interpretaciones
• 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
  • Todos los requisitos deben satisfacer lo que el cliente quiere
• Verificable
  • Se tiene que comprobar que el requisito se pueda hacer
• Consistencia
  • Los requisitos no pueden entrar en conflicto con otros.
• Realizables
  • Que se puedan implementar
• Concisos
  • Deben ser breves
• Independiente del diseño
• Trazable
  • Se deben poder referenciar por numeración
• 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

1. Introducción
   1. Proposición
   2. Ámbito
   3. Definiciones, Acrónimos, Abreviaturas
   4. Referencias
   5. Visión general del resto del documento
2. Descripción General
   1. Perspectiva del producto
   2. Funciones del producto
   3. Características del usuario
   4. Restricciones generales
   5. Asunciones y Dependencias
3. Requisitos específicos: Todos los requisitos que tenemos clasificados con identificador único, referencia, entrada y salida.
   1. Interfaces externas
      1. Descripción detallada de entradas y salidas
      2. Complementa descripciones de interfaz
   2. Funciones
   3. Requisitos de rendimiento/ejecución
   4. Restricciones de diseño
   5. Atributos de calidad del software
   6. Otros 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

1. preparamos plan de revisión
2. Distribuimos los documentos a revisar
3. Preparación de la reunión
4. Realizar la reunión de revisión
5. Identificar defectos y acciones a realizar
6. Realizar correcciones que sean precisas

• Checklist de validación: cada organización tiene uno diferente.
• Pre-Revisiones: antes de la revisión se realizan reuniones pequeñas para ver que errores hay.
• Prototipado
  • Usado en diversas disciplinas
  • Se usa para ver y comprobar que los requisitos que tenemos son correctos
  • Tipos de prototipos:
    • Mock-Ups: Pantallas dibujadas a mano que representa un aspecto en concreto del sistema. Suele ser dibujado en papel
    • StoryBoard: Evolución del MockUp, suelen estar hechos a ordenador, muestra la secuencia de acciones o escenarios que se deben realizar con el programa.
    • Maquetas: versiones simplificadas de nuestra aplicación. Simula realizar las acciones del programa.
  • Prototipos comunes en Ingeniería de Requisitos:
    • Seleccionamos quien evaluara el prototipo
    • Desarrollar escenarios de validacón
    • Ejecutar Escenarios
    • Documentar problemas

• Generación de casos de prueba: Un caso de prueba describe una acción que el cliente quiere que realice el software.
• Manuales de usuario
• Animación y validación de modelos o especificaciones formales