•

•
•

•
Elemento Significado
<determinante> Es el determinante para cada sujeto, por ejemplo: Una, Uno, El,
La, Cada, Todos.
<sujeto> Es una entidad reconocible del negocio, tal como objetos, un
nombre de Rol o una propiedad de un objeto. La entidad puede
ser cualificada por otros elementos descriptores, tales como la
existencia en un estado particular, relacionada con una
aplicabilidad específica de la regla.
<característica> El comportamiento del negocio a tomar lugar o interrelación que
debe ser establecida.
<hecho> Interrelación entre términos identificables en el modelo de
hechos. Esta puede ser cualificada por otro elemento descriptor
relativo a identificar la aplicabilidad de la regla precisada.
<lista de hechos> Una lista de <hechos> elementos
Elemento Significado
<determinante> Es el determinante para cada sujeto, por ejemplo: Una,
Uno, El, La, Cada, Todos. Según el mejor sentido en la
redacción.
<sujeto> Es un elemento de la Base de Datos del negocio, tal como
entidades y objetos. La entidad puede ser cualificada por
otros atributos descriptores, tales como la existencia
en un estado particular o relacionada con una aplicación
específica de la regla.

<características> Describe las características del sujeto en el negocio, tanto

internas como relacionadas con otras entidades.
<hechos> Hechos relativos al estado o comportamiento de la Base
de Datos del negocio, incluyendo o no al sujeto.
Elemento Significado
<m>,<n> Son parámetros numéricos.
<resultado> Cualquier valor, no necesariamente numérico, que tiene algún
significado en el negocio. El resultado es usualmente el valor
del atributo de un objeto del negocio.
<algoritmo> Definición de una técnica usada para obtener el valor de un
resultado; normalmente expresada utilizando combinaciones
de términos del negocio junto a constantes disponibles.
<clasificacion> Definición de un término del negocio. Típicamente define el
valor de un atributo, quizás llamado “estado” o algo similar, o
un subconjunto de objetos en una clase existente.
<lista Definición de un término del negocio. Típicamente define el
enumerada> valor de un atributo, quizás llamado “estado” o algo similar, o
un subconjunto de objetos en una clase existente.
 Análisis y determinación de requerimientos
¿Que es la determinación de requerimientos?

¿Que es un requerimiento?
1. Es una característica que debe incluirse en un nuevo sistema.

2. Puede ser la inclusión de determinada forma para capturar o procesar datos,

producir información, controlar una actividad de la empresa o brindar soporte
a la gerencia.
 Actividades en la determinación de requerimientos

Esta compuesta de tres grandes actividades que son: Anticipación, investigación

y especificación de requerimientos.

Actividad Descripción

Anticipación de requerimientos Prever las características del sistema con

Investigación de requerimientos
Especificación de requerimientos
base en la experiencia previa. Esto puede
llevar al analista a investigar áreas y
aspectos que de otra forma no serán
tomados en cuenta.
Estudio y documentación del sistema
actual utilizando para ello técnicas para
hallar hechos como son: El análisis de
flujo de datos y análisis de decisión.
Análisis de los datos que describen el
sistema para determinar que tan bueno es
su desempeño, que requerimientos se
deben satisfacer y las estrategias para
alcanzarlos.
 Técnicas para encontrar hechos

Entrevistas :
1. Se emplean para reunir información proveniente de personas o de
grupos. Por lo común, los entrevistados son usuarios de los sistemas
existentes o usuarios en potencia del sistema propuesto.

2. En algunos casos, los entrevistados son gerentes o empleados que

proporcionan datos para el sistema propuesto o que serán afectados por
él.

3. Las entrevistas dan a los analistas oportunidades para reunir información

de las personas que han seleccionado debido a sus conocimientos del
sistema que está bajo estudio.
Entrevistas (Continuación)

Entrevistas estructuradas:
1. Utilizan preguntas estándar en un formato de respuesta abierta o
cerrada. El primero permite que el entrevistado de respuesta a las
preguntas con sus propias palabras; el segundo utiliza un conjunto
anticipado de respuestas.

Entrevistas no estructuradas:
1. Utilizan un formato pregunta-respuesta y son apropiadas cuando el
analista desea adquirir información general acerca de un sistema. Este
formato anima a los entrevistados a compartir sus sentimientos, ideas y
creencias.
Cuestionarios :

Revisión de los registros :

1. Varios tipos de registros y reportes pueden proporcionar al analista
información valiosa con respecto a las organizaciones y a sus
operaciones. Al revisar los registros, el analista examina la información
asentada en ellos relacionada con el sistema y los usuarios.
Observación :
 Ayuda a los ingenieros de software a entender mejor
el problema en cuya solución trabajarán.
 ¿Por qué es importante? Se debe entender lo que el
cliente quiere antes de comenzar a diseñar y construir
un sistema.
 Toma en cuenta errores, coste y tiempo.
 La IR trata de los principios, métodos, técnicas y
herramientas que permiten descubrir, documentar y
mantener los requisitos, de forma sistemática y
repetible.

Ingeniería de requisitos 112

 El objetivo del proceso de la ingeniería de requisitos es
darle a todas las partes una explicación escrita del
problema.
 Es esencial que se haga un esfuerzo real por entender
los requisitos de un problema antes de intentar
resolverlo.

113
 Funcionales
◦ Describen los servicios que se esperan del sistema.
 No funcionales
◦ Restricciones sobre los requisitos funcionales
◦ Existen dos tipos:

ORIENTADOS AL USUARIO ORIENTADOS AL DESARROLLADOR

Fiabilidad Disponibilidad
Seguridad Portabilidad
Usabilidad Adaptabilidad
Robustez Testabilidad
Rendimiento, etc Comprensibilidad
 Proporciona el mecanismo adecuado para entender lo
que el cliente quiere.

 Fases de la IR:
 Se inicia muchas veces por:
◦ Identifica nueva necesidad de negocios.
◦ Se descubre un nuevo mercado.
◦ Se descubre un nuevo servicio.

Ingeniería de requisitos 116

 La obtención de información no es tan fácil como
parece. Los ingenieros deben realizar en forma
organizada la actividad de recopilación de requisitos.

DE ÁMBITO DE COMPRENSIÓN DE VOLATILIDAD

El cliente no está seguro
Limite del sistema Los problemas cambian
100% de que es lo que
mal definido con el tiempo.
necesita
Tienen dificultades para
Detalles técnicos
comunicar sus necesidades,
innecesarios, etc.
etc.
 Objetivo: Desarrollar modelo técnico refinado de las
funciones, características y restricciones del software.
 Se conduce mediante la creación y refinamiento de
escenarios.
 El resultado final es un modelo de análisis que define:
◦ El dominio de la información.
◦ Funciones.
◦ Comportamiento del problema.

Ingeniería de requisitos 118

 Clientes, usuarios y otros interesados deben ordenar
sus requisitos y luego discutir los conflictos
relacionados con la prioridad.
 Hacer estimaciones preliminares del esfuerzo
requerido para su desarrollo.
 Mediante un enfoque iterativo los requisitos se
elimina, combinan o modifican.

Ingeniería de requisitos 119

 Puede ser:
Documento escrito
Conjunto de modelos gráficos
Modelo matemático formal
Escenarios de uso
Prototipo
Una combinación de estos.

Se recomienda que: SISTEMAS GRANDES SISTEMAS PEQUEÑOS

Documentos escritos Escenarios de uso

La especificación es el trabajo final que genera la IR.

 Examina la especificación para asegurar que los
requisitos de software se han establecido de manera
precisa.

ALGUNAS PREGUNTAS RECOMENDADAS PARA VALIDAR

¿La fuente del requisito está identificado?

¿Cuáles otros requisitos están relacionados con éste?

¿El requisito viola alguna restricción del dominio del sistema?

¿El requisito se puede probar? ¿Se pueden especificar las pruebas?, etc.

Ingeniería de requisitos 121

 Es el conjunto de actividades que ayuda al equipo del
proyecto a identificar, controlar, rastrear los requisitos como
también los cambios a éstos en el desarrollo del proyecto.
 Para esto se desarrollan las siguientes tablas:
 La gestión formal se inicia solo para proyectos grandes

TABLAS
De rastreabilidad de las características.
De rastreabilidad de la fuente.
De rastreabilidad del subsistema.
De rastreabilidad de la interfaz.

12
Ingeniería de requisitos 2
 Identificación de los interesados.
◦ Todos aquellos que se benefician en una forma directa o indirecta
del sistema.
 Reconocimiento de múltiples puntos de vista.
◦ Categorizar la información de los interesados de manera que
permita elegir un conjunto de requisitos para el sistema que sean
consistentes de manera interna.
 Trabajo con respecto a la colaboración.
◦ Identificar áreas en común y áreas inconsistentes.
 Formulación de las primeras preguntas
◦ Las preguntas deben ser ‘libres de contexto’.
¿Quién usará la solución?
¿Cuál será el beneficio económico de una solución exitosa?

Ingeniería de requisitos 123

 Recopilación conjunta de requisitos
◦ La meta es identificar el problema, proponer elementos de
solución, negociar diferentes enfoques y especificar un
conjunto de requisitos preliminares.

12
Ingeniería de requisitos 4
 Es una técnica que traduce las necesidades del cliente
en requisitos técnicos para el software.
 QFD define los requisitos para maximizar la
satisfacción del cliente.
 QFD identifica 3 tipos de requisitos.

NORMALES ESPERADOS ESTIMULANTES

Objetivos y metas
Características que van más
establecidos para un sistema Están implícitos en el
allá de las expectativas del
durante las reuniones con el producto o sistema.
cliente.
cliente.

Ingeniería de requisitos 125

 Se aplica para determinar el valor de cada función que
se requiere para el sistema.
 El despliegue de la información identifica los datos de
los objetos y eventos que debe consumir y producir el
sistema.
 El despliegue de tareas examina el comportamiento
del sistema o producto dentro del contexto de su
entorno.

12
Ingeniería de requisitos 6
 Escenarios del usuario.
◦ Proporcionan una descripción de cómo se usará el sistema.
 Productos de trabajo de obtención.
◦ Los productos producidos como consecuencia de la
obtención de requisitos variará de acuerdo con el tamaño del
sistema a construir.

Ingeniería de requisitos 127

 Un caso de uso muestra el software o sistema desde el
punto de vista del usuario final.
 Los actores son las diferentes personas que utilizan el
sistema dentro del contexto de la función y el
comportamiento que se describirá.
 Un actor es algún elemento que se comunica con el
sistema y que es externo al sistema.
PRIMARIOS SECUNDARIOS

Interactúan para lograr la función

Dan soporte al sistema.
requerida del sistema

12
Ingeniería de requisitos 8
 12
Ingeniería de requisitos 9
 El objetivo del modelo de análisis radica en describir
requeridos de información, funcionamiento y
comportamiento para un sistema basado en
computadoras.
 Es una representación de los requisitos en un
momento determinado.
 Los elementos del modelo los determina el método de
modelado que se utilice.

Ingeniería de requisitos 130

 Elementos basados en escenarios
◦ Sirven como una entrada para la creación de otros elementos
de modelado.
 Elementos basados en clases.
◦ Conjuntos de objetos que se manipula mientras un actor
interactúa con el sistema.

Ingeniería de requisitos 131

 Elementos de comportamiento.
◦ El comportamiento de un sistema puede tener efecto sobre el
diseño que se elija.
◦ Un estado es cualquier forma de comportamiento
observable.
◦ Las variables de estado indican la manera en que el estado se
manifiesta.

Ingeniería de requisitos 132

 Elementos orientados al flujo.
◦ La información se transforma mientras fluye a través de un
sistema.
◦ Es posible crear un modelo de flujo para un sistema sin que
importe su complejidad.

Ingeniería de requisitos 133

 Representan algo dentro del dominio de aplicación
que puede reutilizarse al modelar muchas
aplicaciones.
 Se pueden encontrar en casi cualquier actividad de la
vida diaria.
PLANTILLA
Nombre del patrón
Intención
Motivación
Fuerzas y contexto
Solución
Consecuencias
Diseño
Usos conocidos
Patrones relacionados
  El objetivo es desarrollar un plan proyecto que
satisfaga las necesidades del cliente.
ACTIVIDADES A CONSIDERAR DIRECTRICES A CONSIDERAR
Reconocer que no es una competencia
Identificación de los interesados clave en el sistema o
subsistema.
Decidir que es lo que se desearía lograr
Determinación de las condiciones 'ganadoras' de los
No se debe pensar en formular una respuesta
interresados.
mientras la otra parte está hablando

Negociación de las condiciones ganadoras para Enfocarse en los intereses de la otra parte
unirlas en un conjunto de condiciones del tipo ganar -
ganar para todos los involucrados.
No dejar que se vuelva personal

Ser creativo

Estar listo para pactar.

Ingeniería de requisitos 135

 Los modelos de análisis se examinan para conocer que
consistencia, omisiones o ambigüedades portan.
 Cada requisito y modelo de análisis se validan como
un todo contrastándolos con las necesidades del
cliente para asegurar que se construirá el sistema
correcto.
ASPÉCTOS DE LA VALIDACIÓN
Válidez
Consistencia
Completitud
Realismo
 “Ingeniería de software: un enfoque práctico” Roger
Pressman, VI edición, McGrawHill.

 www.gris.det.uvigo.es/~jose/doctorado/re/

 www.lsi.us.es/docs/informes/LSI-2002-4.pdf

Ingeniería de requisitos 137