Resumen 97-113

Especificaciones Estructuradas

Son expresadas en lenguaje natural pero estructurado de tal manera que la libertad de
escribir se halla limitada para evitar ambigüedades. En el lenguaje estructurado se
emplean plantillas o tarjetas. En este método se emplea sombreado o fuentes distintas
para resaltar procesos importantes.

Ilustración 1 Ejemplo de plantilla o forma estándar

Las tarjetas o formas estándar deben:

1. Dar una descripción de la función o entidad a especificar

2. Dar una descripción de las entradas y procedencias.
3. Dar una descripción de las salidas y a donde se dirigen.
4. Requerimientos adicionales como por ejemplo de otras entidades del sistema o
datos que se necesiten para hacer cálculos.
5. Describir las acciones a tomar.
6. Si es de enfoque funcional debe tener pre-condiciones y post-condiciones antes
y después de llamar a la función para establecer que es verdadero.
7. Describir los efectos colaterales de las operaciones si es que existen.

Las especificaciones estructuradas ayudan a disminuir la variabilidad de las

especificaciones (ambigüedad) y permite una mejor organización y más efectiva, para
reducir aún más las ambigüedades puede usarse modelos gráficos o de relaciones
matemáticas.

Proceso de ingeniería de requerimientos

Incluye 4 etapas:
1. Estudio de factibilidad (ver si es útil para la empresa)
2. Definir requerimientos.
3. Especificar requerimientos (en forma estándar)
4. Validación (ver si es lo que el cliente quiere)

Para la elaboración de un proyecto pueden utilizarse diagramas de espiral iterativos que

muestran de acuerdo al numero de iteraciones como los requerimientos se van
obteniendo en un proceso de fases entrelazadas y con mayores niveles de detalle.

También se pueden elaborar modelos gráficos que muestren el comportamiento y

funcionamiento del sistema. Si bien los modelos gráficos que se pueden realizar sirven
para un análisis estructurado de la ingeniería de requerimientos, hay partes instancias en
la adquisición de requerimientos donde se tiene que tratar con personas, y a la gente no
le suele gustar las imposiciones de los modelos gráficos ya que generalmente las
personas suelen cambiar su percepción y entendimiento de los requerimientos a medida
que se desarrolla el proceso.

Adquisición y análisis de requerimientos

Proceso posterior al análisis inicial de factibilidad, donde ingenieros de Software

conversan con clientes para entender que necesidades tienen ellos respecto al sistema,
como esperan que funcione y que restricciones de Hardware tienen.

Actividades dentro de adquisición y análisis de requerimientos:

1. Descubrimiento de requerimientos: Interacción con los participantes del sistema

para descubrir los requerimientos.
2. Clasificación y organización de requerimientos: Recopila requerimientos de
forma no estructurada y los agrupa de forma coherente, los organiza de acuerdo
al método de arquitectura de sistemas para identificar grupos y subgrupos.
3. Priorización y negociación de requerimientos: Cuando hay varios involucrados
habrán conflictos entre los requerimientos, de los cuales se debe hacer una
clasificación basada en prioridades y se debe llegar a acuerdos mediante la
negociación.
4. Especificación de requerimientos: Los requerimientos se documentan e ingresan
al espiral.

Razones que hacen difícil el proceso de adquisición y comprensión de

requerimientos

1. Los participantes no saben lo que quieren de un software en términos más allá de

los generales.
2. Los participantes explican los requerimientos en lenguaje natural y en base a su
área de conocimientos de su trabajo, un ingeniero en software que no conozca
acerca de tales áreas de conocimiento podría malinterpretar las necesidades de
los clientes.
3. Diferentes personas pueden describir un mismo requerimiento de varias formas,
por ello deben interpretarse las similitudes y conflictos.
4. La política de la organización influye en el sistema, ya que la gente de altos
rangos puede tener requerimientos que eleven su influencia y control en la
organización.
5. Debido a que el ambiente económico y empresarial es muy variable los
requerimientos pueden evolucionar con el tiempo.

Descubrimiento de requerimientos o adquisición de requerimientos

Proceso que consiste en recopilar información acerca del sistema y de sistemas

existentes, así como requerimientos de los usuarios y dominios del sistema. Las fuentes
de información para esto pueden ser los participantes, documentos, o requerimientos
similares de otros sistemas.
Métodos para interactuar con participantes

Entrevistas

Las entrevistas, ya sean formales o informales, tienen el objetivo de hacer preguntas a

los participantes acerca de cómo es el sistema actual que manejan y como esperan que
sea el sistema en desarrollo. Las entrevistas pueden ser de 2 tipos:

Entrevistas cerradas: Donde los participantes responden a un conjunto de preguntas

preestablecidas.

Entrevistas abiertas: No existen preguntas prediseñadas y mediante la interacción los

programadores pueden ver los conflictos de los participantes de mejor manera y
desarrollar una mejor comprensión del sistema.

Inconvenientes de las entrevistas para requerimientos de dominio

1. Generalmente se utiliza mucha terminología específica del domino que los

ingenieros de requerimientos pueden no entender, y al explicar esta terminología
en palabras más simples se los ingenieros pueden malinterpretar debido a la
ambigüedad de la explicación.
2. Para los participantes a veces existen pasos del proceso tan básicos que muchas
veces olvidan mencionarlos o simplemente no saben como explicarlos porque
los dan por entendidos.

Otro inconveniente de las entrevistas es que a veces las personas no quieren revelar
a extraños las relaciones de toma de decisiones de la organización que muchas veces
son diferentes a lo que en teoría se expresa en el organigrama.

Características del entrevistador efectivo

1. Tienen mentalidad abierta y escuchan a los participantes más allá de sus propios
pre-conceptos.
2. Evita hablar en términos generales y lleva al conversación a contextos definidos
para hallar de mejor manera los requerimientos y ser más específico.

Escenarios

Son una técnica muy útil porque permite a los participantes desarrollar una dinámica
con ejemplos reales que permite que fluya de mejor manera la búsqueda y
entendimiento de los requerimientos. Los escenarios son bosquejos de las situaciones
reales y suelen tener las siguientes características:

1. Descripción de lo que se espera al iniciar el sistema.

2. Descripción del flujo normal de los eventos.
3. Descripción de lo que puede salir mal y como controlarlo .
4. Información de actividades que se den en paralelo (al mismo tiempo).
5. Descripción del sistema cuando termina el escenario.
Ejemplo de escenario:

Casos de Uso

Identifica a los actores de una interacción y nombra a la interacción, además añade

información adicional de las interacciones. En el diagrama de caso de uso se representan
de manera gráfica todos los actores del sistema que pueden ser usuarios u otros
sistemas, las interacciones se representan con elipses y las líneas rectas muestran como
se relacionan entre sí.
Etnografía

La etnografía se utiliza para analizar el contexto organizacional en el que se desarrollará

el sistema. Para el desarrollo de un sistema es crítico conocer como se dan las relaciones
entre los participantes y usuarios, la situación política de la empresa, entre otros factores
de la organización.

La etnografía es especialmente útil para descubrir 2 tipos de requerimientos:

1. Requerimientos derivados de la forma en que realmente trabaja la gente y no

según lo que dicen los manuales, por ejemplo en algunos casos emergentes la
gente puede saltarse pasos del sistema para solucionar un problema.
2. Requerimientos derivados de la cooperación con otros usuarios o actores del
sistema. Cuando un usuario puede usar datos de otro para definir como trabajará
o que estrategia puede utilizar.

La etnografía es crucial para el desarrollo de prototipos porque puede reducir el número

de procesos de refinamiento del producto. La etnografía se enfoca en el usuario final,
por lo que puede descubrir requerimientos críticos a este nivel pero no puede ser muy
bueno cuando se trata de requerimientos macro o de dominio (nivel de organización y
no de usuario final)

Validación de requerimientos

La validación se encarga principalmente de asegurarse que los requerimientos del

sistema representen realmente lo que los clientes quieren y necesitan del mismo.
Durante la validación deben hacerse diferentes comprobaciones.

1. Comprobación de validez: Generalmente puede creerse que se necesitan ciertas

funciones de un sistema pero con el tiempo puede resultar que se necesitan
funciones adicionales y no previstas.
2. Comprobaciones de consistencia: No debe existir conflicto entre los
requerimientos del sistema.
3. Comprobaciones de totalidad: Se debe comprobar que los requerimientos
cumplan con todas las funciones que necesita y espera el cliente o usuario.
4. Comprobaciones de realismo: Se debe comprobar que los requerimientos puedan
de verdad implementarse en base a las condiciones actuales de tecnología y
presupuesto.
5. Verificabilidad: Para que no existan problemas entre el proveedor y el cliente,
los requisitos deben registrarse de manera que puedan ser verificables, es decir
deben poder realizarse pruebas que muestren que el sistema cumple con todos
los requisitos necesarios.

Técnicas de validación

1. Revisiones de requerimientos: Se utiliza un equipo de revisores que se encargan

de encontrar errores e inconsistencias.
2. Creación de prototipos: Se valida por medio de versiones ejecutables del
sistema.
 3. Casos de prueba: se realizan casos de prueba y si una prueba es muy difícil de
realizar entonces se reconsidera su implementación antes de escribir los códigos.

Administración de requerimientos

Una vez que ya se implementa el sistema es inevitable que con el paso del tiempo y a
mayor uso que le den los usuarios y participantes al sistema surjan nuevas necesidades
de requerimientos, las cuales tendrán que ser implementadas. Para evitar esto al máximo
posible, durante el desarrollo los participantes deben tratar de anticipar los efectos que
tendrá en su empresa y su gestión el nuevo sistema.

Existen 3 razones por las que es inevitable el cambio en los sistemas:

1. Las prioridades de la empresa pueden cambiar, así como sus necesidades y la

tecnología y hardware que utilizan.
2. Muchas veces lo que ordenan quienes pagan por el sistema no representa por
completo las necesidades del usuario final, que necesitará implementaciones
que mejoren su interacción con el sistema.
3. Muchas veces en organizaciones grandes pueden darse contradicciones entre
requerimientos de diferentes usuarios y a veces el equilibrio de apoyo a ciertos
usuarios tiene que cambiarse.