La especificación de requisitos de software (SRS) es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como requisitos funcionales. Además de los casos de uso, la ERS también contiene requisitos no funcionales (complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación, como, por ejemplo, restricciones en el diseño o estándares de calidad.

Está dirigida tanto al cliente como al equipo de desarrollo. El lenguaje utilizado para su redacción debe ser informal, de forma que sea fácilmente comprensible para todas las partes involucradas en el desarrollo.

Las características de un buen SRS son:

• Sin ambigüedades
• Completa
• Verificable
• Coherente
• Modificable
• Trazable
• Utilizable durante la fase explotación y mantenimiento

Cada característica se aborda con mayor detalle a continuación:

Sin ambigüedad. Una SRS es inequívoca si- y solo si- cada requisito en ella tiene una única interpretación.

• Como mínimo, esto requiere que cada característica del producto final se describa utilizando un único termino.
• En los casos en los que un término utilizado en un contexto particular pueda tener múltiples significados, el termino debe incluirse en un glosario donde se especifique su significado.

Completa. Un SRS es completo si posee las siguientes cualidades:

• Inclusión de todos los requisitos significativo, ya sean relativos a la funcionalidad, el rendimiento, las limitaciones de diseño, los atributos o las interrelaciones externas.
• Definición de las respuestas de software a todas las clases realizables de datos de entrada en todas las clases realizables de situaciones. Obsérvese que es importante especificar la respuesta a los valores de entrada válidos y no validados.
• Conformidad con cualquier norma del SRS que le sea aplicable. Si una sección particular de la norma no es aplicable, el SRS debe incluir el número de sección y una explicación de porque no es aplicable.

Verificable. Un SRS es verificable si, y solo si, todos los requisitos establecidos en el son verificables. Un requisito es verificable si y solo si existe algún proceso finito y rentable con el que una persona o máquina pueda comprobar que el producto de software cumple con el requisito.

• Ejemplos de requisitos no verificables, estas son declaraciones como: a)El producto debe funcionar bien, o el producto debe tener una buena interfaz humana. Estos requisitos no pueden verificarse porque es imposible definir los términos bueno o bien. b)El programa nunca debe entrar en un bucle infinito. Este requisito no es verificable porque la comprobación de esta cualidad es teóricamente imposible.

Coherente. Un buen SRS es consistente si y solo si ningún conjunto de requisitos individuales descritos en ella entra en conflicto. Hay tres tipos de conflictos principales en un SRS:

• Dos o más requisitos pueden describir el mismo objeto del mundo real, pero utilizar termino diferentes para ese objeto. Por ejemplo, la solicitud de una entrada de usuarios por parte de un programa puede denominarse “prompt” en un requisito y “cue” en otro.
• Las características especificadas de los objetos del mundo real pueden entrar en conflicto. Por ejemplo: 1)El formato de un informe de salida puede describirse en un requisito como «tabular” pero en otro como “textual” 2) Un requisito puede establecer que todas las luces deben ser verdes mientras que otro establece que todas las luces deben ser azules. 3) Puede haber un conflicto lógico o temporal entre dos acciones específicas. Por ejemplo; a) Un requisito podría especificar que el programa sumará dos entradas y otro especificar que el programa las multiplicará. b) Un requisito puede establecer que A debe seguir a B, mientras que otros requieren que A y B ocurran simultáneamente.

Modificable. Un SRS es modificable si su estructura y estilo son tales que cualquier cambio necesario en el requisito puede realizarse de forma fácil, completa y coherente. Los cambios en un SRS generalmente requieren:

• Tener una organización coherente y fácil de usar, con un índice y referencias cruzada explicitas.
• No ser redundante; es decir, el mismo requisito no debe aparecer en otras partes en el SRS.

Trazable. Una SRS es trazable si el origen de cada uno de sus requisitos es claro y se facilita la referencia de cada requisito de la futura documentación de desarrollo o mejora. Se recomiendan dos tipos de trazabilidad:

• La trazabilidad hacia atrás (es decir, hacia etapas anteriores de desarrollo) depende de que cada requisito haga referencia explícita a su fuente en documentos anteriores.
• La trazabilidad hacia adelante (es decir, hacia todos los documentos generados por el SRS) depende que cada requisito del SRS tenga un nombre o número de referencia único.

Utilizable durante la fase de operación y mantenimiento. El SRS debe atender las necesidades de la fase de operación y mantenimiento, incluyendo la eventual sustitución del software.

• El mantenimiento suele ser realizado por personal no relacionado con el desarrollo original. Los cambios locales (correcciones) pueden aplicarse mediante un código. Si embargo, para los cambios de mayor alcance, la documentación sobre el diseño y los requisitos es esencial. Esto implica dos acciones:
• El SRS debe ser modificable
• El SRS debe contener un registro de todas las disposiciones especiales que aplican a los componentes individuales, tales como:
• Su criticidad
• Su relación con las necesidades sólo temporales.
• Su origen
• Este tipo de conocimiento se da por sentado en la organización de desarrollo, pero a menudo falta en la organización de mantenimiento. Si no se entiende la razón o el origen de una función, a menudo es imposible realizar un mantenimiento adecuado del software.

No olvides que todas nuestras soluciones son liberadas bajo un sistema de calidad robusto. En caso de ser necesario, puedes contactarnos para mejorar el proceso de laboratorio y administrativo de tu organización a través software 100% confiable y seguro. Recuerda que en deappharma contamos  con una suite de herramientas que te ayudaran a mejorar tus procesos con un enfoque en integridad de datos. Somos expertos en la materia, por lo que procesos complejos no representa un reto para nosotros, debido a que tenemos en mente los aspectos relevantes de cumplimiento.

Referencias

• FDA, Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices

• GAMP 5 Guide: Compliant GxP Computerized Systems

• Guía del IEEE sobre especificaciones de requisitos de software ANSI/IEEE std 1984.

¡Contáctanos! y conoce de que manera te vamos a ayudar.

¡Únete a nuestra comunidad en redes!