Como crear un documento de Especificación de Requerimientos de Software

Summary

En este video, Ángel Alberto Barón Quimbayo explica detalladamente cómo desarrollar un documento de especificación de requerimientos de software, basado en un estándar internacional. A través de un ejemplo práctico, describe cómo estructurar cada sección del documento, incluyendo la descripción del producto, los requerimientos funcionales y no funcionales, y los detalles de seguridad, rendimiento y dependencias del sistema. Además, se destacan aspectos clave como la importancia de mantener la plantilla intacta, la necesidad de diagramas precisos y la consideración de las políticas de la empresa y los requisitos futuros del software.

Takeaways

• 😀 Es fundamental no modificar la plantilla estándar al desarrollar un documento de especificación de requerimientos de software (SRS).
• 😀 El documento de requerimientos de software actúa como un contrato, definiendo claramente lo que el software hará y lo que no hará.
• 😀 Los requerimientos adicionales pueden ser modificados, pero deben ser negociados en cuanto a tiempo, recursos y costos.
• 😀 El documento debe incluir una introducción que describa el propósito, el alcance, las plataformas y el contexto del software.
• 😀 Se deben definir todas las abreviaturas y acrónimos utilizados en el documento, ya que puede ser leído por personas fuera del área técnica.
• 😀 Es esencial descomponer las funcionalidades del software en diagramas claros y concisos para cada módulo del sistema (e.g., gestión de productos, clientes, ventas).
• 😀 Cada requerimiento funcional debe tener una descripción, entradas, procesos, salidas y requisitos no funcionales asociados (e.g., tiempo de respuesta, seguridad).
• 😀 Los diagramas de descomposición deben realizarse en herramientas adecuadas, como software de modelado, para asegurar claridad y precisión.
• 😀 Es importante describir las características de los usuarios, incluyendo su nivel de conocimiento y las restricciones relacionadas con el uso del software (e.g., horarios de operación, políticas empresariales).
• 😀 Los requisitos no funcionales, como el rendimiento, la seguridad y la integridad, son tan importantes como los funcionales y deben ser claramente establecidos.

Q & A

¿Qué es un documento de especificación de requerimientos de software?

Es un documento que describe detalladamente los requerimientos y funcionalidades del software que se va a desarrollar, estableciendo una línea base que guía el desarrollo del producto, similar a un contrato que especifica lo que el software debe y no debe hacer.

¿Qué información debe incluirse en la introducción del documento?

La introducción debe incluir el nombre del producto de software, el propósito del documento, el ámbito del sistema, y una descripción general de lo que se espera que haga el software. También debe definir las abreviaturas y acrónimos utilizados.

¿Por qué es importante no modificar la plantilla del documento de especificación?

Es importante mantener la plantilla estándar para garantizar que el documento cumpla con las normativas y lineamientos establecidos, como los de la norma ISO y otros estándares relevantes.

¿Qué se entiende por 'requerimientos no funcionales'?

Son aquellos requisitos que no describen las funcionalidades específicas del software, sino atributos como el rendimiento, la seguridad, la fiabilidad o la escalabilidad del sistema. Un ejemplo sería un requerimiento que establezca que la base de datos debe registrar un producto en un máximo de 2 segundos.

¿Cómo se deben estructurar los requerimientos funcionales?

Cada requerimiento funcional debe incluir una descripción clara, los datos de entrada, el proceso a realizar con esos datos, las salidas esperadas, y los requisitos no funcionales asociados, como el tiempo de respuesta o la seguridad.

¿Qué tipo de diagramas se deben utilizar en el documento?

Se deben utilizar diagramas de descomposición de requerimientos del software, en los que se dividen las funcionalidades del sistema en partes más pequeñas y manejables. Estos diagramas deben ser hechos con herramientas específicas y no deben ser diagramas de flujo u otros tipos no relacionados.

¿Qué se debe incluir en la sección de 'características de los usuarios'?

En esta sección se deben detallar los niveles de conocimiento que deben tener los usuarios del sistema, así como cualquier restricción o política de la empresa relacionada con el uso del software.

¿Qué tipo de restricciones pueden incluirse en el documento?

Las restricciones pueden incluir limitaciones en cuanto a las políticas de la empresa (como horarios de funcionamiento), limitaciones de hardware (por ejemplo, requisitos de memoria o sistema operativo), y restricciones de uso (como el acceso solo en ciertos dispositivos o áreas).

¿Cómo se definen las interfaces del software?

Las interfaces se definen especificando cómo el software interactúa con otros sistemas, ya sea hardware o software. Esto puede incluir interfaces de usuario, interfaces de hardware, y otras dependencias o conexiones necesarias para el correcto funcionamiento del sistema.

¿Qué son los requerimientos futuros y por qué son importantes?

Los requerimientos futuros son aquellas funcionalidades o módulos que podrían ser necesarios más adelante, como la expansión del sistema a la web o la integración con otros módulos. Son importantes para prever las necesidades a largo plazo y evitar problemas al intentar modificar el sistema una vez que esté en producción.