S.G.P.M

Introducción – InterfacesActores, Roles y ObjetivosCasos de UsoModelo del Dominio - DocumentaciónDetalle en esp. De requerimientos (atributos)Estructura de los Req. (Apéndice A SRS)Mecanismos de priorización y TrazabilidadPrototipo (Justificación según priorizacion, avance y funcionalidad)Investigación (técnica, SRS y Problema)

“La parte más dura en la construcción de un sistema software es decidir cómo construirlo…Ninguna parte del proceso afecta el resultado del sistema si está hecho mal. Ninguna parte es más dificultosa para rectificarlo después”

Facilitar el mecanismo apropiado para comprender lo que quiere el cliente Analizar algunas necesidadesConfirmar la viabilidad de alguna de estas necesidades Negociar soluciones razonables, sin ambigüedad, validando la especificación y gestionando los requerimientos para que se transformen en un sistema operacional.

No habrá dependencia de otro tipo de sistema Interfaces con el Sistema Teclado, Ratón, Monitor, Interfaz GUI, Tarjeta Grafica y Tarjeta de RED Interfaces con el Usuario Protocolo de comunicación TCP-IP Interfaces con el Hardware Windows JDK Java FX JMF Interfaces con el Software

Los casos de uso de WorDomination describen, mediante acciones y reacciones, el comportamiento del sistema des del punto de vista del usuario. Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno. Son descriptores de las funcionalidades del sistema independientemente de su implementación.

 Inicialmente se muestran todos los casos de uso, organizados por funcionalidades de la siguiente manera: Casos de Uso JugadoresCasos de Uso DiccionariosCasos de Uso EstadísticasCasos De Uso Partidas

En el modelo de dominio tendremos la lógica de negocio, que es donde se implementarán las funcionalidades del sistema. Esto permitirá administrar de manera modular el sistema

 Documentación Clases  Documentación Relaciones Nombre RelaciónTiene un Juego DescripciónPermite la implementación de las jugadas que el usuario escoge. DesdeWorDomination AJuego Nombre clasePartida DescripciónRepresenta las posibles acciones que puede realizar el jugador en una partida, sin incluir la interacción de las jugadas (Juego). Clases RelacionadasAcción Jugada, JugadaLive Nombre AtributoDescripción Atributo

Validación y gestión de requerimientos. Modelado del sistema Especificación de requerimientos Análisis de requerimientos y negociación Identificación de requerimientos

 Total Requerimientos encontrados :83  Juego  Autenticación  Administración  Consulta  No funcionales  Base de Datos  Interfaces:

No. RequerimientoVersiónTipo Nombre Encargado Descripción Objetivo Criterio de Medición Excepciones Observaciones/ Justificación Caso(s) Uso RelacionadoRequerimiento(s) Asociado(s) Trazabilidad  Modelo de dominio  Requerimientos Asociados:  Reglas WorDomination.  Documento Casos de uso: RiesgoPrioridadEstado Verificado en la Plantilla de Construx Capa

 S.G.P.M modifico la plantilla de construx de tal forma que le permitió generar una en la que fuera mas sencilla verificar y validar cada uno de los requerimientos. NUMER O REQUERIMIENTO PARTICULARRESPUESTAJUSTIFICACIO N 1Completo. 2Claro y Conciso. 2Consistente 3Factible 4Suficiente. 5Preciso y no ambiguo. 6Verificable. 7Correcto. 8Modificable 9Trazable 10Necesario.

 (1) cificacionesDeRequerimientos