RESUMEN CAPITULO 7

7 . 1 Estudios de viabilidad
7 . 2 Obtención y análisis de requerimientos
7.2.1 Descubrimiento de requerimientos
7.2.2 Etnografía
7 . 3 Validación de requerimientos
7.3.1 Revisiones de requerimientos
7 . 4 Gestión de requerimientos
7.4.1 Requerimientos duraderos y volátiles
7.4.2 Planificación de la gestión de requerimientos
7.4.3 Gestión del cambio de los requerimientos

RESUMEN CAPITULO 7

Está dividido en :

Estudios de viabilidad: se da un informe de validación

Obtención y análisis de requerimientos: se muestran

modelos del sistema

Especificación de requerimientos: se determinan los

requerimientos del usuario y del sistema

Validación de requerimientos: se documentan los

requerimientos
7 . 1 Estudios de viabilidad

Es un estudio corto y orientado a resolver cuestiones o

problemas como:

 ¿Contribuye el sistema a los objetivos generales de la

organización?

 ¿Se puede implementar el sistema utilizando la tecnología

actual y dentro de las restricciones de coste y tiempo?

 ¿Puede integrarse el sistema con otros sistemas existentes en

la organización?

Se lleva a cabo un estudio de viabilidad y se obtiene información para

poder contestar las preguntas

7 . 2 Obtención y análisis de requerimientos

El término stakeholder se utiliza para referirse a cualquier persona o

grupo que se verá afectado por el sistema, directa o indirectamente.
Entre los stakeholders se encuentran los usuarios finales que
interactúan con el sistema y todos aquellos en la organización que se
pueden ver afectados por su instalación. Otros stakeholders del
sistema pueden ser los ingenieros que desarrollan o dan
mantenimiento a otros sistemas relacionados, los gerentes del
negocio, los expertos en el dominio del sistema y los representantes
de los trabajadores.
Obtener y comprender los requerimientos de los stakeholders es
difícil por :

 No conocen lo que desean obtener del sistema informático

excepto en términos muy generales

 expresan los requerimientos con sus propios términos de forma

natural y con un conocimiento implícito de su propio trabajo.

 tienen requerimientos distintos, que pueden expresar de varias

formas.

 Los factores políticos pueden influir en los requerimientos del

sistema.

 El entorno económico y de negocios en el que se lleva a cabo el

análisis es dinámico. Inevitablemente, cambia durante el
proceso de análisis.

Las actividades del proceso son:

 Descubrimiento de requerimientos.

 Clasificación y organización de requerimientos.

 Ordenación por prioridades y negociación de requerimientos.

 Documentación de requerimientos.
7.2.1 Descubrimiento de requerimientos

Es el proceso de recoger información sobre el sistema propuesto y los

existentes y extraer los requerimientos del usuario y del sistema de
esta información. Las fuentes de información durante la fase del
descubrimiento de requerimientos incluyen la documentación, los
stakeholders del sistema y la especificación de sistemas similares.

Puntos de vista:
Estas fuentes de requerimientos (stakeholders,
dominio, sistemas) se pueden representar como
puntos de vista del sistema, donde cada uno
presenta un subconjunto de requerimientos para el
sistema. Cada punto de vista proporciona una
perspectiva nueva en el sistema, pero éstas no son
completamente independientes. Por lo general
 coinciden parcialmente, por lo que tienen
requerimientos comunes.
Los puntos de vista se pueden utilizar como una forma de clasificar
los stakeholders y otras fuentes de requerimientos. Existen tres tipos
genéricos de puntos de vista:

 Puntos de vista de los interactuadores: representan a las

personas u otros sistemas que interactúan directamente con el
sistema.

 Puntos de vista indirectos: representan a los stakeholders que

no utilizan el sistema ellos mismos pero que influyen en los
requerimientos de algún modo.

 Puntos de vista del dominio: representan las características y

restricciones del dominio que influyen en los requerimientos del
sistema.

Entrevistas

Se puede hacer de dos formas :

Las entrevistas formales

Las entrevistas informales

Estas se desarrollan con los stakeholders del sistema ya que estos
son parte de la mayoría de los procesos de la ingeniería de
requerimientos.

Las entrevistas pueden ser de dos tipos:

1. Entrevistas cerradas donde los stakeholders responden a un

conjunto predefinido de preguntas.

2. Entrevistas abiertas donde no hay un programa predefinido. El

equipo de la ingeniería de requerimientos examina una seria de
cuestiones con los stakeholders del sistema y, por lo tanto,
desarrolla una mejor comprensión de sus necesidades

Es difícil obtener conocimiento del dominio durante las entrevistas

debido a dos razones:

 Todos los especialistas de la aplicación utilizan terminología y

jerga específica de un dominio.
 Cierto conocimiento del dominio es tan familiar para los
stakeholders que o lo encuentran difícil de explicar o piensan
que es tan básico que no merece la pena mencionarlo.

Los entrevistadores eficaces tienen dos características:

  No tienen prejuicios, evitan ideas preconcebidas sobre los
requerimientos y están dispuestos a escuchar a los
stakeholders.
 Incitan al entrevistado a empezar las discusiones con una
pregunta, una propuesta de requerimientos o sugiriendo
trabajar juntos en un prototipo del sistema.

Escenarios

Normalmente, las personas encuentran más fácil dar ejemplos de la

vida real que descripciones abstractas. Pueden comprender y criticar
un escenario de cómo podrían interactuar con un sistema software.

El escenario comienza con un esbozo de la interacción y, durante la

obtención, se agregan detalles para crear una descripción completa
de esta interacción. De forma general, un escenario puede incluir:

 Una descripción de lo que esperan el sistema y los usuarios

cuando el escenario comienza.

 Una descripción del flujo normal de eventos en el escenario.

 Una descripción de lo que puede ir mal y cómo manejarlo.

 Información de otras actividades que se podrían llevar a cabo al

mismo tiempo.

 Una descripción del estado del sistema cuando el escenario

termina.

Casos de uso
Los casos de uso son una técnica que se basa en escenarios para la
obtención de requerimientos que se introdujeron por primera vez en
el método Objetory.
Actualmente se han convertido en una característica fundamental de
la notación de UML, que se utiliza para describir modelos de sistemas
orientados a objetos. En su forma más simple, un caso de uso
identifica el tipo de interacción y los actores involucrados.
 7.2.2 Etnografía
Los sistemas software no existen de forma aislada: se utilizan en un
contexto social y organizacional y los requerimientos de sistemas
software se pueden derivar y restringir según ese contexto.

La etnografía es especialmente efectiva para descubrir dos tipos de

requerimientos:
  Los requerimientos que se derivan de la forma en la que la
gente trabaja realmente más que de la forma en la que las
definiciones de los procesos establecen que debería trabajar.

 Los requerimientos que se derivan de la cooperación y

conocimiento de las actividades de la gente.

7 . 3 Validación de requerimientos

Definen el sistema que el cliente desea. Coincide parcialmente con el

análisis ya que éste implica encontrar problemas con los
requerimientos. La validación de requerimientos es importante debido
a que los errores en el documento de requerimientos pueden conducir
a importantes costes al repetir el trabajo cuando son descubiertos
durante el desarrollo o después de que el sistema esté en uso.

Durante el proceso de validación de requerimientos, se deben llevar a

cabo verificaciones sobre requerimientos en el documento de
requerimientos. Estas verificaciones comprenden:

 Verificaciones de validez. Un usuario puede pensar que se

necesita un sistema para llevar a cabo ciertas funciones. Sin
embargo, el razonamiento y el análisis pueden identificar que
se requieren funciones adicionales o diferentes. Los sistemas
tienen diversos stakeholders con diferentes necesidades, y
cualquier conjunto de requerimientos es inevitablemente un
compromiso en el entorno del stakeholder.
 Verificaciones de consistencia. Los requerimientos en el
documento no deben contradecirse. Esto es, no debe haber
restricciones o descripciones contradictorias de la misma
función del sistema.
 Verificaciones de completitud. El documento de requerimientos
debe incluir requerimientos que definan todas las funciones y
restricciones propuestas por el usuario del sistema.
 Verificaciones de realismo. Utilizando el conocimiento de la
tecnología existente, los requerimientos deben verificarse para
asegurar que se pueden implementar. Estas verificaciones
también deben tener en cuenta el presupuesto y la confección
de agendas para el desarrollo del sistema.
 Verificabilidad. Para reducir la posibilidad de discusiones entre
el cliente y el contratista, los requerimientos del sistema
siempre deben redactarse de tal forma que sean verificables.
 Esto significa que debe poder escribir un conjunto de pruebas
que demuestren que el sistema a entregar cumple cada uno de
los requerimientos especificados.

Se pueden utilizarse en conjunto o de forma individual, varias

técnicas de validación de requerimientos:

 Revisiones de requerimientos.
 Construcción de prototipos.
 Generación de casos de prueba.

7.3.1 Revisiones de requerimientos

Es un proceso manual que involucra a personas tanto de la or-
ganización del cliente como de la del contratista. Ellos verifican el
documento de requerimientos en cuanto a anomalías y omisiones. El
proceso de revisión se puede gestionar de la misma forma que las
inspecciones de programas

Comprueba también:

 Verificabilidad. ¿Puede probarse el requerimiento de modo

realista?

 Comprensibilidad. ¿Las personas que adquieren el sistema o los

usuarios finales comprenden correctamente el requerimiento?
 Rastreabilidad. ¿Está claramente establecido el origen del
requerimiento? Puede tener que volver a la fuente del
requerimiento para evaluar el impacto del cambio. La
rastreabilidad es importante ya que permite evaluar el impacto
del cambio en el resto del sistema. Se trata esto con mayor
detalle en la siguiente sección.

 Adaptabilidad. ¿Es adaptable el requerimiento? Es decir, ¿puede

cambiarse el requerimiento sin causar efectos de gran escala
en los otros requerimientos del sistema?

7 . 4 Gestión de requerimientos
Los requerimientos para sistemas software grandes son siempre
cambiantes. Una razón es que estos sistemas normalmente se
desarrollan para abordar problemas.

Cuando los usuarios finales tienen experiencia con un sistema,

descubren nuevas necesidades y prioridades:
 Normalmente, los sistemas grandes tienen una comunidad de
usuarios diversa donde los usuarios tienen diferentes
requerimientos y prioridades. Éstos pueden contra decirse o
estar en conflicto.
  Las personas que pagan por el sistema y los usuarios de éste
raramente son la misma persona.

 El entorno de negocios y técnico del sistema cambia después

de la instalación, y estos cambios se deben reflejar en el
sistema.

7.4.1 Requerimientos duraderos y volátiles

La evolución de los requerimientos durante el proceso de ingeniería
de requerimientos y después de que un sistema esté en uso es
inevitable. El desarrollo de requerimientos software centra su
atención en las capacidades de éste, los objetivos del negocio y otros
sistemas de la organización.

Desde una perspectiva evolutiva, los requerimientos se dividen en

dos clases:
 Requerimientos duraderos. Son requerimientos relativamente
estables que se derivan de la actividad principal de la
organización y que están relacionados directamente con el
dominio del sistema.

 Requerimientos volátiles. Son requerimientos que

probablemente cambian durante el proceso de desarrollo del
sistema o después de que éste se haya puesto en funciona-
miento.

7.4.2 Planificación de la gestión de requerimientos

Es una primera etapa esencial del proceso de gestión de
requerimientos. La gestión de requerimientos tiene un coste elevado.
Para cada proyecto, la etapa de planificación establece el nivel de
detalle necesario en la gestión de requerimientos. Durante la etapa
de gestión de requerimientos se decidir sobre:
 La identificación de requerimientos.
 Un proceso de gestión del cambio.
 Políticas de rastreo.
 Ayuda de herramientas CASE.
 Existen tres tipos de información de rastreo que pueden ser
mantenidos:

La

1. Información de rastreo de la fuente vincula los

requerimientos con los stakeholders que propusieron los
requerimientos y la razón de éstos. Cuando se propone un
cambio, esta información se utiliza para encontrar y consultar a
los stakeholders sobre el cambio.

2. La información de rastreo de los requerimientos vincula los

requerimientos dependientes en el documento de
requerimientos. Esta información se utiliza para evaluar cómo
es probable que muchos requerimientos se vean afectados por
un cambio propuesto y la magnitud de los cambios
consecuentes en los requerimientos.
 3. La

información de rastreo del diseño vincula los requerimientos a

los módulos del diseño en los cuales son implementados. Esta
información se utiliza para evaluar el impacto de los cambios de
los requerimientos propuestos en el diseño e implementación
del sistema.

La gestión de requerimientos necesita ayuda automatizada; las

herramientas CASE para esto deben elegirse durante la fase de
planificación. Se precisan herramientas de ayuda para:
 Almacenar requerimientos. Los requerimientos deben
mantenerse en un almacén de datos seguro y administrado que
sea accesible a todos los que estén implicados en el proceso de
ingeniería de requerimientos.

 Gestionar el cambio. Este proceso se simplifica si está

disponible una herramienta de ayuda.

 Gestionar el rastreo. Como se indicó anteriormente, las

herramientas de ayuda para el rastreo permiten que se
descubran requerimientos relacionados. Algunas herramientas
utilizan técnicas de procesamiento del lenguaje natural para
ayudarle a descubrir posibles relaciones entre los
requerimientos.

Problemas identificados

Análisis del problema

y especificación del
cambio

Análisis del problema

Implementación del
y cálculo de
cambio costes
 Requerimientos revisados

7.4.3 Gestión del cambio de los requerimientos

La gestión del cambio de los requerimientos (Figura 7.13) se debe

aplicar a todos los cambios propuestos en los requerimientos. La
ventaja de utilizar un proceso formal para gestionar el cambio es que
todos los cambios propuestos son tratados de forma consistente y
que los cambios en el documento de requerimientos se hacen de
forma controlada.

Existen tres etapas principales en un proceso de gestión de cambio:

 Análisis del problema y especificación del cambio.

 Análisis del cambio y cálculo de costes.
 Implementación del cambio.