Tecnicas Efectivas para La Toma de Requerimientos
Tecnicas Efectivas para La Toma de Requerimientos
Tecnicas Efectivas para La Toma de Requerimientos
Enero 2012
Hablando del Desarrollo en Mxico, podemos comenzar diciendo que un gran nmero de los proyectos de desarrollo de sistemas fracasan por no realizar una adecuada denicin, especicacin, y administracin de los requerimientos.
Dentro de esa mala administracin se pueden encontrar factores como la escasa o nula participacin del usuario, lo que puede provocar una pobre definicin de los requerimientos, requerimientos ambiguos o inexactos, aunado a esto la mala administracin de los cambios generados durante la vida del proyecto, que le pega directamente a la duracin del mismo y por ende a la planeacin. Dando como resultado la insatisfaccin del cliente, la extensin de la duracin del proyecto o el fracaso total del mismo. Para conseguir un proyecto de software exitoso debes comprender el mbito del trabajo a realizar, los riesgos en los que se puede incurrir, los recursos requeridos, las tareas a llevar a cabo, el esfuerzo (costo) a consumir y el plan a seguir. Para poder obtener buenos requerimientos, primero debemos definir que son, que los caracteriza y como pueden clasificarse. Hay muchas definiciones de Requerimiento, considero una de las ms completas la siguiente:
Una capacidad necesitada por un usuario para resolver un problema o llevar a cabo un objetivo
Ahora que podemos identificar que es un requerimiento, lo siguiente es ver cules son las caractersticas que debe cumplir.
acerca de la necesidad del requerimiento, se pueden preguntar Qu sera lo peor de no incluirlo? Si no se encuentra una respuesta o cualquier consecuencia, entonces es probable que no sea un requerimiento necesario. completo si no necesita ampliar detalles en su redaccin, es decir, si se proporciona la informacin suficiente para su comprensin. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento
Claro
Necesario Completo
Vericable
Consistente
Priorizado
Correcto
totalmente factible y dentro de presupuesto, calendario y otras restricciones, si se tiene alguna duda de su factibilidad, hay que investigar, generar pruebas de concepto para saber su complejidad y factibilidad, si aun as el requerimiento es no factible hay que revisar la visin del sistema y replantear el requerimiento
Modicable
Factible
Modificable.
nos ayuda a saber el grado de necesidad del mismo Esencial/Critico, Deseado, Opcional Verificable.
organizar de tal forma que cada funcin del sistema se pueda rastrear hasta su conjunto de requerimientos correspondiente. Facilita las pruebas y la validacin del diseo
puede comprobar, entonces Cmo se sabe si se cumpli con l o no? Debe ser posible verificarlo ya sea por inspeccin, anlisis de prueba o demostracin. Cuando se escriba un requerimiento, se deber de determinar los criterios de aceptacin.
Verificable. Si un requerimiento no se
fcil de leer y entender, su redaccin debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.
Ahora, los requerimientos los podemos agrupar en una pirmide de tipos para poderlos explicar:
l de nio ma mi Do oble r
Necesidad
So
Caractersticas
Descripciones en lenguaje del usuario que determinan como espera que el sistema funcione
Requerimientos de Software
Una vez que se tiene la caracterstica y el acuerdo del cliente, se crea la especificacin detallada de los requerimientos que sern cubiertos por el sistema
luc in de lD om ini o
Necesidades
Dentro de la Pirmide de Requerimientos, situados en el punto ms alto, se encuentran las necesidades de los Stakeholders, estn orientadas a oportunidades (problemas) de Negocio las cuales deben de ser cubiertas de forma satisfactoria. Algunas de estas oportunidades desencadenan la realizacin de un sistema de Software.
Caractersticas
(Requerimientos No Funcionales)
Caractersticas o Cualidades que los Stakeholders esperan como parte del comportamiento del sistema de Software. En ocasiones son orientadas al Como en lugar del Que. Las caractersticas proveen mucha informacin acerca de como el sistema debe comportase. Estn relacionados con las caractersticas de calidad del sistema.
Eficiencia
Tiempo Transacciones por segundo Tiempo de Respuesta Tiempo de Operaciones Completas Memoria Principal Memoria Auxiliar Cach
Espacio
Desempeo
Escalabilidad
Requerimientos de Software
(requerimientos funcionales)
Los Requerimientos de Software son las necesidades de los Stakeholders que requiere que el Sistema deba de cumplir de manera Satisfactoria. Son los que definen las funciones que el sistema ser capaz de realizar, describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Es importante que se describa el Qu? y no el Cmo? se deben hacer esas transformaciones. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos, la lgica y gran parte del cdigo del sistema. Una vez que tenemos identificados los tipos de requerimientos que existen, y las caractersticas que deben cumplir, podemos comenzar con la descripcin de las actividades que nos ayudarn a realizar una buena obtencin de requerimientos. No vamos a descubrir el hilo negro, ya est ms que definido el proceso, solo hay que aprender a llevarlo adecuadamente. A este conjunto de actividades de le denomina Ingeniera de Requerimientos, el cual cumple un papel primordial en el proceso de Desarrollo de Software, es la que nos puede apoyar para lograr proyectos exitosos, ya que se enfoca un rea fundamental: la definicin de lo que se desea producir. Su principal tarea consiste en la generacin de especificaciones correctas que describan con claridad, sin ambigedades, en forma consistente y compacta, el comportamiento del sistema. Este proceso comprende cinco actividades de alto nivel:
Obtencin
Anlisis
Especicacin
Vericacin
Aceptacin
Administracin de Requerimientos
1. Obtencin de Requerimientos
Esta fase representa el comienzo de cada ciclo. Es la parte ms importante del proceso ya que todo lo que se obtenga en esta fase ser la base para la construccin del sistema. Aqu, los analistas de requerimientos debern trabajar junto al cliente para descubrir el problema que el sistema debe resolver. Previo a esto es importante que al empezar hagan una definicin de quienes sern los involucrados en la definicin de los requerimientos y sobre todo definir quien ser el encargado de realizar las autorizaciones a los documentos que se obtengan en la fase previo acuerdo con el resto de los involucrados. Esto por lo regular se hace en una junta llamada kick off o de arranque, donde se debe especificar lo siguientes: 1. Objetivo del sistema, y fechas tentativas del inicio y fin del proyecto 2. Presentacin del Equipo de Trabajo 3. Presentacin o definicin de stakeholders (involucrados en la definicin de los requerimientos y lder funcional, que es quien hace la autorizacin de los documentos en nombre de todo el equipo del cliente) 4. Fechas tentativas de reuniones con el cliente (esto se usa cuando es una consultora la que presta el servicio al cliente) Una vez definidos los involucrados en la junta de arranque la siguiente actividad es preparar las sesiones de entrevista, para lo cual es buena idea tener en cuenta las siguientes recomendaciones:
Antes de mantener las reuniones con los clientes y usuarios e identificar los requisitos es fundamental conocer el dominio del problema y los contextos organizacional y operacional, es decir, la situacin actual. Para esto te puedes basar en su pgina de internet, en documentos internos, folletos, sistemas previos, etc. Cabe mencionar que esta tarea es opcional, si el equipo de anlisis ya conoce acerca del dominio del problema podr manejar las reuniones sin problemas. De otra forma esta actividad cobra importancia, porque enfrentarse a un desarrollo sin conocer las caractersticas principales ni el vocabulario propio del cliente suele provocar que el producto final
conozcas las caractersticas de su actividad har que probablemente no entiendas sus necesidades y que su confianza inicial se vea afectada enormemente. Otra cosa importante que debes tener en cuenta y que es una mejor prctica recomendada por el modelo de CMMI es que tengas un repositorio de informacin donde coloques toda la documentacin que se vaya obteniendo del proyecto y manejndola con una nomenclatura que te permita revisar las versiones de los documentos a simple vista.
Identificacin de los usuarios participantes, o ms bien, confirmacin, se supone que esta tarea la realizarnos al iniciar nuestro proyecto. Esta es de las tareas ms importantes, asegrate que los involucrados en la definicin sean realmente los que operan esa parte a definir, con esto ya tienes ganada una buena parte del camino. Otro punto que debes hacer es pasar las fechas tentativas para tener las reuniones de definicin de requerimientos. Dependiendo del tamao del proyecto pueden ser 1, 2 o N juntas de requerimientos. Una cosa importante, trata de que no sean muy largas, mas de 4hrs podra es demasiado. Finalmente preprate para la reunin con todo el material necesario, por ejemplo, puedes llevar hojas de rota folio para cuando quieras ejemplificar una funcionalidad en dibujo, marcadores, presentaciones con informacin que consideres til, cuestionarios preparados, etc. Incluso te puedes preparar con una grabadora, pero para esto es importante que primero le informes al cliente o le preguntes si puedes hacer uso de ella y grabar la sesin. Esto porque hay muchas empresas que consideran su informacin confidencial y luego puede acarrearte problemas. Tambin es importante que definas el objetivo de la entrevista, que definas la informacin que seas obtener, las personas involucradas y hagas la cita con el cliente informndole sobre las personas necesarias para la reunin. Asiste a la reunin con puntualidad, minino 10 minutos antes de la hora pactada.
Cuando estn en la reunin trata de romper el hielo, informa que pretendes tener una junta eficiente y plantea el objetivo de la entrevista, luego al inicial la entrevista presta atencin a lo que dice tu cliente, el contacto visual siempre es importante, trata de no interrumpirlo, una vez que termine de explicarte alguna de sus necesidades parafrasea. Es recomendable que tomes notas, pero si alguien puede acompaarte y tomar las notas mejor. Trata de dar sugerencias de valor a los requerimientos del cliente. Si maneja formularios o reportes no olvides pedirle los formatos. Trata de identificar los riesgos, puntos de negociacin, posibles conflictos que vayan a derivar en ambigedades en los requerimientos y tomar nota de todos aquellos requisitos No funcionales que te defina el cliente con sus comentarios. Al final de la sesin has un mini resumen de los puntos vistos. Hay que agradecer formalmente al entrevistado por su tiempo, hacerle saber que se le mandar una minuta con los acuerdos tomados durante la entrevista y despedirse cordialmente. No te olvides de transcribir cada requerimiento, acuerdo o pendiente en la minuta mencionada. Donde cada pendiente debe tener un responsable y una fecha de entrega /solucin. Enva esta minuta al cliente y en el cuerpo del correo coloca sus pendientes, no olvides darles seguimiento puntual hasta que sean cerrados. Los pasos siguientes son las actividades que debes realizar con el resultado de lo que acabas de obtener:
Inicialmente se deben identificar los actores que interactuarn con el sistema, es decir, aquellas personas u otros sistemas que sern los orgenes o destinos de la informacin que consumir o producir el sistema a desarrollar y que forman su entorno. Anteriormente definidos que es un requerimiento funcional, sabiendo esto, la tarea en esta etapa es identificar los casos de uso (requerimiento funcional) asociados a los actores, con esto obtendremos un listado de requerimientos que posteriormente vamos a desarrollar.
Tambin es importante que retomemos aquellos requerimientos que en un inicio nos parecieron ambiguos para que se los hagamos saber al cliente y se llegue a una definicin clara de los mismos.
Para esta parte te recomiendo darle una revisada a lo que definimos como un requisito no funcional y claro, si tomaste nota de lo que te coment el cliente referente a como quiere que funcione el sistema, que tipo de comunicacin tiene, si quiere que el sistema se desarrolle en alguna plataforma especifica, alguna restriccin de sistema operativo, de ambiente, rapidez, seguridad, usabilidad, modificaciones sencillas, reutilizacin de cdigo, etc.
5. Clasificar requerimientos
En esta etapa, contando ya con requerimientos consistentes, se da un orden de prioridades, de manera tal que las necesidades de alta prioridad pueden ser encaradas primero, lo que permite definirlas y reexaminar los posibles cambios de los requerimientos, antes que los requerimientos de baja prioridad (que tambin pueden cambiar) sean implementados. Durante el desarrollo del sistema, esto permite una disminucin de los costos y ahorro de tiempo en procesamiento de los inevitables cambios de los requerimientos. Para definir las prioridades te debes basar en las necesidades del cliente (es decir, el todos aquellos requerimientos involucrados directamente con el objetivo principal del sistema siempre debe ser prioridad mayor), adems, se debe tener en cuenta el costo y la dependencia entre requerimientos.
2. Anlisis de Requerimientos
Es el segundo paso que nos dicta la Ingeniera de Requerimientos, implica refinar, analizar, y examinar/escudriar los requerimientos obtenidos para asegurar que todos los clientes involucrados entienden lo que pidieron, y para encontrar errores, omisiones y otras deficiencias. En esta etapa se leen los requerimientos, se conceptan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos.
2. Anlisis de Requerimientos
Reducir ambigedades en los requerimientos.
En esta actividad se realizan las tareas que permiten eliminar los trminos que tienen ms de una acepcin, unificando el lxico empleado. Traducir a lenguaje tcnico los requerimientos.
(cont.)
3. Especificacin de Requerimientos
En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle. Se documenta la descripcin completa de las necesidades y funcionalidades del sistema que ser desarrollado; describe el alcance del sistema y la forma como har sus funciones, definiendo los requerimientos funcionales y no funcionales. En la prctica, esta etapa se va realizando conjuntamente con el anlisis, se puede decir que la especificacin es el "pasar en limpio" el anlisis realizado previamente aplicando tcnicas y/o estndares de documentacin.
Elaborar la ERS
4. Verificacin de Requerimientos
La validacin es la etapa final de la IR. Su objetivo es que los analistas se aseguren que los requerimientos especificados son los que realmente quiere el cliente, que estn completos y sean consistentes adems de cumplir con todas las caractersticas de distinguen un buen requerimiento, otro punto de revisin es asegurarse que no se haya omitido ningn requerimiento. Para hacer la verificacin se recomienda primero seleccionar varios revisores de diferentes disciplinas puede ser un analista, arquitecto, o incluso un ingeniero de SW, pero debe ser alguien que est familiarizado con la ingeniera de requerimientos, adems debe tener conocimiento de los estndares de documentacin de la organizacin. Se puede preparar un checklist para la revisin de los requerimientos, esto depender del proyecto que se est manejando. Lo que se debe hacer es realizar revisiones al documento, aplicarles pruebas de escritorio, etc. Aqu un ejemplo de puntos a revisar en los documentos obtenidos: Estn incluidas todas las funcionalidades requeridas por el cliente? (completa). Existen conflictos en los requerimientos? (consistencia) Tiene alguno de los requerimientos ms de una interpretacin? (no ambigua)
10
5. Aceptacin de Requerimientos
Este es un proceso donde los analistas involucrados se renen con el cliente y comienzan a dar una revisin formal al documento, esto es, comienzan a leer y explicar cada requerimiento, incluso se pueden apoyar nuevamente en prototipos en papel para que quede ms claro el funcionamiento, esto con el fin de que todos estn en el mismo entendido de lo que se realizar para cada requerimiento. Una vez que todos estn de acuerdo se hace la aceptacin/aprobacin de la especificacin de requerimientos, se realiza un compromiso formal de que lo contenga la Especificacin ser lo que se construya y se pide al cliente una aprobacin formal va correo electrnico o una firma sobre el documento fsico.
6. Aceptacin de Requerimientos
La administracin de requerimientos se realiza durante todo el proyecto, esto implica llevar un buen control de los cambios, asegurarte de hacerle ver al cliente el impacto en costo y/o el tiempo de entrega del proyecto, pero tambin debes cuidar como pegan estos cambios a los entregables que tienes, segn la etapa donde se den. Otro punto importante es que debes asegurarte de que todas las actividades de tu proyecto se den en tiempo para no causar retrasos en la entrega. Se recomienda tener especial atencin en cuidar las versiones de documentos (en un repositorio como Sharepoint) y cdigo (en alguna herramienta como SourceSafe).
11
Estoy segura que siguiendo estas lneas, tendrs un mejor resultado al nal de tu proyecto de desarrollo.
Si prefieres recibir ayuda profesional y evitar errores en la planeacin financiera y de calidad en tu proyecto de desarrollo, te invito a que nos contactes. Somos una empresa especialista en desarrollo de aplicaciones, base de datos y aplicaciones para Iphone/Ipad. Desarrollamos software basado en Microsoft .net, java y iOS; y para aquellas empresas que slo requieren la contratacin directa de especialistas, proveemos consultores por proyecto, temporales o fijos con experiencia en las tecnologas ms avanzadas para apoyar t estrategia en sistemas de informacin y desarrollo de software.
Contctanos
Interior de la Repblica Mexicana Monterrey, Nuevo Len
facebook.com/northware
Nuestro correo electrnico
twitter.com/northwaremx
info@northware.mx
12
Enero 2012