Вы находитесь на странице: 1из 22

IDENTIFICACION DE NECESIDADES DEL CLIENTE

Como los requerimientos se enfocan a describir las necesidades del cliente, para recabarlos hay que obtener la informacin de primera mano. Esto es, mediante entrevistas con el cliente u obteniendo la documentacin que describa la manera que el cliente desea como funcione el sistema de software. Las necesidades y / o requerimientos del cliente evolucionan con el tiempo y cada cambio involucra un costo. Por eso es necesario tener archivada una copia de la documentacin original del cliente, as como cada revisin o cambio que se haga a esta documentacin. Para que la metodologa sea efectiva en los puntos descritos se definen las siguientes actividades que se deben desarrollar para la correcta identificacin de necesidades del cliente:

Obtener y Analizar informacin de las necesidades del cliente


Para hacer una correcta identificacin de los clientes y poder realizar un anlisis de manera asertiva se pueden implementar una serie de tcnicas de acuerdo al cliente con el que se est tratando. Como apoyo a esta etapa la metodologa presenta algunas tcnicas con las que se pueden identificar las necesidades de manera tal que el anlisis sea apropiado para satisfacer las expectativas del cliente. Estas tcnicas se encuentran en Tcnicas para identificar requerimientos.

Definicin del Alcance


La definicin del alcance tiene como propsito describir y delimitar claramente las necesidades del cliente, las cuales pretenden ser cumplidas con el proyecto. Es importante para la definicin del alcance la identificacin de los siguientes aspectos:

o o o o o

Los entregables que hacen parte del alcance . Describir y listar los entregables finales, principalmente los que deben ser aprobados por el cliente. No mencionar documentos propios del proyecto como cronograma, estimaciones, entre otros. Los tipos de datos que estn en el alcance y fuera de l. Los tipo de datos se refieren a la categora del negocio de los entregables tales como datos financieros, datos de ventas, datos de los empleados, etc. Las fuentes de datos (bases de datos) que estn en el alcance y fuera de l. Esto es similar a los tipos de datos, excepto que ahora se est refiriendo a los datos agregados tales como base de datos de Clientes, Contabilidad General, Cuentas por Pagar, Cuentas por Cobrar, etc. reas involucradas en el alcance y fuera de l. En algunos casos, las reas involucradas en el proyecto ayudan a delimitar el alcance. Condiciones fuera del alcance. Como punto de claridad y contraste al describir entregables que no sern creados, qu reas no sern impactadas, qu facilidades y funciones no sern incluidas, entre otros aspectos.

Fuentes de Informacin Claves


Cualquier informacin creada anteriormente debe ser usada como base para definir el alcance de manera ms detallada. Si por alguna razn no se cuenta con suficiente informacin para la definicin del alcance, se debe buscar apoyo con el patrocinador (Usuarios Claves) para reunir informacin adicional. Si se tienen objetivos del proyecto, se recomienda tenerlos en cuenta para ayudar a afinar el alcance. Por definicin, se deben crear uno o ms entregables para cumplir cada objetivo, y definir los entregables del proyecto es uno de los aspectos principales del alcance del proyecto.

Recomendaciones para definir el alcance


Algunas recomendaciones para la definicin del alcance son:

o o o o o
Objetivo

Desarrollar un escrito o documento formal. Detallar claramente qu actividades y procesos son parte del proyecto, es decir, el trabajo que debe ser realizado con el fin de entregar un producto con las caractersticas y especificaciones solicitadas. Definir los criterios que se utilizarn para determinar si el proyecto o fase ha finalizado exitosamente, es decir, los criterios de aceptacin. Al definir el alcance, tener en mente que lo que no est en el alcance est fuera del proyecto. Formalizar la aceptacin del alcance con el cliente.

El alcance marcara la pauta para la toma de decisiones futuras y realizacin de actividades a nivel operativo, adems de:

o o o o o o

Mejorar la precisin en las estimaciones de tiempo, costo y recursos. Facilitar la asignacin clara de recursos y responsabilidades. Definir la lnea base para la medicin del desempeo y control. Identificar, el equipo de proyecto, el cliente, el objetivo final del proyecto y sus entregables Desarrollar y confirmar un entendimiento comn del proyecto entre ambas partes, cliente y equipo de proyecto. Asegurar que el proyecto incluye todo el trabajo requerido y solamente el trabajo requerido para terminar exitosamente.

Entregable de Identificacin de Necesidades


El presente documento ser trabajado de la mano del cliente, principalmente cuando no se cuenta con documentacin previa que sirva como base para aclarar las necesidades del cliente .

Formato MD050 Diseo Funcional

Objetivo Presentar una descripcin de lo que se requiere desde la perspectiva del cliente para resolver la necesidad u oportunidad de mejora identificada. El documento ser trabajado de la mano del cliente.

TECNICAS PARA IDENTIFICAR REQUERIMIENTOS


Existen diferentes herramientas que permiten facilitar la fase de identificacin de requerimientos, puesto que se presta mayor atencin a las necesidades que se identifican en todas las fases del ciclo de vida del sistema; para as obtener un mejor aprovechamiento y entendimiento. Tcnicas que apoyen una correcta identificacin de los requerimientos:

o o o o

Tcnicas generales para la identificacin de requerimientos. Tcnicas especficas para la identificacin de requerimientos. Tcnicas para Identificar Requisitos Funcionales y No Funcionales. Tcnicas de investigacin de los atributos de las necesidades de los clientes

Tcnicas generales para la identificacin de requerimientos


Las tcnicas agrupadas como generales son las que permiten investigar aspectos generales para posteriormente ser especificados con un mayor detalle con el apoyo de tcnicas ms especficas. Estas tcnicas son ms abiertas y requieren ser adecuadamente orientadas para cubrir la informacin que se requiere capturar, es importante que para sacar el mayor provecho de estas tcnicas se debe tener un dialogo lo ms abierto posible entre el rea de desarrollo de software y los clientes.

Entrevistas. Esta tcnica es muy utilizada para la recoleccin de opiniones, criterios o descripciones sobre diferentes actividades. Se lleva a cabo mediante conversaciones estructuradas donde es fundamental que la relacin con el cliente este basada en la confianza para dar a conocer la informacin de la manera ms detallada. Antes de iniciar una entrevista es importante tener en cuenta lo siguiente: (no es obligacin realizarlas todas pero si es recomendable estudiar cuales son las que ms se aplica para cada rea) 1. Estudiar el tipo de personas a las cuales se les realizar la entrevista. 2. Estudiar cmo ser el entorno donde se llevara a cabo la entrevista para identificar que tan confortables estarn las personas y as obtener la informacin de la manera ms eficiente. 3. Estudiar cmo es la manera de hablar de las personas, individualmente o en un equipo de trabajo. 4. Verificar que las personas tengan la disponibilidad para dar a conocer las necesidades. 5. Revisar como es nuestra relacin con el cliente, esto con el fin de facilitar el trabajo y la disposicin de ambas partes. 6. Entender que es importante obtener la mayor informacin para la definicin de los requerimientos, teniendo en cuenta que nada es obvio.

Lluvia de Ideas Esta tcnica es abierta y se utiliza para explorar necesidades iniciales con la ayuda de la identificacin de ideas de todas las personas que hacen parte del equipo de apoyo para la identificacin de los requerimientos. Utilizada para investigar nuevos servicios o necesidades que no son claramente identificadas. Importante tener en cuenta lo siguiente: 1. Preparacin sobre el tema que se va a desarrollar en la lluvia de ideas 2. Escoger un sitio tranquilo que permita que las personas involucradas se sientan cmodas y dispuestas para dar a conocer sus ideas. 3. Tomar la iniciativa para iniciar una reunin enfocada en la confianza. 4. Tomar nota de las ideas que las personas expresan en los equipos de trabajo.

Entrevistas Esta tcnica puede ir dirigida a un pblico especfico o general, lo que permite obtener una informacin mayor, ya que se tiene la posibilidad de involucrar ms personas para el desarrollo de los cuestionarios y que estos tengan diferentes puntos de vista. Lo importante es tener en cuenta que se debe tener un mayor cuidado en la seleccin de los encuestados y de la forma en que se pregunta para obtener respuestas concretas y confiables

Tcnicas especficas para la identificacin de requerimientos.


Las tcnicas agrupadas como especificas son las que permiten complementar las tcnicas generales, para as obtener mayor detalle y eliminar ambigedad en la informacin inicial.

Observacin. Esta tcnica permite obtener informacin directa sobre la forma en que se realizan las actividades. Sirve para revisar que no existen omisiones o interpretaciones errneas sobre el proceso que se realiza. Tener en cuenta que se debe utilizar si el cliente lo permite y si el proyecto as lo amerita.

Escenarios. Esta tcnica permite conocer el comportamiento del producto ante determinados eventos considerando los datos, acciones y excepciones que se pueden presentar. El anlisis de casos de uso es un ejemplo de aplicacin de esta tcnica.

Tcnicas para Identificar Requisitos Funcionales y No Funcionales.

Identificacin de Requerimientos funcionales. Los requerimientos funcionales son declaraciones de los servicios que proveer el sistema, de la manera en que ste reaccionar a entradas particulares. En algunos casos, los requerimientos funcionales de los sistemas tambin declaran explcitamente lo que el sistema no debe hacer. Muchos de los problemas de la ingeniera de software provienen de la imprecisin en la especificacin de requerimientos. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementacin. Sin embargo, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema, retrasando la entrega de ste e incrementando el costo. En principio, la especificacin de requerimientos funcionales de un sistema debe estar completa y ser consistente. La complecin significa que todos los servicios solicitados por el usuario estn definidos. La consistencia significa que los requerimientos no tienen definiciones contradictorias.

En la prctica, para sistemas grandes y complejos, es imposible cumplir los requerimientos de consistencia y complecin. La razn de esto se debe parcialmente a la complejidad inherente del sistema y parcialmente a que los diferentes puntos de vista tienen necesidades inconsistentes. Estas inconsistencias son obvias cuando los requerimientos se especifican por primera vez. Los problemas emergen despus de un anlisis profundo. Una vez que stos se hayan descubierto en las diferentes revisiones o en las fases posteriores del ciclo de vida, se deben corregir en el documento de requerimientos.

Identificacin de Requerimientos no funcionales. Son aquellos requerimientos que no se refieren directamente a las funciones especficas que entrega el sistema, sino a las propiedades emergentes de ste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y la representacin de datos que se utiliza en la interface del sistema. Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones en el presupuesto, a las polticas de la organizacin, a la necesidad de interoperabilidad con otros sistemas de software o hardware o a factores externos como los reglamentos de seguridad, las polticas de privacidad , entre otros. Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones:

Requerimientos del producto. Especifican el comportamiento del producto; como los requerimientos de desempeo en la rapidez de ejecucin del sistema y cunta memoria se requiere; los de fiabilidad que fijan la tasa de fallas para que el sistema sea aceptable; los de portabilidad y los de usabilidad.

Requerimientos organizacionales. Se derivan de las polticas y procedimientos existentes en la organizacin del cliente y en la del desarrollador: estndares en los procesos que deben utilizarse; requerimientos de implementacin como los lenguajes de programacin o el mtodo de diseo a utilizar, y los requerimientos de entrega que especifican cundo se entregar el producto y su documentacin.

Requerimientos externos. Se derivan de los factores externos al sistema y de su proceso de desarrollo. Incluyen los requerimientos de interoperabilidad que definen la manera en que el sistema interacta con los otros sistemas de la organizacin; los requerimientos legales que deben seguirse para asegurar que el sistema opere dentro de la ley, y los requerimientos ticos. Estos ltimos son impuestos al sistema para asegurar que ser aceptado por el usuario.

En la prctica, la especificacin cuantitativa de requerimientos es difcil. A los clientes no les es posible traducir sus metas en requerimientos cuantitativos; para algunas de stas, como las de mantenimiento, no existen mtricas que se puedan utilizar; el costo de verificar de forma objetiva los requerimientos no funcionales cuantitativos es muy alto. En principio, los requerimientos funcionales y no funcionales se diferencian en el documento de requerimientos. En la prctica, esto es difcil. Si un requerimiento no funcional se declara de forma separada a los funcionales, algunas veces es difcil ver la relacin entre ellos. Si se declaran con los requerimientos funcionales, es difcil separar las condiciones funcionales y no funcionales e identificar los requerimientos que se refieren al sistema como un todo. Se debe hallar un balance apropiado que dependa del tipo de sistema a especificar. Sin embargo, los requerimientos que claramente se refieren a las propiedades emergentes del sistema se deben resaltar. Esto se hace colocndolos en una seccin aparte o diferencindolos, de alguna forma, de los otros requerimientos del sistema. Aspectos a tener en cuenta en la identificacin de requerimientos funcionales y no funcionales Requerimientos bsicos, se estructura su identificacin al buscar respuestas a preguntas como: Cul es el proceso bsico de la empresa? Qu datos utiliza o produce este proceso? Cules son los lmites impuestos por el tiempo y la carga de trabajo? Qu controles de desempeo utiliza?

Siempre se debe comenzar con lo bsico. Cuando se hacen preguntas y se reciben respuestas, se proporcionan antecedentes sobre detalles fundamentales relacionados con el sistema y que sirven para describirlo. Las siguientes preguntas son de utilidad para adquirir la comprensin necesaria: Cul es la finalidad de la actividad dentro de la empresa? Qu pasos se siguen para realizarla? Dnde se realizan estos pasos? Quines los realizan? Cunto tiempo tardan en efectuarlos? Con cunta frecuencia lo hacen? Quines emplean la informacin resultante?

Identificacin de elementos, durante esta, se debe identificar muy claramente los siguientes elementos: Procesos Flujos de datos entre procesos Datos de cada flujo de datos Bases de datos Datos de las bases de datos

Preguntas generales: Cuntos empleados laboran para la organizacin en el rea(s) que se pretende desarrollar el sistema; o sea, cuntos tienen relacin directa con el proyecto Cules son las personas claves en el sistema? Por qu son importantes? Existen obstculos o influencias de tipo poltico que afectan la eficiencia del sistema? Existen manuales de procedimientos, polticas o lineamientos de desempeo documentados oficial o no oficialmente?. Si los hay, Se cumplen en forma cabal en el 100% de las ocasiones?, es decir, se respetan dichos procedimientos? Existen mtodos para evadir el sistema?, Por qu se presentan? Qu reas necesitan un control especfico? Qu criterios se emplean para medir y evaluar el desempeo?

Tcnicas de investigacin de los atributos de las necesidades de los clientes


En realidad, quien conoce sus necesidades es el cliente y, consecuentemente, lo que se hace es preguntarle a l sobre cada una de ellas, con el objeto de clasificar y ponderar su importancia. Este proceso de investigacin debe ser suficientemente inteligente para conseguir respuestas que permitan elevar realmente el nivel de competitividad de la solucin buscada. En definitiva, se recomienda escuchar y entender lo que los estudiosos de la calidad llaman la voz del cliente. Bajo una perspectiva de innovacin proactiva, para la identificacin de necesidades, se requieren mtodos en los cuales el cliente pueda compartir su esfera de conocimientos de aplicacin con mayor riqueza y detalle que en los simples informes de reclamacin. Entre estos mtodos estn:

Grupos Focales. Los grupos focales se conforman reuniendo a un grupo seleccionado de clientes, conjuntamente con un moderador que va a conducir un debate de grupo sobre una serie de aspectos y cuestiones concretas en las que se focaliza la discusin. Esta tcnica de investigacin alcanza mayor profundidad que la encuesta y que los informes anteriores. En la reunin se establece, de por s, una relacin de afinidad por la que todas las respuestas giran en torno a la situacin a analizar. El contexto de uso y aplicacin del producto y las caractersticas que se estudian van quedando claros para todos, ms si desde el principio el moderador tiene la habilidad de exponer el propsito de la reunin con nitidez. Se elimina, pues, uno de los problemas de la encuesta. Al mismo tiempo, se consigue ms informacin y de mayor calidad que en los informes. Primero, porque se cuenta con expertos elegidos e identificados, que pueden matizar y contrastar las respuestas entre ellos, aportando puntos de vista especficos de sus mbitos de aplicacin y segundo, porque en todo momento se pueden aclarar dudas y profundizar en el tema hasta lograr su total comprensin. La habilidad para conducir el debate, sugerir y plantear los temas, atemperar las discusiones sobre aspectos banales y centrarla en los relevantes, es una cuestin que va a determinar la cantidad y calidad de la informacin a obtener.

Entrevista Individual. Una tcnica de investigacin ms eficaz que la anterior es la entrevista individual entre un experto del cliente y un entrevistador cualificado del equipo de anlisis. Esta tiene alguna ventaja adicional sobre el grupo focal, como el que se pueden matizar, en un ambiente de mayor privacidad, los aspectos con mayores atributos de impacto. Si el moderador, en el caso de los grupos focales, era importante, el entrevistador juega aqu un papel crtico. No slo tiene que dominar las tcnicas de la entrevista, como el saber preguntar, el crear un clima de cooperacin, sino que, adems debe reunir la experiencia y dominio suficiente sobre el tema a discutir para generar en el cliente una motivacin positiva, en el sentido de que se est tratando de descubrir los conocimientos de uso del producto que pueden realmente incidir en innovaciones que mejoren el rendimiento de su actividad y su satisfaccin

Anlisis Contextual. En la medida en que el conocimiento del cliente cobra importancia para el diseo del nuevo requerimiento, la comprensin de los detalles y particularidades de uso comienza a ser vital para la innovacin proactiva. Con esta tcnica, lo que se hace es, no slo pedir al cliente que cuente su experiencia de uso y responda a las sagaces y hbiles preguntas de los mtodos anteriores, sino que se le solicita, adems, ver cmo utiliza el producto para comprender el porqu de su necesidad y discutir sobre el terreno cada uno de los detalles y particularidades de uso. En esta tcnica de anlisis, la colaboracin del cliente pasa de contar y relatar su experiencia y opinin, desde luego en sus expresiones y en sus propios trminos, a dejar ver al fabricante cmo realmente se construye esa opinin y se acumula esa experiencia.

Clientes Piloto Un mtodo de investigacin ms sofisticado es utilizar clientes piloto. Clientes de alto prestigio y conocimiento que pueden ofrecer un formidable campo de pruebas para el nuevo producto. Claro est que no es fcil encontrar este tipo de clientes piloto, pero tambin es claro que los beneficios de esta tcnica son elevados. Si el cliente es un

colaborador ms a la hora de descubrir atributos de impacto y de mejorar los de rendimiento, se est contando realmente con una ayuda especializada, con una opinin experta, que aconseja y valida diseos, que contrasta y mide rendimientos y que, de alguna manera, se involucra en el desarrollo. Arthur D. Little llama a este tipo de clientes lead adopters y seala algunas condiciones que deben cumplir con ese papel de cliente piloto. En primer lugar, se espera que sean empresas exigentes en aquellos aspectos del producto que se quiere verificar. Se est solicitando que sean ms exigentes que la media de los dems clientes, para estar seguros de que el proceso trata con rigor y profundidad, incluso con severidad, las caractersticas a estudiar. En segundo lugar, se les pide liderazgo en el producto, es decir, se trata de clientes de reconocido prestigio por su conocimiento y experiencia en su campo de actividad. Se induce, pues, que su potencial para aplicar el nuevo producto y sugerir cambios, corregir defectos o completar caractersticas, es elevado. Con la aplicacin de esta tcnica se busca dar el primer paso hacia la tendencia actual de integracin de la empresa en amplias redes de cooperacin. En la red, clientes y proveedores colaboran, no slo en la generacin de valor, sino tambin en su gestin, contribuyendo a crear estructuras operativas eficaces, consistentes y dinmicas con las que afrontar la creciente diversidad y dificultad de los mercados

Entregable de Identificacin de Requerimientos


El presente documento ser trabajado de la mano del cliente, principalmente cuando no se cuenta con documentacin previa que sirva como base para aclarar las necesidades del cliente.

Formato

Objetivo Sugerir las preguntas que permitan detallar el requerimiento.

DEFINICION DE REQUERIMIENTOS
Para tener una buena definicin de requerimientos es necesario realizar una buena identificacin de los mismos, posterior a esto es importante definirlos de manera detallada, donde se involucre la informacin aportada por los usuarios Para realizar una correcta definicin de los requerimientos del proyecto y que stos satisfagan las necesidades verdaderas del cliente, se deben tener en cuenta las siguientes actividades:

Definicin de Requerimientos
Para realizar con xito la definicin de los requerimientos es importante conseguir que los requerimientos sean claramente definidos para minimizar la ambigedad de los requerimientos, para esto es importante tener en cuenta lo siguiente:

o o o

Definir los requerimientos teniendo en cuenta la informacin identificada con la perspectiva del usuario Reutilizar requerimientos, revisando proyectos ya finalizados para ver si contienen material potencialmente reutilizable. La ventaja de esta reusabilidad es que, una vez que un requisito ha sido especificado satisfactoriamente para un producto y que el producto ha tenido xito, el requerimiento no tendr que volverse a inventar, podr ser utilizado las veces que se desee teniendo en cuenta los derechos de autor Se debe documentar los requerimientos de una forma clara y correcta. En la mayora de los proyectos se observa que la documentacin de los requerimientos puede parecer una tarea tediosa, pero es la nica manera de asegurar que la esencia de los requisitos ha sido capturada correctamente, y que esto pueda ser probado.

Clasificacin de Requerimientos

Requerimientos funcionales. Estos requerimientos se utilizan para determinar que har el Software, definiendo las relaciones de su operacin y su implementacin, sin olvidar que deben ser explcitos tambin en lo que el sistema no debe hacer y que validaciones se deben realizar, teniendo en cuenta cual ser el comportamiento del sistema. Los Requerimientos funcionales se pueden dividir en dos puntos de vista: El primero tiene relacin con el usuario, donde se identifica la relacin del usuario con el sistema

desde el punto de vista del mismo; El segundo tiene relacin con el sistema dando respuesta al usuario, es decir desde el punto de vista de lo que realiza el sistema. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementacin. Sin embargo, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema, retrasando la entrega de ste e incrementando el costo. En principio, la especificacin de requerimientos funcionales de un sistema debe estar completa y ser consistente con lo solicitado por el usuario.

Requerimientos no funcionales. Estos requerimientos se basan en las restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estndares, usabilidad, portabilidad, entre otros. Los Requerimientos funcionales son los requerimientos que no se refieren directamente a las funciones especficas que entrega el sistema, sino a las propiedades emergentes de ste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones en el presupuesto, a las herramientas utilizadas, a las polticas de la organizacin, a la necesidad de interoperabilidad con otros sistemas de software o hardware o a factores externos como los reglamentos de seguridad, las polticas de privacidad, etctera.

Los dos tipos de requerimientos especificados son de gran importancia para el desarrollo de una aplicacin en software, por lo tanto siempre deben ser escritos con claridad, contener la mayor especificacin de las necesidades expuestas por el cliente, esto con el fin de tener un soporte base desde el cual se trabajaran y no presentar ambigedades en la definicin y el resultado del producto. La figura a continuacin muestra los inconvenientes que se pueden presentar cunado no se hace una identificacin correcta de los requerimientos.

Verificacin de Requerimientos
Para la verificacin de requisitos se deben aadir criterios de aceptacin por cada requisito, una tarea de la calidad es asegurarse de que cada requisito cumple con los criterios asignados, este criterio es una medida del requisito que lo hace entendible y con capacidad de ser probado.

Para la verificacin de requisitos se debe validar lo siguiente:

Revisin de Requerimientos vs Especificacin


Una vez ya identificado los requerimientos, documentados y verificados se procede a realizar la revisin de los mismos con base a la informacin recolectada con los usuarios del sistema, en esta revisin participa los analistas del equipo de trabajo y los usuarios necesarios para esta revisin de debe chequear que:

Proceso para la verificacin de los requerimientos.

o o o o

Preparar plan de revisin. Estos requerimientos se basan en las restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estndares, usabilidad, portabilidad, entre otros. Documentos de requisitos a revisar. Identificar cules son los documentos de especificacin de requisitos que se va a revisar. Preparar reunin. Se debe confirmar el lugar en el cual realizar la reunin y se deben prepara los materiales necesarios para la reunin (lpices, hojas, elementos visuales etc). Realizar reunin. Se revisa el entendimiento de la especificacin por parte de los interesados y se valida que lo especificado si cumple con la necesidad del cliente y con lo solicitado.

o o o

Identificar de defectos de la especificacin. Si revisa si se encuentran defectos con respecto a lo solicitado o si hace falta alguna especificacin requerida. Realizacin de correcciones a los documentos. Si en la etapa anterior se encuentran defectos en la especificacin el analista del sistema debe realizan las debidas correcciones al documento. Informar modificaciones a los interesados. Una vez los defectos en la especificacin han sido subsanados, se debe enviar un breve resumen informando las tareas realizadas para la correccin de los documentos especificados junto con los documentos corregidos a los participantes en la reunin para dar su aprobacin.

Cierre de los requerimientos. Por ltimo se da por cerrado y entendido la el requerimiento se firma la aprobacin por parte de los interesados y se procede a enviarse un correo con la aprobacin del requerimiento.

GESTIN DE CAMBIOS
La gestin de cambio en los proyectos debe ser una coordinacin planificada de las actividades que conlleve el logro de los objetivos o propsitos comunes a travs de una comunicacin clara y eficiente La gestin de cambio en los proyectos debe ser una coordinacin planificada de las actividades que conlleve el logro de los objetivos o propsitos comunes a travs de una comunicacin clara y eficiente.

IDENTIFICACION CONTROL DE CAMBIOS


Para una correcta identificacin de lo controles de cambios de los requerimientos de las organizaciones de desarrollo de software, se identifican las siguientes actividades:

Anlisis de la Solicitud
La solicitud es recibida del cliente interno o externo, debe ser recibida por parte del lder de implementacin para ser analizada. Puntos importantes para analizar son el Alcance y el Tiempo, esto con el fin de identificar si la solicitud es viable realizarla sobre el mismo requerimiento o si por el contrario es mejor manejarla como un requerimiento nuevo. Con respecto al anlisis con relacin al alcance es recomendable buscar colaboracin con las reas involucradas en la solicitud, para identificar de mejor manera el impacto y los elementos que se ven afectados con la solicitud.

Valorar el cambio
Valorar la factibilidad de la solicitud realizada ya sea por un cliente interno o uno externo. Para ello se deber ir recorriendo todo el rbol de requisitos viendo como les afecta el cambio, y aqu es donde entra la trazabilidad de los requisitos.

Analizar Modificacin
El lder de implementacin debe realizar el anlisis de la solicitud para saber que tanto impacta la modificacin e identificar puntualmente las modificaciones solicitadas que afectan el requerimiento completo y as identificar si el cambio afecta ms de un requerimiento.

Documentar Cambio
Para tener un mejor control sobre los cambios solicitados es recomendable realizar una documentacin clara para evitar ambigedades en las modificaciones que se van a realizar a los requerimientos. Esto para tener un control de las modificaciones que se realizan sobre un documento de requerimiento esto con el fin de mantener informado al grupo de trabajo y al cliente que actualizaciones se han realizado sobre los documentos, cual es la razn del cambio y quien lo aprob.

APROBACION CONTROL DE CAMBIOS


Para una correcta identificacin de los controles de cambios de los requerimientos, se identifican las siguientes actividades:

Aprobar Cambios
Una vez se ha analizado el impacto del cambio, se debe tomar una decisin. Si se acepta el cambio, tras negociarlo con el cliente, se continuar con la actividad de implementar el cambio. En caso contrario, se deber negociar con el cliente el siguiente paso a realizar.

Planear Cambio
Despus de tener una aprobacin formal del cambio aceptado se planea el tiempo necesario y los recursos necesarios para llevar a cabo el cambio aprobado.

Realizar Cambio
Una vez se planea el cambio aprobado se debe realizar las modificaciones necesarias a todos los productos que resulten afectados por dicho cambio.

Revisar Cambio
Una vez se realice el cambio es recomendable hacer una verificacin por parte del lder para identificar que el requerimiento incluye todos los cambios solicitados y que fueron aprobados.

Actualizar Lnea Base


Es recomendable utilizar el nuevo requerimiento como lnea base, esto con el fin de trabajar siempre sobre la ultima versin del requerimiento.

Informar
Una vez se realice la modificacin de la solicitud se debe informar a los interesados que el cambio ya esta realizado para que sea verificado por el cliente.

Entregable Control de Cambios


Como se especific en los puntos anteriores es importante utilizar el documento que apoye a la identificacin de la solicitud realizada por los clientes internos o externos. Esta documentacin no

debe ser ambigua y debe ser validada por las dos partes, el cliente y el rea de desarrollo de software. El formato necesario para la documentacin del control de cambios se encuentra, la ruta establecida para los documentos del rea de desarrollo.

Formato MD050 Diseo Funcional

Objetivo Describir la situacin de cambio solicitada por el cliente.