Requerimientos de Software: Definición, Tipos y Herramientas Esenciales

Requerimiento

1. Según la Real Academia Española, un requerimiento se define como la acción y efecto de requerir. 2. Condición o capacidad que necesita el usuario para lograr un objetivo o solucionar un problema. 3. Una condición o capacidad que debe tener el sistema para satisfacer un contrato, estándar, especificación de software u otro documento formal.

Requerimientos de Negocio

Estos requerimientos describen cómo sería mejorar el mundo para ciertas comunidades si el producto estuviera disponible. 2. Son aquellos requerimientos que representan los objetivos establecidos por la organización. 3. Reflejan las prácticas de negocio actuales de la organización.

Herramientas para el Desarrollo de Requerimientos de Negocio

Descomposición funcional o mapeo de procesos:

• Este tipo de vista es la representación desglosada de los procesos macro de la organización (mientras estos se puedan descomponer).
• La ventaja de este tipo de descomposición es que permite un mejor entendimiento de la empresa.

Cadena de responsabilidades: Es un patrón de diseño que establece una relación directa entre los responsables de los requerimientos del negocio y los actores externos que interactúan con los mismos.

Requerimientos de Usuario

Los usuarios son los individuos o grupos a quienes va dirigido el sistema. Son aquellas funcionalidades específicas que los usuarios esperan ver en la solución.

Declaraciones en lenguaje natural en diagramas: de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar.

• Definición de Requerimientos: Gerencia de Cliente, Usuarios Finales del Sistema.
• Requerimientos de Especificación: Usuarios Finales del Sistema, Ingenieros de Cliente, Arquitectos del Sistema, Desarrolladores de Software.
• Especificación de Software: Quizá Ingenieros de Clientes, Arquitectos del Sistema, Desarrolladores de Software.

Requerimientos Funcionales

Describen lo que el sistema o software debe hacer. Siempre se refieren a funciones específicas que debe realizar la solución. Dependen del tipo de software y del sistema que se desarrolle, así como de los posibles usuarios del software. Los requerimientos funcionales para el usuario son declaraciones de alto nivel, que los describen en forma general. Sin embargo, los requerimientos funcionales del sistema describen los servicios del sistema en detalle.

Requerimientos No Funcionales

Definen propiedades y restricciones del sistema. Expresan una acción que debe ser capaz de realizar el sistema. También incluyen restricciones físicas sobre los funcionales.

Ejemplos de Requerimientos No Funcionales:

• Usabilidad: factores humanos, ayuda, documentación.
• Confiabilidad: frecuencia de fallas, tiempo de recuperación.
• Performance: tiempo de respuesta, tasa de procesamiento, precisión, capacidad de carga.
• Soportabilidad: adaptabilidad, mantenibilidad, configurabilidad, internacionalización.

Clasificación de Requerimientos No Funcionales

• Requerimientos del Producto: especifican el comportamiento del producto, por ejemplo, rapidez de ejecución, fiabilidad, etc.
• Requerimientos Organizacionales: son consecuencia de las políticas y procedimientos de la organización, por ejemplo, estándares usados en los procesos, requerimientos de implementación, etc.
• Requerimientos Externos: son requerimientos que se originan por factores externos al sistema y a su proceso de desarrollo, por ejemplo, requerimientos legales, éticos, etc.

Para Qué Sirve un SRS

• Comunicar de manera precisa los requerimientos, objetivos y presunciones del dominio.
• Contrato: documento legal, interno o a modo de memorando.
• Base para estimación (tamaño, costo, tiempo) y planificación del proyecto.
• Base para evaluación del producto final: verificación y validación.
• Debería tener suficiente información para decidir si el producto final es aceptable (satisface los requerimientos).
• Base para el control de cambios: los requerimientos cambian, el software evoluciona, el entorno evoluciona.

Orientación Técnica de un SRS

• Clientes y Usuarios: interesados en validar objetivos del sistema y descripción de alto nivel de la funcionalidad. Generalmente no interesados en los requerimientos detallados del sistema.
• Analistas: escribirán especificaciones de otros sistemas que interactúan con este. El SRS sirve más allá de la puesta en producción.
• Desarrolladores: deben implementar los requerimientos.

Cualidades de un SRS

• Completitud
• Pertinencia
• Consistencia
• Medibilidad
• Precisión (no ambiguo)
• Factibilidad
• Entendibilidad
• Trazabilidad
• Buena estructura
• Modificabilidad

Contenido General de un SRS

• Funcionalidad: ¿Qué es lo que el software hace?
• Interfaces Externas: ¿Cómo debe interactuar con personas, con el hardware del sistema, con demás hardware y con demás software?
• Atributos de Calidad: disponibilidad, tiempo de respuesta, tiempo de recuperación después de fallas, etc.
• Consideraciones de Portabilidad: correctitud, precisión, mantenibilidad, seguridad y más.
• Restricciones de Diseño: existen estándares a cumplir, lenguaje de programación, recursos, sistemas operativos, etc.