INGENIERÍA DE

SOFTWARE I
Ing. Angel Ochoa Flores, MSc.
angel.ochoaf@ug.edu.ec
 MODELADO II
COMPRENSIÓN DE LOS REQUERIMIENTOS
Introducción
Entender los requerimientos de un problema es una de las tareas mas difíciles
que enfrenta el ingeniero de software.

Cuando se piensa por primera vez, no parece tan difícil desarrollar un

entendimiento claro de los requerimientos. Después de todo:
• acaso no sabe el cliente lo que se necesita?
• No deberían tener los usuarios finales una buena comprensión de las
características y funciones que le darán un beneficio?

Sorprendentemente, en muchas instancias la respuesta a estas preguntas es

“no”, e incluso si los clientes y los usuarios finales explican sus necesidades,
estas cambiaran mientras se desarrolla el proyecto.
INGENIERÍA DE REQUERIMIENTOS
El espectro amplio de tareas y técnicas que llevan a entender los requerimientos se denomina “ingeniería
de requerimientos”.
Desde la perspectiva del proceso del software, es una de las acciones importantes de la ingeniería de
software que comienza durante la actividad de comunicación y continua en la de modelado. Debe
adaptarse a las necesidades del proceso, del proyecto, del producto y de las personas que hacen el
trabajo.
La ingeniería de requerimientos tiende un puente para el diseño y la construcción. Pero: donde se origina
el puente?
Podría argumentarse que principia en los pies de los participantes en el proyecto (por ejemplo, gerentes,
clientes y usuarios), donde se definen las necesidades del negocio, se describen los escenarios de uso, se
delinean las funciones y características y se identifican las restricciones del proyecto. Otros tal vez
sugieran que empieza con una definición mas amplia del sistema, donde el software no es mas que un
componente del dominio del sistema mayor.
Pero sin importar el punto de arranque, el recorrido por el puente lo lleva a uno muy alto sobre el
proyecto, lo que le permite examinar el contexto del trabajo de software que debe realizarse; las
necesidades especificas que deben abordar el diseño y la construcción; las prioridades que guían el orden
en el que se efectúa el trabajo, y la información, las funciones y los comportamientos que tendrán un
profundo efecto en el diseño resultante.
La ingeniería de requerimientos proporciona el mecanismo apropiado
para entender lo que desea el cliente, analizar las necesidades, evaluar
la factibilidad, negociar una solución razonable, especificar la solución
sin ambigüedades, validar la especificación y administrar los
requerimientos a medida de que se transforman en un sistema
funcional.
Incluye siete tareas diferentes: concepción, indagación, elaboración,
negociación, especificación, validación y administración.
Es importante notar que algunas de estas tareas ocurren en paralelo y
que todas se adaptan a las necesidades del proyecto.
Concepción.
• Como inicia un proyecto de software?
• Existe un solo evento que se convierte en el catalizador de un nuevo sistema o producto
basado en computadora o la necesidad evoluciona en el tiempo?
No hay respuestas definitivas a estas preguntas. En ciertos casos, una conversación casual
es todo lo que se necesita para desencadenar un trabajo grande de ingeniería de software.
Pero en general, la mayor parte de proyectos comienzan cuando se identifica una
necesidad del negocio o se descubre un nuevo mercado o servicio potencial.
Los participantes de la comunidad del negocio, definen un caso de negocios para la idea,
tratan de identificar el ritmo y profundidad del mercado, hacen un análisis de gran visión
de la factibilidad e identifican una descripción funcional del alcance del proyecto.
Toda esta información esta sujeta a cambio, pero es suficiente para desencadenar análisis
con la organización de ingeniería de software. En la concepción del proyecto, se establece
el entendimiento básico del problema, las personas que quieren una solución, la
naturaleza de la solución que se desea, así como la eficacia de la comunicación y
colaboración preliminares entre los otros participantes y el equipo de software.
Indagación.
En verdad que parece muy simple: preguntar al cliente, a los usuarios y a otras personas cuales son
los objetivos para el sistema o producto, que es lo que va a lograrse, como se ajusta el sistema o
producto a las necesidades del negocio y, finalmente, como va a usarse el sistema o producto en las
operaciones cotidianas. Pero no es simple: es muy difícil.
Se pueden identificar cierto numero de problemas que se encuentran cuando ocurre la indagación:
• Problemas de alcance. La frontera de los sistemas esta mal definida o los clientes o usuarios
finales especifican detalles técnicos innecesarios que confunden, mas que clarifican, los objetivos
generales del sistema.
• Problemas de entendimiento. Los clientes o usuarios no están completamente seguros de lo que
se necesita, comprenden mal las capacidades y limitaciones de su ambiente de computación, no
entienden todo el dominio del problema, tienen problemas para comunicar las necesidades al
ingeniero de sistemas, omiten información que creen que es “obvia”, especifican requerimientos
que están en conflicto con las necesidades de otros clientes o usuarios, o solicitan requerimientos
ambiguos o que no pueden someterse a prueba.
• Problemas de volatilidad. Los requerimientos cambian con el tiempo.
Para superar estos problemas, debe enfocarse la obtención de requerimientos en forma organizada.
Elaboración.
La información obtenida del cliente durante la concepción e indagación se
expande y refina durante la elaboración. Esta tarea se centra en desarrollar
un modelo refinado de los requerimientos que identifique distintos
aspectos de la función del software, su comportamiento e información.
La elaboración esta motivada por la creación y mejora de escenarios de
usuario que describan como interactuara el usuario final (y otros actores)
con el sistema. Cada escenario de usuario se enuncia con sintaxis apropiada
para extraer clases de análisis, que son entidades del dominio del negocio
visibles para el usuario final.
Se definen los atributos de cada clase de análisis y se identifican los
servicios que requiere cada una de ellas. Se identifican las relaciones y
colaboración entre clases, y se producen varios diagramas adicionales.
Negociación.
No es raro que los clientes y usuarios pidan mas de lo que puede lograrse
dado lo limitado de los recursos del negocio. También es relativamente
común que distintos clientes o usuarios propongan requerimientos
conflictivos con el argumento de que su versión es “esencial para nuestras
necesidades especiales”.
Estos conflictos deben reconciliarse por medio de un proceso de
negociación. Se pide a clientes, usuarios y otros participantes que ordenen
sus requerimientos según su prioridad y que después analicen los conflictos.
Con el empleo de un enfoque iterativo que da prioridad a los
requerimientos, se evalúa su costo y riesgo, y se enfrentan los conflictos
internos; algunos requerimientos se eliminan, se combinan o se modifican
de modo que cada parte logre cierto grado de satisfacción.
Especificación.
En el contexto de los sistemas basados en computadora (y software), el termino
especificación tiene diferentes significados para distintas personas. Una
especificación puede ser un documento escrito, un conjunto de modelos gráficos,
un modelo matemático formal, un conjunto de escenarios de uso, un prototipo o
cualquier combinación de estos.
Algunos sugieren que para una especificación debe desarrollarse y utilizarse una
“plantilla estándar”, con el argumento de que esto conduce a requerimientos
presentados en forma consistente y por ello mas comprensible.
Sin embargo, en ocasiones es necesario ser flexible cuando se desarrolla una
especificación. Para sistemas grandes, el mejor enfoque puede ser un documento
escrito que combine descripciones en un lenguaje natural con modelos gráficos.
No obstante, para productos o sistemas pequeños que residan en ambientes bien
entendidos, quizá todo lo que se requiera sea escenarios de uso.
Validación.
La calidad de los productos del trabajo que se generan como consecuencia de la ingeniería de
los requerimientos se evalúa durante el paso de validación.
La validación de los requerimientos analiza la especificación a fin de garantizar que todos ellos
han sido enunciados sin ambigüedades; que se detectaron y corrigieron las inconsistencias, las
omisiones y los errores, y que los productos del trabajo se presentan conforme a los estándares
establecidos para el proceso, el proyecto y el producto.
El mecanismo principal de validación de los requerimientos es la revisión técnica. El equipo de
revisión que los valida incluye ingenieros de software, clientes, usuarios y otros participantes,
que analizan la especificación en busca de errores de contenido o de interpretación, de
aspectos en los que tal vez se requiera hacer aclaraciones, falta de información, inconsistencias
(problema notable cuando se hace la ingeniería de productos o sistemas grandes) y
requerimientos en conflicto o irreales (no asequibles).
Administración de los requerimientos.
Los requerimientos para sistemas basados en computadora cambian, y
el deseo de modificarlos persiste durante toda la vida del sistema.
La administración de los requerimientos es el conjunto de actividades
que ayudan al equipo del proyecto a identificar, controlar y dar
seguimiento a los requerimientos y a sus cambios en cualquier
momento del desarrollo del proyecto.
Muchas de estas actividades son idénticas a las técnicas de
administración de la configuración del software (TAS).
ESTABLECER LAS BASES
En el caso ideal, los participantes e ingenieros de software trabajan juntos en el mismo equipo. En esas
condiciones, la ingeniería de requerimientos tan solo consiste en sostener conversaciones significativas
con colegas que sean miembros bien conocidos del equipo.
Pero es frecuente que en la realidad esto sea muy diferente. Los clientes o usuarios finales tal vez se
encuentren en ciudades o países diferentes, quizá solo tengan una idea vaga de lo que se requiere, puede
ser que tengan opiniones en conflicto sobre el sistema que se va a elaborar, que posean un conocimiento
técnico limitado o que dispongan de poco tiempo para interactuar con el ingeniero que recabara los
requerimientos.
Ninguna de estas posibilidades es deseable, pero todas son muy comunes y es frecuente verse forzado a
trabajar con las restricciones impuestas por esta situación.
A continuación se estudian las etapas requeridas para establecer las bases que permiten entender los
requerimientos de software a fin de que el proyecto comience en forma tal que se mantenga avanzando
hacia una solución exitosa.
1. Identificación de los participantes: cualquier persona que se beneficie en forma directa o
indirecta del sistema en desarrollo.
2. Reconocer los múltiples puntos de vista: Debe clasificarse toda la información de los
participantes (incluso los requerimientos inconsistentes y conflictivos) en forma que permita
a quienes toman las decisiones escoger para el sistema un conjunto de requerimientos que
tenga coherencia interna.
3. Trabajar hacia la colaboración: El trabajo del ingeniero de requerimientos es identificar las
áreas de interés común (por ejemplo, requerimientos en los que todos los participantes estén
de acuerdo) y las de conflicto o incongruencia (por ejemplo, requerimientos que desea un
participante, pero que están en conflicto con las necesidades de otro).
4. Hacer las primeras preguntas: El primer conjunto de ellas se centran en el cliente y en otros
participantes, en las metas y beneficios generales. Las preguntas siguientes permiten
entender mejor el problema y hacen que el cliente exprese sus percepciones respecto de la
solución. Las preguntas finales se centran en la eficacia de la actividad de comunicación en si.
INDAGACIÓN DE LOS
REQUERIMIENTOS
La indagación de los requerimientos (actividad también llamada
recabación de los requerimientos) combina elementos de la solución
de problemas, elaboración, negociación y especificación.
A fin de estimular un enfoque colaborativo y orientado al equipo, los
participantes trabajan juntos para identificar el problema, proponer
elementos de la solución, negociar distintas visiones y especificar un
conjunto preliminar de requerimientos para la solución.
Recabación 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 básicos:
• Tanto ingenieros de software como otros participantes dirigen o intervienen en las reuniones.
• Se establecen reglas para la preparación y participación.
• 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 reunión.
• Se utiliza un “mecanismo de definición” (que pueden ser hojas de trabajo, tablas sueltas,
etiquetas adhesivas, pizarrón electrónico, grupos de conversación o foro virtual).
Despliegue de la función de calidad
El despliegue de la función de calidad (DFC) es una técnica de administración de
la calidad que traduce las necesidades del cliente en requerimientos técnicos
para el software. El DFC “se concentra en maximizar la satisfacción del cliente a
partir del proceso de ingeniería del software”.
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 ingeniería. El DFC
identifica tres tipos de requerimientos:
• Requerimientos normales.
• Requerimientos esperados.
• Requerimientos emocionantes.
Aunque los conceptos del DFC son aplicables en todo el proceso del
software, hay técnicas especificas de aquel que pueden aplicarse a la
actividad de indagación de los requerimientos.
El DFC utiliza entrevistas con los clientes, observación, encuestas y estudio
de datos históricos (por ejemplo, reportes de problemas) como materia
prima para la actividad de recabación de los requerimientos.
Después, 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 métodos de evaluación
para extraer los requerimientos esperados y tratar de percibir
requerimientos emocionantes.
Escenarios de uso
A medida que se reúnen los requerimientos, comienza a materializarse la
visión general de funciones y características del sistema. Sin embargo, es
difícil avanzar hacia actividades mas técnicas de la ingeniería de software
hasta no entender como emplearan los usuarios finales dichas funciones
y características.
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,
proporcionan la descripción de la manera en la que se utilizara el sistema.
Indagación de los productos del trabajo
Los productos del trabajo generados como consecuencia de la indagación de los requerimientos
variaran en función del tamaño del sistema o producto que se va a construir. Para la mayoría 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 indagación de los requerimientos.
• Una descripción del ambiente técnico del sistema.
• Una lista de requerimientos (de preferencia organizados por función) 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 operación.
• Cualesquiera prototipos desarrollados para definir requerimientos.
Cada uno de estos productos del trabajo es revisado por todas las personas que participan en la
indagación de los requerimientos.
DESARROLLO DE CASOS DE USO
En esencia, un caso de uso narra una historia estilizada sobre como interactúa un usuario final
(que tiene cierto numero de roles posibles) con el sistema en circunstancias especificas. La
historia puede ser un texto narrativo, un lineamiento de tareas o interacciones, una descripción
basada en un formato o una representación diagramática. Sin importar su forma, un caso de
uso ilustra el software o sistema desde el punto de vista del usuario final. El primer paso para
escribir un caso de uso es definir un conjunto de “actores” que estarán involucrados en la
historia.
Los actores son las distintas personas (o dispositivos) que usan el sistema o producto en el
contexto de la función y comportamiento que va a describirse. Los actores representan los
papeles que desempeñan las personas (o dispositivos) cuando opera el sistema. Con una
definición mas formal, un actor es cualquier cosa que se comunique con el sistema o producto
y que sea externo a este. Todo actor tiene uno o mas objetivos cuando utiliza el sistema.
Una vez identificados los actores, es posible desarrollar casos de uso. Se sugiere varias
preguntas que debe responder un caso de uso:
• Quien es el actor principal y quien(es) el(los) secundario(s)?
• Cuales son los objetivos de los actores?
• Que precondiciones deben existir antes de comenzar la historia?
• Que tareas o funciones principales son realizadas por el actor?
• Que excepciones deben considerarse al describir la historia?
• Cuales variaciones son posibles en la interacción del actor?
• Que información del sistema adquiere, produce o cambia el actor?
• Tendrá que informar el actor al sistema acerca de cambios en el ambiente externo?
• Que información desea obtener el actor del sistema?
• Quiere el actor ser informado sobre cambios inesperados?
ELABORACIÓN DEL MODELO DE LOS REQUERIMIENTOS

El objetivo del modelo del análisis es describir los dominios de

información, función y comportamiento que se requieren para un
sistema basado en computadora. El modelo cambia en forma dinámica
a medida que se aprende mas sobre el sistema por construir, y otros
participantes comprenden mas lo que en realidad requieren.
Por esa razón, el modelo del análisis es una fotografía de los
requerimientos en cualquier momento dado. Es de esperar que cambie.
A medida que evoluciona el modelo de requerimientos, ciertos
elementos se vuelven relativamente estables, lo que da un fundamento
solido para diseñar las tareas que sigan. Sin embargo, otros elementos
del modelo son mas volátiles, lo que indica que los participantes
todavía no entienden bien los requerimientos para el sistema.
Elementos del modelo de requerimientos
Hay muchas formas diferentes de concebir los requerimientos para un
sistema basado en computadora. Algunos profesionales del software afirman
que es mejor seleccionar un modo de representación (por ejemplo, el caso
de uso) y aplicarlo hasta excluir a todos los demás. Otros piensan que es mas
benéfico usar cierto numero de modos de representación distintos para
ilustrar el modelo de requerimientos.
Los modos diferentes de representación fuerzan a considerar los
requerimientos desde distintos puntos de vista, enfoque que tiene una
probabilidad mayor de detectar omisiones, inconsistencia y ambigüedades.
Los elementos específicos del modelo de requerimientos están determinados
por el método de análisis de modelado que se use. No obstante, la mayoría
de modelos tiene en común un conjunto de elementos generales.
Elementos basados en el escenario.
El sistema se describe desde el punto de vista del usuario con el empleo
de un enfoque basado en el escenario. Los elementos del modelo de
requerimientos basados en el escenario con frecuencia son la primera
parte del modelo en desarrollo. Como tales, sirven como entrada para
la creación de otros elementos de modelado.
La figura ilustra un diagrama de actividades UML para indagar los
requerimientos y representarlos con el empleo de casos de uso.
Se aprecian tres niveles de elaboración que culminan en una
representación basada en el escenario.
Elementos basados en clases.
Cada escenario de uso implica un conjunto de objetos que se manipulan cuando
un actor interactúa con el sistema. Estos objetos se clasifican en clases: conjunto
de objetos que tienen atributos similares y comportamientos comunes. Por
ejemplo, para ilustrar la clase Sensor de la función de seguridad de Casa Segura
(véase la figura 5.4), puede utilizarse un diagrama de clase UML.
Observe que el diagrama enlista los atributos de los sensores (por ejemplo,
nombre, tipo, etc.) y las operaciones (por ejemplo, identificar y permitir) que se
aplican para modificarlos. Además de los diagramas de clase, otros elementos
de modelado del análisis ilustran la manera en la que las clases colaboran una
con otra y las relaciones e interacciones entre ellas.
Elementos de comportamiento
El comportamiento de un sistema basado en computadora tiene un efecto
profundo en el diseño que se elija y en el enfoque de implementación que se
aplique. Por tanto, el modelo de requerimientos debe proveer elementos de
modelado que ilustren el comportamiento.
El diagrama de estado es un método de representación del comportamiento de
un sistema que ilustra sus estados y los eventos que ocasionan que el sistema
cambie de estado.
Un estado es cualquier modo de comportamiento observable desde el exterior.
Además, el diagrama de estado indica acciones (como la activación de un
proceso, por ejemplo) tomadas como consecuencia de un evento en particular.
Elementos orientados al flujo.
La información se transforma cuando fluye a través de un sistema basado en
computadora.
El sistema acepta entradas en varias formas, aplica funciones para transformarla y
produce salidas en distintos modos.
La entrada puede ser una señal de control transmitida por un transductor, una serie
de números escritos con el teclado por un operador humano, un paquete de
información enviado por un enlace de red o un archivo grande de datos recuperado
de un almacenamiento secundario.
La transformación quizá incluya una sola comparación lógica, un algoritmo
numérico complicado o un enfoque de regla de inferencia para un sistema experto.
La salida quizá encienda un diodo emisor de luz o genere un informe de 200
paginas. En efecto, es posible crear un modelo del flujo para cualquier sistema
basado en computadora, sin importar su tamaño y complejidad.
VALIDACIÓN DE LOS REQUERIMIENTOS
A medida que se crea cada elemento del modelo de requerimientos, se estudia para
detectar inconsistencias, omisiones y ambigüedades. Los participantes asignan
prioridades a los requerimientos representados por el modelo y se agrupan en
paquetes de requerimientos que se implementaran como incrementos del software.
La revisión del modelo de requerimientos aborda las preguntas siguientes:
• Es coherente cada requerimiento con los objetivos generales del sistema o producto?
• Se han especificado todos los requerimientos en el nivel apropiado de abstracción? Es
decir, .algunos de ellos tienen un nivel de detalle técnico que resulta inapropiado en
esta etapa?
• El requerimiento, es realmente necesario o representa una característica agregada
que tal vez no sea esencial para el objetivo del sistema?
• Cada requerimiento esta acotado y no es ambiguo?
• Tiene atribución cada requerimiento? Es decir, .hay una fuente (por lo general una
individual y especifica) clara para cada requerimiento?
• Hay requerimientos en conflicto con otros?
• Cada requerimiento es asequible en el ambiente técnico que albergara el
sistema o producto?
• Una vez implementado cada requerimiento, puede someterse a prueba?
• El modelo de requerimientos, .refleja de manera apropiada la información, la
función y el comportamiento del sistema que se va a construir?
• Se ha “particionado” el modelo de requerimientos en forma que exponga
información cada vez mas detallada sobre el sistema?
• Se ha usado el patrón de requerimientos para simplificar el modelo de estos?
• Se han validado todos los patrones de manera apropiada? .Son consistentes
todos los patrones con los requerimientos del cliente?
Estas y otras preguntas deben plantearse y responderse para garantizar que el
modelo de requerimientos es una reflexión correcta sobre las necesidades del
participante y que provee un fundamento solido para el diseño.