srs v.0.5 (plantilla corregida)
DESCRIPTION
Plantilla srsTRANSCRIPT
S.G.P.M.SRS
S.G.P.M.
31 / 10 / 09
SRS – Especificación de Requerimientos de Software – V.0.2
Andres Fajardo Bermudez
Andres Hidalgo
Hernan Garcia Peña
Oscar Gomez
Wilson PerezHISTORIAL DE CAMBIOS
S.G.P.M.SRS
VERSION FECHA SECCIÒN MODIFICADA
DESCRIPCION CAMBIOS
RESPONSABLES
V.0.1 Sabado, 5 de Septiembre de 2009.
1.1, 1.3, 1.4. Se realizaron aportes de ideas para las secciones descritas.
S.G.P.M.
V.0.2 Sabado, 12 de Septiembre de 2009.
1.2, 1.5 Se completaron las secciones faltantes.
S.G.P.M.
Tabla 1: Historial de cambios
S.G.P.M.SRS
TABLA DE CONTENIDO
TABLA DE CONTENIDO.............................................................................................................. 3
LISTA DE TABLAS........................................................................................................................ 5
LISTA DE ILUSTRACIONES..................................................................................................................... 6
1 INTRODUCCIÓN................................................................................................................................. 7
1.1 PROPÓSITO............................................................................................................................................71.2 ALCANCE...............................................................................................................................................81.3 DEFINICIONES, ACRÓNIMOS, Y ABREVIACIONES............................................................................................91.4 REFERENCIAS.......................................................................................................................................131.5 APRECIACIÓN GLOBAL...........................................................................................................................14
2 CICLO DE VIDA DE REQUERIMIENTOS...............................................................................................16
2.1 IDENTIFICACIÓN DE STAKEHOLDERS..........................................................................................................162.2 NECESIDADES DEL USUARIO....................................................................................................................172.3 PARTICIPACIÓN POR ROLES....................................................................................................................172.4 PROCESO DE REQUERIMIENTOS................................................................................................................18
2.4.1 Identificación de Requerimientos..............................................................................................182.4.2 Especificación de Requerimientos............................................................................................212.4.3 Priorización de Requerimientos................................................................................................222.4.4 Trazabilidad..............................................................................................................................262.4.5 Validación y verificación...........................................................................................................26
2.5 ADMINISTRACIÓN DE REQUERIMIENTOS.....................................................................................................262.6 INTERFACES.........................................................................................................................................26
3 DESCRIPCIÓN GLOBAL..................................................................................................................... 27
3.1 PERSPECTIVA DEL PRODUCTO..................................................................................................................273.1.1 Interfaces con el sistema..........................................................................................................273.1.2 Interfaces con el usuario...........................................................................................................283.1.3 Interfaces con el Hardware.......................................................................................................303.1.4 Interfaces con el Software.........................................................................................................303.1.5 Interfaces de Comunicación......................................................................................................353.1.6 Restricciones de Memoria.........................................................................................................353.1.7 Operaciones..............................................................................................................................353.1.8 Requerimientos de Adaptación del Sitio...................................................................................36
3.2 FUNCIONES DEL PRODUCTO....................................................................................................................373.3 CARACTERÍSTICAS DEL USUARIO...............................................................................................................373.4 RESTRICCIONES.....................................................................................................................................393.5 MODELO DEL DOMINIO.........................................................................................................................403.6 SUPOSICIONES Y DEPENDENCIAS..............................................................................................................43
S.G.P.M.SRS
4 REQUERIMIENTOS ESPECÍFICOS....................................................................................................... 45
4.1 REQUERIMIENTOS DE INTERFACES EXTERNAS..............................................................................................514.1.1 Interfaces con el Usuario..........................................................................................................514.1.2 Interfaces con el Hardware.......................................................................................................524.1.3 Interfaces con el Software.........................................................................................................544.1.4 Interfaces de Comunicaciones..................................................................................................55
4.2 CARACTERÍSTICAS DEL PRODUCTO DE SOFTWARE........................................................................................554.3 REQUERIMIENTOS DE DESEMPEÑO...........................................................................................................574.4 RESTRICCIONES DE DISEÑO.....................................................................................................................594.5 ATRIBUTOS DEL SISTEMA DE SOFTWARE (NO FUNCIONALES).........................................................................60
4.5.1 Confiabilidad.............................................................................................................................604.5.2 Disponibilidad...........................................................................................................................604.5.3 Seguridad..................................................................................................................................604.5.4 Mantenibilidad.........................................................................................................................614.5.5 Eficiencia...................................................................................................................................614.5.6 Facilidad de Uso........................................................................................................................61
4.6 REQUERIMIENTOS DE LA BASE DE DATOS...................................................................................................61
5 ANEXOS.......................................................................................................................................... 64
S.G.P.M.SRS
Lista de Tablas
Tabla 1: Historial de cambios......................................................................................1Tabla 2: Acrónimos.....................................................................................................7Tabla 3: Interfaces con el Software...........................................................................13Tabla 4: Descripción de las Características del Usuario............................................17Tabla 5: Definiciones del Modelo de Dominio...........................................................19Tabla 6: Formato de documentación del Modelo del Dominio..................................20Tabla 7: Documentación de Requerimientos............................................................27
S.G.P.M.SRS
Lista de Ilustraciones
Ilustración 1: Propósito................................................................................................................................5Ilustración 2: Alcance...................................................................................................................................6Ilustración 3: Apreciación Global..................................................................................................................7Ilustración 4: Tipos de productos de software.............................................................................................8Ilustración 5: Interfaces con el usuario......................................................................................................10Ilustración 6: Operaciones..........................................................................................................................15Ilustración 7: Tips para definir funciones del producto..............................................................................16Ilustración 8: Características del Usuario...................................................................................................17Ilustración 9: Restricciones.........................................................................................................................18Ilustración 10: Limitaciones........................................................................................................................18Ilustración 11: Descripción documentación del modelo del dominio.........................................................20Ilustración 12: Suposiciones.......................................................................................................................21Ilustración 13: Dependencias [1]................................................................................................................21Ilustración 14: Distribución de requerimientos..........................................................................................23Ilustración 15: Características de los Requerimientos................................................................................26Ilustración 16: Documentación de Requerimientos...................................................................................28Ilustración 17: Interfaces con el Usurario...................................................................................................29Ilustración 18: Interfaces de Hardware......................................................................................................30Ilustración 19: Interfaces con el Software..................................................................................................31Ilustración 20: División por Funcionalidades..............................................................................................32Ilustración 21: Ejemplo Enunciado Requerimientos...................................................................................34Ilustración 22: Atributos de Calidad a tener en cuenta..............................................................................35Ilustración 23: Características de Confiabilidad..........................................................................................36Ilustración 24: Características de Disponibilidad........................................................................................37Ilustración 25: Características de Seguridad...............................................................................................37Ilustración 26: Características de Mantenibilidad......................................................................................38Ilustración 27: Portabilidad del Sistema.....................................................................................................38Ilustración 28: Características Bases de Datos...........................................................................................39
S.G.P.M.SRS
1 Introducción
1.1 Propósito
El propósito o razón por la cual es vital la efectiva realización de un SRS bien documentado, se fundamenta en el hecho de que los requerimientos son atributos vitales y necesarios en un sistema, son declaraciones que identifican factores en cuanto a características, capacidades o calidad de un sistema con el fin de que tenga valor y utilidad para un cliente o usuario final, convirtiéndose así en la clave del éxito (o fracaso) de un proyecto técnico, y la base de el trabajo que viene en su futuro desarrollo, por lo cual es importante realizar una buena documentación de la especificación de los requerimientos, originando de esta manera que se satisfagan los objetivos del cliente correctamente [4].
Para el contexto de la materia de Ingeniería de Software, se obtendrán requerimientos del proyecto escogido (WorDomination) con la finalidad descrita anteriormente, para lo cual se describirán sus requerimientos más importantes mediante procedimientos descritos posteriormente.
Vale la pena considerar que -como se mencionó en el SPMP previamente- puesto que es imposible “calcar” o hacer una réplica exacta de las funcionalidades de un software, el SRS siempre estará incompleto en cuanto a la identificación de requerimientos de una u otra manera. [5]
El SRS concierne tanto al cliente (que determina si las especificaciones del producto se cumplen o no de acuerdo a los requerimientos buscados por él – en caso de no cumplirse, el proyecto será considerado como un fracaso. [10] y [11]), para el desarrollador (que de acuerdo a la especificación puede identificar mejor los casos de uso asociados y con base en esto realizar un desarrollo e implementación efectivos) y para el grupo S.G.P.M., puesto que como ingenieros de sistemas se tiene la responsabilidad de proveer la documentación correspondiente de requerimientos y sus funciones de alto nivel que serán implementadas. [10]
S.G.P.M.SRS
1.2 Alcance
S.G.P.M. está encargado de la realización de desarrollo de una aplicación que modela el juego original Scrabble [26], junto con su documentación respectiva, con el fin de que se satisfagan los requerimientos y necesidades del cliente, que en nuestro caso es el Ingeniero Miguel Eduardo Torres Moreno.
Básicamente, se manejarán dos tipos de usuarios del software: el jugador (o clientes) y el administrador (o servidor), y sus funcionalidades son las que se muestran a continuación (también se pueden observar en la Sección 2.1.7 – Funcionamiento):
TIPO DE USUARIO FUNCIONALIDAD
Administrador Crear partidas Lanzar Partidas Cargar Partidas.
Jugador Usuarios Crear Jugador Borrar Jugador Ver Detalles Jugador Añadir Palabra Eliminar Palabra Ver puntaje Salvar Partida Cambiar Fichas Pasar Turno Deshacer Jugada Validar Jugada Colocar Ficha en el tablero Quitar ficha del tablero Mover ficha en el tablero Salir Ver Log
S.G.P.M.SRS
1.3 Definiciones, Acrónimos, y Abreviaciones
A Administrador de Configuraciones [2]: Es el encargado de controlar la evolución del sistema de Software. Incluye identificación (reflejar estructura del producto y sus componentes con sus respectivas ids de versiones y id de configuración), control (tomar decisiones sobre la salida de un producto y sus cambios través del ciclo de vida asegurando consistencia según la línea base), registro de estado (recordar y reportar sobre el estado de los componentes y sus peticiones de cambios), auditoría y revisión (validar que el producto esté completo y mantener su consistencia a través de componentes, asegurando que están en el estado apropiado durante el proyecto.
Arquitecto del sistema [3]: Es aquel encargado de la arquitectura del software, o de la estructura (o estructuras) del sistema que compromete varios elementos de Software, las propiedades externamente visibles de esos elementos y las relaciones entre estos.
Aplicación Cliente- Servidor: Una aplicación con arquitectura Cliente/Servidor es en la cual se requiere que haya dos partes que cumplan funciones distintas, una que requiera de un servicio (cliente) y otra que lo preste (servidor), permitiendo además que puedan realizar procesos de manera paralela o independiente entre ellos.
Artefactos del proyecto [13]: Productos de trabajo desarrollados durante el tiempo de vida del proyecto.
E E.I.: Entradas externas.E.O.: Salidas externas (con operación matemática).E.Q.: Consultas sobre el sistema.Entregables del proyecto [13]: Artefactos diseñados para el cliente.
G Gerente de Proyecto [3]: El gerente es una persona encargada de la gestión del proyecto, o de planear y ubicar recursos para asegurar la entrega de un sistema de calidad de Software con el tiempo, calidad y presupuesto adecuados, enfrentándose a dos barreras importantes: complejidad y cambio.
Gestor de Calidad [9]: Persona encargada del plan de aseguramiento de
S.G.P.M.SRS
calidad en el Software, especificando claramente cual será el propósito del plan del proyecto, la organización y los estándares que se usarán.
Gestor de Riesgos [2]: Persona encargada de identificar riesgos que puedan ocurrir en el proyecto y crear planes para minimizar sus efectos en este [2].
I IDE [1]: (Integrated Development Environment - Entorno integrado de desarrollo). Aplicación compuesta por un conjunto de herramientas útiles para un programador.
IEEE [7]: IEEE es una organización sin ánimo de lucro, una asociación líder profesional en el avance de la tecnología. Originalmente era un acrónimo para “Instituto de Ingenieros Electrónicos y Eléctricos” pero hoy en día se ha expandido de tal manera que tan solo le llamamos IEEE (pronunciado “I Triple E”).
J JDBC: Java database Connectivity: Librería de Java que facilita la labor de conexión a una base de datos desde cualquier IDE.
L Línea Base [6]: Producto de trabajo que ha sido formalmente desarrollado y acordado, que puede ser cambiado solo por medio de cambios acordados en procedimientos en el plan de administración de configuraciones. Un producto de trabajo del documento base puede ser el origen de futuros desarrollos.
P Porcentaje de avance [6]: Son documentos que irán indicando el porcentaje de avance que se lleva de distintas líneas base de un documento
Producto de Trabajo [6]: Es todo elemento tangible que resulte en función de realizar un proyecto, actividad o tarea. Ej. Requisitos de clientes, plan de proyecto, especificaciones funcionales, documentos de diseño, código fuente y objeto, manual del usuario, instrucciones de instalación, planes de pruebas, etc
Puntos de Función: Técnica estándar utilizada para la medición del tamaño del software
R Requerimiento: Atributo vital y necesarios en un sistema, es una declaración que identifica un factor de características, capacidades o calidad de un sistema para que tenga valor y utilidad para un cliente o
S.G.P.M.SRS
usuario final
Requerimiento Completo [14]:
Requerimiento que describa completamente la funcionalidad a ser entregada, conteniendo toda la información necesaria para el desarrollador para que diseñe e implemente esa parte de la funcionalidad.
Si se sabe que no se tiene aún cierta información se puede usar PD (por determinar) como una manera de resaltar que faltan estas cosas, se deben resolver estas partes faltantes antes de proceder con la construcción de dicha porción.
Requerimiento Correcto [14]:
Requerimiento que describe la funcionalidad que se va a construir, para saber si es correcto primero debe saberse la fuente del requerimiento, si es un requerimiento para el usuario actual o de alto nivel del sistema. Un requerimiento de software que tenga conflictos con un requerimiento de un sistema padre, no es correcto.
Requerimiento Excelente [14]:
Es un requerimiento completo, correcto, factible, necesario, priorizable, no ambiguo y verificable.
Requerimiento Factible [14]:
Debe ser posible implementar cada requerimiento, sabiendo las limitaciones y capacidades del sistema y su entorno operacional. Para evitar especificar requerimientos que no sean obtenibles o factibles, se debe contar con un desarrollador o un analista de requerimientos durante el proceso de recolección de los mismos, con el fin de que este mencione lo que se puede hacer o no ya sea por restricciones técnicas o de costo.
Para esto son importantes el desarrollo incremental de la aplicación y los prototipos, que permiten evaluar la factibilidad de requerimientos.
Requerimiento Necesario [14]:
Cada requerimiento debe documentar una capacidad que el cliente realmente necesite o que se requiera para que el sistema se adapte a un requerimiento externo o un estandar. Cada requerimiento debe originarse de una fuente que tenga la autoridad de especificar requerimientos, bien sea por el mismo cliente, casos de uso, regla del negocio, etc.
S.G.P.M.SRS
Requerimiento No ambiguo [14]:
Todos los lectores de un requerimiento deben obtener una y solo una interpretación del mismo, por lo cual sabiendo que el lenguaje tiende a ser ambiguo, es importante que se escriban los requerimientos de forma simple, concisa, concreta y con un lenguaje apropiado según el usuario, por supuesto que además debe ser entendible.
Requerimiento Priorizable [14]:
Cada requerimiento funcional, característica o caso de uso debe tener asignada una prioridad de acuerdo a su importancia según el lanzamiento de un producto en particular. Si todos se consideran igual de importantes, será muy difícil para que el gerente del proyecto pueda responder efectivamente a estimaciones de costos o presupuesto, pérdida de personal, o nuevos requerimientos que salgan del desarrollo.
Requerimiento Verificable [14]:
Es importante desarrollar pruebas o usar otros métodos de verificación (como inspección o demostración) para determinar si un producto implementa apropiadamente (o no) cada requerimiento. Si un requerimiento no es verificable, determinar si está correctamente implementado o no, es solo cuestión de opinión y no de análisis objetivo. Los requerimientos que no sean completos, consistentes y no ambiguos, tampoco son verificables.
S S.D.D. [8]: Software Design Document. Es el documento resultado del proceso de diseño, describe prácticas recomendadas para describir los diseños de software y especifica la información que debe contener, además de recomendar la manera en que debe organizarse.
S.P.M.P. [6]: Software Project Management Plan: Es el documento de Plan Para la Gestión de Proyectos de Software, en el cual se mostrará el plan para la gestión definiendo funciones técnicas y de gestión de proyectos, actividades y tareas que sean requeridas para satisfacer los requisitos de un proyecto de Software.
S.R.S. [8]: Software Requirements Specification. Es la especificación de las funciones que realiza un determinado producto de software, programa o conjunto de programas en un determinado entorno. Este documento puede desarrollarlo personal representativo de la parte suministradora, o
S.G.P.M.SRS
de la parte cliente; si bien es aconsejable la intervención de ambas partes.
Tabla 2: Definiciones, acrónimos y abreviaciones.
1.4 Referencias
[1] Definición de IDE: http://www.alegsa.com.ar/Dic/ide.php
[2] Ian sommerville, Ingeniería de software, Séptima edición, Pearson, 2005.
[3] Bernd Bruegge & Allen H. Dutoit, Object Oriented Software Engineering. Conquering Complex and Changing Systems, Prentice Hall, 1999.
[4] Ralph R. Young, The Requirements Engineering Handbook, 2004. [5] George Stepanek, Software Project Secrets, Apress, 2005. [6] TORRES, Miguel. Plantilla SPMP IronWorks. Documento Disponible en: http://sophia.javeriana.edu.co/~metorres/ SPMP - Norma IEEE 1058.1 para la planificación de proyectos de
software: www.pgsi-g5.googlecode.com/files/T9899_ICaballero.pdf
[7] Definición de IEEE tomada de: http://www.ieee.org/web/aboutus/home/index.html
[8] Definición de SRS y SDD. http://www.navegapolis.net/files/cis/CIS_1_05.pdf
[9] IEEE Std. 730-1-1-1995 Software Quality Assurance Plan. [10] Ronald Kirk Kandt, Software Engineering Quality Practices, Taylor & Francis Group,
2006. [11] Susan Snedaker, How to Cheat at IT Project Management,
Syngress, 2005 [12] Roger S. Pressman, Ingeniería del Software, McGraw-Hill, 2002. [13] Dorota Huizinga / Adam Kolawa, Automated Defect Prevention, Wiley, 2007. [14] Karl E. Wiegers, Software Requirements 2nd Edition, Microsoft Press, 2003 [15] Jag Sodhi & Prince Sodhi, IT Project Management Handbook, Management
Concepts, Inc, 2002 [16] Entrepreneur Press and Sid Kemp, Project Management Made Easy, 2006. [17] Jennifer Greene & Andrew Stellman, Head First Pmp, O Reilly, 2009. [18] Stephen Withall, Software Requirement Patterns, Microsoft Press, 2007 [19] Ana Maria Ortiz, SRS y Calidad de Requerimientos. [20] Luis Carlos Diaz - Miguel Torres, Las Buenas Prácticas de la Ingeniería de
Requerimientos y los Mapas Mentales como Instrumentos de Apoyo al Proceso de
S.G.P.M.SRS
Software, 2007 [21] Ian F. Alexander / Richard Stevens, Writing Better Requirements, Pearson, 2002 [22] Suzanne Robertson / James Robertson, Mastering the
Requirements Process 2nd Edition, Addison Wesley, 2006 [23] Aybüke Aurum and Claes Wohlin, Engineering and Managing
Software Requirements, Springer, 1998 [24] Proyecto SMARTRUMMY-Q, Grupo SmartWare, 2008. [25] Proyecto Tiger Rummy, Grupo Albine, 2008. [26] Definición de Scrabble. Disponible en: http://es.wikipedia.org/wiki/Scrabble [27] Construx Software Builders, Inc, 2000- 2002. Disponible en: www.construx.com
1.5 Apreciación Global
En el SRS se presenta la documentación de los requerimientos funcionales que describen el comportamiento esperado de la aplicación WorDomination, y la correcta certificación de calidad de estos, mediante el uso de las listas de chequeo de Construx. [27]
Por lo tanto, este SRS debería usarse para un correcto desarrollo, pruebas, aseguramiento de la calidad, gestión de proyecto y funcionalidades del proyecto en general. [14]
Para finalizar, es importante mencionar que el SRS incluye también los requerimientos no funcionales que ayudan a la obtención de objetivos del proyecto y descripciones de atributos de calidad del producto desarrollado a partir del mismo, los cuales amplían la descripción de atributos de calidad características que debe manejar (usabilidad, portabilidad, integridad, eficiencia y robustez), proporcionando funcionalidades importantes para el cliente o los desarrolladores; a su vez otros requerimientos no funcionales describen interfaces externas entre el sistema y el mundo externo, al igual que el diseño e implementación de restricciones. [14]
S.G.P.M.SRS
Con la finalidad de lograr satisfactoriamente lo propuesto, en general S.G.P.M busca la correcta ingeniería de requerimientos, o ciencia encargada de encontrar, establecer y documentar los requerimientos de software, a través de un proceso de 4 fases (Recolección, Análisis y Negociaciones, Documentación y Validación) el cual se puede observar en el proceso de Ingeniería de Requerimientos (ver Sección 2.4) y su correcta especificación mediante las características que debería tener un requerimiento excelente (completo, correcto, factible, necesario, priorizable, no ambiguo y verificable), logrando a su vez que el SRS sea completo, consistente, modificable y trazable a través de las listas de chequeo ya descritas [14], [20], [27].
Para observar las descripciones detalladas de requerimientos del sistema, se puede observar la sección 3 – Requerimientos Específicos.
S.G.P.M.SRS
2 Ciclo de Vida de Requerimientos
El Ciclo de Vida de Requerimientos es el encargado de exponer la forma en que se lleva a cabo uno de los procedimientos más importantes del SRS: el Proceso de Requerimientos, que involucra el entendimiento de necesidades y expectativas del cliente (identificación y obtención de requerimientos – ver Sección 2.4.1), análisis y especificación de requerimientos (ver Sección 2.4.2), priorización y ubicación (ver sección 2.4.3), trazabilidad y verificación y validación de los mismos (ver Secciones 2.4.4 y 2.4.5 respectivamente), con el objetivo de tener une enfoque basado en la calidad del producto. [4]
2.1 Identificación de Stakeholders
Para identificar satisfactoriamente a los stakeholders del proyecto, hay que tener en cuenta que son todas aquellas personas que tienen algún interés en el producto, por supuesto se incluye al cliente (o persona que paga por su desarrollo), los usuarios finales que operan el producto, otras personas que influencien el proyecto o con el conocimiento necesario para reunir requerimientos para el producto. [4]
Es importante tenerlos en cuenta puesto que ellos mismos se encargan de proveer el conocimiento necesario para realizar un efectivo Proceso de Requerimientos. Según SGPM los stakeholders serían:
S.G.P.M.SRS
Cliente (Miguel Torres): Es la persona encargada de definir los requerimientos necesarios desde el comienzo del proyecto y quien aprueba si se realizó un correcto proceso de Requerimientos e implementación.
Equipo de Desarrollo (SGPM): Grupo encargado de definir como se realizará el ciclo de vida de requerimientos mediante un Proceso de Requerimientos para la obtención de un producto de calidad.
Usuario Final: Es el actor que interactúa con el sistema y puede pertenecer a dos categorías: Administrador o Jugador normal.
2.2 Necesidades del usuario
En cuanto a las necesidades del usuario se asumen las que se propusieron desde el comienzo del semestre, por lo tanto afirmando así que entre estas necesidades se encuentran:
1) La aplicación debe manejar una arquitectura cliente – servidor.
2) La aplicación debe tener uso de persistencia.
3) La aplicación debe utilizar interfaz gráfica de usuario.
4) La aplicación debe correr en las máquinas del Departamento de Ineniería de Sistemas de la Pontificia Universidad Javeriana.
2.3 Participación por roles
Con el fin de generar una mayor eficiencia en el trabajo del grupo con respecto a la elaboración del documento, para lo cual se ha visto la necesidad de generar tareas especificas a los integrantes de acuerdo a sus roles, como se verá a continuación:
S.G.P.M.SRS
2.4 Proceso de requerimientos
Teniendo en cuenta el concepto básico de requerimiento definido como una característica necesaria que debe poseer el sistema que se desea crear, S.G.P.M utilizara un proceso de requerimientos planteado por Karl E. Wiegers [NºReferencia], con el fin de tener un debido manejo y administración de cada uno de los requerimientos que surjan alrededor del proyecto
[NºReferencia] Wiegers, Karl E. More About Software Requirements. Microsoft. 2006
2.4.1 Identificación de Requerimientos
Oscar Gomez (Gerente y Arquitecto)
Sera responsable de seguir un buen proceso en la elaboracion del documento
Andres Fajardo (Administrador de Configuraciones y documentacion )
Estara a cargo de la actualizacion de versiones en documentos y requerimientos
Wilson Perez (Director Programacion)
Sera responsable por el desarrollo de los requerimientos
Andres Hidalgo ( Director Calidad)
Estara a cargo, hacer cumplir los criterios de calidad en requerimientos y documento SRS en general.
S.G.P.M.SRS
La identificación de Requerimientos es el primer paso dentro de nuestro proceso, y para ello S.G.P.M tomara como base las reglas de juego se Scrabble (Ver Sección 10 SPMP) y los casos de uso propuestos (Ver Documento Casos de Uso), como apoyo para la estructuración y elaboración de los requerimientos del proyecto. La identificación de requerimientos también estará marcada por la división en categorías de cada uno de los requerimientos(Ver ilustración Categoria de Requerimientos), el cual se podrá identificar de acuerdo a los dos últimos números que tenga el Id de cada requerimiento como se observa en la siguiente tabla.
Identificación Especificación
R##01 Negocio
R##02 Usuario
R##03 Sistema
R##04 No funcionales
Requerimientos
S.G.P.M.SRS
Requerimientos de negocio: Representan a gran nivel los objetivos de la organización y/o las solicitudes del cliente con respecto al sistema o producto [http://sophia.javeriana.edu.co/~metorres/, Presentación Requerimientos]Requerimientos de Usuario: Describen las tareas de los usuarios que deben poder ser realizadas con el producto [http://sophia.javeriana.edu.co/~metorres/, Presentación Requerimientos]Requerimientos de Sistema: Definen la funcionalidad del software que los desarrolladores deben construir dentro del producto para permitir al usuario realizar sus tareas y satisfacer los Requerimientos del Negocio. [ http://sophia.javeriana.edu.co/~metorres/, Presentación Requerimientos]Requerimientos no Funcionales: Definen los atributos que le indican al sistema como realizar su trabajo (eficiencia, hardware, software, interfaces, usabilidad, etc.). Es el cómo, cuando y cuanto del que. [http://sophia.javeriana.edu.co/~metorres/, Presentación Requerimientos]
[Ian Sommerville 2000, Software Engineering, 6th Edition. Chapter 5]
Requerimientos del producto
Requerimientos no funcional
esRequerimi
entos organizaci
onales
Requerimientos
externos
Requerimientos éticos
Requerimientos de
interoperabilidad
Requerimientos
legislativos
Requerimientos de
seguridad
Requerimientos de
privacidad
Requerimientos de espacio
Requerimientos de
desempeño
Requerimientos de
usabilidad
Requerimientos de eficiencia
Requerimientos de fiabilidad
Requerimientos de
portabilidad
Requerimientos de entrega
Requerimientos de
implementación
Requerimientos de
estándares
S.G.P.M.SRS
Requerimientos del Producto: Este tipo de requerimientos especifican el comportamiento del producto; como los requerimientos de desempeño en la rapidez de ejecución del sistema y cuánta memoria se requiere; los de fiabilidad que fijan la tasa de fallas para que el sistema sea aceptable; los de portabilidad y los de usabilidad. [Tomado de : http://www.mitecnologico.com/Main/EspecificacionesDeRequerimientos]
Requerimientos Organizacionales: Este tipo de requerimientos se derivan de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador: estándares en los procesos que deben utilizarse; requerimientos de implementación como los lenguajes de programación o el método de diseño a utilizar, y los requerimientos de entrega que especifican cuándo se entregará el producto y su documentación. [Tomado de : http://www.mitecnologico.com/Main/EspecificacionesDeRequerimientos]
Requerimientos Externos: Este tipo de requerimientos Se derivan de los factores externos al sistema y de su proceso de desarrollo. Incluyen los requerimientos de interoperabilidad que definen la manera en que el sistema interactúa con los otros sistemas de la organización; los requerimientos legales que deben seguirse para asegurar que el sistema opere dentro de la ley, y los requerimientos éticos. Estos últimos son impuestos al sistema para asegurar que será aceptado por el usuario y por el público en general. [Tomado de : http://www.mitecnologico.com/Main/EspecificacionesDeRequerimientos]
2.4.2 Especificación de Requerimientos
Con base en técnicas de especificación [55] buscaremos la mejor clasificación, búsqueda y un análisis completo de los requerimientos, teniendo como base sus diferentes etapas de ejecución, la trazabilidad y riesgos de estos con base en este documento. En el grafico se mostrara las etapas y su posible funcionalidad.
S.G.P.M.SRS
2.4.3 Priorización de Requerimientos
Se baso en el uso de técnicas cognitivas planteadas por Nadina Martínez en su escrito Gestión de Preferencias de Requerimientos que nos permite tener un enfoque y dar la debida clasificación, prioridad a cada funcionalidad a nuestro sistema para un mejor desarrollo
Inicio de Juego Como Iniciar y finalizar la aplicaciónPosibles opciones de inicios si hay errores
Información ClientesRequerimientos Perfil e información del UsuarioEstadísticas de juegos
Opciones Juego
Requerimientos asociados a la partida(Eliminar, guardar ,crear)Requerimientos utilizados directamente en la acción de opciones del juego antes del inicio de cada partida
Modo JuegoRequerimientos Implementados en la validación de un juego mientras se ejecuta la funcionalidad (mover, poner, coger ,quitar, etc.)
No Funcionales
Requerimientos Relacionados con la velocidad e implantación del sistema(PC).Conexiones de red y formas no esenciales que no afectan al juego
S.G.P.M.SRS
A) Identificación de Requerimientos y Su nivel de Valorización general
Identificación General: Los requerimientos identificados anteriormente deberán ser vueltos a contemplar para poder valorar que tan importante será para su implementación y que aspecto general influirá en el proceso. [53]
Valorización General: Con base en lo anterior después de una breve revisión general daremos prioridad a las exigencias del cliente, siendo estas Persistencia, Arquitectura y GUI, con base es estas tres condiciones daremos importancia a cada requerimiento identificado y descartar los que no serian de una funcionalidad en el sistema. [53]
B) Prioridad según el RolVisión por cada rol: Aquí usaremos el inciso A para que cada miembro del grupo SGPM pueda valorar los requerimientos ya establecidos y su prioridad, pero dando una valoración individual para contrarrestar y clasificar con la ya dada generalmente, teniendo como fundamento dos
Indentificacion
de Requerimientos
y Su nivel de Valoriza
ción general
Nivel de
Prioridad
segun El rol
Priorida
d Fina
l
S.G.P.M.SRS
puntos de valoración y así priorizar tanto individualmente como generalizado, lo cual nos brindara un mejor visión.
C) Prioridad FinalPara esta relación usaremos las variables anteriores para poder implementar la valorización más acertada para cada requerimiento, siendo estos:
Valorización General.
Valorización Rol.
Prioridad final.
Valorización General. Se tendrá en cuenta la discusión de cada requerimiento de un modo neutral.[53]
Punto de vista de cada persona como si fuera cliente. [53]
Discusión con el grupo de los requerimientos más importantes. [53]
Valorización Rol. Tendremos un valor para cada miembro según el requerimiento con una valoración de -5 a 5. [53]
Cada miembro dará un valor clasificatorio. [53]
Prioridad final. En esta clasificación se dará la priorización final de los requerimientos y hará una matriz de conflicto asiendo las
S.G.P.M.SRS
debidas comparaciones. [53] Los resultados serán dados por
Valorización General y final, debido a que es de global a especifico.[53]
La priorización de requerimientos se dará de una clasificación de 1 a 10 siendo el mayor más importante. La formula seria:
Gestión de Preferencias de Requerimientos basada en
Técnicas Cognitivas
Nadina Martínez Carod and Alejandra Cechich.[53]encontrar http://www.cacic2007.unne.edu.ar/papers/035.pdf
http://ing.de.soft1.googlepages.com/07-SeleccionYPriorizacion.pdf[54]
http://readyset.tigris.org/nonav/es/templates/feature-set.html[55]
2.4.4 Trazabilidad
La trazabilidad es un factor clave para la gestión de requerimientos, y se refiere a la posibilidad que se tiene de perseguir o monitorear el ciclo que tiene un
Valorización Rol(Clasificación Negativa o Positiva)
Prioridad Final
S.G.P.M.SRS
requerimiento en el desarrollo del proyecto, estableciendo relaciones entre dos o más procesos de software [17]. Esta trazabilidad se puede realizar de dos formas:
Hacia adelante Hacia atrás
Figura trazabilidad hacia adelante
Figura trazabilidad hacia atrás
Para poder realizar este seguimiento S.G.P.M se ayudara de herramientas como son los casos de uso (ver documento Casos de uso), el modelo de dominio (ver seccion3.5), el SPMP (ver documento SPMP), y los requerimientos asociados que tenga cada uno.
Así mismo S.G.P.M decidió enfocarse a un estilo de trazabilidad vertical que se garantiza que todos los requerimientos que van a ser diseñados e implementados, pasen por un conjunto de pruebas y planes ya establecidos en el SPMP, como el plan de riesgos, plan de control de requerimientos, plan de verificación y validación (ver Documento SPMP)[17] .
Monitoreo de la
implentacion del
requerimeinto
Origen de los requerimiento
s
S.G.P.M.SRS
[17] trazabilidad en proyectos de software Manolo Sangoquiza http://www.slideshare.net/barcampquito/trazabilidad-en-proyectos-de-software
2.4.5 Validación y verificación.
S.G.P.M seguirá el plan de control de requerimientos estipulado en el S.P.M.P (ver documento S.P.M.P). Así mismo se ayudara de las siguientes herramientas:
Usar listas de chequeo ofrecidas por Construx, que permitirá verificar que cada uno de los requerimientos cumpla con una serie de características.
Trazabilidad (ver sección 2.4.4). Plantilla modificada Volere, para la documentación de los requerimientos.
2.5 Administración de requerimientos
2.6 Interfaces
Con el fin de identificar interacciones entre interfaces del sistema (bien sea entre usuarios, hardware, protocolos y distintos software usados) remítase al punto 3 (ver Secciones 3.1 a 3.5).
S.G.P.M.SRS
3 Descripción Global
3.1 Perspectiva del producto
3.1.1 Interfaces con el sistema
WordDomination no tendrá ninguna clase de dependencia con otro sistema externo, ni con otro producto, es una aplicación completamente nueva, por lo cual no reemplazara a otro sistema, así mismo no se crearan interfaces para nuevos componentes.
3.1.2 Interfaces con el usuario
En la siguiente tabla se especifican las diferentes interfaces con el usuario.
INTERFACES
TECLADO Dispositivo utilizado para el ingreso de caracteres por parte del usuario, para la formación de palabras en el juego
RATON Dispositivo utilizado para la interacción de las diferentes interfaces y captura de datos en el juego
MONITOR Dispositivo utilizado para la visualización de la interfaz por parte del usuario. Resolución mínima 800x 600 pixeles
INTERFAZ GUI Se utilizaran los API’S de las bibliotecas graficas SWING, AWT
TARJETA GRAFICA Dispositivo utilizado para la trasmisión de información grafica al monitor. Resolución mínima de 800 x 600 pixeles
TARJETA DE RED Dispositivo utilizado para la conexión entre maquinas(Redes de área local). Velocidad requerida 2 Mbps
S.G.P.M.SRS
3.1.3 Interfaces con el Hardware
Como se había especificado ya por el cliente, los productos de SGPM buscaran la satisfacción y calidad del producto en la parte de hardware, cumpliendo estos con los requerimientos funcionales y no funcionales encontrados. Por motivos de exigencia del cliente la aplicación será de una arquitectura Cliente/Servidor por tal motivo para una mejor interacción y cumplimiento, se deberá usar protocolos de comunicación como los aquí nombrados y escogidos:
S.G.P.M.SRS
2
La eleccion de escoger este protocolo fue por la busqueda de la simplicidad , funcionalidad y estandarizacion que se manejara, algunas causas de nuestra decision La Arquitectura exigida es cliente-servidor, en lo cual es tipo de protocolo hace mas simple su manejo.[1]Su estandarizacion permitara implementacion en diferentes Laptop o PC, para las conexiones exigidas.[1]Brindara para la implementacion seguridad en la entrada y salida de informacion.[1]Wordomination tendra la simplicida de conexiones locales para cuatro Computadores en una conexion local(Host).[1]Dara la opcion de trasmision de datos con la web, si haci se pide implementar en versiones mas completas.[1]
Protocolo 8080 HttpEste protocolo permitira implementar el requerimiento de arquitectura cliente-servidor , este permite la trasmicion de datos como se pide y se ha documentado.[2]Protocolo 3036Este protocolo permitara la comunicacion con la bases de datos(Diccionario de datos) que nos permitara comunicarno para la informacion requeridad por el juego wordomination.[3],[2]Protocolo 31337Dara la posibilidad de acceder y controlar la aplicacion externamente, ya que se basa en el modelo de cliente-servidor para que funcione.[3][2]
La conexion fisica del sistema se dara gracias a la Cableado UTP (Unshielded Twisted Pai), este tipo de conexion nos permitira iteractura LAN Ethernet y fast Ethernet, segun lo necesitado, ya que la velocidad y eficiencia estara dada en el transcurso del desarrollo. Las conexiones tendremo moden,router y demas tecnologia de conexiones que se necesiten.[4],[5]
S.G.P.M.SRS
3.1.4 Interfaces con el Software
La aplicación WordDomination será implementada en java, utilizando diferentes API’S como JFM (Java Media FrameWork) para el manejo de audio y video, SWING para la interfaz grafica con ayuda de JavaFx útil para aplicaciones multimedia.
Aunque el desarrollo de WordDomination y sus diferentes pruebas fueron realizadas en el sistema operativo Windows XP, no debería existir ninguna clase de problema con otras versiones como: Windows Vista o Windows NT, es mas en Linux debe funcionar, siempre y cuando cada uno de estos cuente con una maquina virtual de java (JVM) con una versión mayor a la JDK 1.5 preferiblemente. Para ver en más detalle cada uno de estos componentes se adjunta la siguiente tabla:
Protocolo de Comunicación
TCP/IP
Puerto TCP
S.G.P.M.SRS
Producto de
Software
Propósito de Uso Versión Fuente
Windows Windows es el sistema operativo más usado del mundo, basado y orientado a la interfaz grafica lo cual permitirá una interacción amigable con el usuario
Windows XP
Windows Vista
Windows NT
MicroSoft Windows
www.microsoft.com/spain/windows/
JDK Permitirá la creación , desarrollo y ejecución del la aplicación WordDominatio
A partir de la versión 5.0 Sun MicroSystem
http://java.sun.com/javase
JavaFx Permitirá creación de una Interfaz con una calidad grafica dinámica 2D o 3D
Versión 1.2 SunMicroSystem
http://java.sun.com/javafx/JMF Permitirá la adaptación de tecnologías
de audio y video , para la aplicaciónVersión 2.1.1e SunMicroSystem
http://java.sun.com/javase/technologies/desktop/media/jmf/
Tabla 3: Interfaces con el Software
S.G.P.M.SRS
3.1.5 Interfaces de Comunicación
Debido a que el Wordomination utilizara arquitectura cliente-servidor, por claro habla que utilizar protocolos de red, en este caso TCP/IP, creando bajo este estándar conexiones LAN, para que se la interacción especificada, una restricción para la conexión es que esta debe estar libre de cualquier corta fuegos para así pueda ocurrir la trasferencia de datos y operaciones (ver más. 2.1.3 Interfaces de Hardware).
3.1.6 Restricciones de Memoria
Para la perfecta ejecución de WorDomination, se considero la total necesidad de consumo de memoria por parte del modulo para la implementación del diccionario en español, puesto que para ofrecer un excelente rendimiento por parte de la aplicación en tiempos de respuesta es primordial hacer un alto consumo de memoria. Normalmente un diccionario para WorDomination incluye entre 110.000 a 150.000 palabras, para las cuales se ha calculado una capacidad de memoria de no menos de 150 a 200 Mb de RAM. Por otro lado, también será necesario que los equipos cumplan los siguientes requisitos, para poder correr todos los programas sobre los que WorDomination se aplicara:
Requisitos del Equipo512 MB de RAMDisco Duro de 80 MBProcesador 1.6 GH
Requisitos de SoftwareNetBeans :256 MBSQL Developer: 106 MB
S.G.P.M.SRS
3.1.7 Operaciones
Dentro de WorDomination se encontrara un rol de jugador que podra ingresar al juego de dos modos distintos. Estos modos son el de Administrador y el modo de Usuario. A continuacion se mostrarán las acciones que podran realizar cada uno de estos:
Wordomination no tendra ningun momento de inactividad en el momento de juego, ya que el juego sera ejecutado por los jugadores para iniciar una partida o las demas opciones. S.G.P.M no ofrecera procesos de recuperacion, en caso de que se produzca algun problema en medio de la ejecucion, como la caida del sistema en la que normalmente no se puede recueperar ningun dato que se haya ingresado con anticipacion.
AdministradorCrear PartidasLanzar PartidaCargar partida
UsuariosCrear JugadorBorrar JugadorVer Detalles JugadorAñadir PalabraEliminar PalabraVer puntajeSalvar PartidaCambiar FichasPasar TurnoDeshacer JugadaValidar JugadaColocar Ficha en el tableroQuitar ficha del tableroMover ficha en el tableroSalirVer Log
S.G.P.M.SRS
3.1.8 Requerimientos de Adaptación del Sitio
El funcionamiento de Wordomination, debe contemplar las necesidades que el cliente menciono en el acuerdo del proyecto, dentro de las cuales encontramos el hecho que el producto debe poder ejecutarse en las salas de facultad de ingeniería, en especial la Sala de Bases de Datos [NºREFERENCIA], el cual es el lugar el lugar más idóneo para realizar la presentación final. El lugar debe contar con los componentes estipulados en las interfaces de Software (Ver sección 2.1.4 Interfaces de Software) de este documento, las cuales estarán incluidos dentro de un paquete con su respectivo manual, listo para utilizarse en el momento de la ejecución de Wordomination.
[NºREFERENCIA]Laboratorio de Bases de Datos, consultado: 05 de Septiembre de 2009, Disponible en: http://ingenierias.javeriana.edu.co/portal/page/portal/facultad_ingenieria/espanol/sistemas/laboratorios/TAB839315?tab=laboratorios
3.2 Funciones del Producto
Esta sección hace referencia a las múltiples funcionalidades que contendrá el producto final del juego WorDomination, para una mejor comprensión del juego por parte del cliente, el equipo de S.G.P.M, o cualquier otra persona que lo quiera conocer. Para tener una mayor información acerca de las Funciones Del Producto, remítase al Documento de Casos de Uso.
3.3 Características del Usuario
Los Usuarios de la aplicación podrá ser cualquier persona que tenga un pleno interés en el mundo de WorlDomination, y que además desee una aplicación en la cual pueda jugar diferentes partidas con una variedad de usuarios, ya sea contra la maquina misma (el computador) o en solitario si así el lo desea.
El sistema deberá ser muy intuitivo, de tal forma que permita su uso por cualquier tipo de usuario, es decir, que no solo estará dirigido para personas expertas en el manejo de la computación sino también para aquellos que aun son inexpertos. Para poder lograr esto los desarrolladores de S.G.P.M harán lo
S.G.P.M.SRS
posible por diseñar pantallas que permitan el fácil manejo de la intuición del usuario, y evitara un gran número de opciones sobre las ventanas con el fin de hacer difícil su uso.
Por otro lado, no será necesario que el usuario domine 100% el juego de WorDomination, pues contara con las herramientas básicas para su buen uso y fácil manejo como lo son el uso de manuales y reglas de juego que estarán a su alcance en todo momento.
A continuación se ha definido una estructura que contendrá las características básicas que debe poseer el jugador, para hacer más viable y satisfactorio el uso del juego: [Fowler, M.: “UML Destilled”, segunda edición, Addison Wesley Longman Inc, 2000.]
Actor Nombre del Actor
Descripción Descripción corta de la característica, responsabilidad o rol que tendrá el actor
Comentarios Información relevante que se deba mencionar
Teniendo en cuenta el cuadro anterior, presentaremos las características del usuario para WorDomination.
Actor Jugador
Descripción El usuario debe Saber leer y escribir, tener un vocabulario, entendimiento aceptable, con el fin de poder crear o poner palabras reales en el momento que tenga el turno dentro del juego.
Comentarios El usuario debe tener un nivel de intelecto y entendimiento aceptable, para vencer y no dejarse ganar.
S.G.P.M.SRS
Actor Jugador
Descripción El usuario debe tener conocimientos básicos de computación (Manejo de Sistema operativo Windows XP) y de los accesorios básicos como teclado y mouse.
Comentarios El producto no brinda ayuda en el manejo del Sistema Operativo.
Actor Jugador
Descripción El usuario debe poderse desenvolver en la web, por si necesita buscar alguna palabra de la cual no se sienta seguro respecto a su significado por medio de algún buscador.
Comentarios Ninguno
Actor Jugador
Descripción No es de total relevancia, pero sería de gran ayuda tener cierta experiencia o conocimiento en juegos de mesa.
Comentarios Ninguno
3.4 Restricciones
Es importante que el usuario tenga en cuenta las restricciones con las que el WorDomination será creado, con la finalidad de un perfecto funcionamiento dentro de los requisitos exigidos por el cliente, para ello S.G.P.M ha realizado una lista con las siguientes restricciones:
S.G.P.M.SRS
WorDomination estará regido 100% por las reglas del juego de mesa Scrabble, al cual no se le ha hecho ningún tipo de modificación para mantener su esencia natural ante el usuario.
El juego manejara únicamente el idioma español para su ejecución y desarrollo, manuales y demás documentos.
WorDomination no contara con la característica de ser tolerante a fallos, es decir, que si se llega a presentar una situación en la que el juego se vea afectado de forma total, este no podrá recuperar ningún tipo de dato que haya sido ingresado, jugadas, puntos ganados por los jugadores de tal forma que será necesario iniciar de 0 el juego.
Las especificaciones mínimas de hardware se podrán ver en la sección 2.1.6 Restricciones de memoria y en la sección 3.1.2 Interfaces con el Hardware.
De igual forma se podrán encontrar las especificaciones mínimas de Software en la sección 2.1.6 Restricciones de memoria y en la sección 3.1.3 Interfaces con el Software, en donde encontraremos los IDE’s y los API’s que se manejaran.
Teniendo en cuenta que el sistema se realizara sobre software libre, esto permitirá que el juego se corra sobre cualquier sistema operativo. Sin embargo, tanto el desarrollo como las pruebas que se realicen será sobre el sistema operativo Windows XP.
[NºREFERENCIA]Requisitos del Sistema, Consultado: 05 de Septiembre de 2009, Disponible en: http:// www.navegapolis.net/files/blog/formato_ieee1362.doc
3.5 Modelo del Dominio
Esta sección del documento debe reflejar el análisis inicial realizado al sistema a desarrollar, mediante la presentación del Diagrama del Modelo del Dominio y la documentación asociada.
S.G.P.M.SRS
Antes de especificar como documentar un diagrama del modelo del domino es importante dar las definiciones otorgadas por las organizaciones más importantes para la ingeniería de software, la siguiente tabla muestra dichas definiciones:
Organización / Autor Definición
Construx El modelo del dominio define un grupo de información que debe ser almacenado en el sistema, y las relaciones entre estos
grupos de información. El modelo contiene al menos una lista de objetos
del negocio, entidades de datos o clases (dichos objetos deben tener sus
relaciones). El modelo del domino detallado debe tener también atributos para cada entidad del modelo sea una clase, una entidad de datos o un objeto
del negocio.
Flower 96 Es una representación visual de las clases conceptuales u objetos del mundo real en un dominio de interés [10]. También se les denomina modelos conceptuales.
Larman El modelo del domino podría considerarse como un diccionario visual
de las abstracciones relevantes, vocabulario del dominio e información
del dominio.
Tabla 4: Definiciones del Modelo de Dominio
Finalmente Larman termina con una conclusión muy importante para entender el porqué de un modelo del dominio. “LOS MODELOS DEL DOMINIO NO SON COMPONENTES DE SOFTWARE, el modelo del dominio es una representación de las cosas reales del mundo del dominio de interés” [11].
S.G.P.M.SRS
A continuación se presenta una forma para documentar los elementos en el diagrama del modelo del dominio.
ID Elemento del Dominio
Descripción
Atributos
Nombre Descripción Tipo de Dato
Objetivo
Tabla 5: Formato de documentación del Modelo del Dominio
S.G.P.M.SRS
Ilustración 1: Descripción documentación del modelo del dominio
3.6 Suposiciones y Dependencias
Lista de factores que afectan los requerimientos:
Suposiciones:
Se deben listar todas aquellas suposiciones que puedan llegar a afectar los requerimientos indicados en la sección 3. Estos pueden incluir componentes comerciales o de terceras personas que usted planea utilizar. Tenga en cuenta que el proyecto
Identificador único del elemento del dominio del problema.IDIndica el nombre del elemento del dominio del problema que será documentado.Elemento del Dominio
Contiene una breve descripción del elemento, se debe indicar el por qué del creación del mismo dentro del elemento del dominio.DescripciónDe acuerdo a los atributos del elemento escogido se debe tomar cada uno para documentarlos.AtributosNombre del atributo que se documentará.NombreDescripción del objetivo del atributo dentro del elemento.DescripciónDe acuerdo al lenguaje planeado para la implementaicon del sistema, establecer el tipo de dato que se le asignará al elemento.Tipo de DatoDescripción global acerca del elemento documentado con el fin de exponer su funcionalidad en el sistema.Objetivo
S.G.P.M.SRS
podría afectarse si estas suposiciones son incorrectas, no se comparten, o se cambian [1].
Ilustración 2: Suposiciones
Dependencias:
Ilustración 3: Dependencias [1]
Tener una maquina
virtual instalada
Una conexion a
internet
Cumplimiento de
especificacion de Hardware de
la seccion 2.4
Restricciones
Que el cliente no haga cambios
significaticos en los
requerimientos
Previa instalacion y puesta en
funcionamiento de la base de
datos del servidor
Velocidad de la red, para obtener un buen
funcionamiento de la aplicacion en cuanto a tiempos de respuesta
Cambio de alguna de las reglas que riguen la
aplicacion
Factores externos, tales como componentes de software que usted se proponga reutilizar de
otro proyecto
S.G.P.M.SRS
4 Requerimientos Específicos
No. Requerimiento
Número de Identificación de requerimiento. Ver Error: Reference source not found
Versión 1.0 Primera Versión del Requerimiento
Tipo Error: Reference source not found Error: Referencesource not found, Error: Reference source not found
Nombre Nombre único del requerimiento. Visualización global del requerimiento.
Encargado Miembro de S.G.P.M que se encargará de implementar el requerimiento.
Descripción
Especificación detallada de la función del requerimiento dentro del sistema
Objetivo
Criterio de Medición
Es un criterio de aceptación o un caso de prueba.
Excepciones
Condiciones imprevisibles o cuando surgen situaciones en la que debe responder rápidamente. Evento no deseado que coloca al sistema fuera de su flujo normal puede ser causado por factores internos o externos
Observaciones/ Justificación
Razón de ser del requerimiento, utilidad para el sistema o aclaraciones acerca de su funcionamiento
Caso(s) Uso Relacionado
Casos de uso que se relacionan con el requerimiento.
Requerimiento(s)
Asociado(s)
Según el grafo (ver Error:Referencesource notfound Error:Referencesource notfound) son los
S.G.P.M.SRS
requerimientos antecesores y predecesores.
Trazabilidad
Riesgo Se mide según el número de requerimientos, que según el grafo de requerimientos (Error:Referencesource notfound Error:Reference sourcenot found), dependen de la implementación de este, es decir los requerimientos predecesores.
Prioridad Medida dada según las especificaciones expuestas en la Sección Error:Reference sourcenot found Error:Reference sourcenot found.
Costo Se mide en términos de personal y conocimiento necesarios para su implementación. Los rangos que se manejan son los siguientes:
Bajo Medio Alto
Estado
Esfuerzo Tiempo requerido para implementar el requerimiento. Se medirá en (días, meses, años)
Capa Capa de la arquitectura del sistema en la que se puede encontrar el requerimiento
S.G.P.M.SRS
TOKA referenciar
4.1 Requerimientos de Interfaces Externas
Las siguientes secciones se encuentran estrechamente relacionadas con la sección 2.1, la explicación de estas, busca simplemente profundizar un poco más en el contenido que debe tenerse en cuenta en el momento de llenar esta plantilla y definir los requerimientos de Interfaces Externas.
4.1.1 Interfaces con el Usuario
En esta sección se debe explicar la forma en que el sistema o que la aplicación permitirá la comunicación con el usuario o el cliente final. Esta comunicación incluye el ingreso de datos al sistema, la navegación por ventanas, la forma en que se muestran las interfaces (si las hay) y los diferentes dispositivos del computador en el que se va a utilizar el sistema en construcción.
Las interfaces deben contener la información lógica, por ejemplo formatos de pantalla requeridos (1024*768, 800*600,600*400), distribución de elementos en la pantalla o si tiene accesos rápidos con el teclado, por dar algunos ejemplos [12].
Algunas interfaces que se deben tener en cuenta son:
S.G.P.M.SRS
Ilustración 4: Interfaces con el Usurario
4.1.2 Interfaces con el Hardware
Puesto que el sistema que se planea desarrollar usualmente debe estar en capacidad de compartir datos e información con otros computadores y dispositivos (ejemplo dispositivos móviles), es necesario tener en cuenta la forma en que los componentes de software (aplicación o sistema) se comunicaran con los componentes de hardware de los otros dispositivos.
Las características del sistema a nivel de hardware que se deben tener en cuenta para el desarrollo, se enfocan en cómo se va a llevar a cabo la comunicación entre las máquinas de los usuarios participantes, algunas de estas interfaces son:
PANTALLLA TECLADO MOUSE INTERFAZ GUI
TARJETA GRAFICA
TARJETA DE RED
S.G.P.M.SRS
Ilustración 5: Interfaces de Hardware
Inter-conexión
TCP-UDP
PuertosUTP
Red HUB SWITCH
Protocolos de comunicación (TCP, UDP)
Puertos usados para la comunicación (si la aplicación es distribuida)
Cables de conexión (UTP)
Dispositivos de red (Routers, Hubs, Switches)
S.G.P.M.SRS
4.1.3 Interfaces con el Software
Para la ejecución del sistema apropiadamente es necesario tener algunos requerimientos mínimos de Software, esto es versión del sistema operativo, servidores de bases de datos y en general todos los productos de software que permitan la correcta utilización del sistema desarrollado. La Error: Reference source not found muestra un formato que puede usarse para explicar estas interfaces.
Ilustración 6: Interfaces con el Software
4.1.4 Interfaces de Comunicaciones
Las interfaces de comunicación son básicamente los métodos como se interconectan las diferentes aplicaciones en las máquinas en donde se ejecutan (nuevamente si la aplicación es distribuida), estas interfaces incluyen el tipo de red que se debe montar para la conexión de computadores (LAN, WAN) y los protocolos de comunicación usados (TCP). Para apoyar la información escrita en esta sección, se aconseja explicar cierta parte en la sección 3.1.2
4.2 Características del Producto de Software
Para lograr un mayor entendimiento en la especificación de los requerimientos por parte del cliente, S.G.P.M ha distribuido los requerimientos en las siguientes categorías, con el fin de establecer una mejor organización y gestión de estos:
S.G.P.M.SRS
2.2.1 Funcionalidad 1: Jugar
No. Requerimiento
R010303
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Cantidad de fichas
Encargado Wilson Perez
Descripción El sistema tiene que permitir a los jugadores tener la misma cantidad de fichas,(Ver reglas de WorDomination)
Objetivo Cada jugador pueda iniciar el juego igualitariamente
Criterio de Medición
Al iniciar el juego, el jugador debe poder armar palabras con el número de fichas entregadas.
Excepciones
Observaciones/ Justificación
Ninguna
Caso(s) Uso Relacionado
CU02, CU07
Requerimiento(s)
R020303
R0703
Requerimientos
JuegoAutenticacionAdministracionConsultas
S.G.P.M.SRS
CU12 Asociado(s)
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU02
CU07
CU12
Requerimientos Asociados
Reglas WorDominatio
n
(SPMP Sección 10.1)
Riesgo 2 Prioridad 12
Costo Medio
Estado Aprobado
Esfuerzo 2 días
Capa Servidor
3
No. Requerimiento
R020303
Versión 1.0
S.G.P.M.SRS
Tipo Funcionales-Modo de juego
Nombre Arrastre de fichas
Encargado Wilson Perez
Descripción El sistema tiene que verificar y mostrar las fichas (letras) que el jugador actual está arrastrando para formar su palabra a todos los demás jugadores.
Objetivo Para que cada jugador se pueda dar cuenta los movimientos de su rival, y los puntajes coincidan con las palabras armadas
Criterio de Medición
Todos los jugadores en su interfaz pueden ver los movimientos(arrastre de fichas) de sus rivales, puntajes se deben modificar.
Excepciones
Observaciones/ Justificación
Ninguna
Caso(s) Uso Relacionado
CU15, CU16
CU18
Requerimiento(s)
Asociado(s)
R080303, R090303, R010303
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU15
CU16
CU18
Requerimientos Asociados
S.G.P.M.SRS
Reglas WorDominatio
n
(SPMP Sección 10.1)
Riesgo 4 Prioridad 14
Costo Alto
Estado Aprobado
Esfuerzo 20 días
Capa Servidor
45
No. Requerimiento
R030303
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Mostrar tiempo
Encargado Wilson Perez
Descripción El sistema mostrara a cada jugador el tiempo máximo que tiene para ingresar la palabra al tablero.(2 minutos, Ver reglas de WorDomination)
Objetivo Para que cada jugador tenga un tiempo establecido, y los rivales no se queden esperando un tiempo indefinido
Criterio de Medición
Después de los 2 minutos, se debe ceder al turno al jugador correspondiente
S.G.P.M.SRS
Excepciones
Observaciones/ Justificación
Ninguna
Caso(s) Uso Relacionado
CU14
CU19
Requerimiento(s)
Asociado(s)
R0103703
R0103403
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU14
CU19
Requerimientos Asociados
Reglas WorDominatio
n
(SPMP Sección 10.1)
Riesgo 3 Prioridad 10
Costo MEDIO
Estado Aprobado
Esfuerzo 3 días
Capa Servidor
S.G.P.M.SRS
67
No. Requerimiento
R0403
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Añadir Palabra
Encargado Wilson Perez
Descripción El sistema deberá permitir al jugador añadir una palabra si la tiene lista antes de que se cumpla el límite de tiempo (2 minutos), esto se hará mediante un botón en la pantalla del jugador.
Objetivo Para que cada jugador tenga la posibilidad realizar su jugada en el tablero
Criterio de Medición
En el tablero el jugador podrá formar sus palabras durante dos minutos, contabilizándole su puntaje
Excepciones
Observaciones/ Justificación
Si no se realiza la jugada, pierde turno
Caso(s) Uso Relacionado
CU15
CU16
CU18
Requerimiento(s)
Asociado(s)
R0203, R0803, R0903, R1703
Trazabilidad Modelo de dominio
Documento Casos de uso:
S.G.P.M.SRS
CU15
CU16
CU18
Requerimientos Asociados
Reglas WorDominatio
n
(SPMP Sección 10.1)
Riesgo 4 Prioridad 15
Costo ALTO
Estado Aprobado
Esfuerzo 12 días
Capa Servidor
89
No. Requerimiento
R0503
Versión 1.0
Tipo Funcionales-Modo de juego
S.G.P.M.SRS
Nombre Eliminar Palabra
Encargado Wilson Perez
Descripción El sistema debe permitir eliminar la última palabra creada por el jugador
Objetivo Para que cada jugador tenga la posibilidad de reversar una mala jugada realizada durante la partida
Criterio de Medición
El sistema debe quitar del tablero la última palabra ingresada si el jugador así lo desea
Excepciones
Observaciones/ Justificación
Caso(s) Uso Relacionado
CU13
CU16
Requerimiento(s)
Asociado(s)
R1403
R0203
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU13
CU16
Requerimientos Asociados
Reglas WorDominatio
n
(SPMP Sección
S.G.P.M.SRS
10.1)
Riesgo 4 Prioridad 12
Costo ALTO
Estado Aprobado
Esfuerzo 12 días
Capa Servidor
1011121314
No. Requerimiento
R0603
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Utilizar comodin
Encargado Wilson Perez
Descripción El sistema debe permitir usar correctamente el comodín o fichas en blanco, las cuales se pueden utilizar en sustitución de cualquier letra.
Objetivo Para que cada jugador tenga la posibilidad de formar sus palabras con diferentes opciones
S.G.P.M.SRS
Criterio de Medición
El sistema debe validar la palabra incluidos los comodines y fichas en blanco y sumarlo al puntaje
Excepciones
Observaciones/ Justificación
Los comodines son de un número limitado (ver reglas WorDomination)
Caso(s) Uso Relacionado
CU18
CU16
Requerimiento(s)
Asociado(s)
R0203
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU18
CU16
Requerimientos Asociados
Reglas WorDominatio
n
(SPMP Sección 10.1)
Riesgo 3 Prioridad 9
Costo BAJO
S.G.P.M.SRS
Estado Aprobado
Esfuerzo 2 días
Capa Servidor
151617
No. Requerimiento
R0703
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Utilizar comodín
Encargado Wilson Pérez
Descripción El sistema debe darle 7 fichas (letras) de forma aleatoria a cada jugador al iniciar la partida.
Objetivo Para que cada jugador pueda iniciar el juego, con igualdad de condiciones
Criterio de Medición
A iniciar el juego cada jugador debe tener 7 fichas
Excepciones
Observaciones/ Justificación
Puede que ha determinado jugador al inicio con sus fichas pueda armar más fácil una palabra.
Caso(s) Uso Relacionado
CU02 Requerimiento(s)
Asociado(s)
R0103
R1303
Trazabilidad Modelo de
S.G.P.M.SRS
dominio
Documento Casos de uso:
CU02
Requerimientos Asociados
Reglas WorDominatio
n
(SPMP Sección 10.1)
Riesgo 2 Prioridad 8
Costo BAJO
Estado Aprobado
Esfuerzo 2 días
Capa Servidor
181920
No. R0803
S.G.P.M.SRS
Requerimiento
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Acomodar Fichas
Encargado Wilson Perez
Descripción El sistema debe permitir acomodar las fichas de forma vertical u horizontal para formar las palabras según le convenga al jugador, (Ver reglas de WorDomination).
Objetivo Para que cada jugador pueda armar sus respectivas palabras en el tablero
Criterio de Medición
El jugador debe poder formar sus palabras en el tablero, tanto en sentido vertical como horizontal
Excepciones
Observaciones/ Justificación
Las casillas donde se ponen las fichas deben ser validas(estar desocupadas)
Caso(s) Uso Relacionado
CU16
CU18
CU15
Requerimiento(s)
Asociado(s)
R0203
R0903
R0403
R1903
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU16
CU18
CU15
S.G.P.M.SRS
Requerimientos Asociados
Reglas WorDominatio
n
(SPMP Sección 10.1)
Riesgo 3 Prioridad 11
Costo MEDIO
Estado Aprobado
Esfuerzo 4 días
Capa Servidor
212223
No. Requerimiento
R0903
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Formar palabras Contiguas
Encargado Wilson Perez
S.G.P.M.SRS
Descripción El sistema debe permitir formar palabras completas si las fichas puestas de forma horizontal o vertical quedan en contacto con filas o columnas contiguas.
Objetivo Para que cada jugador pueda formar sus palabras completas y validar su jugada
Criterio de Medición
El sistema validara las palabras completas ingresadas por el usuario
Excepciones
Observaciones/ Justificación
Las casillas donde se ponen las fichas deben ser validas(estar desocupadas)
Caso(s) Uso Relacionado
CU16
CU18
CU15
Requerimiento(s)
Asociado(s)
R0203
R0803
R0403
R1903
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU16
CU18
CU15
Requerimientos Asociados
Reglas WorDominatio
n
(SPMP Sección
S.G.P.M.SRS
10.1)
Riesgo 3 Prioridad 11
Costo ALTO
Estado Aprobado
Esfuerzo 10 días
Capa Servidor
2425
No. Requerimiento
R1003
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Color casillas
Encargado Wilson Perez
Descripción El sistema debe tener en cuenta el color de cada casilla del tablero al momento de asignar la puntuación a un jugador, pues de acuerdo al color se puede dar un premio por letra o por palabra (Ver reglas de WorDomination)
Objetivo Para que cada jugador tenga la posibilidad de aumentar su puntaje dependiendo del color en el que forme sus palabras
Criterio de Medición
El puntaje de cada jugador se modificara dependiendo del color donde forme la palabras
Excepciones
S.G.P.M.SRS
Observaciones/ Justificación
Caso(s) Uso Relacionado
CU16
CU18
CU15
CU06
Requerimiento(s)
Asociado(s)
R0803
R0903
R1103
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU16
CU18
CU15
CU06
Requerimientos Asociados
Reglas WorDominatio
n
(SPMP Sección 10.1)
Riesgo 4 Prioridad 12
Costo ALTO
S.G.P.M.SRS
Estado Aprobado
Esfuerzo 10 días
Capa Servidor
26272829
No. Requerimiento
R1103
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Calcular puntaje
Encargado Wilson Perez
Descripción El sistema tiene que calcular el puntaje sumando el valor de las fichas utilizadas en las palabras que se hayan formado en ese turno, más los puntos obtenidos por haber puesto una o más fichas en casillas con premio.
Objetivo Para que el puntaje de cada jugador se vaya modificando dependiendo de las jugadas realizadas
Criterio de Medición
El sistema debe actualizar y mostrar el puntaje de cada jugador dependiendo de las palabras formadas en cada turno
Excepciones
Observaciones/ Justificación
Caso(s) Uso Relacionado
CU15 Requerimiento(s R1003
S.G.P.M.SRS
CU06 )
Asociado(s)
R1203
R1303
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU15
CU06
Requerimientos Asociados
Reglas WorDominatio
n
(SPMP Sección 10.1)
Riesgo 4 Prioridad 12
Costo ALTO
Estado Aprobado
Esfuerzo 10 días
Capa Servidor
3031
S.G.P.M.SRS
32
No. Requerimiento
R1203
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Ver Puntaje
Encargado Wilson Perez
Descripción El sistema debe permitir al jugador ver su puntaje durante la ejecución de cada partida
Objetivo Para que jugador tenga información de su puntaje durante el desarrollo de la partida
Criterio de Medición
El sistema debe actualizar y mostrar el puntaje en la pantalla de cada jugador, cada vez que se realice una jugada
Excepciones
Observaciones/ Justificación
Caso(s) Uso Relacionado
CU06
CU03
Requerimiento(s)
Asociado(s)
R1303
R1103
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU06
CU03
Requerimiento
S.G.P.M.SRS
s Asociados
Reglas WorDominatio
n
(SPMP Sección 10.1)
Riesgo 3 Prioridad 11
Costo MEDIO
Estado Aprobado
Esfuerzo 4 días
Capa Servidor
3334
No. Requerimiento
R1303
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Otorgar Puntos
Encargado Wilson Perez
Descripción El sistema otorgara la mayor cantidad de puntos (50 puntos), cuando el jugador haga uso de todas las 7 fichas para formar su palabra.
S.G.P.M.SRS
Objetivo Para que jugador tenga la posibilidad de aumentar su puntaje, pero con un mayor grado de dificultad
Criterio de Medición
El puntaje del jugador se modificara, cuando se usen las siete fichas en el tablero
Excepciones
Observaciones/ Justificación
Caso(s) Uso Relacionado
CU06
CU15
CU16
Requerimiento(s)
Asociado(s)
R1203
R1103
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU06
CU15
CU16
Requerimientos Asociados
Reglas WorDominatio
n
(SPMP Sección 10.1)
S.G.P.M.SRS
Riesgo 3 Prioridad 8
Costo MEDIO
Estado Aprobado
Esfuerzo 4 días
Capa Servidor
3536No. Requerimiento
R1403
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Cambiar Fichas de Jugador
Encargado Andrés Fajardo
Descripción El sistema debe permitir al usuario cambiar las fichas que el desee durante el tiempo de su turno (2 minutos) , máximo 3 veces por turno.
Objetivo Para que jugador tenga la posibilidad de cambiar sus fichas (máximo 3 veces por turno).
Criterio de Medición
Las fichas del jugador se cambiarán aleatoriamente durante su turno si este mismo lo pide, máximo cambiaran máximo 3 veces por turno.
Excepciones Las fichas escogidas por el jugador no se pudieron cambiar satisfactoriamente.
S.G.P.M.SRS
Observaciones/ Justificación
Caso(s) Uso Relacionado
CU12 Requerimiento(s)
Asociado(s)
R1403
R1503
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU12
Requerimientos Asociados
Reglas WorDomination
(SPMP Sección 10.1)
Riesgo 3 Prioridad 10
Costo MEDIO
Estado Aprobado
Esfuerzo 4 días
Capa Servidor
S.G.P.M.SRS
3738No. Requerimiento
R1503
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Cambiar fichas transaccionalmente.
Encargado Andrés Fajardo
Descripción Durante el momento de cambio de fichas, el jugador no podrá desistir de realizar esta acción, lo cual lo obliga a terminarla.
Objetivo Para asegurar que se realice el cambio de fichas por jugador correctamente.
Criterio de Medición
Una vez dada la orden de cambio de fichas, el procedimiento terminará completamente y correctamente.
Excepciones
Observaciones/ Justificación
Caso(s) Uso Relacionado
CU12 Requerimiento(s)
Asociado(s)
R1403
R1703
R2103
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU12
S.G.P.M.SRS
Requerimientos Asociados
Reglas WorDomination
(SPMP Sección 10.1)
Riesgo 3 Prioridad 8
Costo MEDIO
Estado Aprobado
Esfuerzo 4 días
Capa Servidor
3940No. Requerimiento
R1603
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Pasar a siguiente turno.
Encargado Andrés Fajardo
S.G.P.M.SRS
Descripción El sistema debe permitir pasar al turno siguiente, si el jugador en turno lo desea.
Objetivo Para asegurar que se pueda cambiar de turno, bien sea por no tener opciones disponibles o por que el jugador no sabe qué palabra ubicar en el tablero, así el tiempo límite no se haya cumplido.
Criterio de Medición
Una vez oprimido el botón de cambio de turno, el sistema cambia de turno satisfactoriamente.
Excepciones
Observaciones/ Justificación
Caso(s) Uso Relacionado
CU14 Requerimiento(s)
Asociado(s)
R1103
R1703
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU14
Requerimientos Asociados
Reglas WorDomination
(SPMP Sección 10.1)
S.G.P.M.SRS
Riesgo 3 Prioridad 7
Costo MEDIO
Estado Aprobado
Esfuerzo 4 días
Capa Servidor
4142No. Requerimiento
R1703
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Pasar a siguiente turno cuando tiempo límite se haya concluido.
Encargado Andrés Fajardo
Descripción El sistema deberá pasar al siguiente turno si el tiempo de la jugada llega a su límite (2 minutos, Ver reglas de WorDomination).
Objetivo Asegurar que cumplidos dos minutos, se realice un cambio automático de turno.
Criterio de Medición
Pasados 2 minutos, se cambia el turno del jugador satisfactoriamente.
Excepciones
Observaciones/ Justificación
S.G.P.M.SRS
Caso(s) Uso Relacionado
CU14 Requerimiento(s)
Asociado(s)
R1103
R1603
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU14
Requerimientos Asociados
Reglas WorDomination
(SPMP Sección 10.1)
Riesgo 3 Prioridad 8
Costo MEDIO
Estado Aprobado
Esfuerzo 4 días
Capa Servidor
43
S.G.P.M.SRS
44No. Requerimiento
R1803
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Mostrar Fichas.
Encargado Andrés Fajardo
Descripción El sistema debe mostrar en todo momento a los jugadores las fichas que quedan por jugar.
Objetivo Asegurar que el sistema muestre correctamente las fichas correspondientes a cada jugador por cada turno.
Criterio de Medición
Las fichas se muestran en la pantalla y el jugador puede usarlas para jugar posteriormente.
Excepciones
Observaciones/ Justificación
Caso(s) Uso Relacionado
CU11, CU12
CU16, CU17
CU18
Requerimiento(s)
Asociado(s)
R0103, R0203, R0603, R0703, R0803, R1403
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU11
S.G.P.M.SRS
CU12
CU16
CU17
CU18
Requerimientos Asociados
Reglas WorDomination
(SPMP Sección 10.1)
Riesgo 3 Prioridad 10
Costo MEDIO
Estado Aprobado
Esfuerzo 4 días
Capa Servidor
4546No. Requerimiento
R1903
Versión 1.0
S.G.P.M.SRS
Tipo Funcionales-Modo de juego
Nombre Validar jugadas.
Encargado Andrés Fajardo
Descripción El sistema debe validar las jugadas realizando una comparación de la palabra formada por el usuario con ayuda de un diccionario de palabras totalmente implementado dentro del sistema en una base de datos.
Objetivo Comprobar si el jugador obtuvo una respuesta correcta o no.
Criterio de Medición
Si el usuario tiene una respuesta correcta, se le informa en un mensaje diciéndole su correspondiente puntaje y continúa el siguiente turno.
Excepciones
Observaciones/ Justificación
Caso(s) Uso Relacionado
CU04, CU06, CU14, CU15
Requerimiento(s)
Asociado(s)
R0103, R0303, R0403, R0703, R0803, R0903, R1003, R1103, R1203, R1303
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU04, CU06, CU14, CU15
Requerimiento
S.G.P.M.SRS
s Asociados
Reglas WorDomination
(SPMP Sección 10.1)
Riesgo 3 Prioridad 15
Costo MEDIO
Estado Aprobado
Esfuerzo 4 días
Capa Servidor
4748No. Requerimiento
R2003
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Finalizar partida si ningún jugador ubicó palabras.
Encargado Andrés Fajardo
Descripción El sistema terminara la partida cuando ningún jugador pueda colocar mas fichas en el tablero bien sea por límite de tiempo o por palabras no válidas o incorrectas.
S.G.P.M.SRS
Objetivo Evitar más de dos turnos sin jugadas correctas.
Criterio de Medición
Si ninguno de los dos jugadores ubicó palabras en sus dos turnos consecutivos respectivos, el sistema finaliza correctamente y notifica puntajes y ganador.
Excepciones
Observaciones/ Justificación
Caso(s) Uso Relacionado
CU04, CU05,
CU14, CU15
Requerimiento(s)
Asociado(s)
R0103, R0303, R0403, R0703, R0803, R0903, R1003, R1103, R1203, R1303, R1603, R1703, R1903
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU04, CU05, CU14, CU15
Requerimientos Asociados
Reglas WorDomination
(SPMP Sección 10.1)
S.G.P.M.SRS
Riesgo 3 Prioridad 13
Costo MEDIO
Estado Aprobado
Esfuerzo 4 días
Capa Servidor
49505152No. Requerimiento
R2103
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Habilitar límite de tiempo en partida.
Encargado Andrés Fajardo
Descripción El sistema debe tener un límite de tiempo.
Objetivo Evitar partidas sin fin alguno, ni ganadores.
Criterio de Medición
La partida debe tener un tiempo límite (una hora).
Excepciones
Observaciones/ Justificación
S.G.P.M.SRS
Caso(s) Uso Relacionado
CU06
CU08
CU19
Requerimiento(s)
Asociado(s)
R2203
Trazabilidad Modelo de dominio
Documento Casos de uso:
R2203
Requerimientos Asociados
Reglas WorDomination
(SPMP Sección 10.1)
Riesgo 3 Prioridad 13
Costo MEDIO
Estado Aprobado
Esfuerzo 3 días
Capa Servidor
S.G.P.M.SRS
535455No. Requerimiento
R2203
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Finalizar sistema por límite de tiempo.
Encargado Andrés Fajardo
Descripción El sistema debe terminar en caso que se termine el tiempo límite de tiempo.
Objetivo Evitar partidas sin fin alguno, ni ganadores.
Criterio de Medición
La aplicación se finalizará cuando termine el tiempo límite, indicando antes de finalizar, quien fue el ganador de la partida.
Excepciones
Observaciones/ Justificación
Caso(s) Uso Relacionado
CU06, CU08
CU19
Requerimiento(s)
Asociado(s)
R2103
Trazabilidad Modelo de dominio
Documento Casos de uso:
R2203
Requerimiento
S.G.P.M.SRS
s Asociados
Reglas WorDomination
(SPMP Sección 10.1)
Riesgo 3 Prioridad 13
Costo MEDIO
Estado Aprobado
Esfuerzo 3 días
Capa Servidor
5657No. Requerimiento
R2303
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Informar Ganador
Encargado Andrés Fajardo
Descripción El sistema debe informar a todos los jugadores quien es el ganador de la partida.
S.G.P.M.SRS
Objetivo Informar a los jugadores quien fue el ganador.
Criterio de Medición
Si la aplicación termina por cualquier motivo posible (fin del tiempo, dos jugadores no pudieron ubicar más fichas o se les terminó el tiempo), el sistema informa quien ha sido el ganador.
Excepciones
Observaciones/ Justificación
Caso(s) Uso Relacionado
CU15 Requerimiento(s)
Asociado(s)
R0303, R1703, R1903, R2003, R2103, R2203
Trazabilidad Modelo de dominio
Documento Casos de uso:
Requerimientos Asociados
R0303, R1703,
R1903, R2003,
R2103, R2203
Reglas WorDomination
(SPMP Sección 10.1)
Riesgo 3 Prioridad 10
Costo MEDIO
S.G.P.M.SRS
Estado Aprobado
Esfuerzo 3 días
Capa Servidor
57.2.1 Funcionalidad 2: Registro y Autenticación
No. Requerimiento
R240202
Versión 1.0
Tipo Funcionales-Modo de Autenticación
Nombre Crear perfil de jugador
Encargado Andrés Fajardo
Descripción El sistema debe permitir al jugador crear o registrar su perfil al ingresar al juego.
Objetivo Permitir al jugador crear su perfil al ingresar al juego para posteriormente poder utilizar el mismo en partidas, seleccionándolo al inicio de la aplicación.
Criterio de Medición
Excepciones
Observaciones/ Justificación
Caso(s) Uso CU01, Requerimiento(s R2502
S.G.P.M.SRS
Relacionado CU07, CU08, CU09,
CU10
)
Asociado(s)
R2603
Trazabilidad Modelo de dominio
Documento Casos de uso:
Requerimientos Asociados
R2502
R2603
Reglas WorDomination
(SPMP Sección 10.1)
Riesgo 3 Prioridad 12
Costo MEDIO
Estado Aprobado
Esfuerzo 5 días
Capa Servidor
S.G.P.M.SRS
5859
No. Requerimiento
R2502
Versión 1.0
Tipo Funcionales-Modo de Autenticación
Nombre Crear tipo de usuario de jugador
Encargado Andrés Fajardo
Descripción El sistema debe permitir al usuario escoger el tipo de jugador que desee (Administrador, Jugador normal)
Objetivo Permitir al jugador crear el tipo de jugador que desea para operar sus características asociadas.
Criterio de Medición
Excepciones
Observaciones/ Justificación
Caso(s) Uso Relacionado
CU01
CU07
CU08
Requerimiento(s)
Asociado(s)
R2402
R2603
Trazabilidad Modelo de dominio
Documento Casos de uso:
S.G.P.M.SRS
Requerimientos Asociados
R2502
R2603
Reglas WorDomination
(SPMP Sección 10.1)
Riesgo 3 Prioridad 10
Costo MEDIO
Estado Aprobado
Esfuerzo 3 días
Capa Servidor
6061
No. Requerimiento
R2603
Versión 1.0
Tipo Funcionales-Modo de Autenticación
Nombre Almacenar información de archivos de texto de cada jugador.
Encargado Andrés Fajardo
Descripción El sistema debe permitir almacenar la información en archivos de
S.G.P.M.SRS
texto de cada jugador registrado (Nombre Completo, Nickname, contraseña).
Objetivo Permitir la persistencia mediante almacenamiento de la información de características de partidas de cada jugador.
Criterio de Medición
Excepciones
Observaciones/ Justificación
Caso(s) Uso Relacionado
CU01, CU03, CU07, CU08
Requerimiento(s)
Asociado(s)
R2402
R2502
Trazabilidad Modelo de dominio
Documento Casos de uso:
Requerimientos Asociados
R2402
R2502
Reglas WorDomination
(SPMP Sección 10.1)
S.G.P.M.SRS
Riesgo 3 Prioridad 10
Costo MEDIO
Estado Aprobado
Esfuerzo 3 días
Capa Servidor
626364
No. Requerimiento
R2703
Versión 1.0
Tipo Funcionales-Modo de Autenticación
Nombre Validar Información Ingresada
Encargado Oscar Gómez Herrera
Descripción El sistema debe validar la información ingresada por cada uno de los jugadores(NombreCompleto de 20 a 30 caracteres, Nickname 5 a 10 caracteres, contraseña de 6 a 15 caracteres)
Objetivo Se cumplirá que los datos ingresados en el requerimiento 26 se han ciertos a y acorde con lo establecido.
Criterio de Medición
El jugador deberá ingresar los criterios de información básicos para poder acceder al juego
Excepciones Datos Inválidos, Intente de nuevo
Observaciones/ Justificación
Ninguna
S.G.P.M.SRS
Caso(s) Uso Relacionado
CU01
CU02
Requerimiento(s)
Asociado(s)
R2603
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU01
CU02
Requerimientos Asociados
R2603
Reglas Wordominatio
n
(SPMP Sección 10.1)
Riesgo 3 Prioridad 14
Costo Medio
Estado Aprobado
Esfuerzo 15 días
Capa Servidor
65No. R2803
S.G.P.M.SRS
Requerimiento
Versión 1.0
Tipo Funcionales-Modo de Autenticación
Nombre Verificar Acciones Redundantes
Encargado Oscar Gómez Herrera
Descripción EL sistema debe validar cualquier tipo de información que un jugador vaya a ingresar en la aplicación con el fin de evitar redundancia
Objetivo Evitar las posibles repeticiones de información en el sistema
Criterio de Medición
Se dará información y advertirá de que la información a ingresar ya se encuentra
Excepciones
Observaciones/ Justificación
Ninguna
Caso(s) Uso Relacionado
CU01
CU02
CU07
Requerimiento(s)
Asociado(s)
R2502
R2603
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU01
CU02
CU07
Requerimiento
S.G.P.M.SRS
s Asociados
R2502
R2603
Reglas WorDominatio
n
(SPMP Sección 10.1)
Riesgo 4 Prioridad 12
Costo Medio
Estado Aprobado
Esfuerzo 15 dias
Capa Servidor
66No. Requerimiento
R2903
Versión 1.0
Tipo Funcionales-Modo de Autenticación
Nombre Confirmación Jugador Creado
Encargado Oscar Gómez Herrera
Descripción El sistema dará una confirmación de la creación de un jugador al usuario.
S.G.P.M.SRS
Objetivo Permitirá al sistema informar al usuario de la creación exitosa o no de la acción crear jugador
Criterio de Medición
El jugador estará informado si su perfil pudo ser creado, para poder jugar.
Excepciones
Observaciones/ Justificación
Es obligatorio tener un usuario para poder acceder a una partida del juego
Caso(s) Uso Relacionado
CU01 Requerimiento(s)
Asociado(s)
R2402, R2502, R2603, R2703
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU01
Requerimientos Asociados
R2402
R2502
R2603
R2703
Reglas WorDominatio
n
(SPMP Sección 10.1)
S.G.P.M.SRS
Riesgo 5 Prioridad 12
Costo Alto
Estado Aprobado
Esfuerzo 22 dias
67No. Requerimiento
R3002
Versión 1.0
Tipo Funcionales-Modo de Autenticación
Nombre Eliminar Registro Creado
Encargado Oscar Gómez Herrera
Descripción El sistema debe permitir al usuario eliminar el registro creado.
Objetivo Permitirá borrar la información seleccionada del registro creado por parte del usuario
Criterio de Medición
El jugador recibirá la confirmación del éxito o no de la acción por medio de un mensaje visual
Excepciones
Observaciones/ Justificación
Para eliminar el registro deberá existir
Caso(s) Uso Relacionado
CU02
CU03
Requerimiento(s)
Asociado(s)
R2402, R2502, R2603,
R2703
Trazabilidad Modelo de dominio
Documento
S.G.P.M.SRS
Casos de uso: CU01
Requerimientos Asociados
R2402
R2502
R2603
R2703
Reglas WorDominatio
n
(SPMP Sección 10.1)
Riesgo 3 Prioridad 10
Costo Medio
Estado Aprobado
Esfuerzo 25 dias
Capa Servidor
68No. Requerimiento
R3102
Versión 1.0
Tipo Funcionales-Modo de Autenticación
Nombre Ver Perfil
S.G.P.M.SRS
Encargado Oscar Gómez Herrera
Descripción El jugador podrá observar su perfil en el momento que lo desee.
Objetivo Permitirá dar información del usuario cuando este lo solicite
Criterio de Medición
El Jugador deberá poder ser informado del perfil pedido
Excepciones Al no existir el perfil, dará mensaje visual de no valido
Observaciones/ Justificación
El jugador deberá existir para poder ver la información del perfil
Caso(s) Uso Relacionado
CU03 Requerimiento(s)
Asociado(s)
R2603
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU03
Requerimientos Asociados
R2603
Reglas WorDominatio
n
(SPMP Sección 10.1)
Riesgo 4 Prioridad 11
Costo Medio
S.G.P.M.SRS
Estado Aprobado
Esfuerzo 14 dias
Capa Servidor
6970
No. Requerimiento
R3203
Versión 1.0
Tipo Funcionales-Modo de Autenticación
Nombre Eliminar Archivos
Encargado Oscar Gómez Herrera
Descripción El sistema debe eliminar todos los datos de los archivos de persistencia.
Objetivo Permitirá borrar los archivos relacionados con el juego(Persistencia)
Criterio de Medición
Se tendrá la opción de eliminar todos los archivos creados por medio de la aplicación como opción adicional.
Excepciones
Observaciones/ Justificación
Permitirá una mejor eficiencia de los recursos de hardware
Caso(s) Uso Relacionado
CU07
CU08
Requerimiento(s)
Asociado(s)
Trazabilidad Modelo de dominio
S.G.P.M.SRS
Documento Casos de uso:
CU07
CU08
Requerimientos Asociados
Reglas WorDominatio
n
(SPMP Sección 10.1)
Riesgo 2 Prioridad 9
Costo Bajo
Estado Aprobado
Esfuerzo 2 dias
Capa Servidor
717273
No. Requerimiento
R3302
Versión 1.0
Tipo Funcionales-Modo de
S.G.P.M.SRS
Autenticación
Nombre Terminar Partida
Encargado Oscar Gómez Herrera
Descripción El sistema debe permitir terminar la partida a los jugadores y al administrador en el momento en el que lo deseen.
Objetivo Permitirá al sistema acabar en cualquier momento el juego o partida deseados
Criterio de Medición
El jugador tendrá la opción de seguir o no en el juego
Excepciones
Observaciones/ Justificación
El usuario dará finalizar cuando se quiera salir de una partida.
Caso(s) Uso Relacionado
CU08 Requerimiento(s)
Asociado(s)
R3402
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU08
Requerimientos Asociados
R3402
Reglas WorDominatio
n
S.G.P.M.SRS
(SPMP Sección 10.1)
Riesgo 4 Prioridad 11
Costo Medio
Estado Aprobado
Esfuerzo 5 días
Capa Servidor
7475
No. Requerimiento
R3402
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Guarda Partida
Encargado Oscar Gómez Herrera
Descripción El sistema debe permitir salvar (guardar) una partida si un usuario requiere.
Objetivo Permitir retomar un juego después de terminado o aplazado
Criterio de Medición
El usuario podrá guardar su partida sino quiere seguirla en el tiempo dado
Excepciones
Observaciones/ Justificación
Dar la opción de jugar en otro momento la misma partida
Caso(s) Uso Relacionado
CU07
CU08
S.G.P.M.SRS
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU07
CU08
Requerimientos Asociados
Reglas WorDominatio
n
(SPMP Sección 10.1)
Riesgo 4
Costo Bajo
Estado Aprobado
Esfuerzo 15 días
Capa Servidor
7677
No. Requerimiento
R3503
Versión 1.0
Tipo Funcionales-Modo de juego
Nombre Terminar Partida(Desconexion)
Encargado Oscar Gómez Herrera
S.G.P.M.SRS
Descripción El sistema terminara la partida en el momento que un jugador se desconecte del juego.
Objetivo El sistema se desconectara cuando no tenga conexión con el servidor
Criterio de Medición
El sistemas dará como terminado cualquier jugo al no haber conexión
Excepciones
Observaciones/ Justificación
Al no haber conexión el sistema se perderá la información de la partida(Si no se guardo)
Caso(s) Uso Relacionado
Requerimiento(s)
Asociado(s)
Trazabilidad Modelo de dominio
Documento Casos de uso:
Requerimientos Asociados
Reglas WorDominatio
n
(SPMP Sección 10.1)
Riesgo 5 Prioridad 14
Costo Alto
S.G.P.M.SRS
Estado Aprobado
Esfuerzo 8 días
Capa Servidor
77.2.1 Funcionalidad 3: Administración78
No. Requerimiento
R3602
Versión 1.0
Tipo Funcionales- Modo Administración
Nombre Eliminar Jugador
Encargado Oscar Gómez Herrera
Descripción El sistema debe permitir al administrador eliminar un jugador, esperando una confirmación de fracaso o éxito de la solicitud.
Objetivo Eliminar un jugador cuando se exija
Criterio de Medición
El administrador tendrá la opción de eliminar cualquier jugador por conducta indebida
Excepciones
Observaciones/ Justificación
El jugador será sacado de la partidas y eliminado su perfil.
Caso(s) Uso Relacionado
CU02
CU03
Requerimiento(s)
Asociado(s)
Trazabilidad Modelo de dominio
S.G.P.M.SRS
Documento Casos de uso:
CU07
CU08
Requerimientos Asociados
Reglas WorDominatio
n
(SPMP Sección 10.1)
Riesgo 4 Prioridad 10
Costo Bajo
Estado Aprobado
Esfuerzo 2 dias
Capa Servidor
79
No. Requerimiento
R3702
Versión 1.0
Tipo Funcionales- Modo Administración
Nombre Eliminar Archivos(Administrador)
S.G.P.M.SRS
Encargado Oscar Gómez Herrera
Descripción El sistema debe eliminar de los archivos de persistencia al jugador que el administrador desee eliminar.
Objetivo El administrador puede eliminar cualquier tipo de archivo
Criterio de Medición
Se podrá eliminar el archivo de un jugador especifico o varios de varios jugadores
Excepciones
Observaciones/ Justificación
Mejorara la eficiencia del juego, para poder eliminar archivos antiguos y no usados
Caso(s) Uso Relacionado
CU02
CU05
Requerimiento(s)
Asociado(s)
R3002
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU02
CU05
Requerimientos Asociados
R3002
Reglas WorDominatio
n
(SPMP Sección 10.1)
Riesgo 5 Prioridad 12
S.G.P.M.SRS
Costo Alto
Estado Aprobado
Esfuerzo 15 días
Capa Servidor
79.2.1 Funcionalidad 4: Consultas
No. Requerimiento
R3802
Versión 1.0
Tipo Funcionales-Modo de Consulta
Nombre Consultar Estadísticas Usuario
Encargado Oscar Gómez Herrera
Descripción El sistema permitirá a un usuario que tenga un perfil creado en el juego consultar sus estadísticas dentro del juego.
Objetivo Cumplirá con informar al usuario sobre su desempeño en el juego
Criterio de Medición
El jugador deberá indicar su ID para poder mostrar su informacion
Excepciones ID invalido
Observaciones/ Justificación
Mostrar información de cada jugador
Caso(s) Uso Relacionado
CU03
CU06
Requerimiento(s)
Asociado(s)
R3902
Trazabilidad Modelo de dominio
S.G.P.M.SRS
Documento Casos de uso:
CU03
CU06
Requerimientos Asociados
R3902
Reglas Wordominatio
n
(SPMP Sección 10.1)
Riesgo 2 Prioridad 8
Costo Medio
Estado Aprobado
Esfuerzo 12 días
Capa Servidor
80818283
No. Requerimiento
R3902
Versión 1.0
Tipo Funcionales-Modo de
S.G.P.M.SRS
Consulta
Nombre Información Perfil(Restricciones)
Encargado Oscar Gómez Herrera
Descripción El sistema solo permitirá consultar las estadísticas propias de cada jugador que las solicite.
Objetivo Cumplir con la privacidad de información para cada jugador
Criterio de Medición
El jugador solicitante deberá ingresar la información básica para obtener la información(Nombre y Contraseña)
Excepciones Datos Inválidos, Intente de nuevo
Observaciones/ Justificación
Después de 3 errores en la validación de datos el juego se sale.
Caso(s) Uso Relacionado
CU03
CU06
Requerimiento(s)
Asociado(s)
R2603
R2703
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU03
CU06
Requerimientos Asociados
R2603
R2703
Reglas Wordominatio
n
(SPMP Sección 10.1)
S.G.P.M.SRS
Riesgo 4 Prioridad 12
Costo Medio
Estado Aprobado
Esfuerzo 19 días
Capa Servidor
84
No. Requerimiento
R4002
Versión 1.0
Tipo Funcionales-Modo de Consulta
Nombre Consulta Perfil de jugadores
Encargado Andrés Hidalgo
Descripción El sistema debe permitir ver perfil y estadísticas de los demás jugadores.
Objetivo Permite al usuario ver el desempeño de los demás jugadores en la ejecución de la aplicación.
Criterio de Medición
En el momento de realizar esta consulta, deberá mostrar la información correspondiente a las estadísticas de los demás jugadores.
Excepciones
Observaciones/ Justificación
Ninguna
Caso(s) Uso Relacionado
CU03
CU06
CU20
Requerimiento(s)
Asociado(s)
R1003, R3102, R3802
R3902
S.G.P.M.SRS
Trazabilidad Modelo de dominio
Documento Casos de uso: CU03, CU06,
CU20
Requerimientos Asociados
R1003, R3102, R3802
R3902
Reglas Wordominatio
n
(SPMP Sección 10.1)
Riesgo 3 Prioridad 10
Costo Medio
Estado Aprobado
Esfuerzo 2 días
Capa Servidor
858687
No. R4102
S.G.P.M.SRS
Requerimiento
Versión 1.0
Tipo Consulta
Nombre Consulta de Reglas y manuales
Encargado Andrés Hidalgo
Descripción El sistema permitirá al jugador consultar las reglas del juego y el manual de usuario en el momento que lo desee.
Objetivo El jugador podrá consultar tanto manuales como reglas para la resolución de dudas que surjan durante la ejecución del juego
Criterio de Medición
Durante toda la ejecución del juego, debe mostrar un botón de ayuda para los jugadores, el cual al ejecutarlo deberá mostrar la información requerida.
Excepciones
Observaciones/ Justificación
Ninguna
Caso(s) Uso Relacionado
CU21 Requerimiento(s)
Asociado(s)
R5004
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU21
Requerimientos Asociados
R5004
S.G.P.M.SRS
Reglas Wordominatio
n
(SPMP Sección 10.1)
Riesgo 4 Prioridad 10
Costo Medio
Estado Aprobado
Esfuerzo 2 dias
Capa Servidor
88899091
No. Requerimiento
R4202
Versión 1.0
Tipo Funcionales-Modo de Consulta
Nombre Consulta Numero de fichas en juego
Encargado Andrés Hidalgo
Descripción El sistema debe permitir al jugador consultar el número de fichas que faltan por jugar.
Objetivo Conociendo el numero de fichas que faltan por jugar, el usuario sabrá el estado de juego (esta en el inicio, en el medio o finalizando)
Criterio de Medición
EL juego debe mostrar durante todo el juego las fichas que van quedando después de haber colocado una nueva palabra en el
S.G.P.M.SRS
tablero hasta el final del juego.
Excepciones
Observaciones/ Justificación
Ninguna
Caso(s) Uso Relacionado
CU16
CU17
Requerimiento(s)
Asociado(s)
R0203
R0703
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU16, CU17
Requerimientos Asociados
R0203, R0703
Reglas Wordominatio
n
(SPMP Sección 10.1)
Riesgo 4 Prioridad 12
Costo Medio
Estado Aprobado
Esfuerzo 2 días
Capa Servidor
S.G.P.M.SRS
4.3 Requerimientos de Desempeño
No. Requerimiento
R4303
Versión 1.0
Tipo Dinámicos y Estáticos
Nombre Jugadores en línea
Encargado Andrés Hidalgo
Descripción El sistema soportara 4 posibles jugadores conectados al mismo tiempo, es decir, de forma simultanea
Objetivo Aclarar el máximo de usuarios que pueden estar conectados a la espera de una partida
Criterio de Medición
Usuarios conectados de forma simultanea
Excepciones
Observaciones/ Justificación
Ninguna
Caso(s) Uso Relacionado
CU09
CU10
Requerimiento(s)
Asociado(s)
R4403
R4601
Trazabilidad Modelo de dominio
Documento Casos de uso:
S.G.P.M.SRS
CU09, CU10
Requerimientos Asociados
R4403, R4601
Reglas Wordominatio
n
(SPMP Sección 10.1)
Riesgo 5 Prioridad 15
Costo Alto
Estado Aprobado
Esfuerzo 2 días
Capa Servidor
No. Requerimiento
R4403
Versión 1.0
Tipo Dinámicos y
S.G.P.M.SRS
Estáticos
Nombre Jugadores en la partida
Encargado Andrés Hidalgo
Descripción La creación de la partida debe tener por lo menos 2 jugadores y 4 como máximo.
Objetivo Cuando el jugador administrador desee iniciar una partida deberá tener mínimo 2 jugadores, de lo contrario el juego restringirá el inicio de la partida
Criterio de Medición
El juego permitirá la ejecución de las partidas de juego solo en el momento que este el mínimo de jugadores para jugar.
Excepciones
Observaciones/ Justificación
Ninguna
Caso(s) Uso Relacionado
CU09
CU10
Requerimiento(s)
Asociado(s)
R4403
R4601
Trazabilidad Modelo de dominio
Documento Casos de uso:
CU09, CU10
Requerimientos Asociados
R4403, R4601
Reglas
S.G.P.M.SRS
Wordomination
(SPMP Sección 10.1)
Riesgo 5 Prioridad 15
Costo Alto
Estado Aprobado
Esfuerzo 2 días
Capa Servidor
No. Requerimiento
R4503
Versión 1.0
Tipo Dinámicos y Estáticos
Nombre Respuesta inmediata
Encargado Andrés Hidalgo
Descripción El sistema debe realizar respuestas en tiempo real, que no intervengan o influyan en el flujo del juego
Objetivo Mostrar la eficiencia del juego con respecto al manejo de los tiempos.
S.G.P.M.SRS
Criterio de Medición
Se espera que el juego reaccione de manera inmediata ante cualquier acción que realicen los jugadores en la aplicación
Excepciones
Observaciones/ Justificación
Latencia del juego
Caso(s) Uso Relacionado
Requerimiento(s)
Asociado(s)
Trazabilidad Modelo de dominio
Riesgo 4 Prioridad 14
Costo Medio
Estado Aprobado
Esfuerzo 1 días
Capa Servidor
4.4 Restricciones De Diseño
No. Requerimiento
R4601
Versión 1.0
Tipo Restricciones de
S.G.P.M.SRS
Funcionalidad
Nombre Comunicación
Encargado Andrés Hidalgo
Descripción El sistema debe comunicarse por medio de una arquitectura Cliente-Servidor.
Objetivo Hace parte de las restricciones estipuladas por el cliente en el acuerdo del proyecto
Criterio de Medición
En el momento que un computador este dando repuestas a los demás durante el juego, se dará por exitosa la comunicacion
Excepciones
Observaciones/ Justificación
Ninguna
Caso(s) Uso Relacionado
Requerimiento(s)
Asociado(s)
R4601
Trazabilidad Modelo de dominio
Requerimientos Asociados
R4601
Reglas Wordominatio
n
(SPMP Sección 10.1)
Riesgo 3 Prioridad 12
S.G.P.M.SRS
Costo Medio
Estado Aprobado
Esfuerzo 2 dias
Capa Servidor
No. Requerimiento
R4701
Versión 1.0
Tipo Restricciones de Funcionalidad
Nombre Diseño O.O
Encargado Andrés Hidalgo
Descripción El diseño y creación de la aplicación debe ser orientado a objetos.
Objetivo Aplicación del Plan de Procesos Técnicos (Ver Sección 6 del SPMP)
Criterio de Medición
Utilizando lenguaje orientado a objetos (JAVA), en el desarrollo del producto.
Excepciones
Observaciones/ Justificación
Ninguna
Caso(s) Uso Relacionado
Requerimiento(s)
Asociado(s)
S.G.P.M.SRS
Trazabilidad Modelo de dominio
Reglas Wordominatio
n
(SPMP Sección 10.1)
Riesgo 3 Prioridad 12
Costo Medio
Estado Aprobado
Esfuerzo 2 días
Capa Servidor
No. Requerimiento
R4801
Versión 1.0
Tipo Restricciones de Funcionalidad
Nombre Diseño acorde al modelo de dominio
Encargado Andrés Hidalgo
Descripción El diseño se realizara de acuerdo al modelo de dominio.
Objetivo Poder aplicar de forma eficiente todo lo que el grupo ha diseñado para el desarrollo del juego.
Criterio de La aplicación deberá estar acorde al modelo de dominio diseñado
S.G.P.M.SRS
Medición
Excepciones
Observaciones/ Justificación
Ninguna
Caso(s) Uso Relacionado
Requerimiento(s)
Asociado(s)
Trazabilidad Modelo de dominio
Reglas Wordominatio
n
(SPMP Sección 10.1)
Riesgo 3 Prioridad 8
Costo Medio
Estado Aprobado
Esfuerzo 2 días
Capa Servidor
No. Requerimiento
R4901
S.G.P.M.SRS
Versión 1.0
Tipo Restricciones de Funcionalidad
Nombre Funcionamiento en el Sistema Operativo
Encargado Andrés Hidalgo
Descripción La aplicación debe ejecutarse en la plataforma de Windows XP
Objetivo Esto permitirá ejecutar la aplicación en un sistema operativo conocido por el usuario, lo cual permitirá un uso más fácil y eficiente
Criterio de Medición
El Juego debe estar en la capacidad de ejecutarse de forma correcta en este sistema operativo.
Excepciones
Observaciones/ Justificación
Ninguna
Caso(s) Uso Relacionado
Requerimiento(s)
Asociado(s)
Trazabilidad SPMP Casos de Uso
Riesgo 4 Prioridad 14
Costo Medio
Estado Aprobado
Esfuerzo 2 días
Capa Servidor
S.G.P.M.SRS
No. Requerimiento
R5004
S.G.P.M.SRS
Versión 1.0
Tipo Restricciones de Funcionalidad
Nombre Consulta de Reglas y manuales
Encargado Andrés Hidalgo
Descripción La aplicación debe poseer manuales de instalación para los programas que necesita en su ejecución
Objetivo Permitir mayor interacción del juego con el usuario.
Criterio de Medición
Un claro y fácil entendimiento por parte del usuario de los manuales de instalación, descartara cualquier tipo de ambigüedad en su manejo.
Excepciones
Observaciones/ Justificación
Ninguna
Caso(s) Uso Relacionado
CU02
CU07
CU12
Requerimiento(s)
Asociado(s)
R4102
R5104
Trazabilidad SPMP: Reglas de juego
Riesgo 3 Prioridad 8
Costo Bajo
Estado Aprobado
Esfuerzo 2 dias
Capa Servidor
S.G.P.M.SRS
No. Requerimiento
R5104
Versión 1.0
Tipo Restricciones de Funcionalidad
Nombre Manual de Usuario
Encargado Andrés Hidalgo
Descripción La aplicación debe tener un manual de usuario
Objetivo Darle a conocer al usuario, el manejo del juego al alcance de sus manos.
Criterio de Medición
Un claro y fácil entendimiento por parte del usuario de los manuales de usuario, descartara cualquier tipo de ambigüedad respecto a la ejecución del juego.
Excepciones
Observaciones/ Justificación
Ninguna
Caso(s) Uso Relacionado
Requerimiento(s)
Asociado(s)
R4102
R5004
Trazabilidad SPMP
Riesgo 3 Prioridad 8
Costo Bajo
Estado Aprobado
Esfuerzo 2 días
Capa Servidor
S.G.P.M.SRS
No. Requerimiento
R5201
Versión 1.0
Tipo Consulta
Nombre Diseño Agradable (GUI fuerte)
Encargado Andrés Hidalgo
Descripción El sistema debe ser agradable visualmente
Objetivo Hace parte de las restricciones acordadas con el cliente en el planeamiento del proyecto, (Ver sección restricciones SPMP)
Criterio de Medición
La aceptación de la apariencia debe ser superior al 70% , teniendo en cuenta su buen diseño y fácil manejo.
Excepciones
Observaciones/ Justificación
Ninguna
Caso(s) Uso Relacionado
Requerimiento(s)
Asociado(s)
Trazabilidad SPMP
Riesgo 5 Prioridad 14
S.G.P.M.SRS
Costo Alto
Estado Aprobado
Esfuerzo 2 días
Capa Servidor
No. Requerimiento
R5301
Versión 1.0
Tipo Consulta
Nombre Funcionamiento en laboratorios
Encargado Andrés Hidalgo
Descripción El sistema debe funcionar perfectamente en los laboratorios de la facultad
Objetivo El sistema como tal debe correr correctamente en las salas de la facultad pues es una de las restricciones establecidas por el cliente en el acuerdo del proyecto. (Ver Restricciones SPMP)
Criterio de Medición
El sistema deberá correr correctamente en las salas
Excepciones
Observaciones/ Justificación
Ninguna
Caso(s) Uso Relacionado
Requerimiento(s)
Asociado(s)
S.G.P.M.SRS
Trazabilidad SPMP
Riesgo 5 Prioridad 14
Costo Medio
Estado Aprobado
Esfuerzo 2 días
Capa Servidor
4.5 Atributos del Sistema de Software (No funcionales)
Este tipo de atributos se caracterizan por no tener una relación directa con el software que se realiza dentro de un proyecto. Sin embargo, este tipo de atributos reflejan el comportamiento en el momento de la ejecución, estructura y organización del programa fuente y la respectiva documentación. A continuación de mostraran algunos de los atributos con los que deberá contar el producto final que se le mostrara al cliente: [Nº Referencia]
[Nº Referencia]Ian Sommerville 2000, Software Engineering, 6th Edition. Chapter 1
ATRIBUTO APLICACIONConfiabilidad El sistema debe de soportar todas las
funcionalidades anteriormente descritas y garantizar su buen funcionamiento durante todo el período de su ejecución. Para ello, se utilizarán patrones de diseño que han sido ampliamente estudiados y probados.
Disponibilidad Los ficheros utilizados para la persistencia de datos, tales como los
S.G.P.M.SRS
diccionarios de juego e idiomas de localización, perfiles de jugadores, etc., deberán estar disponibles como mínimo al menos durante la ejecución de la aplicación.
Seguridad En un principio, será el propio usuario de la aplicación el encargado de garantizar la seguridad de los datos utilizados por ésta. De la misma manera, el propio Usuario será el encargado de realizar backups de los ficheros con datos sensibles cuando él crea necesario.
Mantenibilidad El mantenimiento y modificaciones que se puedan hacer en el sistema, dependerá de las aplicaciones con las que se quiera integrar y las plataformas donde se quiera poner.
Eficiencia El sistema se ha de comportar de manera eficiente y rápida, tanto en la resolución de los problemas presentados a cada turno de juego, como en el desarrollo general de las partidas. Desde el punto de vista de la gestión de datos, la aplicación se ha diseñado de forma eficiente.
Fácil Manejo La aplicación va dirigida tanto a personas expertas en informática como a personas con conocimientos muy bajos o casi nulos, por tanto, su diseño ha de estar pensado para este último tipo de personas. Esto se deberá conseguir mediante menús y pantallas suficientemente intuitivas y fáciles de usar para cualquier usuario de la aplicación.
S.G.P.M.SRS
4.6 Requerimientos de la base de datos
Para la especificación de los requerimientos de la Base de Datos, es necesario tener en cuenta varios aspectos, entre estos se encuentran:
Ilustración 7: Características Bases de Datos
Tipos de datos almacenados: dependiendo del motor de base de datos escogidos, es posible tener diferentes tipos de datos, sin embargo al hacer esta sección podrían incluirse los más usados: Char, Varchar, Numeric y Date por mencionar algunos.
Tipo de consultas utilizadas: la forma en que los datos serán accedidos, consultadas e ingresados desde los DAO´s (Data Access Object) para evitar la introducción de sentencias malintencionadas. Los tipos más conocidos son Statement y Prepared Statment.
Indexación de los datos: la eficiencia de las consultas complejas pueden reducirse dependiendo de la forma en que se haga el diseño de la base de datos, una buena forma de mostrar este aspecto es con el diagrama de Entidad Relación
Tipos de datos almacenados
Tipo de consultas utilizadas
Indexación de los datos
Uso de Primary key
Frecuencia de acceso
S.G.P.M.SRS
Utilización de Primary Key: al igual que con el aspecto anterior la utilización adecuada de una primary key puede evitar ciclos y además permite y facilita eficiencia en el tiempo de consultas hechas en tiempo real.
Frecuencia de acceso: dependiendo del tipo de sistema que se desea implementar, especificar la frecuencia de acceso a la base de datos incluyendo el número de conexiones abiertas y tener en cuenta el tipo de consulta utilizada, la carga extra que puede producir el manejo de DAO’s puede disminuir, aumentando de esta forma el desempeño en general de la aplicación.
S.G.P.M.SRS
5 Anexos