SRS v.0.5 (Plantilla Corregida)

S.G.P.M.
SRS
S.G.P.M.
31 / 10 / 09
SRS Especificacin de Requerimientos de Software
V.0.2
Andres Fajardo Bermudez

Andres Hidalgo
Hernan Garcia Pea
Oscar Gomez
Wilson Perez
HISTORIAL DE CAMBIOS
S.G.P.M.
SRS
VERSION
V.0.1
V.0.2
FECHA
SECCIN
MODIFICADA
1.1, 1.3, 1.4.
DESCRIPCION
CAMBIOS
Sabado, 5
Se realizaron
de
aportes de
Septiembr
ideas para las
e de 2009.
secciones
descritas.
Sabado, 12 1.2, 1.5
Se
de
completaron
Septiembr
las secciones
e de 2009.
faltantes.
Tabla 1: Historial de cambios
RESPONSAB
LES
S.G.P.M.
S.G.P.M.
S.G.P.M.
SRS
TABLA DE CONTENIDO
TABLA DE CONTENIDO.............................................................................3
LISTA DE TABLAS.....................................................................................5
LISTA DE ILUSTRACIONES.........................................................................6
1 INTRODUCCIN.....................................................................................7
1.1
1.2
1.3
1.4
1.5
PROPSITO........................................................................................................... 7
ALCANCE............................................................................................................. 8
DEFINICIONES, ACRNIMOS, Y ABREVIACIONES............................................................9
REFERENCIAS...................................................................................................... 13
APRECIACIN GLOBAL........................................................................................... 14
2 CICLO DE VIDA DE REQUERIMIENTOS...................................................16

2.1 IDENTIFICACIN DE STAKEHOLDERS.........................................................................16
2.2 NECESIDADES DEL USUARIO...................................................................................17
2.3 PARTICIPACIN POR ROLES....................................................................................17
2.4 PROCESO DE REQUERIMIENTOS...............................................................................18
2.4.1 Identificacin de Requerimientos.............................................................18
2.4.2 Especificacin de Requerimientos...........................................................21
2.4.3 Priorizacin de Requerimientos...............................................................22
2.4.4 Trazabilidad.............................................................................................. 26
2.4.5 Validacin y verificacin...........................................................................26
2.5 ADMINISTRACIN DE REQUERIMIENTOS.....................................................................26
2.6 INTERFACES........................................................................................................ 26
3 DESCRIPCIN GLOBAL.........................................................................27
3.1 PERSPECTIVA DEL PRODUCTO.................................................................................27
3.1.1 Interfaces con el sistema..........................................................................27
3.1.2 Interfaces con el usuario..........................................................................28
3.1.3 Interfaces con el Hardware.......................................................................30
3.1.4 Interfaces con el Software........................................................................30
3.1.5 Interfaces de Comunicacin.....................................................................35
3.1.6 Restricciones de Memoria.........................................................................35
3.1.7 Operaciones.............................................................................................35
3.1.8 Requerimientos de Adaptacin del Sitio...................................................36
3.2 FUNCIONES DEL PRODUCTO...................................................................................37
3.3 CARACTERSTICAS DEL USUARIO.............................................................................37
3.4 RESTRICCIONES................................................................................................... 39
3.5 MODELO DEL DOMINIO......................................................................................... 40
3.6 SUPOSICIONES Y DEPENDENCIAS.............................................................................43
4 REQUERIMIENTOS ESPECFICOS...........................................................45
S.G.P.M.
SRS
4.1 REQUERIMIENTOS DE INTERFACES EXTERNAS.............................................................51

4.1.1 Interfaces con el Usuario..........................................................................51
4.1.2 Interfaces con el Hardware.......................................................................52
4.1.3 Interfaces con el Software........................................................................54
4.1.4 Interfaces de Comunicaciones..................................................................55
4.2 CARACTERSTICAS DEL PRODUCTO DE SOFTWARE.......................................................55
4.3 REQUERIMIENTOS DE DESEMPEO...........................................................................57
4.4 RESTRICCIONES DE DISEO...................................................................................59
4.5 ATRIBUTOS DEL SISTEMA DE SOFTWARE (NO FUNCIONALES)........................................60
4.5.1 Confiabilidad............................................................................................ 60
4.5.2 Disponibilidad........................................................................................... 60
4.5.3 Seguridad.................................................................................................60
4.5.4 Mantenibilidad..........................................................................................61
4.5.5 Eficiencia.................................................................................................. 61
4.5.6 Facilidad de Uso.......................................................................................61
4.6 REQUERIMIENTOS DE LA BASE DE DATOS..................................................................61
5 ANEXOS............................................................................................. 64
S.G.P.M.
SRS
Lista de Tablas
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
1:
2:
3:
4:
5:
6:
7:
Historial de cambios......................................................................................1
Acrnimos...................................................................................................... 7
Interfaces con el Software...........................................................................13
Descripcin de las Caractersticas del Usuario............................................17
Definiciones del Modelo de Dominio............................................................19
Formato de documentacin del Modelo del Dominio...................................20
Documentacin de Requerimientos.............................................................27
S.G.P.M.
SRS
Lista de Ilustraciones
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
Ilustracin
1: Propsito...............................................................................................5
2: Alcance.................................................................................................6
3: Apreciacin Global.................................................................................7
4: Tipos de productos de software.............................................................8
5: Interfaces con el usuario.....................................................................10
6: Operaciones........................................................................................15
7: Tips para definir funciones del producto..............................................16
8: Caractersticas del Usuario..................................................................17
9: Restricciones.......................................................................................18
10: Limitaciones......................................................................................18
11: Descripcin documentacin del modelo del dominio.........................20
12: Suposiciones.....................................................................................21
13: Dependencias [1]..............................................................................21
14: Distribucin de requerimientos.........................................................23
15: Caractersticas de los Requerimientos...............................................26
16: Documentacin de Requerimientos...................................................28
17: Interfaces con el Usurario..................................................................29
18: Interfaces de Hardware.....................................................................30
19: Interfaces con el Software.................................................................31
20: Divisin por Funcionalidades.............................................................32
21: Ejemplo Enunciado Requerimientos..................................................34
22: Atributos de Calidad a tener en cuenta.............................................35
23: Caractersticas de Confiabilidad........................................................36
24: Caractersticas de Disponibilidad......................................................37
25: Caractersticas de Seguridad.............................................................37
26: Caractersticas de Mantenibilidad.....................................................38
27: Portabilidad del Sistema....................................................................38
28: Caractersticas Bases de Datos.........................................................39
1 Introduccin
1.1 Propsito
El propsito o razn por la cual es vital la efectiva realizacin 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 caractersticas, capacidades o calidad de un sistema con
el fin de que tenga valor y utilidad para un cliente o usuario final, convirtindose
as en la clave del xito (o fracaso) de un proyecto tcnico, y la base de el
trabajo que viene en su futuro desarrollo, por lo cual es importante realizar una
buena documentacin de la especificacin de los requerimientos, originando de
esta manera que se satisfagan los objetivos del cliente correctamente [4].
Para el contexto de la materia de Ingeniera de Software, se obtendrn
requerimientos del proyecto escogido (WorDomination) con la finalidad descrita
anteriormente, para lo cual se describirn sus requerimientos ms importantes
mediante procedimientos descritos posteriormente.
Vale la pena considerar que -como se mencion en el SPMP previamentepuesto que es imposible calcar o hacer una rplica exacta de las
funcionalidades de un software, el SRS siempre estar incompleto en cuanto a
la identificacin 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 especificacin puede identificar
mejor los casos de uso asociados y con base en esto realizar un desarrollo e
implementacin efectivos) y para el grupo S.G.P.M., puesto que como
ingenieros de sistemas se tiene
la responsabilidad de proveer la
documentacin correspondiente de requerimientos y sus funciones de alto nivel
que sern implementadas. [10]
1.2 Alcance
S.G.P.M. est encargado de la realizacin de desarrollo de una aplicacin que
modela el juego original Scrabble [26], junto con su documentacin 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.
Bsicamente, se manejarn dos tipos de usuarios del software: el jugador (o
clientes) y el administrador (o servidor), y sus funcionalidades son las que se
muestran a continuacin (tambin se pueden observar en la Seccin 2.1.7
Funcionamiento):
TIPO DE USUARIO
Administrador
Jugador
FUNCIONALIDAD
Crear partidas
Lanzar Partidas
Cargar Partidas.
Usuarios
Crear Jugador
Borrar Jugador
Ver Detalles Jugador
Aadir 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
1.3 Definiciones, Acrnimos, y Abreviaciones

A
Administrador de Configuraciones [2]: Es el encargado de controlar la

evolucin del sistema de Software. Incluye identificacin (reflejar estructura
del producto y sus componentes con sus respectivas ids de versiones y id
de configuracin), control (tomar decisiones sobre la salida de un producto
y sus cambios travs del ciclo de vida asegurando consistencia segn la
lnea base), registro de estado (recordar y reportar sobre el estado de los
componentes y sus peticiones de cambios), auditora y revisin (validar
que el producto est completo y mantener su consistencia a travs de
componentes, asegurando que estn 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.
Aplicacin Cliente- Servidor: Una aplicacin 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 adems 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.I.: Entradas externas.

E.O.: Salidas externas (con operacin matemtica).
E.Q.: Consultas sobre el sistema.
Entregables del proyecto [13]: Artefactos diseados para el cliente.
G Gerente de Proyecto [3]: El gerente es una persona encargada de la
gestin 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, enfrentndose a dos barreras importantes:
complejidad y cambio.
Gestor de Calidad [9]: Persona encargada del plan de aseguramiento de
calidad en el Software, especificando claramente cual ser el propsito del
plan del proyecto, la organizacin y los estndares que se usarn.
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].
IDE [1]: (Integrated Development Environment - Entorno integrado de
desarrollo). Aplicacin compuesta por un conjunto de herramientas tiles
para un programador.
IEEE [7]: IEEE es una organizacin sin nimo de lucro, una asociacin
lder profesional en el avance de la tecnologa. Originalmente era un
acrnimo para Instituto de Ingenieros Electrnicos y Elctricos pero hoy
en da se ha expandido de tal manera que tan solo le llamamos IEEE
(pronunciado I Triple E).
J JDBC: Java database Connectivity: Librera de Java que facilita la labor de
conexin a una base de datos desde cualquier IDE.
L Lnea 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 administracin de
configuraciones. Un producto de trabajo del documento base puede ser el
origen de futuros desarrollos.
P Porcentaje de avance [6]: Son documentos que irn indicando el
porcentaje de avance que se lleva de distintas lneas base de un
documento
Producto de Trabajo [6]: Es todo elemento tangible que resulte en funcin
de realizar un proyecto, actividad o tarea. Ej. Requisitos de clientes, plan
de proyecto, especificaciones funcionales, documentos de diseo, cdigo
fuente y objeto, manual del usuario, instrucciones de instalacin, planes de
pruebas, etc
Puntos de Funcin: Tcnica estndar utilizada para la medicin del
tamao del software
R Requerimiento: Atributo vital y necesarios en un sistema, es una
declaracin que identifica un factor de caractersticas, capacidades o
calidad de un sistema para que tenga valor y utilidad para un cliente o
usuario final
Requerimiento Completo [14]:
Requerimiento que describa completamente la funcionalidad a ser
entregada, conteniendo toda la informacin necesaria para el desarrollador
para que disee e implemente esa parte de la funcionalidad.
Si se sabe que no se tiene an cierta informacin 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 construccin de
dicha porcin.
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 recoleccin de los mismos, con el fin de que este mencione
lo que se puede hacer o no ya sea por restricciones tcnicas o de costo.
Para esto son importantes el desarrollo incremental de la aplicacin y los
prototipos, que permiten evaluar la factibilidad de requerimientos.
Requerimiento Necesario [14]:
Cada requerimiento debe documentar una capacidad que el cliente
realmente necesite o que se requiera para que el sistema se adapte a un
requerimiento externo o un estandar. Cada requerimiento debe originarse
de una fuente que tenga la autoridad de especificar requerimientos, bien
sea por el mismo cliente, casos de uso, regla del negocio, etc.
Requerimiento No ambiguo [14]:
Todos los lectores de un requerimiento deben obtener una y solo una
interpretacin 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 segn el usuario,
por supuesto que adems debe ser entendible.
Requerimiento Priorizable [14]:
Cada requerimiento funcional, caracterstica o caso de uso debe tener
asignada una prioridad de acuerdo a su importancia segn el lanzamiento
de un producto en particular. Si todos se consideran igual de importantes,
ser muy difcil para que el gerente del proyecto pueda responder
efectivamente a estimaciones de costos o presupuesto, prdida de
personal, o nuevos requerimientos que salgan del desarrollo.
Requerimiento Verificable [14]:
Es importante desarrollar pruebas o usar otros mtodos de verificacin
(como inspeccin o demostracin) 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 cuestin de opinin y no de anlisis objetivo.
Los requerimientos que no sean completos, consistentes y no ambiguos,
tampoco son verificables.
S.D.D. [8]: Software Design Document. Es el documento resultado del
proceso de diseo, describe prcticas recomendadas para describir los
diseos de software y especifica la informacin que debe contener,
adems de recomendar la manera en que debe organizarse.
S.P.M.P. [6]: Software Project Management Plan: Es el documento de Plan
Para la Gestin de Proyectos de Software, en el cual se mostrar el plan
para la gestin definiendo funciones tcnicas y de gestin 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 especificacin de
las funciones que realiza un determinado producto de software, programa
o conjunto de programas en un determinado entorno. Este documento
puede desarrollarlo personal representativo de la parte suministradora, o
de la parte cliente; si bien es aconsejable la intervencin de ambas partes.
Tabla 2: Definiciones, acrnimos y abreviaciones.
1.4 Referencias
[1] Definicin de IDE:
http://www.alegsa.com.ar/Dic/ide.php
[2] Ian sommerville, Ingeniera de software, Sptima edicin, 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 planificacin de proyectos de
software:
www.pgsi-g5.googlecode.com/files/T9899_ICaballero.pdf
[7] Definicin de IEEE tomada de:
http://www.ieee.org/web/aboutus/home/index.html
[8] Definicin 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, Ingeniera del Software, McGraw-Hill, 2002.
[13] Dorota Huizinga / Adam Kolawa, Automated Defect Prevention, Wiley, 2007.
[14] Karl E. Wiegers, Software Requirements 2nd Edition, Microsoft Press, 2003
[15] Jag Sodhi & Prince Sodhi, IT Project Management Handbook,
Management Concepts, Inc, 2002
[16] Entrepreneur Press and Sid Kemp, Project Management Made Easy, 2006.
[17] Jennifer Greene & Andrew Stellman, Head First Pmp, O Reilly, 2009.
[18] Stephen Withall, Software Requirement Patterns, Microsoft Press, 2007
[19] Ana Maria Ortiz, SRS y Calidad de Requerimientos.
[20] Luis Carlos Diaz - Miguel Torres, Las Buenas Prcticas de la Ingeniera 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] Aybke 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] Definicin de Scrabble. Disponible en:

http://es.wikipedia.org/wiki/Scrabble
[27] Construx Software Builders, Inc, 2000- 2002.
Disponible en: www.construx.com
1.5 Apreciacin Global

En el SRS se presenta la documentacin de los requerimientos funcionales que
describen el comportamiento esperado de la aplicacin WorDomination, y la
correcta certificacin de calidad de estos, mediante el uso de las listas de
chequeo de Construx. [27]
Por lo tanto, este SRS debera usarse para un correcto desarrollo, pruebas,
aseguramiento de la calidad, gestin de proyecto y funcionalidades del proyecto
en general. [14]
Para finalizar, es importante mencionar que el SRS incluye tambin los
requerimientos no funcionales que ayudan a la obtencin de objetivos del
proyecto y descripciones de atributos de calidad del producto desarrollado a
partir del mismo, los cuales amplan la descripcin de atributos de calidad
caractersticas que debe manejar (usabilidad, portabilidad, integridad, eficiencia
y robustez), proporcionando funcionalidades importantes para el cliente o los
desarrolladores; a su vez otros requerimientos no funcionales describen
interfaces externas entre el sistema y el mundo externo, al igual que el diseo e
implementacin de restricciones. [14]
Con la finalidad de lograr satisfactoriamente lo propuesto, en general S.G.P.M
busca la correcta ingeniera de requerimientos, o ciencia encargada de
encontrar, establecer y documentar los requerimientos de software, a travs de
un proceso de 4 fases (Recoleccin, Anlisis y Negociaciones, Documentacin
y Validacin) el cual se puede observar en el proceso de Ingeniera de
Requerimientos (ver Seccin 2.4) y su correcta especificacin mediante las
caractersticas que debera 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 travs de
las listas de chequeo ya descritas [14], [20], [27].
Para observar las descripciones detalladas de requerimientos del sistema, se
puede observar la seccin 3 Requerimientos Especficos.
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 ms importantes del SRS: el Proceso
de Requerimientos, que involucra el entendimiento de necesidades y
expectativas del cliente (identificacin y obtencin de requerimientos ver
Seccin 2.4.1), anlisis y especificacin de requerimientos (ver Seccin 2.4.2),
priorizacin y ubicacin (ver seccin 2.4.3), trazabilidad y verificacin y
validacin 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 Identificacin de Stakeholders

Para identificar satisfactoriamente a los stakeholders del proyecto, hay que
tener en cuenta que son todas aquellas personas que tienen algn inters 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. Segn SGPM los stakeholders seran:
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 implementacin.
Equipo de Desarrollo (SGPM): Grupo encargado de definir como se
realizar el ciclo de vida de requerimientos mediante un Proceso de
Requerimientos para la obtencin de un producto de calidad.
Usuario Final: Es el actor que interacta con el sistema y puede pertenecer
a dos categoras: 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 aplicacin debe manejar una arquitectura cliente servidor.
2) La aplicacin debe tener uso de persistencia.
3) La aplicacin debe utilizar interfaz grfica de usuario.
4) La aplicacin debe correr en las mquinas del Departamento de Ineniera
de Sistemas de la Pontificia Universidad Javeriana.
2.3 Participacin por roles

Con el fin de generar una mayor eficiencia en el trabajo del grupo con
respecto a la elaboracin 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 continuacin:
SEOA staenscarad rerarresGaspFao camoj anergrdsaz o b d(Al ee dl ame aisenctui sg traua ilridz uoa nrcidbo eun e dn e
SEWA(Gstaenieraldsrereorarenns teaspPH ecaioyred nargzsal g ob, l eh ap co er r e lcu m p l i r l o s cri t e ri o s d e ca l i d a d e n
pvC eroo rsin cefi ogsonu eraes nce i onl an d eosl acuyb mod raoe cuncitoom ns e dny etarel cd qio ucune ri)m m e ine ton to s
dre(D(A erqDqisariure eirroctotctorie mctol r roi eC)dn aetol ildso asyd re)d oq cuu e mri me ni eton toS Rs S e n g e n e ra l .
P ro g ra m a ci o n )
2.4 Proceso de requerimientos
Teniendo en cuenta el concepto bsico de requerimiento definido como una
caracterstica necesaria que debe poseer el sistema que se desea crear,
S.G.P.M utilizara un proceso de requerimientos planteado por Karl E. Wiegers
[NReferencia], con el fin de tener un debido manejo y administracin de cada
uno de los requerimientos que surjan alrededor del proyecto
[NReferencia] Wiegers, Karl E. More About Software Requirements. Microsoft.
2006
2.4.1 Identificacin de Requerimientos
La identificacin 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 Seccin 10 SPMP) y los casos de uso propuestos (Ver Documento Casos
de Uso), como apoyo para la estructuracin y elaboracin de los requerimientos
del proyecto. La identificacin de requerimientos tambin estar marcada por la
divisin en categoras de cada uno de los requerimientos(Ver ilustracin
Categoria de Requerimientos), el cual se podr identificar de acuerdo a los dos
ltimos nmeros que tenga el Id de cada requerimiento como se observa en la
siguiente tabla.
Identificacin
R##01
R##02
R##03
R##04
Especificacin
Negocio
Usuario
Sistema
No funcionales
No
f u n c io
n a lR##0
4
S is t e
m aR##0
3
U su a ri
oR##0
2
Req ue
r im ie n
to s
N egoc
io R##0
1
Requerimientos de negocio: Representan a gran nivel los objetivos de la

organizacin y/o las solicitudes del cliente con respecto al sistema o producto
[http://sophia.javeriana.edu.co/~metorres/, Presentacin Requerimientos]
Requerimientos de Usuario: Describen las tareas de los usuarios que deben

poder ser realizadas con el producto [http://sophia.javeriana.edu.co/~metorres/,
Presentacin 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/, Presentacin Requerimientos]
Requerimientos no Funcionales: Definen los atributos que le indican al
sistema como realizar su trabajo (eficiencia, hardware, software, interfaces,
usabilidad,
etc.).
Es
el
cmo,
cuando
y
cuanto
del
que.
[http://sophia.javeriana.edu.co/~metorres/, Presentacin Requerimientos]
[Ian Sommerville 2000, Software Engineering, 6th Edition. Chapter 5]
Requerimientos del Producto: Este tipo de requerimientos especifican

el comportamiento del producto; como los requerimientos de desempeo
en la rapidez de ejecucin del sistema y cunta 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 polticas y procedimientos existentes en la organizacin
del cliente y en la del desarrollador: estndares en los procesos que
deben utilizarse; requerimientos de implementacin como los lenguajes
de programacin o el mtodo de diseo a utilizar, y los requerimientos de
entrega que especifican cundo se entregar el producto y su
documentacin.
[Tomado
de
:
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 interacta con los otros sistemas de la organizacin; 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
pblico
en
general.
[Tomado
de
:
2.4.2 Especificacin de Requerimientos
Con base en tcnicas de especificacin [55] buscaremos la mejor clasificacin,

bsqueda y un anlisis completo de los requerimientos, teniendo como base
sus diferentes etapas de ejecucin, la trazabilidad y riesgos de estos con base
en este documento. En el grafico se mostrara las etapas y su posible
funcionalidad.
IOM n pfoioccid r imoo naJ duecies g nJJ ouu Cee lgige oon t e s
N o Fu n ci o n a l e s
2.4.3 Priorizacin de Requerimientos
Se baso en el uso de tcnicas cognitivas planteadas por Nadina Martnez en su

escrito Gestin de Preferencias de Requerimientos que nos permite tener un
enfoque y dar la debida clasificacin, prioridad a cada funcionalidad a nuestro
sistema para un mejor desarrollo
In d e n t ifi c a c io n d e R e q u e r im ie n t o s y S u n iv e l N iv e l d e P r io r id a d P r io r id a d
d e V a lo r iz a c i n g e n e r a l
s e g u n E l r o l F in a l
A) Identificacin de Requerimientos y Su nivel de Valorizacin general

Identificacin General: Los requerimientos identificados anteriormente
debern ser vueltos a contemplar para poder valorar que tan importante
ser para su implementacin y que aspecto general influir en el
proceso. [53]
Valorizacin General: Con base en lo anterior despus de una breve
revisin 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 segn el Rol

Visin por cada rol: Aqu usaremos el inciso A para que cada miembro
del grupo SGPM pueda valorar los requerimientos ya establecidos y su
prioridad, pero dando una valoracin individual para contrarrestar y
clasificar con la ya dada generalmente, teniendo como fundamento dos
puntos de valoracin y as priorizar tanto

individualmente como
generalizado, lo cual nos brindara un mejor visin.
C) Prioridad Final
Para esta relacin usaremos las variables anteriores para poder
implementar la valorizacin ms acertada para cada requerimiento,
siendo estos:
Valorizacin General.
Valorizacin Rol.
Prioridad final.
Valorizacin General.
Valorizacin Rol.
Se tendr en cuenta la
discusin de cada requerimiento
de un modo neutral.[53]
Punto de vista de cada persona
como si fuera cliente. [53]
Discusin con el grupo de los
requerimientos ms
importantes. [53]
Tendremos un valor para cada
miembro segn el requerimiento
con una valoracin de -5 a 5.
[53]
Cada miembro dar un valor
clasificatorio. [53]
Prioridad final.
En esta clasificacin se dar la

priorizacin final de los
requerimientos y har una
matriz de conflicto asiendo las
debidas comparaciones. [53]
Los resultados sern dados por
Valorizacin General y final,
debido a que es de global a
especifico.[53]
La priorizacin de requerimientos se dar de una clasificacin de 1 a 10 siendo

el
mayor
ms
importante.
La
formula
seria:
V
R
o
n
o
l o r i z a c i n
l ( C
l a s i fi c a
N
e g a t i v a
s i t i v a )
i
o
P r i o
r i d a
d
F i n a
l
Gestin de Preferencias de Requerimientos basada en

Tcnicas Cognitivas
Nadina
Martnez
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]
2.4.4 Trazabilidad
La trazabilidad es un factor clave para la gestin 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 ms procesos de software [17]. Esta trazabilidad se puede realizar de dos
formas:
Hacia adelante
Hacia atrs
M
o
n
ito
re
od
elaim
p
le
n
ta
cio
n
d
e
lre
q
u
e
rim
e
in
to
Figura trazabilidad hacia adelante
O
rig
e
n
d
e
lo
sre
q
u
e
rim
e
n
to
s
Figura trazabilidad hacia atrs
Para poder realizar este seguimiento S.G.P.M se ayudara de herramientas

como son los casos de uso (ver documento Casos de uso), el modelo de
dominio (ver seccion3.5), el SPMP (ver documento SPMP), y los requerimientos
asociados que tenga cada uno.
As mismo S.G.P.M decidi enfocarse a un estilo de trazabilidad vertical que se
garantiza que todos los requerimientos que van a ser diseados 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
verificacin y validacin (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 Validacin y verificacin.

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 caractersticas.
Trazabilidad (ver seccin 2.4.4).
Plantilla modificada Volere, para la documentacin de los requerimientos.
2.5 Administracin 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) remtase al
punto 3 (ver Secciones 3.1 a 3.5).
3 Descripcin 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 aplicacin completamente nueva, por lo
cual no reemplazara a otro sistema, as mismo no se crearan interfaces para
nuevos componentes.
3.1.2 Interfaces con el usuario
En la siguiente tabla se especifican las diferentes interfaces con el usuario.
INTERFACES
TECLADO
RATON
MONITOR
INTERFAZ GUI
TARJETA GRAFICA
TARJETA DE RED
Dispositivo utilizado para el ingreso de

caracteres por parte del usuario, para
la formacin de palabras en el juego
Dispositivo
utilizado
para
la
interaccin de las diferentes interfaces
y captura de datos en el juego
Dispositivo
utilizado
para
la
visualizacin de la interfaz por parte
del usuario. Resolucin mnima 800x
600 pixeles
Se utilizaran los APIS de las
bibliotecas graficas SWING, AWT
Dispositivo utilizado para la trasmisin
de informacin grafica al monitor.
Resolucin mnima de 800 x 600
pixeles
Dispositivo utilizado para la conexin
entre maquinas(Redes de rea local).
Velocidad requerida 2 Mbps
3.1.3 Interfaces con el Hardware
Como se haba especificado ya por el cliente, los productos de SGPM buscaran

la satisfaccin 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 aplicacin ser de una arquitectura
Cliente/Servidor por tal motivo para una mejor interaccin y cumplimiento, se
deber usar protocolos de comunicacin como los aqu nombrados y escogidos:
LW a o er dl ocm io na tdioe n tsecno dg ea r le s teim p rloi t dcao ld e fuc eo npeoxri lan eb u sloq cuaeld sa pd ae r la csuima tpr olicC do am p , ftua nd c iroensa elind au n ay ceosntea xn ido an r ilzo a c ilo(Hn oqsut e) .[s1e] m a n e ja r , a lg u n a s c a u s a d e n u e s tr a d e c is o n
PLD ara orc to nlace ox lipo cn8iofi0ns8idc0ea Htdrtea lsp sm i isteomn ad se e d da ator s gc or an c liaa sw ae bl , sC iahb alec ai sd eo p UidT eP i(m p le m e n t a r e n v e r s io n e s m a s c o m p le t a s .[1 ]
WL oa rAd oqmu in ea ct iou nr a t e nx digr a l e s imc p elinc tde a-s d rev cido nre, x io nle sc ulo c a le st ip ao r d ec up a t r o cC olm hp u ct ae d om r ea s e inm up nlea scuo nm e ax ioenj l.o[c1 a] l(H o s t ) .[ 1 ]
L a eAlr qc u ioten c dt ue r a secxoig edra e s te c plier on t e c-os el r vfiudeo rp,oern la ob cu s aq lu e sd at ipd oe dlae spimro pt lic o dl a h a, cfue n cm ioa ns limd ap ley s ue mta n deajor i.z[a1 c] io n q u e s e m a n e ja r , a lg u n a s c a u s a d e n u e s tr a d e c is o n
B r in d a r p a r la im p le m e n t a c io n s e g u r id a d e n la e n t r a d a y s a lid a d e in f o r m a c io n .[ 1 ]
S u e s t a n d a r iz a c io n p e r m it a r im p le m e n t a c io n e n d if e r n t e s L a p t o p o P C , p a r la s c o n e x io n e s e x ig d a s .[ 1 ]
Protocolo de
Comunicacin
TCP/IP
Puerto TCP
Partes Fsicas
(Cables
y
Conexiones)
3.1.4 Interfaces con el Software

La aplicacin WordDomination ser implementada en java, utilizando diferentes
APIS 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 debera 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 versin mayor a la JDK 1.5
preferiblemente. Para ver en ms detalle cada uno de estos componentes se
adjunta la siguiente tabla:
Product
o de
Software
Windows
JDK
JavaFx
JMF
Propsito de Uso
Versin
Windows es el sistema operativo ms

usado del mundo, basado y orientado
a la interfaz grafica lo cual permitir
una interaccin amigable con el
usuario
Permitir la creacin , desarrollo y
ejecucin del la aplicacin
WordDominatio
Permitir creacin de una Interfaz con
una calidad grafica dinmica 2D o 3D
Permitir la adaptacin de tecnologas
de audio y video , para la aplicacin
Fuente
Windows XP
Windows Vista
Windows NT
MicroSoft Windows
www.microsoft.com/spain/windows/
A partir de la versin 5.0
Sun MicroSystem
http://java.sun.com/javase
Versin 1.2
SunMicroSystem
http://java.sun.com/javafx/
SunMicroSystem
http://java.sun.com/javase/technologies/d
esktop/media/jmf/
Versin 2.1.1e
Tabla 3: Interfaces con el Software
3.1.5 Interfaces de Comunicacin

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
estndar conexiones LAN, para que se la interaccin especificada, una
restriccin para la conexin es que esta debe estar libre de cualquier corta
fuegos para as pueda ocurrir la trasferencia de datos y operaciones (ver ms.
2.1.3 Interfaces de Hardware).
3.1.6 Restricciones de Memoria

Para la perfecta ejecucin de WorDomination, se considero la total necesidad
de consumo de memoria por parte del modulo para la implementacin del
diccionario en espaol, puesto que para ofrecer un excelente rendimiento por
parte de la aplicacin 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,
tambin ser necesario que los equipos cumplan los siguientes requisitos, para
poder correr todos los programas sobre los que WorDomination se aplicara:
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 mostrarn las acciones que podran realizar cada
uno de estos:
Wordomination no tendra ningun momento de inactividad en el momento de

juego, ya que el juego sera ejecutado por los jugadores para iniciar una partida
o las demas opciones. S.G.P.M no ofrecera procesos de recuperacion, en caso
de que se produzca algun problema en medio de la ejecucion, como la caida del
sistema en la que normalmente no se puede recueperar ningun dato que se
haya ingresado con anticipacion.
3.1.8 Requerimientos de Adaptacin 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
ingeniera, en especial la Sala de Bases de Datos [NREFERENCIA], el cual es
el lugar el lugar ms idneo para realizar la presentacin final. El lugar debe
contar con los componentes estipulados en las interfaces de Software (Ver
seccin 2.1.4 Interfaces de Software) de este documento, las cuales estarn
incluidos dentro de un paquete con su respectivo manual, listo para utilizarse en
el momento de la ejecucin de Wordomination.
[NREFERENCIA]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 seccin hace referencia a las mltiples funcionalidades que contendr el
producto final del juego WorDomination, para una mejor comprensin 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 informacin acerca de las Funciones Del
Producto, remtase al Documento de Casos de Uso.
3.3 Caractersticas del Usuario

Los Usuarios de la aplicacin podr ser cualquier persona que tenga un pleno
inters en el mundo de WorlDomination, y que adems desee una aplicacin en
la cual pueda jugar diferentes partidas con una variedad de usuarios, ya sea
contra la maquina misma (el computador) o en solitario si as el lo desea.
El sistema deber ser muy intuitivo, de tal forma que permita su uso por
cualquier tipo de usuario, es decir, que no solo estar dirigido para personas
expertas en el manejo de la computacin sino tambin para aquellos que aun
son inexpertos. Para poder lograr esto los desarrolladores de S.G.P.M harn lo
posible por disear pantallas que permitan el fcil manejo de la intuicin del
usuario, y evitara un gran nmero de opciones sobre las ventanas con el fin de
hacer difcil su uso.
Por otro lado, no ser necesario que el usuario domine 100% el juego de
WorDomination, pues contara con las herramientas bsicas para su buen uso y
fcil manejo como lo son el uso de manuales y reglas de juego que estarn a su
alcance en todo momento.
A continuacin se ha definido una estructura que contendr las
caractersticas bsicas que debe poseer el jugador, para hacer ms viable y
satisfactorio el uso del juego: [Fowler, M.: UML Destilled, segunda edicin,
Addison Wesley Longman Inc, 2000.]
Actor
Descripcin
Comentarios
Nombre del Actor

Descripcin corta de la caracterstica,
responsabilidad o rol que tendr el
actor
Informacin relevante que se deba
mencionar
Teniendo en cuenta el cuadro anterior, presentaremos las caractersticas del

usuario para WorDomination.
Actor
Descripcin
Comentarios
Actor
Descripcin
Jugador
El usuario debe Saber leer y escribir,
tener un vocabulario, entendimiento
aceptable, con el fin de poder crear o
poner palabras reales en el momento
que tenga el turno dentro del juego.
El usuario debe tener un nivel de
intelecto y entendimiento aceptable,
para vencer y no dejarse ganar.
Jugador
El usuario debe tener conocimientos
bsicos de computacin (Manejo de
Sistema operativo Windows XP) y de
los accesorios bsicos como teclado y
Comentarios
Actor
Descripcin
Comentarios
Actor
Descripcin
Comentarios
mouse.
El producto no brinda ayuda en el
manejo del Sistema Operativo.
Jugador
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 algn buscador.
Ninguno
Jugador
No es de total relevancia, pero sera
de gran ayuda tener cierta experiencia
o conocimiento en juegos de mesa.
Ninguno
3.4 Restricciones
Es importante que el usuario tenga en cuenta las restricciones con las que el
WorDomination ser creado, con la finalidad de un perfecto funcionamiento
dentro de los requisitos exigidos por el cliente, para ello S.G.P.M ha realizado
una lista con las siguientes restricciones:
WorDomination estar regido 100% por las reglas del juego de mesa
Scrabble, al cual no se le ha hecho ningn tipo de modificacin para
mantener su esencia natural ante el usuario.
El juego manejara nicamente el idioma espaol para su ejecucin y

desarrollo, manuales y dems documentos.
WorDomination no contara con la caracterstica de ser tolerante a fallos,

es decir, que si se llega a presentar una situacin en la que el juego se
vea afectado de forma total, este no podr recuperar ningn 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 mnimas de hardware se podrn ver en la seccin

2.1.6 Restricciones de memoria y en la seccin 3.1.2 Interfaces con el
Hardware.
De igual forma se podrn encontrar las especificaciones mnimas de

Software en la seccin 2.1.6 Restricciones de memoria y en la seccin
3.1.3 Interfaces con el Software, en donde encontraremos los IDEs y los
APIs 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.
[NREFERENCIA]Requisitos del Sistema, Consultado: 05 de Septiembre

de
2009,
Disponible
en:
http://www.navegapolis.net/files/blog/formato_ieee1362.doc
3.5 Modelo del Dominio

Esta seccin del documento debe reflejar el anlisis inicial realizado al
sistema a desarrollar, mediante la presentacin del Diagrama del
Modelo del Dominio y la documentacin asociada.
Antes de especificar como documentar un diagrama del modelo del
domino es importante dar las definiciones otorgadas por las
organizaciones ms importantes para la ingeniera de software, la
siguiente tabla muestra dichas definiciones:
Organizacin / Autor
Definicin
Construx
Flower 96
El modelo del dominio define un

grupo de informacin que debe
ser almacenado en el sistema, y
las relaciones entre estos grupos
de informacin. 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 tambin atributos
para cada entidad del modelo
sea una clase, una entidad de
datos o un objeto del negocio.
Es una representacin visual de
las clases conceptuales u
objetos del mundo real en un
dominio de inters [10]. Tambin
se les denomina modelos
conceptuales.
Larman
El modelo del domino podra

considerarse como un
diccionario visual de las
abstracciones relevantes,
vocabulario del dominio e
informacin del dominio.
Tabla 4: Definiciones del Modelo de Dominio
Finalmente Larman termina con una conclusin 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 representacin de las cosas reales del mundo del
dominio de inters [11].
A continuacin se presenta una forma para documentar los elementos
en el diagrama del modelo del dominio.
ID
Elemento
Dominio
del
Descripci
n
Nombre
Atributos
Descripcin
Tipo de Dato
Objetivo
Tabla 5: Formato de documentacin del Modelo del Dominio
IDE l e m e n t o d e l D o m i n i o
DAN toe r msi b c bur irt p eo c s i n
DOT i ebp sjo e c tdr i i vep o c D i a n t o
Ilustracin 1: Descripcin documentacin 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 seccin 3. Estos pueden
incluir componentes comerciales o de terceras personas que usted
planea utilizar. Tenga en cuenta que el proyecto podra afectarse si
estas suposiciones son incorrectas, no se comparten, o se cambian

[1].
a
n
T
u
rtld
e
s
qU
m
iv
a
n
d
to
n
e
lim
p
uR
C
nQ
o
tric
s
e
in
lc
e
u
se
b
m
g
a
h
to
iP
v
r
a
Ilustracin 2: Suposiciones
Dependencias:
Ilustracin 3: Dependencias [1]
4 Requerimientos Especficos
No.
Requerimi
ento
Versin
Tipo
Nmero de Identificacin de requerimiento. Ver Error:

Reference source not found
1.0 Primera Versin del Requerimiento

Error: Reference source not found Error: Reference
source not found, Error: Reference source not found
Nombre
Nombre nico del requerimiento. Visualizacin global
del requerimiento.
Encargado Miembro de S.G.P.M que se encargar de implementar
el requerimiento.
Descripci Especificacin
detallada
de
la
funcin
del
n
requerimiento dentro del sistema
Objetivo
Criterio
Es un criterio de aceptacin o un caso de prueba.
de
Medicin
Excepcion Condiciones imprevisibles o cuando surgen situaciones
es
en la que debe responder rpidamente. Evento no
deseado que coloca al sistema fuera de su flujo normal
puede ser causado por factores internos o externos
Observaci Razn de ser del requerimiento, utilidad para el
ones/
sistema o aclaraciones acerca de su funcionamiento
Justificaci
n
Caso(s)
Casos
de Requerimie Segn el grafo
Uso
uso que se nto(s)
(ver
Error:
Relacion relacionan
Asociado(s) Reference
ado
con
el
source
not
requerimie
found
Error:
nto.
Reference
source
not
found) son los
requerimientos
antecesores y
predecesores.
Trazabilid
ad
Riesgo
Costo
Estado
Esfuerzo
Capa
Se mide segn Prioridad

Medida
dada
el nmero de
segn
las
requerimientos,
especificaciones
que segn el
expuestas en la
grafo
de
Seccin
Error:
requerimientos
Reference source
(Error:
not found Error:
Reference
Reference source
source
not
not found.
found
Error:
Reference
source
not
found),
dependen de la
implementacin
de este, es decir
los
requerimientos
predecesores.
Se mide en trminos de personal y conocimiento
necesarios para su implementacin. Los rangos que se
manejan son los siguientes:
Bajo
Medio
Alto
Tiempo requerido para implementar el requerimiento.
Se medir en (das, meses, aos)
Capa de la arquitectura del sistema en la que se puede
encontrar el requerimiento
TOKA referenciar
4.1 Requerimientos de Interfaces Externas

Las siguientes secciones se encuentran estrechamente relacionadas
con la seccin 2.1, la explicacin de estas, busca simplemente
profundizar un poco ms 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 seccin se debe explicar la forma en que el sistema o que la
aplicacin permitir la comunicacin con el usuario o el cliente final.
Esta comunicacin incluye el ingreso de datos al sistema, la
navegacin 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 construccin.
Las interfaces deben contener la informacin lgica, por ejemplo
formatos de pantalla requeridos (1024*768, 800*600,600*400),
distribucin de elementos en la pantalla o si tiene accesos rpidos con
el teclado, por dar algunos ejemplos [12].
P
T
N
A
LE
L
C
T
OM
D
A
O
E
SIN
U
Z
A
F
R
E
T
UT
G
A
JE
R
IC A
F
G
T
R
E
JD
Algunas interfaces que se deben tener en cuenta son:
Ilustracin 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 informacin con otros
computadores y
dispositivos (ejemplo dispositivos mviles), es
necesario tener en cuenta la forma en que los componentes de
software (aplicacin o sistema) se comunicaran con los componentes
de hardware de los otros dispositivos.
Las caractersticas del sistema a nivel de hardware que se deben

tener en cuenta para el desarrollo, se enfocan en cmo se va a llevar
a cabo la comunicacin entre las mquinas de los usuarios
participantes, algunas de estas interfaces son:
R
Ue
T d
P H
U
B
S
W
I
C
H
I
n
Pt
ue
er
rc
to
on
se
x
T
C
P
U
D
P
P
ra
o
trlo
c
o
lu
o
s
u
e
s
a
d
o
s
p
a
r
a
l
a
P
r
o
t
o
c
o
l
o
s
d
e
c
o
m
u
n
i
c
a
c
i
n
(
T
C
P
,
U
D
P
)
P
u
e
r
t
o
s
u
s
a
d
o
s
p
a
r
a
l
a
c
o
m
u
n
i
c
a
c
i
n
(
s
i
l
a
a
p
l
i
c
a
c
i
n
e
s
d
i
s
t
r
i
b
u
i
d
a
)
C
b
e
s
D
is
p
o
itv
o
s C
a
b
le
sd
e
c
o
n
e
x
i
n
(U
T
P
)D
i
s
p
o
s
i
t
v
o
s
d
e
r
e
d
(
R
o
u
t
e
r
s
,
H
u
b
s
,
S
w
i
t
c
h
e
s
d
e
c
o
m
u
n
ic
a
c
i
n
(s
ila
d
e
re
d
c
a
o
p
m
lic
u
a
n
c
i
c
a
n
c
e
i
sd
is
trib
u
id
a
)
c
o
n
e
x
i
(n
R
u
t
e
r
s
,
(T
C
P
,U
D
P
)
n
(U
T
)
H
u
b
s
,P
S
w
itc
h
e
s
Ilustracin 5: Interfaces de Hardware
4.1.3 Interfaces con el Software

Para la ejecucin del sistema apropiadamente es necesario tener
algunos requerimientos mnimos de Software, esto es versin del
sistema operativo, servidores de bases de datos y en general todos
los productos de software que permitan la correcta utilizacin del
sistema desarrollado. La Error: Reference source not found muestra
un formato que puede usarse para explicar estas interfaces.
Ilustracin 6: Interfaces con el Software

4.1.4 Interfaces de Comunicaciones
Las interfaces de comunicacin son bsicamente los mtodos como
se interconectan las diferentes aplicaciones en las mquinas en donde
se ejecutan (nuevamente si la aplicacin es distribuida), estas
interfaces incluyen el tipo de red que se debe montar para la
conexin de computadores (LAN, WAN) y los protocolos de
comunicacin usados (TCP). Para apoyar la informacin escrita en
esta seccin, se aconseja explicar cierta parte en la seccin 3.1.2
4.2 Caractersticas del Producto de Software

Para lograr un mayor entendimiento en la especificacin de los requerimientos
por parte del cliente, S.G.P.M ha distribuido los requerimientos en las siguientes
categoras, con el fin de establecer una mejor organizacin y gestin de estos:
R e q u e r im ie n t o s
2.2.1 Funcionalidad 1: Jugar

No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
R010303
1.0
Funcionales-Modo de juego
Cantidad de fichas
Wilson Perez
El sistema tiene que permitir a los jugadores tener la
misma
cantidad
de
fichas,(Ver
reglas
de
WorDomination)
Objetivo
Cada jugador pueda iniciar el juego igualitariamente
Criterio de Al iniciar el juego, el jugador debe poder armar
Medicin
palabras con el nmero de fichas entregadas.
Excepcion
es
Observacio Ninguna
nes/
Justificaci
n
Caso(s)
CU02,
Requerimie R020303
Uso
CU07
nto(s)
R0703
Relacionad
CU12
Asociado(s)
o
Trazabilida Modelo de
d
dominio
Documento
Casos de
uso: CU02
CU07
CU12
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
Estado
Esfuerzo
Capa
2
Medio
Aprobado
2 das
Servidor
Prioridad
12
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
R020303
1.0
Arrastre de fichas
Wilson Perez
El sistema tiene que verificar y mostrar las fichas
(letras) que el jugador actual est arrastrando para
formar su palabra a todos los dems jugadores.
Objetivo
Para que cada jugador se pueda dar cuenta los
movimientos de su rival, y los puntajes coincidan con
las palabras armadas
Criterio de Todos los jugadores en su interfaz pueden ver los
Medicin
movimientos(arrastre de fichas) de sus rivales,
puntajes se deben modificar.
Excepcion
es
Observacio Ninguna
nes/
Justificaci
n
Caso(s)
CU15,
Requerimie R080303,
Trazabilida
d
Uso
Relacionad
o
Modelo de
dominio
Documento
Casos de
uso: CU15
CU16
CU18
CU16
CU18
nto(s)
Asociado(s)
R090303,
R010303
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
Estado
Esfuerzo
Capa
4
Alto
Aprobado
20 das
Servidor
Prioridad
14
4
5
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
R030303
1.0
Mostrar tiempo
Wilson Perez
El sistema mostrara a cada jugador el tiempo mximo
que tiene para ingresar la palabra al tablero.(2
minutos, Ver reglas de WorDomination)

Objetivo
Para que cada jugador tenga un tiempo establecido, y
los rivales no se queden esperando un tiempo
indefinido
Criterio de Despus de los 2 minutos, se debe ceder al turno al
Medicin
jugador correspondiente
Excepcion
es
Observacio Ninguna
nes/
Justificaci
n
Caso(s)
CU14
Requerimie R0103703
Uso
CU19
nto(s)
R0103403
Relaciona
Asociado(s)
do
d
dominio
Documento
Casos de
uso:
CU14
CU19
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
Estado
3
MEDIO
Aprobado
Prioridad
10
Esfuerzo
Capa
3 das
Servidor
6
7
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
R0403
1.0
Aadir Palabra
Wilson Perez
El sistema deber permitir al jugador aadir una
palabra si la tiene lista antes de que se cumpla el
lmite de tiempo (2 minutos), esto se har mediante
un botn en la pantalla del jugador.
Objetivo
Para que cada jugador tenga la posibilidad realizar su
jugada en el tablero
Criterio de En el tablero el jugador podr formar sus palabras
Medicin
durante dos minutos, contabilizndole su puntaje
Excepcion
es
Observacio Si no se realiza la jugada, pierde turno
nes/
Justificaci
n
Caso(s)
CU15
Requerimie R0203,
Uso
CU16
nto(s)
R0803,
Relacionad
CU18
Asociado(s) R0903,
o
R1703
d
dominio
Documento
Casos de
uso:
CU15
CU16
CU18
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
4
ALTO
Estado
Esfuerzo
Capa
Aprobado
12 das
Servidor
Prioridad
15
8
9
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
R0503
1.0
Eliminar Palabra
Wilson Perez
El sistema debe permitir eliminar la ltima palabra
creada por el jugador
Para que cada jugador tenga la posibilidad de reversar
una mala jugada realizada durante la partida
Criterio de El sistema debe quitar del tablero la ltima palabra
Medicin
ingresada si el jugador as lo desea
Excepcion
es
Observacio
nes/
Justificaci
n
Trazabilida
d
Caso(s)
Uso
Relacionad
o
Modelo de
dominio
CU13
CU16
Requerimie
nto(s)
Asociado(s)
Documento
Casos de
uso: CU13
CU16
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
4
ALTO
Estado
Esfuerzo
Capa
Aprobado
12 das
Servidor
10
11
12
13
14
No.
R0603
Prioridad
12
R1403
R0203
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
1.0
Utilizar comodin
Wilson Perez
El sistema debe permitir usar correctamente el
comodn o fichas en blanco, las cuales se pueden
utilizar en sustitucin de cualquier letra.
Objetivo
Para que cada jugador tenga la posibilidad de formar
sus palabras con diferentes opciones
Criterio de El sistema debe validar la palabra incluidos los
Medicin
comodines y fichas en blanco y sumarlo al puntaje
Excepcion
es
Observacio Los comodines son de un nmero limitado (ver reglas
nes/
WorDomination)
Justificaci
n
Caso(s)
CU18
Requerimie R0203
Uso
CU16
nto(s)
Relacionad
Asociado(s)
o
d
dominio
Documento
Casos de
uso: CU18
CU16
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
3
BAJO
Estado
Esfuerzo
Capa
Aprobado
2 das
Servidor
Prioridad
15
16
17
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
R0703
1.0
Utilizar comodn
Wilson Prez
El sistema debe darle 7 fichas (letras) de forma aleatoria a cada jugador al
iniciar la partida.
Para que cada jugador pueda iniciar el juego, con

igualdad de condiciones
Criterio de A iniciar el juego cada jugador debe tener 7 fichas
Medicin
Excepcion
es
Observacio Puede que ha determinado jugador al inicio con sus
nes/
fichas pueda armar ms fcil una palabra.
Justificaci
n
Caso(s)
CU02
Requerimie R0103
Uso
nto(s)
R1303
Relacionad
Asociado(s)
o
d
dominio
Documento
Casos de
uso: CU02
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
2
BAJO
Estado
Esfuerzo
Capa
Aprobado
2 das
Servidor
Prioridad
18
19
20
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
R0803
Objetivo
Para que cada jugador pueda armar sus respectivas
1.0
Acomodar Fichas
Wilson Perez
El sistema debe permitir acomodar las fichas de forma vertical u
horizontal para formar las palabras segn le convenga al jugador, (Ver
reglas de WorDomination).
palabras en el tablero
Criterio de El jugador debe poder formar sus palabras en el
Medicin
tablero, tanto en sentido vertical como horizontal
Excepcion
es
Observacio Las casillas donde se ponen las fichas deben ser
nes/
validas(estar desocupadas)
Justificaci
n
Caso(s)
CU16
Requerimie R0203
Uso
CU18
nto(s)
R0903
Relacionad
CU15
Asociado(s) R0403
o
R1903
d
dominio
Documento
Casos de
uso:
CU16
CU18
CU15
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
3
MEDIO
Estado
Aprobado
Prioridad
11
Esfuerzo
Capa
4 das
Servidor
21
22
23
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
R0903
1.0
Formar palabras Contiguas
Wilson Perez
El sistema debe permitir formar palabras completas si las fichas puestas de
forma horizontal o vertical quedan en contacto con filas o columnas
contiguas.
Objetivo
Para que cada jugador pueda formar sus palabras

completas y validar su jugada
Criterio de El sistema validara las palabras completas ingresadas
Medicin
por el usuario
Excepcion
es
Observacio Las casillas donde se ponen las fichas deben ser
nes/
validas(estar desocupadas)
Justificaci
n
Caso(s)
CU16
Requerimie R0203
Uso
CU18
nto(s)
R0803
Relacionad
CU15
Asociado(s) R0403
o
R1903
d
dominio
Documento
Casos de
uso:
CU16
CU18
CU15
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
3
ALTO
Estado
Esfuerzo
Capa
Aprobado
10 das
Servidor
Prioridad
11
24
25
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
R1003
1.0
Color casillas
Wilson Perez
El sistema debe tener en cuenta el color de cada casilla del tablero al
momento de asignar la puntuacin a un jugador, pues de acuerdo al color
se puede dar un premio por letra o por palabra (Ver reglas de
WorDomination)
Para que cada jugador tenga la posibilidad de

aumentar su puntaje dependiendo del color en el que
forme sus palabras
Criterio de El puntaje de cada jugador se modificara dependiendo
Medicin
del color donde forme la palabras
Excepcion
es
Observacio
nes/
Justificaci
n
Caso(s)
Uso
Relacionad
o
Trazabilida
d
CU16
CU18
CU15
CU06
Requerimie
nto(s)
Asociado(s)
Modelo de
dominio
Documento
Casos de
uso:
CU16
CU18
CU15
CU06
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
4
ALTO
Estado
Esfuerzo
Capa
Aprobado
10 das
Servidor
26
Prioridad
12
R0803
R0903
R1103
27
28
29
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
R1103
1.0
Calcular puntaje
Wilson Perez
El sistema tiene que calcular el puntaje sumando el valor de las fichas
utilizadas en las palabras que se hayan formado en ese turno, ms los
puntos obtenidos por haber puesto una o ms fichas en casillas con
premio.
Objetivo
Para que el puntaje de cada jugador se vaya

modificando dependiendo de las jugadas realizadas
Criterio de El sistema debe actualizar y mostrar el puntaje de
Medicin
cada jugador dependiendo de las palabras formadas
en cada turno
Excepcion
es
Observacio
nes/
Justificaci
n
Caso(s)
CU15
Requerimie R1003
Uso
CU06
nto(s)
R1203
Relacionad
Asociado(s) R1303
o
d
dominio
Documento
Casos de
uso:
CU15
CU06
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
4
ALTO
Estado
Esfuerzo
Capa
Aprobado
10 das
Servidor
Prioridad
12
30
31
32
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
R1203
1.0
Ver Puntaje
Wilson Perez
El sistema debe permitir al jugador ver su puntaje durante la ejecucin de
cada partida
Para que jugador tenga informacin de su puntaje

durante el desarrollo de la partida
Criterio de El sistema debe actualizar y mostrar el puntaje en la
Medicin
pantalla de cada jugador, cada vez que se realice una
jugada
Excepcion
es
Observacio
nes/
Justificaci
n
Trazabilida
d
Caso(s)
Uso
Relacionad
o
Requerimie
ntos
CU06
CU03
Requerimie
nto(s)
Asociado(s)
R1303
R1103
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
3
MEDIO
Estado
Esfuerzo
Capa
Aprobado
4 das
Servidor
Prioridad
11
33
34
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
R1303
1.0
Otorgar Puntos
Wilson Perez
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 de El puntaje del jugador se modificara, cuando se usen
Medicin
las siete fichas en el tablero
Excepcion
es
Observacio
nes/
Justificaci
n
Caso(s)
CU06
Requerimie R1203
Uso
CU15
nto(s)
R1103
Relacionad
CU16
Asociado(s)
o
Trazabilida
d
Modelo de
dominio
Documento
Casos de
uso:
CU06
CU15
CU16
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
3
MEDIO
Prioridad
Estado
Esfuerzo
Capa
35
36
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Aprobado
4 das
Servidor
R1403
1.0
Cambiar Fichas de Jugador
Andrs Fajardo
El sistema debe permitir al usuario cambiar las fichas
que el desee durante el tiempo de su turno (2
minutos) , mximo 3 veces por turno.
Objetivo
Para que jugador tenga la posibilidad de cambiar sus
fichas (mximo 3 veces por turno).
Criterio de Las fichas del jugador se cambiarn aleatoriamente
Medicin
durante su turno si este mismo lo pide, mximo
cambiaran mximo 3 veces por turno.
Excepcion
Las fichas escogidas por el jugador no se pudieron
es
cambiar satisfactoriamente.
Observacio
nes/
Justificaci
n
Caso(s)
CU12
Requerimie R1403
Uso
nto(s)
R1503
Relacionad
Asociado(s)
o
d
dominio
Documento
Casos
de
uso:
CU12
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
3
MEDIO
Estado
Esfuerzo
Capa
Aprobado
4 das
Servidor
37
38
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Prioridad
10
R1503
1.0
Cambiar fichas transaccionalmente.
Andrs Fajardo
Durante el momento de cambio de fichas, el jugador
no podr desistir de realizar esta accin, lo cual lo
obliga a terminarla.
Objetivo
Para asegurar que se realice el cambio de fichas por
jugador correctamente.
Criterio de Una vez dada la orden de cambio de fichas, el
Medicin
procedimiento
terminar
completamente
y
correctamente.
Excepcion
es
Observacio
nes/
Justificaci
n
Trazabilida
d
Caso(s)
CU12
Uso
Relacionad
o
Modelo de
dominio
Requerimie
nto(s)
Asociado(s)
Documento
Casos
de
uso:
CU12
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
3
MEDIO
Estado
Esfuerzo
Capa
Aprobado
4 das
Servidor
39
40
No.
Requerimi
ento
R1603
Prioridad
R1403
R1703
R2103
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
1.0
Pasar a siguiente turno.
Andrs Fajardo
El sistema debe permitir pasar al turno siguiente, si el
jugador en turno lo desea.
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 lmite no se haya cumplido.
Criterio de Una vez oprimido el botn de cambio de turno, el
Medicin
sistema cambia de turno satisfactoriamente.
Excepcion
es
Observacio
nes/
Justificaci
n
Caso(s)
CU14
Requerimie R1103
Uso
nto(s)
R1703
Relacionad
Asociado(s)
o
d
dominio
Documento
Casos
de
uso:
CU14
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
3
MEDIO
Estado
Esfuerzo
Capa
Aprobado
4 das
Servidor
41
42
No.
Requerimi
ento
Versin
Tipo
Nombre
Prioridad
R1703
1.0
Pasar a siguiente turno cuando tiempo lmite se haya
concluido.
Encargado Andrs Fajardo
Descripci El sistema deber pasar al siguiente turno si el tiempo
n
de la jugada llega a su lmite (2 minutos, Ver reglas de
WorDomination).
Objetivo
Asegurar que cumplidos dos minutos, se realice un
cambio automtico de turno.
Criterio de Pasados 2 minutos, se cambia el turno del jugador
Medicin
satisfactoriamente.
Excepcion
es
Observacio
nes/
Justificaci
n
Caso(s)
CU14
Requerimie R1103
Uso
nto(s)
R1603
Relacionad
Asociado(s)
o
d
dominio
Documento
Casos
de
uso:
CU14
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
3
MEDIO
Estado
Esfuerzo
Capa
Aprobado
4 das
Servidor
43
44
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
Prioridad
R1803
1.0
Mostrar Fichas.
Andrs Fajardo
El sistema debe mostrar en todo momento a los
jugadores las fichas que quedan por jugar.
Asegurar que el sistema muestre correctamente las
fichas correspondientes a cada jugador por cada
turno.
Criterio de Las fichas se

Medicin
puede usarlas
Excepcion
es
Observacio
nes/
Justificaci
n
Caso(s)
Uso
Relacionad
o
Trazabilida
d
muestran en la pantalla y el jugador

para jugar posteriormente.
CU11,
CU12
CU16,
CU17
CU18
Requerimie
nto(s)
Asociado(s)
Modelo de
dominio
Documento
Casos
de
uso:
CU11
CU12
CU16
CU17
CU18
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
3
MEDIO
Prioridad
10
R0103,
R0203,
R0603,
R0703,
R0803,
R1403
Estado
Esfuerzo
Capa
45
46
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Aprobado
4 das
Servidor
R1903
1.0
Validar jugadas.
Andrs Fajardo
El sistema debe validar las jugadas realizando una
comparacin de la palabra formada por el usuario con
ayuda de un diccionario de palabras totalmente
implementado dentro del sistema en una base de
datos.
Objetivo
Comprobar si el jugador obtuvo una respuesta
correcta o no.
Criterio de Si el usuario tiene una respuesta correcta, se le
Medicin
informa en un mensaje dicindole su correspondiente
puntaje y contina el siguiente turno.
Excepcion
es
Observacio
nes/
Justificaci
n
Caso(s)
CU04,
Requerimie R0103,
Uso
CU06,
nto(s)
R0303,
Relacionad CU14,
Asociado(s) R0403,
o
CU15
R0703,
R0803,
R0903,
R1003,
R1103,
R1203,
R1303
Trazabilida
d
Modelo de
dominio
Documento
Casos
de
uso:
CU04, CU06,
CU14, CU15
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
3
MEDIO
Estado
Esfuerzo
Capa
Aprobado
4 das
Servidor
47
48
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Prioridad
15
R2003
1.0
Finalizar partida si ningn jugador ubic palabras.
Andrs Fajardo
Descripci
n
El sistema terminara la partida cuando ningn jugador

pueda colocar mas fichas en el tablero bien sea por
lmite de tiempo o por palabras no vlidas o
incorrectas.
Objetivo
Evitar ms de dos turnos sin jugadas correctas.
Criterio de Si ninguno de los dos jugadores ubic palabras en sus
Medicin
dos turnos consecutivos respectivos,
el sistema
finaliza correctamente y notifica puntajes y ganador.
Excepcion
es
Observacio
nes/
Justificaci
n
Caso(s)
CU04,
Requerimie R0103,
Uso
CU05,
nto(s)
R0303,
Relacionad CU14,
Asociado(s) R0403,
o
CU15
R0703,
R0803,
R0903,
R1003,
R1103,
R1203,
R1303,
R1603,
R1703,
R1903
d
dominio
Documento
Casos
de
uso:
CU04, CU05,
CU14, CU15
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
3
MEDIO
Estado
Esfuerzo
Capa
Aprobado
4 das
Servidor
49
50
51
52
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
Criterio de
Medicin
Excepcion
es
Observacio
nes/
Justificaci
n
Prioridad
13
R2103
1.0
Habilitar lmite de tiempo en partida.
Andrs Fajardo
El sistema debe tener un lmite de tiempo.
Evitar partidas sin fin alguno, ni ganadores.
La partida debe tener un tiempo lmite (una hora).
Caso(s)
CU06
Requerimie
R2203
Trazabilida
d
Uso
CU08
Relacionad CU19
o
Modelo de
dominio
nto(s)
Asociado(s)
Documento
Casos
de
uso:
R2203
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
3
MEDIO
Estado
Esfuerzo
Capa
Aprobado
3 das
Servidor
53
54
55
No.
Requerimi
ento
Versin
Tipo
Nombre
Prioridad
13
R2203
1.0
Finalizar sistema por lmite de tiempo.
Encargado
Descripci
n
Objetivo
Criterio de
Medicin
Andrs Fajardo
El sistema debe terminar en caso que se termine el
tiempo lmite de tiempo.
Evitar partidas sin fin alguno, ni ganadores.
La aplicacin se finalizar cuando termine el tiempo
lmite, indicando antes de finalizar, quien fue el
ganador de la partida.
Excepcion
es
Observacio
nes/
Justificaci
n
Trazabilida
d
Caso(s)
CU06,
Uso
CU08
Relacionad CU19
o
Modelo de
dominio
Requerimie
nto(s)
Asociado(s)
Documento
Casos
de
uso:
R2203
Requerimie
ntos
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
3
MEDIO
Prioridad
13
R2103
Estado
Esfuerzo
Capa
56
57
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
Criterio de
Medicin
Aprobado
3 das
Servidor
R2303
1.0
Informar Ganador
Andrs Fajardo
El sistema debe informar a todos los jugadores quien
es el ganador de la partida.
Informar a los jugadores quien fue el ganador.
Si la aplicacin termina por cualquier motivo posible
(fin del tiempo, dos jugadores no pudieron ubicar ms
fichas o se les termin el tiempo), el sistema informa
quien ha sido el ganador.
Excepcion
es
Observacio
nes/
Justificaci
n
Caso(s)
Uso
Relacionad
o
Trazabilida
d
Requerimie
R0303,
R1703,
R1903,
R2003,
R2103,
CU15
Requerimie
nto(s)
Asociado(s)
R0303,
R1703,
R1903,
R2003,
R2103,
R2203
R2203
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
3
MEDIO
Estado
Esfuerzo
Capa
Aprobado
3 das
Servidor
57.2.1
Prioridad
10
Funcionalidad 2: Registro y Autenticacin
No.
Requerimie
nto
R240202
Versin
1.0
Tipo
Funcionales-Modo de Autenticacin
Nombre
Crear perfil de jugador
Encargado
Andrs Fajardo
Descripcin
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, seleccionndolo al inicio de la aplicacin.
Criterio de
Medicin
Excepcione
s
Observacio
nes/
Justificacin
Caso(s)
Uso
Relacionad
o
CU01,
CU07,
CU08,
CU09,
Requerimie
nto(s)
Asociado(s)
CU10
Trazabilidad
Modelo de
dominio
Documento
Casos
de
uso:
Requerimie
ntos
Asociados
R2502
R2603
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
MEDIO
Prioridad
12
R2502
R2603
Estado
Aprobado
Esfuerzo
5 das
Capa
Servidor
58
59
No.
Requerimie
nto
R2502
Versin
1.0
Tipo
Nombre
Crear tipo de usuario de jugador
Encargado
Andrs Fajardo
Descripcin
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 caractersticas asociadas.
Criterio de
Medicin
Excepcione
s
Observacio
nes/
Justificacin
Caso(s)
Uso
Relacionad
o
Trazabilidad
Modelo de
dominio
CU01
CU07
Requerimie
nto(s)
CU08
Asociado(s)
R2402
R2603
Documento
Casos
de
uso:
Requerimie
ntos
Asociados
R2502
R2603
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Prioridad
10
Costo
MEDIO
Estado
Aprobado
Esfuerzo
3 das
Capa
Servidor
60
61
No.
Requerimie
nto
R2603
Versin
1.0
Tipo
Nombre
Almacenar informacin de archivos de texto de cada

jugador.
Encargado
Andrs Fajardo
Descripcin
El sistema debe permitir almacenar la informacin en

archivos de texto de cada jugador registrado (Nombre
Completo, Nickname, contrasea).
Objetivo
Permitir la persistencia mediante almacenamiento de

la informacin de caractersticas de partidas de cada
jugador.
Criterio de
Medicin
Excepcione
s
Observacio
nes/
Justificacin
Caso(s)
Uso
Relacionad
o
Trazabilidad
Modelo de
dominio
Documento
Casos
de
uso:
Requerimie
ntos
Asociados
R2402
R2502
Reglas
CU01,
CU03,
CU07,
CU08
Requerimie
nto(s)
Asociado(s)
R2402
R2502
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
MEDIO
Estado
Aprobado
Esfuerzo
3 das
Capa
Servidor
62
63
64
No.
Requerimie
nto
Prioridad
10
R2703
Versin
1.0
Tipo
Nombre
Validar Informacin Ingresada
Encargado
Oscar Gmez Herrera
Descripcin
El sistema debe validar la informacin ingresada por cada uno de los

jugadores(NombreCompleto de 20 a 30 caracteres, Nickname 5 a 10
caracteres, contrasea de 6 a 15 caracteres)
Objetivo
Se cumplir que los datos ingresados en el

requerimiento 26 se han ciertos a y acorde con lo
establecido.
Criterio de El jugador deber ingresar los criterios de informacin

Medicin
bsicos para poder acceder al juego
Excepcione
s
Observacio
nes/
Justificacin
Datos Invlidos, Intente de nuevo

Ninguna
Caso(s)
Uso
Relacionad
o
Trazabilidad
CU01
CU02
Requerimie
nto(s)
Asociado(s)
Modelo de
dominio
Documento
Casos de
uso: CU01
CU02
Requerimi
entos
Asociados
R2603
Reglas
Wordomina
tion
(SPMP
Seccin
10.1)
Riesgo
Costo
Medio
Estado
Aprobado
Esfuerzo
15 das
Prioridad
14
R2603
Capa
65
No.
Requerimie
nto
Servidor
R2803
Versin
1.0
Tipo
Nombre
Verificar Acciones Redundantes
Encargado
Oscar Gmez Herrera
Descripcin
EL sistema debe validar cualquier tipo de informacin que un jugador

vaya a ingresar en la aplicacin con el fin de evitar redundancia
Objetivo
Evitar las posibles repeticiones de informacin en el

sistema
Criterio de Se dar informacin y advertir de que la informacin

Medicin
a ingresar ya se encuentra
Excepcione
s
Observacio
nes/
Justificacin
Ninguna
Caso(s)
Uso
Relacionad
o
Trazabilidad
Modelo de
dominio
Documento
Casos de
uso: CU01
CU02
CU01
CU02
Requerimie
nto(s)
CU07
Asociado(s)
R2502
R2603
CU07
Requerimie
ntos
Asociados
R2502
R2603
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
Medio
Estado
Aprobado
Esfuerzo
15 dias
Capa
Servidor
66
No.
Requerimie
nto
Prioridad
12
R2903
Versin
1.0
Tipo
Nombre
Confirmacin Jugador Creado
Encargado
Oscar Gmez Herrera
Descripcin
El sistema dar una confirmacin de la creacin de un jugador al usuario.
Objetivo
Permitir al sistema informar al usuario de la creacin

exitosa o no de la accin crear jugador
Criterio de El jugador estar informado si su perfil pudo ser

Medicin
creado, para poder jugar.
Excepcione
s
Observacio
nes/
Justificacin
Es obligatorio tener un usuario para poder acceder a

una partida del juego
Caso(s)
Uso
Relacionad
o
CU01
Requerimie
nto(s)
Asociado(s)
R2402,
R2502,
R2603,
R2703
Trazabilidad
Modelo de
dominio
Documento
Casos de
uso: CU01
Requerimie
ntos
Asociados
R2402
R2502
R2603
R2703
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
Alto
Estado
Aprobado
Esfuerzo
22 dias
67
No.
Requerimie
nto
Priorida
d
12
R3002
Versin
1.0
Tipo
Nombre
Eliminar Registro Creado
Encargado
Oscar Gmez Herrera
Descripcin
El sistema debe permitir al usuario eliminar el registro creado.
Objetivo
Permitir borrar la informacin seleccionada del

registro creado por parte del usuario
Criterio de El jugador recibir la confirmacin del xito o no de la

Medicin
accin por medio de un mensaje visual
Excepcione
s
Observacio
nes/
Justificacin
Para eliminar el registro deber existir
Caso(s)
Uso
Relacionad
o
Trazabilidad
Modelo de
dominio
Documento
Casos de
uso: CU01
Requerimie
ntos
Asociados
R2402
R2502
R2603
R2703
Reglas
CU02
CU03
Requerimie
nto(s)
Asociado(s)
R2402,
R2502,
R2603,
R2703
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
Medio
Estado
Aprobado
Esfuerzo
25 dias
Capa
Servidor
68
No.
Requerimie
nto
Prioridad
10
R3102
Versin
1.0
Tipo
Nombre
Ver Perfil
Encargado
Oscar Gmez Herrera
Descripcin
El jugador podr observar su perfil en el momento que lo desee.
Objetivo
Permitir dar informacin del usuario cuando este lo

solicite
Criterio de El Jugador deber poder ser informado del perfil

Medicin
pedido
Excepcione
s
Al no existir el perfil, dar mensaje visual de no valido
Observacio
nes/
Justificacin
El jugador deber existir para poder ver la informacin

del perfil
Caso(s)
Uso
CU03
Requerimie
nto(s)
R2603
Relacionad
o
Trazabilidad
Asociado(s)
Modelo de
dominio
Documento
Casos de
uso: CU03
Requerimie
ntos
Asociados
R2603
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
Medio
Estado
Aprobado
Esfuerzo
14 dias
Capa
Servidor
69
70
No.
Requerimie
R3203
Prioridad
11
nto
Versin
1.0
Tipo
Nombre
Eliminar Archivos
Encargado
Oscar Gmez Herrera
Descripcin
El sistema debe eliminar todos los datos de los archivos de persistencia.
Objetivo
Permitir borrar los archivos relacionados con el

juego(Persistencia)
Criterio de Se tendr la opcin de eliminar todos los archivos

Medicin
creados por medio de la aplicacin como opcin
adicional.
Excepcione
s
Observacio
nes/
Justificacin
Permitir una mejor eficiencia de los recursos de

hardware
Caso(s)
Uso
Relacionad
o
Trazabilidad
Documento
Casos de
uso: CU07
CU08
Requerimie
ntos
Asociados
Reglas
CU07
CU08
Requerimie
nto(s)
Asociado(s)
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
Bajo
Estado
Aprobado
Esfuerzo
2 dias
Capa
Servidor
71
72
73
No.
Requerimie
nto
Prioridad
R3302
Versin
1.0
Tipo
Nombre
Terminar Partida
Encargado
Oscar Gmez Herrera
Descripcin
El sistema debe permitir terminar la partida a los jugadores y al

administrador en el momento en el que lo deseen.
Objetivo
Permitir al sistema acabar en cualquier momento el

juego o partida deseados
Criterio de El jugador tendr la opcin de seguir o no en el juego

Medicin
Excepcione
s
Observacio
El usuario dar finalizar cuando se quiera salir de una
nes/
Justificacin
partida.
Caso(s)
Uso
Relacionad
o
Trazabilidad
CU08
Requerimie
nto(s)
Asociado(s)
Modelo de
dominio
Documento
Casos de
uso: CU08
Requerimie
ntos
Asociados
R3402
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
Medio
Estado
Aprobado
Esfuerzo
5 das
Capa
Servidor
Prioridad
11
R3402
74
75
No.
Requerimie
nto
R3402
Versin
1.0
Tipo
Nombre
Guarda Partida
Encargado
Oscar Gmez Herrera
Descripcin
El sistema debe permitir salvar (guardar) una partida si un usuario

requiere.
Objetivo
Permitir retomar un juego despus de terminado o

aplazado
Criterio de El usuario podr guardar su partida sino quiere

Medicin
seguirla en el tiempo dado
Excepcione
s
Observacio
nes/
Justificacin
Dar la opcin de jugar en otro momento la misma

partida
Caso(s)
Uso
Relacionad
o
Trazabilidad
Modelo de
dominio
Documento
Casos de
uso: CU07
CU08
Requerimie
ntos
CU07
CU08
Asociados
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
Bajo
Estado
Aprobado
Esfuerzo
15 das
Capa
Servidor
76
77
No.
Requerimie
nto
R3503
Versin
1.0
Tipo
Nombre
Terminar Partida(Desconexion)
Encargado
Oscar Gmez Herrera
Descripcin
El sistema terminara la partida en el momento que un jugador se

desconecte del juego.
Objetivo
El sistema se desconectara cuando no tenga conexin

con el servidor
Criterio de El sistemas dar como terminado cualquier jugo al no

Medicin
haber conexin
Excepcione
s
Observacio
nes/
Justificacin
Al no haber conexin el sistema se perder la

informacin de la partida(Si no se guardo)
Caso(s)
Uso
Relacionad
o
Trazabilidad
Requerimie
nto(s)
Asociado(s)
Modelo de
dominio
Documento
Casos de
uso:
Requerimie
ntos
Asociados
Reglas
WorDomina
tion
(SPMP
Seccin
10.1)
Riesgo
Costo
Alto
Estado
Aprobado
Esfuerzo
8 das
Capa
Servidor
77.2.1
Prioridad
Funcionalidad 3: Administracin
14
78
No.
Requerimie
nto
R3602
Versin
1.0
Tipo
Funcionales- Modo Administracin
Nombre
Eliminar Jugador
Encargado
Oscar Gmez Herrera
Descripcin
El sistema debe permitir al administrador eliminar un jugador, esperando

una confirmacin de fracaso o xito de la solicitud.
Objetivo
Eliminar un jugador cuando se exija
Criterio de El administrador tendr la opcin de eliminar cualquier

Medicin
jugador por conducta indebida
Excepcione
s
Observacio
nes/
Justificacin
El jugador ser sacado de la partidas y eliminado su

perfil.
Caso(s)
Uso
Relacionad
o
Trazabilidad
Modelo de
dominio
Documento
Casos de
uso: CU07
CU08
Requerimie
ntos
Asociados
CU02
CU03
Requerimie
nto(s)
Asociado(s)
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
Bajo
Estado
Aprobado
Esfuerzo
2 dias
Capa
Servidor
Prioridad
10
79
No.
Requerimie
nto
R3702
Versin
1.0
Tipo
Funcionales- Modo Administracin
Nombre
Eliminar Archivos(Administrador)
Encargado
Oscar Gmez Herrera
Descripcin
El sistema debe eliminar de los archivos de persistencia al jugador que el

administrador desee eliminar.
Objetivo
El administrador puede eliminar cualquier tipo de

archivo
Criterio de Se podr eliminar el archivo de un jugador especifico o

Medicin
varios de varios jugadores
Excepcione
s
Observacio
nes/
Justificacin
Mejorara la eficiencia del juego, para poder eliminar

archivos antiguos y no usados
Caso(s)
Uso
Relacionad
o
Trazabilidad
CU02
CU05
Requerimie
nto(s)
Asociado(s)
Modelo de
dominio
Documento
Casos de
uso: CU02
CU05
Requerimie
ntos
Asociados
R3002
Reglas
WorDomin
ation
(SPMP
Seccin
10.1)
Riesgo
Costo
Alto
Estado
Aprobado
Esfuerzo
15 das
Capa
Servidor
Prioridad
12
R3002
79.2.1
Funcionalidad 4: Consultas
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
R3802
1.0
Funcionales-Modo de Consulta
Consultar Estadsticas Usuario
Oscar Gmez Herrera
El sistema permitir a un usuario que tenga un perfil
creado en el juego consultar sus estadsticas dentro del
juego.
Cumplir con informar al usuario sobre su desempeo

en el juego
Criterio de El jugador deber indicar su ID para poder mostrar su
Medicin
informacion
Excepcion
ID invalido
es
Observacio Mostrar informacin de cada jugador
nes/
Justificaci
n
Caso(s)
CU03
Requerimie R3902
Uso
CU06
nto(s)
Relacionad
Asociado(s)
o
d
dominio
Documento
Casos de
uso: CU03
CU06
Requerimi
entos
Asociados
R3902
Reglas
Wordomina
tion
(SPMP
Seccin
10.1)
Riesgo
Costo
Estado
Esfuerzo
Capa
2
Medio
Aprobado
12 das
Servidor
Prioridad
80
81
82
83
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
R3902
1.0
Informacin Perfil(Restricciones)
Oscar Gmez Herrera
El sistema solo permitir consultar las estadsticas propias
de cada jugador que las solicite.
Cumplir con la privacidad de informacin para cada

jugador
Criterio de El jugador solicitante deber ingresar la informacin
Medicin
bsica para obtener la informacin(Nombre y
Contrasea)
Excepcion
Datos Invlidos, Intente de nuevo
es
Observacio Despus de 3 errores en la validacin de datos el
nes/
juego se sale.
Justificaci
n
Caso(s)
CU03
Requerimie R2603
Uso
CU06
nto(s)
R2703
Relacionad
Asociado(s)
o
Trazabilida
d
Riesgo
Costo
Estado
Esfuerzo
Capa
Modelo de
dominio
Documento
Casos de
uso: CU03
CU06
Requerimi
entos
Asociados
R2603
R2703
Reglas
Wordomina
tion
(SPMP
Seccin
10.1)
4
Medio
Aprobado
19 das
Servidor
Prioridad
12
84
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
R4002
1.0
Consulta Perfil de jugadores
Andrs Hidalgo
El sistema debe permitir ver perfil y estadsticas de los
dems jugadores.
Permite al usuario ver el desempeo de los dems

jugadores en la ejecucin de la aplicacin.
Criterio de En el momento de realizar esta consulta, deber
Medicin
mostrar la informacin correspondiente a las
estadsticas de los dems jugadores.
Excepcion
es
Observacio Ninguna
nes/
Justificaci
n
Caso(s)
Uso
Relacionad
o
d
dominio
Documento
Casos de
uso: CU03,
CU06, CU20
CU03
CU06
CU20
Requerimie
nto(s)
Asociado(s)
Requerimi
entos
Asociados
R1003,
R3102,
R3802
R3902
Reglas
Wordomina
tion
(SPMP
Seccin
10.1)
Riesgo
Costo
Estado
Esfuerzo
Capa
85
3
Medio
Aprobado
2 das
Servidor
Prioridad
10
R1003,
R3102,
R3802
R3902
86
87
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
R4102
1.0
Consulta
Consulta de Reglas y manuales
Andrs Hidalgo
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 resolucin de dudas que surjan durante
la ejecucin del juego
Criterio de Durante toda la ejecucin del juego, debe mostrar un
Medicin
botn de ayuda para los jugadores, el cual al
ejecutarlo deber mostrar la informacin requerida.
Excepcion
es
Observacio Ninguna
nes/
Justificaci
n
Caso(s)
CU21
Requerimie R5004
Uso
nto(s)
Relacionad
Asociado(s)
o
d
dominio
Documento
Casos de
uso: CU21
Requerimi
entos
Asociados
R5004
Riesgo
Costo
Estado
Esfuerzo
Capa
Reglas
Wordomina
tion
(SPMP
Seccin
10.1)
4
Medio
Aprobado
2 dias
Servidor
Prioridad
10
88
89
90
91
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
R4202
1.0
Consulta Numero de fichas en juego
Andrs Hidalgo
El sistema debe permitir al jugador consultar el nmero de
fichas que faltan por jugar.
Conociendo el numero de fichas que faltan por jugar,

el usuario sabr el estado de juego (esta en el inicio,
en el medio o finalizando)
Criterio de EL juego debe mostrar durante todo el juego las fichas
Medicin
que van quedando despus de haber colocado una
nueva palabra en el tablero hasta el final del juego.
Excepcion
es
Observacio Ninguna
nes/
Justificaci
n
Trazabilida
d
Riesgo
Costo
Estado
Esfuerzo
Capa
Caso(s)
Uso
Relacionad
o
Requerimi
entos
R0203,
R0703
Reglas
Wordomina
tion
(SPMP
Seccin
10.1)
4
Medio
Aprobado
2 das
Servidor
CU16
CU17
Requerimie
nto(s)
Asociado(s)
Prioridad
R0203
R0703
12
4.3 Requerimientos de Desempeo

No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
R4303
1.0
Dinmicos y Estticos
Jugadores en lnea
Andrs Hidalgo
El sistema soportara 4 posibles jugadores conectados al mismo
tiempo, es decir, de forma simultanea
Aclarar el mximo de usuarios que pueden estar
conectados a la espera de una partida
Criterio de Usuarios conectados de forma simultanea
Medicin
Excepcion
es
Observacio Ninguna
nes/
Justificaci
n
Caso(s)
Uso
Relacionad
o
Trazabilida
Modelo de
d
dominio
CU09
CU10
Requerimie
nto(s)
Asociado(s)
Documento
Casos de
uso:
CU09, CU10
Requerimie
ntos
Asociados
R4403,
R4601
Reglas
Wordominat
ion
(SPMP
Seccin
10.1)
Riesgo
Costo
5
Alto
Estado
Esfuerzo
Capa
Aprobado
2 das
Servidor
Prioridad
15
R4403
R4601
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
R4403
1.0
Dinmicos y Estticos
Jugadores en la partida
Andrs Hidalgo
La creacin de la partida debe tener por lo menos 2 jugadores y 4
como mximo.
Cuando el jugador administrador desee iniciar una
partida deber tener mnimo 2 jugadores, de lo
contrario el juego restringir el inicio de la partida
Criterio de El juego permitir la ejecucin de las partidas de
Medicin
juego solo en el momento que este el mnimo de
jugadores para jugar.
Excepcion
es
Observacio Ninguna
nes/
Justificaci
n
Caso(s)
CU09
Requerimie R4403
Uso
CU10
nto(s)
R4601
Relacionad
Asociado(s)
o
Trazabilida
Modelo de
d
dominio
Documento
Casos de
uso:
CU09, CU10
Requerimie
ntos
Asociados
R4403,
R4601
Reglas
Wordominat
ion
(SPMP
Seccin
10.1)
Riesgo
Costo
5
Alto
Estado
Esfuerzo
Capa
Aprobado
2 das
Servidor
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
R4503
Prioridad
15
1.0
Dinmicos y Estticos
Respuesta inmediata
Andrs Hidalgo
El sistema debe realizar respuestas en tiempo real, que no
intervengan o influyan en el flujo del juego
Mostrar la eficiencia del juego con respecto al manejo
de los tiempos.
Criterio de Se espera que el juego reaccione de manera
Medicin
inmediata ante cualquier accin que realicen los
jugadores en la aplicacin
Excepcione
s
Observacio Latencia del juego
nes/
Justificaci
Trazabilida
d
Caso(s)
Uso
Relacion
ado
Modelo de
dominio
Riesgo
Costo
4
Medio
Estado
Esfuerzo
Capa
Aprobado
1 das
Servidor
Requerimie
nto(s)
Asociado(s)
Prioridad
14
4.4 Restricciones De Diseo

No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
R4601
1.0
Restricciones de Funcionalidad
Comunicacin
Andrs Hidalgo
El sistema debe comunicarse por medio de una arquitectura ClienteServidor.
Hace parte de las restricciones estipuladas por el

cliente en el acuerdo del proyecto
Criterio de En el momento que un computador este dando
Medicin
repuestas a los dems durante el juego, se dar por
exitosa la comunicacion
Excepcion
es
Observacio Ninguna
nes/
Justificaci
n
Trazabilida
d
Caso(s)
Uso
Relacionad
o
Modelo de
dominio
Requerimie
nto(s)
Asociado(s)
R4601
Requerimi
entos
Asociados
R4601
Reglas
Wordomina
tion
(SPMP
Seccin
10.1)
Riesgo
Costo
Estado
Esfuerzo
Capa
3
Medio
Aprobado
2 dias
Servidor
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
R4701
Prioridad
12
1.0
Diseo O.O
Andrs Hidalgo
El diseo y creacin de la aplicacin debe ser orientado a objetos.
n
Objetivo
Aplicacin del Plan de Procesos Tcnicos (Ver Seccin

6 del SPMP)
Criterio de Utilizando lenguaje orientado a objetos (JAVA), en el
Medicin
desarrollo del producto.
Excepcion
es
Observacio Ninguna
nes/
Justificaci
n
Caso(s)
Requerimie
Uso
nto(s)
Relacionad
Asociado(s)
o
d
dominio
Riesgo
Costo
Estado
Esfuerzo
Capa
No.
Requerimi
ento
Versin
Tipo
Nombre
Reglas
Wordomina
tion
(SPMP
Seccin
10.1)
3
Medio
Aprobado
2 das
Servidor
Prioridad
12
R4801
1.0
Diseo acorde al modelo de dominio
Encargado
Descripci
n
Objetivo
Andrs Hidalgo
El diseo se realizara de acuerdo al modelo de dominio.
Poder aplicar de forma eficiente todo lo que el grupo

ha diseado para el desarrollo del juego.
Criterio de La aplicacin deber estar acorde al modelo de
Medicin
dominio diseado
Excepcion
es
Observacio Ninguna
nes/
Justificaci
n
Caso(s)
Requerimie
Uso
nto(s)
Relacionad
Asociado(s)
o
Trazabilida
Modelo de
d
dominio
Reglas
Wordominat
ion
(SPMP
Seccin
10.1)
Riesgo
Costo
Estado
Esfuerzo
Capa
3
Medio
Aprobado
2 das
Servidor
Prioridad
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
R4901
No.
Requerimi
ento
Versin
Tipo
R5004
1.0
Funcionamiento en el Sistema Operativo
Andrs Hidalgo
La aplicacin debe ejecutarse en la plataforma de Windows XP
Esto permitir ejecutar la aplicacin en un sistema

operativo conocido por el usuario, lo cual permitir un
uso ms fcil y eficiente
Criterio de El Juego debe estar en la capacidad de ejecutarse de
Medicin
forma correcta en este sistema operativo.
Excepcione
s
Observacio Ninguna
nes/
Justificaci
n
Caso(s)
Requerimie
Uso
nto(s)
Relacion
Asociado(s)
ado
Trazabilida SPMP
Casos de
d
Uso
Riesgo
4
Prioridad 14
Costo
Medio
Estado
Aprobado
Esfuerzo
2 das
Capa
Servidor
1.0
Nombre
Encargado
Descripci
n
Objetivo
Criterio de
Medicin
Consulta de Reglas y manuales

Andrs Hidalgo
La aplicacin debe poseer manuales de instalacin para los programas que
necesita en su ejecucin
Permitir mayor interaccin del juego con el usuario.

Un claro y fcil entendimiento por parte del usuario de
los manuales de instalacin, descartara cualquier tipo
de ambigedad en su manejo.
Excepcione
s
Observacio Ninguna
nes/
Justificaci
n
Caso(s)
Uso
Relacion
ado
Trazabilida SPMP:
d
Reglas de
juego
Riesgo
3
Costo
Bajo
Estado
Aprobado
Esfuerzo
2 dias
Capa
Servidor
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
CU02
CU07
CU12
Requerimie
nto(s)
Asociado(s)
Prioridad
R4102
R5104
R5104
1.0
Manual de Usuario
Andrs Hidalgo
La aplicacin debe tener un manual de usuario
Darle a conocer
al usuario, el manejo del juego al
alcance de sus manos.

Criterio de Un claro y fcil entendimiento por parte del usuario de
Medicin
los manuales de usuario, descartara cualquier tipo de
ambigedad respecto a la ejecucin del juego.
Excepcion
es
Observacio Ninguna
nes/
Justificaci
n
Caso(s)
Requerimie
R4102
Uso
nto(s)
R5004
Relacion
Asociado(s)
ado
Trazabilida SPMP
d
Riesgo
3
Prioridad 8
Costo
Bajo
Estado
Aprobado
Esfuerzo
2 das
Capa
Servidor
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
R5201
1.0
Consulta
Diseo Agradable (GUI fuerte)
Andrs Hidalgo
El sistema debe ser agradable visualmente
Hace parte de las restricciones acordadas con el

cliente en el planeamiento del proyecto, (Ver seccin
restricciones SPMP)
Criterio de La aceptacin de la apariencia debe ser superior al
Medicin
70% , teniendo en cuenta su buen diseo y fcil
manejo.
Excepcione
s
Observacio Ninguna
nes/
Justificaci
n
Caso(s)
Requerimie
Uso
nto(s)
Relacion
Asociado(s)
ado
Trazabilida SPMP
d
Riesgo
5
Prioridad 14
Costo
Estado
Esfuerzo
Capa
No.
Requerimi
ento
Versin
Tipo
Nombre
Encargado
Descripci
n
Objetivo
Alto
Aprobado
2 das
Servidor
R5301
1.0
Consulta
Funcionamiento en laboratorios
Andrs Hidalgo
El sistema debe funcionar perfectamente en los laboratorios de la facultad
El sistema como tal debe correr correctamente en las

salas de la facultad pues es una de las restricciones
establecidas por el cliente en el acuerdo del proyecto.
(Ver Restricciones SPMP)
Criterio de El sistema deber correr correctamente en las salas
Medicin
Excepcione
s
Observacio Ninguna
nes/
Justificaci
n
Caso(s)
Requerimie
Uso
nto(s)
Relacion
Asociado(s)
ado
Trazabilida SPMP
d
Riesgo
5
Prioridad 14
Costo
Medio
Estado
Aprobado
Esfuerzo
Capa
2 das
Servidor
4.5 Atributos del Sistema de Software (No funcionales)

Este tipo de atributos se caracterizan por no tener una relacin 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 ejecucin, estructura y
organizacin del programa fuente y la respectiva documentacin. A continuacin
de mostraran algunos de los atributos con los que deber contar el producto
final que se le mostrara al cliente: [N Referencia]
[N Referencia]Ian Sommerville 2000, Software Engineering, 6th Edition. Chapter 1
ATRIBUTO
Confiabilidad
APLICACION
El sistema debe de soportar todas las

funcionalidades
anteriormente
descritas y garantizar su buen
funcionamiento durante todo el
perodo de su ejecucin. Para ello, se
utilizarn patrones de diseo 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
localizacin, perfiles de jugadores,
etc., debern estar disponibles como
mnimo al menos durante la ejecucin
de la aplicacin.
Seguridad
En un principio, ser el propio usuario

de la aplicacin 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 rpida, tanto en la resolucin
de los problemas presentados a cada
turno de juego, como en el desarrollo
general de las partidas. Desde el punto
de vista de la gestin de datos, la
aplicacin se ha diseado de forma
eficiente.
Fcil Manejo
La aplicacin va dirigida tanto a personas

expertas en informtica como a personas
con conocimientos muy bajos o casi
nulos, por tanto, su diseo ha de estar
pensado para este ltimo tipo de
personas. Esto se deber conseguir
mediante
mens
y
pantallas
suficientemente intuitivas y fciles de usar
para cualquier usuario de la aplicacin.
4.6 Requerimientos de la base de datos

Para la especificacin de los requerimientos de la Base de Datos, es
necesario tener en cuenta varios aspectos, entre estos se encuentran:
Tipos de datos
almacenados
Frecuencia de
acceso
Tipo de consultas
utilizadas
Uso de Primary
key
Indexacin de los
datos
Ilustracin 7: Caractersticas Bases de Datos
Tipos de datos almacenados: dependiendo del motor de

base de datos escogidos, es posible tener diferentes tipos de
datos, sin embargo al hacer esta seccin podran incluirse los
ms usados: Char, Varchar, Numeric y Date por mencionar
algunos.
Tipo de consultas utilizadas: la forma en que los datos sern
accedidos, consultadas e ingresados desde los DAOs (Data
Access Object) para evitar la introduccin de sentencias
malintencionadas. Los tipos ms conocidos son Statement y
Prepared Statment.
Indexacin de los datos: la eficiencia de las consultas
complejas pueden reducirse dependiendo de la forma en que se
haga el diseo de la base de datos, una buena forma de mostrar
este aspecto es con el diagrama de Entidad Relacin
Utilizacin de Primary Key: al igual que con el aspecto
anterior la utilizacin adecuada de una primary key puede
evitar ciclos y adems permite y facilita eficiencia en el tiempo
de consultas hechas en tiempo real.
Frecuencia de acceso: dependiendo del tipo de sistema que

se desea implementar, especificar la frecuencia de acceso a la
base de datos incluyendo el nmero de conexiones abiertas y
tener en cuenta el tipo de consulta utilizada, la carga extra que
puede producir el manejo de DAOs puede disminuir,
aumentando de esta forma el desempeo en general de la
aplicacin.
5 Anexos

SRS v.0.5 (Plantilla Corregida)

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SRS v.0.5 (Plantilla Corregida)

Uploaded by

Copyright:

Available Formats

S.G.P.M.

Andres Fajardo Bermudez

2 CICLO DE VIDA DE REQUERIMIENTOS...................................................16

4.1 REQUERIMIENTOS DE INTERFACES EXTERNAS.............................................................51

1.3 Definiciones, Acrnimos, y Abreviaciones

Administrador de Configuraciones [2]: Es el encargado de controlar la

E.I.: Entradas externas.

puedan ocurrir en el proyecto y crear planes para minimizar sus efectos en

Requerimiento Correcto [14]:

implementa apropiadamente (o no) cada requerimiento. Si un

[8] Definicin de SRS y SDD.

[11] Susan Snedaker, How to Cheat at IT Project Management, Syngress,

[22] Suzanne Robertson / James Robertson, Mastering the

[26] Definicin de Scrabble. Disponible en:

1.5 Apreciacin Global

2 Ciclo de Vida de Requerimientos

2.1 Identificacin de Stakeholders

Cliente (Miguel Torres): Es la persona encargada de definir los

2.2 Necesidades del usuario

2.3 Participacin por roles

2.4.1 Identificacin de Requerimientos

La identificacin de Requerimientos es el primer paso dentro de nuestro

Requerimientos de negocio: Representan a gran nivel los objetivos de la

Requerimientos de Usuario: Describen las tareas de los usuarios que deben

[Ian Sommerville 2000, Software Engineering, 6th Edition. Chapter 5]

Requerimientos del Producto: Este tipo de requerimientos especifican

los de portabilidad y los de usabilidad. [Tomado de :

Requerimientos Organizacionales: Este tipo de requerimientos se

Requerimientos Externos: Este tipo de requerimientos Se derivan de

Con base en tcnicas de especificacin [55] buscaremos la mejor clasificacin,

Se baso en el uso de tcnicas cognitivas planteadas por Nadina Martnez en su

A) Identificacin de Requerimientos y Su nivel de Valorizacin general

B) Prioridad segn el Rol

puntos de valoracin y as priorizar tanto

En esta clasificacin se dar la

La priorizacin de requerimientos se dar de una clasificacin de 1 a 10 siendo

Gestin de Preferencias de Requerimientos basada en

Figura trazabilidad hacia adelante

Figura trazabilidad hacia atrs

Para poder realizar este seguimiento S.G.P.M se ayudara de herramientas

implementados, pasen por un conjunto de pruebas y planes ya establecidos en

2.4.5 Validacin y verificacin.

2.5 Administracin de requerimientos

Dispositivo utilizado para el ingreso de

3.1.3 Interfaces con el Hardware

Como se haba especificado ya por el cliente, los productos de SGPM buscaran

3.1.4 Interfaces con el Software

Windows es el sistema operativo ms

A partir de la versin 5.0

Tabla 3: Interfaces con el Software

3.1.5 Interfaces de Comunicacin

3.1.6 Restricciones de Memoria

Wordomination no tendra ningun momento de inactividad en el momento de

3.1.8 Requerimientos de Adaptacin del Sitio

3.2 Funciones del Producto

3.3 Caractersticas del Usuario

Nombre del Actor

Teniendo en cuenta el cuadro anterior, presentaremos las caractersticas del

El juego manejara nicamente el idioma espaol para su ejecucin y

WorDomination no contara con la caracterstica de ser tolerante a fallos,

Las especificaciones mnimas de hardware se podrn ver en la seccin

De igual forma se podrn encontrar las especificaciones mnimas de

Teniendo en cuenta que el sistema se realizara sobre software libre, esto