ESPECIFICACIN DE REQUERIMIENTOS DE

SOFTWARE
JUEGO EL SEMAFORO

AUTOR
Freddy Leonardo Abad Len.
FECHA:
13 de junio de 2016

ndice
1. Introduccin
1.1. Propsito del
documento
...3
1.2. mbito del Sistema.
...4
1.3. Definiciones, Acrnimos y Abreviaturas....
.4
1.4.
Referencias...........................
....................................5
1.5. Visin General del
Documento...........................................
...5
2. Descripcin General
2.1. Perspectiva del
Producto..
..5
2.2. Funciones del
Producto
.6
2.3. Funcin de
Sistema
..6
2.3. Tipos de Actores...
..
..9
2.4.
Restricciones
11
3. Definicin de Requisitos del Sistema
3.1. Definicin de
Requisitos
.12
3.1.1. Requerimientos del
Usuario.12
3.1.2. Requerimientos del
Sistema
16

3.1.3. Requerimientos
Funcionales
16
3.1.4. Requerimientos No
Funcionales
17
4. Especificacin de Requisitos del Sistema
4.1. Jerarqua de Casos de
Uso..
.19
5. Anexo.
........................................................................20

1. INTRODUCCION
1.1.

PROPSITO DEL DOCUMENTO

El presente documento se elabor debido a la necesidad de documentar los pasos a seguir en el

desarrollo de un proyecto que divertir a un conjunto de personas mediante el juego de
monopolio.
Como objetivo principal del documento se tiene el elaborar un plano del software que se pide
como proyecto final de la materia Programacin 2: Algoritmos y Estructura de Datos.
Este plano constara de los distintos modelos de diseos de Algoritmos que se utilizaran en el
softwares que atiendan a las usuarias.
El presente documento va dirigido al cliente, ms no al usuario. Est dirigido a la persona que
ordena la creacin de este software ms no al usuario final. Llamaremos en este documento a
los/as dueos/as (socios/as propietarios/as) de la empresa como Product Owner.
Este documento ha sido redactado con el fin de especificar los aspectos y especificaciones
generales que deber regir el software, teniendo como principal objetivo satisfacer las
3

necesidades del usuario. Este documento est sujeto a cambios, es decir, que no se aprobara el
documento hasta que el Product Owner lo estipule as, pretendiendo de esta manera orientar
todo el trabajo de desarrollo del producto a las personas interesadas en el proyecto, tomando en
cuenta las descripciones y detalles esenciales de la aplicacin y que identifican a esta. Adems
cabe recalcar que al ser un documento basado en un proyecto de investigacin, estar
dependiente de los cambios en el sistema, circunstancias y dems entornos que afectan a la
realizacin del proyecto. Con esto se busca resaltar que este documento ser sensible al cambio
por las razones ya estipuladas.

1.2.

MBITO DEL SISTEMA

El proyecto tratado en el presente documento tiene el nombre EL SEMAFORO que ofrecer el

servicio de entretenimiento mediante plataformas virtuales.
El tablero del juego consta de 50 casillas hasta llegar a una casilla especial de Meta Final, en el
cual durante todo este trayecto hasta llegar a la Meta Final, existen varias opciones o casillas que
adelantaran a casillas posteriores o retroceder con casillas a determinada casilla dependiendo el
valor de cada casilla.
El modo de operacin de cada oportunidad, consiste en dar la oportunidad a cada jugador lanzar
dos dados, y lo llevara a cierto dado adelante (en el juego), atenindose a ciertas casillas
especiales como la Verde, Puente, Amarillo, Tnel, Rojo, Semforo, Barranco.
Todas estas opciones aparte de entrenar a los usuarios finales agregan la pequea funcionalidad,
de que al caer en determinado casilla, uno tiene que participar en un juego que le ofrecer 3
oportunidades para adivinar los nmeros existentes, aparte de que le brinda el apoyo de
semaforizacin dependiendo el nivel de acierto con el propsito
1.3. DEFINICIONES, ACRNIMOS Y ABREVIATURAS
ADMINISTRADOR: Usuario/a o que tiene acceso tanto a modificar, visualizar y moderar el
sistema.
APLICACIN: Programa informtico implementado para facilitar a los usuarios la realizacin
de un determinado tipo de trabajo.
BASE DE DATOS: Grupo de datos de similar arquitectura y que son almacenados
sistemticamente para su posterior uso.
SERVIDOR: Ordenador remoto que provee los datos solicitados por parte de los usuarios del
sistema.
USUARIOS/AS: Hace referencia a las personas que interactuaran con el sistema, hay dos clases
de usuarios en este caso y son el administrador, relacionistas pblicos, operadores y el cliente.

1.4.

DESCRIPCION GENERAL DEL PROGRAMA

4

Un juego de mesa es un lugar formado artificiosamente por calles y encrucijadas, para confundir
a quien se adentre en l, de modo que no pueda acertar con la salida lo ms pronto posible. Se ha
convertido en un juego muy entretenido donde el jugador tiene un objeto situado en un punto de
partida (entrada), luego debe moverlo hasta encontrar la salida del laberinto, tomando en cuenta,
que el usuario solo puede mover el objeto donde sea posible, es decir, mientras no exista una
casilla que se interponga en su camino, en tal caso podr retroceder hasta encontrar un nuevo
camino de salida.

METODOLOGIA
Estrategia para generar la matriz (tablero)
El algoritmo usado para la generacin de la tabla de juego fue basado en la lgica del algoritmo
llamado 'Recursiva Back tracking', donde su explicacin est en la pgina:
weblog.jamisbuck.org/2010/12/27/maze-generation-recursive-backtracking
Se propone crear distintos tamaos de tableros, para aumentar la dificultad (fcil, medio,
legendario) siendo legendario el tablero de 50 casillas.
Para la creacin de cualquier tablero se induce que la mejor manera (la ms fcil) de realizarlos
es mediante matrices en las cuales se mandan a llenar recursivamente, siendo la casilla de centro
el caso base, y se repite el proceso hasta que llegue al nmero de filas menos 2.
El orden de complejidad de este algoritmo es de O (nnlog(n)), siendo n el tamao del tablero
multiplicado por la dificultad deseada por el usuario.
Esta estrategia de generacin de la matriz es rpida, fcil de entender, y sencilla de implementar,
necesita la memoria suficiente para almacenar toda la matriz en la memoria, sin embargo, y
requiere espacio de pila proporcional al tamao de la matriz, por lo que para excepcionalmente
grandes matrices sera bastante ineficiente. Pero para la mayora de casos, funciona
correctamente.
La estrategia recursiva comienza en:
I.

Elegir un punto de partida en el campo.

II.

Elegir al azar una pared en ese punto y tallar un paso a travs de la celda adyacente, pero
slo si la clula adyacente no ha sido visitado an. Esto se convierte en la nueva celda
actual.

III.

Si se han visitado todas las clulas adyacentes, de vuelta hasta la ltima celda que tiene
paredes sin tallar y repetir.

IV.

El algoritmo termina cuando el proceso ha apoyado todo el camino hasta el punto de

partida.

Se implementa el campo como una cuadrcula de campos de bits (donde los bits en cada celda,
describen caminos con direccin).
La estructura a utilizar es la siguiente
5

typedef struct nodo

{
int x;
int y;
int n;
int m;
struct nodo* anterior;
struct nodo* vecinos[3];
}celda;
Donde x, y se definen como la ubicacin en la matriz creada dependiendo la dificultad: Fcil
(25), Intermedio (30), Difcil (50) casillas respectivamente.
Las variables n, m se definen como los auxiliares que utilizare para saber los lmites de mi
matriz, y as repetir el proceso lnea por lnea, hasta llegar al mximo de flas y el mximo de
columnas.
|
|
|
|
|
|
|

|
|
|
|
|
|

|
|
|
|
|
|

|
|
|
|
|
|

|
|
|
|
|
|

|
|
|
|
|
|

Estrategia para resolver el movimiento de las casillas.

La resolucin de este tem, utilizara directamente el movimiento de pixeles en la pantalla, es
decir en una pantalla se ubica la imagen en las posiciones (x,y) se ubicara en las posiciones (0,0)
para el inicio del juego, la casilla ocupara un espacio de 20x20 y empezara en esa posicin, para
despus moverse en un espacio de 20 pixeles por casillas, para el nmero de casillas que resulte
del lanzador de dados, al llegar a los ltimos pixeles de la pantalla es decir a los lmites de mi
matriz, se empezara a mover solo en la posicin y, de 20 pixeles por 20 pixeles, as hasta
encontrar la salida, todo esto se manejara con punteros y listas ligadas.
Estrategia para resolver las llamadas a las casillas especiales.
La resolucin de la tabla de mesa de El Semforo estar a cargo de una estructura de Hashing que me
permitir optimizar el tiempo de respuesta del programa. Junto a este tipo de ordenacin, se utilizara el
back tracking recursivo, que me permitir seguir avanzando en el tablero.
En la estructura que buscara estarn distintas variables con distintos variables, al avanzar por el tablero, y
toparse con estas casillas especiales, se mandara a buscar a la estructura la variable que coincida con la
que se ha topado el puntero gua, para que al devolverme un valor, mandar a llamar una funcin que me
defina que debe hacer el programa en estos casos, es decir, si cae en una casilla verde, avanzar al
siguiente casillero verde; si cae en una casilla puente, que me permita avanzar 10 posiciones; al toparme
con un casillero amarillo, saber que pierdo 2 turnos; al toparme con una casilla roja, retroceder hasta una

casilla c, que me retendr hasta que adivine un numero X; o si al toparme con un casillero S1, S2, S3,
saber que tengo que presentar una ventana que contenga el juego, rojo-verde-amarillo.
struct casilleros
{
char verde;
char rojo;
char juego_arv;
char puente;
char puente;
char tnel:
char semforo;
char barranco;
struct casilleros *sig;
};
struct id_casilleros
{
int id;
char casilleros;
struct id_casilleros *sig;
struct casilleros *enlace;
};
struct identificador
{
struct id *inicio;
};

SALIDA
|
|
|
|
|
|
|

|
|
|
|
|
|
LLEGADA

C
|
|
|
|
|
|
T2

R
|
|
|
|
|
|

C
|
|
|
|
|
|

|
|
|
|
|
|
T1

P
A
S1
S2
B

Estrategia para el registro de jugadores

Para el registro de estudiantes simplemente se utiliza una estructura que controlara el ingreso del nombre
del jugador, y que se apilara como una pila permitiendo ver los jugadores uno por uno sacados de
ultimo a primero, y que al momento de jugar permitir sacar los jugadores para su debida partida.
struct Jugadores
{
char jugadores[50];
};

Estrategia para la resolucin del Juego Amarillo, Rojo, Verde.

Para el juego Amarillo, Rojo, Verde, se puede emplear una simple comparacin en un vector de 3
entradas, para para manejar punteros, y conocimientos recientemente adquiridos utilizare Hashing, para la
cual se definir esta estructura:
struct datos
{
char numero1[20];
char numero2[20];
char numero2[20];
struct datos *sig;
};
struct id
{
int id_dato;
char direccion[40];
struct id *sig;
struct datos *enlace;
};
struct identificador
{
struct id *inicio;
};
Estas estructuras me permitirn a comparar uno por uno los datos ingresados por pantalla, y
compararlos con los nmeros generados por nmeros randmicos.
Practica por consola:

1.5.

REFERENCIAS

Para elaborar el actual documento se ha seguido y basado en los siguientes escritos:

Nora Isela Zamora Aguilar, ESPECIFICACIN DE REQUERIMIENTOS CON NCORA

Y EL ESTNDAR 830. 2014

IEEE Std. 830-1998, Especificacin de Requisitos segn el estndar de IEEE 830

William J. Montilva C., ESPECIFICACIN DE REQUISITOS DEL SISTEMA DE

REGISTRO Y CONTROL DE BIENES MUEBLES DE LA ULA. 2007

Ian Somerville, INGENIERIA DE SOFTWARE, 9na Edicin, ISBN: 978-607-32-0603-7.

1.6.

VISIN GENERAL DE DOCUMENTO

En el presente documento se trataran el tema principales, el primero: se tratara la informacin

caracterstica del servicio El Semforo como son la descripcin general del documento y el
desarrollo de los requerimientos funcionales y no funcionales del sistema. Como segundo tema,
se analizara el desarrollo del software que interactuara operadores, usuarias, con sus
requerimientos funcionales y no funcionales.
2.1.

2. DESCRIPCION GENERAL
PERSPECTIVA DEL PRODUCTO

Como objetivo se proyecta disear el servicio adecuado que permita entretener efectivamente a
mujeres, hombres o nios mayores o menores de edad a los distintos puntos de destino,
enfatizando y priorizando la Integridad del servicio, la Calidad, el Respeto y la responsabilidad
social hacia los Usuarios.
Todas estas cualidades sostenidas en el constante mejoramiento del servicio, siempre guiados por
la perspectiva de la Excelencia en el servicio.
Al enfatizar todas estas condiciones, harn que Lady Express sea definida por la opinin
pblica por todas las cualidades antes mencionadas. Con esto se lograra que el servicio prestado
por la marca sea de un nivel superior al ofrecido por otras empresas, posicionando a Lady
Express como una empresa lder en el transporte VIP de la ciudad de Guayaquil.
Priorizamos una perspectiva de que el proyecto ha sido diseado para una mejor experiencia de
uso, debido a los mltiples problemas antes descritos.
Los softwares a desarrollar crearan en la usuaria una sensacin de tranquilidad y comodidad,
debido a que ser visualmente atractivo adems de un fcil uso, ya que el rango de edad al que va
dirigido Lady Express est entre los 16 a 65 aos, tomando en cuenta a las fminas de mayor
edad que no se acostumbren a la utilizacin de las nuevas tecnologas (plataformas web,
aplicaciones de telfonos inteligentes).
2.2.

FUNCIONES DEL PRODUCTO

9

El software presenta las siguientes funciones:

2.2.1. Funcin de Registro de Nuevos Usuarios.
En esta funcin las/os usuarias/os tendrn el acceso a la plataforma en la cual registraran
sus datos personales, tales como Nombres y Apellidos Completos, Telfono, Cedula de
Identidad, Direccin, Fecha de Nacimiento, , Correo Electrnico, Correo Electrnico
Alterno, Numero de Tarjeta de Crdito,
Como ltimo paso, se le otorgara un nombre de cuenta, en la cual se tendr explicito el
nombre de el/la usuario/a, y se pedir una contrasea que ser elegida por la clienta.
2.2.2. Funcin de Inicio de Sesin.
Los usuarios de la aplicacin de escritorio tendrn acceso a su cuenta de Mi Semforo
en la cual se tendr toda su informacin, lista para ser consultada, o ser modificada por la
usuaria, adems de poder acceder a todos los servicios de la Empresa. Este acceso ser
mediante el nombre de cuenta otorgada a los clientes y la contrasea que ha sido elegida
por esta. Para la realizacin de esta funcin, el nico requisito ser tener una conexin a
Internet estable, adems de estar activado el servicio de GPS del dispositivo mvil.
2.2.3. Funcin de Cerrar Sesin.
Esta funcionalidad permitir al usuario cerrar la cuenta abierta ya sea en la plataforma de
escritorio. Al estar pendiente un pedido de carrera y los usuarios cierran sesin, se
proceder primero a pedir una confirmacin si se desea la carrera, o se la cancela.
2.2.4. Funcin de Juego AMARILLO VERDE ROJO
Esta funcin permitir a los usuarios que al caer en una determinada casilla durante la
trayectoria a la meta final, se les redirija a un juego penitencia que le otorgo rara 3
oportunidades para realizar el ingreso de nmeros con la intencin de adivinar las
generadas aleatoriamente por el computador.
2.2.5. Funcin de Cancelar Juego.
El cancelar una carrera, ser una funcionalidad, que permita a la usuaria cancelar la
carrera, debido a varias razones, que sern consultadas a la usuaria ya que se le cobrara
un porcentaje de la garanta que se los cobra en el momento de inscripcin, ya que el
cancelar una carrera, implica un gasto operativo que la empresa no se puede hacer cargo.
2.2.6. Funcin de Informacin del Programador.
La funcin Observa Informacin del Programador, permitir saber a la Usuaria ms
acerca de su programador, ya sea los nombres, el tipo de estructuras de datos que utilizo
Esto ayudara a la Usuaria gozar de una confiabilidad y seguridad mayor que abordar un
taxi externo al sistema.
2.2.7. Funcin de Informacin: Cmo jugar?.

10

Este apartado esta creado con la intencin de que aparezca en pantalla un submen con la
informacin pertinente de como jugar, es decir el significado de cada casilla, el
funcionamiento del juego en general, el funcionamiento del juego rojo verde amarillo,
entre muchas ms.
2.2.8. Funcin de Crear un tablero.
Esta funcionalidad del juego permitir e desplegu de un submen con dos opciones, la
creacin aleatoria de un tablero de juego y la creacin de un tablero de juego, con el
ingreso de datos mediante un archivo texto.
2.2.9. Funcin de Creacin Tablero de Posiciones.
Esta funcin del juego permitir crear un tablero de resultados con la posicin de cada
jugador en el tablero, ordenados de mayor a menor
2.3.

TIPOS DE ACTORES

2.3.1. Operador.
El Operador se define como el actor que tenga acceso a las funciones
principales del sistema. Se requiere que sea una persona con un rango de
conocimiento en sistemas informticos bien avanzados para que pueda dar uso
a funciones de acceso solo a personas autorizadas.

2.3.2. Usuarios.
Los Usuarios sern persona que emplee el servicio de El Semforo, es decir,
los empleadores del software.
2.4.

RESTRICCIONES

Este proyecto estar sujeto al tiempo de desarrollo contemplado ante Conciencias 30 DIAS Los operadores deben ser capaces de atender consultas concurrentemente.
El sistema debe tener un diseo e implementacin sencilla, independiente de la
plataforma o lenguaje de programacin.
2.5. SUPOSICIONES.
El factor que puede afectar los requerimientos del sistema es:
o Corto tiempo y por ende dejar las tareas incompletas

11

3. DEFINICIN DE REQUISITOS DEL SISTEMA

En este punto se presentaran los requisitos funcionales y no funcionales que debe obedecer el
software, los cuales estn fundamentados en la entrevista al administrador de la empresa.
3.1.

DEFINICIN DE REQUERIMIENTOS.

En las siguientes tablas estn propuestos de manera clara y detallada los requisitos o
requerimientos funcionales del sistema.
3.1.1. REQUERIMIENTOS DE USUARIO

Cdigo:
Tipo:
Descripcin:

RF1
USUARIO
El sistema permitir al Operador registrar un usuario. El
usuario debe suministrar los datos como C.I. O Pasaporte,
Nombre, Apellido, E-Mail, Edad, Nmero de Tarjeta de
Crdito.

Cdigo:
Tipo:
Descripcin:

RF2
USUARIO
El sistema permitir al Usuario revisar su informacin
personal cada que acceda al sistema.

Cdigo:
Tipo:
Descripcin:

RF3
USUARIO
El sistema permitir al usuario, modificar la Informacin
Personal.

Cdigo:
Tipo:
Descripcin:

RF4
USUARIO
El sistema permitir al Operador O Cliente ingresar nuevas
Usuarios, crendoles una cuenta y asignndoles un nombre
de Cuenta y contrasea.

Cdigo:
Tipo:

RF5
USUARIO
12

Descripcin:

El sistema permitir al Usuario conocer informacin del

Programador.

Cdigo:
Tipo:
Descripcin:

RF6
USUARIO
El sistema permitir al Usuario realizar la cantidad de
intentos que desee tal, no le restringir el ingreso.

3.1.2. REQUERIMIENTOS DEL SISTEMA

Cdigo:
Tipo:
Descripcin:
Entradas:
Salidas:

RS1
SISTEMA
Para el desarrollo de este se utilizar : C & C++
-

3.1.3. REQUERIMIENTOS NO FUNCIONALES

Cdigo:
Tipo:
Descripcin:
Entradas:
Salidas:

Cdigo:
Tipo:
Descripcin:
Entradas:
Salidas:

RNF1
NO FUNCIONAL
Cada usuario del sistema tendr asignado un determinado
perfil, usado para activar los servicios u opciones que l
pueda realizar dentro del sistema.
-

RNF2
NO FUNCIONAL
El sistema deber tener una interfaz grfica sencilla y
amigable, basada en mens, ventanas, listas desplegables y
botones de accin.
-

13

Cdigo:
Tipo:
Descripcin:
Entradas:
Salidas:
Cdigo:
Tipo:
Descripcin:

Entradas:
Salidas:

RNF3
NO FUNCIONAL
La interfaz del sistema deber ser implementada como una
aplicacin de escritorio...
RNF4
NO FUNCIONAL
Cada usuario que desee ingresar al sistema, deber introducir
en la pgina principal con sus datos correspondientes
(nombre, cedula, edad, sexo,..) la cual ser validada por el
sistema, dndole acceso al sistema o envindole un mensaje
para que introduzca nuevamente sus datos.
-

Cdigo:
Tipo:
Descripcin:

RNF5
NO FUNCIONAL
El sistema deber manejar la confidencialidad de los datos de
usuario.

Entradas:
Salidas:

3.3 Requisitos de desarrollo

El ciclo de vida elegido para desarrollar el producto ser el de desarrollo incremental, de
manera que se pueda incorporar fcilmente cambios, y nuevas funciones al sistema, as
como detectar errores en el mismo.
3.4 Requisitos tecnolgicos
Al ser un software de escritorio, se necesitara que la computadora en la que se utilice
tenga instalado: Codeblocks o Netbeans, como principales IDEs, y estos tengan instaladas
y agregadas las libreras de Mingw, GTK + 2.0.
4. APENDICES
DIAGRAMA DE CASOS DE USO

14

Fuente: Autor, Realizado en Visual Paradigm

DIAGRAMA DE CLASES
Estructura de Ventanas

15

Fuente: Autor, Realizado en Blue J

16