Requisitos

Entendiendo los requisitos

Ingeniera de Requisitos-I
Concepcinpreguntar un conjunto de cuestiones que
establezcan
El entendimiento bsico del problema
Las personas que quieren la solucin
La naturaleza de la solucin que se desea, y
La efectividad de la comunicaciones preliminares y la
colaboracin entre el cliente y el desarrollador
Elicitacinelicitar requisitos de todos los stakeholders
Elaboracincrear un modelo de anlisis que identifique los
los requisitos de datos, funciones y comportamiento
Negociacinacordar un sistema entregable que sea
realista para desarrolladores y el cliente
Entendiendo los Requisitos

16/02/2016

Ingeniera de Requisitos-II
Especificacinpuede ser uno o ms de los siguientes:
Un documento escrito.
Un conjunto de modelos.
Una especificacn formal matemtica.
Un conjunto de escenarios de usuario (casos de uso).
Un prototipo.
Validacinun mecanismo de revisin que busque:
Errores en el contenido o la interpretacin.
Areas que requieren una clarificacin.
Informacin perdida.
Inconsistencias ( el mayor problema en la ingeniera de
grandes productos o sistemas).
Requisitos en conflicto o no realistas (Inalcanzables).
Gestin de requisitos
Entendiendo los Requisitos

16/02/2016

Concepcin
Identificacin de stakeholders
Con quin ms cree usted que debera hablar?
Reconocer los mltiples puntos de vista.
Trabajar hacia la colaboracin.
Las primeras preguntas:
Quin est detras de la la peticin de este
trabajo?
Quin usar la solucin?
Cul ser el beneficio econmico de una
solucin exitosa?
Existe otra fuente para la solucin que vd. desea?

Entendiendo los Requisitos

16/02/2016

Elicitando Requisitos
Las reuniones sern dirigidas y asistirn tanto los ingenieros del
software como los los clientes.
Se establecern reglas para la preparacin y participacin.
Se sugerira una agenda.
Las reuniones sern controladas por un facilitador (Puede se un
cliente, un desarrollador o alguien ajeno).
Se utilizar un mecanismo de definicin" (hoja de clculo,
rotafolios, post-it o un tabln de anuncios electrnico, sala de chat
o forum virtual)
La meta es:
Identificar el problema
Proponer elementos de la solucin
Negociar las diferentes aproximaciones, y
Especificar un conjunto preliminar de requisitos de la solucin

Entendiendo los Requisitos

16/02/2016

Elicitando Requisitos

Entendiendo los Requisitos

16/02/2016

Despliegue en Funcin de la
Calidad DFC
Es una tcnica de calidad que se
concentra en maximizar la satisfaccin
del cliente.
Tipos de requisitos:
Normales.
Esperados (Implcitos).
Emocionantes.

Entendiendo los Requisitos

16/02/2016

Productos del trabajo de

Elicitacin
Un enunciado de la necesidad y su factibilidad.
Un enunciado acotado del alcance del sistema o
producto.
Una lista de clientes, usuarios y otros participantes que
intervienen en la indagacin de los requisitos.
Una descripcin del ambiente tcnico del sistema.
Una lista de requisitos (de preferencia organizados por
funcin) y las restricciones del dominio que se aplican a
cada uno.
Un conjunto de escenarios de uso que dan perspectiva
al uso del sistema o producto en diferentes condiciones
de operacin.
Cualquier prototipo desarrollado para definir requisitos.
Entendiendo los Requisitos

16/02/2016

Construyendo el Modelo de
Anlisis
Elementos del Modelo de Anlisis
Elementos basados en escenarios:
Funcionalnarraciones de procesamientos de
funciones software
Casos de usodescripciones de la interaccin entre
un actor y el sistema
Elementos basados en clases:
Implcitos en los escenarios
Elementos de comportamiento:
Diagramas de estados
Elementos basados en el flujo (discurrir-flow):
Diagramas de flujos de datos
Entendiendo los Requisitos

16/02/2016

10

Casos de Uso
Una coleccin de escenarios de usuario que describen un hilo de uso
del sistema.
Cada escenario se describe desde el punto de vista de un actor
una persona o un dispositivo que interactua de alguna manera con el
sotware.
Cada escenario responde las siguientes preguntas:
Quin es el actor principal (primario) y el(los) secundario(s)?
Cules son las metas del actor?
Qu precondiciones existen antes de que comience la historia?
Cules son las tareas o funciones fundamentales del actor?
Qu extensiones deben considerarse al describer la historia?
Qu variaciones son posibles en la interaccin del actor?
Qu informacin del sistema adquiere, produce o modifica el
actor?
Debe el actor informar al sistema sobre modificaciones del entorno?
Qu informacin desea obtener el actor del sistema?
Desea el actor ser informado de cambios inesperados?
Entendiendo los Requisitos

16/02/2016

11

Diagrama de Casos de Uso

Entendiendo los Requisitos

16/02/2016

12

Diagrama de Clases
Cada scenario de uso implica un conjunto de
objetos que se manipulan cuando un actor
interacta con el Sistema.
Estos objetos se clasifican en clases (conjuntos
de objetos que tienen atributos y
comportamientos iguales).
De manera grfica adems de describer las
clases se ilustra la manera en que las clases
colaboran entre s y las relaciones e iteraciones
entre ellas.

Entendiendo los Requisitos

16/02/2016

13

Diagrama de Clases
Del Sistema CasaSegura

Entendiendo los Requisitos

16/02/2016

14

Diagrama de Clases

Entendiendo los Requisitos

16/02/2016

15

Diagrama de Estados (UML)

Es un mtodo de representacin del
comportamiento de un sistema que
muestra sus estados y los eventos que
hacen que el Sistema cambie de estado .
Un estado es cualquier modo de
comportamiento observable del sistema.
En el diagrama adems se incluyen
acciones que resultan de cada cambio.

Entendiendo los Requisitos

16/02/2016

16

Diagrama de Estados (UML)

Entendiendo los Requisitos

16/02/2016

17

Patrones de Anlisis
Dentro de la ingeniera de requisitos nos
encontramos ciertos problemas recurrentes, una
forma adecuada de tratarlos es recurrir a los
patrones de anlisis que nos sugieren soluciones
(clase, funcin, comportamiento) que adems
de representar buenas prcticas pueden
volverse a utilizar para modelar muchas otras
aplicaciones.

Entendiendo los Requisitos

16/02/2016

18

Patrones de Anlisis
Nombre de patrn: Un descriptor que encierra la esencia del patrn.
Objetivo: Describe la misin del patrn y lo que representa.
Motivacin: Un escenario que ilustra cmo puede utilizarse el patrn para
abordar el problema.
Cuestiones y contexto: Una descripcin de como cuestiones externas que
afectan a cmo se usa el patrn y las cuestiones externas que pueden ser
resueltas al utilizar el patrn.
Solucin: Una descripcin de cmo se aplica el patrn para solucionar el
problema, con nfasis en temas estructurales y de comportamiento..
Consecuencias: Determinar que cambios hay cuando se aplica el patrn y
compensaciones que existen.
Diseo: Enunciar cmo el patrn de anlisis puede desarrollarse en patrones
de diseo que sean conocidos.
Experiencias: Ejemplos de uso del patrn en sistemas actuales.
Patrones relacionados: Uno o ms patrones de anlisis que estn relacionados
con el nombre de patrn dado por que se utilicen conjuntamente o por que su
estructura sea similar o por ser una variacin de este.

Entendiendo los Requisitos

16/02/2016

19

Negociacin de requisitos
Identificar los stakeholders clave:
Estas sern las personas involucradas en
la negociacin.
Determinar las condiciones de triunfo (win)
de cada stakeholder. Las condiciones de
triunfo no son siempre evidentes.
Negociacin:
Trabajar para llegar a una situacin en
que las dos partes ganen (win-win).

Entendiendo los Requisitos

16/02/2016

20

Validacin de Requisitos - I
Es coherente cada requisito con los objetivos generales
del sistema o producto?
Se han especificado todos los requisitos en el nivel
apropiado de abstraccin? Es decir, algunos de ellos
tienen un nivel de detalle tcnico que resulta inapropiado
en esta etapa?
El requisito, es realmente necesario o representa una
caracterstica agregada que tal vez no sea esencial para
el objetivo del sistema?
Cada requisito est acotado y no es ambiguo?
Tiene atribucin cada requisito? Es decir, hay una
fuente (por lo general una individual y especfica) clara
para cada requisito?
Hay requisitos en conflicto con otros?
Entendiendo los Requisitos

16/02/2016

21

Validacin de Requisitos - II
Cada requisito es asequible en el ambiente tcnico
que albergar el sistema o producto?
Una vez implementado cada requisito, puede
someterse a prueba?
El modelo de requisitos, refleja de manera apropiada
la informacin, la funcin y el comportamiento del
sistema que se va a construir?
Se ha particionado el modelo de requisitos en forma
que exponga informacin cada vez ms detallada
sobre el sistema?
Se ha usado el patrn de requisitos para simplificar el
modelo de stos? Se han validado todos los patrones
de manera apropiada? Son consistentes todos los
patrones con los requisitos del cliente?
Entendiendo los Requisitos

16/02/2016