TEMA DE EXPOSICION

La meta del proceso de ingeniera de requerimientos es crear y mantener un

documento de requerimientos del sistema. El proceso general corresponde cuatro (4)
subprocesos de alto nivel de ingeniera de requerimientos. Estos tratan de la evaluacin si el
sistema es til para el negocio, el descubrimiento de requerimientos (obtencin y anlisis);
la transformacin de estos requerimientos e n formularios estndar (especificaciones), y la
verificacin de que los requerimientos realmente define el sistema que quiere el cliente
(validacin).
I.

Vialidad
Se empieza con el estudio de la vialidad, una descripcin resumida del sistema y
como este pretende contribuir a los procesos del negocio. Este informe concluir si vale o
no la pena seguir con la ingeniera de requerimientos y el proceso de desarrollo del sistema.
1. Contribuye el sistema a los objetivos generales de la organizacin?
2. Se puede implementar el sistema utilizando la tecnologa actual y dentro de las
restricciones de costo y tiempo?
3. Puede integrarse el sistema con otros sistemas existentes en la organizacin?
Llevar a cabo este estudio comprende la evaluacin y la recopilacin de la
informacin, y la redaccin de informes. La fase de la evaluacin de la informacin
identifica la informacin requerida para contestar las 3 preguntas anteriores. Una vez que
dicha informacin se ha identificado, se debera hablar con las fuentes de informacin para
descubrir las respuestas a estas preguntas.

II.

Obtencin y anlisis de los requerimientos

En esta actividad, los ingenieros de software trabajan con los clientes y los usuarios
finales del sistema para determinar el dominio de la aplicacin, que servicios debe
proporcionar el sistema, el rendimiento requerido del sistema, las restricciones de hardware,
entre otros.
Esto afecta o puede afectar a varios personas de la organizacin, a la cual definiremos
con el termino stakeholders, persona afectada directa o indirectamente. Para obtener y
comprender los requerimientos de los stakeholders es un proceso difcil:
A. A menudo no conocen lo que desean obtener del sistema informtico excepto los
trminos muy generales.
B. Expresan los requerimientos con sus propios trminos de forma natural y con un
conocimiento implcito de su propio trabajo.
C. Tienen requerimientos distintos que pueden expresar varias formas.
D. El entorno econmico y de negocios en el que se lleva acabo el anlisis es dinmico.
Las actividades del proceso de anlisis son:
1. Descubrimiento de Requerimientos: es el proceso de interactuar con los stakeholders
del sistema para recopilar sus requerimientos. Los requerimientos del dominio de los
stakeholders y la documentacin tambin se descubre durante la actividad.

2. Clasificacin y organizacin de los requerimientos: esta actividad toma la recopilacin

no estructurada de requerimientos, grupos relacionados de requerimientos y los
organiza en grupos coherentes.
3. Ordenacin por prioridades y negociacin de requerimientos: inevitablemente cuando
existen muchos stakeholders involucrados, los requerimientos entrarn en conflicto.
Esta actividad se refiere a ordenar segn las prioridades de requerimientos, y a
encontrar y resolver los requerimientos en conflicto a travs de la negociacin.
4. Documentacin de requerimientos: se documentan los requerimientos y entra en la
siguiente vuelta en espiral, se pueden producir documentos de requerimientos formales
e informales.
5.

Anlisis de Requerimientos para el Desarrollo de Software.

En la actualidad, son muchos los procesos existentes para el desarrollo

de software. Con el pasar de los aos, la Ingeniera de Software ha introducido y
popularizado una serie de estndares para medir y certificar la calidad, tanto
del sistema a desarrollar, como del proceso de desarrollo en s. Un nmero
creciente de herramientas automatizadas han surgido para ayudar a definir y
aplicar un proceso de desarrollo de software efectivo.

El anlisis de requerimientos es la tarea que plantea la asignacin de

software a nivel de sistema y el diseo de programas. El anlisis de
requerimientos

facilita

al

ingeniero

de sistemas especificar

la

funcin

comportamiento de los programas, indicar la interfaz con otros elementos del

sistema y establecer las ligaduras de diseo que debe cumplir el programa. El
anlisis de requerimientos permite al ingeniero refinar la asignacin de software y
representar el dominio de la informacin que ser tratada por el programa. El
anlisis de requerimientos se extiende adems al diseador y la representacin de
la informacin y las funciones que pueden ser traducidas en datos, arquitectura y
diseo procedimental. Finalmente, la especificacin de requerimientos suministra
al tcnico y al cliente, los medios para valorar la calidad de los programas, una vez
que se haya construido.

El anlisis de requerimientos para el desarrollo de software puede dividirse en

cuatro reas:
1.- Reconocimiento del problema
2.- Evaluacin y sntesis
3.- Especificacin
4.- Revisin.
Inicialmente, un analista estudia la especificacin del sistema (si existe) y
el plan de proyecto. Es importante comprender el contexto del sistema y revisar el
mbito de los programas que se us para generar las estimaciones de
la planificacin. A continuacin, debe establecerse la comunicacin necesaria para
el anlisis, de forma que se asegure el reconocimiento del problema.
Respecto a las formas de comunicacin requeridas para el anlisis, el
analista debe establecer contacto con el equipo tcnico y de gestin del
usuario/cliente y con la empresa que vaya a desarrollar el software. El gestor del
programa puede servir como coordinador para facilitar el establecimiento de los
caminos de comunicacin. El objetivo del analista es reconocer los elementos
bsicos del programa tal como lo percibe el usuario/cliente.
La evaluacin del problema y la sntesis de la solucin es la siguiente rea
principal de trabajo del anlisis. El analista debe evaluar el flujo y estructura de la
informacin, refinar en detalle todas las funciones del programa, establecer las
caractersticas de la interface del sistema y descubrir las ligaduras del diseo,
Cada una de las tareas sirve para descubrir el problema de forma que pueda
sintetizarse un enfoque o solucin global.
Las tareas asociadas con el anlisis y especificacin existen para dar una
representacin del programa que pueda ser revisada y aprobada por el cliente. En

un mundo ideal el cliente desarrolla una especificacin de requerimientos del

software completamente por s mismo. Esto se presenta raramente en el mundo
real. En el mejor de los casos, la especificacin se desarrolla conjuntamente entre
el cliente y el tcnico.
Una

vez

que

se

hayan

descrito

las

funcionalidades

bsicas,

comportamiento, interface e informacin, se especifican los criterios de validacin

para demostrar una comprensin de una correcta implementacin de los
programas. Estos criterios sirven como base para hacer una prueba durante el
desarrollo de los programas. Para definir las caractersticas y atributos del
software se escribe una especificacin de requerimientos formal. Adems, para los
casos en los que se desarrolle un prototipo se realiza un manual de usuario
preliminar.
Puede parecer innecesario realizar un manual de usuario en una etapa tan
temprana del proceso de desarrollo, Pero de hecho, este borrador del manual de
usuario fuerza al analista a tomar el punto de vista del usuario del software. El
manual permite al usuario / cliente revisar el software desde una perspectiva de
ingeniera humana y frecuentemente produce el comentario: "La idea es correcta
pero esta no es la forma en que pens que se podra hacer esto". Es mejor
descubrir tales comentarios lo ms tempranamente posible en el proceso.
Los documentos del anlisis de requerimiento (especificacin y manual de
usuario) sirven como base para una revisin conducida por el cliente y el tcnico.
La revisin de los requerimientos casi siempre produce modificaciones en la
funcin, comportamiento, representacin de la informacin, ligaduras o criterios de
validacin. Adems, se realiza una nueva apreciacin del plan del proyecto de
software para determinar si las primeras estimaciones siguen siendo vlidas
despus del conocimiento adicional obtenido durante el anlisis.

2. Anlisis de requerimientos de un proyecto de software

En esta etapa se estudia a fondo lo que desea el usuario y la forma en la cual se le va a presentar la solucin que
se est buscando.
Para lograrlo tenemos las siguientes actividades tcnicas que nos ayudaran a realizar un anlisis ms preciso y
acertado:
2.1 Identificar Casos de Uso del sistema
Se presenta en un diagrama de caso de uso donde se muestra las distintas operaciones que hace el usuario con
la aplicacin o sistema y cmo se relaciona con su entorno.
Para poder identificar el actor de caso de uso hay que:
-Identificar los usuarios del sistema.
-Identificar los roles que juegan esos usuarios desde el punto de vista del sistema.
-Identificar otros sistemas con los cuales exista comunicacin.

2.2 Dar detalle a los casos de uso descritos

Describa brevemente su objetivo
Variantes posibles para realizar este caso de uso.
Relacionar el caso de uso con la interfaz a usuario que lo representa.
Especificar el dilogo que da solucin al caso de uso

2.3 Definir una interfaz inicial del sistema (si es aplicable)

2.4 Desarrollar el modelo del mundo.

Identificar Clases
Elementos fsicos y lgicos dentro del sistema a modelar.
Identificar atributos y asociaciones.
Identificar mensajes

Punto de vista funcional

Punto de vista de comportamiento.

Identificar relaciones de herencia

Identificar restricciones del modelo

Identificar valores posibles y no posibles de los atributos. Describirlos como restricciones de las clases

Identificar valores permitidos para las asociaciones. Describirlos como restricciones de la asociacin

Identificar restricciones que relaciones dos o ms atributos o relaciones. Describirlas dentro de la clase

correspondiente
Identificar paquetes

Combinar clases fuertemente relacionadas en un paquete

Combinar clases que tienen que ver con los mismos casos de uso en un paquete.

Consideraciones de re utilizacin

Reutilizar modelos de dominio existentes

Identificar posibles variantes en el futuro tenerlas en cuenta para diseo (patrones)

2.5 Validar los modelos

Para validar los modelos de caso de uso debemos:
Desarrollar diagramas de interaccin (diagramas de secuencia o de colaboracin) para la variante por defecto
de cada caso de uso, usando los objetos del modelo del mundo encontrados y sus mensajes.

Caractersticas de un buen SRS

2.3.1. Correcto: Un SRS es correcto si y slo si, cada requisito declarado se encuentra
en el software. No hay ninguna herramienta o procedimiento que aseguran la exactitud.
Alternativamente el cliente o el usuario pueden determinar si el SRS refleja las
necesidades reales correctamente, identificando los requerimientos; esto hace el
procedimiento ms fcil y con menor probabilidad de error.

2.3.2. Inequvoco: Un SRS es inequvoco si y slo si, cada requisito declarado tiene slo
una interpretacin. Como un mnimo, se requiere que cada caracterstica de la ltima
versin del producto se describa usando un nico trmino. En casos dnde un trmino en
un contexto particular tenga significados mltiples, el trmino debe ser incluido en un
glosario dnde su significado sea ms especfico. El SRS debe ser inequvoco para
aqullos que lo crean y para aqullos que lo usan. Sin embargo, estos grupos no tienen a
menudo el mismo fondo y por consiguiente, no tienden a describir los requisitos del
software de la misma manera.
.
2.3.2.1. Trampas del idioma natural: Los requisitos son a menudo escritos en el
idioma natural (por ejemplo, ingls); este idioma es inherentemente ambiguo. Un
SRS podra ser revisado por una parte independiente, para identificar el uso
ambiguo del idioma para que pueda corregirse.

2.3.2.2. Idiomas de especificacin de requisitos: Una manera de evitar la

ambigedad inherente en el idioma natural es escribir el SRS en un idioma de
especificacin de requisitos particular. Sus procesadores del idioma descubren

muchos errores lxicos, sintcticos y semnticos automticamente. Una

desventaja en el uso de tales idiomas, es que la falta de tiempo exige aprenderlos.
Tambin, muchos usuarios no-tcnicos los encuentran ininteligibles. Es ms, estos
idiomas tienden a ser buenos a expresar ciertos tipos de requisitos y dirigirse a
ciertos tipos de sistemas. As, ellos pueden influir en los requisitos de las maneras
sutiles.

2.3.2.3. Representacin hecha con herramientas: En general, los mtodos de

requisitos e idiomas y las herramientas que los apoyan, se clasifican en tres
categoras generales:

Objeto

Procesos

Organizan los requisitos en lo que se refiere a

los objetos en el mundo real, sus atributos, y
los servicios realizados por esos objetos.
Organizan los requisitos en las jerarquas de
funciones que
comunican va el flujo de datos

Conductual

Describen conducta externa del sistema por lo

que se refiere a alguna nocin de lo abstracto,
las funciones matemticas o el estado de las
mquinas.

El grado en que se usan estas herramientas y los mtodos pueden ser tiles
preparando un SRS pero depende del tamao y complejidad del programa. An
usando cualquiera de estos trminos es mejor retener las descripciones del idioma
natural.

2.3.3. Completo: Un SRS est completo si y slo si, incluye:

Los requisitos estn relacionados a la funcionalidad, el desarrollo, las

restricciones del diseo, los atributos y las interfases externas. En particular debe
reconocerse cualquier requisito externo impuesto por una especificacin del
sistema y si lo requiere, debe tratarse.

La definicin de las respuestas del software a todos los posibles datos de la

entrada del sistema y a toda clase de situaciones. Una nota que es importante
especificar son las contestaciones a las entradas vlidas e invlidas a ciertos
valores.

Tener todas las etiquetas llenas y referencias a todas las figuras, tablas,
diagramas en el SRS y definicin de todas las condiciones y unidades de medida.

2.3.3.1. Uso de TBDs: Cualquier SRS que usa la frase "para ser determinado (to be
determined -TBD) no es un SRS completo. El TBD es sin embargo, ocasionalmente
necesario y debe acompaarse por:

Una descripcin de las condiciones que causan el TBD (por ejemplo, por qu
una respuesta no es conocida) para que la situacin pueda resolverse.

Una descripcin de lo que debe hacerse para eliminar el TBD, quien es el

responsable de su eliminacin y como debe hacerlo.

2.3.4. Consistente: La consistencia se refiere a la consistencia interior. Si un SRS no est

de acuerdo con algn documento de nivel superior, como una especificacin de requisitos
del sistema, entonces no es correcto.

2.3.4.1. Consistencia interior: Un SRS es internamente consistente si y slo si,

ningn subconjunto de requisitos individuales gener conflicto en l.

Los tres tipos de conflictos probables en un SRS son:

Las caractersticas especificadas en el

mundo real de los objetos pueden chocar.

El de un informe del rendimiento puede

describirse en un requisito como tabular
pero en otro como textual

Un requisito puede declarar que todas las

luces sern verdes mientras otro puede
declarar que todas las luces sean azules.

Puede haber conflicto lgico o temporal

entre dos acciones especificadas.

Dos o ms requisitos pueden describir el

mismo mundo real del objeto pero uso las
condiciones diferentes para ese objeto.

Un requisito puede especificar que el

programa sumar dos entradas y otro puede
especificar que el programa los multiplicar.
Un requisito puede declarar que "A" siempre
debe seguir "B", mientras otro puede
requerir
que
"A
y
B"
ocurran
simultneamente.
Una demanda del programa para una
entrada del usuario puede llamarse una
"sugerencia" en un requisito y una "seal" en
otro. El uso de terminologa normal y
definiciones promueve la consistencia.

2.3.5. Delinear que tiene importancia y/o estabilidad: Un SRS debe delinear la
importancia y/o estabilidad, si cada requisito en l tiene un identificador para indicar la
importancia o estabilidad de ese requisito en particular. Tpicamente, todos los requisitos
que relacionan a un producto del software no son igualmente importantes. Algunos
requisitos pueden ser esenciales, sobre todo para las aplicaciones de vida crtica,
mientras otros pueden ser deseables. Cada requisito en el SRS debe identificarse para
representar estas diferencias, aclarar y ser explcito. Para esto, se deben identificar los
requisitos de la manera siguiente:

Los clientes deben dar las consideraciones muy cuidadosamente a cada requisito
para que se clarifique cualquier omisin que ellos pueden tener.
Tener diseadores que hagan diseos correctos y pongan el mismo esfuerzo en
todos los niveles del producto del software.

2.3.5.1. Grado de estabilidad: Puede expresarse la estabilidad, por lo que se refiere

al nmero de cambios esperados a cualquier requisito basado en experiencia o
conocimiento de eventos venideros que afectan la organizacin, funciones y a las
personas que apoyan el sistema del software.

2.3.5.2. Grado de necesidad: Otra manera de alinear los requisitos es distinguir las
clases de requisitos que hay: el esencial, el condicional y optativo.

2.3.6. Comprobable: Un SRS es comprobable si y slo si, cada requisito declarado es

comprobable. Un requisito es comprobable si y slo si, all existe algn proceso rentable
finito con que una persona o la mquina puede verificar que el producto del software
rene el requisito. En general cualquier requisito ambiguo no es comprobable. Los
requisitos no verificables, incluyen las declaraciones como "trabaja bien", "interfase
humana buena" y "normalmente pasar". No pueden verificarse estos requisitos, porque
es imposible definir las condiciones "bueno," "bien" o "normalmente". La declaracin "el
programa nunca entrar en una vuelta infinita" es no verificable porque la comprobacin
de esta calidad es tericamente imposible. Un ejemplo de una declaracin comprobable
es:

El rendimiento del programa se producir dentro de 20 seg. de evento 60% del tiempo; y
se producir dentro de 30 seg. de evento 100% del tiempo. Esta declaracin puede
verificarse porque usa condiciones concretas y las cantidades mensurables. Si un
mtodo no puede inventarse para determinar si el software rene un requisito particular,
entonces ese requisito debe quitarse o debe revisarse.

2.3.7. Modificable: Un SRS es modificable si y slo si, su estructura y estilo son tales que
puede hacerse cualquier cambio a los requisitos fcilmente, completamente y de forma
consistente mientras conserva la estructura y estilo.

Las caractersticas necesarias para que un SRS sea modificable se muestran en el

siguiente esquema:

La redundancia no es un error, pero puede llevar fcilmente a los errores. La redundancia

puede ayudar hacer un SRS ms leble de vez en cuando, pero un problema puede
generarse cuando el documento redundante se actualiza.

2.3.8. Identificable: Un SRS es identificable si el origen de cada uno de sus requisitos

est claro y si facilita las referencias de cada requisito en el desarrollo futuro o
documentacin del mismo. Hay dos tipos de identificabilidad:

El identificable dirigido hacia atrs (es decir, a las fases anteriores de desarrollo).
Esto depende explcitamente en cada requisito, de las referencias de su fuente en
los documentos ms antiguos.

El identificable delantero (es decir, a todos los documentos desovados por el

SRS). Esto depende en cada requisito en el SRS que tiene un nico nombre o
nmero de la referencia. El identificable delantero del SRS es especialmente
importante cuando el producto del software entra en el funcionamiento y fase de
mantenimiento. Como el cdigo y documentos del plan se modifican, es esencial
poder determinar el juego completo de requisitos que pueden afectarse por esas
modificaciones.