Conforme seguimos en el ámbito del desarrollo de software, hemos visto muchos documentos SRS para proyectos que varían de tamaño y que utilizan diferentes metodologías.
Algunos de ellos mejores que otros; por tal motivo en este artículo profundizaré en lo que se necesita para crear uno que sirva como una fuente para su proceso de desarrollo. Un SRS en el que todos los involucrados en el proceso pueden consultar para impulsar las decisiones de ingeniería y crear tickets de desarrollo preliminares para la etapa de planificación del desarrollo. Aumentando así las posibilidades de ejecutar con éxito la parte técnica de su aplicación.
Pero…. ¿Realmente necesita un documento SRS?
Por lo general, una versión anterior de un producto de inicio o MVP no consta de suficientes funciones para necesitar un documento SRS. Caso contrario sí está creando un gran desarrollo, necesitara escribir un SRS.
Si está creando un MVP estándar o la primera iteración de su producto, puede ser suficiente explicar su producto a su equipo de desarrollo en términos del alcance del producto, usar un diagrama BPMN si tiene uno o prototipos de alta fidelidad.
¿Qué es un documento de especificación de requisitos de software?
La especificación de requisitos de software o Software Requirements Specification (SRS) es un documento que proporciona una descripción detallada de una aplicación, propósito, requisitos y características.
Un documento SRS comúnmente incluye:
- El propósito de la aplicación, incluido el público objetivo, el uso previsto y el alcance de la misma.
- Una descripción general de la aplicación, incluidas las necesidades de los usuarios y las suposiciones y dependencias que rodean a la aplicación.
- Un resumen detallado de sus requisitos específicos, incluidos los requisitos funcionales, los requisitos de interfaz, las características del sistema y los requisitos no funcionales.
¿Por qué es importante crear un SRS?
Un SRS actúa como guía de un proyecto, en el cual se especifica el proceso de desarrollo que seguirá el o los equipos involucrados.
Mantiene al equipo de desarrollo, control de calidad, operaciones, mantenimiento y equipo de productos bajo una misma linea de trabajo.
Ayuda en la toma de desiciones sobre la aplicación durante el ciclo de vida del software, cuando se agregan funcionalidades, cuando se eliminan o cuándo los usuarios simplemente la ignoran.
Ademas un SRS puede y debe reducir tiempos y costos del desarrollo.
¿Cómo escribir un documento SRS?
1. Esquema
Como cualquier otro tipo de documento, un SRS requiere que comience con una estructura. Ya que este documento deberá ser entendido por el equipo de desarrollo y los demás equipos involucrados con el proyecto.
2. Proposito
En esta sección del documento SRS, se describe el propósito de la aplicación comenzando por:
Público objetivo/Uso
Se definen las partes interesadas que utilizarán el SRS y cómo será utilizado. Comúnmente son incluidos desarrolladores, equipo de aseguramiento de calidad y gerentes de proyectos.
Sin embargo, ademas de estas personas involucradas, puede que este documento sea compartido con otros departamentos como marketing y ventas.
Definición del producto
Aquí es donde se describirá la aplicación desde una perspectiva empresarial. En este punto se incluyen los beneficios, objetivos y metas, ayudando a alinear todos los departamentos, que dirección tomaran y por qué.
Glosario de términos
Dentro del glosario de términos se definirán cualquier termino relevante de la aplicación. A modo se asegurar que todos estén en la misma página, independientemente de la capacidad técnica o el departamento.
Asimismo las referencias se incluyen aquí (ej. Documentación legal o mejores practicas).
3. Descripción general del producto
En esta sección, deberá describir las funcionalidades de la aplicación. Es decir, se describe lo que se esta construyendo y para quién lo esta construyendo.
Necesidades del usuario
Es de suma importancia describir las necesidades de sus usuarios (también conocidas como clase de usuarios o características de usuarios) dentro de su descripción general.
Ademas se debe enumerar los usuarios principales o secundarios que utilizarán el producto de forma regular y defina su viaje a través del producto.
Esto asegurara que todo el equipo este enfocado en su usuario final durante todo el proceso de desarrollo del producto.
Suposiciones y dependencias
Esta sección del SRS se utiliza para describir cualquier factor que pueda impedir su capacidad para cumplir con las necesidades y las dependencias de factores externos del proyecto.
4. Detalles de los requisitos de la aplicación
Una vez que se tiene en cuenta las necesidades de los usuarios, es necesario brindar una descripción detallada de los casos de uso de su producto, así como de los requisitos no funcionales.
A modo que el caso de uso describa como el usuario final interactuara con la aplicación y sirviendo de ayuda para ponerse en el lugar del usuario final.
Requerimientos no funcionales
Los requisitos no funcionales son tan importantes como los funcionales. Estos incluyen el rendimiento, seguridad, protección y calidad.
Una vez que se escriben los casos de uso y se hayan enumerado los requisito no funcionales, así como también cualquier información complementaria relevante, el documento SRS estará listo para leérselo a las partes interesadas.
5. Implementación del SRS
Esto significa presentar el documento a todos los equipos involucrados en su proceso de desarrollo de productos, plataforma de gestión de tickets o registro de códigos.
Una vez que se haya asegurado de que todos los equipos estén contentos y el documento esté firmado, es hora de implementarlo.
Conclusión
En entornos de inicio acelerados donde los fundadores se ven obligados a moverse cada vez más rápido, la documentación como un SRS a menudo se deja atrás, y si tiene el equipo adecuado a su alrededor, eso no es necesariamente será un mal.
Sin embargo, si necesita crear uno, es importante asegurarse de seguir las mejores prácticas mencionadas anteriormente, a fin de optimizar cada proceso dentro del desarrollo o requerimiento.
Se asegurará de crear un SRS que comunique claramente los requisitos clave a todos los miembros de su equipo o equipos involucrados, reduciendo el tiempo y los costos de desarrollo. Con el beneficio adicional de que puede ayudarlo a tomar decisiones sobre el ciclo de vida de su producto más adelante.
