ingenieria de requerimientos

1. INGENIERÍA DE
REQUERIMIENTOS
2ª- PARTE
NOTAS DEL CURSO:
C121 INGENIERIA DE SOFTWARE I
DRA. MARIA DEL PILAR GÓMEZ GIL
OTOÑO 2012
Versión: 15 Oct.- 2012

2. Mas sobre documentación de
Requerimientos [Wiegers 2003]
 Los requerimientos funcionales y no
funcionales del producto de software a
fabricarse se encuentran en un
documento conocido como SRS
(software requirements specification).

3. Quienes usan el SRS? [Wiegers
2003]
 Clientes – Para ver que tipo de producto
les será entregado
 Administradores del proyecto – para
realizar sus estimaciones
 Desarrolladores, equipo de
mantenimiento – para saber que deben
construir
 Probadores – para hacer planes,
procedimientos y casos de prueba
 Capacitores, staff del area legal, sub-
contratadores, documentitstas etc.

4. Baselining
 Proceso de transformar un SRS en
desarrollo, a uno que ha sido revisado
y aprobado
 Es importante que todo el equipo
trabaje con el mismo conjunto de
requerimientos

5. Sugerencias para escribir
requerimientos (1/3)
 Etiquete secciones, subsecciones y
requerimientos individuales de forma
consistente
 No justifique “a la derecha”
 Deje suficientes espacios en blanco
 Enfatice las palabras clave usando
“negritas”, “italica” o fonts diferentes,
de manera consistente y sensata.

6. Sugerencias para escribir
requerimientos (2/3)
 Genere una tabla de contenido e
indices para facilitar el encontrar
información
 Numere todas las figura y las tablas,
pongales título (o encabezado en
caso de figuras) y haga referencia a
éstas con un número

7. Sugerencias para escribir
requerimientos (3/3)
 Cuando haga referencia a alguna
sección dentro del documento, utilice
las facilidades de “referencias
cruzadas” y numeración automática
del procesador de palabras, en vez de
teclear directamente los números
 Use hiper-ligas para permitir al lector
saltar a una sección, o a otro
documento.
 Use una plantilla para organizar toda

8. Identificación de los
requerimientos
 Todo requerimiento debe estar
identificado de manera única y
persistente, a fin de facilitar su
seguimiento (traceatbility), modificación
y re-uso en otros proyectos
 Estrategias de identificación
◦ Número secuencias único y no re-usable
◦ Numeración jerárquica
◦ Numeración jerárquica usando texto
 Para textos no definidos, se usa la
etiqueta TBD (to be determined)

9. Plantilla propuesta por Wiegers
(2003)

10. Guías para escribir
requerimientos
 Ver [Wiegers 2003]

11. Diccionario de datos
 Usados para definir los flujos de información
 Basados en los BNF’s (Bakus Naus forms)
 Muy útiles para definir información
 Símbolos usados:
◦ + composición (AND)
◦ 1 separación componente alternativo (OR)
◦ { } repetición
◦ [] agrupación de componente alternativo o
primitivas
posibles
◦ ( ) componente opcional
◦ x { } y x:y{} iteración desde x hasta y
(x, y opcionales)
◦ * Inicio y fin de comentarios

12. Diccionario de datos (2/2)
 Escribirlos en una tabla, en orden
alfabético, identificando el elemento
“raiz”
 Definir tanto como sea necesario para
entender el significado del flujo de
dato.
 Ejemplo

13. Proceso Unificado
[Jacobson et al., 2000]

14. Actividad de Análisis
 La especificación de requerimientos
tiene que estar escrita de tal manera
que sea entendida por los usuarios,
sin ser demasiado técnica, pero al a
vez sea suficientemente clara,
completa y detallada para los
diseñadores

15. Estrategia de Solución
 La especificación contiene una
estrategia de solución, escrita por el
equipo de software
 Varias estrategias de solución pueden
ser analizadas y descartadas.
 Es importante registrar el porque una
estrategia es rechazada. Esta
información servirá para aclaraciones
futuras y para evitar que decisiones
no adecuadas se repitan en el futuro

16. Objetivos de la actividad de
análisis en el Proceso Unificado
 Desde el punto de vista de la actividad
de requerimientos, el objetivo es
entender mas profundamente los
requerimientos
 Desde el punto de vista de la actividad
de diseño e implementación, el
objetivo es describir los
requerimientos de tal manera que el
diseño e implementación resultante
sean fáciles de mantener

17. El camino puede ser
definir clases y
objetos involucrados
en el sistema….
El conjunto de clases en un sistema y sus
relaciones definen lo que se conoce como el
Modelo del Sistema

18. Recordando…
Objeto:
Cualquier cosa, real o abstracta, que es descrito
por un conjunto de atributos y será manipulado
dentro del software a través de métodos.

19. Características importantes
 Cada instancia de un objeto (ejemplo
un libro) puede ser identificada
(ejemplo # ISBN) de manera única.
 Cada objeto desempeña una función
necesaria en el sistema; el sistema no
podría funcionar sin el acceso a las
instancias del objeto
 Cada objeto es descrito por atributos.

20. Objeto de Datos y Atributos
Un objeto de datos contiene un conjunto de atributos que determinan
aspectos, cualidades, características o descripciones de éste
Objeto: automóvil
Atributos:
marca
modelo
tipo de carrocería
precio
opciones de código

21. Otros Conceptos Básicos sobre Objetos
 TIPO DE OBJETO: Es una categoría de objeto. Un
objeto es una instancia de un tipo de objeto.
 ATRIBUTOS: Características que definen a un
objeto.
 MÉTODOS: Especificación de la forma en que se
controlan los datos de un objeto.
 ENCAPSULADO: Es el empaque de datos y
métodos, resultado de ocultar los detalles de
implantación de un objeto respecto de su usuario.

22. Conceptos Básicos (continuación...)
• MENSAJE: Es una solicitud para que se lleve a cabo una
operación. Puede utilizar uno o más objetos como parámetros
• CLASE: Es una implantación en software de un tipo de objeto.
Especifica una estructura de datos y los métodos operativos
permisibles que se aplican a cada uno de sus objetos.
• HERENCIA: Las instancias heredan las características de las
clases a las que pertenecen. Las clases heredan características
de las super-clases, etc.

23. Pasos Para Encontrar
Objetos
 La mayoría de las metodologías
orientadas a objetos tienen un conjunto
básico de actividades para definir objetos,
las cuales incluyen:
1. Identificación de objetos
2. Identificación de Atributos
3. Definición de operaciones
4. Comunicación entre objetos
5. Integración final de la definición.

24. Paso 1. Identificación de
Objetos
 Se puede empezar con la identificación de
objetos haciendo una revisión de tipo gramatical
sobre los componentes narrativos de la
especificación de requerimientos.
 Los objetos pueden ser los sustantivos o cláusula
 sustantivas de la narrativa.
 Los objetos pueden manifestarse en alguna de
las siguientes formas:

25. Formas de Objetos
1. Entidades Externas que producen o
consumen información a utilizarse por un
sistema basado en computadora. (ejemplo:
otros sistemas, dispositivos, personas.)
2. Cosas que son parte del dominio de
información para el problema (ejemplo:
reportes, despliegues, letras, señales).
3. Ocurrencias o eventos que ocurren dentro
del contexto de operación del sistema
(ejemplo: transferencia de propiedad, la
terminación de una serie de movimientos de
un robot
continúa…

26. Formas de Objetos (continuación...)
4. Unidades organizacionales que son
relevantes a una aplicación (ejemplo:
división, grupo)
5. Lugares que establecen el contexto
del problema y la función general del
sistema. (ejemplo piso de
manufactura o andén de carga)
6. Estructuras que definen una clase
de objetos o clases de objetos
relacionados

27. Selección de Objetos
Para que un objeto se incluya en el modelo del
sistema debe satisfacer todas (o casi todas) las
siguientes características:
1. Información retenida. El objeto potencial será útil
durante el análisis solo si debe recordarse
información acerca de él para que el sistema
pueda funcionar.
2. Servicios Requeridos. El objeto potencial debe
tener una serie de operaciones identificables que
puedan cambiar el valor de sus atributos
3. Atributos múltiples. Un objeto con un solo atributo
tal vez no sea muy útil como objeto, sino que
probablemente será mejor representarlo como
atributo de otro objeto.

28. Selección de Objetos
(continuación...)
4. Atributos Comunes. Se puede definir un conjunto
de atributos para el objeto potencial, y éstos se
aplican a todas las ocurrencias del objeto.
5. Operaciones comunes. Se puede definir un
conjunto de operaciones para el objeto potencial,
y estas se aplican a todas las ocurrencias del
objeto.
6. Requerimientos esenciales. Las entidades
externas al sistema que producen o consumen
información esencial en su solución,
generalmente se definen como objetos.

29. Un ejemplo de Identificación de Objetos
NARRATIVA:
El software CasaSegura permite que el dueño de la casa
configure el
sistema de seguridad una vez que éste se ha instalado.
Además, el software permite monitorear todos los sensores
conectados al sistema de seguridad e interactuar con el dueño
de la
casa a través de un panel de control.
Durante la instalación, el panel de control de CasaSegura se
utiliza
para programar y configurar el sistema. Cada sensor tiene
asignado
un número y tipo; se programa una contraseña maestra para
conectar y desconectar el sistema, y se proporciona un número
telefónico que se marcará cuando algún evento sensado
ocurra.

30. Narrativa (continuación...)
Cuando un evento es percibido por el software, éste hace sonar
una
alarma audible conectada al sistema. Después de un tiempo de
espera que es especificado por el dueño durante la
configuración del
sistema, el software marca un número de teléfono de un
servicio de
monitoreo, dando información acerca de la localización, y
reporta la
naturaleza del evento que se ha detectado. El número se
marcará
cada 20 segundos, hasta que la conexión telefónica se
obtenga.
Toda interacción con Casa Segura se maneja a través de un
subsistema de interacción con el usuario que lee entradas a
través
del teclado y despliega mensajes e información del estatus en
la

31. Objetos Potenciales del Ejemplo
OBJETO / CLASE
POTENCIALIDAD
CLASIFICACIÓN
GENERAL
ACEPTADO /
RECHAZADO
CARACTERÍSTICAS
ASOCIADAS
Dueño de la casa Entidad externa Rechazado 1 y 2 no se aplican,
aunque 6 sí
Sensor Entidad externa Aceptado Todos se aplican
Panel de control Entidad externa Aceptado Todos se aplican
Instalación Ocurrencia Rechazado
Sistema Cosa Aceptado Todos se aplican
Número y tipo No son objetos sino
atributos
Rechazado 3 no se aplica
Contraseña Maestra Cosa Rechazado 3 no se aplica
Número de teléfono Cosa Rechazado 3 no se aplica
Evento Percibido Ocurrencia Aceptado Todos se aplican
Alarma Audible Entidad externa Aceptado 2, 3, 4, 5, 6, se
aplican
Servicio de Monitoreo Entidad externa
(unidad
organizacional)
Rechazado 1 y 2 no se aplican,
aunque 6 sí se aplica

32. Objetos Identificados en el
ejemplo
SISTEMA
PANEL DE
CONTROL
SENSOR
EVENTO
PERCIBIDO
ALARMA
AUDIBLE

33. Pasos Para Encontrar
Objetos
 La mayoría de las metodologías
orientadas a objetos tienen un conjunto
básico de actividades para definir objetos,
las cuales incluyen:
1. Identificación de objetos
2. Identificación de Atributos
3. Definición de operaciones
4. Comunicación entre objetos
5. Integración final de la definición.

34. Paso 2: Identificación de atributos
 Los atributos son en esencia los que definen al objeto
clasificado según su significado en el contexto del sistema.
 Un objeto puede tener diferentes atributos dependiendo del
sistema en que esté siendo utilizado.
 Para determinar atributos, contestar la pregunta: “Qué
elementos de datos (compuestos o elementales) definen
completamente este objeto en el contexto del sistema?”
SENSOR
tipo
numero de sensor
limite respuesta
Ejemplo:

35. Paso 3. Definición de Operaciones
 Una operación cambia los valores de uno o
más atributos de un objeto. Una operación
debe tener conocimiento de los atributos
del objeto.
 Hay tres tipos de operaciones:
◦ Las que manipulan datos (añadir, borrar, dar
forma)
◦ Las que realizan cálculos
◦ Las que monitorean un objeto para determinar la
ocurrencia del evento

36. Definición de Operaciones (continuación)
 Para encontrar las operaciones de un objeto, se
puede realizar una revisión sobre la narrativa del
sistema, buscando los verbos.
 También se pueden identificar operaciones
analizando la comunicación que existe entre
objetos.
 Ejemplo:
“... Cada sensor tiene asignado un número y un tipo; se
programa una contraseña maestra_para conectar y
desconectar el sistema,...”
Se identifican las operaciones:
Asignar_número()
Programar_contraseña()

37. Pasos Para Encontrar
Objetos
 La mayoría de las metodologías
orientadas a objetos tienen un conjunto
básico de actividades para definir objetos,
las cuales incluyen:
1. Identificación de objetos
2. Identificación de Atributos
3. Definición de operaciones
4. Comunicación entre objetos
5. Integración final de la definición.

38. Paso 4: Comunicación entre
Objetos
 Para construir el sistema es necesario
definir un mecanismo de comunicación
entre objetos.
 Los mensajes tienen la forma:
mensaje: (destino, operación, argumentos)
 Los mensajes son importantes en la
implementación del sistema, pero no se
requiere considerarlos a detalle durante el
análisis del sistema; aquí ayudan a
determinar candidatos de atributos.

39. Paso 5: Integración final de la
Definición
 Se pueden definir operaciones adicionales
considerando la “historia de la vida” de los
objetos y los mensajes que circulan entre
ellos.
 La “historia de vida” de un objeto se puede
definir considerando que un objeto se crea,
se modifica, se manipula, se lee, y
posiblemente se elimina.

40. ¿ Qué es una Relación?
 Relación – indica conectividad , un “hecho”
que debe ser “recordado” por el sistema y
no puede ser o no es calculado o derivado
mecánicamente.
 Pueden existir varias instancias en una
relación.
 Los objetos pueden estar relacionados de
muchas maneras diferentes.

41. Cardinalidad y Modalidad
 CARDINALIDAD: es la especificación del
número de ocurrencias de un objeto que se
relaciona con ocurrencias de otro.
 Se expresa normalmente como “uno” o
“muchos”.
Ejemplo: Un marido tiene una esposa
Un padre tiene muchos hijos

42. Tipos de Cardinalidad:
 Uno a uno (1:1) – Una ocurrencia del objeto A se
puede relacionar a una y solo una ocurrencia del
objeto B.
 Uno a muchos (1:N) – Una ocurrencia del objeto A
se puede relacionar a una o muchas ocurrencias
del objeto B, pero una de B se puede relacionar
sólo a una del objeto A.
 Muchos a muchos (M:N) – Una ocurrencia del
objeto A puede relacionarse con una o más
ocurrencias de B, mientras que una de B se puede
relacionar con una o más de A.

43. Modalidad
 Indica si hay o no una necesidad
explícita de que ocurra una relación, o
que sea opcional.
 La modalidad es “uno” si una ocurrencia
de relación es obligatoria.

44. Un ejemplo de diagrama entidad-
relación
Cliente Solicita Servicio
Orden de
Trabajo
Genera
Consiste
de
Genera
listas
Pruebas de
Trabajo
Materiales
Seleccionadas
de
Tabla de
tareas estándar
1 m
1
w
1
n
1
1
w
n

45. Descripción de un Modelo Conceptual
usando UML
• Básicamente se
definen clases y sus
relaciones

46. Ejemplo
[Larman 1999]

47. Actividad de Análisis en el
Proceso Unificado (UP)
 UP es dirigido por casos de uso.
 Durante el análisis los casos de uso se
describen en términos de clases.
 UP tiene 3 tipos de clases:
◦ Clases de entidad: modelan información que
tendrá “larga vida” en el sistema
◦ Clases de fronteras (boundary classes):
modelan la interacción entre el producto de
software y sus actores, normalmente
asociadas con entradas y salidas
◦ Clases de control: modelan algoritmos y
cálculos complejos

48. Pasos de UP para realizar la
actividad de análisis
1. Repite
a. Realizar modelado funcional
b. Realizar modelado de clases
c. Realizar modelado dinámico
hasta que las clases de identidad hayan
sido extraídas satisfactoriamente.
1. Extrae las clases de frontera y las
clases de control
2. Refina los casos de uso
3. Realiza los casos de uso (extenderlos y
refinarlos)

49. Pasos en UP para extracción de
clases
 Modelado de funciones (hacer
escenarios)
 Modelado de clases de entidad (a
través de extracción de sustantivos)
 Modelado dinámico (genera
diagramas de estados)

50. Ejemplo de un diagrama de
clases de identidad (tomado de
Schach 2008)

51. Modelado dinámico
 El objetivo es producir diagramas de
estado por cada clase
 Un diagrama de flujo de estados
contiene:
◦ Inicio
◦ Fin
◦ Estados (los atributos de la clase se llaman
variables de estado, pues su valor determina
el estado de la clase)
◦ Eventos (ocurrencias que pueden cambiar
los estados)
◦ Predicados (algo que es verdadero o falso)

52. Ejemplo de un diagrama de
estados (tomado de Schach 2008)

53. Tareas de la Ing. de
Requerimientos
◦ Iniciación (Inception)
◦ Licitación (Elicitation)
◦ Elaboración
◦ Negociación
◦ Especificación
◦ Validación (Validation)
◦ Administración

54. Según el
“The sixth subarea [of software requirements] is
Requirements Validation, the aim of which is to pick
up any problems before resources are committed to
addressing the requirements. Requirements validation
is concerned with the process of examining the
requirements documents to ensure that they are
defining the right system (that is, the system that
the user expects). It is subdivided into descriptions of
the conduct of requirements reviews, prototyping, and
model validation and acceptance tests. ” (SWEBOK
2004, pp. 1-4)
“…it is also important to verify that a requirements
document conforms to company standards, and that
it is understandable, consistent, and complete….”
(SWEBOK 2004, pp. 2-8)

55. Más sobre V&V (verificación y
validación)
“…Verification is an attempt to ensure that
the product is built correctly, in the sense
that the output products of an activity meet
the specifications imposed on them in
previous activities. Validation is an attempt
to ensure that the right product is built that
is, the product fulfills its specific intended
purpose.…”
(SWEBOK 2004, pp. 11-3)

56. Validación de Requerimientos
 Revisar consistencia, omisiones,
ambigüedad
 Responder preguntas como:
◦ ¿Es cada requerimiento consistente con el
objetivo final del producto/sistema?
◦ ¿Se han especificado todos los requerimientos
en el nivel de abstracción adecuado?
◦ ¿Es el requerimiento realmente necesario?
◦ ¿Está el requerimiento acotado y bien definido?
◦ ¿Esta identificada la fuente de cada
requerimiento?

57. Validación de requerimientos (cont.)
◦ ¿Algún requerimiento entra en conflicto con
otro?
◦ ¿Es cada requerimiento alcanzable en el
contexto técnico del sistema?
◦ ¿Se puede probar el requerimiento una vez que
se implemente el sistema?
◦ ¿Está dividido el modelo de requerimientos de
tal manera que expone progresivamente el
detalle acerca del sistema?

58. Proceso Unificado
[Jacobson et al., 2000]