3. Guia Análisis de Requerimientos

22
Ingeniería de Requerimientos Levantamiento de Información Requerimientos de Sistemas de Información Hardware Desarrollo Necesidades del Cliente Clientes Analistas Sistemas Documentación

Transcript of 3. Guia Análisis de Requerimientos

Page 1: 3. Guia Análisis de Requerimientos

Ingeniería de Requerimientos

Levantamiento de Información

Requerimientos

de

Sistemas de Información

Hardware

Desarrollo

Necesidades del Cliente

Clientes

Analistas

Sistemas

Documentación

Page 2: 3. Guia Análisis de Requerimientos

La ingeniería de requerimientos ayuda a los

ingenieros de software a entender mejor el

problema en cuya solución trabajarán.

Incluye el conjunto de tareas que conducen a

comprender cuál será el impacto del software y

cómo interactúan los usuarios finales con el

sistema.

Ingeniería de RequerimientosDefinición

Page 3: 3. Guia Análisis de Requerimientos

Ingeniería de RequerimientosDefinición

Teniendo en cuenta lo que usted visualiza enla imagen, una situación muy típica en loreferente proyectos de desarrollo desoftware, ¿Qué deduce de la historieta? ¿Aqué cree que se deba el resultado obtenidoen la imagen?

Pregunta de Análisis Req1

Tarea Req1

Realice un breve y conciso análisis --deacuerdo con su experiencia desarrollandosoftware-- sobre el porqué puede serdesastroso un sistema de información.

Page 4: 3. Guia Análisis de Requerimientos

•La educción de requisitos se refiere a la

captura y descubrimiento de los requisitos.

•Es una actividad más “humana” que técnica

•Se identifica a los interesados (stakeholders) y

se establecen las primeras relaciones entre

ellos y el equipo de desarrollo

La ingeniería de requisitos proporciona el

mecanismo apropiado para:

• Entender lo que el cliente quiere

• Analizar las necesidades

• Evaluar la factibilidad

• Negociar una solución razonable

• Especificar la solución sin ambigüedades

• Validar la especificación y administrar los

requisitos conforme éstos se transforman

en un sistema operacional

Ingeniería de RequerimientosEducción

Page 5: 3. Guia Análisis de Requerimientos

Ingeniería de RequerimientosFunciones

La ingeniería de

requisitos es un puente

hacia el diseño y laconstrucción.

1. Inicio

2. Obtención

3. Elaboración

4. Negociación

5. Especificación

6. Validación

7. Gestión

La ingeniería de requisitos se lleva a acabo a través de siete distintas funciones, ytodas están dirigidas a definir lo que el cliente quiere.

Algunas de estas actividades ocurren en paralelo

Page 6: 3. Guia Análisis de Requerimientos

•Es una tarea que define el ámbito y la naturaleza del problema que debe

resolverse.

•La mayoría de los proyectos comienzan cuando se identifica una necesidad

de negocios o se descubre un nuevo mercado o servicio potencial.

•Los clientes pueden estar en una ciudad o país diferente, pueden tener sólo

una idea vaga de lo que se quiere.

•Debe haber una identificación de los interesados, que son las personas que

se benefician de una forma directa o indirecta.

•Reconocimiento de múltiples puntos de vistas, ejemplo. Las personas de

mercadotecnia, en cuanto a que el nuevo sistema sea fácil de vender, los

gerentes de negocios están interesados en un grupo de características que se

puedan construir sin rebasar un presupuesto.

Ingeniería de Requerimientos1-Inicio

Fase de inicio

Page 7: 3. Guia Análisis de Requerimientos

Técnicas de obtención de requerimientos

• Preliminares: Utilizar preguntas libres de contexto

• Brainstorming. Administrador, lluvias de ideas.

• Creatividad? (manejo de herramientas.)

• Entrevistas: Es el método “tradicional”

• Observación y análisis de tareas

• Casos de uso / Escenarios: requisitos en contexto de uso

• Prototipado: Útiles cuando la incertidumbre es total acerca del futuro sistema.

Ingeniería de Requerimientos2-Obtención

Page 8: 3. Guia Análisis de Requerimientos

• Dentro de las técnicas utilizadas para recopilar información,

las entrevistas ocupan un lugar preponderante, son la mayor

fuente de información del analista.

• Las entrevistas se pueden realizar sobre la base de un

cuestionario rígido o de una guía más o menos detallada que las

orienta hacia puntos bien definidos.

• Es fundamental: Entrevistar a la(s) persona(s) adecuadas

• Preparar las preguntas con antelación

• Utilizar diagramas, modelos, etc.

Ingeniería de Requerimientos2-Obtención

Page 9: 3. Guia Análisis de Requerimientos

El método de entrevistas para obtener información tiene lassiguientes ventajas:

• Permite a los analistas presentar sus necesidades de forma

directa y verificar en las respuestas recibidas, si las preguntas

realizadas fueron interpretadas correctamente.

• Es una oportunidad que tiene el analista para conocer el grado de

aceptación o resistencia que existe entre los usuarios hacia el

sistema que se desea diseñar.

• .

Ingeniería de Requerimientos2-Obtención

Page 10: 3. Guia Análisis de Requerimientos

Objetivo:

• Generar un gran número de ideas

• Seleccionar un grupo variado de participantes

• Eliminar críticas, juicios y evaluaciones mientras los participantes sugieren

ideas

• Producir muchas ideas. “La calidad emerge de la cantidad”

• Recoger todas las ideas por escrito

BRAINSTORMING

Ingeniería de Requerimientos2-Obtención

Page 11: 3. Guia Análisis de Requerimientos

Comprensión de Requerimientos

Ingeniería de Requerimientos2-Obtención

La comprensión de los requisitos de un problema está entre las tareasmás difíciles que enfrenta un ingeniero de software.

El cliente no sabe lo que quiere, no esta seguro de qué es lo que necesita

Algunas veces el cliente no comprende del todo el dominio delproblema.

Tiene dificultades al comunicar necesidades al ingeniero de sistemas.

Omiten información que consideran obvia, y aún si los clientes y usuariosfinales son explícitos en sus necesidades, estos requisitos pueden cambiardurante el proyecto.

Pregunta de Análisis Req2

Page 12: 3. Guia Análisis de Requerimientos

Las listas pueden haber sido colocadas en un boletín electrónico, en un sitio web interno, o

situadas dentro de un ambiente de foro de discusión.

Ingeniería de Requerimientos2-Obtención

R

E

C

O

P

I

L

A

C

I

Ó

N

C

O

N

J

U

N

T

A

R

E

Q

U

I

S

I

T

O

S

D

E

Se crea el equipo de participantes y desarrolladores, para identificar el problema y proponer

elementos de solución, negociar diferentes enfoques y especificar un conjunto preliminar de

requisitos para la solución.

Se programan reuniones dirigidas a los diferentes actores involucrados.

Se sugiere un a agenda que sea tan formal como para cubrir todos los puntos importantes.

Se pide a cada asistente hacer una lista de objetos que son parte del ambiente que rodea el

sistema, otros objetos que éste producirá, y objetos que utiliza para realizar sus funciones.

Además se le pide a cada asistente que elabore una lista de los servicios (procesos o

funciones) que manipulan o interactúan con los objetos.

Page 13: 3. Guia Análisis de Requerimientos

Ingeniería de Requerimientos3-Elaboración

Cada escenario del usuario se analiza para obtener clases deanálisis, entidades del dominio de negocio, se definen losatributos de cada clase de análisis y se identifican las relacionesy la colaboración entre las clases y se produce una variedad dediagramas de UML complementarios.

Esta actividad de la ingeniería de requisitos se enfoca en eldesarrollo de un modelo técnico refinado de las funciones,características y restricciones del software, mediante la creacióny el refinamiento de escenarios del usuario que describen laforma en que el usuario final, y otros actores interactuarán conel sistema.

Page 14: 3. Guia Análisis de Requerimientos

Ingeniería de Requerimientos4-Negociación

Se pide a los clientes, usuarios y otros interesados que ordenensus requisitos y después discutan los conflictos relacionados con laprioridad.

Se identifican y analizan los riesgos asociados con cada requisito

Se hacen estimaciones preliminares de esfuerzo requerido para sudesarrollo y después se utilizan para evaluar el impacto de cadarequisito en el costo del proyecto y sobe el tiempo de entrega.

Page 15: 3. Guia Análisis de Requerimientos

Ingeniería de Requerimientos5-Especificación

Una especificación puede ser un documento

escrito

También puede ser un conjunto de modelos gráficos, una colección de escenarios de uso, un

prototipo o cualquier combinación de estos.

También podría ser un documento que combina descripciones en el lenguaje natural y modelos

gráficos.

Algunos sugieren que para una especificación

se debe desarrollar y utilizar una plantilla

estándar.

ID de Requerimiento: Clave ó identificador del RequerimientoRequerimiento: Nombre del Requerimiento

Tipo de Requerimiento:

Funcional ó No Funcional

Clasificación:Si el requerimiento es NO funcional, clasificarlo

como Facilidad de uso, Disponibilidad, Capacidad…

Descripción: Descripción del RequerimientoDatos de Entrada: Entradas requeridas para el requerimiento

Datos de Salida: Salidas que se obtienen del requerimientoUsuarios Involucrados: Perfiles que intervienen en el requerimiento

Page 16: 3. Guia Análisis de Requerimientos

Ingeniería de Requerimientos6-Validación

El equipo de revisión que valida los requisitosincluye ingenieros de software, clientes, usuarios yotros interesados que examinan la especificación ybuscan errores en el contenido o la interpretación.

Aquí se examina la especificación paraasegurar que todos los requisitos desoftware se han establecido de maneraprecisa.

Tarea Req2

Page 17: 3. Guia Análisis de Requerimientos

Los requisitos contienen demasiados errores

Muchos de estos errores no se detectan al principio

Muchos de estos errores podrían ser detectados al principio

No detectar estos errores incrementará los costes (tiempo, dinero) de forma exponencial

Además, los programadores obedecen los requisitos (cuando existen).

• El sistema resultante no satisfará a los usuarios

• Se producirán desacuerdos entre usuarios desarrolladores

• Puede ser imposible demostrar si el software cumple, o no, los requisitos

• Se gastará tiempo y dinero en construir el sistema equivocado

Ingeniería de RequerimientosErrores

La evidencia empírica demuestra que…

Consecuencias de los errores

Page 18: 3. Guia Análisis de Requerimientos

Problema

Especificación Correcta

Especificación Incorrecta

Diseño Correcto

Diseño Erróneo

Programas Correctos

Programas Erróneos

Diseño Basado en la Especificación Errónea

Programas Basados en la Especificación Errónea

Programas Basados en un Diseño Erróneo

Funciones Correctas

Errores Corregibles

Errores Ocultos

Errores Incorregibles

Especificación de Requisitos

Diseño

Implementación

Pruebas

Productos Imperfectos

Ingeniería de RequerimientosErrores

Acumulación de Errores

Page 19: 3. Guia Análisis de Requerimientos

El proceso de requisitos es excesivamente largo y costoso

Los implicados en el proceso se quejan de falta de tiempo u otros recursos

Se reciben quejas acerca de la inteligibilidad del documento de requisitos

Los implementadores se quejan del trabajo perdido por culpa de errores en los requisitos

Los usuarios no utilizan muchas de las capacidades del sistema

En cuanto el producto se entrega, se recibe una inmensa cantidad de solicitudes de cambios

Lleva demasiado tiempo alcanzar un acuerdo cuando se proponen cambios a los requisitos

Ingeniería de RequerimientosProblemas

Encontraremos problemas en nuestro análisis de requerimientos cuando:

Page 20: 3. Guia Análisis de Requerimientos

_ Sistemas de 15 o 30 requisitos

– Sistemas de cientos de requisitos

– Sistemas de miles de requisitos

– Sistemas de 5.000 requisitos

– Sistemas de más de 10.000

– Sistemas de incluso 60.000 requisitos

Ingeniería de RequerimientosComplejidad

Dependiendo la cantidad de requisitos, el sistema va

adquiriendo cierta complejidad…

Page 21: 3. Guia Análisis de Requerimientos

Tarea Req3

Consultar el esquema estándar de IEEE 810, teniendo en cuenta:

•Introducción• Propósito• Alcance• Definiciones• Referencias• Visión General

•Descripción General• Perspectiva del producto• Funciones del producto• Características del usuario• Restricciones• Suposiciones

•Requisitos específicos• Apéndices• Índice

Ingeniería de RequerimientosTarea

Page 22: 3. Guia Análisis de Requerimientos

• Ingeniería de software, un enfoque práctico. Roger S. Pressman. Mc Graw Hill.

• Ingeniería de software, IAN SOMMERVILLE. Sexta edición. Addison Wesley. Person Educación

• UML y patrones . Craig. Larman

• www.vico.org

• Esquema del estándar de IEEE 830

Ingeniería de RequerimientosBibliografía