02 Captura de requisitos

Document Sample
02 Captura de requisitos Powered By Docstoc
					Capitulo 02 Captura de requisitos

              Pablo Gervás
   F. Informática, UCM, octubre 2004
       Sobre trabajo de P.Mejía, I. Sommerville
                  Contenido
•   Qué es la captura de requisitos
•   Ingeniería de requisitos
•   El proceso de captura
•   Técnicas avanzadas
               Problemas
• Los usuarios no saben lo que quieren.
• Un sistema tiene muchos usuarios y
  ninguno tiene una visión de conjunto.
• No saben cómo hacer más eficiente la
  operación en su conjunto
• No saben qué partes de su trabajo pueden
  transformarse en software.
• No saben detallar lo que saben de forma
  precisa.
  Solución tradicional: analistas
Labores
  – obtener una lista de requisitos de cada usuario
  – adquirir una visión de conjunto
  – componer una especificación completa,
    correcta y consistente
Desventajas
  – listas de requisitos son difíciles de comprender
    y de hacer bien
  – difíciles de transformar en especificaciones de
    diseño e implementación
           Objetivos generales
•   Enumerar los requisitos candidatos
•   Comprender el contexto del sistema
•   Capturar requisitos funcionales
•   Capturar requisitos no funcionales
       Requisitos funcionales
• Definen lo que el sistema tiene que hacer,
  los servicios que debe proporcionar al
  usuario
• Describen la funcionalidad del sistema
       Requisitos no funcionales
• Delimitan las condiciones en que el sistema
  presta servicios a los usuarios
  –   Velocidad de respuesta
  –   Ancho de banda requerido
  –   Espacio en memoria o en disco
  –   ....
               Segunda parte
•   Qué es la captura de requisitos
•   Ingeniería de requisitos
•   El proceso de captura
•   Técnicas avanzadas
   Desafíos para la Ingeniería de
             requisitos
– Al informatizar un determinado proceso el propio
  proceso puede sufrir cambios difíciles de predecir.
– Usuarios diferentes tienen requisitos y prioridades
  diferentes. Hay una negociación de cambios en los
  requisitos.
– Los usuarios finales del sistema y la organización que
  paga por el sistema tienen requisitos diferentes.
– El prototipado es necesario para clarificar requisitos
    Definición y especificación de
              requisitos
Definición de Requisitos

1. El Software proporciona significado de representación y acceso a
  archivos externos creados por otras herramientas.

Especificación de Requisitos
1.1 El usuario debe proporcionar facilidades para definir el tipo de archivos externos.
1.2 Cada tipo de archivo externo puede tener una herramienta asociada. La cual, será
    aplicada para el archivo.
1.3 Cada tipo de archivo externo será representado como un icono específico mostrado al
    usuario.
1.4 Las facilidades proporcionadas para la representación del icono en un tipo de archivo
    externo será definido por el usuario.
1.5 Cuando un usuario selecciona una representación de icono de un archivo externo, el
    efecto de la selección es aplicar las herramientas asociadas con el tipo de archivo ex-
    terno al archivo representado por la selección del icono.
           Lectores de requisitos
                       Gerencia de Cliente
Definición de          Usuarios Finales del Sistema
Requisitos             Ingenieros de Clientes
                       Gerencia de Contratistas
                       Arquitectos del Sistema

                       Usuarios Finales del Sistema
Requisitos
                       Ingenieros de Cliente
Especificación de
                       Arquitectos del Sistema
                       Desarrolladores de Software

Especificación de       (Quizá) Ingenieros de Clientes
Software                Arquitectos del Sistema
                        Desarrolladores de Software
El proceso de ingeniería de requisitos
  Estudio de   Análisis de
  Viabilidad   Requisitos

                              Definición de
  Informe de                  Requisitos
  Viabilidad
                                               Especificación
               Modelos del                     de Requisitos
               Sistema
                               Definición de
                               Requisitos
               Documento de
               Requisitos                        Especificación de
                                                 Requisitos
       Documento de requisitos
• Especificación de la conducta externa del
  sistema.
• Especificar los límites de la implementación.
• Fácil de cambiar.
• Sirve como una herramienta de referencia para
  mantenimiento.
         Validación de requisitos
• Demostración de que los Requisitos que definen
  el sistema son lo que el cliente realmente quiere.
• Los costos de errores en los Requisitos son altos,
  por lo cual, la validación es muy importante.
  – reparar un error de Requisito después del desarrollo
    puede resultar en un coste 100 veces mayor que
    reparar un error en la implementación.
• El Prototipado es una técnica importante de la
  validación de Requisitos.
                Qué comprobar
• Validación. ¿Provee al sistema las funciones que mejor
  soporten las necesidades del cliente?
• Consistencia. ¿Existe cualquier conflicto en los
  Requisitos?
• Completo. ¿Están incluidas todas las funciones
  requeridas por el cliente?
• Realismo. ¿Pueden los Requisitos ser implementados
  con la tecnología y el presupuesto disponible?
        Revisión de Requisitos
• Una revisión regular puede ayudar mientras
  la definición de Requisitos está siendo hecha.
• Tanto el cliente como el personal de
  contratistas deben estar involucrados en la
  revisión.
• La revisión debe ser formal (con los
  documentos completos) o informal. Una
  buena comunicación entre desarrolladores,
  clientes y usuarios puede resolver problemas
  en las primeras etapas.
       Evolución de Requisitos
• Es esencial planear posibles cambios en los
  requisitos cuando el sistema sea desarrollado y
  utilizado.
• El documento de requisitos debe ser organizado,
  de tal forma que los cambios en los requisitos
  puedan ser hechos sin tener que re-escribir
  demasiado.
• Las referencias externas deben ser minimizadas y
  las secciones del documento deben ser tan
  modulares como sea posible.
                Tercera parte
•   Qué es la captura de requisitos
•   Ingeniería de requisitos
•   El proceso de captura
•   Técnicas avanzadas
            Qué se pretende
• definir objetos observables
• evaluar el flujo y contenido de la
  información
• definir y elaborar funciones del software
• entender el comportamiento del sistema
• establecer características del interfaz
• descubrir restricciones ocultas
              Delimitar el alcance
La funcionalidad y el rendimiento del sistema se
  deben acotar de manera comprensible y
  concreta (sin ambigüedades).
Describir:
  –   datos y control,
  –   función
  –   rendimiento
  –   restricciones
  –   interfaces
  –   fiabilidad
                     Viabilidad
     •   Tecnología: hay tecnología? se domina? está dentro del
         estado del arte?
     •   Financiera: pueden asumir el coste la organización, el
         coste, el mercado?
     •   Tiempo: llegará al mercado antes que la competencia?
     •   Recursos: qué se va a necesitar? está disponible?
Muy relacionado con la experiencia disponible en
  los proyectos del tipo que se pretenda
  desarrollar (si se han hecho muchos, es más
  fácil decidir sobre la viabilidad de una
  propuesta)
       Citado en el Pressman

"Quien hace una pregunta parece ignorante
  durante cinco minutos. Quien se la calla
  sigue siéndolo el resto de su vida. "

                     Antiguo proverbio chino
     Una situación en que los participantes...
•   no saben qué decir
•   se preocupan de que se les entienda mal
•   piensan a dónde va a llevar
•   tienen expectativas diferentes
•   quieren que se acabe cuanto antes
•   quieren que sea un éxito

          ¿Una primera cita romántica?
                   No.
      Una entrevista de obtención de requisitos
   Preguntas: sobre el contexto
• Quién solicita este trabajo
• Quién usará el producto
• Cuál es el beneficio económico de una
  solución satisfactoria
• Hay más fuentes para la solución que se
  busca
   Preguntas: sobre el problema
• describir buenos resultados generados por
  una solución buena
• cuál es el problema al que nos enfrentamos
• en qué entorno (describir/mostrar) se va a
  utilizar
• restricciones específicas de rendimiento
Preguntas: sobre la reunión en sí
• es usted la persona adecuada para responder
  a estas preguntas
• son oficiales sus respuestas
• le parecen relevantes mis preguntas
• hago demasiadas preguntas
• hay alguien más que pueda aportar
  información
• hay algo más que debería preguntar
              Limitaciones
• Las reuniones en generales dan resultados
  muy pobres.
• Se deben emplear sólo como primer paso,
  para luego ser sustituidos por reuniones que
  combinen resolución de problemas,
  negociación, y especificación.
                Cuarta parte
•   Qué es la captura de requisitos
•   Ingeniería de requisitos
•   El proceso de captura
•   Técnicas avanzadas
    – FAST
    – QFD
      Facilitated application
 specification techniques (FAST)
• Método específico para gestionar entrevistas
• diseñado para poner a clientes y
  desarrolladores a trabajar en equipo
• hay muchas versiones
• Referencia útil: JAD (Joint Application
  Development)
  www.bee.net/bluebird/jaddoc.htm
                Una reunión
– se celebra en sitio neutral
– asisten clientes y desarrolladores
– hay reglas claras para la preparación y la
  participación
– hay un orden del día, suficientemente formal para que
  se cubra todo, suf. informal para que haya
  flexibilidad
– hay un moderador (cliente o desarrollador)
– hay un mecanismo de definición (pizarra, fichas, ...)
– el objetivo es identificar el problema, especificar
  requisitos básicos de la solución
         Proceso fundamental

– reunión previa con el cliente (alcance y descripción
  básica),
– se redacta una petición de producto (1 o 2 páginas),
– se convoca una reunión FAST,
– se elige un moderador,
– se reparte la petición de producto a todos los
  asistentes
        Deberes para la reunión
Cada asistente tiene que traer preparado a la
 reunión las siguientes listas:
  – objetos (forman parte del entorno del sistema,
    producidos por el sistema, utilizados por el sistema)
  – servicios
  – restricciones (coste, tamaño, reglas de negocio)
  – criterios de rendimiento
Las listas no tienen que ser exhaustivas pero
  deben reflejar la visión que cada uno tiene del
  sistema
     Primera fase de la reunión
• en la reunión se exponen las listas para un
  área concreta
• en este punto no se admiten críticas ni
  discusión
• se elabora una lista combinada
• cuando están las listas combinadas para
  todas las áreas, se acuerda una versión
  negociada de cada una
       Segunda fase de la reunión
• se separan los asistentes por equipos
• cada uno se encarga de hacer una mini
  especificación de unas cuantas propuestas de la
  lista
• cada equipo presenta su mini especificación a
  todos los participantes
• en función de eso se rehacen las listas
• se asigna a alguien la tarea de redactar un
  documento de especificación
    Quality Function Deployment
• Astilleros de Kobe, Mitsubishi Heavy Industries,
  años 70
• Maximizar la satisfacción del cliente a base de
  priorizar los requisitos en función de la
  satisfacción que se espera que proporcionen:
  – normal: los que pide el cliente cuando describe lo que
    quiere, si están, el cliente está satisfecho
  – esperado: los que el cliente no menciona pero da por
    sentado que va a encontrar, si no están, habrá
    protestas
  – emocionantes: adiciones que no hacen falta pero que
    harán feliz al cliente
      Direcciones interesantes
• Joint Application Design
  http://www.bee.net/bluebird/jaddoc.htm
• Quality Function Development Institute
  http://www.qfdi.org/
              Referencias
• Pressman, capítulos 10 y 11
• Sommerville, capítulos 5 y 6

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:22
posted:1/14/2012
language:Spanish
pages:38