Caso Agenda

Introducción

Este documento es una especificación de requisitos software para un Gestor de contactos personales. Todo su contenido ha sido elaborado en colaboración con los profesores de Ingeniería del Software I de la URJC. Esta especificación se ha estructurando inspirándose en las directrices dadas por el estándar “IEEE Recomended

Practice for Software Requirement Especifications ANSI/IEEE 830 1998”

Propósito

El objeto de la especificación es definir de manera clara y precisa todas las funcionalidades y restricciones del sistema que se desea construir. El documento va dirigido a nuestro grupo de trabajo de las prácticas de ISI. Este documento será el canal de comunicación entre las partes implicadas tomando parte en su confección miembros de cada parte. Esta especificación está sujeta a revisiones por el grupo de trabajo que se recogerán por medio de sucesivas versiones del documento, hasta su aprobación por la totalidad del grupo. Una vez aprobado servirá de base al equipo de desarrollo para la construcción del nuevo sistema.

Ámbito del Sistema

El motor que impulsa el desarrollo del sistema es el gestionar nuestros “préstamos a amigos”. Definiremos al sistema como GCP.

Es un sistema simple en cuanto a implementación y concepto: hay que tener una lista de nuestros contactos y los objetos que prestamos a éstos. Sin embargo, enfocaremos el desarrollo del sistema desde el punto de vista de la asignatura.

Esto significa que tendremos que pasar por todas las etapas del Proceso Unificado de Desarrollo Software a pesar de que el sistema no tiene demasiada complicación.

Definiciones y Acrónimos

Definiciones

Contacto Persona relevante que tenemos en la agenda y de la cual guardamos una cierta información como su nombre, apellidos, etc….

Préstamo Registro que enlaza un objeto con un contacto y guardamos la fecha en que se ha ocasionado.

Acrónimos

GCP Gestión de Contactos Personales

ERS Especificación de requisitos Software

RFXXX El estándar seguido para la especificación del identificador de cada requisito funcional será de la siguiente manera:

R = Requisito

F = Funcional

XXX = secuencia de tres dígitos que servirá para la enumeración de cada requisito.

RNFXXX El estándar seguido para la especificación del identificador de cada requisito no funcional será de la siguiente manera:

R = Requisito

NF = No Funcional

XXX = secuencia de tres dígitos que servirá para la enumeración de cada requisito.

Referencias

IEEE Recomendad Practices for Software Requierements especification ANSI/IEEE 830 1998.

Transparencias de la asignatura “Ingeniería del Software I”.

Apuntes de clase de la asignatura “Ingeniería del Software I”.

Visión general del documento

Este documento consta de tres secciones. Esta sección es la introducción y proporciona una visión general del ERS. En la sección 2 se da una descripción general del sistema, con el fin de conocer las principales funciones que debe realizar, los datos asociados y los factores, restricciones, supuestos y dependencias que afectan al desarrollo, sin entrar en excesivos detalles. En la sección 3 se definen detalladamente los requisitos que debe satisfacer el sistema.  

Descripción General

En esta sección se presenta una descripción a alto nivel del sistema. Se presentaran las principales áreas de negocio a las cuales el sistema debe dar soporte, las funciones que el sistema debe realizar, la información utilizada, las restricciones y otros factores que afecten al desarrollo del mismo.

Perspectiva del producto

El sistema en esta versión no interactuará con ningún otro sistema informático.

Funciones del sistema

En términos generales, el sistema GCP deberá proporcionar soporte a las siguientes tareas de gestión de los contactos personales y préstamos a éstos:

o Mantenimiento y Gestión de nuestros contactos personales.

o Gestión de préstamos a los contactos.

o Impresión de una lista de contactos

A continuación se describirán con más detalle estas tareas y como serán soportadas por el sistema.

o Mantenimiento y Gestión de nuestros contactos personales.

Todos nuestros contactos personales pueden ser dados de alta, modificados, consultados y modificados. De cada uno de ellos nos interesará mantener la siguiente información: nombre, apellidos, teléfonos, direcciones de e-mail, dirección postal y apodo.

o Gestión de préstamos a los contactos.

Como suele pasar con cierta frecuencia, solemos dejar objetos como libros, dinero, cd’s,… a nuestros contactos personales. El problema de esto es que con el paso del tiempo olvidamos qué dejamos y a quien, y el objeto queda perdido. Por ello, nos interesa saber qué objetos hemos dejado a cada contacto y la fecha con la que se realizó el préstamo.

o Impresión de una lista de contactos

Nos será útil saber, en un momento dado, quienes son nuestros contactos por este motivo es necesario poder listarlos de forma ordenada para así llevar un control de estos.

Características de los usuarios

Los usuarios de este sistema están familiarizados con el uso de aplicaciones de este tipo ya que simula la agenda tradicional, que todos conocemos. Es por ello que el sistema ha de ser gráfico. Con una interfaz sencilla e intuitiva, que no exija gran tiempo para su aprendizaje, a la vez que lo suficientemente potente para que el usuario pueda hacer aquello que necesita.

Restricciones

El sistema simulará el funcionamiento de una agenda, pudiendo gestionar los contactos y los préstamos a éstos.

Este sistema será accedido solamente por el usuario de la agenda.

Suposiciones y dependencias

El sistema ha sido implementado en el lenguaje C++ bajo Windows. Esto significa que el ejecutable que entregaremos sólo podrá ser chequeado bajo plataformas Windows. Como también se proporciona el código fuente, es posible compilar todos los fuentes y probarlos bajo otra plataforma.

Requisitos

En este apartado se presentan los requisitos funcionales que deberán ser satisfechos por el sistema. Todos los requisitos aquí expuestos son esenciales, es decir, no sería aceptable un sistema que no satisfaga alguno de los requisitos expuestos. Los requisitos se han especificado de manera que sea fácil comprobar si el sistema los ofrece o no y si los ofrece de manera adecuada (criterio de testabilidad)

Requisitos Funcionales

Mantenimiento

...