TABLA DE CONTENIDOS

1. INTRODUCCiÓN
2. 3.
ANTECEDENTES DE LA INGENIERíADE REQUERIMIENTOS TÉCNICAS y MÉTODOS DE IDENTIFICACiÓN 3.1 PREGUNTAS RESPUESTAS.. y 3.2 PROTOTiPOS ... ...

1
:2 5 5 6
7 7
:

4.

TÉCNICAS y MÉTODOS DE ESPECIFICACiÓN 4.1 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 ARQUITECTURA ... DIAGRAMAS FLUJO DE DATOS DE PROCESOS DICCIONARIO DATOS DE MODELODE DATOS MAPA DE NAVEGACiÓN DESCRIPCiÓNDE PÁGINAS y REPORTES USE-CASE MODELOCONCEPTUAL DIAGRAMf.\.S E SECUENCiA D DESCRIPCiÓN DE ARCHiVOS
ESPECIFICACiÓN DE REQUERIMIENTOS

4.2 JERARQuíA FUNCiONAL

7
8 11 13 14 17 19 21 24 24 24
26 26 28 31 31

5.

DOCUMENTODE
5.'1 5.2 5.3 5.4 5.5 DESCRIPCiÓN DESCRIPCiÓN DESCRIPCiÓN DESCRIPCiÓN DESCRIPCiÓN

GENERAL DE ELEMENTOS COMUNES DE LA PLANTILLA PARA ESPECIFICACiÓN FUNCIONAL DE LA PLANTILLA PARA ESPECIFICACiÓN ORIENT/~DA AL OBJETO DE LA PLANTILLA PARA ESPECIFICACiÓN DE APLICACIONES WES

31

6. COMENTARIOSINALES F
ANEXO A PLANTILLAPARA ESPECIFICACiÓNFUNCIONAL ANEXO B PLANTILLAPARA ESPECIFICACiÓNORIENTADAAL OBJETO ANEXO C PLANTILLAPARA ESPECIFICACiÓNDE APLICACIONESWEB ANEXO D CHECKLlST DE REVISiÓNDE REQUERIMIENTOS

33
34 36 38 40

TABLA DE FIGURAS
Fi?,ura l. Ejemplo de Jerarquía de Requerimientos no Funcionales Figura 2. Ejemplo dejerarquíajilllcional tradicionul Figll/'a 3. Ejemplo dejerarquía jilllcional Figura -l. Elemelltos de notación de un DFD Figura 5. Ejemplos de DFD válidos e inválidos Figura 6. Refinamientos sucesivos de los DFD Fi?,ura 7. ~/emplo de espec¡!icaciónmediante Lenguaje Estructurado Figura 8. Ejemplu de Arbol de Decisión Fi?,ura9. Ejemplo de Tabla de Decisión Figura 10. Notación para la descripción de contenido del Diccionario de Datos Figura 1/. Nolaciónutilizada en los dia?,ramasEntidad-Relación Figura 12. Ejemplo de Relación entre Entidades Figura 13. Diferencia entre el Modelo Lógico y el Modelo Físicu Figura 14. Ejemplo de Mapa de Navegación Figura 15. ~iemplo de Descripción de Páginas.: Figura 16. Ejemplo de Especificación de Reporte Figura 17. ~iemplo de Diagrama Use-Case. Figura 18. Ejemplo de Use-Case Figura 19. Niveles de Mode/amiento de Información de más a menos abstracto. 3 7 8 9 9 /0 /1 /2 /3 /./ /5 15 / (i /8 19 2/ 23 23 32

ii

Proyecto de Software

Especificación de Requerimientos

1.

INTRODUCCiÓN
El presente documento entrega algunos de los elementos necesarios para realizar una especificación de requerimientos adecuada de un proyecto de software. En la sección 2 se entregan algunos antecedentes sobre la Ingeniería de Requerimientos, el proceso de identificación y atributos importantes de los requerimientos. En la sección 3 se entregan algunos conceptos básicos para poder realizar una identificación de requerimientos. En la sección 4 se describen las técnicas principales para la especificación de requerimientos. Estas técnicas corresponden principalmente a las utilizadas en el análisis funcional y en el análisis orientado a objetos como son los Diagramas de Flujos de Datos, Descripción de Procesos, Modelo Lógico de Datos, Clases, etc. Además se incluyen algunas técnicas utilizadas para la especificación de requerimientos de aplicaciones web como son el mapa de navegación y la descripción de páginas. En la sección 5 se describen las plantillas de especificación de requerimientos para especificación funcional, especificación orientada al objeto y especificación de aplicaciones web. En los anexos A, B Y C se incluyen las plantillas y en el anexo D se incluye un checklist de revisión como ayuda para determinar si la especificación de un sistema ha sido completa o no.

Proyecto de Software

Especificación de Requerimientos

2.

ANTECEDENTES

DE LA INGENIERíA DE REQUERIMIENTOS

Para que un esfuerzo de desarrollo de software tenga éxito, es esencial comprender perfectamente los requisitos del software. Independientemente de lo bien diseñado o codificado que esté un programa, si se ha especificado y analizado pobremente, decepcionará al usuario y desprestigiará el desarrollo. Los requerimientos bien establecidos permiten realizar un análisis adecuado del problema, identificar las soluciones más apropiadas y, por sobre todo, permiten delimitar la aplicación. La delimitación de la aplicación evita esfuerzos innecesarios, permite identificar claramente el objetivo y además permite obtener un consenso entre el cliente y el equipo de desarrollo. El proyecto de desarrollo de software debe ser exitoso y para ello debe conocerse claramente el objetivo final, es decir, el sistema que se desea construir. Si el objetivo fin.al no está claramente definido, difícilmente se podrá cumplir con él. Además, ninguna otra parte del trabajo deja como inválido al sistema resultante sino está hecha correctamente. En la actualidad la mayoría de los recursos se destinan a la elaboración de los documentos de especificación o de requerimientos. La especificación de requerimientos es el resultado de la comunicación entre el equipo de trabajo y el cliente. El documento de requerimientos además, define el primer punto de referencia para la validación del software. Así, si se quiere verificar que un software cumple con exigencias determinadas, se debe saber contra que se quiere comparar. Es importante destacar que el documento de requerimientos no sólo consigue un consenso entre el cliente y el equipo de trabajo con respecto a lo que se desea, sino que un documento bien concebido provee las bases para la realización del diseño del software. Debido a que no necesariamente todos los integrantes del equipo de trabajo conocen el área de aplicación del sistema, el documento puede servir como una referencia para resolver dudas específicas de la aplicación o simplemente como una forma de informar al equipo de trabajo el proyecto que se va a desarrollar. Por otro lado, permite la incorporación de nuevos recursos (personal) para apoyar el proceso de desarrollo. La elaboración del documento de requerimientos se puede resumir como: "El proceso de establecer los servicios o funcionalidad que el producto de software proveerá, en un lenguaje común que sirva como medio de comunicación entre las partes, y las restricciones bajo las cuales él debe operar" o en términos simples "¿Qué se debe hacer?". Según el estándar IEEE STD-729, un requerimiento se define como: 1. Una condición o capacidad necesitada por un usuario para resolver un problema o lograr un objetivo. 2. Una condición o capacidad que debe ser alcanzada, o poseída por un sistema o componente del sistema para satisfacer un contrato, estándar, especificación u otro documento formalmente impuesto. 3. Una representación documentada de una condición o capacidad como en 1 y 2. A su vez los requerimientos se pueden clasificar en:

. .

Funcionales: No funcionales:

corresponden a los resultados que debe arrojar el sistema bajo están relacionados con el rendimiento, seguridad, precisión, manejo

determinadas circunstancias. de erroresy capacidadespara usuariosespecíficos.Normalmentelas restriccionesse traducenen requerimientos funcionales(ver Figura1). no

2

Proyecto de Software

Especificación de Requerimientos

. .

Inversos: indican lo que el software "no debe hacer". Son de mucha importancia en el software de misión crítica. Restricciones de Diseño e Implementación: corresponden a condiciones impuestas por el usuario para el diseño y la implementación de la aplicación.

Además de la clasificación anterior, los requerimientos deben ser:

. . . .

. Precisos: no deben ser ambiguos.
Consistentes técnicamente: consigo mismo y con otros. Completos: todo lo necesario debe estar descrito. Trazables: descritos de tal manera que tengan una única identificación y que se puedan medir. Comparables: es decir, que se puedan probar.
Requerimientos No Funcionales

Requerimientos del Proceso

Requerimientos de Seguridad

Requerimientos Eticos

Requerimientos de Usabilidad

Requerimientos de Implementación

Requerimientos Legislativos

Requerimientos de Seguridad

Figura 1. Ejemplo de Jerarquía de Requerimíentos no Funcionales

. .

Por otro lado los requerimientos no deben poseer ninguna de las características siguientes:

Ruido: datos que sin aportar nueva información, sólo causan confusión. Omisión: no describir algo que sí debe contemplarse. . Contradicción: el tener dos o más requerimientos en conflicto entre ellos. . Ambigüedad: presencia de texto que se presta para dos o más interpretaciones. . Que no sea comprobable: un requisito que no se pueda comprobar, debe reescribirse
de forma que tenga una prueba objetiva. En la ingeniería de requerimientos se pueden identificar las siguientes actividades: Identificación, Análisis, Representación y Comunicación. A continuación se describe cada una de ellas:

.

Identificación. Los requerimientos son recolectados desde las personas involucradas. .
Se deben identificar los usuarios afectados, intermedios y finales. Además se debe

3

Proyecto de Software

Especificación de Requerimientos

identificar el contexto operativo de cada requerimiento. Para apoyar esta actividad se puede: Observar las operaciones del usuario. Desarrollar encuestas Solicitar asesoría de expertos en el área de aplicación Realizar entrevistas Investigar el área de aplicación Identificar analogías con otros sistemas

.

Análisis.

Los requerimientos

deben ser "compilados"

debido a que ellos provienen de

distintas fuentes. Para ello se deben: Clasificar por tipo de requerimiento Priorizar sobre la base de factores críticos Evaluar los riesgos y la factibilidad económica técnica Validar según los atributos correctos (comprobable, trazable, etc.) Algunas de las técnicas y métodos que apoyan esta actividad son el IBIS (Issue Based Informaction System), el JAD (joint Application Design) y las Inspecciones Formales o Walk-Throughs y PD (Participating Design).

.

Representación. Los requerimientos se traducen desde "una forma textual" a "modelos" o "prototipos". Algunos de los más representativos son: Modelo de la Arquitectura Modelo Funcional Modelo de Datos Modelo de Flujo de Datos Modelo de Interfaz Modelo de Objetos Algunas de las técnicas y métodos que apoyan esta actividad son el SADT (Structured Analysis and Design Technique), Análisis Estructurado y Análisis Orientado al Objeto.

.

Comunicación. Los requerimientos son comunicados oralmente y escritos con el fin de que sean presentados a diversas audiencias para su revisión y aprobación.

La manera más fácil de realizar la especificación del sistema es mediante entrevistas con el cliente, reuniones de trabajo y/o investigación en terreno. Más adelante se describe en términos generales cómo deben realizarse las entrevistas. Con la información obtenida se realiza la construcción del Documento de Especificación de Requerimientos (DER).

4

Proyecto de Software

Especificación de Requerimientos

3.

TÉCNICAS y MÉTODOS DE IDENTIFICACiÓN
Existen variadas metodologías para realizar la identificación de los requerimientos de un sistema. Si la identificación no es lo suficientemente acabada, difícilmente se podrá realizar una especificación adecuada del sistema. La identificación de los requerimientos comprende la interacción entre el equipo de desarrollo y el cliente con el fin de descubrir, revisar, evaluar y comprender las necesidades del usuario y las restricciones sobre el software. Para poder realizar la especificación es necesario poseer toda la información relevante del sistema y la mejor manera de obtenerla es realizando entrevistas con el cliente. Las entrevistas son realizadas para obtener las necesidades del cliente. Para determinar las necesidades del cliente se puede proceder mediante preguntas y respuestas, la presentación de prototipos o una combinación de ambas. Las entrevistas deben ser establecidas con tiempo de tal manera que el equipo de trabajo pueda prepararla y el cliente pueda asistir. Normalmente el cliente no posee la misma disponibilidad de tiempo que el equipo de desarrollo por lo que debe ser avisado con anticipación. Cada entrevista debe ser acompañada de una minuta de reunión. La minuta de reunión contiene el objetivo de la entrevista y los tópicos o problemas que se discutirán. Esta minuta debe ser entregada al cliente con anterioridad a la reunión con el fin de que el cliente asista a la reunión con toda la información necesaria. Como resultado de la reunión se elabora otra minuta que debe ser aprobada por el cliente en la reunión siguiente. Las minutas no sólo permiten hacer las reuniones más productivas, sino que permiten registrar el proceso de entrevistas y los compromisos del cliente y del equipo de trabajo. Este registro puede ser útil para resolver diferencias posteriores en el proceso de desarrollo.

3.1

PREGUNTAS y RESPUESTAS Las preguntas y respuestas son útiles al comienzo de la interacción con el cliente para obtener información importante del sistema. En esta etapa es fundamental que las preguntas permitan "obtener" información, es decir, se deben evitar aquellas preguntas que no son relevantes para la etapa de requerimientos. Por ejemplo, para determinar (y especificar) la funcionalidad de la aplicación no es relevante conocer el lenguaje de implementación. Se debe intentar obtener la funcionalidad (lo que debe hacer el sistema) que desea el cliente. Es responsabilidad del grupo de trabajo elegir a las personas idóneas para las entrevistas además de la elaboración de las preguntas adecuadas. Las entrevistas pueden ser estructuradas y no estructuradas. Las entrevistas estructuradas se asocian a un conjunto de preguntas a las que el usuario debe responder. Las entrevistas no estructuradas por el contrario, son improvisadas con el usuario. A continuación se muestran algunas de las ventajas y desventajas de cada uno de los métodos:

5

Proyecto de Software

Especificación de Requerimientos

VENTAJAS

Asegura la elaboración de un informe de las preguntas para todos los que van a responder. . Fácil de administrar y evaluar Evaluación más objetiva tanto de quienes responden como de las respuestas a las preguntas . Se necesita un limitado entrenamiento del entrevistador . Resulta en entrevistas más

. .

Entrevista

Estructurada

El entrevistador tiene mayor flexibilidad al realizar las preguntas adecuadas a quien responde . El entrevistador puede explotar áreas que surgen espontáneamente durante la entrevista

.

Entrevista

No Estructurada

.

Puede producir información sobre las áreas que se minimizaron o en las que se pensó fueran importantes.

pequeñas

. . .
DESVENTAJAS

.

Alto costo de preparación Los que responden pueden o no aceptar el nivel en la estructura y carácter mecánico de las preguntas. Un alto nivel en la estructura puede o no ser adecuado para todas las situaciones El alto nivel en la estructura reduce responder en forma espontánea, asi como la habilidad del entrevistador para continuar con comentarios hacia el entrevistado

. .

Puede utilizarse negativamente el tiempo, tanto de quien responde como del entrevistador

. Los entrevistadores pueden introducir sus sesgos en las preguntas o al informar los resultados

Puede recopilarse información extraña . El análisis y la interpretación de los resultados puede ser largo . Toma tiempo extra recabarlos hechos esenciales

3.2

PROTOTIPOS Los prototipos constituyen la manera más fácil de validar los requerimientos del sistema

dado que el usuario puede trabajar sobre un elemento concreto y no abstracto como son
los modelos. Según el área de aplicación que se esté analizando el prototipo puede ser distinto. Por ejemplo, en el caso de una aplicación interactiva la descripción de la funcionalidad podría realizarse mediante la presentación de las pantallas, menús, diálogos, etc. En el caso de una aplicación de procesamiento de información el prototipo podría mostrar la información de entrada y la información de salida, sin detallar, necesariamente, el algoritmo asociado. En el caso de una aplicación web, el prototipo podria incluir las páginas del sistema con una simulación de la navegación deseada. Cuando se utilizan prototipos para la identificación de los requerimientos del cliente, ~e incluye una funcionalidad mínima de tal manera que el usuario pueda utilizar el prototipo. Normalmente, durante el proceso de desarrollo, se deben construir varios prototipos. El análisis de requerimientos que debe realizarse previo a la elaboración de los prototipos dependerá exclusivamente de la naturaleza del problema a resolver. Es recomendable que los prototipos sean elaborados exclusivamente para la generación de un conjunto válido de requerimientos; una vez que éstos han sido identificados se deben documentar y continuar con el proceso de desarrollo. Es fundamental encontrar el prototipo adecuado para la presentación ante el cliente. Otra posibilidad para la presentación de prototipos es la elaboración de un manual de usuario preliminar. Dado que el manual presenta la funcionalidad a un usuario cualquiera, que no se encuentra involucrado en el proceso de desarrollo, éste permite identificar errores de interfaz, funcionalidad, etc.

6

Proyecto de Software

Especificación de Requerimientos

4.

TÉCNICAS y MÉTODOS DE ESPECIFICACiÓN
La especificación de requerimientos consiste básicamente en la elaboración de un documento que registre claramente cada uno de los requerimientos del sistema. El Análisis Estructurado y el Análisis Orientado al Objeto constituyen las técnicas y métodos más usuales para realizar la especificación o representación del sistema. Según el ámbito de la aplicación o del sistema que se esté desarrollando, se deben incluir en .el documento de especificación de requerimientos los diagramas que permitan representar y modelar el conocimiento adquirido del sistema. Es importante destacar que en la especificación del documento de requerimientos no se debe incorporar información que este relacionada con la plataforma sobre la cual se vaya a desarrollar el sistema. La información que se debe incluir debe corresponder exclusivamente a las necesidades del cliente y debe representarlas claramente. Normalmente se hace referencia a esta información como el "modelo del negocio".

4.1

ARQUITECTURA

4.2

JERARQuíA FUNCIONAL
El Diagrama de Jerarquía Funcional (DJF) permite representar la funcionalidad deseada de un sistema en un esquema jerárquico. La funcionalidad que se representa en el diagrama de jerarquía funcional corresponde a aquella que desea el usuario o la que se necesita para satisfacer los requerimientos. No se deben incluir funciones (en términos de programación) ya que estas son definidas en el diseño. Normalmente los DJF permiten representar la interacción que es posible realizar con el usuario por medio de menús. Inicialmente los DJF fueron utilizados para representar la interacción con sistemas de tipo consola en los cuales las opciones eran presentadas por pantalla y el usuario debía elegir una opción para acceder a otro menú o para realizar la acción correspondiente. En la actualidad esta interacción puede ser apreciada en los cajeros automáticos. En la Figura 2 se muestra un ejemplo de jerarquía funcional para un cajero automático.
Cajero Automático

Retiro de dinero

Cierre de Cajero

Informes

Figura 2. Ejemplo de Jerarquía Funcional tradicíonal

7

Proyecto de Software

Especificación de Requerimientos

Para sistemas modernos que poseen interfaces con ventanas, menús, diálogos, etc. el diagrama anterior no permite representar la funcionalidad del sistema claramente. Para sistemas de este tipo se puede utilizar un diagrama de jerarquía funcional como el que se muestra en la Figura 3. Este diagrama corresponde un parte de la funcionalidad que provee el Word.
ti ~~,t;~~lr~r!l~.Jn.:~E2i~J2.!m~!1t~~fa¡) !¡¡.b~,V.~~~
J

l
~< Qrtografiay gra.matica.:.

A ~

M...f'..n!e... P:'.r ;>fo...

.~7

f~bm;) c.\)I'1~palb'¡¡¡,.,

---+

~

Q..;lh.. ídlJ~... . 51"OI1lno :. M.yú;+F-7 !jul1ne3... .

~~ ;;;i::f;~:'~.,:3r':_~,:
§ ~k!~:.;:' .' '..,>, '::.' '.

~.;::i;;t~: :
CQn'1\)léI~J;á~~~: '¡J
.c:;J"sotr~ y,e~ta~,;"

.¡jf;':~
1---+

R~n.r,é#ros... :;.~ptilroi~;zamll1bm...
. ~¿,rparartttu~moos...

.

. l?11J""'~~'" .

t~~~i
ifj M16ferrni;t;:..~:'.? ':' ' !i~Ier¡;; eesIJ!as:., , d . . .¡;stib... .~ [-oodo...

:':L;;;~~::'I.E;' ..
.

":c?rr,Q~~~~'"

A~It~W p.;rá.car~;...
'M¡,cr:.~~~~~~--"
.
~

.:. MmQS...

AlttFO
"'~:t¡).:.
All.f 1i

---+.
fJ

¡¡r;.l""r~~
[d,1tr

~ian\JII.$} comeem!!nIOs...

de \lilli~! Bas',:

. PlJl'WOJ"¡ar,,':.. O¡:;cio~ .

Figura 3. Ejemplo de Jerarquía Funcíonal Una vez que se ha realizado el diagrama anterior se deben incorporar descripciones narradas de la opciones existentes. Además de los menús, se pueden incorporar referencias a cuadros de diálogo, cuadros de herramientas, etc. Es necesario considerar que para construir el diagrama de jerarquía funcional es fundamental haber validado un prototipo con el usuario final. Por otro lado, el diagrama anterior no sirve directamente para representar la funcionalidad del un sitio web. Para ello es mejor construir un mapa de navegación.

4.3

DI A GRAMA S DE FLUJO DE DA TOS

Los diagramas de flujo de datos (OFO) permiten desarrollar los modelos del ámbito de la información y del ámbito funcional al mismo tiempo. Los OFO's muestran el flujo de la información (datos) y la transformación (mediante procesos) de ésta en el sistema. Es gracias a los OFO que el análisis estructurado posee las cualidades de ser gráfico, conciso y particionado. Los OFO están compuestos por cuatro elementos: el flujo de datos, el proceso, el repositorio, y el productor/consumidor. Estos elementos se muestran en la Figura 4.

8

Proyecto de Software

Especificación de Requerimientos

Los DFD pueden ser refinados para reflejar mayor conocimiento sobre el sistema. El DFD de nivelO debe reflejar el sistema como una sola burbuja. Para el desarrollo de los siguientes refinamientos se deben tomar en cuenta las siguientes consideraciones: 1. Se debe anotar cuidadosamente la(s) entrada(s) y la(s) salida(s) principal(es) 2. El refinamiento debe comenzar asilando procesos, los elementos de datos y los almacenes de datos que sean candidatos a ser representados en el siguiente nivel. 3. Todas las flechas deben ser rotuladas con nombres significativos. 4. Se deben refinar las burbujas de una en una. Los procesos deben ser refinados de tal manera de generar un DFD para cada proceso. La descomposición no debe reflejar demasiados detalles o aspectos procedurales sobre la información. Se debe refinar hasta un nivel que permita aislar o describir plenamente cada proceso. Para evitar confusiones se pueden numerar los procesos como se muestra en la Figura 6.

~~
1
OFO de NivelO

.1 1.2 1.3
OFOde Nivel 1 para el proceso 1

OFOde Nivel 2 para el proceso 1.1

OFOde Nivel 2 para el proceso 1.2

Figura 6. Refinamientos sucesivos de los DFD
Los almacenes de datos son repositorios de información en el tiempo. Los almacenes se asocian con archivos o bases de datos pero podrían representar también listas, formularios, bandejas, etc. Los almacenes deben estar presentes cuando es necesario comunicar información entre dos procesos que manejan eventos distintos o cuando el sistema requiere "memorizar" la información que manipula. De lo anterior se concluye que los almacenes de datos son necesarios cuando se requiere:

.
.

accesar más de una vez un pedazo de información utilizar información en un orden distinto al que ingresó al sistema

Sobre los almacenes de datos se realizan las operaciones usuales de inserción, recuperación, actualización y eliminación. Es importante destacar que cuando es necesario realizar alguna operación sobre un almacén de datos, no se incluye información ni descripciones sobre las llaves utilizadas. Sólo se debe incluir información sobre los identificadores utilizados (ver 4.6). Esto se debe a que las llaves representan mecanismos de acceso y no flujos de información. Otra razón por la que se omiten las llaves es que no se deben hacer compromisos previos con mecanismos de acceso que deben ser determinados en el diseño. Los productoreslconsumidores representan, respectivamente, de donde viene la información requerida por el sistema y hacia donde va la información producida por el

10

Proyecto de Software

Especificación de Requerimientos

sistema. Un productor es un proveedor de flujos de datos y un consumidor es un receptor de flujos de datos.

4.4

PROCESOS
Todos los procesos relevantes de un proyecto de desarrollo deben ser especificados en la documentación del proyecto. Especialmente aquellos procesos que no sean obvios y que estén muy ligados al negocio que se esté modelando. Una especificación de procesos puede incluir narraciones escritas de los procesos, una descripción del algoritmo mediante lenguaje estructurado, ecuaciones matemáticas, tablas, diagramas y/o gráficos. La especificación de procesos (EP) formal parte de la especificación de los requerimientos. A partir de la EP, el diseñador podrá identificar las componentes de software que implementarán dichos procesos. Normalmente se asocia la EP a la descripción de las burbujas de los DFD, sin embargo, esta idea puede ser ampliada para.describir procesos independientemente del modelo de representación utilizado. Por ejemplo, para describir las acciones necesarias para generar un reporte, para desplegar la información de una página web, etc. A continuación se dan ejemplos de especificación de procesos mediante lenguaje estructurado, árboles de decisión y tablas de decisión. 4.4.1 LENGUAJE ESTRUCTURADO El lenguaje estructurado corresponde a una versión reducida del lenguaje que usamos habitualmente con la incorporación de construcciones de programación estructurada (ifthen-else, while, etc.). El vocabulario comprende:

.

. .

Verbos imperativos (los adjetivos y adverbios son eliminados debido a que son subjetivos y susceptibles de ser mal interpretados. Términos del diccionario de datos Palabras reservadas para reflejar lógica.

En la Figura 7 se muestra la especificación estructurada del proceso "Analizar Triángulo" del DFD que determina si las tres dimensiones ingresadas definen un triángulo.
PROCESO:
dimensiones de los lados del triángulo mensaje de error

Analizar Triángulo

/'
tipo de triángulo

leer dimensiones del triángulo si alguna dimensión es negativa entonces producir mensaje de error si la dimensión más larga es menor que la suma de las otras dos entonces determinar número de lados iguales si hay tres lados iguales entonces tipo es equilátero si hay dos lados iguales entonces tipo es isósceles si no hay lados iguales entonces tipo es escaleno sino tipo = O 1*No existe triángulo *'

Figura 7. Ejemplo de especificación mediante Lenguaje Estructurado
Una de las ventajas de la especificación mediante lenguaje estructurado es que permite mantener la claridad y la consistencia de estilo entre diferentes autores.

11

Proyecto de Software

Especificación de Requerimientos

4.4.2 ARBOLES DE DECISIÓN Hay tipos de procesos para los cuales el lenguaje estructurado no permite la especificación clara y precisa de la transformación realizada a la información. Por ejemplo, si las acciones del usuario dependen de un número importante de variables que a su vez pueden generar un número grande de combinaciones, entonces la descripción mediante lenguaje estructurado será confusa y muy anidada. En esta situación es conveniente utilizar un árbol de decisión que es una herramienta gráfica que separa las condiciones independientes y muestra las acciones resultantes a cada combinación. Como ejemplo, a continuación se muestra la política de ahorro de una empresa ficticia de forma narrada y posteriormente como un árbol de decisión.
"En nuestra empresa, Ficticia Ltda., incentivamos el ahorro de nuestros empleados. Para ello hacemos una contribución a la cantidad que pongan en nuestro plan de ahorro. Además del interés normal, los empleados participantes reciben del Departamento de Finanzas una contribución del 50% de lo que inviertan - siempre y cuando mantengan el monto por más de dos años.
Sin embargo, nosotros limitamos el monto que los empleados pueden ahorrar, dependiendo de sus ingresos y el tiempo de permanencia en la empresa. Un empleado puede ahorrar el cinco, seis o siete por ciento de los primeros $200.000 de su ingresos si ha estado con nosotros un año, dos años, o más, respectivamente. Si ha estado con nosotros un año, puede ahorrar hasta un cuatro por ciento de los siguientes $100.000 Y hasta tres por ciento de cualquier exceso. Los empleados que han estado con nosotros dos ai10S pueden ahorrar el cinco por ciento de cualquier cantidad desde $200.000 a $400.000 y cuatro por ciento para cifras mayores. Personas que han estado mucho tiempo con nosotros pueden ahorrar hasta el siete por ciento de los primeros $200.000 y cinco y seis por ciento para el resto. "

El árbol de decisión de la Figura 8 es mucho más claro y preciso que la versión narrada anterior.
Tiempo de Permanenciaen la Empresa Pocentaje de Ahorro Autorizado
~5% ~ ~3'10 _6% Menos de $200.000 $200.00 $400 00 Más de a $400.00 Menos de $200.000 4%

Rango de Ingreso
Menos de $ 200.00 $200.000 a $300.000 Más de $300.000

Menosde

Ahorro de Ficticia LIda.

Polilica de

(

1 año

1Año a 2Años

L ~ L ~

-5% _4%
_7% -6% ~5'10

Más de 2 Años

~

$200.000 a $400.000 Más de $400 000

Figura 8. Ejemplo de Arbol de Decisión

4.4.3 TABLAS DE DECISIÓN
Una tabla de decisión es una forma tabular de un árbol de decisión. Una tabla de decisión

es más manejable que un diagrama, . sin embargo, es menos comprensible

12

Proyecto de Software

Especificación de Requerimientos

inmediatamente. El árbol anterior, correspondiente a la política de ahorro de la empresa, se representa en la siguiente tabla de decisión: .
Permanencia en la Empresa
Ingresos Porcentaje Autorizado

AÑOS
1 <15 1 1 1-2 < 15 1-2
1-2

>2 <15

>2

>2

15-25 > 25

15-30 > 30

15-30 > 30

5%

4%

3%

6%

5%

4%

7%

6%

5%

Figura 9. Ejemplo de Tabla de Decisión

4.5

DICCIONARIO

DE DA TOS

El análisis incluye la generación de modelos de representación de datos, funciones y control. En cada representación los datos y los ítems de control juegan un rol. Por esta razón es necesario entregar una aproximación organizada para la representación de las características de cada dato y cada ¡tem de control. Esto se logra mediante el diccionario de datos (DD). En particular, el DD debe contener la definición de todos los datos mencionados en los DFD, en la EP o en el mismo DD. El DD ha sido propuesto como una gramática cuasi-formal para la descripción del contenido de los objetos (datos, ítems de control) durante el análisis estructurado. Una definición adecuada del DD es la siguiente:
"El diccionario de datos es un listado organizado de todos los datos que son relevantes para el sistema, con definiciones precisas y rigurosas, de tal manera que, tanto el usuario como el analista, puedan tener una comprensión común de las entradas, salidas, estructuras de almacenamiento y cálculos intermedios"

Hoy en día el DD es implementado directamente en herramientas CASE. A pesar de que el formato varía de una herramienta a otra, todos contienen la siguiente información:

. . . . .

Nombre: nombre identificador del dato, ítem de control, repositorio o entidad externa. Alias: otros nombres o sinónimos utilizados para el nombre. Usado-donde/Usado-como: un listado de los procesos que utilizan el dato o ítem de control y cómo es utilizado (por ejemplo, entrada para un proceso, salida de un proceso, como repositorio, como entidad externa) Descripción: representación gramatical del contenido. Valores/Significados: información adicional sobre tipos de datos, valores predefinidos, restricciones, limitaciones, precisión, etc.

Un elemento de datos es un pedazo de información que no se puede o no se quiere dividir más. A medida que se genera el DD y los elementos son refinados sucesivamente, se identificarán elementos básicos que no pueden seguir siendo refinados. Estos deben ser definidos en términos de los valores (discretos o continuos) que pueden tomar. Por ejemplo:

13

Proyecto de Software

Especificación de Requerimientos

Nombre: Alias: Usado-dondel Usado-como: Descripción: Valoresl Significados:

capacidad de crédito ninguno aceptarCompra(input), capacidadCredito(output) La capacidad de crédito de un cliente es entregada por la Superintendencia de Bancos e Instituciones Financieras, AA = Excelente A = Bueno B = Aceptable e = Pobre D = Deudor DD = Deudor pre-Judicial

La notación que se muestra en la Figura 10 permite representar datos compuestos como una secuencia de ítems, como una selección de un conjunto de ítems o como una agrupación repetida de ítems. Cada ítem que es representado como parte de una secuencia, selección o repetición, puede, a su vez, corresponder a otro dato que requiere mayor refinamiento dentro del DO.
Construcción Secuencia Selección Repetición Notación = [ { + I ] Significado compuesto por Y alguno de n repeticiones de datos opcionales delimitador de comentarios identificador

}n
( ) #

*

*

Figura 10. Notación para la descripción de contenido del Diccionario de Datos A continuación se muestra un ejemplo del DO de un'sistema para una central telefónica:
número teléfono = [ extensión local I número externo) extensión local = [ 2001 I 2002 ... I 2999 ) número externo = 9 + [ número local I número larga distancia] número local = prefijo + número acceso número larga distancia = (1) + código área + número local

prefijo
número acceso

=

[ 795

I 799

I 874

I 877

)

= * cualquier número de cuatro dígitos .

Los ítems del DO pueden ser definidos de muchas maneras. Sin embargo, algunas definiciones son más claras que otras. Por ejemplo, las definiciones siguientes:
factura = folio + dirección + { línea factura} + total línea factura = cantidad + número item + precio unitario + subtotal

son mucho más claras que
factura folío + dirección + { cantidad + número ítem + precio unitario + subtotal } + total

Es importante notar que en la definición del DO se puede incorporar fácilmente el formato de representación de la información, el contenido, la precisión y/o los rangos permitidos.

4.6

MODELO DE DA TOS El modelo de datos permite modelar las entidades (datos) del sistema y las asociaciones (relaciones) existentes entre ellas. Además permite representar las características (atributos) de las entidades y de las relaciones. Normalmente este diagrama se asocia con la representación del modelo conceptual (lógico) de una base de datos, pero puede ser

14

Proyecto de Software

Especificación de Requerimientos

utilizado para modelar la información del sistema aunque no necesariamente se vayan a utilizar bases de datos, por ejemplo, en el caso en que se vayan a utilizar archivos. La notación utilizada en los diagramas de entidad-relación se muestra en la Figura 11.
Nombre

Atributos
I

Entidad A

~
RELACION

rc:::J

ENTIDAD

t t t t 7

t
q~ ~
~

Relación 1 a 1

Relación 1 a 1 (opcional) Relación 1 a muchos

Relación 1 a muchos (opcional) Relación muchos a muchos

EJEMPLOS DE RELACIONES

Figura 11. Notación utilizada en los diagramas Entidad-Relación
Las entidades reciben nombres en singular. Por ejemplo, para una entidad que administra información de clientes, el nombre es CLIENTE y no CLIENTES. Los atributos son incorporados al diagrama a continuación del nombre y no deben hacer referencia al tipo de los atributos. En caso de ser necesario, el tipo de los atributos puede quedar reflejado en el diccionario de datos. El conjunto de atributos que identifican únicamente a una entidad se conocen como Identificadores. Los identificadores se denotan anteponiendo un "#" al nombre del atributo. Las relaciones representan asociaciones entre distintas entidades, pueden tener distintas cardinalidades y pueden ser opcionales. Para reflejar las cardinalidades de las relaciones se agregan símbolos en el extremo de la relación. En la Figura 11 se pueden apreciar algunas combinaciones posibles. La opcionalidad se denota con una "o" en el (los) extremo(s) correspondientes de la relación. En el diagrama entidad-relación se puede incluir información adicional que permite identificar las naturaleza de las relaciones entre las entidades. Por ejemplo, el diagrama de la Figura 12 posee las entidades EMPRESA y PERSONA. La relación entre las entidades posee dos títulos: "Contrata a" y "Trabaja en". La manera de leer las relaciones no está estandarizada, sin embargo, se sugiere que se esto se haga de izquierda a derecha y de arriba hacia abajo. Para el ejemplo anterior, se lee EMPRESA Contrata a PERSONA y PERSONA Trabaja en EMPRESA. Además queda reflejado (para el modelo de la figura) que una empresa contrata a muchas personas y que una persona trabaja en una sola empresa.
PERSONA

EMPRESA
I

Contrata a I

Atributos

'"
Trabajaen

./

Atributos

Figura 12. Ejemplo de Relación entre Entidades
Cuando se realiza la construcción del diagrama entidad-relación no se debe incluir información que se escape al ámbito de los datos esenciales del sistema. Dentro de esta

15

Proyecto

de Software

Especificación de Requerimientos

información se incluyen las llaves foráneas, tablas de resolución de relaciones muchos a muchos, índices, etc. Estos elementos son definidos en la etapa de diseño considerando todos los requerimientos y la plataforma sobre la cual se construirá el sistema. Es importante destacar que el identificador definido en el modelo lógico no corresponde necesariamente a la llave de la entidad en el modelo físico que será definido en el diseño. Esto se debe normalmente a la incorporación de llaves foráneas o la modificación de la llave primaria por consideraciones de diseño. Por ejemplo, en el modelo lógico, se puede establecer que un cliente es identificado por su rut y en el modelo físico éste es identificado por una secuencia o entero.
EMPRESA # rul razon social dirección leléfono Conlrala a Trabaja en PERSONA #rul nombre dirección leléfono

EMPRESA # sec_empresa rul razon_social direccion lelefono inleger
varchar( 1O)

PERSONA sec_empresa

4

=sec_empresa

varchar(30) varchar(100) varchar(7)

# sec_persona sec_empresa rul nombre direccion teléfono

inleger inleger varchar(12) varchar(20) varchar(100) varchar(7)

Figura 13. Diferencia entre el Modelo Lógico y el Modelo Físico En la figura Figura 13 se puede apreciar esta situación. En el modelo físico la entidad persona es identificada por un número entero correlativo. En esta situación, por ejemplo, podría darse el caso de que una persona podría estar en el sistema (y ser identificable) sin tener necesariamente un rut. En la elaboración del modelo lógico se debe intentar identificar toda la información (datos) relevantes del problema. Además de las entidades y relaciones, que corresponden al ámbito del sistema y del negocio, hay otros elementos que deben ser identificados. Algunos de éstos elementos son:

. . .

Usuarios/Roles/Permisos Dominios Parámetros

Usuarios/Roles/Permisos corresponde a la identificación de los usuarios que pueden usar el sistema. Esto puede ser necesario para controlar el acceso, registrar las acciones realizadas por los usuarios, etc Esta información normalmente está disponible en la organización pero en determinadas ocasiones, y según el tipo de sistema que se esté construyendo, puede ser necesario un sistema de control de acceso especial. Además de la identificación, cada usuario además debe tener permiso para realizar un conjunto determinado de acciones. Cada combinación de estos permisos se conoce como un rol. Los roles corresponden, entonces, a la identificación de ciertos permisos estándares para los usuarios. Normalmente los roles pueden ser mapeados directamente a la estructura jerárquica de la organización: Gerente, Sub-Gerente, Administrador, Secretaria, etc. Dominios corresponde a la identificación de conjuntos estructurados que pueden ser utilizados para identificar entidades, estructurar respuestas, registrar acciones realizadas, reflejar estados, etc. Normalmente un dominio surge cuando es posible estructurar alguno de los atributos de una entidad, por ejemplo, el tipo de un auto. Sin embargo, tambiEm pueden ser utilizados, por ejemplo, para estrúcturar el conjunto de respuestas disponibles para un usuario. En la tabla siguiente se muestran algunos ejemplos de dominios.

16

-

-

-

-

..,.

éjúe--éieiermiríaenüñdonamienf6-'deTñifsrrio-:En--Ia -Ti:ib"ias¡~jüieñ(e"se-müestran-'a(gunos
..o.~.~oo:\.l~.~
..~~".6..~"'o:.-?oC". ~--- +------

-

18

Proyecto de Software

Especificación de Requerimientos

4~::i~~l~i~~t1..;liti:~f¿:ftI~~~~j~¿;2~
¡
; I " ..'\\tml~:;:~.'J.,~IO('.>f
'_It

~.4Itnio,

'

"

rt""'

,

;t~n¡\~1

". tu:Ht.t.V" .: ..,."..tMt , ,,-~., . ~~I~~~'~;,~rf--.U.U , ..,w, t..tft!ON............ """: it~~:~~,~\~:',~~~:~:;:..:.~~'ti
~r..,t¡;;r4...t,.!..«U1!-~

.'

;.;t.

. 'H
'1

Pwd Ok

,.....

i~=-':::~:,
.,
.. Y'',.'-.

rt1
------...........
. .' o..~

~
..."'~ h....

.

...""

,

..". ~ ,

.' ~... '"

'.,,-

A

"-'-

..Jv>

,., ,............... .',

";'''':.:\,''~

\;'_1

Compose

Inbox

Proyecto

de Software

Especificación de Requerimientos

4.10

MODELO CONCEPTUAL

Pendiente

4.11

DIAGRAMAS DE SECUENCIA Pendiente

4.12

ARCHIVOS

. .
. .

En algunas ocasiones el cliente puede requerir que el sistema sea capaz de trabajar con archivos con un formato determinado. Esto con el fin de: Importar informacióndesde otros sistemas Exportar información hacia otros sistemas
Guardar la información del sist~ma en un formato determinado (.jpg, .gif, p.df, .html) Leer información desde un formato determinado (.jpg, .gif, .pdf, .html)

En estos casos es necesario describir completamente el formato de los archivos de tal manera de satisfacer las necesidades de comunicación del software. En el caso de los formatos estándares como .gif, .jpg, .html, .pdf, etc., basta con incluir una referencia a la descripción de los estándares disponible en el web o en referencias escritas. Cuando el formato no es estándar y corresponde a un formato propio de la organización (definido o por definir) es necesario describirlo completamente. El formato de los archivos incluye la descripción de los siguientes elementos: a) b) c) d) e) Formato del archivo Distribución del archivo Dependencias de los datos Formato y precisión de los datos Condiciones de error del archivo

El formato del archivo describe si la información almacenada está en formato texto o binario. En el caso en que la información esté almacenada en formato binario será necesario describir la estructura de todos los registros utilizados. En el caso de que la información esté almacenada en formato texto seria necesario incorporar información sobre los delimitadores de los campos. Por ejemplo:
TEXTO
SEPARADOR DE CAMPOS I ------------------------------------------------------109875431 I Ficticia Ltda.
I

BINARIO CLIENTE (
char[12] .. . ) char[30] char[50]

rut
ra::on social direccion

Av.

Departamental

La distribución corresponde a la descripción de la distribución de los datos al interior del archivo. En términos generales se puede describir con diagramas o archivos ejemplo que permitan comprender la distribución de las distintas secciones. Por ejemplo, un archivo que contiene información sobre un grafo podría contener la siguiente distribución:

24

Proyecto de Software

Especificación de Requerimientos

ARCHIVO N A 1 SANTIAGO : : N PUERTO MONTT 1 1 2 45.00 2 1 3 23.12 : : A 20 18 34.23

DESCRIPCION Número de Nadas (N), Número de Arcos (A) N líneas con información sobre los nadas.

Cada línea posee el número del nodo y su descripción.

A líneas con información

sobre los arcos.

Cada línea posee el número del arco, nodo inicial, nodo final y peso.

Las Dependencias corresponde a la descripción de las relaciones existentes entre los datos de una misma sección o de distintas secciones. Dentro de estas dependencias se pueden incluir variación en el contenido de la información u omisión de información. Por ejemplo, un archivo de configuración que describe los colores que deben ser utilizados para darle color a las caras de ciertos tipos de poliedros:
ARCHIVO 1246 23568911 325246734 DESCRIPCION Para cada tipo de poliedro se incluye una línea. Cada linea posee un número de tipo de poliedro y los índices de color para cada cara. Los tipos de políedro son: 1 = Triángulo 2 = Cubo 3 = Tetraedro

En el caso anterior la dependencia queda establecida por el hecho de que cada línea posee un número variable de colores y que depende exclusivamente del tipo de poliedro. Esto se traduce en que el programa que lee o escribe el archivo debe considerar el tipo de poliedro para poder leer o escribir correctamente. El Formato y Precisión debe dejar claro el formato de los datos (alineación, mayúsculas, minúsculas, etc.) y la precisión. La precisión está relacionada con la manera en que guardarán los número con decimales. Por ejemplo, el número 3.14 puede ser escrito como 3.14 o como 314E-2. También es importante determinar el número de decimales que deben ser incorporados. Las Condiciones de Error tienen relación con las condiciones de integridad del archivo, es decir, cuáles son las circunstancias que determinan que un archivo sea válido o no. Siguiendo el ejemplo anterior sobre la descripción del grafo, una condición de integridad sería el hecho de que debe haber tantas líneas de nadas y de arcos como las indicadas en la primera línea. Otro ejemplo seria el hecho de que el programa sólo acepta 50 nadas como máximo (por restricciones de diseño por ejemplo) y por lo tanto se debe validar el número de nadas indicados en la primera línea. Además de indicar las condiciones de integridad, es necesario incluir información sobre el tipo de errores que se desea mostrar al usuario. Es decir, se desea un mensaje que diga "Archivo Inválido" o se desean mensajes del tipo "Error: el número de nadas supera el máximo permitido", "Error: faltan nadas", "Error: faltan arcos".

25

Proyecto de Software

Especificación de Requerimientos

5.

DOCUMENTO DE ESPECIFICACiÓN DE REQUERIMIENTOS
El contenido del Documento de Especificación de Requerimientos (DER) depende normalmente del tipo de sistema que se esté analizando y del tipo de análisis que se esté utilizando. En esta sección se describen tres plantillas: una para análisis funcional o estructurado, una para análisis orientado al objeto y una para sistemas web. Estas se encuentran en los Anexos A, B Y e respectivamente. Durante la elaboración e identificación de los requerimientos del sistema se debe escoger el tipo análisis que se llevará a cabo y, como consecuencia de esto, se debe incluir la información y los diagramas que correspondan. Debido a que el DER debe ser "alidado por el cliente, éste debe poseer las siguientes características:

.

.

.

Modular: debe permitir la modificación fácil de las distintas secciones de tal manera de permitir mantener el documento actualizado ante los cambios en los requerimientos surgidos durante la ejecución del proyecto. Compacto: la información debe ser entregada completa y reducida de tal manera de no aumentar el tamaño del documento innecesariamente. Para ello es fundamental la utilización de diagramas, tablas, figuras, etc. Esto es un elemento fundamental ya que el documento debe ser leído y validado por el cliente. Si el documento es muy extenso puede provocar retrasos innecesarios en el proyecto. Coherente: los requerimientos deben estar descritos de un manera legible y de menor a mayor detalle de tal manera de facilitar la comprensión del problema.

El DER permite documentar las necesidades del sistema. Es el resultado de la interacción con el cliente y describe plenamente la funcionalidad de la aplicación. El documento debe ser escrito en tercera persona. No debe contener lenguaje técnico ni detalles de diseño. Debe centrarse exclusivamente en lo que se desea que resolver o apoyar. Las plantillas presentadas a continuación son una guía de los puntos que deben ir en el documento de requerimientos, sin embargo, es posible que el cliente requiera la inclusión de información adicional. En caso de ser así, ésta información deberá ser adjuntada siguiendo los estándares de documentación utilizados por el cliente. En caso de que el cliente no posea estándares de documentación o éstos no sean los adecuados, se deberá llegar a un acuerdo sobre la manera en que se realizará la documentación correspondiente. Además se deben omitir aquellas secciones indicadas en las plantillas que no sean aplicables al sistema que se esté desarrollando. El DER presenta los requerimientos de una manera coherente y estructurada de menor detalle a mayor detalle de una forma gradual. Normalmente al principio del documento se incluye una descripción general que permite comprender el sistema. La descripción general es similar para todos los tipos de proyectos y es la que se describe a continuación (ver plantillas en los anexos).

5.1

DESCRIPCiÓN GENERAL La sección Introducción debe proveer una visión general del DER. A continuación se describen las secciones que contiene.

.

La sección Propósito debe dc!inear el propósito y la audiencia a la cual está dirigida el documento.

26

Proyecto de Software

Especificación de Requerimientos

.

La sección Alcance del Proyecto debe identificar el software que se va a producir por medio de un nombre (por ejemplo, Generador de Reportes, Host DBMS, etc.). Debe explicar lo que hará y, en caso de ser necesario, lo que no hará el software. Además debe describir los objetivos, beneficios relativos y metas del producto. Las sección Glosario: Definiciones, Acrónimos y Abreviaciones debe proveer la definición de todos los términos, acrónimos y abreviaciones necesarios para interpretar adecuadamente la información incluida en el documento. Esta información puede ser incorporada directamente, mediante referencias a algún anexo ó mediante referencias a otros documentos. La sección Referencias debe proveer una lista de todos los documentos externos utilizados para la elaboración del documento. Debe identificar cada documento por medio de un título, fecha y organización que lo publica. Además, debe identificar las fuentes de las cuales pueden obtenerse los documentos. Por ejemplo, si se utiliza algún estándar de programación externo o se utiliza información proveída por el cliente para la elaboración del documento, entonces debe quedar consignado en esta sección. La información se puede incluir como referencias a anexos del DER o como referencias a otros documentos. La sección Contenidos describir la información que contiene el documento y cómo ésta está organizada. Por ejemplo, "El capítulo 1 entrega información necesaria para la comprensión del El capítulo 2 describe en términos generales el producto y El capítulo 3 describe la funcionalidad del producto siguiendo una metodología "
oo.

.

.

.

La sección Descripción General debe describir los factores que afectan el software y los requerimientos. Esta sección no incluye descripciones de los requerimientos específicos, sino que provee una base para la comprensión de los mismos (que son descritos en la sección siguiente del DER).

.

La sección Contexto del Producto debe describir la interrelación del software con otros sistemas. Si el producto es totalmente independiente, esto deberá consignarse de igual forma. Si el DER describe un software que es componente de un sistema mayor, entonces esta sección deberá relacionar requerimientos del sistema mayor con funcionalidad del software y deberá identificar las interfaces entre ese sistema y el software. La sección Funciones del Producto debe proveer un resumen de las funciones más importantes del software. Por ejemplo, una aplicación de contabilidad podría hacer mención a la mantención de cuentas corrientes, balances de cuentas y estados de cuenta sin mencionar los detalles que cada una de las funciones anteriores requiere. Las funciones deben ser organizadas de tal manera que la lista de funciones sea entendible por el cliente o por cualquier otra persona que lea el documento por primera vez. La sección Características de Usuario debe describir las características generales de los usuarios potenciales del sistema, incluyendo nivel educacional, experiencia y manejo técnico del ámbito de aplicación. La sección Restricciones debe incluir toda la información que limita en algún sentido la implementación del sistema. Esta información puede incluir normas de regulación, limitaciones de hardware, limitaciones de software, interfaces hacia otras aplicaciones, operaciones paralelas, funciones de auditoría, funciones de control, protocolos de comunicación, requerimientos de funcionamiento, factores críticos y/o consideraciones de seguridad.

.

.

.

27

Proyecto de Software

Especificación de Requerimientos

. La sección Dependencias y Supuestos debe describir aquellos factores que afectan los
requerimientos establecidos en el DER. No corresponden a factores que pueden afectan el diseño, sino más bien a aquellos factores que al ser modificados afectan los requerimientos. Por ejemplo, un supuesto podría ser la existencia de algún sistema operativo particular para la plataforma de desarrollo. En caso de que este sistema operativo no estuviera disponible, entonces el DER debería ser modificado adecuadamente. La sección Requerimientos Específicos debe incluir el detalle de los requerimientos del sistema de tal manera que se pueda diseñar un sistema que los satisfaga y los ingenieros de prueba puedan probar que el sistema los satisface. La información de ésta sección dependerá del metodología de desarrollo elegida. A continuación se describe el contenido de los requerimientos específicos correspondiente al análisis estructurado o funcional. En las sección 5.4 se describe las plantilla correspondiente al análisis orientado al objeto y en la sección 5.5 se describe la plantilla para aplicaciones web.

5.2

DESCRIPCIÓN DE ELEMENTOS COMUNES Las plantillas mencionadas anteriormente poseen algunas secciones comunes. A continuación se describe el contenido de aquellas secciones. La sección Requerimientos de Interfaces Externas debe describir detalladamente las entradas y las salidas del sistema. Debe complementar las descripciones de interfaces señaladas en la sección 2 de la plantilla y no debiera repetir información.

.

La sección Interfaces de Usuario debe describir los requerimientos del cliente para la interacción de la aplicación co,, el(los) usuario(s). En el caso más simple, esta sección puede verse reducida a una referencia al estándar de interfaz, definido por el cliente, al interior de su organización. En el caso más complejo, puede ser necesario definir un estándar nuevo o adecuado a la nueva aplicación. En caso de ser así, éste deberá ser discutido y autorizado por el cliente.
La sección Interfaces de Hardware debe describir todos los requerimientos de

.

interacción de la aplicación con elementos de hardware externos. Ejemplos de estos elementos podrian ser balanzas mecánicas, sensores ópticos, sensores térmicos, motores, etc. La interacción con elementos de hardware externos podria realizarse mediante conexiones directas por medio de puertas seriales paralelas, y/o tarjetas. En cualquiera de los casos anteriores, es necesario identificar plenamente el mecanismo de interacción. Para ello se debe especificar el formato de la información enviada y/o recibida. Por ejemplo, si tuviéramos un computador conectado a una sensor magnético, seria necesario identificar cómo el sensor magnético avisa al computador la existencia de una tarjeta magnética. Por otro lado, el computador debe informar al sensor, el procesamiento exitoso de la operación (por ejemplo, para encender alguna luz como señal). Al igual que la sección anterior, ésta puede reducirse a una referencia a algún documento determinado.

.

La sección

Interfaces

de

Software

debe

describir

todos

los

requerimientos

de

comunicación de la aplicación con elementos de software externos o ya existente. Por ejemplo, si se va a desarrollar un sistema de facturación, éste debiera ser capaz de comunicarse con los sistemas ya existentes de la organización que están relacionados, como por ejemplo, el sistema de recaudación, el de contabilidad o el de control de inventario. Normalmente esta comunicación se da cuando una aplicación debe importar/exportar información desde/hacia una base de datos compartida, sin embargo, también puede ser necesario que esta comunicación se realice mediante archivos de traspaso. Por ejemplo, se desarrolla una aplicación para la administración de clientes de una empresa y se desea que el sistema permita el envío de fax a los clientes para el día 28

Proyecto de Software

Especificación de Requerimientos

de su aniversario. Una posibilidad para resolver lo anterior, en vez de intentar programar la interacción con el fax/módem, es la de generar un archivo temporal con la información de los clientes que están de aniversario de tal manera que el software del fax/módem pueda importar la información y realizar los envíos correspondientes. La interfaz de comunicación consistirá, entonces, en la descripción del formato que debe poseer el archivo para que el software del fax/módem pueda realizar la importación.

.

La sección

Interfaces

de Comunicación

debe describir

todos los requerimientos

de

comunicación de la aplicación mediante una red con otros elementos de software o de hardware existentes. La interfaz se limita a la descripción de los protocolos de comunicación, direcciones asociadas, mecanismos de control de errores, mecanismos de seguridad, etc. Esta información normalmente debiera estar disponible en la organización. Un ejemplo de esta situación sería el caso en que se estuviera construyendo una aplicación distribuida para un banco. En este caso, sería necesario describir completamente cómo el sistema haría uso de las redes existentes y los protocolos de comunicación (propios y estándares) para comunicarse con las sucursales y la central. Cada uno de los elementos descritos en las secciones anteriores debiera incorporar la siguiente información: a) b) c) d) e) f) g) h) i) j) k) 1) Nombre del ítem Descripción del propósito Fuente de la entrada o destino de la salida Rangos válidos, precisión y/o tolerancia Unidades de medida Tiempos Relación con otras entradas y otras salidas Organización y formatos de las pantallas Organización y formatos de las ventanas Formatos de los datos Formato de los archivos Formatos de los comandos

Para el caso de la plantilla de análisis funcional, la sección Requerimientos Funcionales debe describir las acciones fundamentales que deben realizarse con el fin de aceptar la entrada, procesar y generar las salidas. Estas acciones normalmente son descritas de la forma "El sistema deberá ...n.Además debe incluir: a) Validaciones en la entrada b) Secuencia exacta de las operaciones c) Reacciones ante situaciones anómalas, incluyendo Overflow Facilidades de Comunicación Manejo y Recuperación de Errores d) Efecto de los parámetros e) Relación de las salidas a las entradas, incluyendo Secuencias de Entradas/Salidas Fórmulas para convertir las entradas en salidas Puede ser útil descomponer los requerimientos funcionales en subfunciones o subprocesos. Esto no implica necesariamente que el diseño del software vaya a ser particionado de igual forma.

29

Proyecto de Software

Especificación de Requerimientos

La sección Requerimientos de Pendimiento debe describir los requerimientos numéricos estáticos y dinámicos para el sistema o para la interacción de los usuarios con el sistema. Los requerimientos numéricos estáticos podrían ser: a) Número de usuarios simultáneos que debe soportar el sistema b) Volumen y tipo de información que debe ser procesada Los requerimientos numéricos dinámicos podrían incluir: a) Número de transacciones a ser procesadas b) Número de tareas que se deben procesar c) Volumen de información que debe ser procesado tanto para períodos normales como para períodos peak de operación. Cada uno de los requerimientos anteriores deberá especificarse en términos medibles. Por ejemplo, "95% de las transacciones deberán ser procesadas en menos de 1 s" en vez de "Un operador no deberá tener que esperar a que la transacción termine". Todas los requerimientos anteriores deben especificarse en común acuerdo con el cliente y deben reflejar sus necesidades. La sección Restricciones de Diseño debe describir las restricciones de diseño que pueden producirse debido a estándares específicos, limitaciones de hardware, software, etc. La sección Atributos de Sistema debe describir los atributos del sistema de tal manera que éstos puedan ser verificados objetivamente. A continuación se incluyen algunos ejemplos:

. .

Confiabilidad: debe especificar los factores que permiten determinar la confiabilidad del sistema al momento de su entrega. Disponibilidad: debe especificar los factores que aseguran un determinado nivel de disponibilidad para el sistema. La disponibilidad está determinada por el tiempo de uso esperado del sistema. Seguridad: debe especificar los factores que protegerán al sistema de uso accidental, modificación y/o destrucción. Ejemplos de esto podrían ser técnicas de criptografía, mantención de registros históricos, asignación de ciertas funciones a distintos módulos, restricción de las comunicaciones entre distintos módulos del programa, revisión de integridad para variables críticas. Mantenibilidad: debe especificar atributos del software que aseguren la mantención del mismo. Podría haber algún requerimiento de modularidad, de interfaz, complejídad, etc. No se deben incorporar requerimientos como resultado de la aplicación de buenas prácticas de diseño. Portabilidad: debe especificar atributos del sistema relacionados con el traspaso del sistema a otro hardware y/o sistema operativo. Esto podría incluir: a) b) c) d) Porcentaje de componentes con código dependiente de la máquina. Porcentaje de código dependiente de la máquina. Utilización de un lenguaje portable. Utilización de un sistema operativo particular.

.

.

.

La sección Requerimientos Adicionales debe incorporar información que no haya sido posible incluir en alguna de las secciones anteriores.

30

Proyecto de Software

Especificación de Requerimientos

5.3

DESCRIPCIÓN DE LA PLANTILLA PARA ESPECIFICACIÓNFUNCIONAL La plantilla para la especificación funcional está disponible en el Anexo A. El punto 4.1 de funcionalidad debe describir la funcionalidad que se desea satisfacer. En el caso de aplicaciones con interacción mediante pantallas esto se reduce a la descripción de las pantallas del prototipo. Para cada pantalla se debe describir la información desplegada y el tipo de interacción posible (habilitación/deshabilitación de botones, opciones de menús, etc.). En el caso de aplicaciones sin interfaz visual (que poseen interacción mediante una línea de comandos, son procesos batch, etc.) la funcionalidad queda descrita indicando las opciones disponibles y algunas ejecuciones ejemplo. De esta manera el prototipo correspondería a una entrada, combinaciones de parámetros y varias salidas distintas. Los otros puntos están claros y no serán descritos en detalle.

5.4

DESCRIPCIÓN

DE LA PLANTILLA. PARA ESPECIFICACIÓN

ORIENTADA AL OBJETO

La plantilla para especificación orientada al objeto está en el Anexo B. El punto 4.1 debe contener los Use-Case para todas las interacciones con el sistema. Lps diagramas pueden ser incorporados aquí directamente o en los anexos. El punto 4.2 corresponde a los reportes que debe generar el sistema. El punto 4.3 corresponde a los díagramas de secuencia asociados a los use-case existentes. El punto 4.4. corresponde a la descripción del modelo conceptual de clases. Aqui se debe incorporar el modelo conceptual completo y posteriormente una descripción de las clases existentes.

5.5

DESCRIPCIÓN DE LA PLANTILLA PARA ESPECIFICACIÓNDE APLICACIONES WEB La tecnología Web es bastante reciente y por lo tanto no existen en la actualidad mecanismos definidos de especificación para este tipo de proyectos. Las aplicaciones web son un caso particular de las aplicaciones hypermediales. En la actualidad la metodología de especificación más utilizada es el RMM (Relationship Management Methodology) que se describe a continuación. El proceso de modelamiento de aplicaciones hypermediales puede ser dividido en tres niveles: almacenamiento, lógico y presentación como se muestra en la Figura 19. El nivel de almacenamiento describe cómo se almacena la información, en términos de qué aplicaciones de software (por ejemplo, bases de datos, editores, etc.) son necesarias, qué archivos son utilizados, la estructura de los directorios, etc.

31

Proyecto de Software

Especificación de Requerimientos

Archivos

Graficos

Páginas

HTML

19 -------Revista

Contactos

u

Nivel de Presentación

Nivel Lógico

Nivel de Almacenamiento

Figura 19. Niveles de Modelamiento de Información de más a menos abstracto.
El nivel lógico describe la estructura de la información que manipula el sistema hypermedial. Elementos de la estructura son, por ejemplo, tablas de una base de datos, entidades y relaciones; objetos y métodos. El nivel de presentación define como la información es presentada a los usuarios. En este nivel se define que información debe ser agrupada en pantallas (o unidades de presentación) y cómo se realiza la navegación a través de ellas. Usualmente las distinciones entre los distintos niveles no son claras produciendo dificultades para el desarrollo y la mantención del software. Para el caso de aplicaciones web, los elementos que las componen son los siguientes: a) b) e) d) Páginas HTML Modelo E-R, Estructura de Directorios. Mapa de Navegación

En la sección de requerimientos funcionales se debe describir el tipo de funcionalidad que se desea tener en el sistema. El punto 4.1 corresponde a la descripción de páginas y para cada página se deben describir los siguientes elementos: a) b) e) d) e) Links Formularios Imágenes Applets Elementos dinámicos: JavaScript, Jscript, VBScript, etc.

El punto 4.2 corresponde a la descripción de los reportes que debe generar el sistema. El unto 4.3 corresponde a la descripción de los procesos que deben ser realizados durante la utilización del sistema. Aquí es importante destacar en que condiciones se realiza la activación de las procesos. Por ejemplo, algunos procesos pueden ser realizados al seguir un link, al cargar una página, al responder un formulario, al presionar un botón, etc.

32

Proyecto de Software

Especificación de Requerimientos

6.

COMENTARIOS

FINALES

El documento de especificación requerimientos no debe incluir todas las secciones señaladas anteriormente. Los responsables de la elaboración del documento deberán eliminar la información que no es aplicable o incluir aquella que no ha sido indicada anteriormente. Además deberán incluir toda la información que el cliente requiera o estime conveniente. Los responsables de la elaboración del documento de requerimientos deberán ser capaces de dejar claramente establecidos los objetivos del sistema siguiendo todas las pautas señaladas en la sección 4. El tiempo invertido en la elaboración de este documento determina los resultados obtenidos. Si el documento es claro, preciso y representa perfectamente los objetivos del sistema, las etapas siguientes pueden ser enfrentadas con mayor eficiencia. En caso contrario, se requerirá de un esfuerzo mayor en las etapas de diseño y codificación. El documento de requerimientos debe ser validado por parte del cliente y no será aceptado hasta que el cliente no haya dado su aprobación. Este manual está en construcción y las sugerencias, comentarios, dudas y/o consultas los pueden hacer llegar a abertini@dcc.uchile.cl.

33

Proyecto de Software

Anexo A

Anexo A
PLANTILLA PARA ESPECIFICACiÓN FUNCIONAL

1. Introducción 1.1. Propósito 1.2. Alcance del Proyecto 1.3. Glosario: Definiciones,Acrónimosy Abreviaciones 1.4. Referencias 1.5. Contenidos 2. Descripción General 2.1. Contexto del Producto 2.2. Funciones del Producto 2.3. Características de los Usuarios 2.4. Restricciones 2.5. Dependencias y Supuestos 3.1. Interfacesde Usuario 3.2. Interfacesde Hardware 3.3. Interfacesde Software 3.4. Interfacesde Comunicación 4. Requerimientos Funcionales 4.1. Funcionalidad 4.1.1. Pantalla1/lnteracción1 4.1.2. Pantalla2/lnteracción 2
4.2. Reportes 4.2.1. Reporte 1 4.2.2. Reporte 2

3. Requerimientos de Interfaces Externas

4.3.

Flujos de Información 4.3.1. DFD 1 4.3.2. DFD2

4.4.

Descripción de Procesos 4.4.1. Proceso 1 4.4.2. Proceso 2

4.5.

Descripción de los Datos 4.5.1. Entidad 1 4.5.2. Entidad 2

4.6.

Diccionariode Datos

5. Requerimientos de Rendimiento
6. Restricciones de Diseño 7. Atributos de Sistema 8. Requerimientos Adicionales

34

Proyecto de Software

Anexo A

9. Anexos . Flujos de Datos . Jerarquía Funcional . Modelo de Datos Lógico . Descripción de Procesos . Pantallas del Prototipo . Descripción de Archivos

35

Proyecto de Software

Anexo B

Anexo 8
PLANTILLA PARA ESPECIFICACiÓN ORIENTADA AL OBJETO

1. Introducción
Propósito Alcance del Proyecto Glosario: Definiciones, Acrónimos y Abreviaciones Referencias Contenidos 2. Descripción General 2.1. Contexto del Producto 2.2. Funciones del Producto 2.3. Características de los Usuarios 2.4. Restricciones 2.5. Dependencias y Supuestos 3. Requerimientos de Interfaces Externas 3.1. Interfaces de Usuario 3.2. Interfaces de Hardware 3.3. Interfaces de Software 3.4. Interfaces de Comunicación 4. Requerimientos Funcionales 4.1. Use-Case 4.1.1. Use-Case 1 4.1.2. Use-Case 2 1.1. 1.2. 1.3. 1.4. 1.5.

4.2.

Reportes 4.2.1. Reporte 1 4.2.2. Reporte 2

4.3.

Diagramas de Secuencia 4.3.1. Diagrama de Secuencia 1 4.3.2. Diagrama de Secuencia 2

4.4.

Modelo Conceptual 4.4.1. Descripción 4.4.2. Clase/Objeto 1 4.4.3. Clase/Objeto 2

5. Requerimientos de Rendimiento 6. Restricciones de Diseño 7. Atributos de Sistema 8. Requerimientos Adicionales 9. Anexos . Modelo Conceptual . Diagramas Use-Case . Diagramas de Secuencia

36

Proyecto de Software

Anexo B

.
.

. . .

Diagramas de Clase Modelo de Datos Lógico Diccionario de Datos Pantallas del Prototipo Descripción de Archivos

37

Proyecto de Software

Anexo

e

Anexoe
PLANTILLA PARA ESPECIFICACiÓN DE APLICACIONES WEB

1.

Introducción
1.1. 1.2. 1.3. 1.4. 1.5.

Propósito Alcance del Proyecto Glosario: Definiciones, Acrónimos y Abreviaciones Referencias Contenidos 2. Descripción General 2.1. Contexto del Producto 2.2. Funciones del Producto 2.3. Características de los Usuarios 2.4. Restricciones 2.5. Dependencias y Supuestos 3. Requerimientos de Interfaces Externas 3.1. Interfaces de Usuario 3.2. Interfaces de Hardware 3.3. Interfaces de Software 3.4. Interfaces de Comunicación

4. Requerimientos Funcionales
4.1. Descripción de Páginas 4.1.1. Página 1 4.1.2. Página 2 4.2. Reportes 4.2.1. Reporte 1 4.2.2. Reporte 2

4.3.

Descripción de Procesos 4.3.1. Proceso 1 4.3.2. Proceso 2

4.4.

Descripción de los Datos 4.4.1. Entidad 1 4.4.2. Entidad 2

5. 6. 7. 8. 9.

4.5. Diccionariode Datos Requerimientos de Rendimiento Restricciones de Diseño Atributos de Sistema Otros Requerimientos Anexos Mapa de Navegación . Descripciónde Procesos . ModeloLógicode Datos

.

38

Proyecto de Software

Anexo

e

.
.

Diccionario de Datos Descripción de Archivos

39

Proyecto de Software

Anexo

O

Anexo D
CHECKLlST DE REVISiÓN DE REQUERIMIENTOS

Los requerimientos deben intentar describir completamente el sistema que se desea construir. Las preguntas siguientes son una ayuda para determinar si se ha realizado un trabajo completo en la etapa de especificación de requerimientos. CONTENIDO DE LOS REQUERIMIENTOS ¿Se ha especificado el objetivo del sistema? ¿Se han especificado todas las entradas del sistema incluyendo su fuente, precisión, rango de valores y frecuencia? ¿Se han especificado todas las salidas del sistema incluyendo su destino, precisión, rango de valores, frecuencia y formato? ¿Se ha construido el modelo lógico de datos? ¿Se han identificado los dominios del modelo de datos? ¿Se han identificado los parámetros del sistema? ¿Se ha construido el mapa de navegación? ¿Se ha descrito cada página del mapa de navegación? ¿Se han especificado todos los reportes del sistema? ¿Se ha definido el tipo de administración que requiere el sistema? ¿Se han especificado todas las interfaces externas de hardware y de software? ¿Se ha especificado el tiempo de respuesta, desde el punto de vista del usuario, para todas las operaciones que lo requieren? ¿Se ha especificado toda la funcionalidad que debe satisfacer el sistema? ¿Se ha especificado para cada proceso los datos utilizados y los datos entregados por el proceso? ¿Se han identificado los usuarios del sistema? ¿Los usuarios finales? ¿Se han definido los roles del sistema? ¿Se ha especificado el nivel de seguridad del sistema? ¿Se ha especificado la confiabilidad incluyendo las consecuencias de una caida del software, información vital protegida, detección de errores y recuperación? ¿Se ha incluido la definición de éxito y de fracaso para los procesos del sistema? ¿Se ha especificado la mantenibilidad del sistema, incluyendo la capacidad de responder a cambios en el ambiente de operación, interfaces con otros sistemas, precisión, rendimiento y otras capacidades predecibles? SI No

COMPLETITUD DE LOS REQUERIMIENTOS ¿En donde la información no está disponible antes del desarrollo, se han especificado las áreas de deficiencia? ¿Están los requerimientos completos en el sentido de que si el sistema satisface los requerimientos, éste será aceptable? ¿Hay disconformidad acerca de algún requerimiento? ¿Hay partes imposibles de implementar o incluidas sólo para satisfacer al cliente?

SI

No

40

Proyecto de Software

Anexo O

CALIDAD DE LOS REQUERIMIENTOS ¿Están los requerimientos descritos en lenguaje del usuario? ¿Lo cree así el usuario? ¿Se han validado los requerimientos con el usuario? ¿Con los demás integrantes del equipo de trabajo? ¿Se han validado los prototipos con el usuario final? ¿Evitan los requerimientos conflictos entre si? ¿Los requerimientos incorporan aspectos de diseño? ¿Están los requerimientos a un nivel de consistencia adecuado? ¿Debiera especificarse en más detalle algún requerimiento? ¿Debiera especificarse en menos detalle algún requerimiento? ¿Son los requerimientos lo suficientemente claros como para ser entregados a un grupo independiente para su codificación y aún ser comprendidos? ¿Es cada requerimiento relevante para el problema y su solución? ¿Puede rastrearse el origen de cada requerimiento en el ambiente del problema? ¿Se puede probar cada requerimi~nto? ¿Será posible para un grupo independiente de pruebas determinar si un determinado requerimiento ha sido satisfecho? ESPECIFICACiÓN DE LOS REQUERIMIENTOS ¿Es la especificación modular? ¿Es posible incorporar/modificar/eliminar información sin producir grandes transformaciones en la estructura? ¿Existen referencias cruzadas en la especificación? ¿Se ha revisado la ortografía y redaccion del documento? ¿Existe una tabla de contenidos, de figuras y/o de tablas?

SI

No

SI

No

41