Especificación de Casos de uso

Los casos de uso deben ser relatos secuenciales que especifiquen una funcionalidad determinada del sistema que se desea desarrollar, así que debe describir como inicia y termina el caso de uso, que datos se intercambian entre el actor y el caso de uso, el flujo de eventos, no solo la funcionalidad, para reforzar esto debe comenzar cada acción con la frase “El actor...”, describir solo los eventos que pertenecen a ese caso de uso, y no lo que pasa en otros casos de uso o fuera del sistema.

De la misma manera se debe tener especial cuidado de no utilizar los siguientes detalles:

• No describir detalles de la interfaz del usuario, a menos que sea necesario para entender el comportamiento del sistema.
•  Evitar terminología vaga tal como “por ejemplo” “etc” “información”.
• Evite dejar en el texto del caso de uso ambigüedades o preguntas que se debieron resolver en el levantamiento de información.

Los casos de uso deben contar con los siguientes elementos

• El conjunto de todos los casos de uso, debe cubrir los requerimientos del sistema en su totalidad.
• Se pueden definir casos de uso en diferentes niveles.
• A nivel de sistema de Negocio
• A nivel de sistema de Software 
• Las descripciones de los casos de uso son cruciales para la comprensión del sistema.
• Debe  contar con Pre y Post Condiciones, una  Pre-Condición es una restricción sobre cuando un caso de uso puede empezar. que necesita para poder ser ejecutado, la Post-Condición para un caso de uso debe ser verdadera, independientemente de cual flujo sea ejecutado. Si algo puede fallar, debería cubrirse en la post condición diciendo: “La acción se ha completado o si algo ha fallado, la acción no se ha realizado”, en lugar de decir “La  acción se ha completado”.

Prototipos

Los prototipos son modelos a escala o facsímil de lo real, pero no tan funcional para que equivalga a un producto final, ya que no lleva a cabo la totalidad de las funciones necesarias del sistema final.

Es importante definir un objetivo para los prototipos, ya que puede ser útil en diferentes fases del proyecto, por ello su objetivo debe ser claro. Es decir durante diferentes etapas del ciclo de vida se pueden utilizar para diferentes necesidades, por ejemplo durante la fase de análisis se usa para obtener los requerimientos del usuario, en la fase de diseño se usa para ayudar a evaluar muchos aspectos de la implementación seleccionada y así de acuerdo a la necesidad de cada etapa.

Características de un prototipo

• El prototipo es una aplicación que puede no funcionar(conjunto de dibujos por ejemplo, una presentación de escenarios) o que puede funcionar (conjunto de pantallas que proporcionan un modelo dinámico).
• Los prototipos se crean con rapidez
• Los prototipos evolucionan a través de un proceso iterativo.
• Los prototipos tiene un costo bajo desarrollo.

Definición de criterios de aceptación

Estos criterios nos permiten asegurar que los requisitos satisfacen la funcionalidad requerida y al mismo tiempo que el producto es de calidad, nos ayuda a obtener un nivel de aceptación realista tanto para el cliente como la empresa que los desarrolla.

para la definición de criterios de aceptación se presenta el siguiente modelo:

• Se debe encontrar el documento de requisito terminado, revisado y aprobado por las diferentes partes, implicadas.
• El requisito no debe tener escenarios ambiguos
• El requisito debe hacer que dice el documento de especificación ni mas, ni menos y cumplir con todos los escenarios.
• El requisito debe ser medible, es fácil identificar si cumple o no cumple.
• No existe contraindicaciones con otros requisitos
• El requisito debe haber sido probado y aceptado por este proceso.
• Se debe entregar el requisito dentro de las fechas establecidas.
• El requisito aparte de cumplir con los anteriores pasos, puede haber otros criterios que el cliente solicite.