FUNDAMENTOS DEL

ANALISIS DE REQUISITOS

ANALISIS DE REQUISITOS
El anlisis de requisitos es la tarea de la ingeniera del
software que establece un puente entre la asignacin del
software a nivel de sistema y de diseo del software.
El anlisis de requisitos facilita al ingeniero de sistemas
la especificacin de la funcin y del rendimiento del
software, la descripcin de la interfaz con otros
elementos del sistema y el establecimiento de las
restricciones de diseo que debe considerar el software.
El anlisis de requisitos permite al ingeniero de software
refinar la asignacin del software y construir modelos de
los mbitos del proceso de los datos y comportamiento.

ANALISIS DE REQUISITOS
El anlisis de requisitos proporciona al diseador del software una
representacin de la informacin y de las funciones que se puede
traducir en un diseo de datos, arquitectnico y procedimental.

Tareas de Anlisis

En el anlisis de los requisitos del software se pueden

identificar cinco reas de esfuerzo:
1.- Reconocimiento del problema,
2.- Evaluacin y sntesis,
3.- modelizacin,
4.- Especificacin y
5.- Revisin.

RECONOCIMIENTO DEL PROBLEMA

Inicialmente, el analista estudia la especificacin del
sistema (si existe) y el plan del proyecto de software. Es
importante llegar a comprender el software dentro del
contexto del sistema y revisar el mbito del software que
se ha usado para generar las estimaciones en la
planificacin.
El analista debe establecer contacto con el equipo
tcnico y de gestin del usuario/cliente y de la
organizacin de desarrollo del software.
El gestor del proyecto puede servir como coordinador
para facilitar el establecimiento de los caminos de
comunicacin. El objetivo del analista es reconocer los
elementos bsicos del problema tal como lo percibe el
usuario/cliente.

EVALUACIN Y SNTESIS
La evaluacin del problema y la sntesis de la solucin
es la siguiente rea principal del esfuerzo del anlisis.
El anlista debe evaluar el flujo y la estructura de la
informacin.
Definir y elaborar todas las funciones del software.
Entender el comportamiento del programa en el contexto
de los sucesos que afectan al sistema.
Establecer las caractersticas de la interfaz del sistema
Descubrir las restricciones del diseo.
Cada una de estas tareas sirve para describir el problema
de forma que pueda sintetizarse un enfoque o situacin
global.

EVALUACION Y SINTESIS
Suponga el desarrollo un sistema de control de
inventarios para un suministrador de respuestos para
coches
El analista descubre que los problemas del sistema
manual son (IDENTIFICACION DEL PROBLEMA):

Imposibilidad de obtener rpidamente el estado de un

componente
Tiempo medio de dos a tres das para la actualizacin del
archivo de targetas
Mltiples repeticiones de pedidos del mismo vendedor ya que
no hay forma de asociar a los vendedores con los componentes

Ahora el analista determina que informacin ba a

producir el nuevo sistema y que datos se le suministraran

EVALUACION Y SINTESIS
El cliente desea un informa diario que indique las piezas que

sean tomado del inventario

El cliente indica que los encargados de inventario registraran
el nmero de identificacin de cada pieza una vez que se retiran
del inventario

Tras evaluar los problemas actuales y la informacin

deseada, el analista comienza a sintetizar una o ms
soluciones
Un sistema basado en una terminal interactiva
Un sistema DBMS

El proceso de evaluacin y sntesis continua hasta que el

analista y el cliente estimen que se puede especficar el
software de forma adecuada para los consiguientes pasos
de desarrollo.

EVALUACION Y SINTESIS

A lo largo de la evaluacin y sntesis de la solucin, el

analista se centra basicamente en el QUE y no en el
COMO.

Que datos produce y consume el sistema ?

Que interfaces estan definidas ?
Que funciones debe realizar el sistema ?
Que restricciones se aplican ?

Durante la evaluacin y la sntesis de la solucin, el

analista crea modelos del sistema en un esfuerzo por
entender mejor el flujo de datos y de control, el
procesamientofuncional, el comportamiento en
operacin y el contenido de la informacin.
El modelo servir de pilar para el diseo del software y
como base para la creacin de una especificacin del
software.

EVALUACION Y SINTESIS
Anteriormente se explico que en esta etapa no es posible
hacer una especificacin detallada. El cliente puede no
estar seguro de lo que precisamente quiere. El
desarollador puede no estar seguro de que un enfoque
concreto sea apropiado para realizar la funcin y
comportamiento deseado.
Por esta y muchas razones, puede seguirse un mtodo
alternativo llamado construccin de prototipos, para el
anlisis de requisitos
Otra alternativa aunque al parecer inecesaria y poco
lgica para un etapa tan temprana del proceso de
ingeniera del software es el desarrollar un manual de
usuario.

EVALUACION Y SINTESIS
El borrador del manual del usuario fuerza al analista a
ponerse en el lugar del usuario del software.
El manual provoca la revisin del software por parte del
usuario/cliente desde una perspectiva de ingeniera
humana. Frecuentemente surge el siguiente comentario.

La idea es correcta, pero esta no es la forma en que pense que se

haria.

El analista debe ser una persona muy completa y exhibir

los siguientes rasgos de carcter:
Habilidad para comprender conceptos abstractos, reorganizarlos

en divisiones lgicas y sintetizar soluciones

Habilidad para abstraer hechos importes de funtes con rudo
Habilidad para comprender entornos de usuarios clientes
Habilidad para aplicar elementos del sistema de hardware y/o
software a entornos de usuarios clientes.

EL ANALISTA
Habilidad para comunicarse bien de forma escrita y verbal
Habilidad para no parar en exceso en los detalles y perder de

vista el objetivo global del software

El analista debe descubrir los requisitos del software de

una manera descendente, comprendiendo perfectamente
las funciones principales, las interfaces y la informacin
antes de especificar los niveles suficientes de detalle
Generalmente es responsable del desarrollo de una
especificacin de requisitos del software
El anlisis de requisistos es una actividad de intensa
comunicacin. Siempre que existe comunicacin, el
ruido puede producir problemas tanto el analista como el
cliente.

AREAS DE PROBLEMAS

Las principales dificultades que pueden encontrarse

durante el anlisis de requisitos estaran asociadas con:
La adquisiscin de la informacin pertinente
El manejo de la complejidad del problema
La gestin de los cambios que pueden producirse durante y

dspues del anlisis

Conforme crece el tamao del problema, crece tambin

la complejidad de la tarea de anlisis cada nuevo
elemento de informacin, nueva funcin, o nueva
restriccin puede afectar a los demas elementos del
software.
Que informacin debe recogerse y como debe representarse ?
Quien suministra las distintas partes de la informacin ?
Que herramientas y tcnicas estan disponibles para facilitar la

recoleccin de informacin ?
Puede un problema grande ser subdividido con efectividad ?

AREAS DE PROBLEMAS
Aunque el enfoque de la ingeniera del software para el
anlisis de requisitos no es una panacea, la aplicacin de
los principios fundamentales de anlisis y de metdos
sistematicos de anlisis reducira considerablemente el
impacto de estos problemas. La tcnica de anlisis ms
comunmente usada para cubrir el vaco de comunicacin
entre cliente y analista es dirigir una entrevista o una
revisin preeliminar.
En las primeras entrevistas se suguiere que el analista
comience con preguntas independientes del contexto un
conjunto de peguntas que lleven al conocimiento bsico
sobre el problema, sobre la gente que quiere una
solucin, sobre la naturaleza de la solucin deseada y
sobre la efectividad del propio primer encuentro.

TECNICAS DE COMUNICACION

El primer conjunto de preguntas independientes del

contexto se centran en el cliente, en los objetivos
generales y en los beneficios
De quien ha surgido la peticin de este trabajo ?
Quien va a utilizar la solucin ?
Cul ser el beneficio econmico de una solucin

satisfactoria ?
Existe otro lugar donde puede encontrar la solucin que
necesita ?

El siguiente conjunto de preguntas permite al analista

conocer mejor el problema y al cliente expresar sus ideas
sobre la solucin:
Como definiria una buena salida generada por una solucin

satisfactoria ?

TECNICAS DE COMUNICACION
Que problema resolvera esta solucin ?
Puede mostrarme el entorno en el que se utilizara la solucin?
Hay alguna limitacin o aspecto especial de rendimiento que

vaya a la forma en que se enfoque la solucin ?

El ultimo conjunto de preguntas se centra en la

efectividad de la reunin (metapreguntas)
Son oficiales sus respuestas ?
Son relevantes mis preguntas para mis problemas ?
Estoy haciendo demasiadas preguntas ?
Hay alguen ms que pueda proporcionar informacin

adicional ?
Hay algo ms que deba preguntar ?

Estas preguntas ayudaran a romper el hielo y a iniciar la

comunicacin, que es esencial para un correcto anlisis

TECNICAS DE COMUNICACION
La sesin de preguntas y respuestas solo debe usarse en
las primeras entrevistas y luego sustituirlas por un
esquema de reunin que combine elementos de
resolucin de problemas, negociacin y especificacin.
Existe un enfoque orientado al equipo para la
recopilacin de requisitos llamado o denominado
Tcnicas para Facilitar la Especificacin de la
Aplicacin (TFEA), que comprende la creacin de un
equipo mixto de clientes y personas encargadas del
desarrollo que trabajan juntos para identificar el
problema, proponer elementos de solucin, evaluar
diferentes enfoques y especificar un conjunto
preeliminar de requisitos de la solucin.

TECNICAS DE COMUNICACION

Utilice las siguientes directrices bsicas:

Se lleva acabo una reunin en un lugar neutral a la que asisten

tanto desarrolladores como cliente

Se establecen reglas para la preparacin y participacin
Se suguiere una agenda lo suficientemente formal para que
cubra todos los puntos importantes, pero lo suficientemente
informal para estmular el flujo libre de deas
Se acuerda la eleccin de un facilitador para controlar la
reunin
Se utiliza un mecanismo de definicin (hojas de trabajos,
diagramas, pizarras o tableros)
El objetivo es identificar el problema, proponer elementos de
una solucin, evaluar los diferentes enfoques y especificar un
conjunto preeliminar de requisitos de la solucin en una
tmosfera adecuada para alcanzar el objetivo.

PRINCIPIOS DE ANALISIS

Los mtodos de anlisis estan relacionados por un

conjunto de principios fundamentales:
Se debe representar y comprender el mbito de informacin del

problema
Se deben desarrollar los modelos que representen la
informacin, funcin y el comportamiento del sistema
Se deben de subdividir los modelos (y el problema) de forma
que se descubran los detalles de una manera progresiva
El proceso de anlisis debe ir de la informacin esencial hacia
el detalles de la implenetacin

Aplicando estos principios el analista enfoca el problema

sistematicamente:
El mbito de informacin se examina para poder comprender

completamente la funcin
Los modelos se utilizan para poder comunicar la informacin
de forma compacta

PRINCIPIOS DE ANALISIS
La particin se aplica para reducir la complejidad
Los planteamientos esencial y de implementacin del software

son necesarios para acomodar las lgaduras lgicas impuestas

por los requisitos del procesamiento y la lgaduras fsicas
impuestas por otros elementos del sistema.

Dentro del mbito de informacin del problema residen

tanto los datos (nmeros, caracteres, imgenes, etc)
como el control (sucesos)
Un suceso representa algun aspecto de control de
sistema, no es ms que un dato booleano
El mbito de informacin contiene tres planteamientos
diferentes de los datos y del control ha medida que son
procesados por un programa

PRINCIPIOS DE ANALISIS
El flujo de informacin .- representa la manera en la que los

datos y el control cambian conforme se mueven atraves de un

sistema. Las transformaciones que se aplican a los datos son
funciones o subfunciones que un programa debe ejecutar. El
control y los datos que se mueven entre dos transformaciones
definen la interfaz de cada funcin.
El contenido de la informacin.- Represnta los elementos de
datos individuales que componen otros elementos mayores de
informacin ([nombre de empleado, sueldo neto, sueldo bruto,
deducciones,etc.] = nomina)
La estructura de la informacin.- Representa la organizacin
interna de los distintos elementos de datos y de control. Que
estructura de datos es la ideal para representar la informacin
(tablas n dimensionales, rboles, etc.)

PRINCIPIOS DE ANALISIS:
MODELIZACION
Creamos modelos para obtener un mejor entendimiento
de la entidad a construir. Nuestro modelo debe ser capaz
de modelizar la informacin que transforma el software,
las funciones que permite que se tradusca la
transformacin y el comportamiento del sistema a
medida que se produce la transformacin
Los modelos se centran en lo que tiene que hacer el
sistema y no en como lo tiene que hacer. En muchos
casos, los modelos utilizan una notacin grafica que
representan la informacin, el proceso, el
comportamiento del sistema y otras caractersticas,
mediante iconos claros y fciles de reconocer.

PRINCIPIOS DE ANALISIS:
MODELIZACION

Los modelos creados durante el anlisis de requisitos

desempean varios papeles importantes:
El modelo ayuda al analista ha entender la informacin, la

funcin y el comportamiento del sistema, haciendo por ello que

la tarea de anlisis de requisitos sea ms fcil y ms sistematica
El modelo se convierte en el punto focal para la revisin, y por
tanto, en la clave para la determinacin de la integridad, la
consistencia y la eficacia de la especificacin
El modelo se convierte en la base del diseo, proporcionando el
diseador una representacin esencial del software que se
puede hacer corresponder con un contexto de
implementacin.

PRINCIPIOS DE ANALISIS: PARTICION

A menudo

los problemas son demasiado grandes y

complejos para que se puedan comprender como
un todo.
Por esta razn, tendemos a partir (dividir) dichos
problemas en partes que se pueden entender
fcilmente y establecer interfaces entre las partes,
de forma que se realice la funcin global.
En esencia, la particin descompone un problema
en sus partes constituyentes.
Conceptualmente, se establece una representacin
jerrquica de la funcin o de la informacin y
luego se descompone el elemento superior de la
siguiente forma:

PRINCIPIOS DE ANALISIS: PARTICION

Exponiendo cada vez ms detalles, al moverse

verticalmente por la jerarqua

Descomponiendo funcionalmente el problema, al
movernos horizontalmente por la jerarqua.
PROBLEMA DEL HOGAR

SEGURO

P a r t ic i n H o r iz o n t a l S o ft w a r e H o g a r S e g u r o
S o ftw a r e d e H o g a r S e g u r o
C o n fig u r a c i n d e l S is t e m a

M o n it o r iz a c i n d e S e n s o r e s

I n t e r a c c i n c o n e l U s u a r io

PRINCIPIOS DE ANALISIS: PARTICION

S o ftw a r e H o g a r S e g u r o

C o n fi g u r a c i n d e l s is te m a

M o n ito r iza c i n d e s e n s o r e s

R a s tr e o d e s u c e s o s d e s e n s o r

L e c tu r a d e l e s ta d o d e l s e n s o r

Id e n tifi c a c i n d e l tip o d e s u c e s o

In te r a c c i n c o n e l u s u a r io

A c tiv a c i n d e la s fu n c io n e s d e a la r m a

A c tiv a c i n / d e s a c tiv a c i n d e l s e n s o r

A c tiv a c i n d e la a lr m a a u d ib le

M a r c a d o d e l n m e r o d e te l fo n o

PRINCIPIOS DE ANALISIS:
PLANTEAMIENTO ESENCIAL
El

mtodo de particin se puede aplicar al mbito

de la informacin y al mbito del comportamiento
del sistema.
El planteamiento esencial de los requisitos del
software presenta las funciones que han de
realizarse y la informacin que ha de procesarse,
independientemente de los detalles de
implementacin.
Centrando la atencin en la esencia del problema
en las primeras etapas del anlisis de requisitos,
dejamos abiertas opciones de especificacin de los
detalles de implementacin en etapas posteriores
de la especifiacin de requisitos y del diseo del
software

PRINCIPIOS DE ANALISIS:
PLANTEAMIENTO ESENCIAL
El

planteamiento de implementacin de los

requisitos del software presenta la manifestacin
en el mundo real de las funciones de
procesamiento y de las estructuras de informacin.
Se deben contemplar caractersticas generales
como parte de la especificacin de requisitos del
software.
El analista debe reconocer las restricciones
impuestas por los elementos predefinidos del
sistema y considerar el punto de vista de
implementacin de la funcin y de la informacin,
cuando dicho planteamiento sea apropiado.

CONSTRUCCION DEL PROTOTIPO

DEL SOFTWARE
El

modelo esencial es genrico en el sentido de

que la realizacin de la funcin no est indicada
explcitamente.
En algunos casos, se pueden aplicar los principios
fundamentales de anlisis y derivar una
especificacin del software en papel a partir de la
cual se pueda desarrollar el diseo.
En otras ocasiones, se realiza una recoleccin de
requisitos, se aplican los principios de anlisis y se
construye un modelo de software, denominado
prototipo.
Este prototipo es valorado por el cliente y el
desarrollador.

CONSTRUCCION DEL PROTOTIPO

DEL SOFTWARE
Por

ltimo, hay veces en las que se requiere la

construccin de un prototipo al comienzo del
anlisis, debido a que el modelo es el nico medio
mediante el cual se pueden obtener los requisitos
de forma efectiva. El modelo evolucionar hasta
transformarse en el producto del software.
Todos los proyectos de ingenieria del software
arrancan con una peticin de un cliente. La
peticin puede venir dada como:
Una memoria qu describe el problema.
Un informe que define el conjunto de objetivos

comerciales o del producto.

Una peticin de propuesta (PDP) formal de una
empresa o agencia exterior.

CONSTRUCCION DEL PROTOTIPO

DEL SOFTWARE

Una especificacin del sistema que asigna una

funcin y un comportamiento al softwarecomo
elemento de un sistema mayor.

Suponiendo que existe una peticin de software

de alguna de las formas anteriores, para
construir un prototipo del software se aplican los
siguientes pasos:
1.

Evaluacin de la peticin de software para determinar

si el software a desarrollar es un buen candidato para
la construccin de un prototipo.
1.

En general cualquier aplicacin que cree una presentacin

visual dinmica, que interacte mucho con el usuario o que
demande algoritmos o procesos combinatorios que deban ser
desarrollados de forma evolutiva, es candidata para ser
construida como prototipo

CONSTRUCCION DEL PROTOTIPO

DEL SOFTWARE
2.

2.

Dado un proyecto candidato aceptable, el analista

desarrolla una representacin abreviada de los
requisitos.
1.

3.

Dado que el cliente deber interactuar con el prototipo en

pasos posteriores es esencial que se tenga en cuenta los
recursos del cliente en la evaluacin y el refinamiento del
prototipo y que el cliente sea capaz de tomar decisiones
sobre requisitos a tiempo.

Antes de que pueda comenzar la construccin del prototipo,

el analista debe representar los mbitos de informacin,
funcional y de comportamiento del problema y desarrollar un
mtodo razonable de descomposicin.

Despus de revisar el modelo de requisitos, se crea un

conjunto abreviado de especificaciones de diseo para
el prototipo.
1.

Antes de comenzar la construccin del prototipo, se debe

llevar cabo un diseo.

CONSTRUCCION DEL PROTOTIPO

DEL SOFTWARE
4.

Creacin del software del prototipo, prueba y

refinamiento.
1.

2.

3.

5.

Lo ideal sera utilizar bloques constituyentes de software

preexistentes para crear el prototipo rpidamente.
Para aplicaciones interactivas, a menudo se puede crear un
prototipo en papel que describa la interaccin hombremquinausando una serie de historietas. Cada hoja de la
historieta contendr una representacin de una imagen de la
pantalla junto con un texto que describa la interaccin entre la
mquina y el usuario.
El cliente revisar las historietas, obteniendo una perspectiva
de usuario del funcionamiento del software. En muchos casos,
el prototipo en papel no es un papel, sino una serie de
pantallas interactivas generadas mediante una herramienta de
creacin de prototipos.

Una vez probado el prototip, presentacin al cliente,

para que conduzca una prueba de la aplicacin y
sugiera modificaciones.

CONSTRUCCION DEL PROTOTIPO

DEL SOFTWARE
1.

6.

Este paso es el foco del mtodo de construccin de

prototipos. Es aqu donde el cliente puede examinar una
representacin implementada de los requisitos del software y
sugerir modificaciones que harn que el software satisfaga
mejor las necesidades reales.

Repeticin de los pasos 4 y 5 de forma iterativa, hasta

que todos los requisitos queden formalizados o hasta
que el prototipo evolucione en el sistema de
produccin.
El paradigama de construccin de prototipos puede seguir con
uno de dos objetivos en mente:
1.
El propsito de la construccin del prototipo es establecer
un conjunto de requisitos formales que puedan luego ser
traducidos en el producto de software mediante el uso de
mtodos y tcnicas de ingeniera del software
2.
El propsito de la construccin del prototipo es proporcionar
una base continua que lleve a un desarrollo evolutivo del
producto de software.

CONSTRUCCION DEL PROTOTIPO

DEL SOFTWARE

Para que la construccin de prototipos de software sea

efectiva, el prototipo debe desarrollarse rpidamente, de
forma que el cliente pueda comprobar los resultados y
recomendar cambios.
Para realizar una construccin rpida del prototipo, existen
tres clases genricas de mtodos y herramientas: tcnicas
de la cuarta generacin, componentes de software
reusables y especificacin formal y entornos de
construccin de prototipos.
Las tcnicas de anlisis pueden conducir a una
especificacin en papel o basada en computadora
(desarrollada con herramientas CASE) que contengan
descripciones grficas y en lenguaje natural de los
requisitos del software.

ESPECIFICACION
La

construccin de prototipos lleva a una

especificacin ejecutable, es decir, el prototipo
sirve como una representacin de los requisitos.
Los lenguajes de especificacin formal conducen a
representaciones formales de los requisitos que
pueden ser verificadas o analizadas.
Los requisitos se representan de forma que
conduzcan finalmente a una correcta
implementacin del software.
Se proponen 8 principios para una buena
especificacin:

ESPECIFICACION
1.

Separar funcionalidad de implementacin

Una especificacin, por definicin, es una
descripcin de lo que se desea realizar, no de cmo se
va a realizar

2.

Se necesita un lenguaje de especificacin de

sistemas orientada al proceso
Debe emplearse una descripcin orientada al proceso,
en el cual la especificacin de qu se consigue
mediante la especificacin de un modelo del
comportamiento deseado en trminos de respuestas
funcionales a distintos estmulos del entormo.
Ha de describirse formalmente el proceso a
automatizar y el entorno en el que existe.

ESPECIFICACION
3.

Una especificacin debe abarcar el sistema del

cual el software es un componente.
Un sistema est compuesto de componentes que
interactan. Slo dentro del contexto del sistema
completo y de la interaccin entre sus partes puede
ser definido el comportamiento de un componente
especfico.

4.

Una especificacin debe abarcar el entorno en el

que el sistema opera.
Similarmente, debe especifiacrse el entorno en el que
opera el sistema y con el que interacta.
Tan solo supone reconocer que le propio entorno es
un sistema compuesto de objetos, pasivos y activos,
que interactan, de los cuales el sistema especificado
es un agente.

ESPECIFICACION
Los otros agentes, los cuales son por definicin
inalterables debido a que son parte del entorno,
limitan el mbito del diseo e implementacin
posteriores.
La especificacin debe retratar con precisin el
sistema y su entorno, tal como se percibe por su
comunidad de usuarios, contantos detalles como sea
necesario para las fases de diseo e implementacin.
5.

Una especificacin de sistema debe ser un

modelo cognitivo
La especificacin de un sistema debe ser un modelo
cognitivo en vez de un modelo de diseo o de
implementacin.

ESPECIFICACION
Debe describir un sistema tal y como es percibido por
su comunidad de usuarios. Los objetos que manipula
deben corresponderse con objetos reales de dicho
mbito; los agentes deben modelizar a los individuos,
a las organizaciones y a los equipos de ese mbito y a
las acciones que ejecutan deben de modelizar lo que
realmente ocurre en el mbito.
6.

Una especificacin debe ser operativa

Esto implica que la especificacin, sin ser una
especificacin completa del cmo, pueda actuar como
un generador de posibles comportamientos, entre los
que debe estar la implementacin propuesta.

ESPECIFICACION
7.

La esepcificacin del sistema debe ser tolerante a

la incompletitud y ampliable.
Ninguna especificacin puede ser totalmente
completa. El entorno en el que existe es demasiado
complejo para que lo sea.

8.

Una especificacin debe estar localizada y

dbilmente acoplada.
Los principios anteriores tratan la especificacin
como una entidad esttica. Esto surge de la dinmica
de la especificacin. Debe reconocerse que, aunque el
principal propsito de una especificacin sea servir
como base para el diseo y la implemntacin de algn
sistema, no es un objeto esttico, sino uno dinmico
que sufre considerables modificaciones.

ESPECIFICACION
El

formato de representacin y el contenido deben

de ser adecuados al problema.
Las formas de representacin contenidas en la

especificacin, normalmente varan de acuerdo con el

rea de aplicacin.
Se

debe anidar la informacin contenida en una

especificacin.
Las representaciones deben revelar capas de

informacin, de forma que un lector pueda ir al nivel de

detalle requerido. Los esquemas de numeracin de
prrafos y de diagramas deben indicar el nivel de
detalle que presentan

ESPECIFICACION
Se

debe restringir el nmero de diagramas y

notaciones, y usarlos de forma consistente.
Una notacin confusa o inconsistente, ya sea grfica o

simblica, degrada la comprensin y fomenta los

errores.
Las

representaciones deben ser revisables

El contenido de una especificacin cambiar. En un

entorno ideal, estarn disponibles herramientas CASE

para actualizar todas las representaciones que puedan
ser afectadas por cada cambio.

ESPECIFICACION DE REQUISITOS
DE SOFTWARE

La especificacin de los requisitos del software se produce

como una culminacin a la etapa de anlisis.
La introduccin describe los fines y los objetivos del
software, describindolos en el contexto de un sistema
basado en computadora.
La seccin de descripcin de la informacin proporciona
una descripcin detallada del problema que el software
debe resolver. Estarn documentados el flujo y la
estructura de la informacin. Se describe el hardware, el
software y las interfaces humanas, para elementos externos
del sistema y las funciones internas del software.

ESPECIFICACION DE REQUISITOS
DE SOFTWARE

La seccin de descripcin funcional proporciona una

descripcin de cada funcin requerida para resolver el
problema. Para cada funcins se da una explicacin del
procesamiento, se establecen y justifican las restricciones
de diseo, se establecen las caractersticas del
comportamiento y se incluyen uno o ms diagramas para
representar grficamente la estructura global del software
y la interrelacin entre sus funcionesy otros elementos del
sistema.
La seccin de criterios de validacin acta como una
revisin implcita del resto de los requisitos.
La bibliografa contiene referencias a todos los
documentos relacionados con el software. Documentacin
de ingenieria de software as como referencias tcnicas,
etc.

ESPECIFICACION DE REQUISITOS
DE SOFTWARE

El apndice contiene informacin que complementa la

especificacin. En los apndices se presentan las tablas de
datos, la descripcin detallada de los algoritmos, los
diagramas los grficos y otro material.
En muchos casos la especificacin de los requisitos del
software puede acompaarse de un prototipo ejecutable, un
manual del usuario preliminar, un prototipo en papel.

I.

Introduccin
A.

Referencia del sistema

B.

Descripcin general

C.

Restricciones del proyecto de

software

ESPECIFICACION DE REQUISITOS
DE SOFTWARE
Descripcin de la informacin

I.

Representacin del flujo de la informacin

A.
1.
2.

Flujo de datos
Flujo de control

Representacin del contenido de la informacin

Descripcin de la interfaz del sistema

B.
C.

Descripcin funcional

II.

Particin funcional
Descripcin funcional

A.
B.
1.
2.
3.
4.
5.

Narrativa de procesamiento
Restricciones y limitaciones
Requisitos de rendimiento
Restricciones de diseo
Diagramas de soporte

ESPECIFICACION DE REQUISITOS
DE SOFTWARE
Descripcin del control

C.
1.
2.

Descripcin del comportamiento

IV.
A.
B.
A.
B.
C.
D.

VII.

Estados del sistema

Sucesos y acciones

Criterios de validacin

V.

VI.

Especificacin del control

Restricciones de diseo

Lmites de rendimiento
Clases de pruebas
Respuesta esperada del software
Consideraciones especiales

Bibliografa
Apndices