INSTITUTO DE ESTUDIOS SUPERIORES DE
OAXACA
ESPECIFICACION DE
REQUISITOS DE
SOFTWARE
PROFESOR: LUDWIG BARCELOS
MENDOZA
MATERIA:INGENIERIA DE SOFTWARE
ALUMNOS: BOHORQUEZ GASPAR LUIS URIEL
KEVIN EDUARDO GARCIA
MARTINEZ
RICARDO VARGAS NAVA
FICHA DEL DOCUMENTO
FECHA
REVISION
AUTOR
11/11/14
1.0
EQUIPO DE
DESARROLLO
POR EL CLIENTE
VERIFICADO DEP.
CALIDAD
POR LA EMPRESA SUMINISTRADORA
SS STUDIO
MAESTRO LUDWIG BARCELOS
MENDOZA
ING. KEVIN EDUARDO GARCIA
MARTINEZ
INDICE
1 INTRODUCCION................................................................................................ 4
1.1PROPOSITO................................................................................................. 4
1.2 ALCANCE.................................................................................................... 4
1.3 PERSONAL INVOLUCRADO..........................................................................4
2 DESCRIPCION GENERAL................................................................................... 5
2.1 PERSPECTIVA DEL PRODUCTO...................................................................5
2.2 FUNCIONALIDAD DEL PRODUCTOS............................................................5
2.3 CARACTERISTICAS DE LOS USUARIOS........................................................6
2.4 RESTRICCIONES......................................................................................... 6
2.5 EVOLUCION PREVISIBLE DEL SISTEMA.......................................................6
5
3 Requisitos especficos...................................................................................... 6
3.1 requisitos comunes de las interfaces.........................................................8
3.1.1 interfaces de usuario...........................................................................8
3.1.2 interfaces de hardware........................................................................8
3.2 requisitos funcionales................................................................................ 8
3.2.1 requisito funcional 1............................................................................ 8
3.2.2 requisito funcional 2............................................................................ 9
3.2.3 requisito funcional 3............................................................................ 9
3.2.4 requisito funcional 4............................................................................ 9
6
3.2.5 requisito funcional 5............................................................................ 9
3.2.6 requisito funcional 6............................................................................ 9
3.2.7 requisito funcional 7............................................................................ 9
3.3 Requisitos no funcionales..........................................................................9
3.3.1 Requisitos de rendimiento...................................................................9
3.3.2 Seguridad.......................................................................................... 10
3.3.3 Fiabilidad........................................................................................... 10
3.3.4 Disponibilidad.................................................................................... 10
3.3.5 Mantenibilidad................................................................................... 10
7
3.3.6 Portabilidad........................................................................................ 11
3.4 Definiciones............................................................................................ 11
3.5 Referencias.............................................................................................. 12
3.6 Resumen.................................................................................................. 12
10
11
1 INTRODUCCION
En este documento se mostraran los requerimientos el sistema para el
monitoreo del transporte pblico de Oaxaca, el cual llevara el control de
las horas de salida de los autobuses, sus rutas y sus tiempos entre
paradas y traslados
12
1.1PROPOSITO
Este documento ha sido redactado con el fin de marcar las pautas
generales y las especificaciones que deber seguir el software a
desarrollar, con el objetivo final de resolver las necesidades que el
cliente ha planteado.
El objetivo de este documento es proporcionar la informacin necesaria
para controlar el proyecto. En este se describirn las especificaciones
funcionales y no funcionales el cual se utilizan para gestionar los
procesos administrativos.
13
1.2 ALCANCE
Se ha constatado la necesidad crear un sistema para el monitoreo del
transporte pblico de Oaxaca, en base a nuevos requerimientos
propuestos por el equipo de SS STUDIO, este documento se har con el
propsito de que la empresa, el personal involucrado pueda ver
informacin detallada y completa a estos mismos.
La informacin que se podr obtener de este documento son las
siguientes:
14
Informacin de la empresa
Descripcin del sistema
El personal involucrado en el sistema
Caractersticas del sistema
Definiciones y acrnimos
1.3 PERSONAL INVOLUCRADO
Nombre
Rol
Categora Profesional
Cristbal carrera carrera
Documentador
Ingeniero
en
computacionales
sistemas
15
Responsabilidad
Informacin de contacto
Aprobacin
Documentacin
general
del
proyecto, revisin del anlisis del
sistema
e-mail:[email protected]
cel:9512515112
Aprobado
16
Nombre
Rol
Categora profesional
Responsabilidad
Informacin de contacto
Aprobacin
Kevin
Programador
Ing. En sistemas computaciones
Revisin
de
Anlisis
y
especificacin de requerimientos,
desarrollo del sistema
Correo: [email protected]
cel:9512557114
Aprobado
17
Nombre
Rol
Categora profesional
Responsabilidad
Informacin de contacto
Aprobacin
julio
Programador
Ing. En sistemas computaciones
Revisin
de
Anlisis
y
especificacin de requerimientos,
desarrollo del sistema
Correo: [email protected]
cel:
Aprobado
18
Nombre
Rol
Categora profesional
Responsabilidad
Informacin de contacto
Aprobacin
julio
Analista
Ing. En sistemas computacionales
Diseo de la arquitectura del
sistema
Correo:
cel:
Aprobado
Nombre
Rol
Kevin Eduardo Garca Martnez
Lder del proyecto
19
Categora profesional
Responsabilidad
Informacin de contacto
Aprobacin
Nombre
Rol
Categora profesional
Responsabilidad
Ing. En sistemas computacionales
Administrar el proyecto en todas
las reas, y responsabilidades.
Correo:
cel:
Aprobado
Ludwig Barcelos Mendoza
Cliente
Administrador del Hospital
Administrar el hospital y llevar un
buen control de este
20
Informacin de contacto
Aprobacin
Correo:[email protected]
m
cel:
Aprobado
2 DESCRIPCION GENERAL
El sistema que se desarrollada es independiente de otros sistemas se
implementara localmente, tendr un diseo modular, este mismo
abarcara una rea de la empresa, se especializara en el rea de
consultas.
21
2.1 PERSPECTIVA DEL PRODUCTO
El sistema ser diseado para llevar el monitoreo del transporte pblico de
Oaxaca con el fin de mantener un control y brindar informacin a los usuarios
de este
2.2 FUNCIONALIDAD DEL PRODUCTOS
Las funciones principales que el sistema debe realizar son las siguientes:
Mostrar el horario de las rutas
Mostrar el tiempo entre paradas
Mostrar el tiempo total de un traslado
22
Brindar rutas alternas en caso de que no estn disponibles las
originales
2.3 CARACTERISTICAS DE LOS USUARIOS
Tipo de usuario
Formacin
Actividades
Usuario
------------------------------------------------------Consultar los horarios y rutas del
transporte publico
23
Tipo de usuario
Formacin
Actividad
Administrador
Ingeniero o Licenciado
Tendr acceso para modificar las
rutas del transporte
24
2.4 RESTRICCIONES
El sistema se desarrollada en el lenguaje de programacin, HTML, PHP,
JAVASCRIPT, este estar conectado con una base datos y lenguaje sql.
Los mtodos que se implementaran ya se encuentran especificados,
estos se recopilaron de una entrevista ya hecha con el cliente.
2.5 EVOLUCION PREVISIBLE DEL SISTEMA
Futuras mejoras del producto:
se podr adaptar a aplicacin mvil
25
3 Requisitos especficos
Numero de requisito
Nombre de requisito
Fuente del requisito
Prioridad del requisito
1
Autentificacin de usuario
administrador
Alta/Esencial
Media/Deseado
Baja/Opcional
Numero de requisito
Nombre de requisito
Fuente del requisito
2
Crear ruta
Administrador
26
Prioridad del requisito
Alta/Esencial
Baja/Opcional
Numero de requisito
Nombre de requisito
Fuente del requisito
Prioridad del requisito
3
Eliminar de ruta
Administrador
Alta/Esencial
Baja/Opcional
Numero de requisito
Media/Deseado
Media/Deseado
27
Nombre de requisito
Fuente del requisito
Prioridad del requisito
Habilitar ruta
Administrador
Alta/Esencial
Baja/Opcional
Numero de requisito
Nombre de requisito
Fuente del requisito
5
Deshabilitar ruta
Administrador
Media/Deseado
28
Prioridad del requisito
Alta/Esencial
Baja/Opcional
Numero de requisito
Nombre de requisito
Fuente del requisito
Prioridad del requisito
6
Modificar ruta
Administrador
Alta/Esencial
Baja/Opcional
Media/Deseado
Media/Deseado
29
Numero de requisito
Nombre de requisito
Fuente del requisito
Prioridad del requisito
7
Consultar ruta
Usuario
Alta/Esencial
Baja/Opcional
Media/Deseado
30
3.1 requisitos comunes de las interfaces
1. interface de confirmacin y cancelacin (ventana emergente o por
botones al final de cada ventana)
3.1.1 interfaces de usuario
Se requiere que la interface sea intuitiva al usuario con texto fcil
de entender y
con botones agiles, que permitan realizar
31
acciones a travs del mismo (eventos de accin) tales como el
inicio de sesin de administrador y la realizacin de consultas
El estilo de las ventanas estar sujeta a los gustos del cliente, no
excediendo las capacidades graficas del equipo desarrollador.
3.1.2 interfaces de hardware
Debido a las especificaciones del cliente el sistema ser
implementado para el uso en computadoras, por tanto el posible
sistema a utilizar ser Windows, ya sea la versin seven ultmate
o la versin ocho punto uno con una resolucin media de
32
(800x1600), RAM mnima de 4gb expandible a 12gb. Disco duro
1TB con posibilidad de agregar un Raid de 3 iguales. Red Ethernet
3.2 requisitos funcionales
3.2.1 requisito funcional 1
Comprobar las entradas y las salidas de los administradores
(logins, passwords)
Establece el ingreso del o los administradores
33
3.2.2 requisito funcional 2
El administrador o administradores sern los nicos que podrn
crear nuevas rutas
3.2.3 requisito funcional 3
El administrador o administradores sern lo que podrn eliminar
una ruta si es necesario
34
3.2.4 requisito funcional 4
El administrador o administradores podrn habilitar de nuevo una
ruta en caso de que esta est deshabilitada
3.2.5 requisito funcional 5
El administrador o administradores podrn deshabilitar una ruta en
caso de que sea necesario
3.2.6 requisito funcional 6
El administrador o administradores podrn modificar los datos de
una ruta como su horario o los puntos por donde pasa
35
3.2.7 requisito funcional 7
Los usuarios una vez que ingresan a la pgina sern los que
podrn realizar las consultas necesaria para saber los horarios y
los sitios por donde pasan las rutas
3.3 Requisitos no funcionales
3.3.1 Requisitos de rendimiento.
Se planea que el sistema este diseado de manera que exista
cierta relacin entre los
diferentes actores involucrados, sin
embargo, tiene restricciones tambin, esta adecuado para que los
pacientes puedan checar su historial clnico desde cualquier
36
ordenador totalmente en tiempo real. Los diferentes doctores
podrn hacer referencias de sus pacientes a otros mdicos.
3.3.2 Seguridad.
Habr diferentes niveles de seguridad, en general todos cuentan
con un login y un password, el de mayor jerarqua ser siempre el o los
administradores del sistema, puesto que ellos sern quienes den de alta
a los mdicos participantes en el sistema, as mismo los doctores
tendrn que hacer su login, para poder recetar, ver historiales, hacer
reportes y referenciar a los pacientes que atiendan, y por ltimo los
37
pacientes solo podrn generar reportes que incluyen su historial mdico,
las recetas que se le han proporcionado y que mdicos los han tratado.
3.3.3 Fiabilidad.
Este sistema debe ser totalmente confiable y con un nulo margen de
error, puesto que se encarga del control de salud de pacientes, que si
hubiera algn incidente podra ser demasiado grave tanto para los
mdicos como para los propias pacientes, toda la informacin debe de
estar respaldada para evitar que se puedan extraviar todos los datos
relacionados con la salud de los pacientes, al igual la informacin debe
38
de estar disponible en cada momento tanto para los mdicos como para
los propios pacientes.
3.3.4 Disponibilidad.
La informacin como ya se menciono debe estar disponible en cualquier
momento para su consulta y modificacin, con una pequea tasa de
error del 0.05%. De este modo el sistema tiene que ser una
disponibilidad de 99.95%, ya que en cualquier momento el sistema
39
pueda requerir o se le puedan agregar ciertas modificaciones y algn
tipo de mantenimiento ya sea preventivo o correctivo.
3.3.5 Mantenibilidad.
Por el tipo de sistema y de informacin que se maneja deber tener un
mantenimiento constante cuatrimestral (cada 4 meses) especialmente
en la base de datos por lo importante de la informacin para asegurar la
fiabilidad de los reportes e informes obtenidos.
40
Se generaran reportes ms que nada a peticin de los doctores y
de los pacientes, pueden ser reportes diarios, semanales, mensuales
segn al usuario le convenga.
3.3.6 Portabilidad.
El sistema estar disponible para cualquier plataforma que utilice
un navegador y que tenga conexin con el servidor.
Los componentes sern totalmente dependientes del servidor esto
quiere decir en un 100%.
41
La aplicacin es nica, es decir, que no depende de otra aplicacin o
sistema para funcionar, se necesitara de una conexin a internet en
caso de que el paciente necesite conocer informacin suya y dicho
paciente quiera hacerlo desde un lugar fuera de la institucin mdica.
Para que la aplicacin funcione dentro de la institucin no es necesaria
una conexin a internet.
3.4 Definiciones
Sistema
Programa que se va a desarrollar
42
Actores
Lenguaje de programacin
Base de datos
Autentificacin de usuario
en este caso el sistema de
monitoreo de transporte publico de
Oaxaca
Personas que van a interactuar con
el
sistema
(usuarios
,
administradores)
Es el lenguaje en que se
desarrollara el sistema.
Es el lugar donde se registraran
todos los datos de las rutas.
Se refiere a la accin que los
43
Interface
Cliente
Usuario
usuarios realizan al momento de
acceder al sistema mediante el
login y password
Son las ventanas con las diferentes
opciones que tiene el sistema.
Persona que solicita el sistema.
Persona que utilizara el sistema.
44
3.5 Referencias
Refere
Ttulo
Ruta
ncia
1
Ing. Del
software
7ma
edicin
2
Especifica http://www.ctr.unican.es/asignatur
ciones de as/list1/IEEE830_esp.pdf
requisitos
del
Fecha
Autor
2004
Ian
Somme
rville
1998
IEEE
45
software
3.6 Resumen.
Este documento cuenta con tres secciones que lo componen. En la
primera de las tres partes, se hace nfasis del proyecto, se proporciona
una introduccin del sistema y las funciones que pretende abarcar de
manera muy general, cual es el propsito se expresan las condiciones,
responsabilidades y los roles de los participantes del proyecto.
En la parte dos de este documento se habla ms especficamente
del sistema, de las funciones especficas que se quieren satisfacer para
46
el cliente, cuales son las perspectivas, los tipos de usuarios y como se
van a desenvolver en el sistema, as como restricciones, suposiciones y
las evoluciones que va a tener el sistema durante su utilizacin y vida
til.
Y por ltimo en la tercera parte de este documento se detallan
minuciosamente los requisitos planteados por el cliente y que deben de
ser cumplidas por el equipo de trabajo, as tambin se hace mencin de
los trminos empleados en el documento y las referencias en las que se
apoy dicho proyecto.
47
