Analisis Requerimientos

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.. ... ... 5
3.2 PROTOTiPOS 6
4. TÉCNICAS y MÉTODOS DE ESPECIFICACiÓN 7
4.1 ARQUITECTURA... 7
4.2 JERARQuíAFUNCiONAL : 7
4.3 DIAGRAMASDE FLUJO DE DATOS 8
4.4 PROCESOS 11
4.5 DICCIONARIODE DATOS 13
4.6 MODELODE DATOS 14
4.7 MAPA DE NAVEGACiÓNy DESCRIPCiÓNDE PÁGINAS 17
4.8 REPORTES 19
4.9 USE-CASE 21
4.10 MODELOCONCEPTUAL 24
4.11 DIAGRAMf.\.S
DE SECUENCiA 24
4.12 DESCRIPCiÓN DE ARCHiVOS 24
5. DOCUMENTODE ESPECIFICACiÓN DE REQUERIMIENTOS 26
5.'1 DESCRIPCiÓN GENERAL 26

5.2 DESCRIPCiÓN DE ELEMENTOS COMUNES 28
5.3 DESCRIPCiÓN DE LA PLANTILLA PARA ESPECIFICACiÓN FUNCIONAL 31
5.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ÓNDE APLICACIONESWEB 38
ANEXO D CHECKLlST DE REVISiÓNDE REQUERIMIENTOS 40

TABLA DE FIGURAS
Fi?,ura l. Ejemplo de Jerarquía de Requerimientos no Funcionales 3

Figura 2. Ejemplo dejerarquíajilllcional tradicionul 7
Figll/'a 3. Ejemplo dejerarquía jilllcional 8
Figura -l. Elemelltos de notación de un DFD 9
Figura 5. Ejemplos de DFD válidos e inválidos 9
Figura 6. Refinamientos sucesivos de los DFD /0
Fi?,ura 7. ~/emplo de espec¡!icaciónmediante Lenguaje Estructurado /1
Figura 8. Ejemplu de Arbol de Decisión /2
Fi?,ura9. Ejemplo de Tabla de Decisión /3
Figura 10. Notación para la descripción de contenido del Diccionario de Datos /./
Figura 1/. Nolaciónutilizada en los dia?,ramasEntidad-Relación /5
Figura 12. Ejemplo de Relación entre Entidades 15
Figura 13. Diferencia entre el Modelo Lógico y el Modelo Físicu / (i
Figura 14. Ejemplo de Mapa de Navegación /8
Figura 15. ~iemplo de Descripción de Páginas.: 19
Figura 16. Ejemplo de Especificación de Reporte 2/
Figura 17. ~iemplo de Diagrama Use-Case. 23
Figura 18. Ejemplo de Use-Case 23
Figura 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 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.
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: corresponden a los resultados que debe arrojar el sistema bajo

determinadascircunstancias.
. No funcionales: están relacionados con el rendimiento, seguridad, precisión, manejo
de erroresy capacidadespara usuariosespecíficos.Normalmentelas restriccionesse
traducenen requerimientosno funcionales(ver Figura1).
2
. 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 Requerimientos
de Seguridad Eticos
Requerimientos Requerimientos Requerimientos

de Usabilidad de Implementación 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
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"

distintas fuentes. Para ello se deben:
debido a que ellos provienen de
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
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
Entrevista Estructurada Entrevista No Estructurada

. Asegura la elaboración de un
informe de las preguntas para todos
. El entrevistador tiene mayor flexibilidad
al realizar las preguntas adecuadas a
los que van a responder. quien responde
VENTAJAS
.
. Fácil de administrar y evaluar
Evaluación más objetiva tanto de
quienes responden como de las
. El entrevistador puede explotar áreas
que surgen espontáneamente
entrevista
durante la
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
Los que responden pueden o no
. Puede utilizarse negativamente el
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
situaciones
El alto nivel en la estructura reduce
. informar los resultados
Puede recopilarse información extraña
. El análisis y la interpretación de los
responder en forma espontánea, asi resultados puede ser largo
como la habilidad del entrevistador . Toma tiempo extra recabarlos hechos
para continuar con comentarios esenciales
hacia el entrevistado
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
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
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
A M...f'..n!e... ~< Qrtografiay gra.matica.:. .~7 ~ Q..;lh.. ídlJ~...
~ P:'.r ;>fo... f~bm;) ---+ . 51"OI1lno :. M.yú;+F-7
c.\)I'1~palb'¡¡¡,., !jul1ne3... .
~~;;;i::f;~:'~.,:3r':_~,:
§ ~k!~:.;:' .' '..,>, '::.' '. ~.;::i;;t~:
: .¡jf;':~ R~n.r,é#ros... .
. l?11J""'~~'" .
CQn'1\)léI~J;á~~~:
'¡J 1---+ :;.~ptilroi~;zamll1bm...
t~~~i
ifj M16ferrni;t;:..'~:'.? ':' .
:':L;;;~~::'I.E;'
":c?rr,Q~~~~'"
..
.c:;J"sotr~ y,e~ta~,;"
. ~¿,rparartttu~moos...
!i~Ier¡;;deesIJ!as:., , A~It~Wp.;rá.car~;... .:. MmQS... AlttFO

. .¡;stib... . 'M¡,cr:.~~~~~~--" ~ ---+. ¡¡r;.l""r~~ "'~:t¡).:.
.~ [-oodo...
. ~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 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
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
1 1.2
1.3
OFO de NivelO OFOde Nivel 1 para

el proceso 1
OFOde Nivel 2 para OFOde Nivel 2 para

el proceso 1.1 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
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 (if-
then-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: Analizar Triángulo

mensaje de error leer dimensiones del triángulo
dimensiones de los
si alguna dimensión es negativa entonces
lados del triángulo
/' 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
tipo de triángulo 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
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 Pocentaje
Permanenciaen Rango de de Ahorro
la Empresa Ingreso Autorizado
Menos de $ 200.00 ~5%
Menosde L $200.000 a $300.000 ~ 4%
~
(
1 año Más de $300.000 ~3'10
_6%
Polilica de
Ahorrode - 1Añoa L Menos de $200.000 -5%
Ficticia
LIda. 2Años
~ $200.00 a $400.00
Más de $400 00 _4%
Menos de $200.000 _7%
Más de
2 Años
~ $200.000 a $400.000
Más de $400 000
Figura 8. Ejemplo de Arbol de Decisión

-6%
~5'10
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
inmediatamente. El árbol anterior, correspondiente a la política de ahorro de la empresa, se

representa en la siguiente tabla de decisión: .
Permanencia AÑOS
en la
1 1 1 1-2 1-2 1-2 >2 >2 >2
Empresa
Ingresos <15 15-25 > 25 < 15 15-30 > 30 <15 15-30 > 30
Porcentaje
5% 4% 3% 6% 5% 4% 7% 6% 5%
Autorizado
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
Nombre: capacidad de crédito

Alias: ninguno
Usado-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 = Excelente
Significados: 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 Notación Significado
= compuesto por
Secuencia + Y
Selección [ I ] alguno de
Repetición { }n n repeticiones de
( ) datos opcionales
* * delimitador de comentarios
# identificador
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 = [ 795 I 799 I 874 I 877 )
número acceso = * 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
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 ~ rc:::J
ENTIDAD RELACION
t t Relación 1 a 1
t q- Relación 1 a 1 (opcional)
t ~ Relación 1 a muchos
t ~ Relación 1 a muchos (opcional)
7 ~ 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.
EMPRESA Contrata a PERSONA

I ./
Atributos I '" Atributos
Trabajaen
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
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 PERSONA
Conlrala a #rul
# rul
razon social nombre
dirección dirección
leléfono Trabaja en leléfono
PERSONA
EMPRESA
# sec_persona inleger
# sec_empresa
rul
inleger
varchar( 1O) 4
sec_empresa =sec_empresa sec_empresa inleger
rul varchar(12)
razon_social varchar(30) nombre varchar(20)
direccion varchar(100) direccion varchar(100)
lelefono varchar(7) teléfono 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í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"
..,."..tMt, , ,,-~.,.: . ~~I~~~'~;,~rf--.U.U
..,w, t..tft!ON............
"""- : it~~:~~,~\~:',~~~:~:;:..:.~~'ti Pwd ..."" ,
,.....
~r..,t¡;;r4...t,.!..«U1!-~
.' ;.;t.
i~=-':::~:,
. 'H
'1 rt1 ~
Ok
. ..". ~ ,
..Jv>
";'''':.:\,''~
,.,
,...............
.',
.' ~... '" '.,,- A "-'-
.. Y'',.'-. . .' o..~ ..."'~

h.... \;'_1
., ------...........
Compose Inbox
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) Formato del archivo

b) Distribución del archivo
c) Dependencias de los datos
d) Formato y precisión de los datos
e) 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 BINARIO
CLIENTE (
SEPARADOR DE CAMPOS I char[12] rut
------------------------------------------------------- char[30] ra::on social
109875431 I Ficticia Ltda. I Av. Departamental .. . char[50] direccion
)
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
ARCHIVO DESCRIPCION
N 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 MONTT
1 1 2 45.00
2 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
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 DESCRIPCION
1246 Para cada tipo de poliedro se incluye una línea.
23568911 Cada linea posee un número de tipo de poliedro y los índices
325246734 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
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
. 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
oo.
capí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 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
. 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
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) Nombre del ítem

b) Descripción del propósito
c) Fuente de la entrada o destino de la salida
d) Rangos válidos, precisión y/o tolerancia
e) Unidades de medida
f) Tiempos
g) Relación con otras entradas y otras salidas
h) Organización y formatos de las pantallas
i) Organización y formatos de las ventanas
j) Formatos de los datos
k) Formato de los archivos
1) 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
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) 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 sido

posible 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 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
Archivos Graficos
Páginas HTML
19
--------
u
Contactos
Revista
Nivel de Nivel Nivel de

Presentación Lógico 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) Páginas HTML
b) 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 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) Links
b) Formularios
e) Imágenes
d) Applets
e) 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
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
PLANTILLAPARA 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. Requerimientos de Interfaces Externas
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ón2
4.2. Reportes
4.2.1. Reporte 1
4.2.2. Reporte 2
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
1.1. Propósito
1.2. Alcance del Proyecto
1.3. Glosario: Definiciones, Acrónimos y Abreviaciones
1.4. Referencias
1.5. Contenidos
2.4. Restricciones
3.1. Interfaces de Usuario
3.2. Interfaces de Hardware
3.3. Interfaces de Software
3.4. Interfaces de Comunicación
4.1. Use-Case
4.1.1. Use-Case 1
4.1.2. Use-Case 2
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
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
37
Proyecto de Software Anexo e
Anexoe
PLANTILLA PARA ESPECIFICACiÓN DE APLICACIONES WEB
1. Introducción
1.1.Propósito
1.2.Alcance del Proyecto
1.3.Glosario: Definiciones, Acrónimos y Abreviaciones
1.4.Referencias
1.5.Contenidos
2.4. Restricciones
3.1. Interfaces de Usuario
3.2. Interfaces de Hardware
3.3. Interfaces de Software
3.4. Interfaces de Comunicación
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
4.5. Diccionariode Datos

8. Otros Requerimientos
9. Anexos
. Mapa de Navegación
. Descripciónde Procesos
. ModeloLógicode Datos
38
Proyecto de Software Anexo e
. Diccionario de Datos
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 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 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?
COMPLETITUD DE LOS REQUERIMIENTOS SI No

¿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?
40
Proyecto de Software Anexo O
CALIDAD DE LOS REQUERIMIENTOS SI No

¿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 SI No

¿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?
41

Analisis Requerimientos

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Analisis Requerimientos

Uploaded by

Copyright:

Available Formats

TABLA DE CONTENIDOS

2. ANTECEDENTES DE LA INGENIERíADE REQUERIMIENTOS :2

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

5. DOCUMENTODE ESPECIFICACiÓN DE REQUERIMIENTOS 26

5.'1 DESCRIPCiÓN GENERAL 26

ANEXO A PLANTILLAPARA ESPECIFICACiÓNFUNCIONAL 34

ANEXO B PLANTILLAPARA ESPECIFICACiÓNORIENTADAAL OBJETO 36

ANEXO C PLANTILLAPARA ESPECIFICACiÓNDE APLICACIONESWEB 38

ANEXO D CHECKLlST DE REVISiÓNDE REQUERIMIENTOS 40

Fi?,ura l. Ejemplo de Jerarquía de Requerimientos no Funcionales 3

En la sección 2 se entregan algunos antecedentes sobre la Ingeniería de Requerimientos,

En la sección 3 se entregan algunos conceptos básicos para poder realizar una

En la sección 4 se describen las técnicas principales para la especificación de

En la sección 5 se describen las plantillas de especificación de requerimientos para

En los anexos A, B Y C se incluyen las plantillas y en el anexo D se incluye un checklist de

2. ANTECEDENTES DE LA INGENIERíA DE REQUERIMIENTOS

Para que un esfuerzo de desarrollo de software tenga éxito, es esencial comprender

Es importante destacar que el documento de requerimientos no sólo consigue un consenso

La elaboración del documento de requerimientos se puede resumir como: "El proceso de

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

A su vez los requerimientos se pueden clasificar en:

. Funcionales: corresponden a los resultados que debe arrojar el sistema bajo

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

. Precisos: no deben ser ambiguos.

Requerimientos Requerimientos Requerimientos

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

En la ingeniería de requerimientos se pueden identificar las siguientes actividades:

. Identificación. Los requerimientos son recolectados desde las personas involucradas. .

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

. Análisis. Los requerimientos deben ser "compilados"

Clasificar por tipo de requerimiento

. Representación. Los requerimientos se traducen desde "una forma textual" a

. Comunicación. Los requerimientos son comunicados oralmente y escritos con el fin de

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

Existen variadas metodologías para realizar la identificación de los requerimientos de un

La minuta de reunión contiene el objetivo de la entrevista y los tópicos o problemas que se

3.1 PREGUNTAS y RESPUESTAS

Las entrevistas pueden ser estructuradas y no estructuradas. Las entrevistas estructuradas

Entrevista Estructurada Entrevista No Estructurada

respuestas a las preguntas . Puede producir información sobre las

Cuando se utilizan prototipos para la identificación de los requerimientos del cliente, ~e

Es fundamental encontrar el prototipo adecuado para la presentación ante el cliente. Otra

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

La especificación de requerimientos consiste básicamente en la elaboración de un

El Análisis Estructurado y el Análisis Orientado al Objeto constituyen las técnicas y

Es importante destacar que en la especificación del documento de requerimientos no se

4.2 JERARQuíA FUNCIONAL

El Diagrama de Jerarquía Funcional (DJF) permite representar la funcionalidad deseada de

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

!i~Ier¡;;deesIJ!as:., , A~It~Wp.;rá.car~;... .:. MmQS... AlttFO

Figura 3. Ejemplo de Jerarquía Funcíonal

Una vez que se ha realizado el diagrama anterior se deben incorporar descripciones

4.3 DI A GRAMA S DE FLUJO DE DA TOS

1. Se debe anotar cuidadosamente la(s) entrada(s) y la(s) salida(s) principal(es)

OFO de NivelO OFOde Nivel 1 para

OFOde Nivel 2 para OFOde Nivel 2 para

Figura 6. Refinamientos sucesivos de los DFD

Los almacenes de datos son repositorios de información en el tiempo. Los almacenes se

. accesar más de una vez un pedazo de información

Sobre los almacenes de datos se realizan las operaciones usuales de inserción,

Los productoreslconsumidores representan, respectivamente, de donde viene la

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