plantilla-R

Sistema PROVEUNA Versión: 1.1Especificación de Requerimientos Fecha: 25/04 /2011

Especificación de Requerimientos Funcionales y

No Funcionales

“Proyecto PROVEUNA”

Integrantes del GrupoTatiana delgado Zúñiga.

Steven Díaz Gómez.Maikol fajardo Gómez.

Fecha25/04/2011.

1


Historia de Revisión

Fecha Versión Descripción Autor

25/04/2011 1.1 Actualización de requerimientos

Equipo de trabajo.

20/04/2011 1.0 Estructuración documento de requerimientos

Maikol Fajardo

2


ContenidoHistoria de Revisión..........................................................................................................21. Introducción...................................................................................................................4

1.1. Propósito.........................................................................................................41.2. Alcance del Documento......................................................................................41.3. Glosario...............................................................................................................41.4. Conceptos............................................................................................................5

2. Requerimientos Funcionales.........................................................................................52.1. Modulo Solicitud.................................................................................................52.2. Modulo Usuarios.................................................................................................62.3. Modulo Proveedores Externos............................................................................72.4. Modulo Requisición............................................................................................82.5. Modulo Inventario...............................................................................................92.6. Modulo Devoluciones.......................................................................................102.7. Modulo Informes...............................................................................................11

3. Requerimientos No Funcionales:................................................................113.1. Usabilidad.............................................................................................................113.2 Confiabilidad y seguridad......................................................................................123.3. Requerimientos de espacio...................................................................................133.4. Portabilidad...........................................................................................................133.5. Eficiencia y rendimiento.......................................................................................143.6. Mantenimiento y soportabilidad..........................................................................153.7. Requerimientos de entrega...................................................................................153.8. Propiedades del diseño.........................................................................................163.9. Interfaces..............................................................................................................173.10. Requerimientos de Licenciamiento....................................................................17

3


1. Introducción.

1.1. Propósito.

Aunque este departamento lleva muchos años en marcha y hasta

ahora no ha surgido ningún problema grave en la gestión, se pretende

desarrollar un sistema que permita mejorar diferentes actividades y

procesos de la organización. El propósito de este documento es

detectar las necesidades reales del área de proveeduría de la UNA

sede Chorotega y a la vez mostrar las especificaciones de los

Requerimientos en forma narrativa del Sistema PROVEUNA,

específicamente para los Módulos Cliente, Proveeduría y

Mantenimiento y para el entendimiento de los involucrados y el usuario

final, no necesariamente informático.

Los Requerimientos a presentar en este documento son:

Requerimientos Funcionales, que se identificarán con las siglas RF,

como los Requerimientos No Funcionales, que se identificarán con las

siglas RNF.

1.2. Alcance del Documento.

El alcance es definir con exactitud todas los Requerimientos

Funcionales (especificaciones suplementarias) y los No

Funcionales, como: limitaciones, restricciones y otros factores que

permitan un mayor entendimiento y compresión, necesarios para una

exitosa ejecución del proyecto.

1.3. Glosario. RF##: Siglas para identificar los Requerimientos Funcionales, seguidos por

un número secuencial de la lista de requerimientos que se está levantando,

con el propósito de identificarlos y hacer referencia en documentos

posteriores, como los Casos de Uso.

4


RNF##: Siglas para identificar los Requerimientos No Funcionales, seguidos

de número secuencial de la lista de requerimientos, con el propósito de

identificarlos y hacer referencia en documentos posteriores.

1.4. Conceptos.

Requerimientos: Atributo necesario dentro de un sistema, que puede

representar una capacidad, una característica o un factor de calidad

del sistema solicitado. Es el descubrimiento de las actividades

involucradas, para dar solución a un producto terminado.

2. Requerimientos Funcionales.

El resultado de realizar esta primera etapa de análisis del sistema, ha

sido la siguiente lista de funcionalidades.

1.5. Modulo SolicitudRF001: El coordinador de cada departamento y el encargado de

proveeduría podrán crear desde una computadora solicitudes de

materiales al departamento de proveeduría.

Los datos que se deberán conservar por cada solicitud son:

Articulo

Cantidad

Código

Fecha solicitud

Solicitante

Numero de solicitud.

Prioridad Alta.

RF002: El encargado de proveeduría podrá eliminar desde una

computadora solicitudes de materiales realizadas al departamento de

proveeduría. Prioridad Alta.

RF003: El coordinador de cada departamento y el encargado de

proveeduría podrán consultar desde una computadora solicitudes de

materiales realizadas al departamento de proveeduría.

5


Los datos que se deberán visualizar sobre las solicitudes son:

Numero de solicitud.

Fecha solicitud

Estado

Departamento

Además por cada solicitud se podrá visualizar respectivamente:

Código

Descripción

Cantidad pedida

Cantidad entregada

Prioridad Alta.

RF004: El encargado de proveeduría podrá actualizar el estado de

una solicitud realizada al departamento de proveeduría.

Los estados que puede presentar una solicitud son:

Entregada: este estado significa que el encargado de

proveeduría ha actualizado el inventario al disminuir los

artículos ya entregados. El encargado podrá imprimir la

respectiva boleta que certifica la entrega de los materiales, la

cual deberá ser firmada por el coordinador del departamento.

Cancelada: para poder realizar este cambio de estado el

coordinador de departamento debe de informar sobre la

cancelación de la solicitud.

En proceso: la solicitud refleja que los artículos no han sido

disminuidos del inventario hasta su posterior entrega.

Prioridad Alta.

1.6. Modulo UsuariosRF005: El administrador del sistema podrá desde una computadora

crear usuarios, con sus respectivos privilegios, para cada

departamento de la universidad. Cada uno de los coordinadores de

los departamentos de la universidad representa un usuario diferente

del sistema, por lo que debe de existir solamente un usuario para

cada departamento.

Los datos que se deberán conservar por cada usuario son:

6


Departamento

Nombre completo

Teléfono

E-mail

Usuario

Contraseña

Prioridad Alta.

RF006: El administrador del sistema podrá desde una computadora

eliminar los usuarios de cada departamento de la universidad.

Prioridad Alta.

RF007: El administrador del sistema y el coordinador de cada

departamento podrán desde una computadora actualizar los datos

de su usuario. Prioridad Alta.

RF008: El administrador del sistema, el coordinador de cada

departamento y el encargado de proveeduría podrán desde una

computadora consultar los datos de su usuario. Prioridad Alta.

1.7. Modulo Proveedores Externos.RF009: El encargado de proveeduría podrá desde una

computadora ingresar proveedores externos a la UNA Sede Regional

Chorotega. Los datos que se deberán conservar para cada proveedor

son:

Casa comercial

Nombre de proveedor completo

Bien o servicio suministrado

Dirección

Teléfono

E-mail

Prioridad Alta.

RF010: El encargado de proveeduría podrá desde una

computadora eliminar proveedores externos a la Universidad.

Prioridad Alta.

7


RF011: El encargado de proveeduría podrán desde una

computadora actualizar los datos de proveedores externos a la

Universidad. Prioridad Alta.

RF012: El encargado de proveeduría podrán desde una

computadora consultar los datos de proveedores externos de la

Universidad. Prioridad Alta.

1.8. Modulo RequisiciónRF013: El encargado de proveeduría podrá crear desde una

computadora las requisiciones de materiales.

Los datos que se deberán conservar por cada requisición solicitada

son:

Fecha de requisición

Número de requisición

Código

Descripción material

Cantidad material

Prioridad Alta.


computadora requisiciones de materiales realizadas. Prioridad Alta.

RF015: El encargado de proveeduría podrá consultar desde una

computadora las requisiciones de materiales realizadas.

Los datos que se deberán visualizar sobre las requisiciones son:

Numero de requisición.

Fecha solicitud requisición.

Estado

Además por cada requisición se podrá visualizar respectivamente:

Código producto

Descripción

Cantidad solicitada

Prioridad Alta.

RF016: El encargado de proveeduría podrá actualizar el estado de

una requisición realizada. Este estado puede ser cambiado según la

8


fecha de ingreso de los materiales y el número de requisición

correspondiente.

Los estados que puede presentar una requisición son:

Recibida: representa que el pedido realizado fue recibido

completamente.

Pendiente: representa que no se ha recibido el pedido

completo.

En proceso: los materiales aún no se han recibido.

Prioridad Alta.

1.9. Modulo InventarioRF017: El encargado de proveeduría podrá crear artículos en el

inventario desde una computadora.

Los datos que se deberán conservar cuando se crea un artículo nuevo

en el inventario son:

Código

Descripción

Cantidad minimiza

Cantidad máxima

Prioridad Alta.

RF018: El encargado de proveeduría podrá ingresar artículos en el

inventario desde una computadora.

Los datos que se deberán conservar cuando se ingresa un artículo al

inventario son:

Número requisición

Fecha de ingreso

Código

Descripción

Cantidad

Precio unitario

Fecha vencimiento

Prioridad Alta.

9



computadora artículos del inventario, esta acción debe de ser

acompañada de su respectiva nota, la cual debe de aclarar el motivo

de la baja del artículo.

Los datos que se deberán conservar por cada baja de materiales son:

Código

Descripción

Cantidad

Fecha de baja

Nota

Prioridad Alta.

RF020: El encargado de proveeduría podrá consultar desde una

computadora el inventario de Los datos que se deberán visualizar

sobre el inventario son:

Código

Descripción

Cantidad mínima

Cantidad máxima

Cantidad disponible

Prioridad Alta.

1.10. Modulo DevolucionesRF021: El encargado de proveeduría podrá crear una devolución de

materiales, los artículos devueltos serán incluidos nuevamente en el

inventario. Esta acción debe de ser acompañada de su respectiva

nota, la cual debe de aclarar el motivo de la devolución del artículo.

Los datos que se deberán conservar por cada devolución de

materiales son:

Código

Descripción

Cantidad devuelta

Fecha de devolución

Nota

Prioridad Alta.

10


RF022: El encargado de proveeduría podrá desde una

computadora consultar los datos de las devoluciones realizadas al

departamento de proveeduría. Prioridad Alta.

1.11. Modulo InformesRF023: El encargado de proveeduría podrá desde una

computadora visualizar los datos referentes al costo total del

inventario con el que dispone la UNA sede regional chorotega.

Los datos que se deberán visualizar sobre el inventario son:

Descripción

Cantidad existente

Costo total de artículos

Prioridad Alta.

3. Requerimientos No Funcionales:

Los requerimientos no funcionales de software para una aplicación de

sistemas, establecen restricciones sobre el software y sobre los

requerimientos funcionales.

Los requerimientos no funcionales establecen el conjunto de

cualidades y atributos necesarios para el sistema resultante.

Notación: Para la captura de los Requerimientos No Funcionales,

utilizar la siguiente nomenclatura: RNF##

3.1. Usabilidad

RNF01: El interfaz del sistema deberá ser sencillo de usar, amigable con el

usuario y sobre todo intuitiva, con el fin de facilitar su utilización, de forma

que el usuario pueda manejarla fluidamente después de un par de sesiones.

RNF02: El interfaz del sistema deberá facilitar el control de errores

habilitando o deshabilitando opciones según el uso que este haga del

mismo o pidiendo confirmaciones para acciones críticas (identificación y

envío de mensajes de error, deshacer, rehacer).

11


RNF03: Los usuarios deben ser capaces de realizar tareas comunes con el

mínimo esfuerzo razonable. Utilizando uno o dos pasos y considerando

minimizar la dificultad de cada paso.

RNF04: La interfaz del sistema deberá facilitar una respuesta efectiva al

usuario, en la ejecución de todas sus funciones.

3.2 Confiabilidad y seguridad.

RNF05: El sistema deberá contar con autorizaciones de seguridad en cada

servidor asignado.

RNF07: La identificación de los usuarios estará vinculada con la

autentificación del sistema operativo.

RNF09: La autenticación de usuarios que interactúan con el sistema se

realizará por medio de un password.

RNF10: El sistema garantizará que la información será vista únicamente

por el usuario que tiene derecho de acuerdo a su Rol.

3.3. Requerimientos de espacio.

RNF12: Los servidores estarán ubicados en el Centro de Cómputo.

RNF13: El sistema deberá de contar con un servidor de 250 Gigabytes

como mínimo, para el servidor de aplicaciones.

RNF14: El sistema deberá contar con un servidor de 10 Gigabytes para el

Motor de Base de Datos.

RNF15: El sistema deberá contar con un servidor de 10 Gigabytes, para almacenar la capa del negocio.

3.4. Portabilidad.

12


Ejemplos:

RNF016: El sistema deberá ser diseñado de tal manera que pueda ser

instalado en cualquiera de las la Sedes de la Universidad Nacional.

RNF017: El sistema podrá ser levantado en sistemas operativos existentes

en Centro de cómputo.

RNF018: El sistema podrá acceder a Base de datos existente en el Centro

de Cómputo.

RNF019: Las páginas del sistema podrán desplegarse con los Browser:

Mozilla Firefox, Internet explorer y Google Chrome.

3.5. Eficiencia y rendimiento.

RNF20: El sistema deberá estar disponible y funcionando durante los 7 días de la semana En caso de una falla, habrá un encargado de soporte para mantenimiento (Encargado de Centro de cómputo) que estará capacitado para resolver cualquier problema que se presente.

RNF21: Los tiempos críticos podrían ser de 8:00 am a 5:00 pm durante los (7 días, 12 meses, 365 al año) en el cuál el sistema no podrá fallar.

RNF23: Para los accesos simultáneos por usuarios múltiples, la base de datos deberá estar libre de carreras o bloqueos.

RNF24: El tiempo de respuesta para el cliente deberá ser máximo de 45

segundos para cada transacción, esto sujeto a la capacidad de los equipos

existentes.

RNF25: Se debe contar con una velocidad de conexión de por lo menos 100

Kbits por segundo.

3.6. Mantenimiento y soportabilidad.

13


RNF26: En el desarrollo se hará uso de las convenciones para el código

(estándares de código), definición de clases y demás características

recomendadas por los estándares como: referenciar a la documentación.

RNF27: Durante la vida útil del sistema se deberá realizar los respaldos se

harán cada semana, el sistema deberá permanecer actualizado para hacer

los respaldos. Referencia las estrategias de Respaldos.

3.7. Requerimientos de entrega.

RNF29: La documentación técnica se entregará en formato digital.

RNF30: La documentación técnica será aprobada por Edgar Vega Briceño.

La revisión deberá realizarse durante los 30 días hábiles contados a partir

de la fecha de entrega.

RNF31: El manual de usuario se entregará en formato digital.

RNF32: El manual de usuario será revisado por Edgar Vega Briceño, Ivannia

Montero Robles, Raquel Baltodano y aprobado por Ivannia Montero Robles.

La revisión deberá realizarse durante los 15 días hábiles contados a partir

de la fecha de entrega.

RNF35: La computadora cliente deberá tener el siguiente sistema operativo

(Windows xp) o superior y el tipo de navegador de internet.

RNF36: Con respecto a la impresión de reportes se deberá disponer de

impresoras laser o a chorro de tinta.

RNF37: Con respecto a la comunicación, se dispondrá de: una red TCP/IP para comunicar los clientes con el servidor de al menos 10 Mbps

3.8. Propiedades del diseño.

Ejemplos:

14


RNF038: Desarrollado con Microsoft Visual Studio .NET 2008.

RNF039: Desarrollado con una arquitectura de 3 capas

RNF040: Implementado para que trabaje con SQL Server 2008

RNF041: Utilización de herramientas web para desarrollar ayudas en línea

en formato ASP.

RNF042: Implementarse bajo la metodología Proceso unificado para

Desarrollo de Software, con los siguientes estándares en cuanto a

documentación: , procedimientos, plantillas, diagramas (modelado del

negocio, especificación de requerimientos, Casos de Uso, diagramas y otros

manuales en versiones actualizadas generadas en Gestión de Proyectos.

3.9. Interfaces.

RNF43: La interfaz de usuario deberá ser implementada en ambiente

Windows XP.

RNF44: Interfaces de hardware

RNF45: Interfaces de software

RNF46: Interfaces de comunicación

3.10. Requerimientos de Licenciamiento.

< En esta sección se debe definir la adquisición de posibles licencias o

necesidad de herramientas de desarrollo, así como herramientas de

certificación del sitio web, BD, S.O., Browser y otros.>

RNF049: (…)

15

plantilla-R

Documents

Transcript of plantilla-R