Ingenieria De Requerimientos - Gezzler

Ingeniería De Requerimientos: Un Acercamiento

Introducción

M.C.C. Luis Islas Hernández [email protected]

¿Qué es la Ingenieria de requisitos?

Es aquel conjunto de técnicas que ayuda a los ingenieros de software a entender mejor el problema en el que trabajarán. ¿Cuál es el corazón de la Ingeniería de Requisitos? Un conjunto de tareas guía. Roger S. Pressman

¿A que conduce ese conjunto de tareas? •Cuál será el impacto del software sobre el negocio. •Qué es lo que el cliente quiere. •Cómo interactuarán los usuarios finales con el software.

¿Qué es un requisito?

Un requisito puede definirse como un atributo necesario dentro de un sistema, que puede representar una capacidad, una característica o un factor de calidad del sistema de tal manera que le sea útil a los clientes o a los usuarios finales.

Otras definiciones de Ingenieria de requisitos

La IR trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadora, de forma sistemática y repetible.

Todas las actividades de la ingeniería de sistemas/software relacionadas con: • Identificación y documentación de necesidades de clientes y usuarios. • Creación de un documento que describe la conducta externa y las restricciones asociadas [de un sistema] que satisfará dichas necesidades. • Análisis y validación del documento de requisitos para asegurar consistencia, compleción y viabilidad. • Evolución de las necesidades.

¿Porque es importante?

Programas elegantes resolviendo Los problemas incorrectos.

Primero hay que entender Exactamente lo que el cliente

quiere antes de comenzar a diseñar.

¿Y cómo se aplica?

Siguiendo una serie de pasos,

tareas o fases. Comenzando por una fase de inicio y terminando con la coincidencia entre la

concepción del problema que

tiene el ingeniero de software y la

percepción del cliente.

Tu peor pesadilla

Ralph Young

Un cliente entra en tu oficina, se sienta, te mira directo a los ojos y dice: “Yo sé que usted piensa que entiende lo que digo pero lo que usted no entiende es que lo que digo no

es realmente lo que quiero decir”

Y el problema es que… El dinero es quizás lo más importante en el desarrollo de proyectos informáticos.

El dinero esta en peligro, además no olvidemos que la reputación esta en juego.

Otro detalle importante… ¿Se pierde el tiempo con la Ingeniería de requisitos? ¡NO se pierde! Es realmente un punto importante que no debe omitirse.

Tareas de la ingenieria de requisitos.

Luis Islas Hernández [email protected]

Inicio Obtención Elaboració n

Especificación

Negociación

Validación

Gestion de requisitos

Inicio

Una conversación informal

Necesidad de negocios

Se descubre un nuevo mercado

Inicio

Preguntas libres de contexto

Objetivo principal Comprensión básica del problema en cuestión

Obtencion

Preguntar •Clientes •Usuarios •Otros Interesados

•Qué es lo que se debe lograr. •Forma en que el producto satisface las necesidades del negocio. •Como se utilizara dia con dia.

NO es facil hacerlo.

Obtencion

Problemas de ámbito. •Limite mal definido. •Detalles tecnicos innecesarios. Problemas de volatilidad. •Problemas cambian •Conforme pasa el tiempo.

Problemas de comprensión. •Ellos no estan seguros. •No comprenden al 100% el dominio del problema. •Dificultad para comunicar necesidades.

Elaboracio n

• •

La información se expande y se refina. Se enfoca en el desarrollo de un modelo técnico de:

1. Funciones. 2. Caracteristicas. 3. Restricciones.

• •

Es una acción del modelado de software. Creación de escenarios de uso del sistema.

Principalmente se busca establecer una base firme para el diseño.

Negociacion

Piden más de lo que se puede lograr. Proponen requisitos que generan conflictos

•Se habla de la prioridad. •Riesgos asociados con cada requisito. •Impacto de cada requisito en el costo. •Impacto en el tiempo de entrega.

Negociacion

Y al final...

•Algunos requisitos se eliminan. •Algunos requisitos se modifican. •Algunos requisitos de combinan.

Ambas partes contentas

Especificacion

Una especificación podria ser…

•Un documento escrito. •Un conjunto de modelos gráficos. •Un modelo matemático formal. •Una colección de escenarios de uso. •Un prototipo. •Una combinacion de todos los anteriores.

Especificacion

Proyectos grandes Un documento escrito combinando: •Lenguaje natural •Modelos gráficos.

Proyectos pequeños •Escenarios de uso… siempre y cuando residan en ambientes tecnicos que se comprendan bien.

•Es el producto final de la ingenieria de requisitos. •Sirve como base para las siguientes actividades.

Validacion

•Se evalua la calidad. •Sirve para asegurar que todos los requisitos se establezcan de manera precisa.

Mecanismo primario Revisión tecnica formal.

Examinan la especificación •Se buscan errores. •Areas que requieran clarificación. •Información faltante. •Inconsistencias. •Conflictos entre requisitos.

Validacion

Listas de verificación Examinamos cada requisito frente a una serie de preguntas. ¿Los requisitos estan establecidos de manera clara? ¿Pueden malinterpretarse? ¿Cuales otros requisitos estan relacionados con este? Buen metodo que se puede aplicar a muchas areas no Solo a ingenieria de requisitos.

Gestion de requisitos

“El deseo de cambios persiste durante la vida del sistema”. Conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en cualquier momento mientras se desarrolla el proyecto. Identificación

Tablas de rastreabilidad

Se comienza identificando cada requerimiento.

Se comienza identificando cada requerimiento.

Gestion de requisitos

Tablas de rastreabilidad

Gestion de requisitos

Tablas de rastreabilidad •De las caracteristicas. Relacion requisitos/caracteristicas observables. •De la fuente. Indica la fuente de cada requisito. •De dependencia. Relacion entre si de los requisitos. •Del subsistema. Categorias de requisitos. •De la interfaz. Relaciones con las interfases internas y externas.

Elementos del modelo de Analisis.

Basados en escenarios

Basados en Clases

Elementos De comportamiento

Orientados al flujo

Elementos orientados al flujo.

Entradas

Procesos Salida En efecto es posible crear un modelo de fluyo para cualquier sistema basado en computadoras, sin importar su tamaño o complejidad.

Negociación de requisitos.

¿Qué es la negociación de requisitos?

Definiéndola, la negociación de requisitos es una función de la ingeniería de requisitos en la cual se llega a “negociar” con el cliente los requisitos que van a satisfacerse con el sistema, de modo que ambas partes salgan ganando, es decir, que obtengan lo que merecen.

Objetivos de la negociación de requisitos

Hay determinadas cosas que se persiguen al negociar los requisitos, y son las siguientes: •Satisfacer a ambas partes (cliente y equipo de desarrollo). •Determinar requerimientos que puedan cumplirse (realistas). •Satisfacer los intereses de la otra parte (cliente en nuestro caso). •Realizar propuestas de posibles requerimientos necesarios pero que no habían sido detectados. •Establecer requerimientos que se encuentren dentro del rango limitado por las restricciones del proyecto tales como recursos, personal, tiempo.

Negociar es llegar a un acuerdo

“Un acuerdo es el arte de dividir un pastel de tal forma que cada Uno piense que se quedó con la rebanada más grande.” Ludwig Erhard

Porqué? Porque cuando se llega a un acuerdo, quiere decir que todos los que participamos del acuerdo estamos satisfechos con lo que hemos obtenido de él.

¿Porqué hay que negociar los requisitos?

Es de vital importancia negociar los requisitos con el cliente en vez de tener una simple charla de lo que ellos quieren porque de esa forma se evitan cosas como: •No hacer todo lo que el cliente requiere por incapacidad de hacerlo. •Quedar mal con el cliente. •Hacer las cosas pero utilizar más recursos de los disponibles y emplear mas tiempo del estipulado.

Actividades de la negociación de requisitos

Bohem ha establecido que hay 3 actividades que componen la negociación de requisitos, y el cumplimiento de estas actividades asegurará un acuerdo exitoso en el que todas las partes salgan ganando. Dichas actividades son: •Identificación de l@s interesad@s clave en el sistema o subsistema. •Determinación de las condiciones ganadoras (requisitos) de los interesados. •Negociación de dichas conexiones para reconciliarlas (establecerlas) en un conjunto de requerimientos del tipo ganar-ganar.

Validacion de requisitos.

¿Porqué validar los requisitos?

Cuando estamos haciendo funciones como determinar, formular, negociar requisitos es necesario examinarlos detalladamente para conocer su consistencia, omisiones y ambigüedades (es decir, interpretado de varias formas, lo que da lugar a dudas). Estos requisitos son jerarquizados debido a que son puestos en paquetes de requisitos que son implementados como incrementos de software (prototipos) que son entregados al cliente (Esto en caso de trabajar con un modelo de desarrollo de software que en donde se entregan prototipos regularmente durante el ciclo de vida del software).

Preguntas clave en la revisión de los requisitos.

¿El requisito es necesario en realidad o es una característica agregada irrelevantemente para el objetivo del sistema? ¿Cada requisito es alcanzable en el ambiente técnico que recibirá al sistema o producto? ¿El modelo de requisitos refleja de manera adecuada la información, la función y el comportamiento? ¿Cada requisito está limitado y no es ambiguo? ¿Algunos requisitos entran en conflicto con otros?

Extras.

Muy importante: ¿Es lo mismo?

Ingeniería de Requisitos

¿Son iguales? Análisis de Requisitos

Ingeniería de Requisitos

Es aquel conjunto de técnicas que ayuda a los ingenieros de software a entender mejor el problema en el que trabajarán.

Análisis de Requisitos

Es aquel que genera la especificación de características operacionales de software ; Indica la interfaz del software con otros elementos del sistema, y establece las restricciones que debe tener el software. El Ing. de Software se extiende sobre requisitos básicos establecidos en la Ingenieria de requisitos.

Caso de la vida real 1. Consecuencias de no aplicar la Ingeniería de requisitos adecuadamente. •Cliente con poco tiempo. •Cliente mentiroso. •Desarrolladores cómodos. •Mala relación con el cliente. El cliente ha amenazado con acciones legales. El proyecto ha cambiado mucho. El cliente se tomo las cosas personales. El proyecto se ha vuelto un desafió.

Caso de la vida real 2. Consecuencias de no aplicar la Ingeniería de requisitos adecuadamente. •Cliente abusador. •Cliente paranoico. •Desarrolladores temperamentales. •Mala relación con el cliente. El cliente no nos dejo respirar. Recibía de 7 a 15 emails diarios y de 5 a 6 llamadas diarias. El cliente cambio de parecer muchas veces. El cliente llamaba a las 10/11 de la noche al celular.

Preguntas y respuestas