Los casos de uso describen un conjunto de secuencias de acciones, incluyendo variantes que ejecuta el sistema para producir un resultado observable de valor para un actor. Se utiliza durante la captura de requisitos y el análisis de requisitos para visualizar, especificar, construir y documentar el comportamiento esperado del sistema. OJO: Describe que hace el sistema, pero no como lo hace

Es una condición o capacidad que un sistema debe poseer o cumplir para satisfacer un estándar, especificación u otros documentos. También pueden ser descritos como una representación documentada de capacidades o condiciones que debe cumplir el sistema.

• Ingeniería de requisitos: Comprende las actividades de desarrollo de software de gestión y definición de requisitos para un sistema.
• Especificación de Requisitos del Software (ERS): Documento formal de los requisitos del sistema

• Ser correctos
• Ser consistentes
• Estar completos
• Ser realistas
• Ser verificables
• Ser rastreables

Se deben evitar requisitos que no reflejen las necesidades reales del cliente, así como los que no sean consistentes o sean ambiguos. También se debe evitar realizar cambios a estos una vez han sido acordados.

Es un conjunto de preguntas que el analista debe considerar para cada requisito individual. Estas preguntas están relacionadas con atributos de calidad. El problema de los checklist es que es imposible detectar defectos en los requisitos con estas.

Se utilizan como herramienta para clarificar requisitos poco claros o para validarlos. Hay varios tipos de prototipado:

Comienza con partes del sistema que no se comprende del todo con el objetivo de obtener requisitos más precisos. Una vez se ha terminado con el prototipo, este se desecha.

Es útil cuando los requisitos están bien establecidos. A diferencia del prototipado rápido, aquí no se desecha el prototipo al final, se reutiliza ya sea modificándolo o como producto final. Es bastante útil en sistemas Orientados a objetos ya que permite el reúso de un paso al siguiente o de un proyecto a otro. Este tipo de prototipado es fácil de cambiar durante el desarrollo, haciendo que sea más probable alcanzar el sistema que los usuarios desean.

Se trata de una combinación del prototipado rápido y el operacional. Solo se implementan los requisitos que están claros usando técnicas de desarrollo de prototipado evolutivo a partir de los requisitos iniciales. Un técnico que actúa de prototipador visita los puestos de los usuarios y crea prototipos rápidos con las características que el usuario desea. Si alguno de estos prototipos rápidos no sirve se desecha, pero en caso de que sea correcto, se desinstala del puesto y se notifica al departamento de desarrollo la inclusión de los requisitos implementados en dicho prototipo.

También conocido como selección de requisitos, el triage consiste en seleccionar los requisitos cuidadosamente con el objetivo de maximizar los beneficios antes de decidir que requisitos se implementarán. Se suele tener en cuenta:

• La influencia de los requisitos en el producto final
• Gastos e ingresos
• Aspectos técnico-sociales

• Escalabilidad: evalúa la resistencia de los requisitos al cambio
  • Estables: Son aquellos relacionados con la esencia del sistema y el dominio
  • Volátiles: depende de las modas o necesidades:
    • Mutables: Cambios en el entorno del sistema
    • Emergentes: Aparecen con el uso del sistema
    • Consecuentes: Producidos por suposiciones erróneas
    • Compatibles: La compatibilidad del sistema cambia con los requisitos
• Propiedades a considerar:
  • Importancia: Evalúa el impacto que los requisitos ejercen en el entorno de inversión
    • Objetiva o subjetiva
    • No pueden obtenerse de los usuarios, es necesario algún tipo de acción específica para su anotación
  • Adecuadas referencias cruzadas
    • Permiten identificar los requisitos que deben implementarse conjuntamente
    • Si dos requisitos están relacionados la implementación de uno afecta al otro

La selección de requisitos implica cuantificar todas las variables, se suelen utilizar valores monetarios para ayudar al cliente a ser consciente del coste, aunque se puede también cuantificar en tiempo.

• evaluación de gastos
• Evaluación de ingresos
  • Contrato fijo, desarrollo interno o ingresos intangibles
  • Debe ser el analista el que idee un método de cuantificación que permita la comparación de productos alternativos

Es el proceso que permite relacionar los requisitos con otros productos del proceso de desarrollo, así como los requisitos entre sí. La especificación de estos debe ser:

• Trazada: cada requisito debe estar relacionado con su origen
  • Trazabilidad hacia atrás: Anotar cada requisito con su origen (Documento o cliente)
• Trazable: Cada requisito debe estar relacionado con los productos subsiguientes
  • Trazabilidad hacia delante: Compleja ya que puede dar lugar a múltiples productos
• Con referencias cruzadas: Cada requisito debe poder relacionarse con otros requisitos
  • Trazabilidad interna: Anotación de cada requisito donde se indicaría los requisitos relacionados (Herramientas CASE)

En la trazabilidad también se pueden utilizar matrices de estabilidad como buena práctica para llevar a cabo la actividad de forma eficiente. Es importante conocer los aspectos de los requisitos como su origen, necesidad, relación con otros requisitos y relación con otros elementos.