analisisRequerimientos

TABLA DE CONTENIDOS

1. INTRODUCCiÓN 1

2. ANTECEDENTES DE LA INGENIERíADE REQUERIMIENTOS :2

3. TÉCNICAS y MÉTODOS DE IDENTIFICACiÓN 5

3.1 PREGUNTASy RESPUESTAS.. ... ... 53.2 PROTOTiPOS 6

4. TÉCNICAS y MÉTODOS DE ESPECIFICACiÓN 7

4.1 ARQUITECTURA... 7

4.2 JERARQuíAFUNCiONAL : 74.3 DIAGRAMASDE FLUJO DE DATOS 84.4 PROCESOS 114.5 DICCIONARIODE DATOS 134.6 MODELODE DATOS 144.7 MAPA DE NAVEGACiÓNy DESCRIPCiÓNDE PÁGINAS 174.8 REPORTES 194.9 USE-CASE 214.10 MODELOCONCEPTUAL 244.11 DIAGRAMf.\.SDE SECUENCiA 244.12 DESCRIPCiÓN DEARCHiVOS 24

5. DOCUMENTODE ESPECIFICACiÓN DE REQUERIMIENTOS 26

5.'1 DESCRIPCiÓN GENERAL 265.2 DESCRIPCiÓN DE ELEMENTOS COMUNES 28

5.3 DESCRIPCiÓN DE LA PLANTILLA PARA ESPECIFICACiÓN FUNCIONAL 315.4 DESCRIPCiÓN DE LA PLANTILLA PARA ESPECIFICACiÓN ORIENT/~DA AL OBJETO 31

5.5 DESCRIPCiÓN DE LA PLANTILLA PARA ESPECIFICACiÓN DE APLICACIONES WES 31

6. COMENTARIOSFINALES 33

ANEXO A PLANTILLAPARA ESPECIFICACiÓNFUNCIONAL 34

ANEXO B PLANTILLAPARA ESPECIFICACiÓNORIENTADAAL OBJETO 36

ANEXO C PLANTILLAPARA ESPECIFICACiÓNDEAPLICACIONESWEB 38

ANEXO D CHECKLlST DE REVISiÓNDE REQUERIMIENTOS 40

TABLA DE FIGURAS

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

ii

Proyecto de Software Especificación de Requerimientos

1. INTRODUCCiÓN

El presente documento entrega algunos de los elementos necesarios para realizar unaespecificació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 unaidentificación de requerimientos.

En la sección 4 se describen las técnicas principales para la especificación derequerimientos. Estas técnicas corresponden principalmente a las utilizadas en el análisisfuncional 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 incluyenalgunas técnicas utilizadas para la especificación de requerimientos de aplicaciones webcomo 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 paraespecificación funcional, especificación orientada al objeto y especificación de aplicacionesweb.

En los anexos A, B Y C se incluyen las plantillas y en el anexo D se incluye un checklist derevisión como ayuda para determinar si la especificación de un sistema ha sido completa ono.


2. ANTECEDENTES DE LA INGENIERíA DE REQUERIMIENTOS

Para que un esfuerzo de desarrollo de software tenga éxito, es esencial comprenderperfectamente los requisitos del software. Independientemente de lo bien diseñado ocodificado 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 claramenteel 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 conocerseclaramente el objetivo final, es decir, el sistema que se desea construir. Si el objetivo fin.alno está claramente definido, difícilmente se podrá cumplir con él. Además, ninguna otraparte 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 documentosde especificación o de requerimientos. La especificación de requerimientos es el resultadode la comunicación entre el equipo de trabajo y el cliente. El documento de requerimientosademás, define el primer punto de referencia para la validación del software. Así, si sequiere verificar que un software cumple con exigencias determinadas, se debe saber contraque se quiere comparar.

Es importante destacar que el documento de requerimientos no sólo consigue un consensoentre el cliente y el equipo de trabajo con respecto a lo que se desea, sino que undocumento 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 pararesolver dudas específicas de la aplicación o simplemente como una forma de informar alequipo de trabajo el proyecto que se va a desarrollar. Por otro lado, permite laincorporación de nuevos recursos (personal) para apoyar el proceso de desarrollo.

La elaboración del documento de requerimientos se puede resumir como: "El proceso deestablecer los servicios o funcionalidad que el producto de software proveerá, en unlenguaje común que sirva como medio de comunicación entre las partes, y las restriccionesbajo 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 olograr un objetivo.

2. Una condición o capacidad que debe ser alcanzada, o poseída por un sistema ocomponente del sistema para satisfacer un contrato, estándar, especificación u otrodocumento 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: corresponden a los resultados que debe arrojar el sistema bajodeterminadascircunstancias.

. No funcionales: están relacionados con el rendimiento, seguridad, precisión, manejode erroresy capacidadespara usuariosespecíficos.Normalmentelas restriccionessetraducenen requerimientosnofuncionales(ver Figura1).

2


. Inversos: indican lo que el software "no debe hacer". Son de mucha importancia en elsoftware de misión crítica.Restricciones de Diseño e Implementación: corresponden a condiciones impuestaspor 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 sepuedan medir.Comparables: es decir, que se puedan probar.

.

.

.

.

RequerimientosNo Funcionales

Requerimientosdel Proceso

Requerimientosde Seguridad

RequerimientosEticos

Requerimientosde Usabilidad

Requerimientosde Implementación

RequerimientosLegislativos

Requerimientosde 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 reescribirsede 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 cadauna 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


identificar el contexto operativo de cada requerimiento. Para apoyar esta actividad sepuede:

Observar las operaciones del usuario.Desarrollar encuestasSolicitar asesoría de expertos en el área de aplicaciónRealizar entrevistasInvestigar el área de aplicaciónIdentificar analogías con otros sistemas

. Análisis. Los requerimientos deben ser "compilados" debido a que ellos provienen dedistintas fuentes. Para ello se deben:

Clasificar por tipo de requerimientoPriorizar sobre la base de factores críticosEvaluar los riesgos y la factibilidad económica técnicaValidar según los atributos correctos (comprobable, trazable, etc.)

Algunas de las técnicas y métodos que apoyan esta actividad son el IBIS (Issue BasedInformaction System), el JAD (joint Application Design) y las Inspecciones Formales oWalk-Throughs y PD (Participating Design).

. Representación. Los requerimientos se traducen desde "una"modelos" o "prototipos". Algunos de los más representativos son:

Modelo de la ArquitecturaModelo FuncionalModelo de DatosModelo de Flujo de DatosModelo de InterfazModelo de Objetos

forma textual" a

Algunas de las técnicas y métodos que apoyan esta actividad son el SADT (StructuredAnalysis and Design Technique), Análisis Estructurado y Análisis Orientado al Objeto.

. Comunicación. Los requerimientos son comunicados oralmente y escritos con el fin deque 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 conel cliente, reuniones de trabajo y/o investigación en terreno. Más adelante se describe entérminos generales cómo deben realizarse las entrevistas. Con la información obtenida serealiza la construcción del Documento de Especificación de Requerimientos (DER).

4


3. TÉCNICAS y MÉTODOS DE IDENTIFICACiÓN

Existen variadas metodologías para realizar la identificación de los requerimientos de unsistema. Si la identificación no es lo suficientemente acabada, difícilmente se podrá realizaruna especificación adecuada del sistema. La identificación de los requerimientoscomprende 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 elsoftware. Para poder realizar la especificación es necesario poseer toda la informaciónrelevante del sistema y la mejor manera de obtenerla es realizando entrevistas con elcliente.

Las entrevistas son realizadas para obtener las necesidades del cliente. Para determinarlas necesidades del cliente se puede proceder mediante preguntas y respuestas, lapresentación de prototipos o una combinación de ambas.

Las entrevistas deben ser establecidas con tiempo de tal manera que el equipo de trabajopueda prepararla y el cliente pueda asistir. Normalmente el cliente no posee la mismadisponibilidad de tiempo que el equipo de desarrollo por lo que debe ser avisado conanticipació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 sediscutirán. Esta minuta debe ser entregada al cliente con anterioridad a la reunión con el finde que el cliente asista a la reunión con toda la información necesaria. Como resultado dela reunión se elabora otra minuta que debe ser aprobada por el cliente en la reuniónsiguiente.

Las minutas no sólo permiten hacer las reuniones más productivas, sino que permitenregistrar 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 dedesarrollo.

3.1 PREGUNTAS y RESPUESTAS

Las preguntas y respuestas son útiles al comienzo de la interacción con el cliente paraobtener información importante del sistema. En esta etapa es fundamental que laspreguntas permitan "obtener" información, es decir, se deben evitar aquellas preguntas queno son relevantes para la etapa de requerimientos. Por ejemplo, para determinar (yespecificar) la funcionalidad de la aplicación no es relevante conocer el lenguaje deimplementació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óneaspara las entrevistas además de la elaboración de las preguntas adecuadas.

Las entrevistas pueden ser estructuradas y no estructuradas. Las entrevistas estructuradasse asocian a un conjunto de preguntas a las que el usuario debe responder. Lasentrevistas no estructuradas por el contrario, son improvisadas con el usuario. Acontinuación se muestran algunas de las ventajas y desventajas de cada uno de losmétodos:

5


3.2 PROTOTIPOS

Los prototipos constituyen la manera más fácil de validar los requerimientos del sistemadado que el usuario puede trabajar sobre un elemento concreto y no abstracto como sonlos modelos. Según el área de aplicación que se esté analizando el prototipo puede serdistinto. Por ejemplo, en el caso de una aplicación interactiva la descripción de lafuncionalidad 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íamostrar 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 laspá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, ~eincluye 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. Elanálisis de requerimientos que debe realizarse previo a la elaboración de los prototiposdependerá exclusivamente de la naturaleza del problema a resolver. Es recomendable quelos prototipos sean elaborados exclusivamente para la generación de un conjunto válido derequerimientos; una vez que éstos han sido identificados se deben documentar y continuarcon el proceso de desarrollo.

Es fundamental encontrar el prototipo adecuado para la presentación ante el cliente. Otraposibilidad para la presentación de prototipos es la elaboración de un manual de usuariopreliminar. Dado que el manual presenta la funcionalidad a un usuario cualquiera, que nose encuentra involucrado en el proceso de desarrollo, éste permite identificar errores deinterfaz, funcionalidad, etc.

6

Entrevista Estructurada Entrevista No Estructurada.Asegura la elaboración de un .El entrevistador tiene mayor flexibilidadinforme de las preguntas para todos al realizar las preguntas adecuadas alos que van a responder. quien responde

. Fácil de administrar y evaluar . El entrevistador puede explotar áreas.Evaluación más objetiva tanto de que surgen espontáneamente durante laVENTAJAS quienes responden como de las entrevista

respuestas a las preguntas . Puede producir información sobre las. Se necesita un limitado áreas que se minimizaron o en las que

entrenamiento del entrevistador se pensó fueran importantes.. Resulta en entrevistas más

pequeñas

. Alto costo de preparación .Puede utilizarse negativamente el

. Los que responden pueden o no tiempo, tanto de quien responde como

aceptar el nivel en la estructura y del entrevistador

carácter mecánico de las preguntas. . Los entrevistadores pueden introducir

. Un alto nivel en la estructura puede sus sesgos en las preguntas o al

DESVENTAJAS o no ser adecuado para todas las informar los resultados

situaciones .Puede recopilarse información extraña. El alto nivel en la estructura reduce . El análisis y la interpretación de los

responder en forma espontánea, asi resultados puede ser largocomo la habilidad del entrevistador . Toma tiempo extra recabarlos hechospara continuar con comentarios esencialeshacia el entrevistado


4. TÉCNICAS y MÉTODOS DE ESPECIFICACiÓN

La especificación de requerimientos consiste básicamente en la elaboración de undocumento 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 ymétodos más usuales para realizar la especificación o representación del sistema. Segúnel ámbito de la aplicación o del sistema que se esté desarrollando, se deben incluir en .eldocumento de especificación de requerimientos los diagramas que permitan representar ymodelar el conocimiento adquirido del sistema.

Es importante destacar que en la especificación del documento de requerimientos no sedebe incorporar información que este relacionada con la plataforma sobre la cual se vaya adesarrollar el sistema. La información que se debe incluir debe corresponderexclusivamente 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 deun sistema en un esquema jerárquico. La funcionalidad que se representa en el diagramade jerarquía funcional corresponde a aquella que desea el usuario o la que se necesitapara satisfacer los requerimientos. No se deben incluir funciones (en términos deprogramación) ya que estas son definidas en el diseño.

Normalmente los DJF permiten representar la interacción que es posible realizar con elusuario por medio de menús. Inicialmente los DJF fueron utilizados para representar lainteracción con sistemas de tipo consola en los cuales las opciones eran presentadas porpantalla y el usuario debía elegir una opción para acceder a otro menú o para realizar laacción correspondiente. En la actualidad esta interacción puede ser apreciada en loscajeros automáticos. En la Figura 2 se muestra un ejemplo de jerarquía funcional para uncajero automático.

Cajero Automático

Retiro de dinero

Cierre de Cajero

Informes

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

7


Para sistemas modernos que poseen interfaces con ventanas, menús, diálogos, etc. eldiagrama anterior no permite representar la funcionalidad del sistema claramente. Parasistemas de este tipo se puede utilizar un diagrama de jerarquía funcional como el que semuestra en la Figura 3. Este diagrama corresponde un parte de la funcionalidad queprovee el Word.

ti ~~,t;~~lr~r!l~.Jn.:~- E2i~J2.!m~!1t~~fa¡) !¡¡.b~,V.~~~

J l

A M...f'..n!e...

~ P:'.r ;>fo...

~~;;;i::f;~:'~.,:3r':_~,:§ ~k!~:.;:' .' '..,>, '::.' '.. l?11J""'~~'" .

t~~~iifj M16ferrni;t;:..'~:'.? ':' .

!i~Ier¡;;deesIJ!as:., ,

. .¡;stib... ..~ [-oodo...

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

!jul1ne3... .

~< Qrtografiay gra.matica.:. .~7f~bm;)c.\)I'1~palb'¡¡¡,.,

~.;::i;;t~:: .¡jf;':~ R~n.r,é#ros... .

CQn'1\)léI~J;á~~~:'¡J 1---+ :;.~ptilroi~;zamll1bm...

:':L;;;~~::'I.E;'.. . ~¿,rparartttu~moos...

":c?rr,Q~~~~'".c:;J"sotr~ y,e~ta~,;"

A~It~Wp.;rá.car~;... .:. MmQS... AlttFO

'M¡,cr:.~~~~~~--" ~ ---+. ¡¡r;.l""r~~ "'~:t¡).:.

. ~ian\JII.$} comeem!!nIOs... fJ [d,1tr de \lilli~! Bas',: All.f 1i

. 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 descripcionesnarradas de la opciones existentes. Además de los menús, se pueden incorporarreferencias a cuadros de diálogo, cuadros de herramientas, etc. Es necesario considerarque para construir el diagrama de jerarquía funcional es fundamental haber validado unprototipo con el usuario final. Por otro lado, el diagrama anterior no sirve directamente pararepresentar la funcionalidad del un sitio web. Para ello es mejor construir un mapa denavegación.

4.3 DI AGRAMA S DE FLUJO DE DA TOS

Los diagramas de flujo de datos (OFO) permiten desarrollar los modelos del ámbito de lainformación y del ámbito funcional al mismo tiempo. Los OFO's muestran el flujo de lainformación (datos) y la transformación (mediante procesos) de ésta en el sistema. Esgracias a los OFO que el análisis estructurado posee las cualidades de ser gráfico, concisoy particionado.

Los OFO están compuestos por cuatro elementos: el flujo de datos, el proceso, elrepositorio, y el productor/consumidor. Estos elementos se muestran en la Figura 4.

8


Los DFD pueden ser refinados para reflejar mayor conocimiento sobre el sistema. El DFDde nivelO debe reflejar el sistema como una sola burbuja. Para el desarrollo de lossiguientes 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. Ladescomposición no debe reflejar demasiados detalles o aspectos procedurales sobre lainformación. Se debe refinar hasta un nivel que permita aislar o describir plenamente cadaproceso. Para evitar confusiones se pueden numerar los procesos como se muestra en laFigura 6.

~~ .1

1 1.2

1.3

OFO de NivelO OFOde Nivel 1 parael proceso 1

OFOde Nivel 2 parael proceso 1.1

OFOde Nivel 2 parael proceso 1.2

Figura 6. Refinamientos sucesivos de los DFD

Los almacenes de datos son repositorios de información en el tiempo. Los almacenes seasocian con archivos o bases de datos pero podrían representar también listas,formularios, bandejas, etc. Los almacenes deben estar presentes cuando es necesariocomunicar información entre dos procesos que manejan eventos distintos o cuando elsistema requiere "memorizar" la información que manipula. De lo anterior se concluye quelos almacenes de datos son necesarios cuando se requiere:

. accesar más de una vez un pedazo de informaciónutilizar 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 necesariorealizar alguna operación sobre un almacén de datos, no se incluye información nidescripciones sobre las llaves utilizadas. Sólo se debe incluir información sobre losidentificadores utilizados (ver 4.6). Esto se debe a que las llaves representan mecanismosde acceso y no flujos de información. Otra razón por la que se omiten las llaves es que nose deben hacer compromisos previos con mecanismos de acceso que deben serdeterminados en el diseño.

Los productoreslconsumidores representan, respectivamente, de donde viene lainformación requerida por el sistema y hacia donde va la información producida por el

10


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

4.4 PROCESOS

Todos los procesos relevantes de un proyecto de desarrollo deben ser especificados en ladocumentación del proyecto. Especialmente aquellos procesos que no sean obvios y queestén muy ligados al negocio que se esté modelando. Una especificación de procesospuede incluir narraciones escritas de los procesos, una descripción del algoritmo mediantelenguaje 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 queimplementará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 derepresentación utilizado. Por ejemplo, para describir las acciones necesarias para generarun reporte, para desplegar la información de una página web, etc. A continuación se danejemplos de especificación de procesos mediante lenguaje estructurado, árboles dedecisión y tablas de decisión.

4.4.1 LENGUAJE ESTRUCTURADO

El lenguaje estructurado corresponde a una versión reducida del lenguaje que usamoshabitualmente con la incorporación de construcciones de programación estructurada (if-then-else, while, etc.). El vocabulario comprende:

. Verbos imperativos (los adjetivos y adverbios sonsubjetivos y susceptibles de ser mal interpretados.Términos del diccionario de datosPalabras reservadas para reflejar lógica.

eliminados debido a que son

.

.

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.

tipo de triángulo

PROCESO: Analizar Triánguloleer dimensiones del triángulosi alguna dimensión es negativa entonces

producir mensaje de errorsi la dimensión más larga es menor que la suma de las otrasdos entonces

determinar número de lados igualessi hay tres lados iguales entonces tipo es equiláterosi hay dos lados iguales entonces tipo es isóscelessi no hay lados iguales entonces tipo es escaleno

sinotipo = O 1*No existe triángulo *'

dimensiones de los

lados del triángulo

mensaje de error

/'

Figura 7. Ejemplo de especificación mediante Lenguaje Estructurado

Una de las ventajas de la especificación mediante lenguaje estructurado es que permitemantener la claridad y la consistencia de estilo entre diferentes autores.

11


4.4.2 ARBOLES DE DECISIÓN

Hay tipos de procesos para los cuales el lenguaje estructurado no permite la especificaciónclara y precisa de la transformación realizada a la información. Por ejemplo, si las accionesdel usuario dependen de un número importante de variables que a su vez pueden generarun número grande de combinaciones, entonces la descripción mediante lenguajeestructurado será confusa y muy anidada. En esta situación es conveniente utilizar un árbolde decisión que es una herramienta gráfica que separa las condiciones independientes ymuestra las acciones resultantes a cada combinación.

Como ejemplo, a continuación se muestra la política de ahorro de una empresa ficticia deforma narrada y posteriormente como un árbol de decisión.

"En nuestra empresa, Ficticia Ltda., incentivamos el ahorro de nuestros empleados. Paraello 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 deFinanzas una contribución del 50% de lo que inviertan - siempre y cuando mantengan elmonto por más de dos años.

Sin embargo, nosotros limitamos el monto que los empleados pueden ahorrar, dependiendode sus ingresos y el tiempo de permanencia en la empresa. Un empleado puede ahorrar elcinco, seis o siete por ciento de los primeros $200.000 de su ingresos si ha estado connosotros 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 cientode cualquier exceso. Los empleados que han estado con nosotros dos ai10S pueden ahorrarel cinco por ciento de cualquier cantidad desde $200.000 a $400.000 y cuatro por cientopara cifras mayores. Personas que han estado mucho tiempo con nosotros pueden ahorrarhasta 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 narradaanterior.

Tiempo dePermanenciaen

la EmpresaRango deIngreso

Pocentajede AhorroAutorizado

(Menosde L

1 año ~Menos de $ 200.00 ~5%

$200.000 a $300.000 ~ 4%

Más de $300.000 ~3'10

L Menos de $200.000

~ $200.00 a $400.00Más de $400 00

_6%

Polilica deAhorrode - 1Añoa

FicticiaLIda. 2Años-5%

_4%

~Menos de $200.000

Más de2 Años $200.000 a $400.000

Más de $400 000

_7%

-6%

~5'10

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ónes más manejable que un diagrama, .sin embargo, es menos comprensible

12


inmediatamente. El árbol anterior, correspondiente a la política de ahorro de la empresa, serepresenta en la siguiente tabla de decisión: .

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 ycontrol. En cada representación los datos y los ítems de control juegan un rol. Por estarazón es necesario entregar una aproximación organizada para la representación de lascaracterísticas de cada dato y cada ¡tem de control. Esto se logra mediante el diccionariode datos (DD). En particular, el DD debe contener la definición de todos los datosmencionados 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 delcontenido de los objetos (datos, ítems de control) durante el análisis estructurado. Unadefinición adecuada del DD es la siguiente:

"El diccionario de datos es un listado organizado de todos los datos que son relevantes parael sistema, con definiciones precisas y rigurosas, de tal manera que, tanto el usuario comoel analista, puedan tener una comprensión común de las entradas, salidas, estructuras dealmacenamiento y cálculos intermedios"

Hoy en día el DD es implementado directamente en herramientas CASE. A pesar de que elformato 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 decontrol y cómo es utilizado (por ejemplo, entrada para un proceso, salida de unproceso, 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 dividirmás. A medida que se genera el DD y los elementos son refinados sucesivamente, seidentificarán elementos básicos que no pueden seguir siendo refinados. Estos deben serdefinidos en términos de los valores (discretos o continuos) que pueden tomar. Porejemplo:

13

Permanencia AÑOSen la

1 1Empresa

1 1-2 1-2 1-2 >2 >2 >2

Ingresos <15 15-25 > 25 < 15 15-30 > 30 <15 15-30 > 30

Porcentaje 5% 4% 3% 6% 5% 4% 7% 6% 5%Autorizado


La notación que se muestra en la Figura 10 permite representar datos compuestos comouna secuencia de ítems, como una selección de un conjunto de ítems o como unaagrupación repetida de ítems. Cada ítem que es representado como parte de unasecuencia, selección o repetición, puede, a su vez, corresponder a otro dato que requieremayor refinamiento dentro del DO.

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éfonoextensión localnúmero externonúmero local

número larga distanciaprefijonúmero acceso

= [ extensión local I número externo)

= [ 2001 I 2002 ... I 2999 )= 9 + [ número local I número larga distancia]

= prefijo + número acceso= (1) + código área + número local= [ 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, algunasdefiniciones son más claras que otras. Por ejemplo, las definiciones siguientes:

factura = folio + dirección + { línea factura} + totallínea factura = cantidad + número item + precio unitario + subtotal

son mucho más claras que

factura folío + dirección + { cantidad + número ítem + preciounitario + subtotal } + total

Es importante notar que en la definición del DO se puede incorporar fácilmente el formatode 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 conla representación del modelo conceptual (lógico) de una base de datos, pero puede ser

14

Nombre: capacidad de créditoAlias: ningunoUsado-dondel aceptarCompra(input), capacidadCredito(output)Usado-como:Descripción: La capacidad de crédito de un cliente es entregada por la Superintendencia de

Bancos e Instituciones Financieras,Valoresl AA = ExcelenteSignificados: A = Bueno

B = Aceptablee = PobreD = Deudor

DD = Deudor pre-Judicial

Construcción Notación Significado= compuesto por

Secuencia + YSelección [ I ] alguno de

Repetición { }n n repeticiones de( ) datos opcionales

* * delimitador de comentarios# identificador


utilizado para modelar la información del sistema aunque no necesariamente se vayan autilizar 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

ENTIDAD

I Entidad A ~ rc:::JRELACION

t

t

t

t

7

t

q-

~

~

~ Relación muchos a muchos

Relación 1 a 1

Relación 1 a 1 (opcional)

Relación 1 a muchos

Relación 1 a muchos (opcional)

Figura11. Notación utilizada en los diagramas Entidad-Relación

EJEMPLOS DE RELACIONES

Las entidades reciben nombres en singular. Por ejemplo, para una entidad que administrainformación de clientes, el nombre es CLIENTE y no CLIENTES. Los atributos sonincorporados al diagrama a continuación del nombre y no deben hacer referencia al tipo delos atributos. En caso de ser necesario, el tipo de los atributos puede quedar reflejado en eldiccionario de datos. El conjunto de atributos que identifican únicamente a una entidad seconocen como Identificadores. Los identificadores se denotan anteponiendo un "#" alnombre del atributo.

Las relaciones representan asociaciones entre distintas entidades, pueden tener distintascardinalidades y pueden ser opcionales. Para reflejar las cardinalidades de las relacionesse agregan símbolos en el extremo de la relación. En la Figura 11 se pueden apreciaralgunas 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 puedeincluir información adicional que permite identificar las naturaleza de las relaciones entrelas entidades. Por ejemplo, el diagrama de la Figura 12 posee las entidades EMPRESA yPERSONA. 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 seesto se haga de izquierda a derecha y de arriba hacia abajo. Para el ejemplo anterior, selee EMPRESA Contrata a PERSONA y PERSONA Trabaja en EMPRESA. Además quedareflejado (para el modelo de la figura) que una empresa contrata a muchas personas y queuna persona trabaja en una sola empresa.

Figura 12. Ejemplo de Relación entre Entidades

Cuando se realiza la construcción del diagrama entidad-relación no se debe incluirinformación que se escape al ámbito de los datos esenciales del sistema. Dentro de esta

15

EMPRESA Contrata a PERSONA

I ./Atributos I '" Atributos

Trabajaen


información se incluyen las llaves foráneas, tablas de resolución de relaciones muchos amuchos, índices, etc. Estos elementos son definidos en la etapa de diseño considerandotodos 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 correspondenecesariamente 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 lallave primaria por consideraciones de diseño. Por ejemplo, en el modelo lógico, se puedeestablecer que un cliente es identificado por su rut y en el modelo físico éste es identificadopor una secuencia o entero.

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 entidadpersona 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) sintener 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/PermisosDominiosParámetros

.

.

Usuarios/Roles/Permisos corresponde a la identificación de los usuarios que pueden usarel sistema. Esto puede ser necesario para controlar el acceso, registrar las accionesrealizadas por los usuarios, etc Esta información normalmente está disponible en laorganizació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 dela identificación, cada usuario además debe tener permiso para realizar un conjuntodeterminado 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 paralos usuarios. Normalmente los roles pueden ser mapeados directamente a la estructurajerárquica de la organización: Gerente, Sub-Gerente, Administrador, Secretaria, etc.

Dominios corresponde a la identificación de conjuntos estructurados que pueden serutilizados para identificar entidades, estructurar respuestas, registrar acciones realizadas,reflejar estados, etc. Normalmente un dominio surge cuando es posible estructurar algunode los atributos de una entidad, por ejemplo, el tipo de un auto. Sin embargo, tambiEmpueden ser utilizados, por ejemplo, para estrúcturar el conjunto de respuestas disponiblespara un usuario. En la tabla siguiente se muestran algunos ejemplos de dominios.

16

EMPRESA PERSONA

# rul Conlralaa #rulrazon social nombredirección

Trabaja endirección

leléfono leléfono

PERSONAEMPRESA

# sec_persona inleger# sec_empresa inleger sec_empresa =sec_empresa sec_empresa inlegerrul varchar( 1O) 4 rul varchar(12)razon_social varchar(30) nombre varchar(20)direccion varchar(100) direccion varchar(100)lelefono varchar(7) teléfono varchar(7)

- - - - ..,.

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

-

18


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

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

~r..,t¡;;r4...t,.!..«U1!-~

. ' ;.;t. . 'H

i~=-':::~:,'1 rt1 ~.. Y'',.'-. . .' o..~ ..."'~

h....., ------...........

Compose

PwdOk

..."" ,

,.....

..". ~ , .' ~... '" '.,,- A "-'-...Jv> ,.,,...............

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

\;'_1

Inbox


4.10

4.11

4.12

MODELO CONCEPTUAL

Pendiente

DIAGRAMAS DE SECUENCIA

Pendiente

ARCHIVOS

En algunas ocasiones el cliente puede requerir que el sistema sea capaz de trabajar conarchivos con un formato determinado. Esto con el finde:

. Importar informacióndesde otros sistemasExportar informaciónhacia otros sistemasGuardar 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 talmanera de satisfacer las necesidades de comunicación del software. En el caso de losformatos estándares como .gif, .jpg, .html, .pdf, etc., basta con incluir una referencia a ladescripción de los estándares disponible en el web o en referencias escritas. Cuando elformato no es estándar y corresponde a un formato propio de la organización (definido opor definir) es necesario describirlo completamente.

El formato de los archivos incluye la descripción de los siguientes elementos:

a) Formato del archivob) Distribución del archivoc) Dependencias de los datosd) Formato y precisión de los datose) Condiciones de error del archivo

El formato del archivo describe si la información almacenada está en formato texto obinario. 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 lainformación esté almacenada en formato texto seria necesario incorporar informaciónsobre los delimitadores de los campos. Por ejemplo:

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

24

TEXTO BINARIO

CLIENTE (SEPARADOR DE CAMPOS I char[12] rut------------------------------------------------------- char[30] ra::on social

109875431 I Ficticia Ltda. I Av. Departamental .. . char[50] direccion

)


Las Dependencias corresponde a la descripción de las relaciones existentes entre losdatos de una misma sección o de distintas secciones. Dentro de estas dependencias sepueden incluir variación en el contenido de la información u omisión de información. Porejemplo, un archivo de configuración que describe los colores que deben ser utilizadospara darle color a las caras de ciertos tipos de poliedros:

En el caso anterior la dependencia queda establecida por el hecho de que cada líneaposee 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 depoliedro 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 queguardarán los número con decimales. Por ejemplo, el número 3.14 puede ser escrito como3.14 o como 314E-2. También es importante determinar el número de decimales quedeben ser incorporados.

Las Condiciones de Error tienen relación con las condiciones de integridad del archivo, esdecir, 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 integridadsería el hecho de que debe haber tantas líneas de nadas y de arcos como las indicadas enla primera línea. Otro ejemplo seria el hecho de que el programa sólo acepta 50 nadascomo máximo (por restricciones de diseño por ejemplo) y por lo tanto se debe validar elnúmero de nadas indicados en la primera línea.

Además de indicar las condiciones de integridad, es necesario incluir información sobre eltipo 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 elmáximo permitido", "Error: faltan nadas", "Error: faltan arcos".

25

ARCHIVO DESCRIPCIONN A Número de Nadas (N), Número de Arcos (A)1 SANTIAGO: N líneas con información sobre los nadas.: Cada línea posee el número del nodo y su descripción.N PUERTO MONTT1 1 2 45.002 1 3 23.12 A líneas con información sobre los arcos.: Cada línea posee el número del arco, nodo inicial, nodo final: y peso.A 20 18 34.23

ARCHIVO DESCRIPCION1246 Para cada tipo de poliedro se incluye una línea.23568911 Cada linea posee un número de tipo de poliedro y los índices325246734 de color para cada cara.

Los tipos de políedro son:1 = Triángulo2 = Cubo3 = Tetraedro


5. DOCUMENTO DE ESPECIFICACiÓN DE REQUERIMIENTOS

El contenido del Documento de Especificación de Requerimientos (DER) dependenormalmente 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 oestructurado, una para análisis orientado al objeto y una para sistemas web. Estas seencuentran en los Anexos A, B Y e respectivamente. Durante la elaboración e identificaciónde 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 quecorrespondan.

Debido a que el DER debe ser "alidado por el cliente, éste debe poseer las siguientescaracterísticas:

. Modular: debe permitir la modificación fácil de las distintas secciones de tal manera depermitir mantener el documento actualizado ante los cambios en los requerimientossurgidos durante la ejecución del proyecto.Compacto: la información debe ser entregada completa y reducida de tal manera deno aumentar el tamaño del documento innecesariamente. Para ello es fundamental lautilización de diagramas, tablas, figuras, etc. Esto es un elemento fundamental ya queel documento debe ser leído y validado por el cliente. Si el documento es muy extensopuede provocar retrasos innecesarios en el proyecto.Coherente: los requerimientos deben estar descritos de un manera legible y de menora 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óncon el cliente y describe plenamente la funcionalidad de la aplicación. El documento debeser 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 plantillaspresentadas a continuación son una guía de los puntos que deben ir en el documento derequerimientos, sin embargo, es posible que el cliente requiera la inclusión de informaciónadicional. En caso de ser así, ésta información deberá ser adjuntada siguiendo losestándares de documentación utilizados por el cliente. En caso de que el cliente no poseaestándares de documentación o éstos no sean los adecuados, se deberá llegar a unacuerdo sobre la manera en que se realizará la documentación correspondiente. Ademásse deben omitir aquellas secciones indicadas en las plantillas que no sean aplicables alsistema que se esté desarrollando.

El DER presenta los requerimientos de una manera coherente y estructurada de menordetalle a mayor detalle de una forma gradual. Normalmente al principio del documento seincluye una descripción general que permite comprender el sistema. La descripción generales similar para todos los tipos de proyectos y es la que se describe a continuación (verplantillas en los anexos).

5.1 DESCRIPCiÓN GENERAL

La sección Introducción debe proveer una visión general del DER. A continuación sedescriben las secciones que contiene.

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

26


. La sección Alcance del Proyecto debe identificar el software que se va a producir pormedio de un nombre (por ejemplo, Generador de Reportes, Host DBMS, etc.). Debeexplicar lo que hará y, en caso de ser necesario, lo que no hará el software. Ademásdebe describir los objetivos, beneficios relativos y metas del producto.

. Las sección Glosario: Definiciones, Acrónimos y Abreviaciones debe proveer ladefinición de todos los términos, acrónimos y abreviaciones necesarios para interpretaradecuadamente la información incluida en el documento. Esta información puede serincorporada directamente, mediante referencias a algún anexo ó mediante referenciasa otros documentos.

. La sección Referencias debe proveer una lista de todos los documentos externosutilizados para la elaboración del documento. Debe identificar cada documento pormedio de un título, fecha y organización que lo publica. Además, debe identificar lasfuentes de las cuales pueden obtenerse los documentos. Por ejemplo, si se utilizaalgún estándar de programación externo o se utiliza información proveída por el clientepara 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 comoreferencias a otros documentos.

. La sección Contenidos describir la información que contiene el documento y cómo éstaestá organizada. Por ejemplo, "El capítulo 1 entrega información necesaria para lacomprensión del El capítulo 2 describe en términos generales el producto y oo. Elcapítulo 3 describe la funcionalidad del producto siguiendo una metodología "

La sección Descripción General debe describir los factores que afectan el software y losrequerimientos. 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 lasección siguiente del DER).

. La sección Contexto del Producto debe describir la interrelación del software con otrossistemas. Si el producto es totalmente independiente, esto deberá consignarse de igualforma. Si el DER describe un software que es componente de un sistema mayor,entonces esta sección deberá relacionar requerimientos del sistema mayor confuncionalidad del software y deberá identificar las interfaces entre ese sistema y elsoftware.

. La sección Funciones del Producto debe proveer un resumen de las funciones másimportantes del software. Por ejemplo, una aplicación de contabilidad podría hacermención a la mantención de cuentas corrientes, balances de cuentas y estados decuenta 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 seaentendible por el cliente o por cualquier otra persona que lea el documento por primeravez.

. La sección Características de Usuario debe describir las características generales delos usuarios potenciales del sistema, incluyendo nivel educacional, experiencia ymanejo técnico del ámbito de aplicación.

. La sección Restricciones debe incluir toda la información que limita en algún sentido laimplementació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 decomunicación, requerimientos de funcionamiento, factores críticos y/o consideracionesde seguridad.

27


. La sección Dependencias y Supuestos debe describir aquellos factores que afectan losrequerimientos establecidos en el DER. No corresponden a factores que puedenafectan el diseño, sino más bien a aquellos factores que al ser modificados afectan losrequerimientos. Por ejemplo, un supuesto podría ser la existencia de algún sistemaoperativo particular para la plataforma de desarrollo. En caso de que este sistemaoperativo no estuviera disponible, entonces el DER debería ser modificadoadecuadamente.

La sección Requerimientos Específicos debe incluir el detalle de los requerimientos delsistema de tal manera que se pueda diseñar un sistema que los satisfaga y los ingenierosde prueba puedan probar que el sistema los satisface. La información de ésta seccióndependerá del metodología de desarrollo elegida. A continuación se describe el contenidode los requerimientos específicos correspondiente al análisis estructurado o funcional. Enlas sección 5.4 se describe las plantilla correspondiente al análisis orientado al objeto y enla 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. Acontinuación se describe el contenido de aquellas secciones.

La sección Requerimientos de Interfaces Externas debe describir detalladamente lasentradas y las salidas del sistema. Debe complementar las descripciones de interfacesseñ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 lainteracción de la aplicación co,, el(los) usuario(s). En el caso más simple, esta secciónpuede verse reducida a una referencia al estándar de interfaz, definido por el cliente, alinterior de su organización. En el caso más complejo, puede ser necesario definir unestándar nuevo o adecuado a la nueva aplicación. En caso de ser así, éste deberá serdiscutido y autorizado por el cliente.

. La sección Interfaces de Hardware debe describir todos los requerimientos deinteracción de la aplicación con elementos de hardware externos. Ejemplos de estoselementos podrian ser balanzas mecánicas, sensores ópticos, sensores térmicos,motores, etc. La interacción con elementos de hardware externos podria realizarsemediante conexiones directas por medio de puertas seriales paralelas, y/o tarjetas. Encualquiera de los casos anteriores, es necesario identificar plenamente el mecanismode interacción. Para ello se debe especificar el formato de la información enviada y/orecibida. 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 existenciade una tarjeta magnética. Por otro lado, el computador debe informar al sensor, elprocesamiento exitoso de la operación (por ejemplo, para encender alguna luz comoseñal). Al igual que la sección anterior, ésta puede reducirse a una referencia a algúndocumento determinado.

. La sección Interfaces de Software debe describir todos los requerimientos decomunicación de la aplicación con elementos de software externos o ya existente. Porejemplo, si se va a desarrollar un sistema de facturación, éste debiera ser capaz decomunicarse 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 deinventario. Normalmente esta comunicación se da cuando una aplicación debeimportar/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 detraspaso. Por ejemplo, se desarrolla una aplicación para la administración de clientes deuna empresa y se desea que el sistema permita el envío de fax a los clientes para el día

28


de su aniversario. Una posibilidad para resolver lo anterior, en vez de intentarprogramar la interacción con el fax/módem, es la de generar un archivo temporal con lainformación de los clientes que están de aniversario de tal manera que el software delfax/módem pueda importar la información y realizar los envíos correspondientes. Lainterfaz de comunicación consistirá, entonces, en la descripción del formato que debeposeer 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 decomunicación de la aplicación mediante una red con otros elementos de software o dehardware existentes. La interfaz se limita a la descripción de los protocolos decomunicación, direcciones asociadas, mecanismos de control de errores, mecanismosde seguridad, etc. Esta información normalmente debiera estar disponible en laorganización. Un ejemplo de esta situación sería el caso en que se estuvieraconstruyendo una aplicación distribuida para un banco. En este caso, sería necesariodescribir completamente cómo el sistema haría uso de las redes existentes y losprotocolos de comunicación (propios y estándares) para comunicarse con lassucursales y la central.

Cada uno de los elementos descritos en las secciones anteriores debiera incorporar lasiguiente información:

a) Nombre del ítemb) Descripción del propósitoc) Fuente de la entrada o destino de la salidad) Rangos válidos, precisión y/o toleranciae) Unidades de medidaf) Tiemposg) Relación con otras entradas y otras salidash) Organización y formatos de las pantallasi) Organización y formatos de las ventanasj) Formatos de los datosk) Formato de los archivos1) Formatos de los comandos

Para el caso de la plantilla de análisis funcional, la sección Requerimientos Funcionalesdebe describir las acciones fundamentales que deben realizarse con el fin de aceptar laentrada, procesar y generar las salidas. Estas acciones normalmente son descritas de laforma "El sistema deberá ...n.Además debe incluir:

a) Validaciones en la entradab) Secuencia exacta de las operacionesc) Reacciones ante situaciones anómalas, incluyendo

OverflowFacilidades de ComunicaciónManejo y Recuperación de Errores

d) Efecto de los parámetrose) Relación de las salidas a las entradas, incluyendo

Secuencias de Entradas/SalidasFórmulas para convertir las entradas en salidas

Puede ser útil descomponer los requerimientos funcionales en subfunciones osubprocesos. Esto no implica necesariamente que el diseño del software vaya a serparticionado de igual forma.

29


La sección Requerimientos de Pendimiento debe describir los requerimientos numéricosestá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 sistemab) 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 procesadasb) Número de tareas que se deben procesarc) 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. Porejemplo, "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 losrequerimientos anteriores deben especificarse en común acuerdo con el cliente y debenreflejar sus necesidades.

La sección Restricciones de Diseño debe describir las restricciones de diseño que puedenproducirse 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 confiabilidaddel sistema al momento de su entrega.

. Disponibilidad: debe especificar los factores que aseguran un determinado nivel dedisponibilidad para el sistema. La disponibilidad está determinada por el tiempo de usoesperado 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 deintegridad para variables críticas.

. Mantenibilidad: debe especificar atributos del software que aseguren la mantencióndel 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 buenasprácticas de diseño.

. Portabilidad: debe especificar atributos del sistema relacionados con el traspaso delsistema a otro hardware y/o sistema operativo. Esto podría incluir:

a) Porcentaje de componentes con código dependiente de la máquina.b) Porcentaje de código dependiente de la máquina.c) Utilización de un lenguaje portable.d) Utilización de un sistema operativo particular.

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

30


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 elcaso de aplicaciones con interacción mediante pantallas esto se reduce a la descripción delas pantallas del prototipo. Para cada pantalla se debe describir la información desplegaday 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 unalínea de comandos, son procesos batch, etc.) la funcionalidad queda descrita indicando lasopciones disponibles y algunas ejecuciones ejemplo. De esta manera el prototipocorresponderí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. Lpsdiagramas 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.3corresponde a los díagramas de secuencia asociados a los use-case existentes. El punto4.4. corresponde a la descripción del modelo conceptual de clases. Aqui se debeincorporar el modelo conceptual completo y posteriormente una descripción de las clasesexistentes.

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 actualidadmecanismos definidos de especificación para este tipo de proyectos. Las aplicaciones webson un caso particular de las aplicaciones hypermediales. En la actualidad la metodologíade especificación más utilizada es el RMM (Relationship Management Methodology) quese describe a continuación.

El proceso de modelamiento de aplicaciones hypermediales puede ser dividido en tresniveles: 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


Archivos Graficos

Páginas HTML

19--------Revista

uContactos

Nivel dePresentación

NivelLógico

Nivel deAlmacenamiento

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 sistemahypermedial. 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 estenivel se define que información debe ser agrupada en pantallas (o unidades depresentación) y cómo se realiza la navegación a través de ellas.

Usualmente las distinciones entre los distintos niveles no son claras produciendodificultades para el desarrollo y la mantención del software.

Para el caso de aplicaciones web, los elementos que las componen son los siguientes:

a) Páginas HTMLb) Modelo E-R,e) Estructura de Directorios.d) Mapa de Navegación

En la sección de requerimientos funcionales se debe describir el tipo de funcionalidad quese desea tener en el sistema.

El punto 4.1 corresponde a la descripción de páginas y para cada página se debendescribir los siguientes elementos:

a) Linksb) Formulariose) Imágenesd) Appletse) 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 durantela utilización del sistema. Aquí es importante destacar en que condiciones se realiza laactivación de las procesos. Por ejemplo, algunos procesos pueden ser realizados al seguirun link, al cargar una página, al responder un formulario, al presionar un botón, etc.

32


6. COMENTARIOS FINALES

El documento de especificación requerimientos no debe incluir todas las seccionesseñaladas anteriormente. Los responsables de la elaboración del documento deberáneliminar la información que no es aplicable o incluir aquella que no ha sido indicadaanteriormente. Además deberán incluir toda la información que el cliente requiera o estimeconveniente. Los responsables de la elaboración del documento de requerimientosdeberán ser capaces de dejar claramente establecidos los objetivos del sistema siguiendotodas las pautas señaladas en la sección 4. El tiempo invertido en la elaboración de estedocumento determina los resultados obtenidos. Si el documento es claro, preciso yrepresenta perfectamente los objetivos del sistema, las etapas siguientes pueden serenfrentadas con mayor eficiencia. En caso contrario, se requerirá de un esfuerzo mayor enlas etapas de diseño y codificación.

El documento de requerimientos debe ser validado por parte del cliente y no será aceptadohasta que el cliente no haya dado su aprobación.

Este manual está en construcción y las sugerencias, comentarios, dudas y/o consultas lospueden hacer llegar a [email protected].

33

Proyecto de Software Anexo A

Anexo A

PLANTILLAPARA ESPECIFICACiÓN FUNCIONAL

1. Introducción1.1. Propósito1.2. Alcance del Proyecto1.3. Glosario: Definiciones,Acrónimosy Abreviaciones1.4. Referencias1.5. Contenidos

2. Descripción General2.1. Contexto del Producto2.2. Funciones del Producto2.3. Características de los Usuarios2.4. Restricciones2.5. Dependencias y Supuestos

3. Requerimientos de Interfaces Externas3.1. Interfacesde Usuario3.2. Interfacesde Hardware3.3. Interfacesde Software3.4. Interfacesde Comunicación

4. Requerimientos Funcionales4.1. Funcionalidad

4.1.1. Pantalla1/lnteracción14.1.2. Pantalla2/lnteracción2

4.2. Reportes4.2.1. Reporte 14.2.2. Reporte 2

4.3. Flujos de Información4.3.1. DFD 14.3.2. DFD2

4.4. Descripción de Procesos4.4.1. Proceso 14.4.2. Proceso 2

4.5. Descripción de los Datos4.5.1. Entidad 14.5.2. Entidad 2

4.6. Diccionariode Datos5. Requerimientos de Rendimiento6. Restricciones de Diseño7. Atributos de Sistema8. 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ón1.1. Propósito1.2. Alcance del Proyecto1.3. Glosario: Definiciones, Acrónimos y Abreviaciones1.4. Referencias1.5. Contenidos


3. Requerimientos de Interfaces Externas3.1. Interfaces de Usuario3.2. Interfaces de Hardware3.3. Interfaces de Software3.4. Interfaces de Comunicación

4. Requerimientos Funcionales4.1. Use-Case

4.1.1. Use-Case 14.1.2. Use-Case 2


4.3. Diagramas de Secuencia4.3.1. Diagrama de Secuencia 14.3.2. Diagrama de Secuencia 2

4.4. Modelo Conceptual4.4.1. Descripción4.4.2. Clase/Objeto 14.4.3. Clase/Objeto 2

5. Requerimientos de Rendimiento6. Restricciones de Diseño7. Atributos de Sistema8. Requerimientos Adicionales9. Anexos

. Modelo Conceptual

. Diagramas Use-Case

. Diagramas de Secuencia

36

Proyecto de Software Anexo B

. Diagramas de ClaseModelo de Datos LógicoDiccionario de DatosPantallas del PrototipoDescripción de Archivos

.

.

.

.

37

Proyecto de Software Anexo e

Anexoe

PLANTILLA PARA ESPECIFICACiÓN DE APLICACIONES WEB

1. Introducción1.1. Propósito1.2. Alcance del Proyecto1.3. Glosario: Definiciones, Acrónimos y Abreviaciones1.4. Referencias1.5. Contenidos


3. Requerimientos de Interfaces Externas3.1. Interfaces de Usuario3.2. Interfaces de Hardware3.3. Interfaces de Software3.4. Interfaces de Comunicación

4. Requerimientos Funcionales4.1. Descripción de Páginas

4.1.1. Página 14.1.2. Página 2


4.3. Descripción de Procesos4.3.1. Proceso 14.3.2. Proceso 2

4.4. Descripción de los Datos4.4.1. Entidad 14.4.2. Entidad 2

4.5. Diccionariode Datos5. Requerimientos de Rendimiento6. Restricciones de Diseño7. Atributos de Sistema8. Otros Requerimientos9. Anexos. Mapa de Navegación

. Descripciónde Procesos

. ModeloLógicode Datos

38

Proyecto de Software Anexo e

. Diccionario de DatosDescripció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 completoen la etapa de especificación de requerimientos.

40

CONTENIDO DE LOS REQUERIMIENTOS SI No

¿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 losparámetros del sistema?¿Se ha construido el mapa de navegación? ¿Se ha descrito cada página del mapade 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 entregadospor 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 seguridaddel sistema?¿Se ha especificado la confiabilidad incluyendo las consecuencias de una caidadel 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 deresponder a cambios en el ambiente de operación, interfaces con otros sistemas,precisión, rendimiento y otras capacidades predecibles?

COMPLETITUD DE LOS REQUERIMIENTOS SI No

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

Proyecto de Software Anexo O

CALIDAD DE LOS REQUERIMIENTOS

¿Están los requerimientos descritos en lenguaje del usuario? ¿Lo cree así elusuario?

¿Se han validado los requerimientos con el usuario? ¿Con los demás integrantesdel 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? ¿Debieraespecificarse en más detalle algún requerimiento? ¿Debiera especificarse enmenos detalle algún requerimiento?¿Son los requerimientos lo suficientemente claros como para ser entregados a ungrupo independiente para su codificación y aún ser comprendidos?¿Es cada requerimiento relevante para el problema y su solución? ¿Puederastrearse el origen de cada requerimiento en el ambiente del problema?¿Se puede probar cada requerimi~nto? ¿Será posible para un grupoindependiente de pruebas determinar si un determinado requerimiento ha sidosatisfecho?

SI No

41

ESPECIFICACiÓNDE LOS REQUERIMIENTOS SI No

¿Es la especificación modular? ¿Es posible incorporar/modificar/eliminarinformació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?

analisisRequerimientos

Documents

Transcript of analisisRequerimientos