Levantamiento de requerimientos

El siguiente escenario es tí­pico: Un consultor trabaja con los usuarios para describir los procesos de negocioque serán soportados por el software. El equipo de desarrollo recibe la descripción del consultor pero no están familiarizados con los términos de negocio y consideran la descripción demasiado informal. Los desarrolladores escriben su propia descripción desde un punto de vista técnico. El usuario no entiende esta descripción pero la acepta para que el proyecto avance.


El resultado puede ser un sistema que desde el punto de vista del usuario es difícil de usar y que no cumple con sus expectativas.

Parte de este problema es metodológico, y en parte es intrínseco a las caracterí­sticas de los usuarios. Algunas de las problemáticas que se presentan:

  • Los usuarios no saben que es lo que quieren

  • Los usuarios no aceptan como un compromiso los requerimientos escritos

  • Los usuarios insistirán en nuevos requerimientos después de fijar costos y agendas.

  • Los usuarios no están disponibles y la comunicación con ellos es lenta

  • Los usuarios no participan en revisiones de avance.

  • Los usuarios no entienden el proceso de desarrollo y no les interesa.


Existen herramientas y metodologías para el levantamiento de requerimientos. Casos de uso y UML son medios para formalizar este proceso. Que diagramas UML es apropiado usar dependerá del sistema a desarrollar.

Una guía simple en términos de la complejidad del sistema:

  • Aplicación monousuario

    • Diagrama de casos de uso.

    • Diagrama de clases.

    • Diagrama de interacción.



  • Aplicación monousuario, con manejo de eventos:

    • Añadir: Diagrama de estados.



  • Aplicación cliente servidor:

    • Añadir: Diagrama de despliegue y diagrama de componentes, dependiendo de la complejidad.



  • Aplicación compleja distribuida:

    • Todos.




Para una aplicación sencilla debemos realizar entre tres y seis tipos de diagramas, y para una aplicación compleja unos nueve tipos.

El diagrama de casos de uso puede modelar el contexto de un sistema o los requisitos del mismo.

Se puede extender la colección de elementos base de UML utilizando estereotipos.

Referencias:

Database answers es un repositorio con más de 450 esquemas de datos para diferentes aplicaciones. Algunos usados como referencia en la documentación de Micorsoft SQL Server 2005

En el caso de .Net, Design patterns,  AJAX Design Patterns, and .NET training , tiene ejemplos en C# y VB

https://www6.software.ibm.com/developerworks/education/r-rsmvisual/

http://www.programacion.net/tutorial/uml/

http://www.clikear.com/manuales/uml/

http://odl-skopje.etf.ukim.edu.mk/uml-help/