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:

• 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

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 ambos es el nivel de detalle (EXAMEN), uno está más detallado que otro.