SRS v.0.5 (Plantilla Corregida)

S.G.P.M.SRS

S.G.P.M.

31 / 10 / 09

SRS – Especificación de Requerimientos de Software – V.0.2

Andres Fajardo Bermudez

Andres Hidalgo

Hernan Garcia Peña

Oscar Gomez

Wilson PerezHISTORIAL DE CAMBIOS

S.G.P.M.SRS

VERSION FECHA SECCIÒN MODIFICADA

DESCRIPCION CAMBIOS

RESPONSABLES

V.0.1 Sabado, 5 de Septiembre de 2009.

1.1, 1.3, 1.4. Se realizaron aportes de ideas para las secciones descritas.

S.G.P.M.

V.0.2 Sabado, 12 de Septiembre de 2009.

1.2, 1.5 Se completaron las secciones faltantes.

S.G.P.M.

Tabla 1: Historial de cambios

S.G.P.M.SRS

TABLA DE CONTENIDO

TABLA DE CONTENIDO.............................................................................................................. 3

LISTA DE TABLAS........................................................................................................................ 5

LISTA DE ILUSTRACIONES..................................................................................................................... 6

1 INTRODUCCIÓN................................................................................................................................. 7

1.1 PROPÓSITO............................................................................................................................................71.2 ALCANCE...............................................................................................................................................81.3 DEFINICIONES, ACRÓNIMOS, Y ABREVIACIONES............................................................................................91.4 REFERENCIAS.......................................................................................................................................131.5 APRECIACIÓN GLOBAL...........................................................................................................................14

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

2.1 IDENTIFICACIÓN DE STAKEHOLDERS..........................................................................................................162.2 NECESIDADES DEL USUARIO....................................................................................................................172.3 PARTICIPACIÓN POR ROLES....................................................................................................................172.4 PROCESO DE REQUERIMIENTOS................................................................................................................18

2.4.1 Identificación de Requerimientos..............................................................................................182.4.2 Especificación de Requerimientos............................................................................................212.4.3 Priorización de Requerimientos................................................................................................222.4.4 Trazabilidad..............................................................................................................................262.4.5 Validación y verificación...........................................................................................................26

2.5 ADMINISTRACIÓN DE REQUERIMIENTOS.....................................................................................................262.6 INTERFACES.........................................................................................................................................26

3 DESCRIPCIÓN GLOBAL..................................................................................................................... 27

3.1 PERSPECTIVA DEL PRODUCTO..................................................................................................................273.1.1 Interfaces con el sistema..........................................................................................................273.1.2 Interfaces con el usuario...........................................................................................................283.1.3 Interfaces con el Hardware.......................................................................................................303.1.4 Interfaces con el Software.........................................................................................................303.1.5 Interfaces de Comunicación......................................................................................................353.1.6 Restricciones de Memoria.........................................................................................................353.1.7 Operaciones..............................................................................................................................353.1.8 Requerimientos de Adaptación del Sitio...................................................................................36

3.2 FUNCIONES DEL PRODUCTO....................................................................................................................373.3 CARACTERÍSTICAS DEL USUARIO...............................................................................................................373.4 RESTRICCIONES.....................................................................................................................................393.5 MODELO DEL DOMINIO.........................................................................................................................403.6 SUPOSICIONES Y DEPENDENCIAS..............................................................................................................43

S.G.P.M.SRS

4 REQUERIMIENTOS ESPECÍFICOS....................................................................................................... 45

4.1 REQUERIMIENTOS DE INTERFACES EXTERNAS..............................................................................................514.1.1 Interfaces con el Usuario..........................................................................................................514.1.2 Interfaces con el Hardware.......................................................................................................524.1.3 Interfaces con el Software.........................................................................................................544.1.4 Interfaces de Comunicaciones..................................................................................................55

4.2 CARACTERÍSTICAS DEL PRODUCTO DE SOFTWARE........................................................................................554.3 REQUERIMIENTOS DE DESEMPEÑO...........................................................................................................574.4 RESTRICCIONES DE DISEÑO.....................................................................................................................594.5 ATRIBUTOS DEL SISTEMA DE SOFTWARE (NO FUNCIONALES).........................................................................60

4.5.1 Confiabilidad.............................................................................................................................604.5.2 Disponibilidad...........................................................................................................................604.5.3 Seguridad..................................................................................................................................604.5.4 Mantenibilidad.........................................................................................................................614.5.5 Eficiencia...................................................................................................................................614.5.6 Facilidad de Uso........................................................................................................................61

4.6 REQUERIMIENTOS DE LA BASE DE DATOS...................................................................................................61

5 ANEXOS.......................................................................................................................................... 64

S.G.P.M.SRS

Lista de Tablas

Tabla 1: Historial de cambios......................................................................................1Tabla 2: Acrónimos.....................................................................................................7Tabla 3: Interfaces con el Software...........................................................................13Tabla 4: Descripción de las Características del Usuario............................................17Tabla 5: Definiciones del Modelo de Dominio...........................................................19Tabla 6: Formato de documentación del Modelo del Dominio..................................20Tabla 7: Documentación de Requerimientos............................................................27

S.G.P.M.SRS

Lista de Ilustraciones

Ilustración 1: Propósito................................................................................................................................5Ilustración 2: Alcance...................................................................................................................................6Ilustración 3: Apreciación Global..................................................................................................................7Ilustración 4: Tipos de productos de software.............................................................................................8Ilustración 5: Interfaces con el usuario......................................................................................................10Ilustración 6: Operaciones..........................................................................................................................15Ilustración 7: Tips para definir funciones del producto..............................................................................16Ilustración 8: Características del Usuario...................................................................................................17Ilustración 9: Restricciones.........................................................................................................................18Ilustración 10: Limitaciones........................................................................................................................18Ilustración 11: Descripción documentación del modelo del dominio.........................................................20Ilustración 12: Suposiciones.......................................................................................................................21Ilustración 13: Dependencias [1]................................................................................................................21Ilustración 14: Distribución de requerimientos..........................................................................................23Ilustración 15: Características de los Requerimientos................................................................................26Ilustración 16: Documentación de Requerimientos...................................................................................28Ilustración 17: Interfaces con el Usurario...................................................................................................29Ilustración 18: Interfaces de Hardware......................................................................................................30Ilustración 19: Interfaces con el Software..................................................................................................31Ilustración 20: División por Funcionalidades..............................................................................................32Ilustración 21: Ejemplo Enunciado Requerimientos...................................................................................34Ilustración 22: Atributos de Calidad a tener en cuenta..............................................................................35Ilustración 23: Características de Confiabilidad..........................................................................................36Ilustración 24: Características de Disponibilidad........................................................................................37Ilustración 25: Características de Seguridad...............................................................................................37Ilustración 26: Características de Mantenibilidad......................................................................................38Ilustración 27: Portabilidad del Sistema.....................................................................................................38Ilustración 28: Características Bases de Datos...........................................................................................39

S.G.P.M.SRS

1 Introducción

1.1 Propósito

El propósito o razón por la cual es vital la efectiva realización de un SRS bien documentado, se fundamenta en el hecho de que los requerimientos son atributos vitales y necesarios en un sistema, son declaraciones que identifican factores en cuanto a características, capacidades o calidad de un sistema con el fin de que tenga valor y utilidad para un cliente o usuario final, convirtiéndose así en la clave del éxito (o fracaso) de un proyecto técnico, y la base de el trabajo que viene en su futuro desarrollo, por lo cual es importante realizar una buena documentación de la especificación de los requerimientos, originando de esta manera que se satisfagan los objetivos del cliente correctamente [4].

Para el contexto de la materia de Ingeniería de Software, se obtendrán requerimientos del proyecto escogido (WorDomination) con la finalidad descrita anteriormente, para lo cual se describirán sus requerimientos más importantes mediante procedimientos descritos posteriormente.

Vale la pena considerar que -como se mencionó en el SPMP previamente- puesto que es imposible “calcar” o hacer una réplica exacta de las funcionalidades de un software, el SRS siempre estará incompleto en cuanto a la identificación de requerimientos de una u otra manera. [5]

El SRS concierne tanto al cliente (que determina si las especificaciones del producto se cumplen o no de acuerdo a los requerimientos buscados por él – en caso de no cumplirse, el proyecto será considerado como un fracaso. [10] y [11]), para el desarrollador (que de acuerdo a la especificación puede identificar mejor los casos de uso asociados y con base en esto realizar un desarrollo e implementación efectivos) y para el grupo S.G.P.M., puesto que como ingenieros de sistemas se tiene la responsabilidad de proveer la documentación correspondiente de requerimientos y sus funciones de alto nivel que serán implementadas. [10]

S.G.P.M.SRS

1.2 Alcance

S.G.P.M. está encargado de la realización de desarrollo de una aplicación que modela el juego original Scrabble [26], junto con su documentación respectiva, con el fin de que se satisfagan los requerimientos y necesidades del cliente, que en nuestro caso es el Ingeniero Miguel Eduardo Torres Moreno.

Básicamente, se manejarán dos tipos de usuarios del software: el jugador (o clientes) y el administrador (o servidor), y sus funcionalidades son las que se muestran a continuación (también se pueden observar en la Sección 2.1.7 – Funcionamiento):

TIPO DE USUARIO FUNCIONALIDAD

Administrador Crear partidas Lanzar Partidas Cargar Partidas.

Jugador Usuarios Crear Jugador Borrar Jugador Ver Detalles Jugador Añadir Palabra Eliminar Palabra Ver puntaje Salvar Partida Cambiar Fichas Pasar Turno Deshacer Jugada Validar Jugada Colocar Ficha en el tablero Quitar ficha del tablero Mover ficha en el tablero Salir Ver Log

S.G.P.M.SRS

1.3 Definiciones, Acrónimos, y Abreviaciones

A Administrador de Configuraciones [2]: Es el encargado de controlar la evolución del sistema de Software. Incluye identificación (reflejar estructura del producto y sus componentes con sus respectivas ids de versiones y id de configuración), control (tomar decisiones sobre la salida de un producto y sus cambios través del ciclo de vida asegurando consistencia según la línea base), registro de estado (recordar y reportar sobre el estado de los componentes y sus peticiones de cambios), auditoría y revisión (validar que el producto esté completo y mantener su consistencia a través de componentes, asegurando que están en el estado apropiado durante el proyecto.

Arquitecto del sistema [3]: Es aquel encargado de la arquitectura del software, o de la estructura (o estructuras) del sistema que compromete varios elementos de Software, las propiedades externamente visibles de esos elementos y las relaciones entre estos.

Aplicación Cliente- Servidor: Una aplicación con arquitectura Cliente/Servidor es en la cual se requiere que haya dos partes que cumplan funciones distintas, una que requiera de un servicio (cliente) y otra que lo preste (servidor), permitiendo además que puedan realizar procesos de manera paralela o independiente entre ellos.

Artefactos del proyecto [13]: Productos de trabajo desarrollados durante el tiempo de vida del proyecto.

E E.I.: Entradas externas.E.O.: Salidas externas (con operación matemática).E.Q.: Consultas sobre el sistema.Entregables del proyecto [13]: Artefactos diseñados para el cliente.

G Gerente de Proyecto [3]: El gerente es una persona encargada de la gestión del proyecto, o de planear y ubicar recursos para asegurar la entrega de un sistema de calidad de Software con el tiempo, calidad y presupuesto adecuados, enfrentándose a dos barreras importantes: complejidad y cambio.

Gestor de Calidad [9]: Persona encargada del plan de aseguramiento de

S.G.P.M.SRS

calidad en el Software, especificando claramente cual será el propósito del plan del proyecto, la organización y los estándares que se usarán.

Gestor de Riesgos [2]: Persona encargada de identificar riesgos que puedan ocurrir en el proyecto y crear planes para minimizar sus efectos en este [2].

I IDE [1]: (Integrated Development Environment - Entorno integrado de desarrollo). Aplicación compuesta por un conjunto de herramientas útiles para un programador.

IEEE [7]: IEEE es una organización sin ánimo de lucro, una asociación líder profesional en el avance de la tecnología. Originalmente era un acrónimo para “Instituto de Ingenieros Electrónicos y Eléctricos” pero hoy en día se ha expandido de tal manera que tan solo le llamamos IEEE (pronunciado “I Triple E”).

J JDBC: Java database Connectivity: Librería de Java que facilita la labor de conexión a una base de datos desde cualquier IDE.

L Línea Base [6]: Producto de trabajo que ha sido formalmente desarrollado y acordado, que puede ser cambiado solo por medio de cambios acordados en procedimientos en el plan de administración de configuraciones. Un producto de trabajo del documento base puede ser el origen de futuros desarrollos.

P Porcentaje de avance [6]: Son documentos que irán indicando el porcentaje de avance que se lleva de distintas líneas base de un documento

Producto de Trabajo [6]: Es todo elemento tangible que resulte en función de realizar un proyecto, actividad o tarea. Ej. Requisitos de clientes, plan de proyecto, especificaciones funcionales, documentos de diseño, código fuente y objeto, manual del usuario, instrucciones de instalación, planes de pruebas, etc

Puntos de Función: Técnica estándar utilizada para la medición del tamaño del software

R Requerimiento: Atributo vital y necesarios en un sistema, es una declaración que identifica un factor de características, capacidades o calidad de un sistema para que tenga valor y utilidad para un cliente o

S.G.P.M.SRS

usuario final

Requerimiento Completo [14]:

Requerimiento que describa completamente la funcionalidad a ser entregada, conteniendo toda la información necesaria para el desarrollador para que diseñe e implemente esa parte de la funcionalidad.

Si se sabe que no se tiene aún cierta información se puede usar PD (por determinar) como una manera de resaltar que faltan estas cosas, se deben resolver estas partes faltantes antes de proceder con la construcción de dicha porción.

Requerimiento Correcto [14]:

Requerimiento que describe la funcionalidad que se va a construir, para saber si es correcto primero debe saberse la fuente del requerimiento, si es un requerimiento para el usuario actual o de alto nivel del sistema. Un requerimiento de software que tenga conflictos con un requerimiento de un sistema padre, no es correcto.

Requerimiento Excelente [14]:

Es un requerimiento completo, correcto, factible, necesario, priorizable, no ambiguo y verificable.

Requerimiento Factible [14]:

Debe ser posible implementar cada requerimiento, sabiendo las limitaciones y capacidades del sistema y su entorno operacional. Para evitar especificar requerimientos que no sean obtenibles o factibles, se debe contar con un desarrollador o un analista de requerimientos durante el proceso de recolección de los mismos, con el fin de que este mencione lo que se puede hacer o no ya sea por restricciones técnicas o de costo.

Para esto son importantes el desarrollo incremental de la aplicación y los prototipos, que permiten evaluar la factibilidad de requerimientos.

Requerimiento Necesario [14]:

Cada requerimiento debe documentar una capacidad que el cliente realmente necesite o que se requiera para que el sistema se adapte a un requerimiento externo o un estandar. Cada requerimiento debe originarse de una fuente que tenga la autoridad de especificar requerimientos, bien sea por el mismo cliente, casos de uso, regla del negocio, etc.

S.G.P.M.SRS

Requerimiento No ambiguo [14]:

Todos los lectores de un requerimiento deben obtener una y solo una interpretación del mismo, por lo cual sabiendo que el lenguaje tiende a ser ambiguo, es importante que se escriban los requerimientos de forma simple, concisa, concreta y con un lenguaje apropiado según el usuario, por supuesto que además debe ser entendible.

Requerimiento Priorizable [14]:

Cada requerimiento funcional, característica o caso de uso debe tener asignada una prioridad de acuerdo a su importancia según el lanzamiento de un producto en particular. Si todos se consideran igual de importantes, será muy difícil para que el gerente del proyecto pueda responder efectivamente a estimaciones de costos o presupuesto, pérdida de personal, o nuevos requerimientos que salgan del desarrollo.

Requerimiento Verificable [14]:

Es importante desarrollar pruebas o usar otros métodos de verificación (como inspección o demostración) para determinar si un producto implementa apropiadamente (o no) cada requerimiento. Si un requerimiento no es verificable, determinar si está correctamente implementado o no, es solo cuestión de opinión y no de análisis objetivo. Los requerimientos que no sean completos, consistentes y no ambiguos, tampoco son verificables.

S S.D.D. [8]: Software Design Document. Es el documento resultado del proceso de diseño, describe prácticas recomendadas para describir los diseños de software y especifica la información que debe contener, además de recomendar la manera en que debe organizarse.

S.P.M.P. [6]: Software Project Management Plan: Es el documento de Plan Para la Gestión de Proyectos de Software, en el cual se mostrará el plan para la gestión definiendo funciones técnicas y de gestión de proyectos, actividades y tareas que sean requeridas para satisfacer los requisitos de un proyecto de Software.

S.R.S. [8]: Software Requirements Specification. Es la especificación de las funciones que realiza un determinado producto de software, programa o conjunto de programas en un determinado entorno. Este documento puede desarrollarlo personal representativo de la parte suministradora, o

S.G.P.M.SRS

de la parte cliente; si bien es aconsejable la intervención de ambas partes.

Tabla 2: Definiciones, acrónimos y abreviaciones.

1.4 Referencias

[1] Definición de IDE: http://www.alegsa.com.ar/Dic/ide.php

[2] Ian sommerville, Ingeniería de software, Séptima edición, Pearson, 2005.

[3] Bernd Bruegge & Allen H. Dutoit, Object Oriented Software Engineering. Conquering Complex and Changing Systems, Prentice Hall, 1999.

[4] Ralph R. Young, The Requirements Engineering Handbook, 2004. [5] George Stepanek, Software Project Secrets, Apress, 2005. [6] TORRES, Miguel. Plantilla SPMP IronWorks. Documento Disponible en: http://sophia.javeriana.edu.co/~metorres/ SPMP - Norma IEEE 1058.1 para la planificación de proyectos de

software: www.pgsi-g5.googlecode.com/files/T9899_ICaballero.pdf

[7] Definición de IEEE tomada de: http://www.ieee.org/web/aboutus/home/index.html

[8] Definición de SRS y SDD. http://www.navegapolis.net/files/cis/CIS_1_05.pdf

[9] IEEE Std. 730-1-1-1995 Software Quality Assurance Plan. [10] Ronald Kirk Kandt, Software Engineering Quality Practices, Taylor & Francis Group,

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

Syngress, 2005 [12] Roger S. Pressman, Ingeniería del Software, McGraw-Hill, 2002. [13] Dorota Huizinga / Adam Kolawa, Automated Defect Prevention, Wiley, 2007. [14] Karl E. Wiegers, Software Requirements 2nd Edition, Microsoft Press, 2003 [15] Jag Sodhi & Prince Sodhi, IT Project Management Handbook, Management

Concepts, Inc, 2002 [16] Entrepreneur Press and Sid Kemp, Project Management Made Easy, 2006. [17] Jennifer Greene & Andrew Stellman, Head First Pmp, O Reilly, 2009. [18] Stephen Withall, Software Requirement Patterns, Microsoft Press, 2007 [19] Ana Maria Ortiz, SRS y Calidad de Requerimientos. [20] Luis Carlos Diaz - Miguel Torres, Las Buenas Prácticas de la Ingeniería de

Requerimientos y los Mapas Mentales como Instrumentos de Apoyo al Proceso de

http://www.navegapolis.net/files/cis/CIS_1_05.pdf

http://www.ieee.org/web/aboutus/home/index.html

http://www.pgsi-g5.googlecode.com/files/T9899_ICaballero.pdf

http://sophia.javeriana.edu.co/~metorres/

http://www.alegsa.com.ar/Dic/ide.php

S.G.P.M.SRS

Software, 2007 [21] Ian F. Alexander / Richard Stevens, Writing Better Requirements, Pearson, 2002 [22] Suzanne Robertson / James Robertson, Mastering the

Requirements Process 2nd Edition, Addison Wesley, 2006 [23] Aybüke Aurum and Claes Wohlin, Engineering and Managing

Software Requirements, Springer, 1998 [24] Proyecto SMARTRUMMY-Q, Grupo SmartWare, 2008. [25] Proyecto Tiger Rummy, Grupo Albine, 2008. [26] Definición de Scrabble. Disponible en: http://es.wikipedia.org/wiki/Scrabble [27] Construx Software Builders, Inc, 2000- 2002. Disponible en: www.construx.com

1.5 Apreciación Global

En el SRS se presenta la documentación de los requerimientos funcionales que describen el comportamiento esperado de la aplicación WorDomination, y la correcta certificación de calidad de estos, mediante el uso de las listas de chequeo de Construx. [27]

Por lo tanto, este SRS debería usarse para un correcto desarrollo, pruebas, aseguramiento de la calidad, gestión de proyecto y funcionalidades del proyecto en general. [14]

Para finalizar, es importante mencionar que el SRS incluye también los requerimientos no funcionales que ayudan a la obtención de objetivos del proyecto y descripciones de atributos de calidad del producto desarrollado a partir del mismo, los cuales amplían la descripción de atributos de calidad características que debe manejar (usabilidad, portabilidad, integridad, eficiencia y robustez), proporcionando funcionalidades importantes para el cliente o los desarrolladores; a su vez otros requerimientos no funcionales describen interfaces externas entre el sistema y el mundo externo, al igual que el diseño e implementación de restricciones. [14]

http://www.construx.com/

http://es.wikipedia.org/wiki/Scrabble

S.G.P.M.SRS

Con la finalidad de lograr satisfactoriamente lo propuesto, en general S.G.P.M busca la correcta ingeniería de requerimientos, o ciencia encargada de encontrar, establecer y documentar los requerimientos de software, a través de un proceso de 4 fases (Recolección, Análisis y Negociaciones, Documentación y Validación) el cual se puede observar en el proceso de Ingeniería de Requerimientos (ver Sección 2.4) y su correcta especificación mediante las características que debería tener un requerimiento excelente (completo, correcto, factible, necesario, priorizable, no ambiguo y verificable), logrando a su vez que el SRS sea completo, consistente, modificable y trazable a través de las listas de chequeo ya descritas [14], [20], [27].

Para observar las descripciones detalladas de requerimientos del sistema, se puede observar la sección 3 – Requerimientos Específicos.

S.G.P.M.SRS

2 Ciclo de Vida de Requerimientos

El Ciclo de Vida de Requerimientos es el encargado de exponer la forma en que se lleva a cabo uno de los procedimientos más importantes del SRS: el Proceso de Requerimientos, que involucra el entendimiento de necesidades y expectativas del cliente (identificación y obtención de requerimientos – ver Sección 2.4.1), análisis y especificación de requerimientos (ver Sección 2.4.2), priorización y ubicación (ver sección 2.4.3), trazabilidad y verificación y validación de los mismos (ver Secciones 2.4.4 y 2.4.5 respectivamente), con el objetivo de tener une enfoque basado en la calidad del producto. [4]

2.1 Identificación de Stakeholders

Para identificar satisfactoriamente a los stakeholders del proyecto, hay que tener en cuenta que son todas aquellas personas que tienen algún interés en el producto, por supuesto se incluye al cliente (o persona que paga por su desarrollo), los usuarios finales que operan el producto, otras personas que influencien el proyecto o con el conocimiento necesario para reunir requerimientos para el producto. [4]

Es importante tenerlos en cuenta puesto que ellos mismos se encargan de proveer el conocimiento necesario para realizar un efectivo Proceso de Requerimientos. Según SGPM los stakeholders serían:

S.G.P.M.SRS

Cliente (Miguel Torres): Es la persona encargada de definir los requerimientos necesarios desde el comienzo del proyecto y quien aprueba si se realizó un correcto proceso de Requerimientos e implementación.

Equipo de Desarrollo (SGPM): Grupo encargado de definir como se realizará el ciclo de vida de requerimientos mediante un Proceso de Requerimientos para la obtención de un producto de calidad.

Usuario Final: Es el actor que interactúa con el sistema y puede pertenecer a dos categorías: Administrador o Jugador normal.

2.2 Necesidades del usuario

En cuanto a las necesidades del usuario se asumen las que se propusieron desde el comienzo del semestre, por lo tanto afirmando así que entre estas necesidades se encuentran:

1) La aplicación debe manejar una arquitectura cliente – servidor.

2) La aplicación debe tener uso de persistencia.

3) La aplicación debe utilizar interfaz gráfica de usuario.

4) La aplicación debe correr en las máquinas del Departamento de Ineniería de Sistemas de la Pontificia Universidad Javeriana.

2.3 Participación por roles

Con el fin de generar una mayor eficiencia en el trabajo del grupo con respecto a la elaboración del documento, para lo cual se ha visto la necesidad de generar tareas especificas a los integrantes de acuerdo a sus roles, como se verá a continuación:

S.G.P.M.SRS

2.4 Proceso de requerimientos

Teniendo en cuenta el concepto básico de requerimiento definido como una característica necesaria que debe poseer el sistema que se desea crear, S.G.P.M utilizara un proceso de requerimientos planteado por Karl E. Wiegers [NºReferencia], con el fin de tener un debido manejo y administración de cada uno de los requerimientos que surjan alrededor del proyecto

[NºReferencia] Wiegers, Karl E. More About Software Requirements. Microsoft. 2006

2.4.1 Identificación de Requerimientos

Oscar Gomez (Gerente y Arquitecto)

Sera responsable de seguir un buen proceso en la elaboracion del documento

Andres Fajardo (Administrador de Configuraciones y documentacion )

Estara a cargo de la actualizacion de versiones en documentos y requerimientos

Wilson Perez (Director Programacion)

Sera responsable por el desarrollo de los requerimientos

Andres Hidalgo ( Director Calidad)

Estara a cargo, hacer cumplir los criterios de calidad en requerimientos y documento SRS en general.

S.G.P.M.SRS

La identificación de Requerimientos es el primer paso dentro de nuestro proceso, y para ello S.G.P.M tomara como base las reglas de juego se Scrabble (Ver Sección 10 SPMP) y los casos de uso propuestos (Ver Documento Casos de Uso), como apoyo para la estructuración y elaboración de los requerimientos del proyecto. La identificación de requerimientos también estará marcada por la división en categorías de cada uno de los requerimientos(Ver ilustración Categoria de Requerimientos), el cual se podrá identificar de acuerdo a los dos últimos números que tenga el Id de cada requerimiento como se observa en la siguiente tabla.

Identificación Especificación

R##01 Negocio

R##02 Usuario

R##03 Sistema

R##04 No funcionales

Requerimientos

S.G.P.M.SRS

Requerimientos de negocio: Representan a gran nivel los objetivos de la organización y/o las solicitudes del cliente con respecto al sistema o producto [http://sophia.javeriana.edu.co/~metorres/, Presentación Requerimientos]Requerimientos de Usuario: Describen las tareas de los usuarios que deben poder ser realizadas con el producto [http://sophia.javeriana.edu.co/~metorres/, Presentación Requerimientos]Requerimientos de Sistema: Definen la funcionalidad del software que los desarrolladores deben construir dentro del producto para permitir al usuario realizar sus tareas y satisfacer los Requerimientos del Negocio. [ http://sophia.javeriana.edu.co/~metorres/, Presentación Requerimientos]Requerimientos no Funcionales: Definen los atributos que le indican al sistema como realizar su trabajo (eficiencia, hardware, software, interfaces, usabilidad, etc.). Es el cómo, cuando y cuanto del que. [http://sophia.javeriana.edu.co/~metorres/, Presentación Requerimientos]

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

Requerimientos del producto

Requerimientos no funcional

esRequerimi

entos organizaci

onales

Requerimientos

externos

Requerimientos éticos

Requerimientos de

interoperabilidad

Requerimientos

legislativos

Requerimientos de

seguridad

Requerimientos de

privacidad

Requerimientos de espacio

Requerimientos de

desempeño

Requerimientos de

usabilidad

Requerimientos de eficiencia

Requerimientos de fiabilidad

Requerimientos de

portabilidad

Requerimientos de entrega

Requerimientos de

implementación

Requerimientos de

estándares

S.G.P.M.SRS

Requerimientos del Producto: Este tipo de requerimientos especifican el comportamiento del producto; como los requerimientos de desempeño en la rapidez de ejecución del sistema y cuánta memoria se requiere; los de fiabilidad que fijan la tasa de fallas para que el sistema sea aceptable; los de portabilidad y los de usabilidad. [Tomado de : http://www.mitecnologico.com/Main/EspecificacionesDeRequerimientos]

Requerimientos Organizacionales: Este tipo de requerimientos se derivan de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador: estándares en los procesos que deben utilizarse; requerimientos de implementación como los lenguajes de programación o el método de diseño a utilizar, y los requerimientos de entrega que especifican cuándo se entregará el producto y su documentación. [Tomado de : http://www.mitecnologico.com/Main/EspecificacionesDeRequerimientos]

Requerimientos Externos: Este tipo de requerimientos Se derivan de los factores externos al sistema y de su proceso de desarrollo. Incluyen los requerimientos de interoperabilidad que definen la manera en que el sistema interactúa con los otros sistemas de la organización; los requerimientos legales que deben seguirse para asegurar que el sistema opere dentro de la ley, y los requerimientos éticos. Estos últimos son impuestos al sistema para asegurar que será aceptado por el usuario y por el público en general. [Tomado de : http://www.mitecnologico.com/Main/EspecificacionesDeRequerimientos]

2.4.2 Especificación de Requerimientos

Con base en técnicas de especificación [55] buscaremos la mejor clasificación, búsqueda y un análisis completo de los requerimientos, teniendo como base sus diferentes etapas de ejecución, la trazabilidad y riesgos de estos con base en este documento. En el grafico se mostrara las etapas y su posible funcionalidad.

S.G.P.M.SRS

2.4.3 Priorización de Requerimientos

Se baso en el uso de técnicas cognitivas planteadas por Nadina Martínez en su escrito Gestión de Preferencias de Requerimientos que nos permite tener un enfoque y dar la debida clasificación, prioridad a cada funcionalidad a nuestro sistema para un mejor desarrollo

Inicio de Juego Como Iniciar y finalizar la aplicaciónPosibles opciones de inicios si hay errores

Información ClientesRequerimientos Perfil e información del UsuarioEstadísticas de juegos

Opciones Juego

Requerimientos asociados a la partida(Eliminar, guardar ,crear)Requerimientos utilizados directamente en la acción de opciones del juego antes del inicio de cada partida

Modo JuegoRequerimientos Implementados en la validación de un juego mientras se ejecuta la funcionalidad (mover, poner, coger ,quitar, etc.)

No Funcionales

Requerimientos Relacionados con la velocidad e implantación del sistema(PC).Conexiones de red y formas no esenciales que no afectan al juego

S.G.P.M.SRS

A) Identificación de Requerimientos y Su nivel de Valorización general

Identificación General: Los requerimientos identificados anteriormente deberán ser vueltos a contemplar para poder valorar que tan importante será para su implementación y que aspecto general influirá en el proceso. [53]

Valorización General: Con base en lo anterior después de una breve revisión general daremos prioridad a las exigencias del cliente, siendo estas Persistencia, Arquitectura y GUI, con base es estas tres condiciones daremos importancia a cada requerimiento identificado y descartar los que no serian de una funcionalidad en el sistema. [53]

B) Prioridad según el RolVisión por cada rol: Aquí usaremos el inciso A para que cada miembro del grupo SGPM pueda valorar los requerimientos ya establecidos y su prioridad, pero dando una valoración individual para contrarrestar y clasificar con la ya dada generalmente, teniendo como fundamento dos

Indentificacion

de Requerimientos

y Su nivel de Valoriza

ción general

Nivel de

Prioridad

segun El rol

Priorida

d Fina

l

S.G.P.M.SRS

puntos de valoración y así priorizar tanto individualmente como generalizado, lo cual nos brindara un mejor visión.

C) Prioridad FinalPara esta relación usaremos las variables anteriores para poder implementar la valorización más acertada para cada requerimiento, siendo estos:

Valorización General.

Valorización Rol.

Prioridad final.

Valorización General. Se tendrá en cuenta la discusión de cada requerimiento de un modo neutral.[53]

Punto de vista de cada persona como si fuera cliente. [53]

Discusión con el grupo de los requerimientos más importantes. [53]

Valorización Rol. Tendremos un valor para cada miembro según el requerimiento con una valoración de -5 a 5. [53]

Cada miembro dará un valor clasificatorio. [53]

Prioridad final. En esta clasificación se dará la priorización final de los requerimientos y hará una matriz de conflicto asiendo las

S.G.P.M.SRS

debidas comparaciones. [53] Los resultados serán dados por

Valorización General y final, debido a que es de global a especifico.[53]

La priorización de requerimientos se dará de una clasificación de 1 a 10 siendo el mayor más importante. La formula seria:

Gestión de Preferencias de Requerimientos basada en

Técnicas Cognitivas

Nadina Martínez Carod and Alejandra Cechich.[53]encontrar http://www.cacic2007.unne.edu.ar/papers/035.pdf

http://ing.de.soft1.googlepages.com/07-SeleccionYPriorizacion.pdf[54]

http://readyset.tigris.org/nonav/es/templates/feature-set.html[55]

2.4.4 Trazabilidad

La trazabilidad es un factor clave para la gestión de requerimientos, y se refiere a la posibilidad que se tiene de perseguir o monitorear el ciclo que tiene un

Valorización Rol(Clasificación Negativa o Positiva)

Prioridad Final

S.G.P.M.SRS

requerimiento en el desarrollo del proyecto, estableciendo relaciones entre dos o más procesos de software [17]. Esta trazabilidad se puede realizar de dos formas:

Hacia adelante Hacia atrás

Figura trazabilidad hacia adelante

Figura trazabilidad hacia atrás

Para poder realizar este seguimiento S.G.P.M se ayudara de herramientas como son los casos de uso (ver documento Casos de uso), el modelo de dominio (ver seccion3.5), el SPMP (ver documento SPMP), y los requerimientos asociados que tenga cada uno.

Así mismo S.G.P.M decidió enfocarse a un estilo de trazabilidad vertical que se garantiza que todos los requerimientos que van a ser diseñados e implementados, pasen por un conjunto de pruebas y planes ya establecidos en el SPMP, como el plan de riesgos, plan de control de requerimientos, plan de verificación y validación (ver Documento SPMP)[17] .

Monitoreo de la

implentacion del

requerimeinto

Origen de los requerimiento

s

S.G.P.M.SRS

[17] trazabilidad en proyectos de software Manolo Sangoquiza http://www.slideshare.net/barcampquito/trazabilidad-en-proyectos-de-software

2.4.5 Validación y verificación.

S.G.P.M seguirá el plan de control de requerimientos estipulado en el S.P.M.P (ver documento S.P.M.P). Así mismo se ayudara de las siguientes herramientas:

Usar listas de chequeo ofrecidas por Construx, que permitirá verificar que cada uno de los requerimientos cumpla con una serie de características.

Trazabilidad (ver sección 2.4.4). Plantilla modificada Volere, para la documentación de los requerimientos.

2.5 Administración de requerimientos

2.6 Interfaces

Con el fin de identificar interacciones entre interfaces del sistema (bien sea entre usuarios, hardware, protocolos y distintos software usados) remítase al punto 3 (ver Secciones 3.1 a 3.5).

S.G.P.M.SRS

3 Descripción Global

3.1 Perspectiva del producto

3.1.1 Interfaces con el sistema

WordDomination no tendrá ninguna clase de dependencia con otro sistema externo, ni con otro producto, es una aplicación completamente nueva, por lo cual no reemplazara a otro sistema, así mismo no se crearan interfaces para nuevos componentes.

3.1.2 Interfaces con el usuario

En la siguiente tabla se especifican las diferentes interfaces con el usuario.

INTERFACES

TECLADO Dispositivo utilizado para el ingreso de caracteres por parte del usuario, para la formación de palabras en el juego

RATON Dispositivo utilizado para la interacción de las diferentes interfaces y captura de datos en el juego

MONITOR Dispositivo utilizado para la visualización de la interfaz por parte del usuario. Resolución mínima 800x 600 pixeles

INTERFAZ GUI Se utilizaran los API’S de las bibliotecas graficas SWING, AWT

TARJETA GRAFICA Dispositivo utilizado para la trasmisión de información grafica al monitor. Resolución mínima de 800 x 600 pixeles

TARJETA DE RED Dispositivo utilizado para la conexión entre maquinas(Redes de área local). Velocidad requerida 2 Mbps

S.G.P.M.SRS

3.1.3 Interfaces con el Hardware

Como se había especificado ya por el cliente, los productos de SGPM buscaran la satisfacción y calidad del producto en la parte de hardware, cumpliendo estos con los requerimientos funcionales y no funcionales encontrados. Por motivos de exigencia del cliente la aplicación será de una arquitectura Cliente/Servidor por tal motivo para una mejor interacción y cumplimiento, se deberá usar protocolos de comunicación como los aquí nombrados y escogidos:

S.G.P.M.SRS

2

La eleccion de escoger este protocolo fue por la busqueda de la simplicidad , funcionalidad y estandarizacion que se manejara, algunas causas de nuestra decision La Arquitectura exigida es cliente-servidor, en lo cual es tipo de protocolo hace mas simple su manejo.[1]Su estandarizacion permitara implementacion en diferentes Laptop o PC, para las conexiones exigidas.[1]Brindara para la implementacion seguridad en la entrada y salida de informacion.[1]Wordomination tendra la simplicida de conexiones locales para cuatro Computadores en una conexion local(Host).[1]Dara la opcion de trasmision de datos con la web, si haci se pide implementar en versiones mas completas.[1]

Protocolo 8080 HttpEste protocolo permitira implementar el requerimiento de arquitectura cliente-servidor , este permite la trasmicion de datos como se pide y se ha documentado.[2]Protocolo 3036Este protocolo permitara la comunicacion con la bases de datos(Diccionario de datos) que nos permitara comunicarno para la informacion requeridad por el juego wordomination.[3],[2]Protocolo 31337Dara la posibilidad de acceder y controlar la aplicacion externamente, ya que se basa en el modelo de cliente-servidor para que funcione.[3][2]

La conexion fisica del sistema se dara gracias a la Cableado UTP (Unshielded Twisted Pai), este tipo de conexion nos permitira iteractura LAN Ethernet y fast Ethernet, segun lo necesitado, ya que la velocidad y eficiencia estara dada en el transcurso del desarrollo. Las conexiones tendremo moden,router y demas tecnologia de conexiones que se necesiten.[4],[5]

S.G.P.M.SRS

3.1.4 Interfaces con el Software

La aplicación WordDomination será implementada en java, utilizando diferentes API’S como JFM (Java Media FrameWork) para el manejo de audio y video, SWING para la interfaz grafica con ayuda de JavaFx útil para aplicaciones multimedia.

Aunque el desarrollo de WordDomination y sus diferentes pruebas fueron realizadas en el sistema operativo Windows XP, no debería existir ninguna clase de problema con otras versiones como: Windows Vista o Windows NT, es mas en Linux debe funcionar, siempre y cuando cada uno de estos cuente con una maquina virtual de java (JVM) con una versión mayor a la JDK 1.5 preferiblemente. Para ver en más detalle cada uno de estos componentes se adjunta la siguiente tabla:

Protocolo de Comunicación

TCP/IP

Puerto TCP

S.G.P.M.SRS

Producto de

Software

Propósito de Uso Versión Fuente

Windows Windows es el sistema operativo más usado del mundo, basado y orientado a la interfaz grafica lo cual permitirá una interacción amigable con el usuario

Windows XP

Windows Vista

Windows NT

MicroSoft Windows

www.microsoft.com/spain/windows/

JDK Permitirá la creación , desarrollo y ejecución del la aplicación WordDominatio

A partir de la versión 5.0 Sun MicroSystem

http://java.sun.com/javase

JavaFx Permitirá creación de una Interfaz con una calidad grafica dinámica 2D o 3D

Versión 1.2 SunMicroSystem

http://java.sun.com/javafx/JMF Permitirá la adaptación de tecnologías

de audio y video , para la aplicaciónVersión 2.1.1e SunMicroSystem

http://java.sun.com/javase/technologies/desktop/media/jmf/

Tabla 3: Interfaces con el Software

S.G.P.M.SRS

3.1.5 Interfaces de Comunicación

Debido a que el Wordomination utilizara arquitectura cliente-servidor, por claro habla que utilizar protocolos de red, en este caso TCP/IP, creando bajo este estándar conexiones LAN, para que se la interacción especificada, una restricción para la conexión es que esta debe estar libre de cualquier corta fuegos para así pueda ocurrir la trasferencia de datos y operaciones (ver más. 2.1.3 Interfaces de Hardware).

3.1.6 Restricciones de Memoria

Para la perfecta ejecución de WorDomination, se considero la total necesidad de consumo de memoria por parte del modulo para la implementación del diccionario en español, puesto que para ofrecer un excelente rendimiento por parte de la aplicación en tiempos de respuesta es primordial hacer un alto consumo de memoria. Normalmente un diccionario para WorDomination incluye entre 110.000 a 150.000 palabras, para las cuales se ha calculado una capacidad de memoria de no menos de 150 a 200 Mb de RAM. Por otro lado, también será necesario que los equipos cumplan los siguientes requisitos, para poder correr todos los programas sobre los que WorDomination se aplicara:

Requisitos del Equipo512 MB de RAMDisco Duro de 80 MBProcesador 1.6 GH

Requisitos de SoftwareNetBeans :256 MBSQL Developer: 106 MB

S.G.P.M.SRS

3.1.7 Operaciones

Dentro de WorDomination se encontrara un rol de jugador que podra ingresar al juego de dos modos distintos. Estos modos son el de Administrador y el modo de Usuario. A continuacion se mostrarán las acciones que podran realizar cada uno de estos:

Wordomination no tendra ningun momento de inactividad en el momento de juego, ya que el juego sera ejecutado por los jugadores para iniciar una partida o las demas opciones. S.G.P.M no ofrecera procesos de recuperacion, en caso de que se produzca algun problema en medio de la ejecucion, como la caida del sistema en la que normalmente no se puede recueperar ningun dato que se haya ingresado con anticipacion.

AdministradorCrear PartidasLanzar PartidaCargar partida

UsuariosCrear JugadorBorrar JugadorVer Detalles JugadorAñadir PalabraEliminar PalabraVer puntajeSalvar PartidaCambiar FichasPasar TurnoDeshacer JugadaValidar JugadaColocar Ficha en el tableroQuitar ficha del tableroMover ficha en el tableroSalirVer Log

S.G.P.M.SRS

3.1.8 Requerimientos de Adaptación del Sitio

El funcionamiento de Wordomination, debe contemplar las necesidades que el cliente menciono en el acuerdo del proyecto, dentro de las cuales encontramos el hecho que el producto debe poder ejecutarse en las salas de facultad de ingeniería, en especial la Sala de Bases de Datos [NºREFERENCIA], el cual es el lugar el lugar más idóneo para realizar la presentación final. El lugar debe contar con los componentes estipulados en las interfaces de Software (Ver sección 2.1.4 Interfaces de Software) de este documento, las cuales estarán incluidos dentro de un paquete con su respectivo manual, listo para utilizarse en el momento de la ejecución de Wordomination.

[NºREFERENCIA]Laboratorio de Bases de Datos, consultado: 05 de Septiembre de 2009, Disponible en: http://ingenierias.javeriana.edu.co/portal/page/portal/facultad_ingenieria/espanol/sistemas/laboratorios/TAB839315?tab=laboratorios

3.2 Funciones del Producto

Esta sección hace referencia a las múltiples funcionalidades que contendrá el producto final del juego WorDomination, para una mejor comprensión del juego por parte del cliente, el equipo de S.G.P.M, o cualquier otra persona que lo quiera conocer. Para tener una mayor información acerca de las Funciones Del Producto, remítase al Documento de Casos de Uso.

3.3 Características del Usuario

Los Usuarios de la aplicación podrá ser cualquier persona que tenga un pleno interés en el mundo de WorlDomination, y que además desee una aplicación en la cual pueda jugar diferentes partidas con una variedad de usuarios, ya sea contra la maquina misma (el computador) o en solitario si así el lo desea.

El sistema deberá ser muy intuitivo, de tal forma que permita su uso por cualquier tipo de usuario, es decir, que no solo estará dirigido para personas expertas en el manejo de la computación sino también para aquellos que aun son inexpertos. Para poder lograr esto los desarrolladores de S.G.P.M harán lo

S.G.P.M.SRS

posible por diseñar pantallas que permitan el fácil manejo de la intuición del usuario, y evitara un gran número de opciones sobre las ventanas con el fin de hacer difícil su uso.

Por otro lado, no será necesario que el usuario domine 100% el juego de WorDomination, pues contara con las herramientas básicas para su buen uso y fácil manejo como lo son el uso de manuales y reglas de juego que estarán a su alcance en todo momento.

A continuación se ha definido una estructura que contendrá las características básicas que debe poseer el jugador, para hacer más viable y satisfactorio el uso del juego: [Fowler, M.: “UML Destilled”, segunda edición, Addison Wesley Longman Inc, 2000.]

Actor Nombre del Actor

Descripción Descripción corta de la característica, responsabilidad o rol que tendrá el actor

Comentarios Información relevante que se deba mencionar

Teniendo en cuenta el cuadro anterior, presentaremos las características del usuario para WorDomination.

Actor Jugador

Descripción El usuario debe Saber leer y escribir, tener un vocabulario, entendimiento aceptable, con el fin de poder crear o poner palabras reales en el momento que tenga el turno dentro del juego.

Comentarios El usuario debe tener un nivel de intelecto y entendimiento aceptable, para vencer y no dejarse ganar.

http://ingenierias.javeriana.edu.co/portal/page/portal/facultad_ingenieria/espanol/sistemas/laboratorios/TAB839315?tab=laboratorios

http://ingenierias.javeriana.edu.co/portal/page/portal/facultad_ingenieria/espanol/sistemas/laboratorios/TAB839315?tab=laboratorios

S.G.P.M.SRS

Actor Jugador

Descripción El usuario debe tener conocimientos básicos de computación (Manejo de Sistema operativo Windows XP) y de los accesorios básicos como teclado y mouse.

Comentarios El producto no brinda ayuda en el manejo del Sistema Operativo.

Actor Jugador

Descripción El usuario debe poderse desenvolver en la web, por si necesita buscar alguna palabra de la cual no se sienta seguro respecto a su significado por medio de algún buscador.

Comentarios Ninguno

Actor Jugador

Descripción No es de total relevancia, pero sería de gran ayuda tener cierta experiencia o conocimiento en juegos de mesa.

Comentarios Ninguno

3.4 Restricciones

Es importante que el usuario tenga en cuenta las restricciones con las que el WorDomination será creado, con la finalidad de un perfecto funcionamiento dentro de los requisitos exigidos por el cliente, para ello S.G.P.M ha realizado una lista con las siguientes restricciones:

S.G.P.M.SRS

WorDomination estará regido 100% por las reglas del juego de mesa Scrabble, al cual no se le ha hecho ningún tipo de modificación para mantener su esencia natural ante el usuario.

El juego manejara únicamente el idioma español para su ejecución y desarrollo, manuales y demás documentos.

WorDomination no contara con la característica de ser tolerante a fallos, es decir, que si se llega a presentar una situación en la que el juego se vea afectado de forma total, este no podrá recuperar ningún tipo de dato que haya sido ingresado, jugadas, puntos ganados por los jugadores de tal forma que será necesario iniciar de 0 el juego.

Las especificaciones mínimas de hardware se podrán ver en la sección 2.1.6 Restricciones de memoria y en la sección 3.1.2 Interfaces con el Hardware.

De igual forma se podrán encontrar las especificaciones mínimas de Software en la sección 2.1.6 Restricciones de memoria y en la sección 3.1.3 Interfaces con el Software, en donde encontraremos los IDE’s y los API’s que se manejaran.

Teniendo en cuenta que el sistema se realizara sobre software libre, esto permitirá que el juego se corra sobre cualquier sistema operativo. Sin embargo, tanto el desarrollo como las pruebas que se realicen será sobre el sistema operativo Windows XP.

[NºREFERENCIA]Requisitos del Sistema, Consultado: 05 de Septiembre de 2009, Disponible en: http:// www.navegapolis.net/files/blog/formato_ieee1362.doc

3.5 Modelo del Dominio

Esta sección del documento debe reflejar el análisis inicial realizado al sistema a desarrollar, mediante la presentación del Diagrama del Modelo del Dominio y la documentación asociada.

S.G.P.M.SRS

Antes de especificar como documentar un diagrama del modelo del domino es importante dar las definiciones otorgadas por las organizaciones más importantes para la ingeniería de software, la siguiente tabla muestra dichas definiciones:

Organización / Autor Definición

Construx El modelo del dominio define un grupo de información que debe ser almacenado en el sistema, y las relaciones entre estos

grupos de información. El modelo contiene al menos una lista de objetos

del negocio, entidades de datos o clases (dichos objetos deben tener sus

relaciones). El modelo del domino detallado debe tener también atributos para cada entidad del modelo sea una clase, una entidad de datos o un objeto

del negocio.

Flower 96 Es una representación visual de las clases conceptuales u objetos del mundo real en un dominio de interés [10]. También se les denomina modelos conceptuales.

Larman El modelo del domino podría considerarse como un diccionario visual

de las abstracciones relevantes, vocabulario del dominio e información

del dominio.

Tabla 4: Definiciones del Modelo de Dominio

Finalmente Larman termina con una conclusión muy importante para entender el porqué de un modelo del dominio. “LOS MODELOS DEL DOMINIO NO SON COMPONENTES DE SOFTWARE, el modelo del dominio es una representación de las cosas reales del mundo del dominio de interés” [11].

http://www.navegapolis.net/files/blog/formato_ieee1362.doc

S.G.P.M.SRS

A continuación se presenta una forma para documentar los elementos en el diagrama del modelo del dominio.

ID Elemento del Dominio

Descripción

Atributos

Nombre Descripción Tipo de Dato

Objetivo

Tabla 5: Formato de documentación del Modelo del Dominio

S.G.P.M.SRS

Ilustración 1: Descripción documentación del modelo del dominio

3.6 Suposiciones y Dependencias

Lista de factores que afectan los requerimientos:

Suposiciones:

Se deben listar todas aquellas suposiciones que puedan llegar a afectar los requerimientos indicados en la sección 3. Estos pueden incluir componentes comerciales o de terceras personas que usted planea utilizar. Tenga en cuenta que el proyecto

Identificador único del elemento del dominio del problema.IDIndica el nombre del elemento del dominio del problema que será documentado.Elemento del Dominio

Contiene una breve descripción del elemento, se debe indicar el por qué del creación del mismo dentro del elemento del dominio.DescripciónDe acuerdo a los atributos del elemento escogido se debe tomar cada uno para documentarlos.AtributosNombre del atributo que se documentará.NombreDescripción del objetivo del atributo dentro del elemento.DescripciónDe acuerdo al lenguaje planeado para la implementaicon del sistema, establecer el tipo de dato que se le asignará al elemento.Tipo de DatoDescripción global acerca del elemento documentado con el fin de exponer su funcionalidad en el sistema.Objetivo

S.G.P.M.SRS

podría afectarse si estas suposiciones son incorrectas, no se comparten, o se cambian [1].

Ilustración 2: Suposiciones

Dependencias:

Ilustración 3: Dependencias [1]

Tener una maquina

virtual instalada

Una conexion a

internet

Cumplimiento de

especificacion de Hardware de

la seccion 2.4

Restricciones

Que el cliente no haga cambios

significaticos en los

requerimientos

Previa instalacion y puesta en

funcionamiento de la base de

datos del servidor

Velocidad de la red, para obtener un buen

funcionamiento de la aplicacion en cuanto a tiempos de respuesta

Cambio de alguna de las reglas que riguen la

aplicacion

Factores externos, tales como componentes de software que usted se proponga reutilizar de

otro proyecto

S.G.P.M.SRS

4 Requerimientos Específicos

No. Requerimiento

Número de Identificación de requerimiento. Ver Error: Reference source not found

Versión 1.0 Primera Versión del Requerimiento

Tipo Error: Reference source not found Error: Referencesource not found, Error: Reference source not found

Nombre Nombre único del requerimiento. Visualización global del requerimiento.

Encargado Miembro de S.G.P.M que se encargará de implementar el requerimiento.

Descripción

Especificación detallada de la función del requerimiento dentro del sistema

Objetivo

Criterio de Medición

Es un criterio de aceptación o un caso de prueba.

Excepciones

Condiciones imprevisibles o cuando surgen situaciones en la que debe responder rápidamente. Evento no deseado que coloca al sistema fuera de su flujo normal puede ser causado por factores internos o externos

Observaciones/ Justificación

Razón de ser del requerimiento, utilidad para el sistema o aclaraciones acerca de su funcionamiento

Caso(s) Uso Relacionado

Casos de uso que se relacionan con el requerimiento.

Requerimiento(s)

Asociado(s)

Según el grafo (ver Error:Referencesource notfound Error:Referencesource notfound) son los

S.G.P.M.SRS

requerimientos antecesores y predecesores.

Trazabilidad

Riesgo Se mide según el número de requerimientos, que según el grafo de requerimientos (Error:Referencesource notfound Error:Reference sourcenot found), dependen de la implementación de este, es decir los requerimientos predecesores.

Prioridad Medida dada según las especificaciones expuestas en la Sección Error:Reference sourcenot found Error:Reference sourcenot found.

Costo Se mide en términos de personal y conocimiento necesarios para su implementación. Los rangos que se manejan son los siguientes:

Bajo Medio Alto

Estado

Esfuerzo Tiempo requerido para implementar el requerimiento. Se medirá en (días, meses, años)

Capa Capa de la arquitectura del sistema en la que se puede encontrar el requerimiento

S.G.P.M.SRS

TOKA referenciar

4.1 Requerimientos de Interfaces Externas

Las siguientes secciones se encuentran estrechamente relacionadas con la sección 2.1, la explicación de estas, busca simplemente profundizar un poco más en el contenido que debe tenerse en cuenta en el momento de llenar esta plantilla y definir los requerimientos de Interfaces Externas.

4.1.1 Interfaces con el Usuario

En esta sección se debe explicar la forma en que el sistema o que la aplicación permitirá la comunicación con el usuario o el cliente final. Esta comunicación incluye el ingreso de datos al sistema, la navegación por ventanas, la forma en que se muestran las interfaces (si las hay) y los diferentes dispositivos del computador en el que se va a utilizar el sistema en construcción.

Las interfaces deben contener la información lógica, por ejemplo formatos de pantalla requeridos (1024*768, 800*600,600*400), distribución de elementos en la pantalla o si tiene accesos rápidos con el teclado, por dar algunos ejemplos [12].

Algunas interfaces que se deben tener en cuenta son:

S.G.P.M.SRS

Ilustración 4: Interfaces con el Usurario

4.1.2 Interfaces con el Hardware

Puesto que el sistema que se planea desarrollar usualmente debe estar en capacidad de compartir datos e información con otros computadores y dispositivos (ejemplo dispositivos móviles), es necesario tener en cuenta la forma en que los componentes de software (aplicación o sistema) se comunicaran con los componentes de hardware de los otros dispositivos.

Las características del sistema a nivel de hardware que se deben tener en cuenta para el desarrollo, se enfocan en cómo se va a llevar a cabo la comunicación entre las máquinas de los usuarios participantes, algunas de estas interfaces son:

PANTALLLA TECLADO MOUSE INTERFAZ GUI

TARJETA GRAFICA

TARJETA DE RED

S.G.P.M.SRS

Ilustración 5: Interfaces de Hardware

Inter-conexión

TCP-UDP

PuertosUTP

Red HUB SWITCH

Protocolos de comunicación (TCP, UDP)

Puertos usados para la comunicación (si la aplicación es distribuida)

Cables de conexión (UTP)

Dispositivos de red (Routers, Hubs, Switches)

S.G.P.M.SRS

4.1.3 Interfaces con el Software

Para la ejecución del sistema apropiadamente es necesario tener algunos requerimientos mínimos de Software, esto es versión del sistema operativo, servidores de bases de datos y en general todos los productos de software que permitan la correcta utilización del sistema desarrollado. La Error: Reference source not found muestra un formato que puede usarse para explicar estas interfaces.

Ilustración 6: Interfaces con el Software

4.1.4 Interfaces de Comunicaciones

Las interfaces de comunicación son básicamente los métodos como se interconectan las diferentes aplicaciones en las máquinas en donde se ejecutan (nuevamente si la aplicación es distribuida), estas interfaces incluyen el tipo de red que se debe montar para la conexión de computadores (LAN, WAN) y los protocolos de comunicación usados (TCP). Para apoyar la información escrita en esta sección, se aconseja explicar cierta parte en la sección 3.1.2

4.2 Características del Producto de Software

Para lograr un mayor entendimiento en la especificación de los requerimientos por parte del cliente, S.G.P.M ha distribuido los requerimientos en las siguientes categorías, con el fin de establecer una mejor organización y gestión de estos:

S.G.P.M.SRS

2.2.1 Funcionalidad 1: Jugar

No. Requerimiento

R010303

Versión 1.0

Tipo Funcionales-Modo de juego

Nombre Cantidad de fichas

Encargado Wilson Perez

Descripción El sistema tiene que permitir a los jugadores tener la misma cantidad de fichas,(Ver reglas de WorDomination)

Objetivo Cada jugador pueda iniciar el juego igualitariamente


Al iniciar el juego, el jugador debe poder armar palabras con el número de fichas entregadas.

Excepciones


Ninguna


CU02, CU07

Requerimiento(s)

R020303

R0703

Requerimientos

JuegoAutenticacionAdministracionConsultas

S.G.P.M.SRS

CU12 Asociado(s)

Trazabilidad Modelo de dominio

Documento Casos de uso:

CU02

CU07

CU12

Requerimientos Asociados

Reglas WorDominatio

n

(SPMP Sección 10.1)

Riesgo 2 Prioridad 12

Costo Medio

Estado Aprobado

Esfuerzo 2 días

Capa Servidor

3

No. Requerimiento

R020303

Versión 1.0

S.G.P.M.SRS


Nombre Arrastre de fichas


Descripción El sistema tiene que verificar y mostrar las fichas (letras) que el jugador actual está arrastrando para formar su palabra a todos los demás jugadores.

Objetivo Para que cada jugador se pueda dar cuenta los movimientos de su rival, y los puntajes coincidan con las palabras armadas


Todos los jugadores en su interfaz pueden ver los movimientos(arrastre de fichas) de sus rivales, puntajes se deben modificar.

Excepciones


Ninguna


CU15, CU16

CU18

Requerimiento(s)

Asociado(s)

R080303, R090303, R010303



CU15

CU16

CU18


S.G.P.M.SRS

Reglas WorDominatio

n



Costo Alto

Estado Aprobado

Esfuerzo 20 días

Capa Servidor

45

No. Requerimiento

R030303

Versión 1.0


Nombre Mostrar tiempo


Descripción El sistema mostrara a cada jugador el tiempo máximo que tiene para ingresar la palabra al tablero.(2 minutos, Ver reglas de WorDomination)

Objetivo Para que cada jugador tenga un tiempo establecido, y los rivales no se queden esperando un tiempo indefinido


Después de los 2 minutos, se debe ceder al turno al jugador correspondiente

S.G.P.M.SRS

Excepciones


Ninguna


CU14

CU19

Requerimiento(s)

Asociado(s)

R0103703

R0103403



CU14

CU19


Reglas WorDominatio

n



Costo MEDIO

Estado Aprobado

Esfuerzo 3 días

Capa Servidor

S.G.P.M.SRS

67

No. Requerimiento

R0403

Versión 1.0


Nombre Añadir Palabra


Descripción El sistema deberá permitir al jugador añadir una palabra si la tiene lista antes de que se cumpla el límite de tiempo (2 minutos), esto se hará mediante un botón en la pantalla del jugador.

Objetivo Para que cada jugador tenga la posibilidad realizar su jugada en el tablero


En el tablero el jugador podrá formar sus palabras durante dos minutos, contabilizándole su puntaje

Excepciones


Si no se realiza la jugada, pierde turno


CU15

CU16

CU18

Requerimiento(s)

Asociado(s)

R0203, R0803, R0903, R1703



S.G.P.M.SRS

CU15

CU16

CU18


Reglas WorDominatio

n



Costo ALTO

Estado Aprobado

Esfuerzo 12 días

Capa Servidor

89

No. Requerimiento

R0503

Versión 1.0


S.G.P.M.SRS

Nombre Eliminar Palabra


Descripción El sistema debe permitir eliminar la última palabra creada por el jugador

Objetivo Para que cada jugador tenga la posibilidad de reversar una mala jugada realizada durante la partida


El sistema debe quitar del tablero la última palabra ingresada si el jugador así lo desea

Excepciones



CU13

CU16

Requerimiento(s)

Asociado(s)

R1403

R0203



CU13

CU16


Reglas WorDominatio

n

(SPMP Sección

S.G.P.M.SRS

10.1)


Costo ALTO

Estado Aprobado

Esfuerzo 12 días

Capa Servidor

1011121314

No. Requerimiento

R0603

Versión 1.0


Nombre Utilizar comodin


Descripción El sistema debe permitir usar correctamente el comodín o fichas en blanco, las cuales se pueden utilizar en sustitución de cualquier letra.

Objetivo Para que cada jugador tenga la posibilidad de formar sus palabras con diferentes opciones

S.G.P.M.SRS


El sistema debe validar la palabra incluidos los comodines y fichas en blanco y sumarlo al puntaje

Excepciones


Los comodines son de un número limitado (ver reglas WorDomination)


CU18

CU16

Requerimiento(s)

Asociado(s)

R0203



CU18

CU16


Reglas WorDominatio

n



Costo BAJO

S.G.P.M.SRS

Estado Aprobado

Esfuerzo 2 días

Capa Servidor

151617

No. Requerimiento

R0703

Versión 1.0


Nombre Utilizar comodín

Encargado Wilson Pérez

Descripción El sistema debe darle 7 fichas (letras) de forma aleatoria a cada jugador al iniciar la partida.

Objetivo Para que cada jugador pueda iniciar el juego, con igualdad de condiciones


A iniciar el juego cada jugador debe tener 7 fichas

Excepciones


Puede que ha determinado jugador al inicio con sus fichas pueda armar más fácil una palabra.


CU02 Requerimiento(s)

Asociado(s)

R0103

R1303

Trazabilidad Modelo de

S.G.P.M.SRS

dominio


CU02


Reglas WorDominatio

n



Costo BAJO

Estado Aprobado

Esfuerzo 2 días

Capa Servidor

181920

No. R0803

S.G.P.M.SRS

Requerimiento

Versión 1.0


Nombre Acomodar Fichas


Descripción El sistema debe permitir acomodar las fichas de forma vertical u horizontal para formar las palabras según le convenga al jugador, (Ver reglas de WorDomination).

Objetivo Para que cada jugador pueda armar sus respectivas palabras en el tablero


El jugador debe poder formar sus palabras en el tablero, tanto en sentido vertical como horizontal

Excepciones


Las casillas donde se ponen las fichas deben ser validas(estar desocupadas)


CU16

CU18

CU15

Requerimiento(s)

Asociado(s)

R0203

R0903

R0403

R1903



CU16

CU18

CU15

S.G.P.M.SRS


Reglas WorDominatio

n



Costo MEDIO

Estado Aprobado

Esfuerzo 4 días

Capa Servidor

212223

No. Requerimiento

R0903

Versión 1.0


Nombre Formar palabras Contiguas


S.G.P.M.SRS

Descripción El sistema debe permitir formar palabras completas si las fichas puestas de forma horizontal o vertical quedan en contacto con filas o columnas contiguas.

Objetivo Para que cada jugador pueda formar sus palabras completas y validar su jugada


El sistema validara las palabras completas ingresadas por el usuario

Excepciones


Las casillas donde se ponen las fichas deben ser validas(estar desocupadas)


CU16

CU18

CU15

Requerimiento(s)

Asociado(s)

R0203

R0803

R0403

R1903



CU16

CU18

CU15


Reglas WorDominatio

n

(SPMP Sección

S.G.P.M.SRS

10.1)


Costo ALTO

Estado Aprobado

Esfuerzo 10 días

Capa Servidor

2425

No. Requerimiento

R1003

Versión 1.0


Nombre Color casillas


Descripción El sistema debe tener en cuenta el color de cada casilla del tablero al momento de asignar la puntuación a un jugador, pues de acuerdo al color se puede dar un premio por letra o por palabra (Ver reglas de WorDomination)

Objetivo Para que cada jugador tenga la posibilidad de aumentar su puntaje dependiendo del color en el que forme sus palabras


El puntaje de cada jugador se modificara dependiendo del color donde forme la palabras

Excepciones

S.G.P.M.SRS



CU16

CU18

CU15

CU06

Requerimiento(s)

Asociado(s)

R0803

R0903

R1103



CU16

CU18

CU15

CU06


Reglas WorDominatio

n



Costo ALTO

S.G.P.M.SRS

Estado Aprobado

Esfuerzo 10 días

Capa Servidor

26272829

No. Requerimiento

R1103

Versión 1.0


Nombre Calcular puntaje


Descripción El sistema tiene que calcular el puntaje sumando el valor de las fichas utilizadas en las palabras que se hayan formado en ese turno, más los puntos obtenidos por haber puesto una o más fichas en casillas con premio.

Objetivo Para que el puntaje de cada jugador se vaya modificando dependiendo de las jugadas realizadas


El sistema debe actualizar y mostrar el puntaje de cada jugador dependiendo de las palabras formadas en cada turno

Excepciones



CU15 Requerimiento(s R1003

S.G.P.M.SRS

CU06 )

Asociado(s)

R1203

R1303



CU15

CU06


Reglas WorDominatio

n



Costo ALTO

Estado Aprobado

Esfuerzo 10 días

Capa Servidor

3031

S.G.P.M.SRS

32

No. Requerimiento

R1203

Versión 1.0


Nombre Ver Puntaje


Descripción El sistema debe permitir al jugador ver su puntaje durante la ejecución de cada partida

Objetivo Para que jugador tenga información de su puntaje durante el desarrollo de la partida


El sistema debe actualizar y mostrar el puntaje en la pantalla de cada jugador, cada vez que se realice una jugada

Excepciones



CU06

CU03

Requerimiento(s)

Asociado(s)

R1303

R1103



CU06

CU03

Requerimiento

S.G.P.M.SRS

s Asociados

Reglas WorDominatio

n



Costo MEDIO

Estado Aprobado

Esfuerzo 4 días

Capa Servidor

3334

No. Requerimiento

R1303

Versión 1.0


Nombre Otorgar Puntos


Descripción El sistema otorgara la mayor cantidad de puntos (50 puntos), cuando el jugador haga uso de todas las 7 fichas para formar su palabra.

S.G.P.M.SRS

Objetivo Para que jugador tenga la posibilidad de aumentar su puntaje, pero con un mayor grado de dificultad


El puntaje del jugador se modificara, cuando se usen las siete fichas en el tablero

Excepciones



CU06

CU15

CU16

Requerimiento(s)

Asociado(s)

R1203

R1103



CU06

CU15

CU16


Reglas WorDominatio

n


S.G.P.M.SRS


Costo MEDIO

Estado Aprobado

Esfuerzo 4 días

Capa Servidor

3536No. Requerimiento

R1403

Versión 1.0


Nombre Cambiar Fichas de Jugador

Encargado Andrés Fajardo

Descripción El sistema debe permitir al usuario cambiar las fichas que el desee durante el tiempo de su turno (2 minutos) , máximo 3 veces por turno.

Objetivo Para que jugador tenga la posibilidad de cambiar sus fichas (máximo 3 veces por turno).


Las fichas del jugador se cambiarán aleatoriamente durante su turno si este mismo lo pide, máximo cambiaran máximo 3 veces por turno.

Excepciones Las fichas escogidas por el jugador no se pudieron cambiar satisfactoriamente.

S.G.P.M.SRS




Asociado(s)

R1403

R1503



CU12


Reglas WorDomination



Costo MEDIO

Estado Aprobado

Esfuerzo 4 días

Capa Servidor

S.G.P.M.SRS


R1503

Versión 1.0


Nombre Cambiar fichas transaccionalmente.


Descripción Durante el momento de cambio de fichas, el jugador no podrá desistir de realizar esta acción, lo cual lo obliga a terminarla.

Objetivo Para asegurar que se realice el cambio de fichas por jugador correctamente.


Una vez dada la orden de cambio de fichas, el procedimiento terminará completamente y correctamente.

Excepciones




Asociado(s)

R1403

R1703

R2103



CU12

S.G.P.M.SRS





Costo MEDIO

Estado Aprobado

Esfuerzo 4 días

Capa Servidor


R1603

Versión 1.0


Nombre Pasar a siguiente turno.


S.G.P.M.SRS

Descripción El sistema debe permitir pasar al turno siguiente, si el jugador en turno lo desea.

Objetivo Para asegurar que se pueda cambiar de turno, bien sea por no tener opciones disponibles o por que el jugador no sabe qué palabra ubicar en el tablero, así el tiempo límite no se haya cumplido.


Una vez oprimido el botón de cambio de turno, el sistema cambia de turno satisfactoriamente.

Excepciones




Asociado(s)

R1103

R1703



CU14




S.G.P.M.SRS


Costo MEDIO

Estado Aprobado

Esfuerzo 4 días

Capa Servidor


R1703

Versión 1.0


Nombre Pasar a siguiente turno cuando tiempo límite se haya concluido.


Descripción El sistema deberá pasar al siguiente turno si el tiempo de la jugada llega a su límite (2 minutos, Ver reglas de WorDomination).

Objetivo Asegurar que cumplidos dos minutos, se realice un cambio automático de turno.


Pasados 2 minutos, se cambia el turno del jugador satisfactoriamente.

Excepciones


S.G.P.M.SRS



Asociado(s)

R1103

R1603



CU14





Costo MEDIO

Estado Aprobado

Esfuerzo 4 días

Capa Servidor

43

S.G.P.M.SRS

44No. Requerimiento

R1803

Versión 1.0


Nombre Mostrar Fichas.


Descripción El sistema debe mostrar en todo momento a los jugadores las fichas que quedan por jugar.

Objetivo Asegurar que el sistema muestre correctamente las fichas correspondientes a cada jugador por cada turno.


Las fichas se muestran en la pantalla y el jugador puede usarlas para jugar posteriormente.

Excepciones



CU11, CU12

CU16, CU17

CU18

Requerimiento(s)

Asociado(s)

R0103, R0203, R0603, R0703, R0803, R1403



CU11

S.G.P.M.SRS

CU12

CU16

CU17

CU18





Costo MEDIO

Estado Aprobado

Esfuerzo 4 días

Capa Servidor


R1903

Versión 1.0

S.G.P.M.SRS


Nombre Validar jugadas.


Descripción El sistema debe validar las jugadas realizando una comparación de la palabra formada por el usuario con ayuda de un diccionario de palabras totalmente implementado dentro del sistema en una base de datos.

Objetivo Comprobar si el jugador obtuvo una respuesta correcta o no.


Si el usuario tiene una respuesta correcta, se le informa en un mensaje diciéndole su correspondiente puntaje y continúa el siguiente turno.

Excepciones



CU04, CU06, CU14, CU15

Requerimiento(s)

Asociado(s)

R0103, R0303, R0403, R0703, R0803, R0903, R1003, R1103, R1203, R1303



CU04, CU06, CU14, CU15

Requerimiento

S.G.P.M.SRS

s Asociados




Costo MEDIO

Estado Aprobado

Esfuerzo 4 días

Capa Servidor


R2003

Versión 1.0


Nombre Finalizar partida si ningún jugador ubicó palabras.


Descripción El sistema terminara la partida cuando ningún jugador pueda colocar mas fichas en el tablero bien sea por límite de tiempo o por palabras no válidas o incorrectas.

S.G.P.M.SRS

Objetivo Evitar más de dos turnos sin jugadas correctas.


Si ninguno de los dos jugadores ubicó palabras en sus dos turnos consecutivos respectivos, el sistema finaliza correctamente y notifica puntajes y ganador.

Excepciones



CU04, CU05,

CU14, CU15

Requerimiento(s)

Asociado(s)

R0103, R0303, R0403, R0703, R0803, R0903, R1003, R1103, R1203, R1303, R1603, R1703, R1903



CU04, CU05, CU14, CU15




S.G.P.M.SRS


Costo MEDIO

Estado Aprobado

Esfuerzo 4 días

Capa Servidor


R2103

Versión 1.0


Nombre Habilitar límite de tiempo en partida.


Descripción El sistema debe tener un límite de tiempo.

Objetivo Evitar partidas sin fin alguno, ni ganadores.


La partida debe tener un tiempo límite (una hora).

Excepciones


S.G.P.M.SRS


CU06

CU08

CU19

Requerimiento(s)

Asociado(s)

R2203



R2203





Costo MEDIO

Estado Aprobado

Esfuerzo 3 días

Capa Servidor

S.G.P.M.SRS


R2203

Versión 1.0


Nombre Finalizar sistema por límite de tiempo.


Descripción El sistema debe terminar en caso que se termine el tiempo límite de tiempo.

Objetivo Evitar partidas sin fin alguno, ni ganadores.


La aplicación se finalizará cuando termine el tiempo límite, indicando antes de finalizar, quien fue el ganador de la partida.

Excepciones



CU06, CU08

CU19

Requerimiento(s)

Asociado(s)

R2103



R2203

Requerimiento

S.G.P.M.SRS

s Asociados




Costo MEDIO

Estado Aprobado

Esfuerzo 3 días

Capa Servidor


R2303

Versión 1.0


Nombre Informar Ganador


Descripción El sistema debe informar a todos los jugadores quien es el ganador de la partida.

S.G.P.M.SRS

Objetivo Informar a los jugadores quien fue el ganador.


Si la aplicación termina por cualquier motivo posible (fin del tiempo, dos jugadores no pudieron ubicar más fichas o se les terminó el tiempo), el sistema informa quien ha sido el ganador.

Excepciones




Asociado(s)

R0303, R1703, R1903, R2003, R2103, R2203




R0303, R1703,

R1903, R2003,

R2103, R2203




Costo MEDIO

S.G.P.M.SRS

Estado Aprobado

Esfuerzo 3 días

Capa Servidor

57.2.1 Funcionalidad 2: Registro y Autenticación

No. Requerimiento

R240202

Versión 1.0

Tipo Funcionales-Modo de Autenticación

Nombre Crear perfil de jugador


Descripción El sistema debe permitir al jugador crear o registrar su perfil al ingresar al juego.

Objetivo Permitir al jugador crear su perfil al ingresar al juego para posteriormente poder utilizar el mismo en partidas, seleccionándolo al inicio de la aplicación.


Excepciones


Caso(s) Uso CU01, Requerimiento(s R2502

S.G.P.M.SRS

Relacionado CU07, CU08, CU09,

CU10

)

Asociado(s)

R2603




R2502

R2603




Costo MEDIO

Estado Aprobado

Esfuerzo 5 días

Capa Servidor

S.G.P.M.SRS

5859

No. Requerimiento

R2502

Versión 1.0


Nombre Crear tipo de usuario de jugador


Descripción El sistema debe permitir al usuario escoger el tipo de jugador que desee (Administrador, Jugador normal)

Objetivo Permitir al jugador crear el tipo de jugador que desea para operar sus características asociadas.


Excepciones



CU01

CU07

CU08

Requerimiento(s)

Asociado(s)

R2402

R2603



S.G.P.M.SRS


R2502

R2603




Costo MEDIO

Estado Aprobado

Esfuerzo 3 días

Capa Servidor

6061

No. Requerimiento

R2603

Versión 1.0


Nombre Almacenar información de archivos de texto de cada jugador.


Descripción El sistema debe permitir almacenar la información en archivos de

S.G.P.M.SRS

texto de cada jugador registrado (Nombre Completo, Nickname, contraseña).

Objetivo Permitir la persistencia mediante almacenamiento de la información de características de partidas de cada jugador.


Excepciones



CU01, CU03, CU07, CU08

Requerimiento(s)

Asociado(s)

R2402

R2502




R2402

R2502



S.G.P.M.SRS


Costo MEDIO

Estado Aprobado

Esfuerzo 3 días

Capa Servidor

626364

No. Requerimiento

R2703

Versión 1.0


Nombre Validar Información Ingresada

Encargado Oscar Gómez Herrera

Descripción El sistema debe validar la información ingresada por cada uno de los jugadores(NombreCompleto de 20 a 30 caracteres, Nickname 5 a 10 caracteres, contraseña de 6 a 15 caracteres)

Objetivo Se cumplirá que los datos ingresados en el requerimiento 26 se han ciertos a y acorde con lo establecido.


El jugador deberá ingresar los criterios de información básicos para poder acceder al juego

Excepciones Datos Inválidos, Intente de nuevo


Ninguna

S.G.P.M.SRS


CU01

CU02

Requerimiento(s)

Asociado(s)

R2603



CU01

CU02


R2603

Reglas Wordominatio

n



Costo Medio

Estado Aprobado

Esfuerzo 15 días

Capa Servidor

65No. R2803

S.G.P.M.SRS

Requerimiento

Versión 1.0


Nombre Verificar Acciones Redundantes


Descripción EL sistema debe validar cualquier tipo de información que un jugador vaya a ingresar en la aplicación con el fin de evitar redundancia

Objetivo Evitar las posibles repeticiones de información en el sistema


Se dará información y advertirá de que la información a ingresar ya se encuentra

Excepciones


Ninguna


CU01

CU02

CU07

Requerimiento(s)

Asociado(s)

R2502

R2603



CU01

CU02

CU07

Requerimiento

S.G.P.M.SRS

s Asociados

R2502

R2603

Reglas WorDominatio

n



Costo Medio

Estado Aprobado

Esfuerzo 15 dias

Capa Servidor

66No. Requerimiento

R2903

Versión 1.0


Nombre Confirmación Jugador Creado


Descripción El sistema dará una confirmación de la creación de un jugador al usuario.

S.G.P.M.SRS

Objetivo Permitirá al sistema informar al usuario de la creación exitosa o no de la acción crear jugador


El jugador estará informado si su perfil pudo ser creado, para poder jugar.

Excepciones


Es obligatorio tener un usuario para poder acceder a una partida del juego



Asociado(s)

R2402, R2502, R2603, R2703



CU01


R2402

R2502

R2603

R2703

Reglas WorDominatio

n


S.G.P.M.SRS


Costo Alto

Estado Aprobado

Esfuerzo 22 dias

67No. Requerimiento

R3002

Versión 1.0


Nombre Eliminar Registro Creado


Descripción El sistema debe permitir al usuario eliminar el registro creado.

Objetivo Permitirá borrar la información seleccionada del registro creado por parte del usuario


El jugador recibirá la confirmación del éxito o no de la acción por medio de un mensaje visual

Excepciones


Para eliminar el registro deberá existir


CU02

CU03

Requerimiento(s)

Asociado(s)

R2402, R2502, R2603,

R2703


Documento

S.G.P.M.SRS

Casos de uso: CU01


R2402

R2502

R2603

R2703

Reglas WorDominatio

n



Costo Medio

Estado Aprobado

Esfuerzo 25 dias

Capa Servidor

68No. Requerimiento

R3102

Versión 1.0


Nombre Ver Perfil

S.G.P.M.SRS


Descripción El jugador podrá observar su perfil en el momento que lo desee.

Objetivo Permitirá dar información del usuario cuando este lo solicite


El Jugador deberá poder ser informado del perfil pedido

Excepciones Al no existir el perfil, dará mensaje visual de no valido


El jugador deberá existir para poder ver la información del perfil



Asociado(s)

R2603



CU03


R2603

Reglas WorDominatio

n



Costo Medio

S.G.P.M.SRS

Estado Aprobado

Esfuerzo 14 dias

Capa Servidor

6970

No. Requerimiento

R3203

Versión 1.0


Nombre Eliminar Archivos


Descripción El sistema debe eliminar todos los datos de los archivos de persistencia.

Objetivo Permitirá borrar los archivos relacionados con el juego(Persistencia)


Se tendrá la opción de eliminar todos los archivos creados por medio de la aplicación como opción adicional.

Excepciones


Permitirá una mejor eficiencia de los recursos de hardware


CU07

CU08

Requerimiento(s)

Asociado(s)


S.G.P.M.SRS


CU07

CU08


Reglas WorDominatio

n



Costo Bajo

Estado Aprobado

Esfuerzo 2 dias

Capa Servidor

717273

No. Requerimiento

R3302

Versión 1.0

Tipo Funcionales-Modo de

S.G.P.M.SRS

Autenticación

Nombre Terminar Partida


Descripción El sistema debe permitir terminar la partida a los jugadores y al administrador en el momento en el que lo deseen.

Objetivo Permitirá al sistema acabar en cualquier momento el juego o partida deseados


El jugador tendrá la opción de seguir o no en el juego

Excepciones


El usuario dará finalizar cuando se quiera salir de una partida.



Asociado(s)

R3402



CU08


R3402

Reglas WorDominatio

n

S.G.P.M.SRS



Costo Medio

Estado Aprobado

Esfuerzo 5 días

Capa Servidor

7475

No. Requerimiento

R3402

Versión 1.0


Nombre Guarda Partida


Descripción El sistema debe permitir salvar (guardar) una partida si un usuario requiere.

Objetivo Permitir retomar un juego después de terminado o aplazado


El usuario podrá guardar su partida sino quiere seguirla en el tiempo dado

Excepciones


Dar la opción de jugar en otro momento la misma partida


CU07

CU08

S.G.P.M.SRS



CU07

CU08


Reglas WorDominatio

n


Riesgo 4

Costo Bajo

Estado Aprobado

Esfuerzo 15 días

Capa Servidor

7677

No. Requerimiento

R3503

Versión 1.0


Nombre Terminar Partida(Desconexion)


S.G.P.M.SRS

Descripción El sistema terminara la partida en el momento que un jugador se desconecte del juego.

Objetivo El sistema se desconectara cuando no tenga conexión con el servidor


El sistemas dará como terminado cualquier jugo al no haber conexión

Excepciones


Al no haber conexión el sistema se perderá la información de la partida(Si no se guardo)


Requerimiento(s)

Asociado(s)




Reglas WorDominatio

n



Costo Alto

S.G.P.M.SRS

Estado Aprobado

Esfuerzo 8 días

Capa Servidor

77.2.1 Funcionalidad 3: Administración78

No. Requerimiento

R3602

Versión 1.0

Tipo Funcionales- Modo Administración

Nombre Eliminar Jugador


Descripción El sistema debe permitir al administrador eliminar un jugador, esperando una confirmación de fracaso o éxito de la solicitud.

Objetivo Eliminar un jugador cuando se exija


El administrador tendrá la opción de eliminar cualquier jugador por conducta indebida

Excepciones


El jugador será sacado de la partidas y eliminado su perfil.


CU02

CU03

Requerimiento(s)

Asociado(s)


S.G.P.M.SRS


CU07

CU08


Reglas WorDominatio

n



Costo Bajo

Estado Aprobado

Esfuerzo 2 dias

Capa Servidor

79

No. Requerimiento

R3702

Versión 1.0

Tipo Funcionales- Modo Administración

Nombre Eliminar Archivos(Administrador)

S.G.P.M.SRS


Descripción El sistema debe eliminar de los archivos de persistencia al jugador que el administrador desee eliminar.

Objetivo El administrador puede eliminar cualquier tipo de archivo


Se podrá eliminar el archivo de un jugador especifico o varios de varios jugadores

Excepciones


Mejorara la eficiencia del juego, para poder eliminar archivos antiguos y no usados


CU02

CU05

Requerimiento(s)

Asociado(s)

R3002



CU02

CU05


R3002

Reglas WorDominatio

n



S.G.P.M.SRS

Costo Alto

Estado Aprobado

Esfuerzo 15 días

Capa Servidor

79.2.1 Funcionalidad 4: Consultas

No. Requerimiento

R3802

Versión 1.0

Tipo Funcionales-Modo de Consulta

Nombre Consultar Estadísticas Usuario


Descripción El sistema permitirá a un usuario que tenga un perfil creado en el juego consultar sus estadísticas dentro del juego.

Objetivo Cumplirá con informar al usuario sobre su desempeño en el juego


El jugador deberá indicar su ID para poder mostrar su informacion

Excepciones ID invalido


Mostrar información de cada jugador


CU03

CU06

Requerimiento(s)

Asociado(s)

R3902


S.G.P.M.SRS


CU03

CU06


R3902

Reglas Wordominatio

n



Costo Medio

Estado Aprobado

Esfuerzo 12 días

Capa Servidor

80818283

No. Requerimiento

R3902

Versión 1.0

Tipo Funcionales-Modo de

S.G.P.M.SRS

Consulta

Nombre Información Perfil(Restricciones)


Descripción El sistema solo permitirá consultar las estadísticas propias de cada jugador que las solicite.

Objetivo Cumplir con la privacidad de información para cada jugador


El jugador solicitante deberá ingresar la información básica para obtener la información(Nombre y Contraseña)

Excepciones Datos Inválidos, Intente de nuevo


Después de 3 errores en la validación de datos el juego se sale.


CU03

CU06

Requerimiento(s)

Asociado(s)

R2603

R2703



CU03

CU06


R2603

R2703

Reglas Wordominatio

n


S.G.P.M.SRS


Costo Medio

Estado Aprobado

Esfuerzo 19 días

Capa Servidor

84

No. Requerimiento

R4002

Versión 1.0


Nombre Consulta Perfil de jugadores

Encargado Andrés Hidalgo

Descripción El sistema debe permitir ver perfil y estadísticas de los demás jugadores.

Objetivo Permite al usuario ver el desempeño de los demás jugadores en la ejecución de la aplicación.


En el momento de realizar esta consulta, deberá mostrar la información correspondiente a las estadísticas de los demás jugadores.

Excepciones


Ninguna


CU03

CU06

CU20

Requerimiento(s)

Asociado(s)

R1003, R3102, R3802

R3902

S.G.P.M.SRS


Documento Casos de uso: CU03, CU06,

CU20


R1003, R3102, R3802

R3902

Reglas Wordominatio

n



Costo Medio

Estado Aprobado

Esfuerzo 2 días

Capa Servidor

858687

No. R4102

S.G.P.M.SRS

Requerimiento

Versión 1.0

Tipo Consulta

Nombre Consulta de Reglas y manuales


Descripción El sistema permitirá al jugador consultar las reglas del juego y el manual de usuario en el momento que lo desee.

Objetivo El jugador podrá consultar tanto manuales como reglas para la resolución de dudas que surjan durante la ejecución del juego


Durante toda la ejecución del juego, debe mostrar un botón de ayuda para los jugadores, el cual al ejecutarlo deberá mostrar la información requerida.

Excepciones


Ninguna



Asociado(s)

R5004



CU21


R5004

S.G.P.M.SRS

Reglas Wordominatio

n



Costo Medio

Estado Aprobado

Esfuerzo 2 dias

Capa Servidor

88899091

No. Requerimiento

R4202

Versión 1.0


Nombre Consulta Numero de fichas en juego


Descripción El sistema debe permitir al jugador consultar el número de fichas que faltan por jugar.

Objetivo Conociendo el numero de fichas que faltan por jugar, el usuario sabrá el estado de juego (esta en el inicio, en el medio o finalizando)


EL juego debe mostrar durante todo el juego las fichas que van quedando después de haber colocado una nueva palabra en el

S.G.P.M.SRS

tablero hasta el final del juego.

Excepciones


Ninguna


CU16

CU17

Requerimiento(s)

Asociado(s)

R0203

R0703



CU16, CU17


R0203, R0703

Reglas Wordominatio

n



Costo Medio

Estado Aprobado

Esfuerzo 2 días

Capa Servidor

S.G.P.M.SRS

4.3 Requerimientos de Desempeño

No. Requerimiento

R4303

Versión 1.0

Tipo Dinámicos y Estáticos

Nombre Jugadores en línea


Descripción El sistema soportara 4 posibles jugadores conectados al mismo tiempo, es decir, de forma simultanea

Objetivo Aclarar el máximo de usuarios que pueden estar conectados a la espera de una partida


Usuarios conectados de forma simultanea

Excepciones


Ninguna


CU09

CU10

Requerimiento(s)

Asociado(s)

R4403

R4601



S.G.P.M.SRS

CU09, CU10


R4403, R4601

Reglas Wordominatio

n



Costo Alto

Estado Aprobado

Esfuerzo 2 días

Capa Servidor

No. Requerimiento

R4403

Versión 1.0

Tipo Dinámicos y

S.G.P.M.SRS

Estáticos

Nombre Jugadores en la partida


Descripción La creación de la partida debe tener por lo menos 2 jugadores y 4 como máximo.

Objetivo Cuando el jugador administrador desee iniciar una partida deberá tener mínimo 2 jugadores, de lo contrario el juego restringirá el inicio de la partida


El juego permitirá la ejecución de las partidas de juego solo en el momento que este el mínimo de jugadores para jugar.

Excepciones


Ninguna


CU09

CU10

Requerimiento(s)

Asociado(s)

R4403

R4601



CU09, CU10


R4403, R4601

Reglas

S.G.P.M.SRS

Wordomination



Costo Alto

Estado Aprobado

Esfuerzo 2 días

Capa Servidor

No. Requerimiento

R4503

Versión 1.0

Tipo Dinámicos y Estáticos

Nombre Respuesta inmediata


Descripción El sistema debe realizar respuestas en tiempo real, que no intervengan o influyan en el flujo del juego

Objetivo Mostrar la eficiencia del juego con respecto al manejo de los tiempos.

S.G.P.M.SRS


Se espera que el juego reaccione de manera inmediata ante cualquier acción que realicen los jugadores en la aplicación

Excepciones


Latencia del juego


Requerimiento(s)

Asociado(s)



Costo Medio

Estado Aprobado

Esfuerzo 1 días

Capa Servidor

4.4 Restricciones De Diseño

No. Requerimiento

R4601

Versión 1.0

Tipo Restricciones de

S.G.P.M.SRS

Funcionalidad

Nombre Comunicación


Descripción El sistema debe comunicarse por medio de una arquitectura Cliente-Servidor.

Objetivo Hace parte de las restricciones estipuladas por el cliente en el acuerdo del proyecto


En el momento que un computador este dando repuestas a los demás durante el juego, se dará por exitosa la comunicacion

Excepciones


Ninguna


Requerimiento(s)

Asociado(s)

R4601



R4601

Reglas Wordominatio

n



S.G.P.M.SRS

Costo Medio

Estado Aprobado

Esfuerzo 2 dias

Capa Servidor

No. Requerimiento

R4701

Versión 1.0

Tipo Restricciones de Funcionalidad

Nombre Diseño O.O


Descripción El diseño y creación de la aplicación debe ser orientado a objetos.

Objetivo Aplicación del Plan de Procesos Técnicos (Ver Sección 6 del SPMP)


Utilizando lenguaje orientado a objetos (JAVA), en el desarrollo del producto.

Excepciones


Ninguna


Requerimiento(s)

Asociado(s)

S.G.P.M.SRS


Reglas Wordominatio

n



Costo Medio

Estado Aprobado

Esfuerzo 2 días

Capa Servidor

No. Requerimiento

R4801

Versión 1.0


Nombre Diseño acorde al modelo de dominio


Descripción El diseño se realizara de acuerdo al modelo de dominio.

Objetivo Poder aplicar de forma eficiente todo lo que el grupo ha diseñado para el desarrollo del juego.

Criterio de La aplicación deberá estar acorde al modelo de dominio diseñado

S.G.P.M.SRS

Medición

Excepciones


Ninguna


Requerimiento(s)

Asociado(s)


Reglas Wordominatio

n



Costo Medio

Estado Aprobado

Esfuerzo 2 días

Capa Servidor

No. Requerimiento

R4901

S.G.P.M.SRS

Versión 1.0


Nombre Funcionamiento en el Sistema Operativo


Descripción La aplicación debe ejecutarse en la plataforma de Windows XP

Objetivo Esto permitirá ejecutar la aplicación en un sistema operativo conocido por el usuario, lo cual permitirá un uso más fácil y eficiente


El Juego debe estar en la capacidad de ejecutarse de forma correcta en este sistema operativo.

Excepciones


Ninguna


Requerimiento(s)

Asociado(s)

Trazabilidad SPMP Casos de Uso


Costo Medio

Estado Aprobado

Esfuerzo 2 días

Capa Servidor

S.G.P.M.SRS

No. Requerimiento

R5004

S.G.P.M.SRS

Versión 1.0


Nombre Consulta de Reglas y manuales


Descripción La aplicación debe poseer manuales de instalación para los programas que necesita en su ejecución

Objetivo Permitir mayor interacción del juego con el usuario.


Un claro y fácil entendimiento por parte del usuario de los manuales de instalación, descartara cualquier tipo de ambigüedad en su manejo.

Excepciones


Ninguna


CU02

CU07

CU12

Requerimiento(s)

Asociado(s)

R4102

R5104

Trazabilidad SPMP: Reglas de juego


Costo Bajo

Estado Aprobado

Esfuerzo 2 dias

Capa Servidor

S.G.P.M.SRS

No. Requerimiento

R5104

Versión 1.0


Nombre Manual de Usuario


Descripción La aplicación debe tener un manual de usuario

Objetivo Darle a conocer al usuario, el manejo del juego al alcance de sus manos.


Un claro y fácil entendimiento por parte del usuario de los manuales de usuario, descartara cualquier tipo de ambigüedad respecto a la ejecución del juego.

Excepciones


Ninguna


Requerimiento(s)

Asociado(s)

R4102

R5004

Trazabilidad SPMP


Costo Bajo

Estado Aprobado

Esfuerzo 2 días

Capa Servidor

S.G.P.M.SRS

No. Requerimiento

R5201

Versión 1.0

Tipo Consulta

Nombre Diseño Agradable (GUI fuerte)


Descripción El sistema debe ser agradable visualmente

Objetivo Hace parte de las restricciones acordadas con el cliente en el planeamiento del proyecto, (Ver sección restricciones SPMP)


La aceptación de la apariencia debe ser superior al 70% , teniendo en cuenta su buen diseño y fácil manejo.

Excepciones


Ninguna


Requerimiento(s)

Asociado(s)

Trazabilidad SPMP


S.G.P.M.SRS

Costo Alto

Estado Aprobado

Esfuerzo 2 días

Capa Servidor

No. Requerimiento

R5301

Versión 1.0

Tipo Consulta

Nombre Funcionamiento en laboratorios


Descripción El sistema debe funcionar perfectamente en los laboratorios de la facultad

Objetivo El sistema como tal debe correr correctamente en las salas de la facultad pues es una de las restricciones establecidas por el cliente en el acuerdo del proyecto. (Ver Restricciones SPMP)


El sistema deberá correr correctamente en las salas

Excepciones


Ninguna


Requerimiento(s)

Asociado(s)

S.G.P.M.SRS

Trazabilidad SPMP


Costo Medio

Estado Aprobado

Esfuerzo 2 días

Capa Servidor

4.5 Atributos del Sistema de Software (No funcionales)

Este tipo de atributos se caracterizan por no tener una relación directa con el software que se realiza dentro de un proyecto. Sin embargo, este tipo de atributos reflejan el comportamiento en el momento de la ejecución, estructura y organización del programa fuente y la respectiva documentación. A continuación de mostraran algunos de los atributos con los que deberá contar el producto final que se le mostrara al cliente: [Nº Referencia]

[Nº Referencia]Ian Sommerville 2000, Software Engineering, 6th Edition. Chapter 1

ATRIBUTO APLICACIONConfiabilidad El sistema debe de soportar todas las

funcionalidades anteriormente descritas y garantizar su buen funcionamiento durante todo el período de su ejecución. Para ello, se utilizarán patrones de diseño que han sido ampliamente estudiados y probados.

Disponibilidad Los ficheros utilizados para la persistencia de datos, tales como los

S.G.P.M.SRS

diccionarios de juego e idiomas de localización, perfiles de jugadores, etc., deberán estar disponibles como mínimo al menos durante la ejecución de la aplicación.

Seguridad En un principio, será el propio usuario de la aplicación el encargado de garantizar la seguridad de los datos utilizados por ésta. De la misma manera, el propio Usuario será el encargado de realizar backups de los ficheros con datos sensibles cuando él crea necesario.

Mantenibilidad El mantenimiento y modificaciones que se puedan hacer en el sistema, dependerá de las aplicaciones con las que se quiera integrar y las plataformas donde se quiera poner.

Eficiencia El sistema se ha de comportar de manera eficiente y rápida, tanto en la resolución de los problemas presentados a cada turno de juego, como en el desarrollo general de las partidas. Desde el punto de vista de la gestión de datos, la aplicación se ha diseñado de forma eficiente.

Fácil Manejo La aplicación va dirigida tanto a personas expertas en informática como a personas con conocimientos muy bajos o casi nulos, por tanto, su diseño ha de estar pensado para este último tipo de personas. Esto se deberá conseguir mediante menús y pantallas suficientemente intuitivas y fáciles de usar para cualquier usuario de la aplicación.

S.G.P.M.SRS

4.6 Requerimientos de la base de datos

Para la especificación de los requerimientos de la Base de Datos, es necesario tener en cuenta varios aspectos, entre estos se encuentran:

Ilustración 7: Características Bases de Datos

Tipos de datos almacenados: dependiendo del motor de base de datos escogidos, es posible tener diferentes tipos de datos, sin embargo al hacer esta sección podrían incluirse los más usados: Char, Varchar, Numeric y Date por mencionar algunos.

Tipo de consultas utilizadas: la forma en que los datos serán accedidos, consultadas e ingresados desde los DAO´s (Data Access Object) para evitar la introducción de sentencias malintencionadas. Los tipos más conocidos son Statement y Prepared Statment.

Indexación de los datos: la eficiencia de las consultas complejas pueden reducirse dependiendo de la forma en que se haga el diseño de la base de datos, una buena forma de mostrar este aspecto es con el diagrama de Entidad Relación

Tipos de datos almacenados

Tipo de consultas utilizadas

Indexación de los datos

Uso de Primary key

Frecuencia de acceso

S.G.P.M.SRS

Utilización de Primary Key: al igual que con el aspecto anterior la utilización adecuada de una primary key puede evitar ciclos y además permite y facilita eficiencia en el tiempo de consultas hechas en tiempo real.

Frecuencia de acceso: dependiendo del tipo de sistema que se desea implementar, especificar la frecuencia de acceso a la base de datos incluyendo el número de conexiones abiertas y tener en cuenta el tipo de consulta utilizada, la carga extra que puede producir el manejo de DAO’s puede disminuir, aumentando de esta forma el desempeño en general de la aplicación.

S.G.P.M.SRS

5 Anexos

SRS v.0.5 (Plantilla Corregida)

Documents

Transcript of SRS v.0.5 (Plantilla Corregida)