Sidney Valer Quispe

 Entender los requerimientos de una solución basada en

software es una de las tareas mas difíciles para un(a) Ing. de
software.
 Como otras actividades de Ing. de Sw, ésta debe adaptarse a
las necesidades del proceso, proyecto, producto y gente que
hace el software.
 La Ing. de Requerimientos provee de un mecanismo apropiado
para entender que quiere el consumidor, analizar sus
necesidades, valorar la factibilidad de construcción, negociar
una solución razonable, especificar de manera no ambigua
una solución, validar la especificación y administrar los
requerimientos conforme se transforman.
*Referencia: capítulo 7 libro de texto (Pressman 2005)
  Iniciación (Inception)
 Obtención (Elicitation)
 Elaboración
 Negociación
 Especificación
 Validación (Validation)
 Administración
 Algunas de estas funciones pueden ocurrir en
paralelo y ajustarse a las necesidades del proyecto
 Como se empieza un proyecto? Algunas veces inicia por
conversaciones informales, otras de manera mas formal;
normalmente como resultado de una necesidad importante
 En esta parte, los ingenieros de software realizan preguntas
“libres de contexto” (generales), para establecer un
entendimiento básico del problema, determinar las personas
que quieren una solución, la naturaleza de la solución, y la
efectividad de las colaboraciones y comunicaciones
preeliminares que se generan entre el consumidor y el
desarrollador
 Se refiere a definir formalmente los
requerimientos de la solución. Es difícil
porque como ya se ha visto:
 Hay problemas de definición de alcances
 Hay problemas de entendimiento entre los
involucrados
 Hay problemas de volatilidad (los requerimientos
cambian con el tiempo)
 Esta actividad expande y refina la información
obtenida en la tarea de iniciación
 Se enfoca en realizar modelos técnicos refinados de
las funciones del software, características y
limitantes.
 Es básicamente una función de modelado. Se
conduce a través de la definición de escenarios del
usuario que describen la interacción del usuario final
con el sistema
 Se define el dominio del problema desde varios
puntos de vista: información, funciones y
comportamiento
 Los usuarios y consumidores normalmente piden
mas de lo que se puede hacer con los recursos con
que se cuenta.
 Casi siempre diferentes involucrados (stakeholders)
piden cosas diferentes, por lo que hay que conciliar
intereses a través de negociaciones.
 Hay varias maneras para negociar, y depende de la
cultura de la organización y tamaño del proyecto
 Especificación significa diferentes cosas para
diferentes personas en el área de Ing. de software.
 Este es el producto de trabajo final de la ingeniería
de requerimientos.
 Sirve como base para actividades subsecuentes.
 Describe la función y desempeño de un sistema y las
restricción que tiene.
 Hay muchas técnicas para escribir especificaciones:
diagramas, narraciones en prosa, modelos
matemáticos, dibujos, etc.
 El producto generado por la ingeniería de
requerimientos debe ser evaluado en términos de
congruencia y calidad. Se debe asegurar que la
especificación concuerda con las expectativas del
usuario y que no es ambigua.
 Deben detectarse y corregirse errores, omisiones e
inconsistencias con respecto a los estándares
establecidos en el proyecto.
 El mecanismo común de validación es la revisión
técnica formal.
 Actividades que ayudan al equipo de trabajo a identificar,
controlar y seguir los requerimientos y cambios que ocurren
en ellos a través de todo el proceso de desarrollo.
 La administración empieza con la identificación de cada
requerimiento. Posteriormente se generan tablas que
permitirán darles seguimiento. Algunas de éstas son:
 Tablas de características
 Tablas de fuentes
 Tablas de dependencias
 Tablas de subsistemas
 Tablas de interfaces
 Iniciación (Inception)
 Obtención (Elicitation)
 Elaboración
 Negociación
 Especificación
 Validación (Validation)
 Administración
1. Identificación de involucrados (Stakeholders).
2. Reconocimiento de diferentes puntos de
vista.
3. Desarrollo de un ambiente colaborativo.
Implica identificar puntos en común, áreas
de conflicto e inconsistencias.
4. Aplicación de preguntas iniciales.
 Primeras
 ¿Quién está detrás de la requisición de este trabajo?
 ¿Quién usará la solución ?
 ¿ Cual es el beneficio económico de una solución exitosa?
 ¿ Hay otras fuentes para obtener la solución buscada que se
necesitarán?
 Siguientes:
 ¿ Qué sería una “buena salida” para generar una solución
eficiente?
 ¿ Que problemas aparecerán con esta solución?
 ¿ Podría describirme el medio ambiente en que la solución
funcionará?
 ¿ Qué aspectos de desempeño o limitaciones afectan la
solución?
 Siguientes:
 ¿ Es Usted la persona correcta a preguntarle? ¿Son
sus respuestas “oficiales”?
 ¿ Considera mis preguntas relevantes al problema
que Usted tiene?
 ¿ Le estoy preguntando demasiado?
 ¿ Puede alguien mas darme información adicional
?
 Habilidad para captar conceptos abstractos sintetizándolos y
reorganizándolos en divisiones lógicas.
 Habilidad para obtener hechos importantes de situaciones confusas.
 Habilidad para entender el medio ambiente.
 Habilidad para comunicarse bien en forma verbal y escrita.
 Habilidad para "ver el bosque a través de las hojas".
 Herramientas para obtener información de las
necesidades del Cliente:
 Cuestionarios
 Entrevistas
 Estudio de campo
▪ Revisión de documentos en la base de datos de
conocimiento de la organización
 Autoaprendizaje
 Los cuestionarios son útiles especialmente cuando hay una gran

cantidad de usuarios finales.
 El diseño de un cuestionario requiere de tiempo y dedicación, ya que
un cuestionario deficiente produce frustración y pérdida de interés en
el usuario.
 El cuestionario debe ser fácil de procesar
 En caso de que el cuestionario no se aplique a todos los usuarios, se
debe seleccionar correctamente al grupo que realice el cuestionario.
 La entrevista es una herramienta muy útil para
obtener información.

 Se puede llevar a cabo en cualquier nivel dentro de

la organización, desde el presidente hasta el obrero
en la línea de ensamble.

 La entrevista debe prepararse adecuadamente.

1) Preparación de la entrevista:

a) Buscar el apoyo del gerente de departamento o jefe

donde se llevará a cabo la entrevista.
b) Preparar la entrevista para un tiempo determinado, y
dárselo a conocer al entrevistado.
c) Identificar de antemano la posición del entrevistado
en la organización, sus responsabilidades y
actividades.
d) Acordar de antemano la hora y el lugar de la
entrevista. Evitar las interrupciones.
e) Preparar el contenido de la entrevista: temas,
preguntas etc.
2) Conduciendo la entrevista:
a) Presentarse al entrevistado y presentar al proyecto en el
que se trabaja.
b) Asegurarse de se entendieron correctamente las
responsabilidades del entrevistado. Realizar preguntas de
la forma: "tengo entendido que... ".
c) Estudiar el método de decisión del entrevistado.
d) Evitar palabras técnicas o rebuscadas.
e) Darse una idea del "sentimiento" del entrevistado con
respecto al sistema.
f) Escuchar al entrevistado.
g) Preguntar al entrevistado sobre algunas ideas propias que
pudieron olvidarse.
h) Al final de la entrevista resumir las conclusiones y escribir
una bitácora.
i) No tomar demasiadas notas.
j) Grabar la entrevista la mayoría de las veces resulta anti-
productivo.
 Respuestas falsas por temor a admitir
ignorancia
 El usuario tiende a decir lo que el
entrevistador quiere oír
 Boicoteo de información
 Actitud cerrada hacia cambios
 Pesimismo total
 Desvío del objetivo fundamental hacia otros
problemas de la organización
 Iniciación (Inception)
 Obtención (Elicitation)
 Elaboración
 Negociación
 Especificación
 Validación (Validation)
 Administración
 Según [Larman 99] las principales actividades
asociadas al análisis son:
 Definir los casos de uso
 Definir el modelo conceptual
 Definir los diagramas de colaboración
 Definir diagramas de diseño de clases
 Incluye juntas colaborativas de definición, despliegue de
funciones y descripción de escenarios
 Los productos que genera son:
 Una declaración de necesidades y factibilidades
 Una declaración delimitada del alcance del sistema o
producto
 Una lista de consumidores, usuarios y otros involucrados
(stakeholders) que participaron en la definición del
documento
 Una descripción del medio ambiente técnico del sistema
 Una lista de requerimientos, de preferencia organizados por
función, y las restricciones de dominio que los afectan
 Un conjunto de escenarios de uso que dan idea del uso del
producto en diferentes condiciones operativas
 Prototipos desarrollados
 Un caso de uso describe el comportamiento del sistema en
condiciones diferentes, así como la respuesta del sistema a
las requisiciones de uno o mas stakeholders
 El primer paso es definir por escrito los “actores” que estarán
involucrados en el sistema. Los actores son personas o
dispositivos que usan el producto dentro de un contexto o
función. Representan los roles de las personas o dispositivos
 De manera formal un actor es cualquier cosa que se
comunica con el sistema o producto y que es externa a éste.
Cada actor puede tener uno o mas objetivos cuando usa el
sistema.
 Se pueden identificar actores primarios, aquellos que
interactúan directamente con el sistema, y secundarios,
aquellos que de alguna manera dan soporte al sistema, a fin
de que lo primarios puedan realizar su trabajo
 Una vez que se han identificado los actores, lo
siguiente es desarrollar el caso de uso. Jacobson
sugiere hacer las siguientes preguntas:
 Quienes son los actores primarios y secundarios?
 Cuales son las “metas” de los actores?
 Que precondiciones deben existir antes de que la
“historia” empiece?
 Que tareas principales son realizadas por el actor?
 Que excepciones se pueden considerar con respecto a la
descripción de la “historia”?
Continúa...
 Que variaciones en las interacciones del actor son
posibles?
 Qué sistemas de información adquirirá, producirá o
cambiará el actor?
 El actor tendrá que informar al sistema acerca de cambios
en el medio ambiente externo?
 Que información desea el usuario del sistema?
 Desea el actor ser informado acera de cambios
inesperados?
Caso de
Uso
1. Sistema de control de registro para maquinas tragamonedas. Alvarez, V. et al.Otoño 04
 Cada ovalo en el diagrama de casos de uso
debe ser descrito detalladamente, a través de
un escenario.
 Nombre del caso de uso
 Actor principal
 Objetivo
 Pre-condiciones
 Iniciador del caso de uso
 Descripción del Escenario
 Excepciones
 Prioridades
 Disponibilidad
 Frecuencia de Uso
 Canales de comunicación con actores
 Canales con actores secundarios
 Puntos aún no resueltos
[Larman,99]
 Representa el flujo de interacción con respecto a un
escenario específico
 Los rectángulos indican funciones, las flechas
indican flujo, los diamantes indican ramas de
decisión y las líneas horizontales indican que
ocurren actividades en paralelo.
[Pressman 2004]
 Son una variación de los de actividades.
Permiten representar el flujo de actividades y
al mismo tiempo indicar que actor(a) o clase
tiene la responsabilidad de la acción descrita
por el rectángulo. Se divide con líneas
verticales el diagrama, una columna por cada
actor (como los canales de nado en una
piscina).
Fig. 8.8 [Pressman 04]
 UML es:
 Un lenguaje que permite especificar, visualizar y
construir artefactos de software
 Un lenguaje destinado a los sistemas que utilizan
conceptos orientados a objetos
 Notación estándar para construir modelos
orientados a objetos
 Solo una notación. No es un método o proceso de
desarrollo
1. Rea, J. “Introducción a Análisis y Diseño Orientado a Objetos.” Presentación UDLA ,2003
En el 2009 ya
se liberó la versión 2.2
 Tres tipos, 13 diagramas:
1. Diagramas de estructura estática. Incluyen Diagramas
de Clase, Diagramas de Objetos, Diagramas de Componente,
Diagramas de Estructura Compuesta, Diagramas de Paquete y
Diagramas de Entrega (Deployment)
2. Diagramas de Comportamiento. Incluyen Diagramas de
Caso de Uso, Diagramas de Actividades y Diagramas de
Estado de Máquina
3. Diagramas de Interacción. Incluyen Diagramas de
Secuencia, Diagramas de Comunicación, Diagramas de
Sincronización (timing) y Diagramas Generales de Interacción
(Interaction Overview Diagram)