Ingeniería de Requisitos: Guía completa para el desarrollo de software

Ingeniería de Requisitos

Análisis de Requerimientos

El proceso de descubrir, analizar, documentar y verificar los servicios necesarios para un sistema y sus limitaciones operativas.

¿Qué es un requisito?

Puede variar desde una declaración abstracta de alto nivel de un servicio o una restricción del sistema hasta una especificación matemática.

Tipos de Requisitos

• Requisitos Funcionales: Describen los servicios o funcionalidades del sistema. Dependerán del tipo de software, los usuarios previstos y el tipo de sistema que utiliza el software. Pueden ser declaraciones de alto nivel. Los requisitos funcionales del sistema deben describir los servicios del sistema en detalle.
  • Ejemplo: El usuario debe ser capaz de buscar en el conjunto inicial de la base de datos o seleccionar un subconjunto de ella. El sistema deberá proporcionar visores adecuados para que el usuario lea documentos en el repositorio de documentos.
• Requisitos No Funcionales: Definen las propiedades del sistema y las restricciones de fiabilidad, por ejemplo, el tiempo de respuesta y los requisitos de almacenamiento. Restricciones a la capacidad de los dispositivos de E/S, representaciones del sistema, etc. Pueden ser más críticos que los requisitos funcionales.
  • Ejemplo: Requisitos del producto, requisitos de la organización, requisitos externos.
  • Requisitos del producto: Especifican que el producto entregado debe comportarse de una manera particular, por ejemplo, velocidad de ejecución, confiabilidad, etc.
  • Requisitos de la organización: Consecuencia de las políticas y procedimientos de la organización, por ejemplo, normas de proceso utilizadas, requisitos de implementación, etc.
  • Requisitos externos: Factores externos al sistema y su proceso de desarrollo, por ejemplo, requisitos de interoperabilidad, requisitos legales, etc.
• Requisitos de Dominio: Derivados del dominio de aplicación y describen las características del sistema que reflejan el dominio. Pueden restringir los requisitos funcionales existentes o definir cálculos específicos que deben llevarse a cabo. Si no se cumplen los requisitos de dominio, el sistema puede no funcionar.
  • Problemas de los requisitos de dominio:
    • Facilidad de comprensión: Los requisitos se expresan en el lenguaje del dominio de la aplicación, que a menudo no es comprendido por los ingenieros de desarrollo de software del sistema.
    • Implícitos: Los expertos conocen el área tan bien que no piensan en hacer explícitos los requisitos del dominio.
• Solicitudes de los usuarios: Declaraciones en lenguaje natural más diagramas de los servicios que proporciona el sistema y sus limitaciones operacionales. Escrito para los usuarios.
• Requisitos del sistema: Un documento estructurado que establece una descripción detallada de las funciones, servicios y limitaciones operativas del sistema. Define lo que debe implementarse y puede ser parte de un contrato entre el cliente y el desarrollador.

El sistema LIBSYS

Un sistema de biblioteca que proporciona una única interfaz para una serie de elementos de bases de datos de diferentes bibliotecas.

• Solicitudes de los usuarios: Administradores de clientes, usuarios finales, ingenieros de sistemas, clientes, gerentes de proveedores, arquitectos de sistemas.
• Requisitos del sistema: Usuarios finales del sistema, clientes, ingenieros, arquitectos de sistemas, desarrollo.

Documentos de Especificación de Requisitos

Debe estar compuesto por frases en lenguaje natural, siguiendo ciertas normas:

1. Usar "deberá" para requisitos obligatorios y "debería" para requisitos deseables. Ejemplo: "El sistema deberá funcionar en la línea de PC de IBM de equipos que tengan un microprocesador 486 DX o superior."
2. Los requisitos deben estar organizados de forma lógica.
3. Cada requisito debe tener un identificador único, por ejemplo, un identificador numérico para su posterior consulta.
4. Los requisitos de software se deben dividir en requisitos funcionales y no funcionales.
5. Evitar el uso de jerga informática.

Formato de Especificación de Requisitos

IEEE/ANSI 830/1998. (Introducción > Descripción > Requisitos específicos > Anexos > Índice)

Problemas con la Especificación en Lenguaje Natural

• Ambigüedad: Lectores y escritores del requisito pueden interpretar las mismas palabras de diferentes maneras. El lenguaje natural es inherentemente ambiguo, por lo tanto, muy difícil de interpretar.
• Excesiva flexibilidad: Lo mismo puede decirse de varias formas diferentes en la especificación.
• Falta de modularización: Las estructuras del lenguaje natural no son adecuadas para la estructura de los requisitos del sistema.

Ingeniería de Requisitos: Fases

Cuatro fases: Estudio de viabilidad, obtención y análisis de requisitos, validación de requisitos, gestión de requisitos.

Estudio de Viabilidad

Decide si vale la pena o no dedicar tiempo y esfuerzo al sistema propuesto. Se trata de un estudio a corto plazo centrado en comprobar si el sistema contribuye a los objetivos de la organización; si el sistema puede implementarse con la tecnología actual y dentro del presupuesto; y si el sistema puede integrarse con los demás.

Obtención y Análisis de Requisitos

Recopilar información sobre el sistema propuesto y las fuentes existentes: documentos, la organización, especificaciones existentes, observaciones, entrevistas, etc.

Validación de Requisitos

Se dedica a demostrar que los requisitos definen el sistema que el cliente realmente quiere. El coste de los errores en los requisitos es alto y, por lo tanto, la validación es muy importante.

• Comprobar la validez: ¿El sistema proporciona las funciones que mejor soportan las necesidades del cliente?
• Comprobación de la coherencia: ¿Existen requisitos contradictorios?
• Comprobación de la integridad: ¿Se incluyen todas las funciones requeridas por el cliente?
• Comprobación del realismo: ¿Se pueden implementar los requisitos con el presupuesto y la tecnología disponibles?
• Facilidad de control: ¿Se pueden revisar los requisitos?

Dificultades

• Las partes interesadas no saben lo que quieren del sistema o no expresan lo que quieren con claridad.
• Los actores expresan sus necesidades utilizando sus propios términos.
• Las diferentes partes interesadas tienen diferentes requisitos.
• Los factores políticos pueden influir.
• Entorno dinámico en constante evolución.

Gestión de Requisitos

Es el proceso de gestión de los nuevos requisitos en la ingeniería de requisitos y el desarrollo del sistema. Los requisitos son, inevitablemente, incompletos e inconsistentes.

Trazabilidad

Está relacionada con las relaciones entre los requisitos, sus fuentes y el diseño del sistema.

• Trazabilidad de la fuente: Enlaces de los requisitos a las partes interesadas que propusieron esos requisitos.
• Trazabilidad de los requisitos: Enlaces entre los requisitos y su dependencia.
• Trazabilidad del diseño: Enlaces de los requisitos a los módulos del diseño.