METODOS PARA LEVANTAR REQUERIMIENTOS DE UN SOFTWARE QUE ES REQUERIMIENTO?

Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo.

Entrevistas
Las entrevistas son un mtodo comn. Por lo general no se entrevista a toda la gente que se relacionar con el sistema, sino a una seleccin de personas que represente a todos los sectores crticos de la organizacin, con el nfasis puesto en los sectores ms afectados o que harn un uso ms frecuente del nuevo sistema. Los requisitos que surgen de las entrevistas a menudo se contradicen unos a otros o se formulan desde la ignorancia de los detalles del funcionamiento del sistema, sus potencialidades, interdependencias o limitaciones; por lo que se debe trabajar con los mismos para corregir sus fallos. Las entrevistas pueden ser personales o grupales. COMO SE APLICA UNA ENTERVISTA 1) PREPARACION DE LA ENTREVISTA: DEDETERMINAR la posicin que ocupa de la organizacin el futuro entrevistado, sus responsabilidades bsicas, actividades, etc. (Investigacin). PREPARAR LAS PREGUNTAS que van a plantearse, y los documentos necesarios (Organizacin). FIJAR UN LIMITE DE TIEMPO y preparar la agenda para la entrevista. (Sicologa). ELEGIR UN LUGAR donde se puede conducir la entrevista con la mayor comodidad (Sicologa). HACER LA CITA con la debida anticipacin (Planeacin). CONDUCCION DE LA ENTREVISTA Explicar con toda amplitud el propsito y alcance del estudio (HONESTIDAD). Explicar la funcin propietaria como analista y la funcin que se espera conferir al entrevistado. (IMPARCIALIDAD). Hacer preguntas especficas para obtener respuestas cuantitativas (HECHOS). Evitar las preguntas que exijan opiniones interesadas, subjetividad y actitudes similares (HABILIDAD). Evitar el cuchicheo y las frases carentes de sentido (CLARIDAD). Ser corts y comedio, abstenindose de emitir juicios de valores. (OBJETIVIDAD). Conservar el control de la entrevista, evitando las divagaciones y los comentarios al margen de la cuestin. Escuchar atentamente lo que se dice, guardndose de anticiparse a las SECUELA DE LA ENTREVISTA Escribir los resultados (Documentacin). Entregar una copia al entrevistado, solicitando su conformacin, correcciones o adiciones. (Profesionalismo). Archivar los resultados de la entrevista para referencia y anlisis posteriores (Documentacin). D) RECABAR DATOS MEDIANTE LA ENTREVISTA La entrevista es una forma de conversacin, no de interrogacin, al analizar las caractersticas de los sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre el sistema, los analistas pueden conocer datos que no estn disponibles en ningn otra forma. DETERMINACION DEL TIPO DE ENTREVISTA La estructura de la entrevista varia. Si el objetivo de la entrevista radica en adquirir informacin general, es conveniente elaborar una serie de pregunta sin estructura, con una sesin de preguntas y respuesta libres

2)

3)

4)

5)

Talleres
Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es til la seleccin de un secretario dedicado a la documentacin de la discusin, liberando al analista del negocio para centrarse en el proceso de la definicin de los requisitos y para dirigir la discusin. COMO SE APLICA UN TALLER

1. 2. 3. 4.

Nombre: Taller Estructurado de Requerimientos Descripcin: Reunin especial dedicada a examinar y discutir un grupo de Requerimientos Elementos: Paquete de Requerimientos, Alcance, Comprensin, Confirmacin y Aprobacin de Requerimientos Roles: A. Autor.- El analista de negocio responsable de recolectar los requerimientos. Objetivo: contestar preguntas, escuchar comentarios y sugerencias, realizar cambios a los requerimientos

B. C. D. E. F. 5.

Experto(s).- Persona o personas especializadas en la Solucin. Objetivo: realizar preguntas, escuchar comentarios y sugerencias, analizar informacin, determinar viabilidad Moderador.- Facilitador Neutral. Objetivo: facilitar la sesin, mantener el foco en los requerimientos, imponer la participacin, reglas del juego y disciplina, vigilar el cumplimiento de la agenda, facilitar el proceso de toma de decisiones y consenso Escribano: Persona que registra los resultados de la sesin. Objetivo: Documentar todos los comentarios, sugerencias y asuntos surgidos en la sesin Participantes : Cualquier otra persona involucrada en el proyecto. Objetivo: Leer la documentacin, Presentar y Discutir Comentarios, Realizar Preguntas, Sugerir Cambios a Requerimientos Autorizador: Persona con facultades para aprobar cambios a los requerimientos. Objetivo: Aprobar los Requerimientos durante o al final de la sesin.

Reglas del juego A. Definir cules son las condiciones de la reunin, por ejemplo: no influencia de puestos jerrquicos, participacin activa, la duracin de las discusiones, que se hace si un tema no se resuelve en el tiempo lmite, uso de un parking lotetc.

6.

Entregables A. Qu resultados debe de generar la reunin: requerimientos confirmados y aprobados, minuta de la reunin, relacin de preguntas, supuestos, comentarios, temas pendientes, sugerencias y pendientes del Parking Lot, etc.

Forma de contrato
En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos stos pueden tener centenares de pginas

Prototipos
Un prototipo es una pequea muestra, de funcionalidad limitada, de cmo sera el producto final una vez terminado. Ayudan a conocer la opinin de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.

Casos de uso
Un caso de uso es una tcnica para documentar posibles requisitos, graficando la relacin del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y slo se representa su interaccin con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta prctica es mejorar la comunicacin entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta tcnica se enfrenta a los siguientes peligros potenciales.

A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseo final. Los diseadores tienden a reutilizar el cdigo de los prototipos por temor a perder el tiempo al comenzar otra vez. Los prototipos ayudan principalmente a las decisiones del diseo y de la interfaz de usuario. Sin embargo, no proporcionan explcitamente cules son los requisitos. Los diseadores y los usuarios finales pueden centrarse demasiado en el diseo de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.