Análisis de Requisitos de Software: Fundamentos y Principios

1. Introducción al Análisis

1.1 Generalidades

Fase fundamental en el ciclo de vida del software.

• Análisis: del sistema y de requisitos.
• Para analizar los requisitos, estos deben haberse obtenido previamente.
• Determinación de requisitos.
• Ingeniería de requisitos.

1.1 Definición de Análisis

Proceso de estudio de las necesidades de los usuarios para llegar a una definición de los requisitos del sistema (hardware o software), así como el proceso de estudio y refinamiento de dichos requisitos.

1.1 Ingeniería de Requisitos

Primera fase del ciclo de vida del software donde se produce una especificación a partir de ideas informales.

• Deben obtenerse y documentarse:
  • Los requisitos funcionales.
  • Los requisitos no funcionales.
  • Los criterios para medir el grado de su consecución.

El proceso de desarrollo de dicha especificación de requisitos se conoce como Ingeniería de Requisitos.

• Importancia creciente de:
  • El correcto entendimiento (obtención), documentación (especificación) y validación de las necesidades de los usuarios y clientes.
  • La medida de la calidad de los sistemas en función del grado de satisfacción de los usuarios.

1.3 Requisitos

Condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado. Aparente simplicidad del concepto. Es frecuente encontrar el término requisito calificado con adjetivos que pueden resultar confusos.

Ámbito

• Indica en qué contexto se debe entender el requisito:
  • El ámbito de sistema indica que el requisito debe cumplirse a nivel de sistema, entendiendo por sistema un conjunto de hardware y software.
  • Si el ámbito es de software, el requisito solo afecta a la parte software de un sistema.
  • Si el ámbito es de hardware, solo afecta a la parte hardware.

Característica que define un requisito

• Dimensión por la que los requisitos son clasificados en función de la naturaleza de la característica del sistema que se especifica:
  • La clasificación más habitual suele ser la de requisitos funcionales (qué funciones debe realizar el sistema) y no funcionales (otras características del sistema).
  • Esta clasificación a veces no resulta muy clara porque, en algunas ocasiones, un requisito puede ser catalogado en varias categorías a la vez.

Audiencia

• Dimensión que indica a quién va dirigido el requisito, es decir, las personas que deben ser capaces de entenderlo:
  • En general, se pueden distinguir dos tipos de audiencia: los clientes y usuarios (que no tienen que tener formación en Ingeniería del Software) y los desarrolladores de software.
  • En esta dimensión se suele utilizar la nomenclatura:
    • Requisitos orientados al cliente (requisitos-C): requisitos desde el punto de vista de los clientes y usuarios.
    • Requisitos orientados al desarrollador (requisitos-D): requisitos desde el punto de vista de los desarrolladores.

Representación

• Dimensión que se utiliza para establecer la forma en que se definen los requisitos:
  • Las categorías que habitualmente se manejan son: formal, semiformal o no formal.
  • Las representaciones formales presentan una semántica y una sintaxis rigurosas.
  • Las representaciones semiformales son modelos que facilitan el entendimiento entre los participantes.
  • Las representaciones no formales son expresiones en texto natural, vídeos, imágenes, voz y sonidos para restringir el sistema a construir.

1.4 Objetivo

Construir una especificación precisa de los requisitos del software que describa lo que el sistema debe hacer, pero sin entrar a detallar cómo debe llevarse a cabo.

• Especificación de Requisitos del Software (ERS):
  • Este documento debe incluir tanto los requisitos-C como los requisitos-D.
  • Sin embargo, hay metodologías que abogan por la separación de estas representaciones en dos documentos diferentes:
    • El DRS (Documento de Requisitos del Sistema), también denominado catálogo de requisitos, donde se recogen los requisitos-C.
    • La ERS propiamente dicha, que recoge los requisitos-D.
  • En la realización de una ERS participan:
    • Ingenieros del software (analistas).
    • Clientes y usuarios.

1.7 Los Principios del Análisis

• Se debe representar y comprender el ámbito de la información del problema.
• Se deben desarrollar los modelos que representen la información, el componente funcional y el comportamiento del sistema.
• Se deben subdividir los modelos de forma que se descubran los detalles de una manera progresiva o jerárquica.
• El proceso de análisis debe ir de la información esencial hacia el detalle de la implementación.

1.7.1 Representación de la Información

• Tres formas de representar la información:
  • Flujo de la información.
  • El contenido de la información.
  • La estructura de la información.

1.7.2 Construcción de Modelos

• Objetivo: combatir la complejidad.
• Centrados en qué hace el sistema.
• Representaciones gráficas con complemento de información textual.
• Tipos:
  • Lógicos.
  • Físicos.

1.7.2.1 ¿Por qué Modelar?

• En la vida real, se construyen muchas clases de modelos con distintos propósitos antes de construirlos.
• Objetivos de los modelos:
  • Probar una entidad física antes de construirla.
  • Comunicación con el cliente.
  • Visualización.
  • Reducción de la complejidad.
  • Estructurar las ideas.