SRS: Especificación de Requerimientos de Software

1. Introducción
1.1 Propósito

Este documento constituye la especificación de requerimientos de software, o

SRS (Software Requirement Specification) para el proyecto de software Agenda Tec.
Como tal, tiene como objeto servir como referencia a lo largo del desarrollo de dicho
proyecto, en términos cuáles son todas y cada una de las características concretas que
habrá de ostentar el producto final.

El documento va dirigido a todas aquellas personas o grupos de alguna manera

involucrados o afectados por el desarrollo del proyecto Agenda Tec.

1.2 Alcance (hará y lo que no hará, se describirán los beneficios, objetivos y metas)

La Agenda Tec será una aplicación de software para uso exclusivo en la

plataforma Pocket PC. La aplicación será una agenda especialmente elaborada para
ofrecer un valor agregado al estudiante del ITESM.

En la aplicación se distinguirán los siguientes tres componentes: el repositorio

de información para los contactos del usuario (una base de datos); el programa
parser de XML cuya labor será procesar un documento obtenido de un servidor del
tecnológico de dirección de IP conocida; y el programa motor, accediendo a través
de un interfase gráfico, que permitirá al usuario hacer uso relevante de la información
obtenida de los otros dos componentes.

La AgendaTec ostentará dos tipos de funcionalidades: aquellas que le confieren

funcionalidad como una agenda electrónica en sí; y aquellas que ofrecen un valor
agregado al estudiante del ITESM.

Como agenda electrónica genérica la Agenda Tec permitirá al usuario llevar un

registro de los eventos y contactos personales, y asignar eventos a fechas y horas
concretas, y en general calendarizar sus responsabilidades de manera lógica e intuitiva.

Como producto con un valor agregado al estudiante del ITESM, la Agenda Tec
le facilitará al usuario acceder de manera fácil e inmediata la información relevante a
su vida estudiantil, como las tareas pendientes para cada materia, el horario de sus
clases, las citas con maestros y compañeros de equipo y demás. Adicionalmente se
comunicará con un servidor en el ITESM a través de un Web service para obtener y
poder ofrecerle información sobre los eventos de las distintas asociaciones del Campus
que son de su interés.

1.2.1 Definiciones, Acrónimos, Abreviaciones

Parser. Un programa que lee e interpreta la información contenida en un archivo

elaborado de acuerdo a un formato determinado. Un parser en XML se refiere a un
programa que, al leer un documento XML, puede identificar los elementos del mismo y
procesarlos como salida para que posteriormente sirvan de entrada a otro programa.
SRS: Especificación de Requerimientos de Software

XML. Extensible Markup Language

ITESM. Instituto Tecnológico y de Estudios Superiores de Monterrey

Pocket PC. Plataforma de cómputo móvil (PDA) de Microsoft.

Dirección de IP. Dirección de Internet Protocol. Número de 12 dígitos que identifica a

toda computadora conectada al Internet.

Base de datos. Un repositorio de información organizado de tal manera que un

programa de software puede fácilmente encontrar, seleccionar y encontrar relaciones
entre los elementos que el usuario desee.

Programa motor. Programa principal en una aplicación, que permite a los distintos
componentes de la aplicación interactuar para producir resultados tangibles para el
usuario.

Agenda electrónica. Aplicación de agenda que típicamente encontramos en las

computadoras personales, en los PDA’s y en los teléfonos celulares modernos.

PDA. Personal Digital Assistant, o asistente digital personal. Una computadora

sumamente compacta. Cabe en el bolsillo de una persona y sirve principalmente para
ayudarle a administrar su tiempo, mantenerse en contacto con los demás, y gozar de
algunos de los beneficios que brindan las computadoras personales, cómo navegar la
Web.

Web service. En este documento, Web Service se refiere al uso de XML y SOAP para
comunicar aplicaciones a través de la red.

SOAP. Simple Object Access Protocol. Estándar que permite interactuar a aplicaciones
remotas a través de los protocolos de Internet, como HTTP.

HTTP. Hyper Text Transfer Protocol. Protocolo de comunicación propio de la Web. Los
navegadores de Internet generalmente utilizan el HTTP para acceder información.

Cliente. Computadora elemento de una arquitectura cliente servidor. La Internet sigue

este modelo, en que existen computadoras servidores, que administran recursos, y
computadoras clientes, que los solicitan.

Servidor. Computadora elemento de una arquitectura cliente servidor. La Internet

sigue este modelo, en que existen computadoras servidores, que administran recursos,
y computadoras clientes, que los solicitan.

Base de Datos Externa. Para una aplicación, una base de datos externa es una base
de datos ubicada en hardware remoto cuya información habrá de acceder.

Base de Datos Local. Para una aplicación, una base de datos local es una base de
datos localizada en el mismo dispositivo de hardware y a la cual tiene acceso dicha
aplicación.
SRS: Especificación de Requerimientos de Software

Windows Mobile. Sistema operativo de Microsoft soportado por la plataforma Pocket

PC. Las Pocket PC’s incluyen Windows Mobile. Hay ediciones 2001, 2002 y 2003 de
este sistema operativo.

Pixeles. Picture Elements. Las unidades visuales que componen las pantallas de las
computadoras. Un mayor número de pixeles por unidad de área se define como una
mayor resolución.

WLAN. Wireless Local Area Network. Red de área local inalámbrica. Una red de área
local en que las computadoras se comunican por medio inalámbrico. El Tec de
Monterrey soporta esta tecnología.

Wi-Fi. Conexión inalámbrica de alta velocidad.

1.2.2 Referencias

Esta especificación se hizo tomando como referencia a los siguientes documentos:

• Análisis de Mercado

Y como apoyo visual tenemos el Storyboard generado a partir de los requerimientos en

este documento

• Storyboard

1.2.3 Descripción

Este documento consta de tres secciones principales, dividida cada una en múltiples
apartados. Estas secciones son: Introducción, Descripción Global y Requerimientos
Específicos. Como anexos tendremos el documento de Análisis de Mercado y el Story-
board de la aplicación.

Análisis de Mercado

El propósito de este documento es atestiguar las características del mercado meta para
la Agenda Tec.

Para conocer la perspectiva de los estudiantes del ITESM respecto al uso de la

plataforma Pocket PC, sus gustos y prioridades en cuanto a la funcionalidad para una
agenda electrónica en general, y específicamente para una agenda electrónica hecha
para ellos, se llevó a cabo una encuesta que se encuentra incluida en este documento.

El documento incluye, por supuesto, los resultados de dichas respuestas, un resumen

analítico de las mismas, y las conclusiones obtenidas del análisis.

El análisis de mercado fue indispensable como auxiliar en el diseño de la aplicación,

facilitando establecer prioridades entre las funcionalidades varias características de la
agenda.

Story-board
SRS: Especificación de Requerimientos de Software

El Story-board constituye un prototipo de las pantallas que conformarán la interfase de

usuario - máquina de la aplicación. A lo largo de la descripción de la interfase con el
usuario en la sección de Descripción se hace constantemente referencia a este
documento, y porciones del mismo han sido insertadas en este documento de
especificación de requerimientos con fines de claridad.

2. Descripción global
2.1 Perspectiva del producto

La aplicación Agenda Tec es una aplicación que requiere de sólo un elemento

externo y para realizar sólo una de sus múltiples funcionalidades, aquella de mantener
al usuario informado respecto a los eventos y la información relevante del Campus. El
elemento externo en cuestión es el servidor del ITESM que le proporcionará la
información. Por lo demás la aplicación es completamente auto-contenida e
independiente; ninguno de los componentes restantes de la agenda – base de datos,
parser, programa motor – se considera para efectos de uso en forma independiente.

Toda la información del servidor que la aplicación requiere y por ende accede
está contenida en un documento XML. El interfase con el servidor se llevará a cabo a
sobre HTTP, accediéndose el documento a través de SOAP; se presupone que el
programa conoce la dirección IP del servidor.

2.1.8. Operaciones
2.1.8.1. Modos de operación de los distintos grupos de usuarios
2.1.8.2. Periodos de opera
ciones interactivas y automáticas
2.1.8.3. Funciones respaldo del procesamiento de datos
2.1.8.4. Operaciones de backup y recuperación

2.2 Funciones del producto

Como agenda electrónica genérica, la Agenda Tec:

• Permitirá al usuario llevar un registro de los eventos que tiene

programados para cada día del año.
• Permitirá al usuario llevar un registro de sus contactos personales;
es decir, el nombre, teléfono, dirección de correo electrónico, fax y
dirección de residencia de las personas con quienes desee o requiera
estar en comunicación.
• Facilitará al usuario la identificación de días del año especiales o
de relevancia.
• Permitirá al usuario conocer la fecha y la hora actuales.

Respecto a las anteriores funcionalidades:

SRS: Especificación de Requerimientos de Software

• Por registro de un evento se entenderá que el usuario tendrá la

capacidad para definir, para cada evento, nombre, fecha, hora de
inicio, hora de terminación, prioridad y una descripción textual; y para
cada evento habrá de definir al menos la nombre y la fecha del mismo.

Como características distintivas, la Agenda Tec:

• Conferirá a cada tipo de día especial un color distintivo en el ya

mencionado calendario, amén de facilitar al usuario la pronta
identificación de dichas ocasiones.

• Permitirá al mismo usuario definir una categoría para cada evento del
calendario. Al asignar el usuario una categoría específica a un día del
calendario, convierte a ésta fecha en una fecha especial, para la cual
él mismo usuario habrá de conferir un color distintivo.

• Permitirá al usuario determinar si una actividad es o no una actividad a

ser llevada a cabo en algún momento del día, o a lo largo de todo el día,
sin hora de inicio y terminación específicas.

• Permitirá al usuario fijar una de las siguientes prioridades a cada cita:

alta, normal y baja.

• Permitirá al usuario poner alarma a cada evento en el calendario, y

determinar qué tanto tiempo antes, en minutos u horas, habrá de sonar.

Como aplicación con un valor agregado al estudiante del ITESM, la Agenda Tec:

• Permitirá al usuario acceder fácil y rápidamente la información sobre los

eventos en el calendario que conciernen su vida estudiantil. Dichos
eventos serán tareas, citas con profesores, citas compañeros de
equipos de trabajo y eventos especiales.

• Los eventos especiales corresponderán a una de las siguientes

categorías: Difusión Cultural, Grupos Estudiantiles, Actividades
Deportivas, Actividades de la Sociedad de Alumnos, Simposiums,
Calendario Académico (Evalu@net y Exámenes Finales) y Eventos
Misceláneos (para todo aquel evento de relevancia que no se ubique en
categoría alguna de las anteriores).

• Permitirá al usuario acceder fácil y rápidamente información relevante a

su vida estudiantil.

• Dicha información corresponderá a una de las siguientes categorías:

Menús de las Cafeterías, Horarios Extendidos de Biblioteca y Salas
de Cómputo, e Información Miscelánea. El Menú de las Cafeterías
será actualizado al día, asumiendo que el documento XML en el servidor
del ITESM es actualizado día con día.
SRS: Especificación de Requerimientos de Software

• Permitirá al usuario definir materias como una categoría de

información especial.
• Permitirá al usuario asignar maestro, horario de clase, equipos y
compañeros de quipo a cada materia, así como crear y eliminar
materias.

*cliente o cualquier otra persona lo entienda perfectamente. Para ello se pueden utilizar
métodos textuales o gráficos, siempre que dichos gráficos reflejen las relaciones entre
funciones y no el diseño del sistema. En la metodología estructurada se podrían utilizar
los DFDs y en una metodología orientada a objetos, el funcionamiento y las relaciones
del futuro sistema se modelarían a través de los Casos de Uso.

2.3 Requerimientos y limitantes en hardware y software

La aplicación Agenda Tec correrá sobre la plataforma de PDA “Pocket PC”,

sobre el sistema operativo Windows Mobile 2002, y se supone será soportado así
mismo por Windows Mobile 2003, supuesto que no se tienen los medios para verificar
durante el proceso de desarrollo.

El ambiente gráfico de la aplicación abarcará el tamaño de toda la pantalla de la

Pocket PC, misma que ostenta una resolución de 240 x 320 pixeles.

Para correr poder realizar el enlace remoto con el servidor del ITESM, la
aplicación requerirá que el dispositivo Pocket PC soporte Wi-Fi amén de que pueda
conectarse a la WLAN (802.11) del Campus. La configuración de la conexión
inalámbrica correrá por cuenta del usuario.

2.3 Características de los usuarios: al que se dirige la aplicación.

2.4 Restricciones: políticas de la empresa, limitaciones hardware, seguridad, protocolos de comunicación,
interfaces con otras aplicaciones, estándares de la empresa en cuanto a interfaces, etc. Serán las
limitaciones que se imponen sobre los desarrolladores del producto.
2.5 Suposiciones y Dependencias
2.6 Requisitos Futuros

3. Requerimientos específicos

Debe cumplir los principios descritos en los primeros apartados de este informe.
Estos principios son la corrección, no ambigüedad, completitud, consistencia,
clasificación, verificabilidad, modificabilidad, explorabilidad y facilidad de
mantenimiento.

3.1. Características del Sistema (Por usuario, objeto,

objetivo(entrada,funciones para llevar a cabo), funciones(prog. estructurada))
* se ha realizado por objetivos

3.1.1. Característica: Capacidad para dar de alta un contacto.

SRS: Especificación de Requerimientos de Software

3.1.1.1 Propósito de la característica: Permitir al usuario llevar un

registro de los datos de las personas con quienes podría desear en algún
momento comunicarse.
3.1.1.2 Estímulo: El usuario selecciona la opción marcada como
Contactos en la pantalla principal.
3.1.1.3 Respuesta: El sistema hace una transición de pantallas a la
pantalla de contactos.
3.1.1.4 Estímulo: El usuario selecciona la opción marcada como
Nuevo.
3.1.1.5 Respuesta: El sistema hace una transición de pantallas a la
pantalla de Nuevo Contacto. La pantalla de nuevo contacto tiene campos para
que el usuario determine:

• Nombre: una variable alfanumérica de mínimo 1 caracter, máximo 50

caracteres. Es un campo requerido.
• Apellido: una variable alfanumérica de mínimo el carácter nulo, máximo 50
caracteres.
• Teléfono de Hogar: una variable numérica entera de mínimo el caracter
nulo, máximo 20.
• Teléfono de Oficina: una variable numérica entera de mínimo el carácter
nulo, máximo 20.
• Fax: una variable numérica entera de mínimo el carácter nulo, máximo 20.

• Dirección de Correo Electrónico: una variable alfanumérica de mínimo el

carácter nulo, máximo 100.
• Dirección Domiciliaria: una variable alfanumérica de mínimo el carácter
nulo, máximo 100.
• Categoría del usuario: uno de los siguientes valores: compañero, maestro,
amigo, familiar, ninguno. Requisito. El valor predeterminado es “ninguno”.

3.1.1.6 Estímulo: El usuario determina la información de al menos el

campo de nombre y de categoría y selecciona Aceptar.
3.1.1.7 Respuesta: El sistema da de alta el nuevo contacto.

3.1.1.8 Requerimientos funcionales asociados:

3.1.1.8.1 Que el sistema permita dar de alta un contacto si y sólo si el

campo de nombre en la pantalla de Nuevo Contacto contiene un valor válido.
3.1.1.8.2 Que el sistema a avise al usuario de su error al no cumplir
éste con el requerimiento 3.1.1.8.1 mediante una ventana de diálogo.
3.1.1.8.3 Que el sistema verifique que los campos llenados por el
usuario en la pantalla de Nuevo Contacto contengan valores válidos.
3.1.1.8.4 Que el sistema a avise al usuario de su error al no cumplir
éste con el requerimiento 3.1.1.8.3 mediante una ventana de diálogo
3.1.1.8.5 Que el sistema permita al usuario no dar de alta al contacto,
seleccionando la opción de Cancelar en vez de aquella de Aceptar.

3.1.2. Característica: Capacidad para dar de alta una cita.

SRS: Especificación de Requerimientos de Software

3.1.2.1 Propósito de la característica: Permitir al usuario llevar un

registro de las citas que tiene pendientes.
3.1.2.1 Estímulo: El usuario selecciona la opción marcada como
Calendario en la pantalla principal.
3.1.2.3 Respuesta: El sistema hace una transición de pantallas a la
pantalla de calendario.
3.1.2.4 Estímulo: El usuario selecciona la opción marcada como
Nueva.
3.1.2.5 Respuesta: El sistema hace una transición de pantallas a la
pantalla de Nueva Cita. La pantalla de nueva cita tiene campos para que el
usuario determine:

• Título: una variable alfanumérica de mínimo 1 caracter, máximo 50

caracteres. Es un campo requerido.
• Fecha de Inicio: una variable de tipo fecha, especificando día, mes y año.
• Hora de Inicio: una variable de tipo hora, especificando horas, minutos y
segundos, y si es AM o PM.
• Fecha de Terminación: una variable de tipo fecha, especificando día, mes y
año.
• Hora de Terminación: una variable de tipo hora, especificando horas,
minutos y segundos, y si es AM o PM.
• Alarma: una variable en minutos u horas. Puede tener también el valor de
ninguna, que es el predeterminado.
• Prioridad: uno de los siguientes valores: alta, normal y baja.
• Etiqueta: uno de los siguientes valores: vacaciones, comida, romance,
social, escuela, trabajo, familia, cumpleaños, aniversario, ninguna.

3.1.2.6 Estímulo: El usuario determina la información de al menos los

campos de título, fecha de inicio, hora de inicio, fecha de terminación, hora de
terminación; o en su defecto al menos los campos de título, de fecha de inicio,
de fecha de terminación y la opción de todo el día; y selecciona Aceptar.
3.1.2.7 Respuesta: El sistema da de alta la nueva cita.

3.1.2.8 Requerimientos funcionales asociados:

3.1.2.8.1 Que el sistema permite el alta de la cita sólo si

3.1.2.8.1.1 los campos de nombre, fecha de inicio, hora de
inicio, fecha de terminación y hora de terminación tienen un valor
válido.
o bien,
3.1.2.8.1.2 los campos de nombre, fecha de inicio, fecha de
terminación tienen un valor válido, y la opción de todo el día haya sido
seleccionada.
3.1.2.8.2 Que el sistema a avise al usuario de su error al no cumplir
éste con el requerimiento 3.1.2.8.1 mediante una ventana de diálogo.
3.1.2.8.3 Que el sistema verifique que los campos llenados por el
usuario contengan valores válidos.
3.1.2.8.4 Que el sistema a avise al usuario de su error al no cumplir
éste con el requerimiento 3.1.2.8.3 mediante una ventana de diálogo.