Entrevistas y Levantamiento de Requisitos

Presentación del tema: "Entrevistas y Levantamiento de Requisitos"— Transcripción de la presentación:

1 Entrevistas y Levantamiento de Requisitos
Sergio Ochoa D. Clase 4 - Versión 6.

2 ¿Puedes Leer la Mente? Sergio Ochoa D.

3 ¿Puedes Leer la Mente? Si la respuesta es NO, entonces vas a tener que trabajar duro para identificar y delimitar el problema a resolver. Todo aporta... Las entrevistas son una parte importante de esto. ... También hay otros recursos complementarios: formularios, sistemas legados, etc.

4 Estructura de la Presentación
Introducción Detalles sobre Entrevistas Primera Entrevista Segunda/Tercera Entrevista Entrevistas de Validación Conclusiones

5 Entrevistas: Introducción
Las entrevistas sirven para: Conocer, clarificar, o limitar el problema a resolver. Identificar a los actores involucrados. Construir la confianza cliente-desarrollador. Establecer los requisitos del sistema sin ambigüedades. Validar el trabajo ya hecho. Dar visibilidad al trabajo realizado. Las entrevistas son el primer paso, en el desarrollo de un proyecto de software.

6 Entrevistas: Introducción
En un proyecto chico o en un equipo de trabajo chico (3-7 personas), todos deberíamos conocer y comprender el problema a resolver, y sus implicancias. Aunque tengamos responsabilidades distintas (roles distintos), debemos conocer el problema, de primera mano. Esto no es sólo responsabilidad de los analistas, o del adm. del proyecto. Hay muchas cosas que requieren intuición y buen criterio. Y eso se puede lograr sólo si comprendo el problema y el desafío que éste representa.

7 Entrevistas: Introducción
Hacer una primera entrevista abierta (como para abordar el tema) y revisarla (si es posible en grupo). Hacer una segunda entrevista focalizada, diseñada para sacarle el resto de la información al cliente. Se pueden hacer más entrevistas si es necesario. Haga la MENOR CANTIDAD POSIBLE de entrevistas. … pero TODAS LAS NECESARIAS. Graben las entrevistas.

8 Entrevistas: Introducción
Revisar los ítems más importantes (respecto a los requisitos) con el cliente (se debe obtener un OK explícito – por ej. a través de un ). Validen con los usuarios, los requisitos entregados por el cliente…. Usuarios y clientes deben estar alineados. Usuarios y Clientes deben sentirse parte del proceso. Trabajen rápido y focalizados. Traigan y analicen todos los recursos que puedan: formularios, sistemas legados, manuales de procesos, etc.

9 Entrevistas: Introducción
Este es el proyecto Problema a resolver Req. de Usuarios (Necesidad del Usuario) Lo que el cliente quiere 1º y 2º Entrevista 2º/3º Entrevista en adelante… Contexto Considerar el Contexto Solución de Software (req., diseño, código, pruebas, etc.) Considerar el Problema

10 Detalles sobre Entrevistas
Entre 20’ y 1 hora. Vestirse igual (o similar) al cliente. Dos entrevistadores (máximo). Sólo uno pregunta, el otro toma nota. Llevar una pauta, con las preguntas. Identificar la entrevista: día, hora, tema a tratar, participantes, cargos, etc. Grabar cada entrevista (audio), pero sea sutil. Que el usuario/cliente sepa que las cosas confidenciales no saldrán a la luz. Obtener copia de todos los formularios involucrados en el sistema (si existen).

11 Detalles sobre Entrevistas
Tráiganse el modelo de datos actual (detallado), en caso de existir sistemas legados. Lleven lápiz y papel, aunque no lo use (podría necesitarlo). No usen jerga computacional, ni regionalismos. La puntualidad es fundamental. Traten al cliente con respeto SIEMPRE !!! No traten de demostrar cuánto saben de ésto: La estrella es el Cliente !!!

12 Detalles sobre Entrevistas
Escuchen las opiniones del cliente/usuario, aunque parezcan descabelladas. No repitan las preguntas, siempre primero revise la cinta de sesiones anteriores. Muéstrenle al cliente que ha comprendido su problema. No critiquen las falencias de los actuales sistemas, ni las del personal que lo construyó o que lo opera. Si van a pedir algo adicional que requiere un esfuerzo importante del cliente/usuario, entréguenle algo a cambio. Ganarse a la secretaria del cliente, es casi tan importante como ganarse al cliente.

13 Primera Entrevista Tenga en cuenta todo lo anterior.
Entrevista abierta (guiada por el cliente). Que el cliente diga todo lo que tenga que decir. Ser “Positivo”, hasta conocer más el problema. No prometer nada hasta analizar el problema en detalle. CONTÉNGANSE !!!! La primera entrevista se usa para obtener una idea aproximada del problema a resolver. Normalmente se obtiene mucha basura, por lo que hay que separar la paja, del trigo. Establezca claramente quién será la contraparte en el proyecto, y quiénes serán los interlocutores válidos.

14 Primera Entrevista (cont.)
Trate de traerse toda la documentación que pueda, para poder analizar mejor el problema a resolver, determinar su alcance e implicancias sobre otros sistemas. Entre la información que debe traerse de la 1º entrevista (dentro de lo posible) está: Formularios actuales que se usan en el sistema (o solicitar un screenshot de las pantallas). Documentación de proyectos previos (tanto exitosos como fracasados) Modelo de datos actual. Tipo y cantidad de usuarios del sistema. Recursos de hardware disponibles. Recursos de software que forman parte del ambiente operacional.

15 Primera Entrevista (cont.)
Entre la información que debe traerse de la 1º entrevista (dentro de lo posible) está: Recursos de comunicaciones que forman parte del ambiente operacional Restricciones del desarrollo (plazos, lenguajes de desarrollo o BD a utilizar, browsers usados para Front-End, etc.) Una idea general de los macro- componentes del sistema (2 – 4 comp.), y sus prioridades de desarrollo. Relación entre estos componentes. Nivel de innovación que involucra el proyecto, para la organización.

16 Después de la Primera Entrevista
Entre todos traten de entender el escenario, el problema y la posible solución (de grano grueso)…. O sea, armar el puzzle.

17 Segunda Entrevista (para Clarificar)
Entre 30’ y 1 hora. Entrevista semi-abierta (guiada por el cliente y el entrevistador). La idea es conocer más en detalle los sub- problemas a resolver, el ambiente operacional (en caso de dudas) y las características de los usuarios del sistema. Revisen los puntos críticos identificados en la primera entrevista. Que guíe el entrevistador, pero permitanle al cliente expresar todo lo que tenga que decir. Continúen siendo “positivos”, hasta conocer más el problema. Sin embargo si hay alarmas tempranas, pónganle el aviso al cliente.

18 Segunda Entrevista (para Clarificar)
No prometan nada hasta analizar el problema en detalle…… CONTÉNGANSE !!!! Usen esta entrevista para completar la información relevada y clarificar aspectos oscuros. Lleven la lista de preguntas preparadas... Traten de mantener al cliente en la línea de lo que es relevante. Caractericen a los clientes/usuarios del sistema. Determinen clara y formalmente el compromiso de tiempo de su contraparte!!

19 De la Tercera en Adelante…
Entre 20’ y 35’. Entrevista focalizada (guiada por el entrevistador). Se utiliza para completar/profundizar la información relevada y clarificar aspectos oscuros. Usted debe hacer que el cliente se mantenga en la línea de lo que es relevante. Obtener requisitos de usuarios completos. Hay que IDENTIFICAR EL CORE DEL PROYECTO + las extensiones Sea realista, cueste lo que cueste. No prometer nada que no tengamos la certeza, de que va a poder (o no) realizarse.

20 ¿Qué Cosas Preguntar (por ej.)?
¿Qué debe hacer el sistema?, Determinación de los servicios del sistema. ¿Quiénes y cuántos son los usuarios?, ¿Qué debería hacer cada uno con el sistema? Determinación de los perfiles de usuario del sistema. ¿Qué calidad se espera que tenga el software?. Determinación de los req. de calidad del software. ¿Cuáles son los formularios que actualmente contienen la información a procesar por el sistema? Determinación de datos y servicios básicos a manejar por el sistema.

21 ¿Qué Cosas Preguntar (por ej.)?
¿Cuál es el escenario en el que funcionará el sistema?. Determinación del Ambiente Operacional. ¿Qué datos están involucrados en el sistema?. Determinación del dominio de datos del sistema. ¿Existen restricciones acerca del funcionamiento del software o del proceso de desarrollo del sistema? Determinación de Restricciones. ¿Existen restricciones de tecnologías? Determinación de Restricciones.

22 ¿Qué Cosas Preguntar (por ej.)?
¿Se han hecho sistemas de este tipo antes en la empresa? Determinación del contexto de trabajo. ¿Cómo les ha ido a los desarrolladores? Determinación del contexto de trabajo. ¿Cuáles fueron los principales problemas que encontraron? Determinación del contexto de trabajo. ... Cada una de estas preguntas pueden ser desglosadas en varias ...

23 Entrevistas de Validación…

24 Entrevistas de Validación
El cliente siempre pretende validar al final. Generar un acta de la reunión, con los compromisos / decis. tomadas / resultados de las validaciones… Y que el cliente de su OK explícito. Validar los requisitos conflictivos (al menos una vez). Validar todo lo que usted considere necesario, ... pero con cuidado... Validar el avance del proyecto, a través de prototipos (buenos prototipos !!!). Validen sólo lo que está escrito en los requisitos.... Cualquier otra cosa está fuera de lo que ustedes deben realizar. Sean directos, el tiempo del cliente también vale .... Esfuércense por validar en forma temprana.

25 Entrevistas de Validación
Póngale presión al Cliente… Es por tu propio bien. Instálele el software (prototipo) al cliente, y asegúrese de que los prototipos sean validados. El usuario/cliente SIEMPRE está ocupado, por lo tanto no va a validar nada a menos que usted lo fuerce. El uso de prototipos involucra una etapa de entrenamiento que usted debe ofrecer, e incluir en el presupuesto.

26 Conclusiones Las entrevistas sirven para construir confianza/ acuerdos entre el proveedor y los clientes/usuarios.... aprovéchenlas!!! Prepárense MUY BIEN para cada entrevista... Su imagen y la de su empresa depende en gran medida de ello. Demuestre que usted es serio, y que sabe hacer su trabajo. Demuestre compromiso con el proyecto. Aclare y limite el problema (junto con el cliente)... y luego póngalo por escrito (docum. de requisitos), y que el cliente lo firme!!!

27 Conclusiones Sea cuidadoso al consultar, ... pero no se quede con ninguna duda. Sea efectivo en su trabajo… No pierda tiempo, ni improvise. Documente todos los acuerdos, y ojalá que éstos sean públicos (para clientes/usuarios y desarrolladores). Genere y mantenga una visión compartida del proyecto. No a las justificaciones. No a las críticas.

28 Conclusiones Se debe entregar copia de las minutas de las entrevistas, a todos los participantes. Otra opción es pasar la documentación en limpio, y hacerla firmar por el cliente / usuario. El entrevistador debe ser alguien con buena capacidad de comunicación y habilidades sociales. Debe ser cuidadoso, formal y no impulsivo.

29 Hints para el Proyecto La administración de requisitos se va a llevar con MainReq: Todos los grupos tienen que tener cuenta allí. Usen el CVS que tienen en sus cuentas del curso. Entiendan el contexto y el problema asociado a su proyecto. Clarifiquen y delimiten su proyecto.

30 Hints para el Proyecto Identifiquen los tipos de usuarios que van a tener. Identifiquen los servicios a los que va a acceder cada uno. Cosas a clarificar: Servicios a prestar por el sistema. Dominio de datos sobre el cual se va a trabajar. Revisen los procesos que se van a apoyar. Hagan una lista jerarquizada de requisitos. Establezcan el primer corte (iteración 1) en base a esa lista.