Documento de Requisitos de Software

ndice

1 INTRODUCCIN 3

1.1 PROPSITO 3
1.2 ALCANCES 3
1.3 DEFINICIONES, SIGLAS Y ABREVIATURAS 4
1.4 REFERENCIAS 5
1.5 VISIN GENERAL 5

2 DESCRIPCIN GENERAL 6

2.1 RELACIN CON PROYECTOS ACTUALES 6

2.2 RELACIN CON PROYECTOS PREDECESORES Y SUCESORES 6
2.3 FUNCIN Y PROPSITO 6
2.4 CONSIDERACIONES AMBIENTALES 6
2.5 RELACIN CON OTROS SISTEMAS 7
2.6 RESTRICCIONES GENERALES 7
2.7 DESCRIPCIN DEL MODELO 8
2.7.1 MODELO CONCEPTUAL 8
2.7.2 CASOS DE USO 9

3 REQUISITOS ESPECFICOS 10

3.1 REQUISITOS FUNCIONALES 10

3.1.1 REQUISITOS DE ENTRADA 10
3.1.2 REQUISITOS DE SALIDA 10
3.2 REQUISITOS DE RENDIMIENTO 12
3.3 REQUISITOS DE INTERFACES 12
3.4 REQUISITOS OPERACIONALES 12
3.5 REQUISITOS DE RECURSOS 13
3.6 REQUISITOS DE VERIFICACIN 13
3.7 REQUISITOS DE ACEPTACIN DE TESTS 13

1
3.8 REQUISITOS DE DOCUMENTACIN 13
3.9 REQUISITOS DE SEGURIDAD DE LA INFORMACIN 13
3.10 REQUISITOS DE TRANSPORTABILIDAD 13
3.11 REQUISITOS DE CALIDAD 13
3.12 REQUISITOS DE CONFIABILIDAD 13
3.13 REQUISITOS DE MANTENCIN 14
3.14 REQUISITOS DE SEGURIDAD DE LA OPERACIN 14

4 MATRIZ DE TRAZABILIDAD DE REQUISITOS DE USUARIOS V/S REQUISITOS

DE SOFTWARE 14

2
1 Introduccin

1.1 Propsito
El propsito de ste proyecto es el desarrollar un sistema de gestin sobre el
Workflow ya existente, desarrollado por la Escuela de Ingeniera de la Universidad de
Chile.

1.2 Alcances
Se desarrollar la primera etapa de un Sistema de Control de Gestin para un
Workflow actualmente en etapa de prueba dentro de la Escuela de Ingeniera de la
Universidad de Chile. Este sistema proveer las herramientas bsicas para la gestin de
personal y sus labores asociadas dentro del workflow.
El sistema debe ser modularizado, ya que debe ser integrado a sistemas ya en
funcionamiento en la Escuela de Ingeniera y a sistemas futuros.
Para esta etapa se defini como lmite la generacin de estadsticas bsicas y de
archivos CVS (formato de texto plano) para su posterior manejo en Excel, dejando para
etapas posteriores un anlisis de flujo de procesos y despliegue de estadsticas mediante
grficos, entre otras.

3
1.3 Definiciones, Siglas y abreviaturas

Browser o navegador: Aplicacin utilizada para navegar por el internet, y que despliega
las pginas tradas desde el servidor en la pantalla del computador del usuario.
CVS (Concurrent Version System): Este sistema permite mantener un control de las
versiones de desarrollo en un repositorio centralizado.
Cliente: Computador y programa computacional que solicita servicios a otro computador
en Internet, llamado servidor.
Familia: Conjunto de procesos que por alguna razn estn relacionados.
Instancia: Es la ejecucin particular de un proceso especfico la cual posee un perodo de
vigencia. Ejemplo: Proceso de Inscripcin Acadmica 2002
MS: Microsoft, compaa proveedora de Software y Sistemas operativos.
MSIE: Microsoft Internet Explorer, browser estandar de la plataforma Windows.
Orden: Requerimiento de un cliente para una instancia determinada.
Pgina Web: Documento del web con informacin (texto, imgenes, video, audio, etc.)
que se presenta en una misma pantalla. Una pgina Web est en un servidor Web, y es
trada al computador del usuario para visualizarla.
PHP: Lenguaje que interacta con el usuario y la base de datos para trabajar en pginas
web.
Procesos: Conjunto de tareas, eventos ordenados. Es importante sealar que un proceso
posee muchas instancias.
Servidor: Computador y programa computacional que brinda los servicios solicitados por
otro computador llamado cliente.
Tarea: Procedimiento o evento a realizar por un colaborador.
Tarea Activa: Tarea tomada por un colaborador desde el repositorio y que todava no se
resuelve.
Tarea Delegada: Tarea tomada por un colaborador y devuelta por el mismo al repositorio.
Tarea Pendiente: Tarea que todava est en el repositorio.
Tarea Terminada: Tarea finalizada.
Tarea Zombie: Tarea que, una vez creada, nunca ser realizada y que ha sido terminada
por otra ruta.

4
1.4 Referencias

Este SRD hace referencias al URD desarrollado con anterioridad y est

confeccionado de acuerdo a la norma PSS-05 de la ESA para generacin de SRD.
Documento histrico del workflow desarrollado para la Facultad de Ciencias
Fsicas y Matemticas de la Universidad de Chile.
Facilitador de tareas (PHD, Project History Document)

1.5 Visin general

Este proyecto se enmarca dentro del conjunto de herramientas de apoyo a los

servicios que entrega la Escuela de Ingeniera a sus alumnos.

5
2 Descripcin General

2.1 Relacin con proyectos actuales

Desde el punto de vista del desarrollo, no existe relacin directa con proyectos
actuales y slo debe verificarse consistencia en caso de incorporacin o mejoras de
funcionalidades propias del workflow.

2.2 Relacin con proyectos predecesores y sucesores

Este proyecto se relaciona con el software workflow desarrollado por la Facultad

de Cs. Fsicas y Matemticas. La relacin est dada a travs de los procesos y tareas que
ejecuta el workflow, ya que el software a desarrollar realizar una gestin sobre ellos.

2.3 Funcin y propsito

Desarrollar un anexo al software preexistente de workflow, que posee la Facultad

de Ciencias Fsicas y Matemticas, tal que permita llevar registros de los procesos y
tareas que en l se estn ejecutando. De esta manera, se puede llevar una gestin de los
procesos en su conjunto y permite tomar decisiones, es decir, que son utilizadas como
herramientas de gestin para la toma de decisiones.

2.4 Consideraciones ambientales

El sistema debera estar diseado para funcionar en cualquier computadora que tenga
acceso a Internet mediante un browser. Por ello el sistema debera funcionar en:

Konqueror 2.0 o superior.

Netscape 4.0 o superior.

Internet Explorer 4.0 o superior.

6
2.5 Relacin con otros sistemas

El sistema comparte el acceso a la base de datos del workflow, razn por la cual,
cualquier elemento nuevo que se incorpore a ella debe mantener la consistencia con el
modelo lgico existente.

2.6 Restricciones generales

Tiempo mximo de desarrollo del software:10 semanas.

Versiones de Browser: siempre debe verse en Konqueror 2.0 o superior, browser
estndar del ambiente de escritorio KDE.
Deber acoplarse a un sistema de seguridad que valide y aplique restricciones a los
usuarios. Este sistema de seguridad ser desarrollado por otro equipo de trabajo en
conjunto con el cliente.

7
2.7 Descripcin del modelo

2.7.1 Modelo conceptual

Colaborador

Servidor
HTML
PHP
Admin
HTML

SQL
Sistema
HTML
Supervisor
BD

El sistema ser capaz de generar estadsticas de los procesos que maneja el workflow.
Las estadsticas se calcularn usando una API que permitir consultar la BD y calcular las
variables de inters.

Existir un usuario cliente genrico, y tres hijos que heredarn su estructura bsica,
admin., colaborador y supervisor. Este ltimo tendr dos hijos, uno para el encargado de
supervisar procesos y el otro encargado de supervisar familias. La estructura de herencia
se puede apreciar claramente en la figura de abajo que muestra los actores y casos de
uso. Los clientes sern los actores encargados de consultar las estadsticas del sistema.

8
2.7.2 Casos de uso

A continuacin se detallan las funcionalidades del sistema en base a actores y casos de

uso.

9
3 Requisitos especficos

3.1 Requisitos funcionales

3.1.1 Requisitos de Entrada

SR101: El sistema deber ser construido sobre el Workflow.
Prioridad : Alta.
Autoridad: Entrevista con Cliente.

SR102: La informacin entregada por el usuario debe ser obtenida a travs de formularios
HTML.
Prioridad : Alta.
Autoridad: Entrevista con Cliente.

SR103: Se debe crear un sistema de perfiles que permita asociar funcionalidades y

privilegios a cada usuario de acuerdo al rol que tenga dentro del sistema.
Prioridad : Alta.
Autoridad: Entrevista con Cliente.

3.1.2 Requisitos de Salida

SR104: Toda la informacin entregada por el sistema debe ser presentada al usuario en
formato HTML.
Prioridad : Alta.
Autoridad: Entrevista con Cliente.

SR105: Deber existir una funcin capaz de convertir la informacin estadstica resultante
a formato CVS, compatible con MS Excel.
Prioridad : Alta.
Autoridad: Entrevista con Cliente.

10
SR106: El sistema deber tener algunas funciones que calculen:
Los tiempos estimados por tarea.
Los tiempos reales por tarea.
Eficiencia del sistema por tarea.
Prioridad : Alta.
Autoridad: Entrevista con Cliente.

SR107: El sistema deber tener algunas funciones que calculen:

Los tiempos estimados por orden.
Los tiempos reales por orden.
Eficiencia del sistema por orden.
Identificacin de los peores casos.
Prioridad : Alta.
Autoridad: Entrevista con Cliente.

SR108: El sistema deber tener algunas funciones que calculen:

Los tiempos estimados por proceso.
Los tiempos reales por proceso.
Eficiencia del sistema por proceso.
Prioridad : Baja.
Autoridad: Entrevista con Cliente.

SR109: El sistema deber tener algunas funciones que calculen:

Los tiempos estimados por familia.
Los tiempos reales por familia.
Eficiencia del sistema por familia.
Prioridad : Baja.
Autoridad: Entrevista con Cliente.

11
3.2 Requisitos de rendimiento

No existen requisitos de rendimientos.

3.3 Requisitos de interfaces

SR301: El idioma en que deben ser escritas todas las salidas del sistema deber ser
espaol.
Prioridad : Alta.
Autoridad: Entrevista con Cliente.

SR302: El diseo de la interfaz debe reconocer eventos de mouse y/o teclado para la
navegacin del sistema.
Prioridad : Alta.
Autoridad: Entrevista con Cliente.

SR303: El cdigo HTML generado en el servidor mediante PHP deber cumplir con el
estndar HTML 4.0, adems de estar escrito en forma estricta, de tal forma que sea
correctamente interpretado por Konqueror 2.0 o superior.
Prioridad : Alta.
Autoridad: Entrevista con Cliente.

SR304: El diseo del sistema debe ser modularizado.

Prioridad : Alta.
Autoridad: Entrevista con Cliente.

3.4 Requisitos operacionales

No existen requisitos operacionales.

12
3.5 Requisitos de recursos
SR501: El tiempo disponible para la realizacin del proyecto termina el mes de Junio del
ao 2002.
Prioridad: Alta.
Autoridad: Entrevista con Cliente y nosotros.

3.6 Requisitos de verificacin

No existen requisitos de verificacin.

3.7 Requisitos de aceptacin de tests

No existen requisitos de aceptacin de test.

3.8 Requisitos de documentacin

No existen requisitos de documentacin.

3.9 Requisitos de seguridad de la informacin

SR901: El software debe contar con un sistema de autenticacin de usuarios a travs de:
Una identificacin de usuario correspondiente al RUT .
Un password.
Prioridad : Media.
Autoridad: Entrevista con Cliente.

3.10 Requisitos de transportabilidad

No existen requisitos de transportabilidad.

3.11 Requisitos de calidad

SR1101: Todas las pginas debern mantener el mismo patrn, en cuanto a fondo y
opciones similares.
Prioridad : Baja.
Autoridad: Entrevista con Cliente.

13
 3.12 Requisitos de confiabilidad
No existen requisitos de confiabilidad.

3.13 Requisitos de mantencin

No existen requisitos de mantencin

3.14 Requisitos de seguridad de la operacin

No existen requisitos de seguridad en la operacin.

4 Matriz de trazabilidad de requisitos de usuarios v/s requisitos

de software

SR SR SR SR SR SR SR SR SR SR SR SR SR SR SR SR
101 102 103 104 105 106 107 108 109 301 302 303 304 501 901 1101
UR101
UR102
UR103
UR201
UR202
UR203
UR204
UR205
UR206
UR301
UR302
UR303
UR304
UR305
UR902

14