SportsUNAM

Documento de Especificación de
Requerimientos (SRS).
Preparado por: Team9 Consultores
Para: Universidad Nacional Autónoma de
México
Versión 1.0
Fecha: 14-03-2016

Historial de Revisiones
Fecha Versión Autor Descripción
04-04-2016 1.0

Historial de Aprobaciones
Nombre de la
Fecha Versión persona que Información de contacto
aprueba
04-04-2016 1.0
Contenido.

1. Introducción
1.1. Propósito.
1.2. Alcance.
1.3. Contexto del Sistema.
1.4. Involucrados.
1.5. Acrónimos y abreviaturas.
1.6. Organización del documento.
1.7. Referencias.
2. Restricciones y suposiciones.
3. Riesgos.
3.1. Políticos.
3.2. Tecnológicos.
3.3. De recursos.
3.4. De habilidades.
3.5. De requerimientos.
4. Requerimientos funcionales.
4.1. Características principales del Sistema.
4.2. Descripción de los Actores.
Actor No. 1:
Actor No. 2:
Actor No. 3:
4.3. Casos de Uso.
4.4. Aplicaciones.
4.5. Requerimientos funcionales para cada caso de uso.
5. Requerimientos no-funcionales.
6. Glosario del proyecto.

SRS <sistema> <UNAM> confidencial página 2 de 11

1. Introducción

El presente documento brindará a los lectores una comprensión

adecuada de las características más relevantes de SportsUNAM; un
sistema de administración que apoyará la organización, creación,
operación y gestión de los torneos deportivos realizados por la
UNAM.

1.1. Propósito.

En este documento exclusivamente se detallarán las propiedades

del sistema SportsUNAM (en lo subsecuente se le mencionará
como “sistema”), con el propósito de ampliar, clarificar y dar a
conocer el funcionamiento del mismo. El documento está dirigido
especialmente a los trabajadores de la División de Actividades
Deportivas de la UNAM encargados de la realización y planeación
de los torneos deportivos.

1.2. Alcance.

El sistema solamente administrara todos los aspectos de la

creación, configuración y gestión de los torneos deportivos que
realice la UNAM, encargándose de dar de alta equipos y jugadores
de las distintas universidades del país, así como la generación de
los calendarios de partidos.

Además, será responsable de la informar al público en general de

los resultados, estadísticas, fechas y lugar en que se realiza cada
partido mediante una aplicación web.

1.3. Contexto del Sistema.

El sistema es independiente y es desarrollado para trabajar en la

organización de eventos deportivos para facilitar su creación y
gestión.

1.4. Involucrados.

Actor (rol) Involucrado Primario Involucrados Secundarios

Director de la
Enrique Contel Marisol Sandoval
División de
SRS <sistema> <UNAM> confidencial página 3 de 11
 Actividades
Deportivas de la
UNAM

Coordinador de la
División de
Actividades Juan Carlos Pérez Sandra Botello
Deportivas

Secretaria
Liliana Huerta Lizbeth Morales
Coordinador de
Mariana Zepeda Rogelio Chávez
Eventos

1.5. Acrónimos y abreviaturas.

Acrónimo/Abreviatura Descripción.

FR Functional Requirements (Requerimientos funcionales)

NFR Non Functional Requirements (Requerimientos no funcionales)

1.6. Organización del documento.

El documento se divide en secciones, en las cuales se describen

todos los requerimientos del sistema conocidos hasta el momento,
incluyendo requerimientos funcionales y requerimientos no
funcionales.

● Sección 1: Breve introducción al sistema y sus aspectos

generales.
● Sección 2: Describe las restricciones y suposiciones del
presente proyecto.
● Sección 3: Riesgos conocidos y como mitigarlos.
● Sección 4: Descripción de los FRs en forma de casos de uso.
Los cuales son necesarios para el correcto funcionamiento del
sistema.
● Sección 5: Descripción de los NFRs del Sistema.
Requerimientos para el mejor desempeño del sistema.
● Sección 6: Glosario del proyecto.

1.7. Referencias.
SRS <sistema> <UNAM> confidencial página 4 de 11
 ● Documento de Visión SportsUNAM.
● Notas de las entrevistas hechas a los directivos de la División
de Actividades Deportivas de la UNAM.
● Notas de las entrevistas hechas a los empleados de la
División de Actividades Deportivas de la UNAM.

2. Restricciones y suposiciones.
2.1 Restricciones de Tecnología de Hardware y Software.

● Para las labores de administración del SportsUNAM, se deben

utilizar las computadoras personales con que actualmente
cuentan la Dirección de Actividades Deportivas de la UNAM.

● Debe haber una base de datos común para uso tanto de

administradores como de seguidores del torneo.

2.2 Fecha límite.

● El sistema deberá estar ya implementado en el mes de

octubre del año 2016 (presente año).

3. Riesgos.
3.1. Políticos.

Por el momento no se visualizan riesgos de ámbito político.

3.2. Tecnológicos.

● La capacidad de las PCs con que se cuenta puede no

ser suficiente para el sistema. Se diseñará el sistema
para que sea compatible con los recursos con los que se
cuentan actualmente, pero no se garantiza un
funcionamiento óptimo del mismo.

● El software libre puede tener fallos en sistemas

operativos Windows además de no tener soporte ya que
se entrega “tal cual”. Se tiene experiencia en el uso del
software libre de tal manera que se mitigaran en lo
posible los problemas que se lleguen a presentar.

SRS <sistema> <UNAM> confidencial página 5 de 11

 ● El sistema puede no funcionar en algún navegador de
Internet especial. Es prácticamente imposible probar un
sistema en todos los navegadores existentes. Se
recomendará el uso de navegadores más amigables con
la programación de software libre como es el caso de
Mozilla Firefox.

3.3. De recursos.

Las personas no están capacitadas.

3.4. De habilidades.

El Sistema cuenta con varias especificaciones, pero no es un

sistema particularmente difícil de desarrollar e implementar.
La curva de aprendizaje para el usuario final no será elevada
y será muy intuitivo su uso.

3.5. De requerimientos.

Los requerimientos solicitados no necesitan de la aplicación

de una tecnología en específico, es por ello que no
representan un problema en el desarrollo del Sistema.

4. Requerimientos funcionales.
El sistema debe cumplir con ciertas funciones fundamentales, las
cuales nos definen el funcionamiento del sistema, las hemos
dividido en esenciales, requeridos y deseables, esta división es para
denotar prioridad e importancia.

4.1. Características principales del Sistema.

Esenciales:

● El Sistema deberá permitir la administración de las

Universidades participantes.
● El Sistema deberá permitir la administración de los equipos.
● El Sistema deberá permitir la administración de los jugadores
● El Sistema deberá permitir la administración de los árbitros.
● El Sistema deberá permitir la administración de las canchas
donde se jugarán los partidos.

SRS <sistema> <UNAM> confidencial página 6 de 11

 ● El Sistema deberá permitir la elaboración del calendario de
juegos del torneo para todas las rondas.
● El Sistema deberá permitir el registro de los resultados de los
partidos.

Requeridos:

● El Sistema deberá permitir la consulta del calendario.

● El Sistema deberá permitir la consulta de los resultados de los
partidos.

Deseables:

● El Sistema deberá permitir la consulta del calendario vía web.

● El Sistema deberá permitir la consulta de los resultados de los
partidos vía web.

4.2. Descripción de los Actores.

Administrador:

Será el responsable de la creación, actualización y, es su caso, el

borrado de los registros de la Base de Datos, Sitio Web y
Calendario. Tendrá acceso a la Estación de Trabajo y la Intranet del
torneo. Puede dar de alta, modificar y borrar de los registros e
información de equipos, jugadores, fechas de calendario, canchas,
partidos.

Árbitro:

Usuario del Sistema que solo podrá modificar la información de los

resultados de los partidos, así como la reseña del mismo. Este
Actor solo podrá modificar los datos de los partidos existentes, no
puede crear nuevos ni borrarlos y solo tendrá acceso a la
modificación de resultados y reseña, es decir, queda fuera del
alcance del Actor la modificación de fechas y/o información de los
equipos y jugadores.

Aficionado:

Actor que solo tendrá acceso al Sitio Web del torneo. Sus privilegios
se limitan a solo lectura.

SRS <sistema> <UNAM> confidencial página 7 de 11

4.3. Casos de Uso.

Caso de Uso Prioridad Núm. Descripción

El sistema deberá permitir el uso del
calendario a los encargados y permitirá
Manejo del
E 1 asignar fechas a los partidos, en el cual
Calendario.
también se contempla la cancelación y
modificación de fechas
El Sistema deberá permitir guardar la
información de las universidades, equipos,
jugadores, árbitros y canchas que
Registro de participaran en el torneo. Debe permitir la
E 2
participantes. modificación de un registro ya creado y
además tener la capacidad de borrar
registros cuando el administrador lo crea
pertinente.
Se podrá asignar y modificar los resultados
Registro de
de los partidos, donde también se
resultado de E 3
contemplan campos como “tiempo extra” y
los partidos.
“penales”.
El sistema deberá mostrar al usuario el
calendario de los partidos, así como los
Consulta
R 1 resultados, pero no tendrá acceso a
Calendario.
modificaciones de los registro ni alta ni baja
de los mismos.
Se permitirá la consulta del calendario de
partidos vía web, así como los resultados de
Consulta Web. D 1 los mismos. Esto será solo a modo
informativo, no se permitirá la modificación,
alta o baja de registros

4.4. Aplicaciones.

Subsistema Descripción / Casos de Uso

Este subsistema muestra las fechas de los partidos

Calendario
acomodadas a manera de calendario mensual.
Subsistema que sirve como medio de información para el
Sitio Web Público. En él se pueden revisar los resultados, reseñas
de los partidos, así como el Calendario.
Subsistema que funciona para la administración del
sistema. En ella se puede dar de alta/baja y editar
Estación de trabajo
información de los equipos, Calendario, partidos,
resultados e información relevante.

Base de datos Sirve para el almacenamiento de la información de toda

Subsistema para revisar y administrar los datos del

Intranet
torneo. Con funcionalidades comparables a las funciones
SRS <sistema> <UNAM> confidencial página 8 de 11
 realizadas por la Estación de Trabajo, pero solo con
permisos de modificación de la información en ciertas
áreas.

4.5. Requerimientos funcionales para cada caso de uso.

FR Descripción

El sistema permitirá la modificación del calendario desde el sitio Web

E1 – 1

El sistema verificará el nivel jerárquico del usuario y permitirá

E1 – 2 acceder a las opciones de acuerdo a sus privilegios.

El sistema verificará si la fecha creada no se encima a una creada

E1 – 3 anteriormente. De ser así, no creará el registro hasta que la fecha
esté en un horario vacío o disponible.
El sistema verificará que antes de crear u equipo deberá estar
creado el registro de la universidad a la cual pertenece, de no ser así
E2 – 1
el sistema mostrará la pantalla de creación del registro de la
universidad del equipo.
El sistema verificará que antes de crear un jugador deberá estar
creado el equipo al cual pertenece el jugador, de no ser así el
E2 – 2
sistema mostrará la pantalla de creación de equipo en vez de la de
creación de nuevo jugador.
Si se requiere el sistema permitirá la modificación de un registro
E2 – 3 creado.

El sistema enviará un registro borrado a un respaldo y lo quitará del

E2 – 4 sistema principal.

El sistema permitirá recuperar un registro borrado del respaldo para

E2 – 5 reinstalarlo en el sistema principal.

El sistema permitirá la modificación de resultados a los usuarios con

E3 – 1 nivel mínimo de Árbitro y registrará el nombre de usuario quien hizo
la modificación.
El registro de resultados tendrá un historial del cual solo será visible
E3 – 2 el ultimo resultado registrado, pero se podrá volver a un registro
anterior de ser necesario.
El sistema solo mostrará los registros más actuales al Publico, y en
R1 – 1 tiempo real.

El Sitio Web mostrará los resultados en tiempo real y los mostrará a

D1 – 1 cualquiera que acece al sitio sin necesidad de que se cuente con
una cuenta de acceso.

5. Requerimientos no-funcionales.
SRS <sistema> <UNAM> confidencial página 9 de 11
 NFR Descripción

Deberá estar disponible 24 horas diarias durante las 2 semanas de

Disponibilidad
duración del torneo y tres semanas antes del inicio del mismo.

El Sistema deberá poder manejar hasta 20 Universidades, 60

Escalabilidad equipos, 1200
jugadores, 100 canchas y 100 árbitros.
El tiempo de respuesta de las operaciones de consulta debe ser
Tiempo de menor a 5 segundos. El tiempo de respuesta de las operaciones de
Respuesta administración debe ser menor a 5
minutos.
La consulta de los resultados de los partidos y del calendario
Consulta de
deberá poder ser hecha desde cualquier computadora conectada a
Resultados
la Internet.

El uso de datos personales implica resguardar la información

Seguridad
proporcionada por los participantes del torneo.

6. Glosario del proyecto.

Bancos de información que contienen datos relativos a

diversas temáticas y categorizados de distinta manera, pero
Base de datos que comparten entre sí algún tipo de vínculo o relación que
busca ordenarlos y clasificarlos en conjunto.

Conocida también como GUI (del inglés graphical user

interface), es un programa informático que actúa de interfaz
de usuario,
utilizando un conjunto de imágenes y objetos gráficos para
Interfaz
representar la información y acciones disponibles en la
gráfica/entorno
interfaz. Su principal uso, consiste en proporcionar un
entorno visual sencillo para permitir la comunicación con el
sistema operativo de una máquina o computador.

Son aquellas herramientas que los usuarios pueden utilizar

Aplicación web accediendo a un servidor web a través de Internet o de una
intranet mediante un navegador.

Un icono o ícono1 es, en informática, un pictograma que es

Icono
utilizado para representar archivos, carpetas, programas,

SRS <sistema> <UNAM> confidencial página 10 de 11

 unidades de almacenamiento, etc. en un sistema operativo
gráfico.

Una ventana es un área visual, normalmente de forma

rectangular, que contiene algún tipo de interfaz de usuario,
Ventana mostrando la salida y permitiendo la entrada de datos para
uno de varios procesos que se ejecutan simultáneamente.

Persona que se encarga del arbitraje de los partidos

Árbitro

Persona que participa en el torneo como integrante de un

Jugador
equipo.

Grupo de jugadores que participan en el torneo.

Equipo

Persona que asiste al torneo presencialmente o que sigue

Aficionado las actualizaciones desde la aplicación sin tener un registro
en el torneo.

FIN DEL DOCUMENTO SRS

SRS <sistema> <UNAM> confidencial página 11 de 11

 Casos de uso (basico)
Sistema Sports UNAM

D1: Consulta Web

Aficionado
R1: Consulta Calendario

E3: Registro de resultados de los partidos

Árbitro

E1: Manejo del Calendario

Administrador E2: Registro de Participantes

 Escenario Principal

Inicio:

El administrador abrirá la aplicación Sports UNAM dando doble click sobre el icono en el escritorio,
se abrirá una ventana de login solicitando usuario y contraseña, los cuales introducirá y presionara
el botón “ENTRAR”, se abrirá una ventana con las siguientes opciones:

A. Administrar inscripciones
B. Administrar equipos
C. Administrar jugadores
D. Administrar canchas
E. Administrar árbitros
F. Administrar puntajes
G. Crear calendario

Pulsara sobre la opción “CREAR CALENDARIO”.

Cuerpo:

El sistema emparejara los equipos aleatoriamente y en unos segundos desplegara un archivo PDF
(En el programa que este predeterminado para abrir este tipo de archivos) con los encuentros
alineados en forma de árbol inverso mostrando el logotipo y nombre de cada equipo en la parte
superior del árbol, la cancha y la fecha en la que se llevara a cabo el encuentro y los árbitros que
estarán presente en cada partido, así mismo el sistema creara una tabla en la base de datos, a la
espera de resultados.

Final:

Una vez creado el calendario el administrador cerrara la ventana, dará click en “SALIR” en la
ventana principal y cerrara el programa.
 Casos de Uso (refinado)
Sistema Sports UNAM
D1: Consulta Web
Aficionado
R1: Consulta Calendario

E3: Registro Resultado Partido Consultar Partido

Árbitro E1: Manejo del E1a: Seleccionar Fijar

Calendario fecha partido

Buscar Universidad
E2a: Alta de Participante
Crear Universidad
E2b: Actualizar Participante
Administrador Consultar Registro
E2c: Borrar de Participante
Diagrama de Actividades

Capturar Nombre

Capturar Edad

Seleccionar equipo

Capturar Nombre del No existe equipo

equipo
else
Guardar registro del
equipo

Seleccionar
Universidad

Capturar Nombre de No existe la universidad

la universidad
else
Crear otro registro
Guardar registro de
la universidad
else
 Candidato a
Causa de eliminacion Nombre seleccionado
Abstraccion clave
Equipos Atributo de Jugador

Jugadores Jugador

Universidad Atributo de Jugador

Administrador Administrador

Arbitro Arbitro
No tiene colaboradores
Aficionado
o atributos
Base de Datos Sistema externo

Sitio Web Sistema externo

Calendario Calendario

Estación de trabajo Atributo del Sistema

Intranet Atributo del Sistema

Torneo Atributo del Calendario

Canchas Atributo del Partido

Partidos Partido

Encargado Sinonimo de Administrador

Registro Registro

Tiempo Extra Atributo del Calendario

Penal Atributo del Calendario

Interfaz gráfica Atributo del Sistema

Entorno Atributo del Sistema

Aplicación Web Atributo del Sistema

 Tarjetas CRC
Jugador Administrador
Responsabilidades Colaboradores Responsabilidades Colaboradores

Registro Registrar Jugadores Registro

Admin. Calendario Jugadores
Admin. Arbitro Arbitro

Nombre Nombre
Apellido Clave
Edad

Arbitro Calendario
Responsabilidades Colaboradores Responsabilidades Colaboradores

Registrar resultados Administrador Programación del Partido

de los partidos Calendario Torneo Administrador

Fecha
Equipos
Cancha
Nombre Hora
Clave
ID

Registro Partido
Responsabilidades Colaboradores Responsabilidades Colaboradores

Registrar jugador Administrador Calendario

Jugador Arbitro

Datos Jugador Tiempo extra

Nombre Equipo Penales
Universidad Puntos
Numero de goles
 Modelo Conceptual

Registro Jugador

-Datos del Jugador +agrega -Nombre

1 1..*
-Nombre del Equipo -Apellido
-Universidad -Edad
1..*
-Registrar Jugador
+realiza

Administrador Calendario
-Fecha Partido
-Nombre 1 +controla 1..* -Equipo
-Clave 1 +agrega 1..* -Tiempo Extra
-Arbitro
-Cancha -Penales
-Registrar Jugador -Hora -Puntos
-Administrar Calendario -No. Goles
-Administrar Arbitro -Programación de los partidos
1..*
1

Arbitro +administra
+administra
1
-Nombre
-Clave
1..*
-ID

-Registrar Resultados de los

partidos
 1:Registrar Jugador

:MainUI :Caracteristicas

1.1:Mostrar RegJugUI 2.1.1:Crear

1.1.1:Obtener lista de equipos

2.1:Obtener lista de Jugadores

:RegJugUI :RegJugService
3.1:Buscar Lugares Disponibles

3.1.1:Crear

Diagrama de Secuencia y Comunicación

:Jugadores

:MainUI :RegJugUI :RegJugService :Caracteristicas :Jugadores

Registrar Jugador Mostrar

RegJugUI Obtener lista de
equipos

Seleccionar Equipo Obtener lista de

Jugadores Crear

Introducir Datos Buscar Lugares

Disponibles
Crear
 Arquitectura General del Sistema

Servidor de
Cliente Web Server Aplicaciones
Navegador
Aplicación Sports
De
Web UNAM
Internet
Aplicación
Público de
Negocios

Intranet Workstation

Base de Datos
Torneo
App

Administrador
Menú Principal
Capa Cliente Capa de Presentación Capa de Negocio Capa de Integración Capa de Recursos

Cliente HTTP Servidor Web

JRMP Aplication Server
Aplicación Web
Navegador Revisar <RMI> Registro RMI
Web Calendario Servicio Calendario
Calendario

Servicio Calendario

Elegir Fecha <RMI>

PublicoGral Calendario

Sports UNAM Aplicación de Negocios

Publico en
General
DAOFactory_JDBC

Base de Datos
Intranet Workstation Calendario DAOFactory <create>

Torneo App Partidos

<RMI>
Calendario CustDAO_JDBC
Servicio
<GUI>
Mai n Menu
Servicio Calendario
Calendario
JRMP
PublicoGral
CustDAO
Administrador
 Diagrama de Stratos
Cliente Presentación Negocios Integración Recursos

Sports UNAM
Aplicación Esquema
App Torneo App
Web
Aplicación de DAOs
BD
Negocios

VP HTML v5.0 STRUTS 2.5 RMI JDBC v4.1 SQL/DDL

Cualquier Tomcat v9.0 PostDriver

AI Navegador J2SE v5.0
J2SE v5.0
J2SE v5.0
PostgreSQL

Cualquier RedHat
ES S.O.
Linux Enterprise
Linux

Cualquier Xeon
C&S PC
Athlon
Server
 Modelo Conceptual (detallado y refinado)
Registro
Jugador
-DatosJugador: (String, string, int)
-Nombre del Equipo: String
-Nombre: String
-Universidad: String 1 +agrega 1..*
-Apellido: String
-AddJugador(:Nombre, :Apellido, -Edad: int
1..* :Edad)
-SetNomEquipo(String)
+realiza -SetUniversidad(String)

1
Calendario
Administrador
-Fecha: date {changeable}
-Equipo: String Partido
-Nombre: String{Frozen} 1 +controla 1..* -Cancha: String
-Clave: int {Frozen} -Hora: Hora {changeable} 1 +agrega 1..* -TiempoExtra: boolean
-Penales: boolean
+RegistrarJugador() :String -Puntos: int
+AdminCalendario() : -AddPartido(:Partido)
-SetFecha(date) -Goles: int
+Administrar Arbitro
+getNombre(): String -SetCancha(String) 1..*
+getClave(): int -GetFecha() :date
+setNombre(String) -GetCancha() :String
1
+setClave(int) +administra
Arbitro 1
+administra 1..*
-Nombre: String
-Clave: int{frozen}
-ID: int{frozen}
-RegPartido(:TiempoExtra,
:Penales, :Puntos, :Goles)
-SetNombre(String)
-SetClave(int)
-SetID(int)
 Plan de Desarrollo
Tamaño del equipo de desarrollo y experiencia de los participantes.
El equipo tiene 4 desarrolladores a cargo del proyecto:
Desarrollador 1: Experiencia en el desarrollo de web
Desarrollador 2: Conocimiento en el área de aplicaciones tecnológicas
Desarrollador 3: Experiencia en el desarrollo de instalación e iniciación de servidores Linux.
Desarrollador 4: Programador en Java

•Priorización de los casos de uso a desarrollo

Caso de uso Diagrama de Desarrollador web Desarrollador lógica
GUI negocio
E1: Manejar de calendario 6 semanas 6 semanas 15 semanas
E2: Registro de 8 semanas NA 8 semanas
participantes.
E3: Registro de resultado 4 semanas 3 semanas 6 semanas
de los partidos.
Total 18 semanas 9 semanas 29 semanas

Diagrama de Gantt para el desarrollo.

Febrero Marzo Abril Mayo

Actividades
Sem1 Sem2 Sem3 Sem4 Sem1 Sem2 Sem3 Sem4 Sem1 Sem2 Sem3 Sem4 Sem1 Sem2 Sem3
Torneo
App
Calendario
Sitio web
Pruebas
Mayo Junio Julio Agosto Septiembre
Actividades
Sem4 Sem1 Sem2 Sem3 Sem4 Sem1 Sem2 Sem3 Sem4 Sem1 Sem2 Sem3 Sem4 Sem1 Sem2
Torneo
App
Calendario
Sitio web
Pruebas
Septiembre Octubre Noviembre
Actividades
Sem3 Sem4 Sem1 Sem2 Sem3 Sem4 Sem1 Sem2 Sem3 Sem4
Torneo
App
Calendario
Sitio web
Pruebas