Ingenieria de Requerimientos

7/17/2019 Ingenieria de Requerimientos

http://slidepdf.com/reader/full/ingenieria-de-requerimientos-568f08573cf11 1/55

INGENIERÍA DE

REQUERIMIENTOS

Ing. Michael Asturias López



INGENIERÍA DE REQUERIMIENTOS

"Yo sé que usted piensa que entiende lo que digo,

pero lo que usted no entiende es que lo que digono es realmente lo que quiero decir".




Ley de Humphrey:Los clientes nunca saben lo que desean hasta queven el software que funciona.




Sirve para entender el problema que se resolverá.Incluyen tareas que conducen a comprender cuálserá el impacto del software sobre el negocio, quées lo que el cliente quiere y cómo se interactuara.

Trata de los principios, métodos, técnicas y

herramientas que permiten descubrir,documentar y mantener los requisitos parasistemas basados en computadora, de formasistemática y repetible.



INGENIERÍA DEREQUERIMIENTOS*

Entender los requerimientos de una solución basada ensoftware es una de las tareas mas difíciles para un(a)Ing. de software.

Como otras actividades de Ing. de Sw, ésta debeadaptarse a las necesidades del proceso, proyecto,producto y gente que hace el software.

La Ing. de Requerimientosprovee de un mecanismoapropiado 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, validarla especificación y administrar los requerimientosconforme se transforman.



REQUERIMIENTOS FUNCIONALES VSNO FUNCIONALESFuncionales: describen los servicios que seesperan del sistema.El sistema debe aceptar pagos con tarjetas Visa.

No funcionales: son restricciones sobre losrequisitos funcionales.De forma segura y con un tiempo menor a Nsegundos.



TAREAS DE LA ING. DEREQUERIMIENTOSIniciación ( Inception)Obtención ( Elicitation)Elaboración

NegociaciónEspecificación Validación (Validation) Administración

Algunas de estas funciones pueden ocurriren paralelo y ajustarse a las necesidadesdel proyecto



INICIACIÓN

Como se empieza un proyecto? Algunas vecesinicia por conversaciones informales, otras demanera mas formal; normalmente comoresultado de una necesidad importante

En esta parte, los ingenieros de software realizanpreguntas “libres de contexto” (generales), paraestablecer un entendimiento básico del problema,determinar las personas que quieren una

solución, la naturaleza de la solución, y laefectividad de las colaboraciones ycomunicaciones preeliminares que se generanentre el consumidor y el desarrollador



OBTENCIÓN DE REQUERIMIENTOS

Se refiere a definir formalmente losrequerimientos de la solución. Es difícil porquecomo ya se ha visto:Hay problemas de definición de alcancesHay problemas de entendimiento entre losinvolucrados

Hay problemas de volatilidad (los requerimientoscambian con el tiempo)



ELABORACIÓN

Esta actividad expande y refina la informaciónobtenida en la tarea de iniciación

Se enfoca en realizar modelos técnicos refinados de lasfunciones del software, características y limitantes.

Es básicamente una función de modelado. Se conducea través de la definición de escenarios del usuario quedescriben la interacción del usuario final con elsistema

Se define el dominio del problema desde varios puntos

de vista: información, funciones y comportamiento



NEGOCIACIÓN

Los usuarios y consumidores normalmente pidenmas de lo que se puede hacer con los recursos conque se cuenta.

Casi siempre diferentes involucrados( stakeholders) piden cosas diferentes, por lo quehay que conciliar intereses a través denegociaciones.

Hay varias maneras para negociar, y depende dela cultura de la organización y tamaño delproyecto



ESPECIFICACIÓN

Especificación significa diferentes cosas paradiferentes personas en el área de Ing. desoftware.

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 ylas restricción que tiene.



VALIDACIÓN

El producto generado por la ingeniería derequerimientos debe ser evaluado en términos decongruencia y calidad. Se debe asegurar que laespecificación concuerda con las expectativas del

usuario y que no es ambigua. Deben detectarse y corregirse errores, omisionese inconsistencias con respecto a los estándaresestablecidos en el proyecto.

El mecanismo común de validación es la revisióntécnica formal.



DESCRIPCIÓN DETALLADA DE LASTAREAS DE LA ING. DE

REQUERIMIENTOSIniciación ( Inception)

Obtención (Obtención ( Elicitation Elicitation))ElaboraciónElaboración

NegociaciónNegociaciónEspecificaciónEspecificación Validación ( Validación (ValidationValidation)) Administración Administración



PASOS DEL PROCESO DEINICIACIÓ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 deconflicto e inconsistencias.

4. Aplicación de preguntas iniciales.



ALGUNAS PREGUNTAS INICIALESTÍPICAS

Primeras¿Quién está detrás de la requisición de estetrabajo?

¿Quién usará la solución ?¿ Cual es el beneficio económico de una soluciónexitosa?

¿ Hay otras fuentes para obtener la soluciónbuscada que se necesitarán?

Siguientes:¿ Qué sería una “buena salida” para generar unasolución eficiente?

¿ Que problemas aparecerán con esta solución?¿ Podría describirme el medio ambiente en que lasolución funcionará?

¿ Qué aspectos de desempeño o limitacionesafectan la solución?



ALGUNAS PREGUNTAS TÍPICAS (2)

Siguientes:¿ Es Usted la persona correcta a preguntarle? ¿Sonsus respuestas “oficiales”?

¿ Considera mis preguntas relevantes al problema

que Usted tiene?¿ Le estoy preguntando demasiado?¿ Puede alguien mas darme información adicional ?



CARACTERÍSTICAS DE UN(A)BUEN(A) ING. DE

REQUERIMIENTOS Habilidad para captar conceptos abstractos sintetizándolosy

reorganizándolos en divisiones lógicas. Habilidad para obtener hechos importantes de situacionesconfusas.

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".



GENERACIÓN DE LASNECESIDADES DEL CLIENTEHerramientas para obtener información de lasnecesidades del Cliente:Cuestionarios

EntrevistasEstudio de campoRevisión de documentos en la base de datos deconocimiento de la organización

Autoaprendizaje



CUESTIONARIOS Los cuestionarios son útiles especialmente cuando hayuna gran cantidad de usuarios finales.

El diseño de un cuestionario requiere de tiempo y

dedicación, ya que un cuestionario deficiente producefrustració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 losusuarios, se debe seleccionar correctamente al grupo querealice el cuestionario.



ENTREVISTAS

La entrevista es una herramienta muy útilpara obtener información.

Se puede llevar a cabo en cualquier niveldentro de la organización, desde elpresidente hasta el obrero en la línea deensamble.

La entrevista debe prepararseadecuadamente.



CONSEJOS PARA REALIZARUNA ENTREVISTA

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

organiación, sus responsabilidades y actividades.

d) !cordar de antemano la "ora y el lugar de la entrevista.#vitar las interrupciones.

e) Preparar el contenido de la entrevista: temas, preguntas

etc.



CONSEJOS PARA REALIZARUNA ENTREVISTA

(CONTINUACIÓN)2) Conduciendo la entrevista: a) Presentarse al entrevistado y presentar al proyecto en el que se

trabaja.

b) Asegurarse de se entendieron correctamente lasresponsabilidades del entrevistado. Realizar preguntas de laforma: "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.



ALGUNOS PROBLEMASDURANTE L AS ENTREVISTAS

-Respuestas falsas por temor a admitir ignorancia- El usuario tiende a decir lo que el entrevistador quiere oír- Actitud cerrada hacia cambios

- Pesimismo total- Desvío del objetivo fundamental hacia otros problemas de

la organización



TAREAS DE LA ING. DEREQUERIMIENTOSIniciación (Iniciación ( Inception Inception))Obtención ( Elicitation)

ElaboraciónElaboración

NegociaciónNegociaciónEspecificaciónEspecificación Validación ( Validación (ValidationValidation)) Administración Administración



CONTINUANDO CON EL ANÁLISIS...

Según [Larman 99] las principales actividadesasociadas al análisis son:Definir los casos de usoDefinir el modelo conceptualDefinir los diagramas de colaboraciónDefinir diagramas de diseño de clases



OBTENCIÓN DE REQUERIMIENTOS Incluye juntas colaborativas de definición, despliegue defunciones y descripción de escenarios

Los productos que genera son:Una declaración de necesidades y factibilidadesUna declaración delimitada del alcance del sistema o

productoUna lista de consumidores, usuarios y otrosinvolucrados ( stakeholders) que participaron en ladefinición del documento

Una descripción del medio ambiente técnico del sistemaUna lista de requerimientos, de preferencia organizadospor función, y las restricciones de dominio que losafectan

Un conjunto de escenarios de uso que dan idea del usodel producto en diferentes condiciones operativas

Prototipos desarrollados



DESARROLLO DE CASOS DE USO Un caso de uso describe el comportamiento del sistema encondiciones diferentes, así como la respuesta del sistema alas requisiciones de uno o mas stakeholders

El primer paso es definir por escrito los “actores” queestarán involucrados en el sistema. Los actores son

personas o dispositivos que usan el producto dentro de uncontexto o función. Representan los roles de las personas odispositivos

De manera formal un actor es cualquier cosa que secomunica con el sistema o producto y que es externa a éste.Cada actor puede tener uno o mas objetivos cuando usa elsistema.

Se pueden identificar actores primarios, aquellos queinteractúan directamente con el sistema, y secundarios,aquellos que de alguna manera dan soporte al sistema, afin de que lo primarios puedan realizar su trabajo



DESARROLLO DE CASOS DE USO (2)

Una vez que se han identificado los actores, losiguiente es desarrollar el caso de uso. Jacobsonsugiere 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 ladescripción de la “historia”?

Continúa...



DESARROLLO DE CASOS DE USO (2)

Que variaciones en las interacciones del actorson posibles?

Qué sistemas de información adquirirá,producirá o cambiará el actor?

El actor tendrá que informar al sistema acercade cambios en el medio ambiente externo?

Que información desea el usuario del sistema?

Desea el actor ser informado acera de cambiosinesperados?



SÍMBOLOS USADOS EN LOSDIAGRAMA DE CASOS DE USO DE

UML*

Caso de

Uso



EJEMPLO DE UN DIAGRAMADE CASOS DE USO1

1. $istema de control de registro para ma%uinas tragamonedas. !lvare, &. et al.'to(o *



ESCENARIOS

Cada ovalo en el diagrama de casos de uso debeser descrito detalladamente, a través de unescenario.



INFORMACIÓN PRINCIPAL AINCLUIR EN LA DESCRIPCIÓN 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



DE

S C RIP

CI

Ó N

E S

CE NA

RI

O S



OT RA

PLA

NTILLA

PA

RADE S C RIBI R

ES

CENARIOS

[Larman,99]



EJEMPLO DE CASO DE USODEL PROYECTO “CASA

SEGURA”Involucrados:Dueño de la casa Administrador de la configuración

(probablemente la misma persona que eldueño)SensoresSubsistema de monitoreo

Escogiendo como “actor” al dueño de lacasa…



SISTEMA CASA SEGURA



INTERACCIONES DE “DUEÑODE LA CASA” CON EL SISTEMAIntroduce un “ password” para permitirotras interacciones

Pregunta sobre el status de una zona de

seguridadPregunta sobre el status de un sensorOprime el botón “pánico” en caso de unaemergencia

Activa o desactiva el sistema de seguridad



EJEMPLO DE CASO DE USODEL PROYECTO “CASA

SEGURA”



DIAGRAMA DE ACTIVIDADES

Representa el flujo de interacción conrespecto a un escenario específico

Los rectángulos indican funciones, las

flechas indican flujo, los diamantesindican ramas de decisión y las líneashorizontales indican que ocurrenactividades en paralelo.



DIAGRAMA DE ACTIVIDADESPARA LICITACIÓN DE

REQUERIMIENTOS



DIAGRAMAS TIPOSWIMLANE(CARRILES)

Son una variación de los de actividades. Permitenrepresentar el flujo de actividades y al mismotiempo indicar que actor(a) o clase tiene laresponsabilidad de la acción descrita por el

rectángulo. Se divide con líneas verticales eldiagrama, una columna por cada actor (como loscanales de nado en una piscina).



DIAGRAMA TIPO CARRILES



UNIFIED MODELINGLANGUAGE (UML)1

UML es:Un lenguaje que permite especificar, visualizar yconstruir artefactos de software

Un lenguaje destinado a los sistemas que utilizan

conceptos orientados a objetosNotación estándar para construir modelos orientadosa objetos

Solo una notación. No es un método o proceso dedesarrollo



DIAGRAMAS DE UML 2.0

Tres tipos, 13 diagramas:1. Diagramas de estructura estática.

Incluyen Diagramas de Clase, Diagramas de Objetos,Diagramas de Componente, Diagramas de EstructuraCompuesta, 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 DiagramasGenerales de Interacción (Interaction OverviewDiagram)



REQUERIMIENTOS DE LASNEGOCIACIONES

En lugar de una sola actividad de comunicacióncon el cliente, se definen las actividadessiguientes:

1.Identificación de los participantes clave delsistema o subsistema.2.Determinación de las “condiciones para ganar”de los participantes.

3.Negociación de las condiciones para ganar delos participantes a fin de reconciliarlas en unconjunto de condiciones ganar-ganar para todoslos que intervienen (incluso el equipo desoftware)



REQUERIMIENTOS DE LASNEGOCIACIONES



VALIDACIÓN DE LOSREQUERIMIENTOS

La revisión del modelo de requerimientos abordalas preguntas siguientes:

¿Es coherente cada requerimiento con losobjetivos generales del sistema o producto?

¿Se han especificado todos los requerimientos enel nivel apropiado de abstracción? Es decir,¿algunos de ellos tienen un nivel de detalletécnico que resulta inapropiado en esta etapa?




El requerimiento, ¿es realmente necesario orepresenta una característica agregada que talvez no sea esencial para el objetivo del sistema?

¿Cada requerimiento está acotado y no es

ambiguo?¿Tiene atribución cada requerimiento? Es decir,¿hay una fuente (por lo general una individual yespecífica) clara para cada requerimiento?

¿Hay requerimientos en conflicto con otros?




¿Cada requerimiento es asequible en el ambientetécnico que albergará el sistema o producto?

Una vez implementado cada requerimiento, ¿puedesometerse a prueba?

El modelo de requerimientos, ¿refleja de maneraapropiada la información, la función y elcomportamiento del sistema que se va a construir?

¿Se ha “particionado” el modelo de requerimientos enforma que exponga información cada vez más

detallada sobre el sistema? ¿Se ha usado el patrón de requerimientos parasimplificar el modelo de éstos? ¿Se han validado todoslos patrones de manera apropiada? ¿Son consistentestodos los patrones con los requerimientos del cliente?

Ingenieria de Requerimientos

Documents

Transcript of Ingenieria de Requerimientos