Metodología Para Toma De Requerimientos

¿ Que es un requerimiento ?
Una definición adoptada es que un requerimiento es simplemente una declaración abstracta de alto nivel
de un servicio que debe proporcionar un sistema.
Los requerimientos son una pieza fundamental en proyectos de Software, en base a esto se puede determinar y hacer estimaciones de tiempo, costos, definir recursos necesarios, elaborar cronogramas, plan de trabajo, cartas gantt, etc.
Permite verificar y comprobar si se obtuvieron los objetivos establecidos para el proyecto.
Muchas veces los proyectos fracasan por que la toma de requerimientos es incompleta, falta de documentación o por el mal manejo de los cambios de los requerimientos durante la vida de desarrollo del Software.

Clasificación de Requerimientos
La clasificación de requerimientos es importante, de esta manera podemos definir y abstraer con mayor detalle los tipos de requerimientos a los que nos enfrentamos, los requerimientos se pueden clasificar en:

● Requerimientos Funcionales.
● Requerimientos no Funcionales.
● Requerimientos de Implementación.

Requerimientos Funcionales: Describen las interacciones entre el sistema y su entorno, usuarios u otros
sistemas.
Requerimientos No Funcionales: Describen aspectos visibles del sistema por el usuario, y que no se relacionan directamente con el comportamiento funcional del sistema.
Requerimientos de Implementación: Corresponden a las necesidades del cliente que restringen la implementación, como la plataforma tecnológica, de hardware, redes, etc.

Características en la Toma de Requerimientos
Las características mas importantes y fundamentales para una toma de requerimientos deben contener los siguientes puntos:

● Un requerimientos debe estar especificado siempre por escrito.
● Un requerimiento debe ser posible de probar y verificar.
● Un requerimiento debe ser conciso.
● Un requerimiento debe ser completo.
● Un requerimiento debe ser consistente.
● Un requerimiento no debe ser ambiguo.

Normas de Calidad y Estándares
Ahora que ya entendemos lo que es un requerimiento, podemos hacer uso de alguna técnica enmarcada en una metodología estándar, utilizada en la industria y de clase mundial. (Std 610.12-1900, IEEE:62 ) y que nos permitirá entender y documentar formalmente la obtención de requerimientos para el desarrollo de algún tipo de proyecto de software.

● Se sugiere la utilización de diagramas UML(Caso de Uso) y Procesos(BPMN) con formato de documentos definidos (IEEE-STD-803-1998) y (formal/2011-01-03).
● También se sugiere utilizar SCRUM como metodología ágil para la definición de requerimientos para un desarrollo de software.

Las metodologías imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo más predecible y eficiente.
Nos dan la posibilidad de hacer mejor las cosas y generar valor.

Casos de Uso (UML)
UML (Lenguaje Unificado de Modelado), con los casos de uso, apoyan al análisis de los requerimientos como una técnica de adquisición de estos, una definición es que los Casos de Uso no son parte del diseño, sino parte del análisis.



Ficha de Caso de Uso
Cada caso de uso debe estar documentado en el siguiente formato estándar conocido como ficha de caso de uso.



BPMN
Corresponde a la notación estándar para el diseño de procesos de negocio, similar al diagrama de actividades del UML, pretende proporcionar una notación fácilmente comprensible por todos los usuarios del negocio, desde los analistas, desarrolladores, clientes, hasta aquellos que monitorizarán y gestionarán los procesos.

Notación básica















SCRUM

Metodología ágil, la medida justa entre “ningún proceso” y “demasiado proceso”, proporcionando simplemente “suficiente proceso”.
Para tomar requerimientos con esta técnica debemos saber crear una pila de producto.
La pila de producto es el corazón de Scrum, básicamente es una lista priorizada de requisitos, o funcionalidades. Cosas que el cliente quiere y que debe al menos tener los sigtes. campos.

ID – un identificador único auto-incremental.
Nombre – una descripción corta de la historia. Por ejemplo, “Ver tu historial de transacciones”. Suficientemente claro como para comprender de qué estamos hablando.
Importancia – el ratio de importancia que se da a la historia. Por ejemplo, 10. O 150. Más alto = más importante. Suelo evitar el término “prioridad” porque típicamente “1” se considera la “máxima prioridad, lo que es muy incómodo si posteriormente decides que algo es más importante. ¿Qué prioridad le daríamos a ese nuevo elemento? ¿Prioridad 0? ¿Prioridad -1?
Estimación inicial – la valoración inicial del Equipo acerca de cuanto trabajo es necesario para implementar la historia, comparada con otras historias. La unidad son “puntos de historia” y usualmente corresponde a “días-persona ideales”.
Como probarlo – una descripción a alto nivel de como se demostrará esta historia. Se trata, esencialmente, de una simple especificación de un test: “Haz esto, entonces haz lo otro, y entonces debería ocurrir aquello”. Si se practica TDD (Test-Driven Development, desarrollo orientado a test) esta descripción puede usarse como pseudo-código para vuestro test de aceptación.
Notas – cualquier otra información, clarificación, referencia a otras fuentes de información, etc. Normalmente muy breve.

Ejemplo de pila de producto



Resumen
Hemos revisado 3 técnicas para toma de requerimientos y análisis, con el fin de entender la verdadera necesidad del cliente.
UML, BPMN y Scrum son estándares. Se utilizan exitosamente, ya sea en propuestas o en desarrollos.
Estas metodologías se deben incorporar como técnicas para la captura de requerimientos, comprometerse con cumplir el procedimiento y adoptar estas técnicas nos diferenciaran positivamente de la competencia y agregaran valor a nuestro trabajo.
En un proceso de desarrollo de software es muy importante contar con un nivel de documentación de los sistemas, estos nos permite:

● Mejoramiento continuo de los sistemas
● Entendimiento claro de los requisitos.
● Re-ingeniería de sistemas.
● Certificación y controles de auditoría más expedito.
● Mejor administración de sistemas y control de cambios.


¿Por qué utilizar un modelo de desarrollo?
● Por que es una guía a seguir que contiene las mejores prácticas reconocidas a nivel mundial.
● Por que permite estandarizar las prácticas establecidas en cuanto a desarrollo y mantención del software.
● Por que se enfoca en las áreas claves donde es necesario realizar mejoras.
● Por que genera mejoramiento de la calidad y satisfacción del cliente, mediante una mejor administración de
los requerimientos e identificación temprana de errores.
● Por que permite mejorar cumplimiento de los tiempos de entrega estimados a través de una planificación
más rigurosa.
● Por que genera una base de conocimiento para el mejoramiento continuo.
● Por que permite detectar errores en las etapas iniciales y mejorar el presupuesto de los proyectos.
● A través de los repositorios de datos, permite obtener métricas para apoyar la toma de decisiones.


Este es un proceso de aprendizaje continuo, así que la historia no acaba aquí.


Bee Free.. Use Linux...