ANLISIS 4.

REQUISITOS

Este tema tiene que ver con el proceso de anlisis de requisitos a:

Detectar y resolver los conflictos entre requisitos.

Descubrir los lmites del software y cmo debe interactuar con su entorno
organizacional y operativo.
Requisitos del sistema elaborados para derivar los requisitos de software.

La visin tradicional de anlisis de requerimientos ha sido que sea reducido a

modelado conceptual usando uno de varios mtodos de anlisis, tales como el
mtodo de anlisis estructurado. Si bien el modelado conceptual es importante,
Incluimos la clasificacin de los requisitos para ayudar a informar a las
compensaciones entre los requisitos (clasificacin requisitos) y el proceso de
creacin de estos compensaciones (requisitos de negociacin).
Se debe tener cuidado para describir los requisitos suficientes, precisamente para
permitir a los requisitos para ser validados, su aplicacin para ser verificada, y sus
costes a estimar.
4.1. Clasificacin de requerimientos
Los requisitos pueden ser clasificados en un nmero de dimensiones.
Algunos ejemplos son los siguientes:

Si el requisito es funcional o no funcional (ver seccin 1.3, Funcional y

requisitos no funcionales).

Si el requisito se deriva de uno o ms requisitos de alto nivel o una

propiedad emergente (ver seccin 1.4, las propiedades emergentes), o est
siendo impuesta directamente en el software por una de las partes
interesadas o de alguna otra fuente.

Si el requisito es en el producto o el proceso (ver seccin 1.2, del producto

y requisitos de proceso). Requisitos sobre el proceso pueden limitar la
eleccin del contratista, el proceso de ingeniera de software para ser
adoptado, o las normas que deben cumplirse.

La prioridad requisito. Cuanto mayor sea la prioridad, ms esencial es el

requisito para cumplir con los objetivos generales del programa. A menudo
clasifican en una escala de coma fija como obligatoria, muy deseable,

deseable o opcional, la prioridad a menudo tiene que ser equilibrada contra

el costo de desarrollo y aplicacin.

El alcance de la prescripcin. mbito de aplicacin se refiere a la medida en

que un requisito afecta a los componentes de software y de software.
Algunos de los requisitos, en especial a algunos que no funcionales, tienen
un alcance global en que su satisfaccin no puede ser asignado a un
componente discreto. Por lo tanto, un requisito con el alcance global puede
afectar fuertemente la arquitectura de software y el diseo de muchos
componentes, mientras que uno con un alcance limitado puede ofrecer una
serie de opciones de diseo y tienen poco impacto en la satisfaccin de
otras necesidades.

Volatilidad / estabilidad. Algunos requisitos cambiarn durante el ciclo de

vida del software- e incluso durante el propio proceso de desarrollo. Es til
si alguna estimacin de la probabilidad de que un requisito cambiar puede
hacerse. Por ejemplo, en una banca
aplicacin, los requisitos para las funciones para calcular y el inters de
crdito a los clientes cuentas tienden a ser ms estable que un requisito
para apoyar un tipo particular de cuenta libre de impuestos. El primero
refleja una caracterstica fundamental del dominio bancario (que las cuentas
pueden ganar intereses), mientras que los segundos pueden dejarlo
obsoleto por un cambio en la legislacin del gobierno. Cmo marcar
requisitos potencialmente voltiles puede ayudar al ingeniero de software
de establecer un diseo que es ms tolerante de cambio.

Otras clasificaciones pueden ser apropiados, dependiendo de la prctica normal

de la organizacin y la propia aplicacin.
Existe una fuerte coincidencia entre atributos requisitos de clasificacin y
requisitos (ver seccin 7.3, Requisitos Atributos).

4.2. Modelado conceptual

El desarrollo de modelos de un problema del mundo real es clave para el anlisis
de los requisitos de software.
Su propsito es ayudar en la comprensin de la situacin en la que se produce el
problema, as como que representa una solucin. Por lo tanto, los modelos
conceptuales comprenden modelos de entidades del dominio del problema,

configurado para reflejar sus relaciones del mundo real y dependencias. Este tema
est estrechamente relacionado con los modelos de ingeniera de software y
Mtodos KA.
Varios tipos de modelos se pueden desarrollar. Estos incluyen diagramas de casos
de uso, los modelos de flujo de datos, modelos de estado, los modelos basados
en objetivos, las interacciones del usuario, modelos de objetos, modelos de datos,
y muchos otros. Muchas de estas notaciones de modelado son parte de la Unified
Modeling Language (UML). Usar diagramas de casos, por ejemplo, se utilizan
habitualmente para representar escenarios en los que el lmite que separa a los
actores (usuarios o sistemas en el entorno externo) Del comportamiento interno,
donde cada caso de uso representa una funcionalidad del sistema.

Los factores que influyen en la eleccin de la notacin de modelado incluyen los

siguientes:

La naturaleza del problema. Algunos tipos de software exigen que ciertos

aspectos se analizarn especialmente rigurosa. Para los modelos de
ejemplo, estatales y paramtricas, que son parte de SysML [4], es probable
que sean ms importantes para el software en tiempo real de los sistemas
de informacin, mientras que por lo general sera lo contrario para los
modelos de objetos y de actividad.

La experiencia del ingeniero de software. A menudo es ms productivo

adoptar una notacin de modelado o el mtodo con el que el ingeniero de
software con experiencia.

Los requisitos del proceso del cliente (ver seccin 1.2, Productos y
Procesos Requisitos). Los clientes pueden imponer su notacin o mtodo
favorecido o prohibir cualquier con las que estn familiarizados. Este factor
puede entrar en conflicto con el factor anterior.

Tenga en cuenta que, en casi todos los casos, es til comenzar mediante la
construccin de un modelo del contexto software. El contexto software proporciona
una conexin entre los programas informticos destinados y su entorno externo.
Esto es crucial para entender el contexto del software en su entorno operativo y
para la identificacin de sus interfaces con el medio ambiente.

Este subtema no busca "ensear" un estilo de modelado en particular o la

notacin sino ms bien proporciona orientacin sobre el propsito y la intencin de
la modelizacin.
4.3. Diseo y requisitos arquitectnicos de asignacin
En algn momento, la arquitectura de la solucin debe ser derivada. El diseo
arquitectnico es el punto en el que el proceso se superpone con los requisitos de
software o sistemas de diseo e ilustra cun imposible es disociar limpiamente las
dos tareas.
Este tema est estrechamente relacionado con la estructura del software y la
arquitectura en el diseo de software KA. En muchos casos, los actos de
ingeniera de software como arquitecto de software debido a que el proceso de
anlisis y la elaboracin de los requisitos exige que se identifiquen los
componentes de la arquitectura / diseo que se encargarn de satisfacer los
requisitos. Se trata de requisitos de asignacin de-la asignacin de componentes
de la arquitectura responsables de la satisfaccin de las necesidades.
Asignacin es importante para permitir un anlisis detallado de las necesidades.
Por lo tanto, por ejemplo, una vez que un conjunto de requisitos se ha asignado a
un componente, los requisitos individuales se pueden analizar an ms para
descubrir nuevos requisitos sobre cmo el componente necesita interactuar con
otros componentes con el fin de satisfacer los requerimientos asignados.
En grandes proyectos, la asignacin estimula una nueva ronda de anlisis para
cada subsistema. Como ejemplo, los requisitos para un rendimiento de frenado en
particular para un coche (distancia de frenado, la seguridad en malas condiciones
de conduccin, la suavidad de la aplicacin, la presin del pedal necesarios, y as
sucesivamente) pueden asignarse al hardware de frenado (conjuntos mecnicos e
hidrulicos) y una sistema de frenos antibloqueo (ABS). Slo cuando un requisito
para un sistema de frenado antibloqueo ha sido identificado, y los requisitos que
se le asignen, se puede utilizar las capacidades del ABS, el hardware de frenado y
propiedades emergentes (tales como el peso del coche) para identificar los
requisitos detallados de software del ABS.
El diseo arquitectnico est estrechamente identificado con el modelado
conceptual (ver seccin 4.2, Modelado Conceptual).

4.4. Requerimientos de negociacin

Otro trmino comnmente utilizado para este subtema es "resolucin de

conflictos". Esto se refiere la resolucin de problemas con los requisitos que se
producen conflictos entre dos partes interesadas que requieran funciones
incompatibles entre s, entre las necesidades y los recursos, o entre requisitos
funcionales y no funcionales, por ejemplo. En la mayora de los casos, no es
aconsejable para el ingeniero de software para hacer una decisin unilateral, por
lo que se hace necesario consultar con la parte interesada (s) para llegar a un
consenso sobre una compensacin adecuada. A menudo es importante, por
razones contractuales, que tales decisiones volvern trazable al cliente. Hemos
clasificado esto como un tema de anlisis de requisitos de software porque los
problemas surgen como el resultado del anlisis. Sin embargo, un caso fuerte
tambin se puede hacer por considerarlo un tema de validacin requisitos (ver
tema 6, Requisitos de validacin).
Requisitos priorizacin es necesario, no slo como un medio para filtrar los
requisitos importantes, sino tambin con el fin de resolver los conflictos y planificar
las entregas escalonadas, lo que significa tomar decisiones complejas que
requieren un conocimiento detallado de dominio
y buenas habilidades de estimacin. Sin embargo, a menudo es difcil obtener
informacin real que puede actuar como una base para tales decisiones. Adems,
los requisitos a menudo dependen unos de otros, y las prioridades son relativas.
En la prctica, los ingenieros de software realizan requisitos priorizacin con
frecuencia sin necesidad de conocer todos los requisitos.
Requisitos priorizacin puede seguir un enfoque de valor costo que implica un
anlisis de las partes interesadas definen en una escala de los beneficios o el
valor agregado que la aplicacin del requisito de las trae, contra las penas de no
haber implementado un requisito particular. Tambin implica un anlisis de los
ingenieros de software de estimacin en una escala el costo de la implementacin
de cada requisito, relativo
a otros requisitos. Otro enfoque requisitos priorizacin llama el proceso analtico
jerrquico implica la comparacin de todos los pares nicos de los requisitos para
determinar cul de los dos es de mayor prioridad, y en qu medida.

4.5. Anlisis formal

Anlisis preocupaciones formales no slo el tema 4, sino tambin las secciones
5.3 y 6.3. En este tema tambin se relaciona con los mtodos formales en los
modelos de ingeniera de software y mtodos rea de Conocimiento.
Anlisis formal ha hecho un impacto en algunos dominios de aplicacin, en
particular los de los sistemas de alta integridad. La expresin formal de requisitos
requiere un lenguaje con semntica definida formalmente. El uso de un anlisis
formal para los requisitos de expresin tiene dos beneficios.
En primer lugar, permite a los requisitos expresados en el lenguaje para
especificar con precisin y sin ambigedades, por lo tanto (en principio) para evitar
la posibilidad de una mala interpretacin. En segundo lugar, los requisitos se
puede razonar sobre, permitiendo propiedades deseadas del software
especificado por demostrar. Razonamiento formal requiere soporte de
herramientas para ser practicable para distintos de los sistemas triviales nada, y
las herramientas generalmente se dividen en dos tipos: demostradores de
teoremas o las damas modelo. En ninguno de los casos puede ser completamente
a prueba automatizado, y el nivel de competencia en razonamiento formal sea
necesario con el fin de utilizar las herramientas restringe la aplicacin ms amplia
de anlisis formal.

El mayor anlisis formal se centra en etapas relativamente tardas de anlisis de

requisitos. En general, es contraproducente para solicitar la formalizacin hasta
que los objetivos de negocio y necesidades de los usuarios han entrado en un
enfoque ntido a travs de medios tales como los descritos en otras partes de la
seccin 4. Sin embargo, una vez que los requisitos se han estabilizado y se han
elaborado para especificar las propiedades del concreto del software, puede ser
beneficioso para la formalizacin de al menos los requisitos crticos. esto permite
validacin esttica que el software especificado por los requisitos s tiene las
propiedades (por ejemplo, ausencia de estancamiento) que el cliente, los usuarios,
y el ingeniero de software de esperar que tenga.

5.3 INDAGACIN DE LOS REQUERIMIENTOS

La indagacin de los requerimientos (actividad tambin llamada recabacin de los
requerimientos) combina elementos de la solucin de problemas, elaboracin,
negociacin y especificacin.
A fin de estimular un enfoque colaborativo y orientado al equipo, los participantes
trabajan juntos para identificar el problema, proponer elementos de la solucin,
negociar distintas visiones y especificar un conjunto preliminar de requerimientos
para la solucin [Zah90].
5.3.1 Recabacin de los requerimientos en forma colaborativa
Se han propuesto muchos enfoques distintos para recabar los requerimientos en
forma colaborativa.
Cada uno utiliza un escenario un poco diferente, pero todos son variantes de los
siguientes lineamientos bsicos:
Tantos ingenieros de software como otros participantes dirigen o intervienen en las
reuniones.
Se establecen reglas para la preparacin y participacin.
Se sugiere una agenda con suficiente formalidad para cubrir todos los puntos
importantes, pero con la suficiente informalidad para que estimule el libre flujo de
ideas.
Un facilitador (cliente, desarrollador o participante externo) controla la reunin.
Se utiliza un mecanismo de definicin (que pueden ser hojas de trabajo, tablas
sueltas, etiquetas adhesivas, pizarrn electrnico, grupos de conversacin o foro
virtual).
La meta es identificar el problema, proponer elementos de la solucin, negociar
distintos enfoques y especificar un conjunto preliminar de requerimientos de la
solucin en una atmsfera que favorezca el logro de la meta. Para entender mejor
el flujo de eventos conforme ocurren, se presenta un escenario breve que
bosqueja la secuencia de hechos que llevan a la reunin para obtener
requerimientos, a lo que sucede durante sta y a lo que sigue despus de ella.
Durante la concepcin (vase la seccin 5.2), hay preguntas y respuestas bsicas
que establecen el alcance del problema y la percepcin general de lo que
constituye una solucin. Fuera de estas reuniones iniciales, el desarrollador y los
clientes escriben una o dos pginas de solicitud de producto.
Se selecciona un lugar, fecha y hora para la reunin, se escoge un facilitador y se
invita a asistir a integrantes del equipo de software y de otras organizaciones
participantes. Antes de la fecha de la reunin, se distribuye la solicitud de producto
a todos los asistentes.

Por ejemplo, considere un extracto de una solicitud de producto escrita por una
persona de mercadotecnia involucrada en el proyecto CasaSegura. Esta persona
escribe la siguiente narracin sobre la funcin de seguridad en el hogar que va a
ser parte de CasaSegura:
Nuestras investigaciones indican que el mercado para los sistemas de
administracin del hogar crece a razn de 40% anual. La primera funcin de
CasaSegura que llevemos al mercado deber ser la de seguridad del hogar. La
mayora de la gente est familiarizada con sistemas de alarma, por lo que sta
deber ser fcil de vender.
La funcin de seguridad del hogar protegera, o reconocera, varias situaciones
indeseables, como acceso ilegal, incendio y niveles de monxido de carbono,
entre otros. Empleara sensores inalmbricos para detectar cada situacin. Sera
programada por el propietario y telefoneara en forma automtica a una agencia
de vigilancia cuando detectara una situacin como las descritas. En realidad,
durante la reunin para recabar los requerimientos, otros contribuiran a esta
narracin y se dispondra de mucha ms informacin. Pero aun con sta habra
ambigedad, sera probable que existieran omisiones y ocurrieran errores. Por
ahora bastar la descripcin funcional anterior.
Mientras se revisa la solicitud del producto antes de la reunin, se pide a cada
asistente que elabore una lista de objetos que sean parte del ambiente que
rodear al sistema, los objetos que producir ste y los que usar para realizar
sus funciones. Adems, se solicita a cada asistente que haga otra lista de
servicios (procesos o funciones) que manipulen o interacten con los objetos. Por
ltimo, tambin se desarrollan listas de restricciones (por ejemplo, costo, tamao,
reglas del negocio, etc.) y criterios de desempeo (como velocidad y exactitud). Se
informa a los asistentes que no se espera que las listas sean exhaustivas, pero s
que reflejen la percepcin que cada persona tiene del sistema.
Entre los objetos descritos por CasaSegura tal vez estn incluidos el panel de
control, detectores de humo, sensores en ventanas y puertas, detectores de
movimiento, alarma, un evento (activacin de un sensor), una pantalla, una
computadora, nmeros telefnicos, una llamada telefnica, etc. La lista de
servicios puede incluir configurar el sistema, preparar la alarma, vigilar los
sensores, marcar el telfono, programar el panel de control y leer la pantalla
(observe que los servicios actan sobre los objetos). En forma similar, cada
asistente desarrollar una lista de restricciones (por ejemplo, el sistema debe
reconocer cuando los sensores no estn operando, debe ser amistoso con el
usuario, debe tener una interfaz directa con una lnea telefnica estndar, etc.) y
de criterios de desempeo (un evento en un sensor debe reconocerse antes de un
segundo, debe implementarse un esquema de prioridad de eventos, etctera).

Las listas de objetos pueden adherirse a las paredes del cuarto con el empleo de
pliegos de papel grandes o con lminas adhesivas, o escribirse en un tablero.
Alternativamente, las listas podran plasmarse en un boletn electrnico, sitio web
interno o en un ambiente de grupo de conversacin para revisarlas antes de la
reunin. Lo ideal es que cada entrada de las listas pueda manipularse por
separado a fin de combinar las listas o modificar las entradas y agregar otras. En
esta etapa, estn estrictamente prohibidos las crticas y el debate.
Una vez que se presentan las listas individuales acerca de un rea temtica, el
grupo crea una lista, eliminando las entradas redundantes o agregando ideas
nuevas que surjan durante el anlisis, pero no se elimina ninguna. Despus de
crear listas combinadas para todas las reas temticas, sigue el anlisis,
coordinado por el facilitador. La lista combinada se acorta, se alarga o se modifica
su redaccin para que refleje de manera apropiada al producto o sistema que se
va a desarrollar. El objetivo es llegar a un consenso sobre la lista de objetos,
servicios, restricciones y desempeo del sistema que se va a construir.
En muchos casos, un objeto o servicio descrito en la lista requerir mayores
explicaciones. Para lograr esto, los participantes desarrollan mini especificaciones
para las entradas en las listas. Cada mini especificacin es una elaboracin de un
objeto o servicio. Por ejemplo, la correspondiente al objeto Panel de control de
Casa Segura sera as:
El panel de control es una unidad montada en un muro, sus dimensiones
aproximadas son de 9 por 5 pulgadas. Tiene conectividad inalmbrica con los
sensores y con una PC. La interaccin con el usuario tiene lugar por medio de un
tablero que contiene 12 teclas. Una pantalla de cristal lquido de 3 por 3 pulgadas
brinda retroalimentacin al usuario. El software hace anuncios interactivos, como
eco y funciones similares.
Las mini especificaciones se presentan a todos los participantes para que sean
analizadas. Se hacen adiciones, eliminaciones y otras modificaciones. En ciertos
casos, el desarrollo de las mini especificaciones descubrir nuevos objetos,
servicios o restricciones, o requerimientos de desempeo que se agregarn a las
listas originales. Durante todos los anlisis, el equipo debe posponer los aspectos
que no puedan resolverse en la reunin. Se conserva una lista de aspectos para
volver despus a dichas ideas.
5.3.2 Despliegue de la funcin de calidad
El despliegue de la funcin de calidad (DFC) es una tcnica de administracin de
la calidad que traduce las necesidades del cliente en requerimientos tcnicos para
el software. El DFC se concentra en maximizar la satisfaccin del cliente a partir
del proceso de ingeniera del software [Zul92]. Para lograr esto, el DFC pone el
nfasis en entender lo que resulta valioso para el cliente y luego despliega dichos
valores en todo el proceso de ingeniera. El DFC identifica tres tipos de
requerimientos [Zul92]:

Requerimientos normales. Objetivos y metas que se establecen para un

producto o sistema durante las reuniones con el cliente. Si estos requerimientos
estn presentes, el cliente queda satisfecho. Ejemplos de requerimientos normales
son los tipos de grficos pedidos para aparecer en la pantalla, funciones
especficas del sistema y niveles de rendimiento definidos.
Requerimientos esperados. Estn implcitos en el producto o sistema y quiz
sean tan importantes que el cliente no los mencione de manera explcita. Su
ausencia causar mucha insatisfaccin. Algunos ejemplos de requerimientos
esperados son: fcil interaccin humano/mquina, operacin general correcta y
confiable, y facilidad para instalar el software.
Requerimientos emocionantes. Estas caractersticas van ms all de las
expectativas del cliente y son muy satisfactorias si estn presentes. Por ejemplo,
el software para un nuevo telfono mvil viene con caractersticas estndar, pero
si incluye capacidades inesperadas (como pantalla sensible al tacto, correo de voz
visual, etc.) agrada a todos los usuarios del producto.
Aunque los conceptos del DFC son aplicables en todo el proceso del software
[Par96a], hay tcnicas especficas de aqul que pueden aplicarse a la actividad de
indagacin de los requerimientos. El DFC utiliza entrevistas con los clientes,
observacin, encuestas y estudio de datos histricos (por ejemplo, reportes de
problemas) como materia prima para la actividad de recabacin de los
requerimientos. Despus, estos datos se llevan a una tabla de requerimientos
llamada tabla de la voz del cliente que se revisa con el cliente y con otros
participantes. Luego se emplean varios diagramas, matrices y mtodos de
evaluacin para extraer los requerimientos esperados y tratar de percibir
requerimientos emocionantes [Aka04].

5.3.3 Escenarios de uso

A medida que se renen los requerimientos, comienza a materializarse la visin
general de funciones y caractersticas del sistema. Sin embargo, es difcil avanzar
hacia actividades ms tcnicas de la ingeniera de software hasta no entender
cmo emplearn los usuarios finales dichas funciones y caractersticas. Para
lograr esto, los desarrolladores y usuarios crean un conjunto de escenarios que
identifican la naturaleza de los usos para el sistema que se va a construir. Los
escenarios, que a menudo se llaman casos de uso [Jac92], proporcionan la
descripcin de la manera en la que se utilizar el sistema. Los casos de uso se
estudian con ms detalle en la seccin 5.4.

5.3.4 Indagacin de los productos del trabajo

Los productos del trabajo generados como consecuencia de la indagacin de los
requerimientos variarn en funcin del tamao del sistema o producto que se va a
construir. Para la mayora de sistemas, los productos del trabajo incluyen los
siguientes:
Un enunciado de la necesidad y su factibilidad.
Un enunciado acotado del alcance del sistema o producto.
Una lista de clientes, usuarios y otros participantes que intervienen en la
indagacin de los requerimientos.
Una descripcin del ambiente tcnico del sistema.
Una lista de requerimientos (de preferencia organizados por funcin) y las
restricciones del dominio que se aplican a cada uno.
Un conjunto de escenarios de uso que dan perspectiva al uso del sistema o
producto en diferentes condiciones de operacin.
Cualesquiera prototipos desarrollados para definir requerimientos. Cada uno de
estos productos del trabajo es revisado por todas las personas que participan en la
indagacin de los requerimientos.