¿Qué es una especificación de requisitos de software? Estructura y Características del SRS.

El resultado de la fase de requisitos del proceso de desarrollo de software es la Especificación de requisitos de software (SRS) (también conocido como documentación de necesidades).

Este documento sienta las bases para las actividades de ingeniería de software y se crea cuando se derivan y analizan los requisitos generales.

El SRS es un documento formal que actúa como una representación del software, lo que permite a los usuarios revisar si (el SRS) cumple con sus requisitos. Además, incluye los requisitos del usuario para el sistema y una especificación detallada de los requisitos del sistema.

IEEE Define una especificación de requisitos de software como "un documento que describe de forma clara y precisa cada requisito básico (función, rendimiento, restricciones de diseño y atributos de calidad) del software y las interfaces externas". Cada requisito se define de tal manera que su cumplimiento puede verificarse objetivamente mediante métodos prescritos, como inspección, demostración, análisis o ensayo.

Tenga en cuenta que las especificaciones de requisitos pueden tomar la forma de documentos escritos, modelos matemáticos, colecciones de modelos gráficos, prototipos, etc. Esencialmente, lo que se pasa de la actividad de análisis de requisitos a la actividad de especificación es el conocimiento adquirido sobre el sistema.

La necesidad de mantener la documentación de requisitos es que las actividades de modelado se centran principalmente en la estructura del problema en lugar de su comportamiento estructural.

En SRS, sin embargo, las restricciones de rendimiento, las restricciones de diseño y la recuperación del cumplimiento de los estándares están claramente especificadas. Esta información ayuda a desarrollar un diseño de sistema correcto.

A continuación se enumeran varios otros propósitos para los que sirve SRS:

1. Comentario: Proporcionar retroalimentación para asegurar que los usuarios (la organización que desarrolla el software) comprendan los problemas o problemas a resolver y el comportamiento del software requerido para resolverlos.
2. Problema descompuesto en componentes: Organizar la información y desglosar el problema en sus componentes de manera ordenada.
3. Verificar: Utilizar la estrategia de validación aplicable a los requisitos para confirmar que los requisitos se han establecido correctamente.
4. Entrada de diseño: Incluir suficientes detalles en los requisitos del sistema funcional para diseñar una solución de diseño.
5. Acuerdo entre usuarios y organización: Proporcionar una descripción completa de la función que debe realizar el sistema. Además, ayuda a los usuarios a determinar si se cumplen los requisitos especificados.
6. Menos esfuerzo de desarrollo: Permitir a los desarrolladores considerar las necesidades de los usuarios antes de que comience el diseño del sistema. Como resultado, se pueden reducir la "reelaboración" y las inconsistencias de etapas posteriores.
7. Estimar costo y horario: Determinar los requisitos del sistema, lo que permite a los desarrolladores tener una estimación "aproximada" del costo total y el cronograma del proyecto.

SRS es utilizado por varias personas en una organización. Los clientes del sistema necesitan un SRS para especificar y verificar que los requisitos cumplan con los requisitos esperados. Además, SRS permite a los administradores planificar el proceso de desarrollo del sistema.

Un ingeniero de sistemas necesita un documento de requisitos para comprender qué sistema desarrollar. Estos ingenieros también necesitan esta documentación para desarrollar pruebas de verificación para el sistema deseado.

Finalmente, los ingenieros de mantenimiento de sistemas necesitan documentos de requisitos para trabajar con los requisitos y las relaciones entre sus partes. Los documentos de requisitos tienen diferentes usuarios. Por lo tanto, al comunicar los requisitos a los usuarios, también debe definir los requisitos con detalles precisos para los desarrolladores y evaluadores.

Además, también debe incluir información sobre posibles cambios en el sistema, lo que puede ayudar al diseñador del sistema a evitar tomar decisiones restrictivas sobre el diseño. SRS también ayuda a los ingenieros de mantenimiento a adaptar el sistema a los nuevos requisitos.

Características de SRS

La especificación de requisitos de software debe ser precisa, completa, eficiente y de alta calidad, para no afectar todo el plan del proyecto.

Cuando los desarrolladores y usuarios entienden fácilmente la documentación preparada, se puede decir que el SRS es de alta calidad. Otras características de SRS se analizan a continuación.

1. Correcto: SRS es correcto cuando todos los requisitos del usuario se establecen en un documento de requisitos. Los requisitos especificados se basarán en el sistema deseado. Esto significa verificar cada requisito para asegurarse de que (SRS) represente las necesidades del usuario. Tenga en cuenta que no existen herramientas o procedimientos específicos para garantizar la corrección del SRS. La corrección asegura la correcta ejecución de todos los requisitos especificados.
2. Claro: Un SRS no es ambiguo cuando solo hay una interpretación de cada requisito establecido. Esto significa que cada solicitud se interpreta de forma única.

Si un término tiene varios significados, el documento de requisitos debe especificar el significado en el SRS para que quede claro.

Finalizar: Un SRS está completo cuando los requisitos definen claramente lo que debe hacer el software. Esto incluye todos los requisitos relacionados con el rendimiento, el diseño y la funcionalidad.

Ordenar por importancia/estabilidad: No todos los requisitos son igualmente importantes, así que identifique cada requisito para diferenciarlo de los demás. Para ello, cada requisito debe estar claramente identificado. La estabilidad implica la posibilidad de cambios futuros en la demanda.

Modificable: Los requisitos del usuario pueden cambiar, por lo que los documentos de requisitos deben crearse de tal manera que estos cambios puedan modificarse fácilmente, manteniendo la estructura y el estilo del SRS.

Trazable: SRS es rastreable, es decir, la fuente de cada requisito es clara, lo cual es conveniente para futuras referencias a cada requisito. Para esto, se utilizan el seguimiento hacia adelante y el seguimiento hacia atrás. El rastreo hacia adelante significa que cada requisito debe ser rastreable hasta los elementos de diseño y código. Retroceder significa definir cada requisito citando explícitamente su fuente.

Verificable: Un SRS es verificable cuando los requisitos especificados pueden verificarse mediante un proceso rentable para verificar que el software final cumpla con esos requisitos. Estas afirmaciones se verifican con la ayuda de los comentarios.

Tenga en cuenta que la claridad es esencial para la verificabilidad.

Por unanimidad: Un SRS es coherente cuando los subconjuntos de requisitos definidos no entran en conflicto entre sí. Por ejemplo, puede haber situaciones en las que diferentes requisitos pueden usar diferentes términos para referirse al mismo objeto. Puede haber un conflicto lógico o temporal entre un requisito especificado y un requisito para el que no se cumple alguna característica lógica o temporal. Por ejemplo, un requisito establece que el evento "a" ocurre antes que otro evento "b". Pero otro conjunto de requisitos establece (ya sea directa o indirectamente a través de la transitividad) que el evento "b" debe ocurrir antes que el evento "a".

Estructura del SRS

Los documentos de requisitos están diseñados de tal manera que son más fáciles de escribir, revisar y mantener. Está organizado en partes independientes, y cada parte está organizada en módulos o unidades. Tenga en cuenta que el nivel de detalle a incluir en el SRS depende del tipo de sistema que se esté desarrollando y del modelo de proceso elegido para su desarrollo. Por ejemplo, si el sistema está siendo desarrollado por un contratista externo, las especificaciones clave del sistema deben ser precisas y detalladas.

Asimismo, los documentos de requisitos pueden ser menos detallados cuando se requiere flexibilidad en los requisitos y se desarrollan internamente. Dado que el documento de requisitos es la base para las etapas posteriores de desarrollo de software, es importante desarrollar el documento de manera prescrita. Por esta razón, se siguen ciertas pautas al preparar el SRS. Estas pautas se enumeran a continuación.

1. Función: Debe estar separado de la implementación.
2. Modelo de análisis: Debe desarrollarse de acuerdo con el comportamiento deseado del sistema. Esto debe incluir los datos del sistema y las respuestas funcionales a las diversas entradas que se le proporcionan.
3. Modelo cognitivo: Debe desarrollarse independientemente de los modelos de diseño o implementación. El modelo expresa el sistema tal como lo percibe el usuario.
4. Contenido y estructura normativa: Debe ser lo suficientemente flexible para adaptarse a los cambios.
5. Especificación: Debe ser sólido. Es decir, debe tolerar lo incompleto y la complejidad.

La información a incluir en el SRS depende de muchos factores, como el tipo de software que se está desarrollando y los métodos utilizados en su desarrollo.

Si el software se desarrolla usando un proceso de desarrollo iterativo, la documentación de requisitos será menos detallada que para el software desarrollado para sistemas críticos. Esto se debe a que las especificaciones de estos sistemas deben ser muy detalladas y precisas.

Se han propuesto una serie de normas para desarrollar documentos de requisitos. Sin embargo, los estándares más utilizados son desarrollados por el IEEE, que sirve como marco común. Este marco general se puede personalizar y ajustar para satisfacer las necesidades de organizaciones específicas.

Cada SRS se ajusta a un esquema específico, por lo que es necesario estandarizar la estructura del documento de requisitos para que sea más fácil de entender. Debido a que este estándar IEEE se usa para que SRS organice los requisitos de diferentes proyectos, proporciona diferentes formas de construir SRS.

Tenga en cuenta que las dos primeras secciones son iguales en todos los documentos de requisitos.

Este documento consta de las siguientes secciones.

1. Introducción: Esto proporciona una descripción general de toda la información descrita en el SRS. Esto se refiere al propósito y alcance del SRS, que especifica las funciones que debe realizar el sistema. Además, describe las definiciones, abreviaturas y siglas utilizadas. Las referencias utilizadas en el SRS proporcionan una lista de documentos a los que se hace referencia en el documento.
2. Descripción general: Determina los factores que afectan a los requisitos del sistema. Describe brevemente los requisitos definidos en la siguiente sección denominada "Requisitos Específicos". Incluye las siguientes subsecciones.
3. Perspectiva del producto: Decida si el producto es un producto independiente o parte de un producto más grande. Determina la interfaz con el hardware, el software, el sistema y la comunicación.

También se define el usuario, la memoria, las limitaciones y las operaciones.

Características del producto: Este proporciona un resumen de la función que debe realizar el software. Las funciones se organizan en una lista para facilitar la comprensión del usuario.

Características del usuario: Estas determinan las características generales del usuario.

Restricciones: Esta proporciona una descripción general de las restricciones, como políticas regulatorias, funciones de auditoría, requisitos de confiabilidad, etc.

Suposiciones y dependencias: Esta proporciona una lista de suposiciones y factores que afectan los requisitos establecidos en este documento.

Asignación de la demanda: Esta identifica los requisitos que se pueden aplazar a versiones futuras del sistema.

Requisitos específicos: Estos identifican todos los requisitos en detalle para que el diseñador pueda diseñar el sistema de acuerdo con estos requisitos. Estos requisitos incluyen una descripción de cada entrada y salida del sistema y las funciones realizadas en respuesta a las entradas proporcionadas. Incluye las siguientes subsecciones.

Interfaz externa: Esta determina la interfaz del software con otros sistemas, que pueden incluir el sistema operativo, la interfaz, etc. Las interfaces externas también especifican la interacción del software con el usuario, el hardware u otro software. Las características de cada interfaz de usuario de un producto de software se especifican en el SRS. Para las interfaces de hardware, el SRS especifica las características lógicas de cada interfaz entre los componentes de software y hardware. Si el software se va a ejecutar en hardware existente, se deben especificar funciones como los límites de memoria.

Función: Esta determina la capacidad funcional del sistema. Para cada requisito funcional, se especifica aceptar y procesar entradas para generar salidas.

Esto incluye comprobaciones de validación de entradas, secuencia exacta de operaciones, relación entre entradas y salidas, etc.

Requisitos de desempeño: Determina las restricciones de rendimiento del sistema de software. Hay dos tipos de requisitos de desempeño: requisitos estáticos y requisitos dinámicos. Demanda estática (también conocido como requisitos de capacidad) No se imponen restricciones a las características de rendimiento del sistema. Estos incluyen la cantidad de puntos finales y usuarios necesarios para ser compatibles. Demanda dinámica Determina las restricciones impuestas al comportamiento del sistema, incluido el tiempo de respuesta (el tiempo entre el inicio y el final de una operación en condiciones específicas) y el rendimiento (la cantidad total de trabajo realizado en un período de tiempo determinado).

Lógica de la demanda base de datos: Es seguro almacenar en base de datos requisitos lógicos. Esto incluye el tipo de información utilizada, la frecuencia de uso, las entidades de datos y las relaciones entre ellas, etc.

Restricciones de diseño: Identifica todas las restricciones de diseño impuestas por estándares, limitaciones de hardware, etc. El cumplimiento de los estándares determina los requisitos de un sistema, que se ajustan a los estándares especificados. Estos estándares pueden incluir procedimientos contables y formatos de informes. Las restricciones de hardware significan que el software puede ejecutarse en el hardware existente o en algún hardware predeterminado. Esto puede imponer restricciones al desarrollar diseños de software. Las restricciones de hardware incluyen la configuración de hardware de la máquina y el sistema operativo.

Propiedades del sistema de software: Proporciona propiedades tales como confiabilidad, disponibilidad, mantenibilidad y portabilidad. Todas estas propiedades deben describirse para verificar que se implementen en el sistema final.

Necesidades específicas de la organización: Identifica los requisitos para que puedan organizarse adecuadamente para una comprensión óptima. Los requisitos se pueden organizar en términos de modos operativos, clases de usuarios, objetos, propiedades, respuestas y jerarquías funcionales.

Proceso de gestión de cambios: Define el proceso de gestión de cambios para identificar, evaluar y actualizar el SRS para reflejar los cambios en el alcance y los requisitos del proyecto.

Aprobación de documentos: Estos proporcionan información sobre el aprobador del documento SRS, incluidos detalles como el nombre del aprobador, la firma, la fecha, etc.

Información de soporte: Proporciona información como catálogos e índices. Esto es especialmente necesario cuando se prepara SRS para proyectos grandes y complejos.