METODOS PARA LEVANTAR REQUERIMIENTOS DE UN SOFTWARE ¿QUE ES REQUERIMIENTO?

Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.
Entrevistas
Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más 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 posición que ocupa de la organización el futuro entrevistado, sus responsabilidades básicas, actividades, etc. (Investigación). PREPARAR LAS PREGUNTAS que van a plantearse, y los documentos necesarios (Organización). FIJAR UN LIMITE DE TIEMPO y preparar la agenda para la entrevista. (Sicología). ELEGIR UN LUGAR donde se puede conducir la entrevista con la mayor comodidad (Sicología). HACER LA CITA con la debida anticipación (Planeación). CONDUCCION DE LA ENTREVISTA Explicar con toda amplitud el propósito y alcance del estudio (HONESTIDAD). Explicar la función propietaria como analista y la función que se espera conferir al entrevistado. (IMPARCIALIDAD). Hacer preguntas específicas 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 cortés y comedio, absteniéndose de emitir juicios de valores. (OBJETIVIDAD). Conservar el control de la entrevista, evitando las divagaciones y los comentarios al margen de la cuestión. Escuchar atentamente lo que se dice, guardándose de anticiparse a las SECUELA DE LA ENTREVISTA Escribir los resultados (Documentación). Entregar una copia al entrevistado, solicitando su conformación, correcciones o adiciones. (Profesionalismo). Archivar los resultados de la entrevista para referencia y análisis posteriores (Documentación). D) RECABAR DATOS MEDIANTE LA ENTREVISTA La entrevista es una forma de conversación, no de interrogación, al analizar las características de los sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre el sistema, los analistas pueden conocer datos que no están disponibles en ningún otra forma. DETERMINACION DEL TIPO DE ENTREVISTA La estructura de la entrevista varia. Si el objetivo de la entrevista radica en adquirir información general, es conveniente elaborar una serie de pregunta sin estructura, con una sesión 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 selección de un secretario dedicado a la documentación de la discusión, liberando al analista del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión. COMO SE APLICA UN TALLER

1. 2. 3. 4.

Nombre: Taller Estructurado de Requerimientos Descripción: Reunión especial dedicada a examinar y discutir un grupo de Requerimientos Elementos: Paquete de Requerimientos, Alcance, Comprensión, Confirmación y Aprobación 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

mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. mantener el foco en los requerimientos. Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio. permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. Objetivo: facilitar la sesión.B. Esta técnica se enfrenta a los siguientes peligros potenciales. Casos de uso Un caso de uso es una técnica para documentar posibles requisitos.. Realizar Preguntas. sugerencias y pendientes del “Parking Lot”. participación activa. reglas del juego y disciplina. graficando la relación del sistema con los usuarios u otros sistemas. de funcionalidad limitada. que se hace si un tema no se resuelve en el tiempo límite. Presentar y Discutir Comentarios. comentarios. temas pendientes. se pueden llenar formularios o contratos indicando los requisitos. E. y sólo se representa su interacción con entidades externas. por ejemplo: no influencia de puestos jerárquicos. Definir cuáles son las condiciones de la reunión. de cómo sería el producto final una vez terminado. Forma de contrato En lugar de una entrevista. En sistemas muy complejos éstos pueden tener centenares de páginas Prototipos Un prototipo es una pequeña muestra. Objetivo: Leer la documentación. una vez que ven un prototipo. Objetivo: Aprobar los Requerimientos durante o al final de la sesión. Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Objetivo: realizar preguntas. escuchar comentarios y sugerencias. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado. no proporcionan explícitamente cuáles son los requisitos.Facilitador Neutral. minuta de la reunión. Entregables A. 5. relación de preguntas.     A los directivos. etc. sugerencias y asuntos surgidos en la sesión Participantes : Cualquier otra persona involucrada en el proyecto. C. supuestos. uso de un “parking lot”etc.. Experto(s). Sugerir Cambios a Requerimientos Autorizador: Persona con facultades para aprobar cambios a los requerimientos. vigilar el cumplimiento de la agenda. Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez. determinar viabilidad Moderador. Sin embargo. . la duración de las discusiones.Persona o personas especializadas en la Solución. facilitar el proceso de toma de decisiones y consenso Escribano: Persona que registra los resultados de la sesión. Reglas del juego A. imponer la participación. Qué resultados debe de generar la reunión: requerimientos confirmados y aprobados. El objetivo de esta práctica es mejorar la comunicación entre los usuarios y los desarrolladores. Dado que el propio sistema aparece como una caja negra. Objetivo: Documentar todos los comentarios. D. les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final. F. 6. analizar información.