Ingeniera de requisitos

 Ayuda a los ingenieros de software a entender
mejor el problema en cuya solución trabajarán.
 ¿Por qué es importante? Se debe entender lo que
el cliente quiere antes de comenzar a diseñar y
construir un sistema.
 Toma en cuenta errores, coste y tiempo.
 La IR trata de los principios, métodos, técnicas y
herramientas que permiten descubrir, documentar
y mantener los requisitos, de forma
sistemática y repetible.
2Ingeniería de requisitos

 El objetivo del proceso de la ingeniería de
requisitos es darle a todas las partes una
explicación escrita del problema.
 Es esencial que se haga un esfuerzo real por
entender los requisitos de un problema antes de
intentar resolverlo.
Ingeniería de requisitos 3

 Funcionales
◦ Describen los servicios que se esperan del sistema.
 No funcionales
◦ Restricciones sobre los requisitos funcionales
◦ Existen dos tipos:
ORIENTADOS AL USUARIO ORIENTADOS AL DESARROLLADOR
Fiabilidad Disponibilidad
Seguridad Portabilidad
Usabilidad Adaptabilidad
Robustez Testabilidad
Rendimiento, etc Comprensibilidad

 Proporciona el mecanismo adecuado para
entender lo que el cliente quiere.
 Fases de la IR:

 Se inicia muchas veces por:
◦ Identifica nueva necesidad de negocios.
◦ Se descubre un nuevo mercado.
◦ Se descubre un nuevo servicio.

 La obtención de información no es tan fácil como
parece. Los ingenieros deben realizar en forma
organizada la actividad de recopilación de
requisitos.
DE ÁMBITO DE COMPRENSIÓN DE VOLATILIDAD
Limite del sistema mal
definido
El cliente no está seguro 100% de
que es lo que necesita
Los problemas cambian con el
tiempo.
Detalles técnicos
innecesarios, etc.
Tienen dificultades para
comunicar sus necesidades, etc.

 Objetivo: Desarrollar modelo técnico refinado de
las funciones, características y restricciones del
software.
 Se conduce mediante la creación y refinamiento
de escenarios.
 El resultado final es un modelo de análisis que
define:
◦ El dominio de la información.
◦ Funciones.
◦ Comportamiento del problema.

 Clientes, usuarios y otros interesados deben
ordenar sus requisitos y luego discutir los
conflictos relacionados con la prioridad.
 Hacer estimaciones preliminares del esfuerzo
requerido para su desarrollo.
 Mediante un enfoque iterativo los requisitos se
elimina, combinan o modifican.

 Puede ser:
Se recomienda que:
La especificación es el trabajo final que genera la IR.
SISTEMAS GRANDES SISTEMAS PEQUEÑOS
Documentos escritos Escenarios de uso
Documento escrito
Conjunto de modelos gráficos
Modelo matemático formal
Escenarios de uso
Prototipo
Una combinación de estos.

 Examina la especificación para asegurar que los
requisitos de software se han establecido de
manera precisa.
ALGUNAS PREGUNTAS RECOMENDADAS PARA VALIDAR
¿La fuente del requisito está identificado?
¿Cuáles otros requisitos están relacionados con éste?
¿El requisito viola alguna restricción del dominio del sistema?
¿El requisito se puede probar? ¿Se pueden especificar las pruebas?, etc.

 Es el conjunto de actividades que ayuda al equipo del
proyecto a identificar, controlar, rastrear los requisitos
como también los cambios a éstos en el desarrollo del
proyecto.
 Para esto se desarrollan las siguientes tablas:
 La gestión formal se inicia solo para proyectos grandes
TABLAS
De rastreabilidad de las características.
De rastreabilidad de la fuente.
De rastreabilidad del subsistema.
De rastreabilidad de la interfaz.

 Identificación de los interesados.
◦ Todos aquellos que se benefician en una forma directa o
indirecta del sistema.
 Reconocimiento de múltiples puntos de vista.
◦ Categorizar la información de los interesados de manera que
permita elegir un conjunto de requisitos para el sistema que
sean consistentes de manera interna.
 Trabajo con respecto a la colaboración.
◦ Identificar áreas en común y áreas inconsistentes.
 Formulación de las primeras preguntas
◦ Las preguntas deben ser ‘libres de contexto’.
 ¿Quién usará la solución?
 ¿Cuál será el beneficio económico de una solución exitosa?

 Recopilación conjunta de requisitos
◦ La meta es identificar el problema, proponer elementos
de solución, negociar diferentes enfoques y especificar
un conjunto de requisitos preliminares.

 Es una técnica que traduce las necesidades del
cliente en requisitos técnicos para el software.
 QFD define los requisitos para maximizar la
satisfacción del cliente.
 QFD identifica 3 tipos de requisitos.
NORMALES ESPERADOS ESTIMULANTES
Objetivos y metas establecidos para un
sistema durante las reuniones con el
cliente.
Están implícitos en el producto o
sistema.
Características que van más allá de las
expectativas del cliente.

 Se aplica para determinar el valor de cada función
que se requiere para el sistema.
 El despliegue de la información identifica los
datos de los objetos y eventos que debe consumir
y producir el sistema.
 El despliegue de tareas examina el
comportamiento del sistema o producto dentro del
contexto de su entorno.

 Escenarios del usuario.
◦ Proporcionan una descripción de cómo se usará el
sistema.
 Productos de trabajo de obtención.
◦ Los productos producidos como consecuencia de la
obtención de requisitos variará de acuerdo con el
tamaño del sistema a construir.

 Un caso de uso muestra el software o sistema
desde el punto de vista del usuario final.
 Los actores son las diferentes personas que utilizan
el sistema dentro del contexto de la función y el
comportamiento que se describirá.
 Un actor es algún elemento que se comunica con el
sistema y que es externo al sistema.
PRIMARIOS SECUNDARIOS
Interactúan para lograr la función
requerida del sistema
Dan soporte al sistema.

 El objetivo del modelo de análisis radica en
describir requeridos de información,
funcionamiento y comportamiento para un
sistema basado en computadoras.
 Es una representación de los requisitos en un
momento determinado.
 Los elementos del modelo los determina el
método de modelado que se utilice.

 Elementos basados en escenarios
◦ Sirven como una entrada para la creación de otros
elementos de modelado.
 Elementos basados en clases.
◦ Conjuntos de objetos que se manipula mientras un actor
interactúa con el sistema.

 Elementos de comportamiento.
◦ El comportamiento de un sistema puede tener efecto
sobre el diseño que se elija.
◦ Un estado es cualquier forma de comportamiento
observable.
◦ Las variables de estado indican la manera en que el
estado se manifiesta.

 Elementos orientados al flujo.
◦ La información se transforma mientras fluye a través de
un sistema.
◦ Es posible crear un modelo de flujo para un sistema sin
que importe su complejidad.

 Representan algo dentro del dominio de
aplicación que puede reutilizarse al modelar
muchas aplicaciones.
 Se pueden encontrar en casi cualquier actividad
de la vida diaria.
PLANTILLA
Nombre del patrón
Intención
Motivación
Fuerzas y contexto
Solución
Consecuencias
Diseño
Usos conocidos
Patrones relacionados

 El objetivo es desarrollar un plan proyecto que
satisfaga las necesidades del cliente.
DIRECTRICES A CONSIDERAR
Reconocer que no es una competencia
Decidir que es lo que se desearía lograr
No se debe pensar en formular una respuesta
mientras la otra parte está hablando
Enfocarse en los intereses de la otra parte
No dejar que se vuelva personal
Ser creativo
Estar listo para pactar.
ACTIVIDADES A CONSIDERAR
Identificación de los interesados clave en el sistema
o subsistema.
Determinación de las condiciones 'ganadoras' de
los interresados.
Negociación de las condiciones ganadoras para
unirlas en un conjunto de condiciones del tipo
ganar - ganar para todos los involucrados.

 Los modelos de análisis se examinan para
conocer que consistencia, omisiones o
ambigüedades portan.
 Cada requisito y modelo de análisis se validan
como un todo contrastándolos con las
necesidades del cliente para asegurar que se
construirá el sistema correcto.
ASPÉCTOS DE LA VALIDACIÓN
Válidez
Consistencia
Completitud
Realismo

Ingeniera de requisitos

Más contenido relacionado

La actualidad más candente

Similar a Ingeniera de requisitos

Último

Ingeniera de requisitos