Agenda Web Solicitudes de Requerimientos de Software Versión 1.0
Información del Documento Título del Documento: Nombre del archivo del Documento: Número de Revisión: Creado por: Fecha de Creación: Estado: Solicitud de requerimientos de Agenda Web SRS-Agenda_Web RV-SRS-001 Fernando Espinoza Becerra 19/noviembre/2005 Aprobado Tabla de Contenidos 1 INTRODUCCIÓN... 1.1 Propósito 1.2 Definiciones, Acrónimos y Abreviaturas 1.3 Audiencia 1.4 Alcance 1.5 Descripción General del resto del documento 2 DESCRIPCIÓN DEL REQUERIMIENTO... 2.1 Tipo de Requerimiento 2.2 Versión del Requerimiento 2.3 Clave del Requerimiento 2.4 Información Principal 2.5 Información Complementaria 1 Introducción Estándar de Solicitud de Requerimientos Funcionales 1.1 Propósito La Solicitud de Requerimientos de Software, tiene el propósito de recabar las necesidades del cliente. 1.2 Definiciones, Acrónimos y Abreviaturas SRS: Solicitud de Requerimientos de Software BES: Borland Enterprise Server 1.3 Audiencia UD: Usuario directo UI: Usuario indirecto
1.4 Alcance Capturar la nueva y/o modificación información de los clientes, en cual posteriormente servirá para generar consultas y reportes sobre el comportamiento de los clientes. 1.5 Descripción General del resto del documento Esta organizado de acuerdo al Estandar IEEE830 Recommended Practice for Software Requirements Specifications. Sponsor Software Engineering Standards Committee of the IEEE Computer Society Approved 25 June 1998 IEEE-SA Standards Borrad 2. Descripción total 2.1 Perspectiva de producto El sistema debe ser capaz de guardar y enviar eficazmente citas, administrar contactos y enviar correos electronicos a los contactos invitados a una cita Debera tener un nivel optimo en cuanto a tiempo de procesamiento de datos, es decir un performance aceptable. Solo podran accesar los usuarios validados y/o con permisos adecuados. 2.2 Funciones de producto Almacenar las citas existentes e insertar las nuevas. Permitir la edición de las citas existentes. Creación y edición de contactos. Administración de invitaciones. Envio de correos electronicos a los contactos invitados a una cita. 2.3 Características de usuario El sistema va dirigido hacia usuarios con nivel normal de conocimientos de Informatica (Manejo basico-intermedio de manejo de sistemas de informacion similares).
2.4 Dependencias a) Políticas Reguladoras. Manual de Politicas de uso de sistemas de la empresa. b) Limitaciones de hardware El sistema no se instala en servidores con caracteristicas inferiores a: MS Windows 2000 Server con Service Pack 4. El sistema operativo deberá tener las actualizaciones más recientes. Microsoft SQL-Server 2000 con Service Pack 4. BES 6.0 Java EE 1.4 Procesador Athlon 64 3200+ 2 Gb en RAM (PC3200). Disco Duro Serial ATA de 120 GB. c) Operación paralela. Comunicacion con la Bases de Datos. 2.5 Asunciones y dependencias Todo maquina que use el sistema debera tener instalado Internet Explorer 5.5 o superior, conexión a internet o a una red interna. Apéndices A.1 Template of SRS Section 3 organized by mode: Version 2
3. Requerimientos Específicos 3.1. Functional requirements 3.1.1 Mode 1 3.1.1.1 Functional requirements 3.1.1.1.1 Functional requirement 1 Enviar invitaciones a los usuarios incluidos en algún evento. IEEE Std 830-1998 IEEE RECOMMENDED PRACTICE FOR 22 Copyright 1998 IEEE. All rights reserved. 3.1.1.1.2 Functional requirement 2 El usuario tendrá los contactos organizados y podrá hacer modificaciones en esa lista de contactos (añadir, borrar, actualizar). IEEE Std 830-1998 IEEE RECOMMENDED PRACTICE FOR 22 Copyright 1998 IEEE. All rights reserved. 3.1.1.1.3 Functional requirement 3 La agenda deberá ser multiusuario, ya que se generarán altas por varias personas a la vez. IEEE Std 830-1998 IEEE RECOMMENDED PRACTICE FOR 22 Copyright 1998 IEEE. All rights reserved. 3.1.1.2 Performance Varios usuarios podrán ingresar a la agenda al mismo tiempo, sin que la funcionalidad del producto se vea afectada. 3.3 Software system attributes 3.3.1. Atributos de Seguridad 3.3.1.1. Atributos de Seguridad 1. Solo podrán validarse en el sistema los usuarios que tengan login y password, además del permiso correspondiente.
3.3.2. Atributos de Disponibilidad. 3.3.2.1. Atributos de Disponibilidad 1. El sistema debe presentar una disponibilidad del 95%, en uso de horario de oficina. 3.3.3. Atributos de Mantenimiento. 3.3.3.1. Atributos de Mantenimiento 1. El administrador del sistema, será responsable de capturar los datos de los usuarios internos. 3.4 Otros Requerimientos 3.4.1. Tipo de requerimiento: Base de Datos El tener un tiempo de respuesta aceptable dirigido a las consultas y una administración adecuada de la base de datos. 3.4.2. Tipo de requerimiento: Desempeño Podrán Interactúan varias personas a la vez con la base de datos. A.2 Template of SRS Section 3 organized by feature 3. Specific requirements 3.1 System features 3.1.1 System Feature of priority 3.1.1.1 Introduction/Purpose of feature Esta característica sirve para medir la criticidad de los Requerimientos. 3.1.1.2 Associated priority requirements Debe delinear la prioridad si cada requisito en él tiene un identificador para indicar la importancia de ese requisito en particular. Establecimos que las prioridades ya sean: Alta: cuando el requerimiento tenga la prioridad más alta. Media: cuando el requerimiento tenga una prioridad media. Baja: cuando el requerimiento tenga la prioridad más baja. Se define por el número de cambios esperados a cualquier requisito basándonos en la experiencia y en el conocimiento de eventos venideros que afectarán a la organización, funciones y a las personas que apoyan el sistema del software.
3.1.2 System feature of stability 3.1.2.1 Introduction/Purpose of feature Esta característica sirve para medir la estabilidad de los Requerimientos. 3.1.2.2 Associated priority requirements La estabilidad se cuantifica de acuerdo a los siguientes términos: Alta: Media: Baja: El requerimiento es poco propenso a cambiar. El requerimiento puede ser modificado, en caso de que no represente algún impacto significativo en el sistema. En caso de que el requerimiento sea modificado el impacto en el sistema será mínimo. 3.3 Performance requirements El sistema debe presentar una disponibilidad del 95%, en uso de horario de oficina.