He escrito mucho de requerimientos pero no me he explayado en este aspecto sobre todo si alguien viene iniciando, no sabrá de qué estoy hablando.
Los requerimientos son las piezas fundamentales de todo proyecto de desarrollo software ya que nos dan la pauta para la planeación, podemos dictar costos y manejar recursos, “tener claro lo que se va a hacer durante la ejecución del proyecto, es clave para el éxito del mismo”.
Los requerimientos se dividen básicamente en dos, los funcionales y no funcionales.
Requerimientos Funcionales
Los requerimientos más digeribles, digámoslo entre comillas, su concepto es simple y son las descripciones detalladas de como debe funcionar un sistema y qué información debe manejar.
Expresan todas las cualidades que se deben desarrollar durante la ejecución de un proyecto de software, estás cualidades deben satisfacer el negocio proporcionado por los stakeholders, su descripción se debe plantear de manera muuuy detallada para facilitar la implementación.
Ambigüedades en los requerimientos funcionales justo durante el desarrollo, pueden causar interpretaciones inadecuadas, que pase esto no es del todo mal, siempre es menos costoso tomarse un momento para re-analizar el requerimiento, que desarrollar algo que no sea válido.
Un ejemplo de un requerimiento funcional ambiguo:
“El sistema enviará una notificación a los usuarios”
¿Qué notificación(es)?, ¿Dónde se deben visualizar esas notificaciones?, ¿Bajo qué escenarios y circunstancias?, ¿Qué usuarios?
Entre otras preguntas…
Si vamos resolviendo dudas el requerimiento se irá afinando, al final es el objetivo, analizar correctamente.
Requerimientos No Funcionales
Estos requerimientos dictan como realiza un sistema su trabajo. Va más enfocado al como lo hace y NO al que hace. En estos requerimientos se necesita definir todos los atributos del sistema, como lo es la escalabilidad, la seguridad, disponibilidad, rendimiento, mantenimiento, etc.
Estos requerimientos se dividen en tres tipos:
Requerimientos del producto. Son los que indican que necesita el sistema para ser eficiente y fiable, por ejemplo la velocidad con la que se ejecuta una App móvil, la practicidad con la que un usuario domina la aplicación, cuántos recursos necesita para funcionar, etc.
Requerimientos organizacionales. Esto se enfoca más a qué políticas y procedimientos se tienen que seguir, tanto como políticas del cliente y políticas del equipo de desarrollo. Por ejemplo, si el cliente necesita utilizar alguna herramienta de auditoría de código, por petición de alguna entidad certificadora, esto debe seguirse al pie de la letra y fundamentar este requerimiento. Algunas políticas a la hora de desarrollar pueden ser, qué lenguajes y frameworks utilizar, seguir una guía de estilo de código, convenciones de nombres, etc.
Requerimientos externos. Son los requerimientos no funcionales que se derivan por causas externa, pueden ser requerimientos legales, por ejemplo alguna ley que dicte como operar en algún país, requerimientos éticos que constituyen que será aceptado por los usuarios y sus costumbres.
Estos requerimientos a la hora de definirse pueden ser complicados, sobre todo al momento de ponerlos más explícitos para los interesados, no darlos por hecho ni dejarlos a un lado, pueden ayudar a evitarse preocupaciones, por ejemplo algún mantenimiento del sistema si no se define correctamente, puede causar un problema futuro.
Conclusión
El análisis deficiente de los requerimientos, es posiblemente una de las causas que determinan una mala ejecución de un proyecto de software, entender bien los requerimientos y gestionarlos de manera efectiva en una matriz de trazabilidad, que es básicamente la bitácora de los requerimientos, nos ayudarán a tener un fin exitoso de nuestro proyecto.