Documento de Especificación de Requerimientos

INSTITUTO GEOGRÁFICO AGUSTÍN CODAZZI
SEDE CENTRAL
DOCUMENTO DE ESPECIFICACIÓN DE
REQUERIMIENTOS
1.
Glosario de Términos
Aquí se listaran y definirán los términos asociados y necesarios para comprender los casos de
uso del sistema.
TÉRMINO
DESCRIPCIÓN
Término a Definir
2.
Definición clara del término.
Inventario de Casos de uso
Aquí se define la nemotecnia de los diferentes casos de uso para identificarlos en sus
diferentes estados.
Abreviación: CUNSIT XX
Nemónico
Significado
CU
NS
IT
XX
Casos de uso.
Nombre del sistema
Iteración
Número de ítem.
En esta tabla se realiza un listado que servirá para inventariar los casos de usos contemplados
para el sistema.
IDENTIFICADOR
NOMBRE
CUNSIT 01
Nombre del caso de uso número 01
CUNSIT 02
Nombre del caso de uso número 02
IGAC-Entidad
Documento de Especificación de Requerimientos
INSTITUTO GEOGRÁFICO AGUSTÍN CODAZZI
SEDE CENTRAL
3.
Diagrama de casos de uso del sistema
Aquí se presenta el diagrama de casos de uso que se ha elaborado para el sistema. Este
diagrama que se muestra a continuación es solo un ejemplo de cómo se presenta un diagrama
de casos de uso.
En esta tabla se documenta la información básica de elaboración del diagrama.
Diagrama de Casos de Uso
Entidad:
Elaboró:
Fecha de Elaboración:
IGAC-Entidad
Nombre del Analista
DD/MM/AAAA
IGAC-Entidad
Documento de Especificación de Requerimientos
INSTITUTO GEOGRÁFICO AGUSTÍN CODAZZI
SEDE CENTRAL
4.
Especificación de casos de uso
En estas tablas se especificará cada uno de los casos de usos presentados en el diagrama de
casos de uso del sistema.
Instituto Geográfico Agustín Codazzi
Oficina Centro de Investigación y Desarrollo en
Información Geográfica CIAF
Grupo Geoservicios y Geoservicios
Diligencio IGAC
Valido IGAC
Nombre:
Nombre
Firma:
Firma:
Fecha:
Fecha:
Identificador
Nombre
Entidad-Número
Requerimiento
Nombre del Requerimiento (Los requerimientos deben comenzar con verbos en
infinitivo). Ej.: Añadir servicio de mapas
Resumen
El resumen es una descripción breve que concuerda con el propósito de los casos de uso, según la
funcionalidad expresada por cada requerimiento funcional. Ej.: Se debe cargar un servicio de mapas al
Visor Web. La primera vista del mapa que se muestra se debe ajustar a la extensión definida en el servicio
de mapas.
Actor
Proceso de negocio en el que participa
Se define el (los) usuario(s) que tienen acceso
a este requerimiento. Ej.: Usuario
Define en qué proceso va a funcionar el requerimiento
(por ejemplo, carga de capas a un visor geográfico) y en
qué mercado (quiénes son sus usuarios). Establece si el
proyecto está siendo desarrollado por llenar un contrato o
si es un producto comercial. Si el requerimiento hace
parte de un proyecto existente, esto debe ser
mencionado.
Entradas
Salidas
Entradas del requerimiento para cumplir su
funcionalidad. Ej.:
Salidas producto de la realización del requerimiento. Ej.:
1. Dirección URL del servicio.
IGAC-Entidad
Documento de Especificación de Requerimientos
5. El servicio se agrega a la tabla de contenido del
servidor junto con las capas que lo componen.
INSTITUTO GEOGRÁFICO AGUSTÍN CODAZZI
SEDE CENTRAL
Precondición
Postcondición
Estado en el cual el sistema debe encontrarse
antes de que la funcionalidad que expresa el
requerimiento se lleve a cabo.
Lista de posibles estados que el sistema puede tomar
luego de que la funcionalidad que expresa el
requerimiento se lleva a cabo.
Ej.: El servidor de mapas solicitado debe estar
disponible
Ej.: Las capas del servicio de mapas se deben agregar a
la tabla de contenido del visor y estas capas se deben
visualizar en la vista del visor
Suposiciones
Son las condiciones que se dan por establecidas, en las que se supone que se encuentra el sistema en el
momento de que el requerimiento que representa el caso de uso entra en juego, o las condiciones en las
que se encuentra el entorno para que el proyecto pueda comenzar.
Ej.: El MPS proporciona las capas que necesita montar en el visor geográfico.
Flujo normal de eventos
El caso de uso que representa este requerimiento funcional comienza cuando un actor realiza alguna acción. Un Actor
siempre inicia los casos de uso. El caso de uso describe lo que el actor hace, y lo que hace el sistema, en respuesta.
Esto se expone en forma de diálogo entre el actor y el sistema. El caso de uso describe lo que ocurre al interior del
sistema, pero no cómo o por qué. Si la información es intercambiada, se debe especificar qué pasará antes y
después. Por ejemplo, no está bien decir que el actor introduce información del cliente, si ésta no está definida. Es
mejor decir que el actor introduce el nombre y la dirección del cliente. Un Glosario de Términos es esencial para
mantener manejable la complejidad de los casos de uso. Puede que se quieran definir cosas como la información del
cliente en este glosario. Las alternativas simples pueden presentarse dentro del texto del flujo normal de eventos. Sólo
toma unas pocas frases describir lo que ocurre cuando existe una alternativa, y hay que hacerlo dentro del flujo. Si la
alternativa es más compleja, se usará una sección separada para describirla. Por ejemplo, la sección Caminos
Alternativos, explica cómo describir alternativas más complejas, y la sección Caminos de Excepción explica cómo
describir comportamientos incorrectos llamados Excepciones. Una imagen vale más que mil palabras, aunque no
hay substituto para la redacción clara. Esta redacción da claridad, sintiéndonos libres de pegar flujogramas,
diagramas de actividades u otras figuras en esta especificación. Esto clarifica el comportamiento del sistema, a veces
mejor que páginas y páginas de texto. Use el medio adecuado de presentación para el problema, pero tenga cuidado
de emplear terminología, notaciones o figuras que los interesados puedan no entender. Recuerde que el
propósito es aclarar, no oscurecer.
Acción del actor
Respuesta del sistema
1
El usuario indica que va a agregar un
servidor de mapas.
2
El sistema solicita la url y la versión del servicio de
mapas.
3
El usuario ingresa la url y la versión del
servicio de mapas.
4
El sistema hace solicitud getcapabilities al servidor de
mapas y retorna las capas disponibles y los sistemas
de referencia soportados por el servicio de mapas.
Además solícita al usuario cuales capas desea cargar
y el sistema de referencia con que desea cargarlas.
Excepción 1: Si la url del servicio no es correcta.
5
El usuario selecciona las capas a cargar y
el sistema de referencia con que va a
cargar las capas.
IGAC-Entidad
Documento de Especificación de Requerimientos
6
El sistema carga referencia de las capas solicitadas a
la tabla de contenido del visor.
INSTITUTO GEOGRÁFICO AGUSTÍN CODAZZI
SEDE CENTRAL
Caminos Alternativos
Alternativas más complejas son descritas en esta sección por separado, referidas a la sección Flujo
Normal de Eventos. Piense en estos Caminos Alternativos como comportamientos alternativos (cada
camino alternativo representa un comportamiento alternativo, usualmente debido a las Excepciones que
ocurren en el Flujo Normal). Se debe tomar un espacio tan largo como sea necesario para describir los
eventos asociados con el comportamiento alternativo. Se debe comenzar con una línea clara que
establezca dónde puede ocurrir el camino alternativo, y las condiciones bajo las cuales es ejecutado. Se
debe terminar el camino alternativo con una línea que establezca dónde los eventos del Flujo Normal son
resumidos. Esto debe estar explícitamente establecido.
Caminos de Excepción
Las acciones realizadas luego de presentarse las Excepciones son descritas en esta sección por separado, referidas
a la sección Flujo Normal de Eventos. Las Excepciones son comportamientos alternativos incorrectos, ante los
cuales el sistema debe responder de cierta forma para notificar al usuario. Se debe tomar un espacio tan largo como
sea necesario para describir los eventos asociados con cada una de las excepciones.
Ej.: Excepción 1: El sistema indica que el servicio no es encontrado.
Puntos de Extensión
Aquí se documentan las posibles especializaciones del presente caso de uso. La extensión refleja
situaciones particulares en un caso de uso que pueden ser tratadas (extendidas) por otro.
Observaciones
Aquí se colocaran las observaciones relevantes que se vayan dando en las iteraciones y en el refinamiento
de requerimientos.
Autor
Fecha
IGAC-Entidad
Documento de Especificación de Requerimientos
Creación / Modificación
INSTITUTO GEOGRÁFICO AGUSTÍN CODAZZI
SEDE CENTRAL
6.
Especificación de Requerimientos No Funcionales
En este artefacto, se deben especificar cada uno de los siguientes tipos de requerimientos no funcionales
con la tabla que se muestra a continuación.
Identificador
Entidad – RNF – Número del RNF
Nombre
Nombre del Requerimiento No Funcional. Ej.: Programación en tecnología
.Net
Tipo:
Tipo de Requerimiento No Funcional.Ej.: Restricción Tecnológica
Indispensable/Deseable:
Un Requerimiento No Funcional es Indispensable cuando es necesario
tenerlo en cuenta para la realización de algún requerimiento funcional.
Un Requerimiento No Funcional es Deseable cuando la funcionalidad que
proporciona puede ser implementada de forma opcional, y ningún
requerimiento funcional depende de ella. Ej.: Indispensable
Crítico:
El criterio de “Crítico” implica evaluar el impacto de la ausencia y presencia
del RNF, y cómo se ve afectado el sistema por estas condiciones. Ej.: Sí
Descripción
Comentario breve del por qué se necesita este RNF. Ej.: Para este proyecto
estamos sujetos a utilizar tecnología .Net para el desarrollo debido a
restricciones del cliente.
Criterios de aceptación:
Criterios que validan este RNF frente a los interesados. Ej.: Todo el código
que se implemente debe ser en lenguaje .Net.
Seguridad
Colocar tabla asociada.
Conformidad
Colocar tabla asociada.
Confiabilidad
Colocar tabla asociada.
Usabilidad
Colocar tabla asociada.
IGAC-Entidad
Documento de Especificación de Requerimientos
INSTITUTO GEOGRÁFICO AGUSTÍN CODAZZI
SEDE CENTRAL
Desempeño
Colocar tabla asociada.
Mantenibilidad
Colocar tabla asociada.
Integración
Colocar tabla asociada.
Integridad
Colocar tabla asociada.
Visualización
Colocar tabla asociada.
Operación
Colocar tabla asociada.
Interacción
Colocar tabla asociada.
Lenguaje de Programación
Colocar tabla asociada.
Plataforma de Implantación
Colocar tabla asociada.
Portabilidad
Describir tabla.
Aprobó Entidad
Nombre Interventor:
Firma:
Fecha:
IGAC-Entidad
Documento de Especificación de Requerimientos