Ing De Sfotware

El análisis de requisitos es el primer paso del desarrollo de todo sistema software y, por lo tanto, resulta de gran importancia, ya que asienta la base del resto de etapas. Existen muchas formas de especificar los requisitos software y depende del equipo de desarrollo el utilizar una u otra. En este post explicaré cómo hacerlo basándonos en el estándar IEEE 830-1998, puesto que es la forma que vengo utilizando desde hace tiempo y me parece completa y elegante. Adelanto que esta forma no sigue el estándar de forma totálmente rigurosa, sino que es una adaptación del mismo —recordemos que estamos hablando de un estándar de hace más de 10 años—.

Los requisitos se presentan en una lista ordenada, categorizada según su ámbito, así como la influencia y prioridad respecto al entorno de aplicación del proyecto:

Restricciones de diseño: requisitos que limitan el desarrollo al crear el producto. Se etiquetan como RD.x, siendo x el número del requisito.

Requisitos funcionales: conjunto de requisitos que reflejan la funcionalidad que debe prestar el sistema. Se etiquetan como RF.x, siendo x el número de requisito.

Requisitos de interfaz: conjunto de requisitos que definen las necesidades de la interacción del software con otros sistemas y usuarios. Se etiquetan como IN.x, siendo x el número de requisito.

Requisitos de calidad: exigencias en la calidad que se piden explícitamente para el producto. En esta categoría se engloban los requisitos de rendimiento, escalabilidad, accesibilidad, usabilidad, etc. Se etiquetan como CA.x, siendo x el número de requisito.

Requisitos de evolución: requisitos para el diseño del producto con el objetivo de facilitar la adaptación a exigencias o condiciones que puedan surgir en el futuro. Se etiquetan como EV.x, siendo x el número de requisito.

Requisitos del proyecto: requisitos que afectan y condicionan el proceso de desarrollo del proyecto. Se etiquetan como PR.x, siendo x el número de requisito.

Requisitos de soporte: requisitos que deben ser cumplidos por el cliente (a diferencia de los anteriores). Se etiquetan como SO.x, siendo x el número de requisito.

Dentro de la clasificación anterior, cada requisito debe especificarse formalmente, empleando para ello la siguiente plantilla:

Descripción: descripción corta del requisito, que se concreta en los siguientes apartados.

Importancia: pudiendo ser de una de estas tres clases: esencial (cuyo no cumplimiento provocaría el fracaso inmediato del proyecto), condicional (el requisito mejoraría el resultado final del desarrollo), opcional (el requisito no tiene que ser implementado, pero se puede tener en cuenta al realizar el diseño del producto).

...