El proceso de la Especificaci

1
El proceso de la Especificación de Requerimientos

• Metodologías de Análisis

2
Ingeniería de Requisitos

• La ingeniería de requisitos facilita el
  mecanismo apropiado para comprender lo que quiere
  el cliente

• Analizando necesidades

Confirmando su viabilidad
Negociando una solución razonable
Especificando la solución sin ambigüedad
Validando la especificación
Gestionando los requisitos para que se
transformen en un sistema operacional
.
3
Ingeniería de Requisitos
Índice del Tema

• Conocer las principales actividades de la
  ingeniería de requisitos y sus relaciones.

• Introducir a diversas técnicas para la obtención
  y análisis de requisitos.

• Conocer la importancia de la validación de
  requisitos y la utilización de las revisiones en
  este proceso.

• Entender por qué es necesaria la administración
  de requisitos y cómo ayuda a otras actividades de
  la misma.

4
Ingeniería de Requisitos
Tópicos a Cubrir

• Estudios de Factibilidad

• Obtención y Análisis de Requisitos

• Validación de Requisitos

• Administración de Requisitos

5
Ingeniería de Requisitos
Introducción
Actividades Genéricas de la Ingeniería de
Requisitos

• Estudio de Factibilidad --gt Informe de
  Factibilidad

• Obtención y análisis de Requisitos --gt Modelo de
  Sistemas

• Especificación de Requisitos --gt Requisitos del
  Usuario y del Sistema

• Validación de Requisitos --gt Documento de
  Requisitos

6
Ingeniería de Requisitos
Estudio de Factibilidad

• Entrada descripción resumida del sistema y de
  cómo se usará dentro de una organización.

• Salida informe que recomienda si es conveniente
  llevar a cabo la ingeniería de requisitos y el
  proceso de desarrollo del sistema.

7
Ingeniería de Requisitos
Estudio de Factibilidad
Estudio corto y orientado a resolver varias
preguntas

• El sistema contribuye a los objetivos generales
  de la organización?

• El sistema se puede implementar utilizando la
  tecnología actual y con las restricciones de
  costo y tiempo?

• El sistema puede integrarse a otros que existen
  en la organización?

8
Ingeniería de Requisitos
Estudio de Factibilidad
Aspecto Crítico el sistema contribuye a los
objetivos del negocio?

• Si la respuesta es no, entonces el sistema no
  tiene un valor real para el negocio.

9
Ingeniería de Requisitos
Estudio de Factibilidad
Actividades

• Evaluación y Recolección de la Información.

• Identifica la información requerida para
  contestar las tres preguntas anteriores.
• Luego, se cuestionan las fuentes de información
  para descubrir las respuestas.

10
Ingeniería de Requisitos
Estudio de Factibilidad
Actividades

• Evaluación y Recolección de la Información
  preguntas...

• cómo se las arreglaría la organización si no se
  lleva a cabo este sistema?
• cuáles son los problemas con los procesos
  actuales y cómo ayudaría el nuevo sistema a
  resolverlos?
• cuál es la contribución directa que hará el
  sistema a los objetivos del negocio?

11
Ingeniería de Requisitos
Estudio de Factibilidad
Actividades

• Evaluación y Recolección de la Información
  preguntas...

• la información se puede obtener y transferir a
  otros sistemas de la organización?.
• el sistema requiere de tecnología que no se ha
  utilizado previamente en la organización?
• a qué debe ayudar el sistema y a qué no necesita
  ayudar?

12
Ingeniería de Requisitos
Estudio de Factibilidad
Actividades

• Evaluación y Recolección de la Información
  fuentes...

• Administradores de departamentos
• Ingenieros de software
• Expertos en tecnología
• Usuarios finales

13
Ingeniería de Requisitos
Estudio de Factibilidad
Actividades

• Redacción de Informes

• Recomendación de cuándo debe continuar el
  desarrollo del sistema.
• Debe proponer cambios en el alcance, presupuesto
  y calendarización del sistema.
• Sugerir requerimientos adicionales de alto nivel.

14
Ingeniería de Requisitos
Obtención y Análisis de Requisitos

• Objetivos determinar el dominio de la
  aplicación, cuáles servicios debe proveer el
  sistema, el desempeño requerido, etc.

• Se deben incluir diversos tipos de personas de la
  organización stakeholders.

15
Ingeniería de Requisitos
Obtención y Análisis de Requisitos
Proceso difícil debido a...

• Los stakeholders, a menudo, no conocen realmente
  lo que desean obtener del sistema, excepto en
  términos muy generales.

• Los stakeholders de un sistema expresan los
  requisitos con sus propios términos, de forma
  natural y con un conocimiento explícito de su
  trabajo.

16
Ingeniería de Requisitos
Obtención y Análisis de Requisitos
Proceso difícil debido a...

• Diferentes stakeholders tienen requisitos
  diferentes y podrían expresarlos de varias formas.

• Los factores políticos influyen en los requisitos
  del sistema.

• El entorno económico y de negocios en el que se
  lleva a cabo el análisis.

17
Ingeniería de Requisitos
Obtención y Análisis de Requisitos
Proceso actividades del...

• Comprensión del problema.

• Recolecciónde requisitos.

• Clasificación.

• Resolución de conflictos.

• Priorización.

• Verificación de requisitos.

18
Ingeniería de Requisitos
Obtención y Análisis de Requisitos
Proceso técnicas

• Obtención orientada al punto de vista (VORD).

• Escenarios.

• Etnografía.

• Análisis estructurado.

• Prototipos.

19
Ingeniería de Requisitos
Obtención y Análisis de Requisitos
Técnica Obtención Orientada a Puntos de Vista

• Los enfoques orientados a puntos de vista toman
  en cuenta diferentes puntos de vista, y los usan
  para estructurar y organizar tanto el proceso de
  obtención como los requisitos mismos.

20
Ingeniería de Requisitos
Obtención y Análisis de Requisitos
Técnica Obtención Orientada a Puntos de Vista

• Diferentes ideas de lo que significa un punto de
  vista

• Una fuente o consumidor de datos.

• Un marco de trabajo de la representación.

• Un receptor de servicios.

21
Ingeniería de Requisitos
Obtención y Análisis de Requisitos
Técnica Obtención Orientada a Puntos de
Vistaetapas

• Identificación de puntos de vista, descubriendo
  los que reciben servicios del sistema e
  identificando los servicios específicos que se
  dan a cada punto de vista.

• Estructuración de puntos de vista, que comprende
  agrupar los relacionados en una jerarquía.

22
Ingeniería de Requisitos
Obtención y Análisis de Requisitos
Técnica Obtención Orientada a Puntos de
Vistaetapas

• Documentación de puntos de vista, que considera
  refinar la descripción de éstos y los servicios
  identificados.

• Trazado del punto de vista del sistema, que
  comprende identificar los objetos en un diseño
  orientado a objetos utilizando la información del
  servicio encapsulado en los puntos de vista.

23
Ingeniería de Requisitos
Obtención y Análisis de Requisitos
Técnica Obtención Orientada a Puntos de
Vistaejemplo.

• Referencia Cliente
• Atributos Número de cuenta, clave secreta,
  inicio transacción
• Eventos seleccionar servicio, cancelar
  transaccíón, finalizar transacción
• Servicios retiro de efectivo, consulta de saldo
• Subpuntos de Vista cuenta habiente, cliente
  extranjero

Descripción de Punto de vista
24
Ingeniería de Requisitos
Obtención y Análisis de Requisitos

• Referencia Retiro de efectivo
• Fundamento Mejorar el servicio al cliente y
  reducir papeleo
• Especificación los usuarios eligen este servicio
  presionando el botón de retiro de efectivo.
  Después ingresan la cantidad requerida. Ésta se
  confirma y, si los fondos lo permiten, se entrega
  la cantidad solicitada.
• Puntos de Vista Cliente
• Requisitos no Funcionales entregar efectivo en
  menos de 30 segundos desde que se haya confirmado
  la cantidad.

Descripción de Servicio
25
Ingeniería de Requisitos
Obtención y Análisis de Requisitos
Técnica Etnografía

• Los sistemas de software no existen de forma
  aislada se utilizan en un contexto social y
  organizacional.

• Un razón de por qué muchos sistemas de software
  se entregan pero no se usan (al menos con el
  impacto esperado), se debe a que no se toma en
  cuenta la importancia este tipo de requisitos.

26
Ingeniería de Requisitos
Obtención y Análisis de Requisitos
Técnica Etnografía

• La etnografía es una técnica de observación que
  se puede utilizar para entender los requisitos
  sociales y organizacionales.

• Radica en que ayuda a descubrir los requisitos
  explícitos que reflejan los procesos reales más
  que los formales.

• Consiste en sumergir un analista en el entorno,
  para que observe el desarrollo diario del sistema.

27
Ingeniería de Requisitos
Obtención y Análisis de Requisitos
Técnica Etnografía

• Especialmente efectiva para detectar

• Los requisitos que se derivan de la forma en que
  la persona trabaja realmente, más que de la forma
  en que las definiciones de los procesos
  establecen que debería hacerse.

• Los requisitos que se derivan de la cooperación y
  conocimiento de las actividades de la gente.

28
Ingeniería de Requisitos
Obtención y Análisis de Requisitos
Técnica Etnografía

• Se puede combinar con la construcción de
  prototipos (cont).

• La etnografía suministra información al
  desarrollo del prototipo de forma que se
  requieran menos ciclos de refinamiento.

• La construcción de prototipos usa la etnografía
  para identificar problemas y preguntas que se
  podrán discutir, posteriormente, con el etnógrafo.

29
Ingeniería de Requisitos
Obtención y Análisis de Requisitos
Técnica Escenarios

• Normalmente, es más fácil dar ejemplos de la vida
  diaria que descripciones generales o abstractas.

• Los analistas pueden aprovechar los datos
  obtenidos de estos ejemplos para formular los
  requisitos reales del sistema.

• Un escenario puede ser especialmente útil para
  agregar detalle a un bosquejo de descripción de
  requisitos.

30
Ingeniería de Requisitos
Obtención y Análisis de Requisitos
Técnica Escenarios

• La obtención de requisitos basada en escenarios
  se puede llevar a cabo de modo informal
  trabajando directamente con los stakeholders, o
  aplicando un esquema más estructurado como los
  escenarios de eventos o los casos de uso.

31
Ingeniería de Requisitos
Obtención y Análisis de Requisitos
Técnica Escenarios

• Un escenario incluye

• Una descripción del estado del sistema al inicio
  del escenario.

• 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 después de
  completar el escenario.

32
Especificación de requisitos de Calidad y otros
Requisitos

• Todos los requisitos de calidad se pueden y deben
  expresar sin ambigüedades.
• Si un requisito se expresa claramente..
• Terminar antes del 15/09/2008
• Se le da prioridad por sobre requisitos no tan
  claros
• más fácil de usar
• Información consistente
• User Friendly
• Mejor que el sistema anterior

33
Ejemplo de Requisito de Calidad cuantificado
34
Otro ejemplo de requerimiento de calidad
35
Cómo se describe un requisito de calidad
36
La escala y la prueba
37
Escala y Prueba
38
El peor nivel
39
El Nivel planificado
40
Los límites de la especificación de requisitos
41
Niveles actual y mejor
42
La autoridad
43
Jerarquía de Requisitos de calidad
44
Otro ejemplo de Jerarquía
45
Cómo hacer Jerarquía de Atributos
46
Análisis de requisitos
47
Caso M-DTV
48
Atributos relevantes del simulador (en Inglés)
49
Ease of learning
50
Ease of Operation
51
Time accuracy
52
TallerPaso 0 Identificar proyecto
53
Tallerpaso1 Jerarquía de Atributos
54
Tallerpaso 2 Especificación de Atributos
55
Clases de Atributos según ISO/IEC 9126 Parte 1
56
Requisitos usuales importantes
57
Atributos o cualidades ISO/IEC 9126-1
58
Advertencia
59
Funcionalidad
60
Confiabilidad
61
Usabilidad
62
Pseudo Atributos de usabilidad
63
Eficiencia
64
Mantenibilidad
65
Portabilidad
66
Críticas a ISO/IEC 9126-1
67
Planificación de calidad
68
Pasos de la planificación de calidad
69
1.- Identificar los Interesados
70
Priorizar el Nivel de Impacto
71
Matriz de Priorización
72
Ejemplo con escala alternativa y unos en la
diagonal
73
2.- Identificar Requerimientos de calidad del
proyecto

• Acá sólo se enumeran los requerimientos de
  calidad
• Cuidado que sean efectivamente requerimientos y
  no sólo deseos o ideales.
• Si algún requerimiento fuera de muy alto nivel
  (por ejemplo, fácil de usar) conviene hacer una
  jerarquía de atributos.

74
3.- Priorizar requerimientos de calidad del
proyecto

• Es posible usar una matriz de contribución
• Identificar requerimientos y la contribución que
  hace a cada interesado.
• Contribución se pondera por la prioridad del
  interesado.
• Esto entrega una priorización que indica cuánto
  contribuye cada requerimiento a quién

75
4.- Desarrollo de Estándares de calidad del
proyecto

• Estándar de calidad es una expresión medible de
  un requerimiento.
• Anteriormente vimos como es posible
  especificarlos
• Idealmente se hacen estándares para todos los
  requerimientos de calidad, pero se podrían omitir
  los menos prioritarios.

76
Estándares de calidad SMART

• Cada Estándar debe ser SMART (Astuto)
• S pecific (Específico)
• M easurable (Medible)
• A greed Upon (Acordado)
• R ealistic (Realista)
• T ime bound (Acotado en el tiempo)

77
Estándares de calidad
78
Taller 1Identificar Interesados
79
Taller 2Priorizar interesados
80
Taller 3Identificar requisitos
81
Taller 4Priorización de requisitos de calidad