SRS V.0.5 (Plantilla Corregida)

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 Perez
1
1
S.G.P.M.
SRS
HISTORIAL DE CAMBIOS
VERSION
FECHA
SECCIÒN
MODIFICADA
DESCRIPCION RESPONSA
CAMBIOS
BLES
V.0.1
Sabado, 5
1.1, 1.3, 1.4.
de
Septiembre
de 2009.
Se realizaron
aportes de
ideas para las
secciones
descritas.
V.0.2
Sabado, 12 1.2, 1.5
de
Septiembre
de 2009.
Se
S.G.P.M.
completaron
las secciones
faltantes.
Tabla 1: Historial de cambios
2
S.G.P.M.
2
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 ............................................................................................................................................ 7
1.2 ALCANCE................................................................................................................................................ 8
1.3 DEFINICIONES, ACRÓNIMOS, Y ABREVIACIONES ............................................................................................. 9
1.4 REFERENCIAS ........................................................................................................................................ 13
1.5 APRECIACIÓN GLOBAL ............................................................................................................................ 14
2 CICLO DE VIDA DE REQUERIMIENTOS ................................................................................................ 16
2.1 IDENTIFICACIÓN DE STAKEHOLDERS ........................................................................................................... 16
2.2 NECESIDADES DEL USUARIO ..................................................................................................................... 17
2.3 PARTICIPACIÓN POR ROLES...................................................................................................................... 17
2.4 PROCESO DE REQUERIMIENTOS................................................................................................................. 18
2.4.1 Identificación de Requerimientos .............................................................................................. 19
2.4.2 Especificación de Requerimientos ............................................................................................ 22
2.4.3 Priorización de Requerimientos ................................................................................................ 23
2.4.4 Trazabilidad ............................................................................................................................... 27
2.4.5 Validación y verificación. ........................................................................................................... 28
2.5 ADMINISTRACIÓN DE REQUERIMIENTOS ..................................................................................................... 28
2.6 INTERFACES .......................................................................................................................................... 28
3 DESCRIPCIÓN GLOBAL ....................................................................................................................... 29
3.1 PERSPECTIVA DEL PRODUCTO ................................................................................................................... 29
3.1.1 Interfaces con el sistema ........................................................................................................... 29
3.1.2 Interfaces con el usuario ........................................................................................................... 29
3.1.3 Interfaces con el Hardware ....................................................................................................... 30
3.1.4 Interfaces con el Software ......................................................................................................... 32
3.1.5 Interfaces de Comunicación ...................................................................................................... 34
3.1.6 Restricciones de Memoria ......................................................................................................... 34
3.1.7 Operaciones .............................................................................................................................. 35
3.1.8 Requerimientos de Adaptación del Sitio.................................................................................... 36
3.2 FUNCIONES DEL PRODUCTO ..................................................................................................................... 36
3.3 CARACTERÍSTICAS DEL USUARIO................................................................................................................ 36
3.4 RESTRICCIONES ..................................................................................................................................... 39
3.5 MODELO DEL DOMINIO .......................................................................................................................... 40
3
3
S.G.P.M.
SRS
3.6 SUPOSICIONES Y DEPENDENCIAS ............................................................................................................... 42
4 REQUERIMIENTOS ESPECÍFICOS ......................................................................................................... 44
4.1 REQUERIMIENTOS DE INTERFACES EXTERNAS............................................................................................... 46
4.1.1 Interfaces con el Usuario ........................................................................................................... 46
4.1.2 Interfaces con el Hardware ....................................................................................................... 47
4.1.3 Interfaces con el Software ......................................................................................................... 48
4.1.4 Interfaces de Comunicaciones ................................................................................................... 49
4.2 CARACTERÍSTICAS DEL PRODUCTO DE SOFTWARE ......................................................................................... 49
4.3 REQUERIMIENTOS DE DESEMPEÑO .......................................................................................................... 117
4.4 RESTRICCIONES DE DISEÑO.................................................................................................................... 122
4.5 ATRIBUTOS DEL SISTEMA DE SOFTWARE (NO FUNCIONALES) ........................................................................ 131
4.5.1 Confiabilidad ................................................................................. Error! Bookmark not defined.
4.5.2 Disponibilidad ................................................................................ Error! Bookmark not defined.
4.5.3 Seguridad ...................................................................................... Error! Bookmark not defined.
4.5.4 Mantenibilidad .............................................................................. Error! Bookmark not defined.
4.5.5 Eficiencia ....................................................................................... Error! Bookmark not defined.
4.5.6 Facilidad de Uso ............................................................................ Error! Bookmark not defined.
4.6 REQUERIMIENTOS DE LA BASE DE DATOS................................................................................................... 133
5 ANEXOS ........................................................................................................................................... 136
4
4
S.G.P.M.
SRS
Lista de Tablas
Tabla 1: Historial de cambios .................................................................................................................. 2
Tabla 2: Acrónimos ................................................................................................................................13
Tabla 3: Interfaces con el Software ....................................................................................................... 33
Tabla 4: Descripción de las Características del Usuario .............................. Error! Bookmark not defined.
Tabla 5: Definiciones del Modelo de Dominio ....................................................................................... 41
Tabla 6: Formato de documentación del Modelo del Dominio .............................................................. 41
Tabla 7: Documentación de Requerimientos ............................................. Error! Bookmark not defined.
5
5
S.G.P.M.
SRS
Lista de Ilustraciones
Ilustración 1: Propósito ................................................................................... Error! Bookmark not defined.
Ilustración 2: Alcance ...................................................................................... Error! Bookmark not defined.
Ilustración 3: Apreciación Global .................................................................... Error! Bookmark not defined.
Ilustración 4: Tipos de productos de software ............................................... Error! Bookmark not defined.
Ilustración 5: Interfaces con el usuario ........................................................... Error! Bookmark not defined.
Ilustración 6: Operaciones .............................................................................. Error! Bookmark not defined.
Ilustración 7: Tips para definir funciones del producto .................................. Error! Bookmark not defined.
Ilustración 8: Características del Usuario ........................................................ Error! Bookmark not defined.
Ilustración 9: Restricciones ............................................................................. Error! Bookmark not defined.
Ilustración 10: Limitaciones ........................................................................................................................ 39
Ilustración 11: Descripción documentación del modelo del dominio ........................................................ 42
Ilustración 12: Suposiciones ....................................................................................................................... 43
Ilustración 13: Dependencias [1] ................................................................................................................ 43
Ilustración 14: Distribución de requerimientos .............................................. Error! Bookmark not defined.
Ilustración 15: Características de los Requerimientos .................................... Error! Bookmark not defined.
Ilustración 16: Documentación de Requerimientos ....................................... Error! Bookmark not defined.
Ilustración 17: Interfaces con el Usurario ................................................................................................... 46
Ilustración 18: Interfaces de Hardware ...................................................................................................... 48
Ilustración 19: Interfaces con el Software .................................................................................................. 49
Ilustración 20: División por Funcionalidades .................................................. Error! Bookmark not defined.
Ilustración 21: Ejemplo Enunciado Requerimientos ....................................... Error! Bookmark not defined.
Ilustración 22: Atributos de Calidad a tener en cuenta .................................. Error! Bookmark not defined.
Ilustración 23: Características de Confiabilidad .............................................. Error! Bookmark not defined.
Ilustración 24: Características de Disponibilidad ............................................ Error! Bookmark not defined.
Ilustración 25: Características de Seguridad ................................................... Error! Bookmark not defined.
Ilustración 26: Características de Mantenibilidad .......................................... Error! Bookmark not defined.
Ilustración 27: Portabilidad del Sistema ......................................................... Error! Bookmark not defined.
Ilustración 28: Características Bases de Datos .......................................................................................... 134
6
6
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 previamentepuesto 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]
7
7
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):
8
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
8
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
9
9
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
J
L
P
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”).
JDBC: Java database Connectivity: Librería de Java que facilita la labor de
conexión a una base de datos desde cualquier IDE.
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.
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
10
10
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
11
11
S.G.P.M.
SRS
sea por el mismo cliente, casos de uso, regla del negocio, etc.
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
12
12
S.G.P.M.
SRS
o conjunto de programas en un determinado entorno. Este documento
puede desarrollarlo personal representativo de la parte suministradora, o
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
13
13
S.G.P.M.
SRS
 [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
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
14
14
S.G.P.M.
SRS
interfaces externas entre el sistema y el mundo externo, al igual que el diseño e
implementación de restricciones. [14]
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.
15
15
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:
16
16
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:
17
17
S.G.P.M.
SRS
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.
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
18
18
S.G.P.M.
SRS
2.4.1 Identificación de Requerimientos
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.
19
Identificación
Especificación
R##01
Negocio
R##02
Usuario
R##03
Sistema
R##04
No funcionales
19
S.G.P.M.
SRS
NegocioR##01
No
funcionalR##04
Requerimientos
UsuarioR##02
SistemaR##03
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]
20
20
S.G.P.M.
SRS
[Ian Sommerville 2000, Software Engineering, 6th Edition. Chapter 5]


21
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
21
S.G.P.M.
SRS
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.
22
22
S.G.P.M.
SRS
Inicio
de
Juego
Informació
n Clientes
Opciones
Juego
Modo
Juego
No
Funciona
les
• Como Iniciar y finalizar la aplicación
• Posibles opciones de inicios si hay errores
• Requerimientos Perfil e información del Usuario
• Estadísticas de juegos
• 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
• Requerimientos Implementados en la validación de un juego mientras se ejecuta la
funcionalidad (mover, poner, coger ,quitar, etc.)
• Requerimientos Relacionados con la velocidad e implantación del sistema(PC).
Conexiones de red y formas no esenciales que no afectan al juego
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
23
23
S.G.P.M.
SRS
Indentificacion
de
Requerimientos
y Su nivel de
Valorización
general
Nivel de
Prioridad segun
El rol
Prioridad Final
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 Rol
Visión por cada rol: Aquí usaremos el inciso A para que cada miembro
del grupo SGPM pueda valorar los requerimientos ya establecidos y su
24
24
S.G.P.M.
SRS
prioridad, pero dando una valoración individual para contrarrestar y
clasificar con la ya dada generalmente, teniendo como fundamento dos
puntos de valoración y así priorizar tanto
individualmente como
generalizado, lo cual nos brindara un mejor visión.
C) Prioridad Final
Para 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.



Valorización Rol.


25
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]
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]
25
S.G.P.M.
SRS

Prioridad final.

En esta clasificación se dará la
priorización final de los
requerimientos y hará una
matriz de conflicto asiendo las
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:
Valorización
General
Valorización
Rol(Clasificación
Negativa o
Positiva)
Prioridad Final
Gestión de Preferencias de Requerimientos basada en
Técnicas Cognitivas
Nadina
Martínez
Carod
and
Alejandra
http://www.cacic2007.unne.edu.ar/papers/035.pdf
Cechich.[53]encontrar
http://ing.de.soft1.googlepages.com/07-SeleccionYPriorizacion.pdf[54]
http://readyset.tigris.org/nonav/es/templates/feature-set.html[55]
26
26
S.G.P.M.
SRS
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
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
Monitoreo de la
implentacion del
requerimeinto
Figura trazabilidad hacia adelante
Origen de los
requerimientos
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.
27
27
S.G.P.M.
SRS
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] .
[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).
28
28
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
29
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
29
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:
30
30
S.G.P.M.
SRS
31
La eleccion de escoger este protocolo fue por la busqueda de la simplicidad
, funcionalidad y estandarizacion que se manejara, algunas causas de
nuestra decision
Protocolo de
Comunicación
TCP/IP
• 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 Http
Este protocolo permitira implementar el requerimiento de arquitectura
cliente-servidor , este permite la trasmicion de datos como se pide y se ha
documentado.[2]
Puerto TCP
Protocolo 3036
Este 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 31337
Dara la posibilidad de acceder y controlar la aplicacion externamente, ya
que se basa en el modelo de cliente-servidor para que funcione.[3][2]
Partes Físicas
(Cables
y
Conexiones)
31
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:
32
32
S.G.P.M.
SRS
Producto
de
Software
Propósito de Uso
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
MicroSoft Windows
Windows Vista
www.microsoft.com/spain/windows/
Permitirá la creación , desarrollo y
ejecución del la aplicación
WordDominatio
A partir de la versión 5.0
JavaFx
Permitirá creación de una Interfaz con
una calidad grafica dinámica 2D o 3D
Versión 1.2
SunMicroSystem
JMF
Permitirá la adaptación de tecnologías
de audio y video , para la aplicación
Versión 2.1.1e
http://java.sun.com/javafx/
SunMicroSystem
JDK
Versión
33
Fuente
Windows NT
Sun MicroSystem
http://java.sun.com/javase
http://java.sun.com/javase/technologies/d
esktop/media/jmf/
33
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 Equipo
•512 MB de RAM
•Disco Duro de 80 MB
•Procesador 1.6 GH
Requisitos de Software
•NetBeans :256 MB
•SQL Developer: 106 MB
34
34
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:
Usuarios
Administrador
• Crear Partidas
• Lanzar Partida
• Cargar partida
•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
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
35
35
S.G.P.M.
SRS
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.
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
36
36
S.G.P.M.
SRS
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
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.
37
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
37
S.G.P.M.
SRS
que tenga el turno dentro del juego.
38
Comentarios
El usuario debe tener un nivel de
intelecto y entendimiento aceptable,
para vencer y no dejarse ganar.
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
38
S.G.P.M.
SRS
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:






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
39
39
S.G.P.M.
SRS
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.
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:
40
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
40
S.G.P.M.
SRS
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].
A continuación se presenta una forma para documentar los elementos en el diagrama
del modelo del dominio.
ID
Elemento
Dominio
del
Descripción
Atributos
Nombre
Descripción
Tipo de Dato
Objetivo
Tabla 5: Formato de documentación del Modelo del Dominio
41
41
S.G.P.M.
SRS
ID
Elemento del Dominio
Descripción
Atributos
Nombre
Descripción
Tipo de Dato
Objetivo
•Identificador único del elemento del dominio del problema.
•Indica el nombre del elemento del dominio del problema que será
documentado.
•Contiene una breve descripción del elemento, se debe indicar el por
qué del creación del mismo dentro del elemento del dominio.
•De acuerdo a los atributos del elemento escogido se debe tomar cada
uno para documentarlos.
•Nombre del atributo que se documentará.
•Descripción del objetivo del atributo dentro del elemento.
•De acuerdo al lenguaje planeado para la implementaicon del sistema,
establecer el tipo de dato que se le asignará al elemento.
•Descripción global acerca del elemento documentado con el fin de
exponer su funcionalidad en el sistema.
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
42
42
S.G.P.M.
SRS
podría afectarse si estas suposiciones son incorrectas, no se comparten, o se cambian
[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
Ilustración 2: Suposiciones
Dependencias:
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
Ilustración 3: Dependencias [1]
43
43
S.G.P.M.
SRS
4 Requerimientos Específicos
No.
Requerimiento
Número de Identificación de requerimiento. Ver Error! Reference
Versión
1.0 Primera Versión del Requerimiento
Tipo
Error! Reference source not found. Error! Reference source 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
source not found.
Objetivo
Criterio
Medición
de 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 Casos de uso Requerimiento(s
Relacionad que
se )
o
relacionan
Asociado(s)
con
el
requerimiento
.
Según el grafo
(ver
Error!
Reference
source
not
found. Error!
Reference
source
not
found.) son los
requerimiento
s antecesores y
44
44
S.G.P.M.
SRS
predecesores.
Trazabilidad
Riesgo
Se mide según el Prioridad
número
de
requerimientos, que
según el grafo de
requerimientos
(Error!
Reference
source
Error!
source
not
found.
Reference
not found.),
dependen de la
implementación de
este, es decir los
requerimientos
predecesores.
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
TOKA referenciar
45
Medida
dada
según
las
especificaciones
expuestas en la
Sección
Error!
Reference
not found.
Reference
not found..
source
Error!
source
45
S.G.P.M.
SRS
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:
PANTALLLA
TECLADO
MOUSE
INTERFAZ
GUI
TARJETA
GRAFICA
TARJETA
DE RED
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
46
46
S.G.P.M.
SRS
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:
TCP-UDP
Red HUB
SWITCH
Interconexión
UTP
47
Puertos
47
S.G.P.M.
SRS
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)
Ilustración 5: Interfaces de Hardware
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 Tabla 3: Interfaces con el Software
muestra un formato que puede usarse para explicar estas interfaces.
48
48
S.G.P.M.
SRS
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:
49
49
S.G.P.M.
SRS
• Juego
• Autenticacion
Requerimientos
• Administracion
• Consultas
2.2.1 Funcionalidad 1: Jugar
No.
Requerimiento
R010303
Versión
1.0
Tipo
FuncionalesModo 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
Medición
de Al iniciar el juego, el jugador debe poder armar palabras con el
número de fichas entregadas.
Excepciones
Observaciones/ Ninguna
Justificación
Caso(s)
50
Uso
CU02,
Requerimiento(s) R020303
50
S.G.P.M.
SRS
Relacionado
CU07
Asociado(s)
CU12
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU02
CU07
CU12
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
2
Costo
Medio
Estado
Aprobado
Esfuerzo
2 días
Capa
Servidor
3
No.
Requerimiento
51
R020303
Prioridad
12
R0703
51
S.G.P.M.
SRS
Versión
1.0
Tipo
FuncionalesModo 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
Medición
de Todos los jugadores en su interfaz pueden ver los
movimientos(arrastre de fichas) de sus rivales, puntajes se deben
modificar.
Excepciones
Observaciones/ Ninguna
Justificación
Caso(s)
Uso
Relacionado
CU15,
CU16
CU18
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU15
CU16
CU18
Requerimientos
52
Requerimiento(s) R080303,
R090303,
Asociado(s)
R010303
52
S.G.P.M.
SRS
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
4
Costo
Alto
Estado
Aprobado
Esfuerzo
20 días
Capa
Servidor
Prioridad
14
4
5
No.
Requerimiento
R030303
Versión
1.0
Tipo
FuncionalesModo 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
53
de Después de los 2 minutos, se debe ceder al turno al jugador
53
S.G.P.M.
SRS
Medición
correspondiente
Excepciones
Observaciones/ Ninguna
Justificación
Caso(s)
Uso
Relacionado
Trazabilidad
CU14
Requerimiento(s) R0103703
CU19
Asociado(s)
Modelo de
dominio
Documento
Casos de uso:
CU14
CU19
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
54
Riesgo
3
Costo
MEDIO
Estado
Aprobado
Esfuerzo
3 días
Prioridad
10
R0103403
54
S.G.P.M.
SRS
Capa
Servidor
6
7
No.
Requerimiento
R0403
Versión
1.0
Tipo
FuncionalesModo 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
Medición
de En el tablero el jugador podrá formar sus palabras durante dos
minutos, contabilizándole su puntaje
Excepciones
Observaciones/ Si no se realiza la jugada, pierde turno
Justificación
Caso(s)
Uso
Relacionado
CU15
CU16
CU18
Trazabilidad
Modelo de
dominio
Documento
55
Requerimiento(s) R0203, R0803,
R0903, R1703
Asociado(s)
55
S.G.P.M.
SRS
Casos de uso:
CU15
CU16
CU18
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
4
Costo
ALTO
Estado
Aprobado
Esfuerzo
12 días
Capa
Servidor
8
9
56
No.
Requerimiento
R0503
Versión
1.0
Tipo
Funcionales-
Prioridad
15
56
S.G.P.M.
SRS
Modo de juego
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
Medición
de El sistema debe quitar del tablero la última palabra ingresada si el
jugador así lo desea
Excepciones
Observaciones/
Justificación
Caso(s)
Uso
Relacionado
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU13
CU16
Requerimientos
Asociados
Reglas
WorDomination
57
CU13
Requerimiento(s) R1403
CU16
Asociado(s)
R0203
57
S.G.P.M.
SRS
(SPMP Sección
10.1)
Riesgo
4
Costo
ALTO
Estado
Aprobado
Esfuerzo
12 días
Capa
Servidor
Prioridad
12
10
11
12
13
14
No.
Requerimiento
R0603
Versión
1.0
Tipo
FuncionalesModo 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
Criterio
Medición
58
de El sistema debe validar la palabra incluidos los comodines y fichas en
blanco y sumarlo al puntaje
58
S.G.P.M.
SRS
Excepciones
Observaciones/ Los comodines
Justificación
WorDomination)
Caso(s)
Uso
Relacionado
Trazabilidad
son
de
un
número
Requerimiento(s) R0203
CU16
Asociado(s)
Documento
Casos de uso:
CU18
CU16
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
59
3
Costo
BAJO
Estado
Aprobado
(ver
CU18
Modelo de
dominio
Riesgo
limitado
Prioridad
9
reglas
59
S.G.P.M.
SRS
Esfuerzo
2 días
Capa
Servidor
15
16
17
No.
Requerimiento
R0703
Versión
1.0
Tipo
FuncionalesModo 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
Medición
de A iniciar el juego cada jugador debe tener 7 fichas
Excepciones
Observaciones/ Puede que ha determinado jugador al inicio con sus fichas pueda
Justificación
armar más fácil una palabra.
Caso(s)
Uso
Relacionado
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
60
CU02
Requerimiento(s) R0103
Asociado(s)
R1303
60
S.G.P.M.
SRS
CU02
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
2
Costo
BAJO
Estado
Aprobado
Esfuerzo
2 días
Capa
Servidor
18
19
20
61
No.
Requerimiento
R0803
Versión
1.0
Tipo
FuncionalesModo de juego
Nombre
Acomodar Fichas
Prioridad
8
61
S.G.P.M.
SRS
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
Medición
de El jugador debe poder formar sus palabras en el tablero, tanto en
sentido vertical como horizontal
Excepciones
Observaciones/ Las casillas donde se ponen las fichas deben ser validas(estar
Justificación
desocupadas)
Caso(s)
Uso
Relacionado
CU16
Requerimiento(s) R0203
CU18
Asociado(s)
CU15
R0903
R0403
R1903
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU16
CU18
CU15
Requerimientos
Asociados
62
62
S.G.P.M.
SRS
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
3
Costo
MEDIO
Estado
Aprobado
Esfuerzo
4 días
Capa
Servidor
Prioridad
11
21
22
23
63
No.
Requerimiento
R0903
Versión
1.0
Tipo
FuncionalesModo de juego
Nombre
Formar palabras Contiguas
Encargado
Wilson Perez
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
63
S.G.P.M.
SRS
Criterio
Medición
de El sistema validara las palabras completas ingresadas por el usuario
Excepciones
Observaciones/ Las casillas donde se ponen las fichas deben ser validas(estar
Justificación
desocupadas)
Caso(s)
Uso
Relacionado
CU16
Requerimiento(s) R0203
CU18
Asociado(s)
CU15
R0803
R0403
R1903
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU16
CU18
CU15
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
64
3
Prioridad
11
64
S.G.P.M.
SRS
Costo
ALTO
Estado
Aprobado
Esfuerzo
10 días
Capa
Servidor
24
25
No.
Requerimiento
R1003
Versión
1.0
Tipo
FuncionalesModo 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
Medición
de El puntaje de cada jugador se modificara dependiendo del color
donde forme la palabras
Excepciones
Observaciones/
Justificación
Caso(s)
Uso
Relacionado
65
CU16
Requerimiento(s) R0803
CU18
Asociado(s)
R0903
65
S.G.P.M.
SRS
CU15
R1103
CU06
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU16
CU18
CU15
CU06
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
66
Riesgo
4
Costo
ALTO
Estado
Aprobado
Esfuerzo
10 días
Prioridad
12
66
S.G.P.M.
SRS
Capa
Servidor
26
27
28
29
No.
Requerimiento
R1103
Versión
1.0
Tipo
FuncionalesModo 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
Medición
de 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
CU06
Asociado(s)
R1203
R1303
Trazabilidad
67
Modelo de
dominio
67
S.G.P.M.
SRS
Documento
Casos de uso:
CU15
CU06
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
4
Costo
ALTO
Estado
Aprobado
Esfuerzo
10 días
Capa
Servidor
30
31
32
68
No.
Requerimiento
R1203
Versión
1.0
Tipo
FuncionalesModo de juego
Prioridad
12
68
S.G.P.M.
SRS
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
Medición
de 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
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU06
CU03
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
69
CU06
Requerimiento(s) R1303
CU03
Asociado(s)
R1103
69
S.G.P.M.
SRS
Riesgo
3
Costo
MEDIO
Estado
Aprobado
Esfuerzo
4 días
Capa
Servidor
Prioridad
11
33
34
No.
Requerimiento
R1303
Versión
1.0
Tipo
FuncionalesModo 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.
Objetivo
Para que jugador tenga la posibilidad de aumentar su puntaje, pero
con un mayor grado de dificultad
Criterio
Medición
de El puntaje del jugador se modificara, cuando se usen las siete fichas
en el tablero
Excepciones
Observaciones/
Justificación
70
70
S.G.P.M.
SRS
Caso(s)
Uso
Relacionado
CU06
Requerimiento(s) R1203
CU15
Asociado(s)
CU16
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU06
CU15
CU16
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
71
Riesgo
3
Costo
MEDIO
Estado
Aprobado
Esfuerzo
4 días
Prioridad
8
R1103
71
S.G.P.M.
SRS
Capa
Servidor
35
36
No.
Requerimiento
R1403
Versión
1.0
Tipo
FuncionalesModo 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
Medición
de 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.
Observaciones/
Justificación
Caso(s)
Uso CU12
Relacionado
Trazabilidad
Modelo
dominio
Documento
Casos de uso:
72
de
Requerimiento(s) R1403
Asociado(s)
R1503
72
S.G.P.M.
SRS
CU12
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
3
Costo
MEDIO
Estado
Aprobado
Esfuerzo
4 días
Capa
Servidor
37
38
No.
Requerimiento
73
Prioridad
R1503
Versión
1.0
Tipo
FuncionalesModo de juego
Nombre
Cambiar fichas transaccionalmente.
Encargado
Andrés Fajardo
10
73
S.G.P.M.
SRS
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
Medición
de Una vez dada la orden de cambio de fichas, el procedimiento
terminará completamente y correctamente.
Excepciones
Observaciones/
Justificación
Caso(s)
Uso CU12
Relacionado
Requerimiento(s) R1403
Asociado(s)
R1703
R2103
Trazabilidad
Modelo
dominio
de
Documento
Casos de uso:
CU12
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
74
74
S.G.P.M.
SRS
Riesgo
3
Costo
MEDIO
Estado
Aprobado
Esfuerzo
4 días
Capa
Servidor
39
40
No.
Requerimiento
Prioridad
8
R1603
Versión
1.0
Tipo
FuncionalesModo de juego
Nombre
Pasar a siguiente turno.
Encargado
Andrés Fajardo
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
Medición
de Una vez oprimido el botón de cambio de turno, el sistema cambia de
turno satisfactoriamente.
Excepciones
Observaciones/
Justificación
Caso(s)
75
Uso CU14
Requerimiento(s) R1103
75
S.G.P.M.
SRS
Relacionado
Trazabilidad
Modelo
dominio
Asociado(s)
de
Documento
Casos de uso:
CU14
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
3
Costo
MEDIO
Estado
Aprobado
Esfuerzo
4 días
Capa
Servidor
41
42
No.
Requerimiento
76
R1703
Prioridad
7
R1703
76
S.G.P.M.
SRS
Versión
1.0
Tipo
FuncionalesModo 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
Medición
de Pasados 2 minutos,
satisfactoriamente.
se
cambia
el
turno
del
Excepciones
Observaciones/
Justificación
Caso(s)
Uso CU14
Relacionado
Trazabilidad
Modelo
dominio
de
Documento
Casos de uso:
CU14
Requerimientos
Asociados
Reglas
77
Requerimiento(s) R1103
Asociado(s)
R1603
jugador
77
S.G.P.M.
SRS
WorDomination
(SPMP Sección
10.1)
Riesgo
3
Costo
MEDIO
Estado
Aprobado
Esfuerzo
4 días
Capa
Servidor
43
44
No.
Requerimiento
8
R1803
Versión
1.0
Tipo
FuncionalesModo 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
Medición
Excepciones
78
Prioridad
de Las fichas se muestran en la pantalla y el jugador puede usarlas para
jugar posteriormente.
78
S.G.P.M.
SRS
Observaciones/
Justificación
Caso(s)
Uso CU11,
Relacionado
CU12
CU16,
CU17
Requerimiento(s) R0103, R0203,
R0603, R0703,
Asociado(s)
R0803, R1403
CU18
Trazabilidad
Modelo
dominio
de
Documento
Casos de uso:
CU11
CU12
CU16
CU17
CU18
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
79
3
Prioridad
10
79
S.G.P.M.
SRS
Costo
MEDIO
Estado
Aprobado
Esfuerzo
4 días
Capa
Servidor
45
46
No.
Requerimiento
R1903
Versión
1.0
Tipo
FuncionalesModo 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
Medición
de 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)
80
Uso CU04,
CU06,
Requerimiento(s) R0103,
R0403,
R0303,
R0703,
80
S.G.P.M.
SRS
Relacionado
Trazabilidad
Modelo
dominio
CU14,
CU15
Asociado(s)
de
Documento
Casos de uso:
CU04,
CU06,
CU14, CU15
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
3
Costo
MEDIO
Estado
Aprobado
Esfuerzo
4 días
Capa
Servidor
47
81
Prioridad
15
R0803, R0903,
R1003, R1103,
R1203, R1303
81
S.G.P.M.
SRS
48
No.
Requerimiento
R2003
Versión
1.0
Tipo
FuncionalesModo 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.
Objetivo
Evitar más de dos turnos sin jugadas correctas.
Criterio
Medición
de 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 CU04,
Relacionado
CU05,
CU14,
CU15
Trazabilidad
Modelo
dominio
Documento
82
de
Requerimiento(s) R0103,
R0403,
Asociado(s)
R0803,
R1003,
R1203,
R1603,
R1903
R0303,
R0703,
R0903,
R1103,
R1303,
R1703,
82
S.G.P.M.
SRS
Casos de uso:
CU04,
CU05,
CU14, CU15
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
3
Costo
MEDIO
Estado
Aprobado
Esfuerzo
4 días
Capa
Servidor
49
50
51
52
No.
Requerimiento
83
R2103
Versión
1.0
Tipo
Funcionales-
Prioridad
13
83
S.G.P.M.
SRS
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
Medición
de La partida debe tener un tiempo límite (una hora).
Excepciones
Observaciones/
Justificación
Caso(s)
Uso CU06
Relacionado
CU08
CU19
Trazabilidad
Modelo
dominio
de
Documento
Casos de uso:
R2203
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
84
Requerimiento(s) R2203
Asociado(s)
84
S.G.P.M.
SRS
10.1)
Riesgo
3
Costo
MEDIO
Estado
Aprobado
Esfuerzo
3 días
Capa
Servidor
53
54
55
No.
Requerimiento
13
R2203
Versión
1.0
Tipo
FuncionalesModo 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
Medición
de La aplicación se finalizará cuando termine el tiempo límite, indicando
antes de finalizar, quien fue el ganador de la partida.
Excepciones
Observaciones/
85
Prioridad
85
S.G.P.M.
SRS
Justificación
Caso(s)
Uso CU06,
Relacionado
CU08
Requerimiento(s) R2103
Asociado(s)
CU19
Trazabilidad
Modelo
dominio
de
Documento
Casos de uso:
R2203
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
86
Riesgo
3
Costo
MEDIO
Estado
Aprobado
Esfuerzo
3 días
Capa
Servidor
Prioridad
13
86
S.G.P.M.
SRS
56
57
No.
Requerimiento
R2303
Versión
1.0
Tipo
FuncionalesModo 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.
Objetivo
Informar a los jugadores quien fue el ganador.
Criterio
Medición
de 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 CU15
Relacionado
Trazabilidad
Modelo
dominio
de
Documento
Casos de uso:
Requerimientos
Asociados
87
Requerimiento(s) R0303, R1703,
R1903, R2003,
Asociado(s)
R2103, R2203
87
S.G.P.M.
SRS
R0303, R1703,
R1903, R2003,
R2103, R2203
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
3
Costo
MEDIO
Estado
Aprobado
Esfuerzo
3 días
Capa
Servidor
Prioridad
57.2.1 Funcionalidad 2: Registro y Autenticación
88
No.
Requerimiento
R240202
Versión
1.0
Tipo
FuncionalesModo
de
Autenticación
Nombre
Crear perfil de jugador
Encargado
Andrés Fajardo
10
88
S.G.P.M.
SRS
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
Medición
de
Excepciones
Observaciones/
Justificación
Caso(s)
Uso CU01,
Relacionado
CU07,
CU08,
CU09,
CU10
Trazabilidad
Modelo
dominio
de
Documento
Casos de uso:
Requerimientos
Asociados
R2502
R2603
Reglas
WorDomination
(SPMP Sección
89
Requerimiento(s) R2502
Asociado(s)
R2603
89
S.G.P.M.
SRS
10.1)
Riesgo
3
Costo
MEDIO
Estado
Aprobado
Esfuerzo
5 días
Capa
Servidor
58
59
No.
Requerimiento
12
R2502
Versión
1.0
Tipo
FuncionalesModo
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
Medición
Excepciones
90
Prioridad
de
90
S.G.P.M.
SRS
Observaciones/
Justificación
Caso(s)
Uso CU01
Relacionado
CU07
Requerimiento(s) R2402
Asociado(s)
CU08
Trazabilidad
Modelo
dominio
de
Documento
Casos de uso:
Requerimientos
Asociados
R2502
R2603
Reglas
WorDomination
(SPMP Sección
10.1)
91
Riesgo
3
Costo
MEDIO
Estado
Aprobado
Esfuerzo
3 días
Prioridad
10
R2603
91
S.G.P.M.
SRS
Capa
Servidor
60
61
No.
Requerimiento
R2603
Versión
1.0
Tipo
FuncionalesModo
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
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
Medición
de
Excepciones
Observaciones/
Justificación
Caso(s)
Uso CU01,
Requerimiento(s) R2402
Relacionado
CU03,
Asociado(s)
R2502
CU07, CU08
Trazabilidad
Modelo
dominio
Documento
92
de
92
S.G.P.M.
SRS
Casos de uso:
Requerimientos
Asociados
R2402
R2502
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
3
Costo
MEDIO
Estado
Aprobado
Esfuerzo
3 días
Capa
Servidor
62
63
64
No.
Requerimiento
93
R2703
Versión
1.0
Tipo
FuncionalesModo
de
Autenticación
Prioridad
10
93
S.G.P.M.
SRS
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
Medición
Excepciones
de El jugador deberá ingresar los criterios de información básicos para
poder acceder al juego
Datos Inválidos, Intente de nuevo
Observaciones/ Ninguna
Justificación
Caso(s)
Uso
Relacionado
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU01
CU02
Requerimientos
Asociados
R2603
Reglas
Wordomination
(SPMP Sección
94
CU01
Requerimiento(s) R2603
CU02
Asociado(s)
94
S.G.P.M.
SRS
10.1)
Riesgo
3
Costo
Medio
Estado
Aprobado
Esfuerzo
15 días
Capa
Servidor
65
No.
Requerimiento
R2803
Versión
1.0
Tipo
FuncionalesModo
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
Medición
Prioridad
14
de Se dará información y advertirá de que la información a ingresar ya se
encuentra
Excepciones
Observaciones/ Ninguna
Justificación
Caso(s)
Uso
Relacionado
95
CU01
Requerimiento(s) R2502
CU02
Asociado(s)
R2603
95
S.G.P.M.
SRS
CU07
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU01
CU02
CU07
Requerimientos
Asociados
R2502
R2603
Reglas
WorDomination
(SPMP Sección
10.1)
96
Riesgo
4
Costo
Medio
Estado
Aprobado
Esfuerzo
15 dias
Capa
Servidor
66
No.
Requerimiento
R2903
Prioridad
12
96
S.G.P.M.
SRS
Versión
1.0
Tipo
FuncionalesModo
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.
Objetivo
Permitirá al sistema informar al usuario de la creación exitosa o no de
la acción crear jugador
Criterio
Medición
de El jugador estará informado si su perfil pudo ser creado, para poder
jugar.
Excepciones
Observaciones/ Es obligatorio tener un usuario para poder acceder a una partida del
Justificación
juego
Caso(s)
Uso
Relacionado
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU01
Requerimientos
Asociados
R2402
R2502
R2603
97
CU01
Requerimiento(s) R2402, R2502,
R2603, R2703
Asociado(s)
97
S.G.P.M.
SRS
R2703
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
5
Costo
Alto
Estado
Aprobado
Esfuerzo
22 dias
67
No.
Requerimiento
R3002
Versión
1.0
Tipo
FuncionalesModo
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
Medición
Prioridad
de El jugador recibirá la confirmación del éxito o no de la acción por
medio de un mensaje visual
Excepciones
Observaciones/ Para eliminar el registro deberá existir
Justificación
98
12
98
S.G.P.M.
SRS
Caso(s)
Uso
Relacionado
CU02
CU03
Requerimiento(s) R2402,
R2603,
Asociado(s)
R2703
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU01
Requerimientos
Asociados
R2402
R2502
R2603
R2703
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
3
Costo
Medio
Estado
Aprobado
Esfuerzo
25 dias
Capa
Servidor
68
99
Prioridad
10
R2502,
99
S.G.P.M.
SRS
No.
Requerimiento
R3102
Versión
1.0
Tipo
FuncionalesModo
de
Autenticación
Nombre
Ver Perfil
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
Medición
Excepciones
de El Jugador deberá poder ser informado del perfil pedido
Al no existir el perfil, dará mensaje visual de no valido
Observaciones/ El jugador deberá existir para poder ver la información del perfil
Justificación
Caso(s)
Uso
Relacionado
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU03
Requerimientos
Asociados
R2603
100
CU03
Requerimiento(s) R2603
Asociado(s)
100
S.G.P.M.
SRS
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
4
Costo
Medio
Estado
Aprobado
Esfuerzo
14 dias
Capa
Servidor
Prioridad
11
69
70
No.
Requerimiento
R3203
Versión
1.0
Tipo
FuncionalesModo
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
Medición
Excepciones
101
de Se tendrá la opción de eliminar todos los archivos creados por medio
de la aplicación como opción adicional.
101
S.G.P.M.
SRS
Observaciones/ Permitirá una mejor eficiencia de los recursos de hardware
Justificación
Caso(s)
Uso CU07
Relacionado
CU08
Trazabilidad
Requerimiento(s)
Asociado(s)
Modelo de
dominio
Documento
Casos de uso:
CU07
CU08
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
2
Costo
Bajo
Estado
Aprobado
Esfuerzo
2 dias
Capa
Servidor
71
72
102
Prioridad
9
102
S.G.P.M.
SRS
73
No.
Requerimiento
R3302
Versión
1.0
Tipo
FuncionalesModo
de
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
Medición
de El jugador tendrá la opción de seguir o no en el juego
Excepciones
Observaciones/ El usuario dará finalizar cuando se quiera salir de una partida.
Justificación
Caso(s)
Uso
Relacionado
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU08
Requerimientos
Asociados
103
CU08
Requerimiento(s) R3402
Asociado(s)
103
S.G.P.M.
SRS
R3402
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
4
Costo
Medio
Estado
Aprobado
Esfuerzo
5 días
Capa
Servidor
Prioridad
11
74
75
No.
Requerimiento
R3402
Versión
1.0
Tipo
FuncionalesModo 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
Medición
104
de El usuario podrá guardar su partida sino quiere seguirla en el tiempo
dado
104
S.G.P.M.
SRS
Excepciones
Observaciones/ Dar la opción de jugar en otro momento la misma partida
Justificación
Caso(s)
Uso CU07
Relacionado
CU08
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU07
CU08
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
105
Riesgo
4
Costo
Bajo
Estado
Aprobado
Esfuerzo
15 días
Capa
Servidor
76
77
No.
R3503
105
S.G.P.M.
SRS
Requerimiento
Versión
1.0
Tipo
FuncionalesModo de juego
Nombre
Terminar Partida(Desconexion)
Encargado
Oscar Gómez Herrera
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
Medición
de El sistemas dará como terminado cualquier jugo al no haber conexión
Excepciones
Observaciones/ Al no haber conexión el sistema se perderá la información de la
Justificación
partida(Si no se guardo)
Caso(s)
Uso
Relacionado
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
106
Requerimiento(s)
Asociado(s)
106
S.G.P.M.
SRS
10.1)
Riesgo
5
Costo
Alto
Estado
Aprobado
Esfuerzo
8 días
Capa
Servidor
Prioridad
14
77.2.1 Funcionalidad 3: Administración
78
No.
Requerimiento
R3602
Versión
1.0
Tipo
FuncionalesModo
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
Medición
de El administrador tendrá la opción de eliminar cualquier jugador por
conducta indebida
Excepciones
Observaciones/ El jugador será sacado de la partidas y eliminado su perfil.
Justificación
107
107
S.G.P.M.
SRS
Caso(s)
Uso CU02
Relacionado
CU03
Trazabilidad
Requerimiento(s)
Asociado(s)
Modelo de
dominio
Documento
Casos de uso:
CU07
CU08
Requerimientos
Asociados
Reglas
WorDomination
(SPMP Sección
10.1)
Riesgo
4
Costo
Bajo
Estado
Aprobado
Esfuerzo
2 dias
Capa
Servidor
79
108
No.
Requerimiento
R3702
Versión
1.0
Prioridad
10
108
S.G.P.M.
SRS
Tipo
FuncionalesModo
Administración
Nombre
Eliminar Archivos(Administrador)
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
Medición
de Se podrá eliminar el archivo de un jugador especifico o varios de
varios jugadores
Excepciones
Observaciones/ Mejorara la eficiencia del juego, para poder eliminar archivos
Justificación
antiguos y no usados
Caso(s)
Uso
Relacionado
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU02
CU05
Requerimientos
Asociados
R3002
Reglas
WorDomination
(SPMP Sección
109
CU02
Requerimiento(s) R3002
CU05
Asociado(s)
109
S.G.P.M.
SRS
10.1)
Riesgo
5
Costo
Alto
Estado
Aprobado
Esfuerzo
15 días
Capa
Servidor
Prioridad
12
79.2.1 Funcionalidad 4: Consultas
No.
Requerimiento
R3802
Versión
1.0
Tipo
FuncionalesModo
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
Medición
Excepciones
de El jugador deberá indicar su ID para poder mostrar su informacion
ID invalido
Observaciones/ Mostrar información de cada jugador
Justificación
Caso(s)
110
Uso
CU03
Requerimiento(s) R3902
110
S.G.P.M.
SRS
Relacionado
Trazabilidad
CU06
Asociado(s)
Modelo de
dominio
Documento
Casos de uso:
CU03
CU06
Requerimientos
Asociados
R3902
Reglas
Wordomination
(SPMP Sección
10.1)
Riesgo
2
Costo
Medio
Estado
Aprobado
Esfuerzo
12 días
Capa
Servidor
80
81
82
83
111
No.
Requerimiento
R3902
Versión
1.0
Tipo
Funcionales-
Prioridad
8
111
S.G.P.M.
SRS
Modo
Consulta
de
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
Medición
Excepciones
de El jugador solicitante deberá ingresar la información básica para
obtener la información(Nombre y Contraseña)
Datos Inválidos, Intente de nuevo
Observaciones/ Después de 3 errores en la validación de datos el juego se sale.
Justificación
Caso(s)
Uso
Relacionado
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU03
CU06
Requerimientos
Asociados
R2603
R2703
Reglas
Wordomination
(SPMP Sección
10.1)
112
CU03
Requerimiento(s) R2603
CU06
Asociado(s)
R2703
112
S.G.P.M.
SRS
Riesgo
4
Costo
Medio
Estado
Aprobado
Esfuerzo
19 días
Capa
Servidor
Prioridad
12
84
No.
Requerimiento
R4002
Versión
1.0
Tipo
FuncionalesModo
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
Medición
de En el momento de realizar esta consulta, deberá mostrar la
información correspondiente a las estadísticas de los demás
jugadores.
Excepciones
Observaciones/ Ninguna
Justificación
Caso(s)
Uso
Relacionado
113
CU03
CU06
Requerimiento(s) R1003,
R3802
Asociado(s)
CU20
R3902
R3102,
113
S.G.P.M.
SRS
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU03, CU06,
CU20
Requerimientos
Asociados
R1003, R3102,
R3802
R3902
Reglas
Wordomination
(SPMP Sección
10.1)
Riesgo
3
Costo
Medio
Estado
Aprobado
Esfuerzo
2 días
Capa
Servidor
85
86
87
No.
Requerimiento
114
R4102
Prioridad
10
114
S.G.P.M.
SRS
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
Medición
de 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/ Ninguna
Justificación
Caso(s)
Uso
Relacionado
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU21
Requerimientos
Asociados
R5004
Reglas
115
CU21
Requerimiento(s) R5004
Asociado(s)
115
S.G.P.M.
SRS
Wordomination
(SPMP Sección
10.1)
Riesgo
4
Costo
Medio
Estado
Aprobado
Esfuerzo
2 dias
Capa
Servidor
Prioridad
10
88
89
90
91
No.
Requerimiento
R4202
Versión
1.0
Tipo
FuncionalesModo
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
Medición
Excepciones
116
de EL juego debe mostrar durante todo el juego las fichas que van
quedando después de haber colocado una nueva palabra en el
tablero hasta el final del juego.
116
S.G.P.M.
SRS
Observaciones/ Ninguna
Justificación
Caso(s)
Uso
Relacionado
Trazabilidad
CU16
Requerimiento(s) R0203
CU17
Asociado(s)
Modelo de
dominio
Documento
Casos de uso:
CU16, CU17
Requerimientos
Asociados
R0203, R0703
Reglas
Wordomination
(SPMP Sección
10.1)
Riesgo
4
Costo
Medio
Estado
Aprobado
Esfuerzo
2 días
Capa
Servidor
Prioridad
4.3 Requerimientos de Desempeño
No.
117
R4303
12
R0703
117
S.G.P.M.
SRS
Requerimiento
Versión
1.0
Tipo
Dinámicos
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
Medición
y
de Usuarios conectados de forma simultanea
Excepciones
Observaciones/ Ninguna
Justificación
Caso(s)
Uso
Relacionado
Trazabilidad
Modelo de
dominio
Documento
Casos de uso:
CU09, CU10
Requerimientos
Asociados
R4403, R4601
118
CU09
Requerimiento(s) R4403
CU10
Asociado(s)
R4601
118
S.G.P.M.
SRS
Reglas
Wordomination
(SPMP Sección
10.1)
119
Riesgo
5
Prioridad
15
Costo
Alto
Estado
Aprobado
Esfuerzo
2 días
Capa
Servidor
No.
Requerimiento
R4403
Versión
1.0
Tipo
Dinámicos
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á
y
119
S.G.P.M.
SRS
tener mínimo 2 jugadores, de lo contrario el juego restringirá el inicio
de la partida
Criterio
Medición
de 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/ Ninguna
Justificación
Caso(s)
Uso
Relacionado
Trazabilidad
CU09
Requerimiento(s) R4403
CU10
Asociado(s)
Modelo de
dominio
Documento
Casos de uso:
CU09, CU10
Requerimientos
Asociados
R4403, R4601
Reglas
Wordomination
(SPMP Sección
10.1)
120
Riesgo
5
Costo
Alto
Prioridad
15
R4601
120
S.G.P.M.
SRS
Estado
Aprobado
Esfuerzo
2 días
Capa
Servidor
No.
Requerimiento
R4503
Versión
1.0
Tipo
Dinámicos
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.
Criterio
Medición
y
de Se espera que el juego reaccione de manera inmediata ante
cualquier acción que realicen los jugadores en la aplicación
Excepciones
Observaciones/ Latencia del juego
Justificación
Caso(s) Uso
Relacionado
121
Requerimiento(s)
Asociado(s)
121
S.G.P.M.
SRS
Trazabilidad
Modelo de
dominio
Riesgo
4
Costo
Medio
Estado
Aprobado
Esfuerzo
1 días
Capa
Servidor
Prioridad
14
4.4 Restricciones De Diseño
No.
Requerimiento
R4601
Versión
1.0
Tipo
Restricciones de
Funcionalidad
Nombre
Comunicación
Encargado
Andrés Hidalgo
Descripción
El sistema debe comunicarse por medio de una arquitectura ClienteServidor.
Objetivo
Hace parte de las restricciones estipuladas por el cliente en el
acuerdo del proyecto
Criterio
122
de En el momento que un computador este dando repuestas a los
122
S.G.P.M.
SRS
Medición
demás durante el juego, se dará por exitosa la comunicacion
Excepciones
Observaciones/ Ninguna
Justificación
Caso(s)
Uso
Relacionado
Trazabilidad
Requerimiento(s) R4601
Asociado(s)
Modelo de
dominio
Requerimientos
Asociados
R4601
Reglas
Wordomination
(SPMP Sección
10.1)
123
Riesgo
3
Costo
Medio
Estado
Aprobado
Esfuerzo
2 dias
Capa
Servidor
Prioridad
12
123
S.G.P.M.
SRS
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
Medición
de Utilizando lenguaje orientado a objetos (JAVA), en el desarrollo del
producto.
Excepciones
Observaciones/ Ninguna
Justificación
Caso(s)
Uso
Relacionado
Trazabilidad
Requerimiento(s)
Asociado(s)
Modelo de
dominio
Reglas
Wordomination
(SPMP Sección
10.1)
124
Riesgo
3
Costo
Medio
Estado
Aprobado
Prioridad
12
124
S.G.P.M.
SRS
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
Medición
de La aplicación deberá estar acorde al modelo de dominio diseñado
Excepciones
Observaciones/ Ninguna
Justificación
Caso(s)
Uso
Relacionado
Trazabilidad
Modelo de
dominio
Reglas
Wordomination
125
Requerimiento(s)
Asociado(s)
125
S.G.P.M.
SRS
(SPMP Sección
10.1)
Riesgo
3
Costo
Medio
Estado
Aprobado
Esfuerzo
2 días
Capa
Servidor
No.
Requerimiento
R4901
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
Medición
8
de El Juego debe estar en la capacidad de ejecutarse de forma correcta
en este sistema operativo.
Excepciones
Observaciones/ Ninguna
126
Prioridad
126
S.G.P.M.
SRS
Justificación
Caso(s) Uso
Relacionado
Asociado(s)
Trazabilidad
SPMP
Riesgo
4
Costo
Medio
Estado
Aprobado
Esfuerzo
2 días
Capa
Servidor
No.
Requerimiento
R5004
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
Medición
Casos de Uso
Prioridad
14
de 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/ Ninguna
127
Requerimiento(s)
127
S.G.P.M.
SRS
Justificación
Caso(s) Uso
Relacionado
CU02
Requerimiento(s) R4102
CU07
Asociado(s)
R5104
CU12
Trazabilidad
SPMP: Reglas
de juego
Riesgo
3
Costo
Bajo
Estado
Aprobado
Esfuerzo
2 dias
Capa
Servidor
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
Medición
128
Prioridad
8
de 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.
128
S.G.P.M.
SRS
Excepciones
Observaciones/ Ninguna
Justificación
Caso(s) Uso
Relacionado
129
Requerimiento(s) R4102
Asociado(s)
Trazabilidad
SPMP
Riesgo
3
Costo
Bajo
Estado
Aprobado
Esfuerzo
2 días
Capa
Servidor
No.
Requerimiento
R5201
Versión
1.0
Tipo
Consulta
Nombre
Diseño Agradable (GUI fuerte)
Encargado
Andrés Hidalgo
Prioridad
8
R5004
129
S.G.P.M.
SRS
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
Medición
de La aceptación de la apariencia debe ser superior al 70% , teniendo en
cuenta su buen diseño y fácil manejo.
Excepciones
Observaciones/ Ninguna
Justificación
Caso(s) Uso
Relacionado
130
Requerimiento(s)
Asociado(s)
Trazabilidad
SPMP
Riesgo
5
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
Prioridad
14
130
S.G.P.M.
SRS
Objetivo
Criterio
Medición
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)
de El sistema deberá correr correctamente en las salas
Excepciones
Observaciones/ Ninguna
Justificación
Caso(s) Uso
Relacionado
Trazabilidad
SPMP
Riesgo
5
Costo
Medio
Estado
Aprobado
Esfuerzo
2 días
Capa
Servidor
Requerimiento(s)
Asociado(s)
Prioridad
14
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
131
131
S.G.P.M.
SRS
ATRIBUTO
Confiabilidad
132
APLICACION
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
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
132
S.G.P.M.
SRS
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.
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:
133
133
S.G.P.M.
SRS
Tipos de
datos
almacenados
Frecuencia de
acceso
Uso de
Primary key
Tipo de
consultas
utilizadas
Indexación de
los datos
Ilustración 7: Características Bases de Datos




134
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
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.
134
S.G.P.M.
SRS

135
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.
135
S.G.P.M.
SRS
5 Anexos
136
136