Técnicas de Recopilación de Requerimientos (Gestión de Requisitos)
Técnicas de Recopilación de Requerimientos
El descubrimiento de requerimientos es el proceso
de recoger información sobre el sistema propuesto y los existentes y
extraer los requerimientos del usuario y del sistema de esta
información. Las fuentes de información durante la fase del
descubrimiento de requerimientos incluyen la documentación, los
stakeholders del sistema y la especificación de sistemas similares.
Nosotros nos relacionaremos con los stakeholders a través de entrevistas y de la observación y se puede utilizar escenarios y prototipos para ayudar al descubrimiento de requerimientos. Entre los stakeholders podemos encontrar desde los usuarios finales del sistema hasta los gerentes y stakeholders externos como los reguladores, quienes certifican la aceptabilidad del sistema.
Además de los stakeholders del sistema, ya hemos visto que los requerimientos pueden venir del dominio de la aplicación y de otros sistemas que interactúan con el sistema a especificar. Todos estos se deben considerar durante el proceso de obtención de requerimientos. Estas fuentes de requerimientos (stakeholders, dominio, sistemas) se pueden representar como puntos de vista del sistema, donde cada uno presenta un subconjunto de requerimientos para el sistema. Cada punto de vista proporciona una perspectiva nueva en el sistema, pero estas no son completamente independientes. Por lo general coinciden parcialmente, por lo que tienen requerimientos comunes.
Nosotros nos relacionaremos con los stakeholders a través de entrevistas y de la observación y se puede utilizar escenarios y prototipos para ayudar al descubrimiento de requerimientos. Entre los stakeholders podemos encontrar desde los usuarios finales del sistema hasta los gerentes y stakeholders externos como los reguladores, quienes certifican la aceptabilidad del sistema.
Además de los stakeholders del sistema, ya hemos visto que los requerimientos pueden venir del dominio de la aplicación y de otros sistemas que interactúan con el sistema a especificar. Todos estos se deben considerar durante el proceso de obtención de requerimientos. Estas fuentes de requerimientos (stakeholders, dominio, sistemas) se pueden representar como puntos de vista del sistema, donde cada uno presenta un subconjunto de requerimientos para el sistema. Cada punto de vista proporciona una perspectiva nueva en el sistema, pero estas no son completamente independientes. Por lo general coinciden parcialmente, por lo que tienen requerimientos comunes.
PUNTOS DE VISTA
Un
punto clave del análisis orientado a puntos de vista es que reconoce
varias perspectivas y proporcionar un marco de trabajo para descubrir
conflictos en los requerimientos propuestos por diferentes stakeholders.
Los puntos de vista se pueden utilizar como una forma de clasificar los
stakeholders y otras fuentes de requerimientos. Existen tres tipos
genéricos de puntos de vista:
I. Puntos de vista de los interactuadores: representan a las personas u otros sistemas que interactúan directamente con el sistema.
2. Puntos de vista indirectos: representan a los stakeholders que no utilizan el sistema ellos mismos pero que influyen en los requerimientos de algún modo.
3. Puntos de vista del dominio: representan las características y restricciones del dominio que influyen en los requerimientos del sistema.
Por lo general, estos puntos de vista proporcionan diferentes tipos de requerimientos. Los puntos de vista de los interactuadores proporcionan requerimientos detallados del sistema que cubren las características e interfaces del mismo. Los puntos de vista indirectos es más probable que proporcionen requerimientos y restricciones organizacionales de alto nivel.
Los puntos de vista del dominio proporcionan restricciones del dominio que se aplican al sistema. La identificación inicial de los puntos de vista que son relevantes a un sistema a veces puede ser difícil. Para ayudar a este proceso, se debería intentar identificar tipos de puntos de vista más específicos.
Casi todos los sistemas organizacionales deben interactuar con otros sistemas en la organización. Cuando se diseña un sistema nuevo, se deben diseñar las interacciones con los otros sistemas. Las interfaces ofrecidas por estos otros sistemas ya se han diseñado. Estas pueden poner requerimientos y restricciones en el sistema nuevo. Además, los sistemas nuevos se pueden tener que ajustar a las regulaciones y estándares existentes, y estos restringen los requerimientos del sistema.
Se deben identificar los requerimientos no funcionales y de negocio de alto nivel al inicio del proceso de ingeniería de requerimientos. Las fuentes de estos requerimientos pueden ser puntos de vista útiles en un proceso más detallado. Pueden ser capaces de ampliar y desarrollar los requerimientos de alto nivel en requerimientos del sistema más específicos. Los puntos de vista de la ingeniería pueden ser importantes por dos razones.
En primer lugar, los ingenieros que desarrollan el sistema pueden tener experiencia con sistemas similares y sugerir requerimientos a partir de esa experiencia. En segundo lugar, el personal técnico que tiene que administrar y mantener el sistema puede tener requerimientos que ayuden a simplificar el soporte del sistema. Los requerimientos de administración del sistema son cada vez mas importantes debido a que los costes de administración del sistema son una proporción creciente de los costes totales para un sistema.
Finalmente, los puntos de vista que proporcionan requerimientos pueden venir de los departamentos de marketing y asuntos externos en una organización. Esto es especialmente cierto para sistemas basados en web, particularmente sistemas de comercio electrónico y productos software empaquetados. Los sistemas basados en web deben presentar una imagen favorable de la organización además de entregar funcionalidad al usuario. Para productos software, el departamento de marketing debería conocer que características del sistema lo harán más comercializable para los compradores potenciales.
Para cualquier sistema no trivial existe un enorme número de posibles puntos de vista, y es prácticamente imposible obtener requerimientos de todos ellos. Por lo tanto, es importante organizar y estructurar los puntos de vista en una jerarquía. Es probable que los puntos de vista en la misma rama compartan requerimientos comunes.
Una vez que se han identificado y estructurado los puntos de vista, se debe intentar identificar los más importantes y empezar con ellos al descubrir los requerimientos del sistema.
I. Puntos de vista de los interactuadores: representan a las personas u otros sistemas que interactúan directamente con el sistema.
2. Puntos de vista indirectos: representan a los stakeholders que no utilizan el sistema ellos mismos pero que influyen en los requerimientos de algún modo.
3. Puntos de vista del dominio: representan las características y restricciones del dominio que influyen en los requerimientos del sistema.
Por lo general, estos puntos de vista proporcionan diferentes tipos de requerimientos. Los puntos de vista de los interactuadores proporcionan requerimientos detallados del sistema que cubren las características e interfaces del mismo. Los puntos de vista indirectos es más probable que proporcionen requerimientos y restricciones organizacionales de alto nivel.
Los puntos de vista del dominio proporcionan restricciones del dominio que se aplican al sistema. La identificación inicial de los puntos de vista que son relevantes a un sistema a veces puede ser difícil. Para ayudar a este proceso, se debería intentar identificar tipos de puntos de vista más específicos.
Casi todos los sistemas organizacionales deben interactuar con otros sistemas en la organización. Cuando se diseña un sistema nuevo, se deben diseñar las interacciones con los otros sistemas. Las interfaces ofrecidas por estos otros sistemas ya se han diseñado. Estas pueden poner requerimientos y restricciones en el sistema nuevo. Además, los sistemas nuevos se pueden tener que ajustar a las regulaciones y estándares existentes, y estos restringen los requerimientos del sistema.
Se deben identificar los requerimientos no funcionales y de negocio de alto nivel al inicio del proceso de ingeniería de requerimientos. Las fuentes de estos requerimientos pueden ser puntos de vista útiles en un proceso más detallado. Pueden ser capaces de ampliar y desarrollar los requerimientos de alto nivel en requerimientos del sistema más específicos. Los puntos de vista de la ingeniería pueden ser importantes por dos razones.
En primer lugar, los ingenieros que desarrollan el sistema pueden tener experiencia con sistemas similares y sugerir requerimientos a partir de esa experiencia. En segundo lugar, el personal técnico que tiene que administrar y mantener el sistema puede tener requerimientos que ayuden a simplificar el soporte del sistema. Los requerimientos de administración del sistema son cada vez mas importantes debido a que los costes de administración del sistema son una proporción creciente de los costes totales para un sistema.
Finalmente, los puntos de vista que proporcionan requerimientos pueden venir de los departamentos de marketing y asuntos externos en una organización. Esto es especialmente cierto para sistemas basados en web, particularmente sistemas de comercio electrónico y productos software empaquetados. Los sistemas basados en web deben presentar una imagen favorable de la organización además de entregar funcionalidad al usuario. Para productos software, el departamento de marketing debería conocer que características del sistema lo harán más comercializable para los compradores potenciales.
Para cualquier sistema no trivial existe un enorme número de posibles puntos de vista, y es prácticamente imposible obtener requerimientos de todos ellos. Por lo tanto, es importante organizar y estructurar los puntos de vista en una jerarquía. Es probable que los puntos de vista en la misma rama compartan requerimientos comunes.
Una vez que se han identificado y estructurado los puntos de vista, se debe intentar identificar los más importantes y empezar con ellos al descubrir los requerimientos del sistema.
ENTREVISTAS
Las entrevistas
formales o informales con los stakeholders del sistema son parte de la
mayoría de los procesos de la ingeniería de requerimientos. En estas
entrevistas, el equipo de la ingeniería de requerimientos hace preguntas
a los stakeholders sobre el sistema que utilizan y sobre el sistema a
desarrollar. Los requerimientos provienen de las respuestas a estas
preguntas. Las entrevistas pueden ser de dos tipos:
I. Entrevistas cerradas donde los stakeholders responden a un conjunto predefinido de preguntas.
2. Entrevistas abiertas donde no hay un programa predefinido. El equipo de ]a ingeniería de requerimientos examina una seria de cuestiones con los stakeholders del sistema y, por lo tanto, desarrolla una mejor comprensión de sus necesidades.
En la práctica, las entrevistas con los stakeholders normalmente son una mezcla de estos. Las respuestas a algunas preguntas pueden conducir a otras cuestiones que se discuten de una forma menos estructurada. Las discusiones completamente abiertas raramente salen bien; la mayoría de las entrevistas requieren algunas preguntas para empezar y para mantener la entrevista centrada en el sistema a desarrollar.
Las entrevistas sirven para obtener una comprensión general de lo que hacen los stakeholders, como podrían interactuar con el sistema y las dificultades a las que se enfrentan con los sistemas actuales. A la gente le gusta hablar sobre su trabajo y normalmente se alegran de verse implicados en las entrevistas. Sin embargo, no son de tanta utilidad para la comprensión de los requerimientos del dominio de la aplicación.
Es difícil obtener conocimiento del dominio durante las entrevistas debido a dos razones:
1. Todos los especialistas de la aplicación utilizan terminología y lenguaje especifica de un dominio. Es imposible para ellos discutir requerimientos del dominio sin utilizar esta terminología. Normalmente la utilizan de un modo preciso y sutil, por lo que es fácil que la malinterpreten los ingenieros de requerimientos.
2. Cierto conocimiento del dominio es tan familiar para los stakeholders que lo encuentran difícil de explicar o piensan que es tan básico que no merece la pena mencionarlo.
Las entrevistas no son una técnica eficaz para obtener conocimiento sobre los requerimientos y restricciones organizacionales debido a que existen sutiles poderes e influencias entre los stakeholders en la organización. Las estructuras organizacionales publicadas rara vez se corresponden con la realidad de la toma de decisiones en una organización, pero los entrevistados pueden no desear revelar la estructura real en vez de la teórica a un desconocido. En general, la mayoría de la gente es reacia a discutir cuestiones políticas y organizacionales que pueden influir en los requerimientos.
Los entrevistadores eficaces tienen dos características:
1. No tienen prejuicios, evitan ideas preconcebidas sobre los requerimientos y están dispuestos a escuchar. Si el stakeholder propone requerimientos sorprendentes, están dispuestos a cambiar su opinión del sistema.
2. Instan al entrevistado a empezar las discusiones con una pregunta, una propuesta de requerimientos o sugiriendo trabajar juntos en un prototipo del sistema. Decir a la gente “dime lo que quieres” es improbable que cause información de utilidad. La mayoría de la gente encuentra mucho mas fácil hablar en un contexto definido en vez de en términos generales.
La información de la entrevistas complementa otras informaciones sobre el sistema de los documentos, observaciones de los usuarios, etc. Algunas veces, aparte de la información de los documentos, las entrevistas pueden ser la técnica fuente de información sobre los requerimientos del sistema. Sin embargo, las entrevistas por si mismas tienden a omitir información esencial, por lo que deberían ser usadas al lado de otras técnicas de obtención de requerimientos.
I. Entrevistas cerradas donde los stakeholders responden a un conjunto predefinido de preguntas.
2. Entrevistas abiertas donde no hay un programa predefinido. El equipo de ]a ingeniería de requerimientos examina una seria de cuestiones con los stakeholders del sistema y, por lo tanto, desarrolla una mejor comprensión de sus necesidades.
En la práctica, las entrevistas con los stakeholders normalmente son una mezcla de estos. Las respuestas a algunas preguntas pueden conducir a otras cuestiones que se discuten de una forma menos estructurada. Las discusiones completamente abiertas raramente salen bien; la mayoría de las entrevistas requieren algunas preguntas para empezar y para mantener la entrevista centrada en el sistema a desarrollar.
Las entrevistas sirven para obtener una comprensión general de lo que hacen los stakeholders, como podrían interactuar con el sistema y las dificultades a las que se enfrentan con los sistemas actuales. A la gente le gusta hablar sobre su trabajo y normalmente se alegran de verse implicados en las entrevistas. Sin embargo, no son de tanta utilidad para la comprensión de los requerimientos del dominio de la aplicación.
Es difícil obtener conocimiento del dominio durante las entrevistas debido a dos razones:
1. Todos los especialistas de la aplicación utilizan terminología y lenguaje especifica de un dominio. Es imposible para ellos discutir requerimientos del dominio sin utilizar esta terminología. Normalmente la utilizan de un modo preciso y sutil, por lo que es fácil que la malinterpreten los ingenieros de requerimientos.
2. Cierto conocimiento del dominio es tan familiar para los stakeholders que lo encuentran difícil de explicar o piensan que es tan básico que no merece la pena mencionarlo.
Las entrevistas no son una técnica eficaz para obtener conocimiento sobre los requerimientos y restricciones organizacionales debido a que existen sutiles poderes e influencias entre los stakeholders en la organización. Las estructuras organizacionales publicadas rara vez se corresponden con la realidad de la toma de decisiones en una organización, pero los entrevistados pueden no desear revelar la estructura real en vez de la teórica a un desconocido. En general, la mayoría de la gente es reacia a discutir cuestiones políticas y organizacionales que pueden influir en los requerimientos.
Los entrevistadores eficaces tienen dos características:
1. No tienen prejuicios, evitan ideas preconcebidas sobre los requerimientos y están dispuestos a escuchar. Si el stakeholder propone requerimientos sorprendentes, están dispuestos a cambiar su opinión del sistema.
2. Instan al entrevistado a empezar las discusiones con una pregunta, una propuesta de requerimientos o sugiriendo trabajar juntos en un prototipo del sistema. Decir a la gente “dime lo que quieres” es improbable que cause información de utilidad. La mayoría de la gente encuentra mucho mas fácil hablar en un contexto definido en vez de en términos generales.
La información de la entrevistas complementa otras informaciones sobre el sistema de los documentos, observaciones de los usuarios, etc. Algunas veces, aparte de la información de los documentos, las entrevistas pueden ser la técnica fuente de información sobre los requerimientos del sistema. Sin embargo, las entrevistas por si mismas tienden a omitir información esencial, por lo que deberían ser usadas al lado de otras técnicas de obtención de requerimientos.
ESCENARIOS
Normalmente,
las personas encuentran más fácil dar ejemplos de la vida real que
descripciones abstractas. Pueden comprender y criticar un escenario de
cómo podría interactuar con un sistema software. Los ingenieros de
requerimientos pueden utilizar la información obtenida de esta discusión
para formular los requerimientos reales del sistema.
Los escenarios pueden ser especialmente útiles para agregar detalle a un esbozo de la descripción de requerimientos. Son descripciones de ejemplos de las sesiones de interacción.
Cada escenario abarca una o más posibles interacciones. Se han desarrollado varias formas de escenarios, cada una de las cuales proporciona diferentes tipos de información en diferentes niveles de detalle sobre el sistema. Utilizar escenarios para describir requerimientos es una parte fundamental de los métodos ágiles.
El escenario comienza con un esbozo de la interacción y durante la obtención se agregan detalles para crear una descripción completa de esta interacción. De forma general, un escenario puede incluir:
1. Una descripción de lo que esperan el sistema y los usuarios cuando el escenario comienza.
2. Una descripción del flujo normal de eventos en el escenario.
3. Una descripción de lo que puede ir mal y cómo manejarlo.
4. Información de otras actividades que se podrían Ilevar a cabo al mismo tiempo.
5. Una descripción del estado del sistema cuando el escenario termina.
Es posible llevar a cabo de manera informal la obtención de requerimientos basada en escenarios cuando los ingenieros de requerimientos trabajan con los stakeholders en la identificación de escenarios y en la captura de detalles de dichos escenarios. Los escenarios se pueden redactar como texto, complementados por diagramas, fotografías de las pantallas, etc. De forma alternativa, se puede adoptar un enfoque más estructurado, como los escenarios de evento o los casos de uso.
Los escenarios pueden ser especialmente útiles para agregar detalle a un esbozo de la descripción de requerimientos. Son descripciones de ejemplos de las sesiones de interacción.
Cada escenario abarca una o más posibles interacciones. Se han desarrollado varias formas de escenarios, cada una de las cuales proporciona diferentes tipos de información en diferentes niveles de detalle sobre el sistema. Utilizar escenarios para describir requerimientos es una parte fundamental de los métodos ágiles.
El escenario comienza con un esbozo de la interacción y durante la obtención se agregan detalles para crear una descripción completa de esta interacción. De forma general, un escenario puede incluir:
1. Una descripción de lo que esperan el sistema y los usuarios cuando el escenario comienza.
2. Una descripción del flujo normal de eventos en el escenario.
3. Una descripción de lo que puede ir mal y cómo manejarlo.
4. Información de otras actividades que se podrían Ilevar a cabo al mismo tiempo.
5. Una descripción del estado del sistema cuando el escenario termina.
Es posible llevar a cabo de manera informal la obtención de requerimientos basada en escenarios cuando los ingenieros de requerimientos trabajan con los stakeholders en la identificación de escenarios y en la captura de detalles de dichos escenarios. Los escenarios se pueden redactar como texto, complementados por diagramas, fotografías de las pantallas, etc. De forma alternativa, se puede adoptar un enfoque más estructurado, como los escenarios de evento o los casos de uso.
CASOS DE USO
Los casos de uso son una técnica que se basa en escenarios para la obtención de requerimientos.
En su forma más simple, un caso de uso identifica el tipo de interacción y los actores involucrados. El conjunto de casos de uso representa todas las posibles interacciones a representar en los requerimientos del sistema.
Algunas veces existe confusión sobre si un caso de uso es un escenario o, como sugiere Fowler (Fowler y Scott, 1997), un caso de uso encierra un conjunto de escenarios, y cada uno de estos es un hilo único a través del caso de use. Si un escenario incluye múltiples hilos, habrá un escenario para la interacción normal y escenarios adicionales para las posibles excepciones.
Los casos de uso identifican las interacciones particulares con el sistema. Pueden ser documentadas con texto o vinculadas a modelos UML que desarrollan el escenario en más detalle. Los diagramas de secuencia se utilizan a menudo para añadir información a un caso de uso. Estos muestran los actores involucrados en la interacción, los objetos con los que interactúan y las operaciones asociadas con estos objetos.
UML es un estándar de facto para el modelado orientado a objetos, por lo que los casos de uso y la obtención de requerimientos basada en casos de uso se utilizan cada vez más para la obtenci6n de requerimientos.
Los escenarios y los casos de use son técnicas eficaces para obtener requerimientos para los puntos de vista de los interactuadores, donde cada tipo de interacción se puede representar como un caso de uso. También se pueden utilizar conjuntamente con algunos puntos de vista indirectos cuando éstos reciben resultados (como un informe de gestión) del sistema. Sin embargo, debido a que se centran en las interacciones, no son tan eficaces para obtener restricciones y requerimientos de negocio y no funcionales de alto nivel de puntos de vista indirectos o para descubrir requerimientos del domino.
En su forma más simple, un caso de uso identifica el tipo de interacción y los actores involucrados. El conjunto de casos de uso representa todas las posibles interacciones a representar en los requerimientos del sistema.
Algunas veces existe confusión sobre si un caso de uso es un escenario o, como sugiere Fowler (Fowler y Scott, 1997), un caso de uso encierra un conjunto de escenarios, y cada uno de estos es un hilo único a través del caso de use. Si un escenario incluye múltiples hilos, habrá un escenario para la interacción normal y escenarios adicionales para las posibles excepciones.
Los casos de uso identifican las interacciones particulares con el sistema. Pueden ser documentadas con texto o vinculadas a modelos UML que desarrollan el escenario en más detalle. Los diagramas de secuencia se utilizan a menudo para añadir información a un caso de uso. Estos muestran los actores involucrados en la interacción, los objetos con los que interactúan y las operaciones asociadas con estos objetos.
UML es un estándar de facto para el modelado orientado a objetos, por lo que los casos de uso y la obtención de requerimientos basada en casos de uso se utilizan cada vez más para la obtenci6n de requerimientos.
Los escenarios y los casos de use son técnicas eficaces para obtener requerimientos para los puntos de vista de los interactuadores, donde cada tipo de interacción se puede representar como un caso de uso. También se pueden utilizar conjuntamente con algunos puntos de vista indirectos cuando éstos reciben resultados (como un informe de gestión) del sistema. Sin embargo, debido a que se centran en las interacciones, no son tan eficaces para obtener restricciones y requerimientos de negocio y no funcionales de alto nivel de puntos de vista indirectos o para descubrir requerimientos del domino.
ETNOGRAFÍA
Los
sistemas software no existen de forma aislada: se utilizan en un
contexto social y organizacional, y los requerimientos de sistemas
software se pueden derivar y restringir según ese contexto. A menudo,
satisfacer estos requerimientos sociales y organizacionales es crítico
para el éxito del sistema. Una razón de por qué muchos sistemas software
se entregan pero nunca se utilizan es que no se tiene en cuenta
adecuadamente la importancia de este tipo de requerimientos del sistema.
La etnografía es una técnica de observación que se puede utilizar para entender los requerimientos sociales y organizacionales. Un analista se sumerge por si solo en el entorno laboral donde se utilizara el sistema. Observa el trabajo diario y anota las tareas reales en las que los participantes están involucrados. El valor de la etnografía es que ayuda a los analistas a descubrir los requerimientos implícitos que reflejan los procesos reales más que los formales en los que la gente está involucrada.
A menudo, a la gente le resulta muy difícil articular detalles de su propio trabajo debido a que lo asumen como algo completamente natural. Comprenden su propio trabajo pero no su relación con las demás tareas en la organizaci6n. Los factores sociales y organizacionales que afectan a] trabajo, pero que no son obvios para las personas, es posible que s6lo queden claros cuando se fije en ellos un observador imparcial.
Suchman (Suchman, 1987) utilizó la etnografía para estudiar el trabajo de oficina y observó que las prácticas del trabajo real eran macho más ricas, más complejas y más dinámicas que los modelos sencillos supuestos por los sistemas de automatización de oficinas.
La diferencia entre el trabajo supuesto y el real fue la razón más importante de por qué estos sistemas de oficina no han tenido efectos significativos en la productividad.
La etnografía es especialmente efectiva para descubrir dos tipos de requerimientos:
I. Los requerimientos que se derivan de la forma en la que la gente trabaja realmente más que de la forma en la que las definiciones de los procesos establecen que debería trabajar.
2. Los requerimientos que se derivan de la cooperación y conocimiento de las actividades de la gente.
La etnografía se puede combinar con la construcción de prototipos. La etnografía suministra información al desarrollo del prototipo de forma que se requieran menos ciclos de refinamiento. Además, la construcci6n de prototipos se centra en la etnografía para identificar problemas y preguntas que se puedan discutir posteriormente con el etnógrafo.
Los estudios etnográficos pueden revelar los detalles de los procesos críticos que otras técnicas de obtención de requerimientos a menudo olvidan. Sin embargo, puesto que se centran en el usuario final, este enfoque no es apropiado para descubrir los requerimientos organizacionales o del dominio. Los estudios etnográficos no siempre pueden identificar nuevas propiedades que se deban agregar al sistema. Por lo tanto, la etnografía no es un enfoque completo para la obtenci6n de requerimientos por sí mismo, y debe utilizarse para complementar otros enfoques, como el análisis de casos de uso.
La etnografía es una técnica de observación que se puede utilizar para entender los requerimientos sociales y organizacionales. Un analista se sumerge por si solo en el entorno laboral donde se utilizara el sistema. Observa el trabajo diario y anota las tareas reales en las que los participantes están involucrados. El valor de la etnografía es que ayuda a los analistas a descubrir los requerimientos implícitos que reflejan los procesos reales más que los formales en los que la gente está involucrada.
A menudo, a la gente le resulta muy difícil articular detalles de su propio trabajo debido a que lo asumen como algo completamente natural. Comprenden su propio trabajo pero no su relación con las demás tareas en la organizaci6n. Los factores sociales y organizacionales que afectan a] trabajo, pero que no son obvios para las personas, es posible que s6lo queden claros cuando se fije en ellos un observador imparcial.
Suchman (Suchman, 1987) utilizó la etnografía para estudiar el trabajo de oficina y observó que las prácticas del trabajo real eran macho más ricas, más complejas y más dinámicas que los modelos sencillos supuestos por los sistemas de automatización de oficinas.
La diferencia entre el trabajo supuesto y el real fue la razón más importante de por qué estos sistemas de oficina no han tenido efectos significativos en la productividad.
La etnografía es especialmente efectiva para descubrir dos tipos de requerimientos:
I. Los requerimientos que se derivan de la forma en la que la gente trabaja realmente más que de la forma en la que las definiciones de los procesos establecen que debería trabajar.
2. Los requerimientos que se derivan de la cooperación y conocimiento de las actividades de la gente.
La etnografía se puede combinar con la construcción de prototipos. La etnografía suministra información al desarrollo del prototipo de forma que se requieran menos ciclos de refinamiento. Además, la construcci6n de prototipos se centra en la etnografía para identificar problemas y preguntas que se puedan discutir posteriormente con el etnógrafo.
Los estudios etnográficos pueden revelar los detalles de los procesos críticos que otras técnicas de obtención de requerimientos a menudo olvidan. Sin embargo, puesto que se centran en el usuario final, este enfoque no es apropiado para descubrir los requerimientos organizacionales o del dominio. Los estudios etnográficos no siempre pueden identificar nuevas propiedades que se deban agregar al sistema. Por lo tanto, la etnografía no es un enfoque completo para la obtenci6n de requerimientos por sí mismo, y debe utilizarse para complementar otros enfoques, como el análisis de casos de uso.
CUESTIONARIOS
Es
un conjunto de preguntas que deben ser contestadas por escrito por una
determinada población, generalmente esta población es amplia. Según el
contenido de los cuestionarios podemos clasificarlos en los siguientes
tipos:
1. Abiertos: Las respuestas no están delimitadas, esto permite
mayor libertad de expresión.
2. Cerrados: Se fuerza a respuestas
concretas. Un mismo tipo de pregunta puede formularse para obtener
diferente rango de respuestas: Elección exclusiva (respuestas del tipo
si/no). Por ejemplo: ¿Cree que existen muchos circuitos integrados
defectuosos? Escala cualitativa (acuerdo/desacuerdo). Por ejemplo:
Existen muchos circuitos integrados defectuosos. Las posibles respuestas
son: de acuerdo, totalmente de acuerdo, no estoy seguro, en desacuerdo,
totalmente en desacuerdo. Cantidad, es decir, la pregunta requiere como
respuesta una determinada cantidad. Por ejemplo: De cada 100 circuitos
integrados ¿cuántos son defectuosos? Rango o escala cuantitativa, donde
la respuesta es un rango de valores. Por ejemplo: De cada 100 circuitos
integrados son defectuosos (0–5, 6–10, >50, etc.) Selección de
respuestas limitadas. Por ejemplo: Las causas más frecuentes de
circuitos integrados defectuosos son:
a) Fallo en la impresión de la
pista.
b) Fallo en la conexión de las patillas.
c) Fallo en el
encapsulado de plástico.
3. Mixtos: una combinación de los anteriores
Los buenos cuestionarios no solo se escriben sino que se diseñan. Una
buena elaboración acompañada de una prueba previa, tanto del formato
como de las preguntas, son la base de una recopilación de datos
significativa a través del cuestionario.
Puntos que ayudarán en la
formulación de un cuestionario:
1. Determinar qué datos necesitan
recabarse y qué personas son las más calificadas para proporcionarlos.
Si hay otros grupos que pueden proporcionar datos variantes y mayor
visión también se identificarán.
2. Seleccionar el tipo de cuestionario a
utilizar (abierto, cerrado o mixto).
3. Desarrollar un grupo de
preguntas para incluirlas en el cuestionario. Las preguntas extras que
son intencionalmente redundantes, pueden ser útiles al asegurar
respuestas consistentes por parte de quien responda.
4. Examinar el
cuestionario para encontrarle fallos y defectos, como:
a) Interrogantes
innecesarias.
b) Preguntas que pueden ser mal interpretadas debido a su
enfoque o forma de escritura.
c) Preguntas que el sujeto posiblemente no
pueda responder, dado que desconoce la respuesta.
d) Preguntas que
están escritas de forma que se escogerá la respuesta preferida.
e)
Preguntas que se interpretarán de forma diferente dependiendo del marco
de referencia de cada entrevistado.
f) Preguntas que no proporcionan
opciones adecuadas de respuesta.
g) Un ordenamiento no adecuado de las
preguntas o respuestas.
5. Probar previamente el cuestionario en un
grupo pequeño de personas, para detectar otros problemas posibles. Así
no solamente se describen los problemas en cuanto a su escritura,
espaciado, ortografía, y métodos de registro de respuestas, sino también
proporciona una indicación del tipo de respuestas que se recopilarán en
un grupo mayor. Si existen muchas respuestas inesperadas, se captarán
durante la prueba previa. Hay que asegurar que la muestra de prueba sea
comparable al grupo mayor que recibirá el cuestionario.
6. Analizar las
respuestas del grupo de prueba para asegurar que el análisis de los
datos que se busca puede llevarse a cabo con el tipo de datos
recopilados. Si estos datos no revelan algo que los analistas no
reconocen y no necesitan verificar, el cuestionario puede no ser
necesario en su forma actual.
7. Realizar cambios finales de edición,
correcciones de mecanografía y ajustes en la forma; entonces imprimir el
cuestionario en una forma limpia y legible.
8. Distribuir el
cuestionario. Cuando sea posible, anotar el nombre de cada persona.
Ventajas
1. En su mayoría, los cuestionarios pueden ser contestados con
rapidez. Los encuestados pueden completar y remitir los cuestionarios
cuando mejor les convenga.
2. Los cuestionarios ofrecen un medio
relativamente económico para recoger datos de un amplio número de
personas.
3. Los cuestionarios permiten a las personas mantener el
anonimato. Por consiguiente, es más probable que éstas informen de los
hechos reales, en vez de decir lo que piensan que su jefe aprobaría que
dijera.
4. Las respuestas pueden incluirse en tablas y analizarse
rápidamente.
Desventajas
1. El número de encuestados es, a menudo,
insuficiente.
2. No existe garantía de que los encuestados respondan o
expliquen todas las preguntas.
3. Los cuestionarios suelen ser poco
flexibles. Impiden que el analista de sistemas obtenga información
voluntaria de las personas o replantee preguntas que puedan haber sido
malinterpretadas.
4. El analista de sistemas no tiene la posibilidad de
observar y analizar el lenguaje corporal del encuestado.
5. No existe
una oportunidad inmediata para aclarar respuestas vagas o incompletas a
una pregunta.
MAPAS MENTALES
Generalmente
cuando se realiza una entrevista -en este caso nosotros- observamos,
escuchamos y tratamos de tomar notas para recordar y definir lo que
estamos escuchando.
Sin embargo frecuentemente sucede que cuando queremos ocupar dicha información, nos cuesta un poco de trabajo darle sentido a esas notas y entenderlas de nuevo. Otro punto en contra de "tomar notas" es el hecho de que no podemos detallar mucho, pues perdemos parte de la información de la entrevista.
Un mapa mental es una forma de tomar notas más completas y extensas. Con los mapas mentales utilizamos símbolos, palabras, imágenes y colores para capturar la esencia del tema que estamos tratando. Al revisarlo después, gracias a la información personalizada, será más fácil recordar detalles que de otra forma se hubieran perdido al tomar nota de forma convencional.
Los mapas mentales no solo funcionan como una forma de enriquecer las notas que tomamos, sino que otra de sus funcionalidades es para realizar un resumen sobre lo que entendimos de una lectura.
Sin embargo frecuentemente sucede que cuando queremos ocupar dicha información, nos cuesta un poco de trabajo darle sentido a esas notas y entenderlas de nuevo. Otro punto en contra de "tomar notas" es el hecho de que no podemos detallar mucho, pues perdemos parte de la información de la entrevista.
Un mapa mental es una forma de tomar notas más completas y extensas. Con los mapas mentales utilizamos símbolos, palabras, imágenes y colores para capturar la esencia del tema que estamos tratando. Al revisarlo después, gracias a la información personalizada, será más fácil recordar detalles que de otra forma se hubieran perdido al tomar nota de forma convencional.
Los mapas mentales no solo funcionan como una forma de enriquecer las notas que tomamos, sino que otra de sus funcionalidades es para realizar un resumen sobre lo que entendimos de una lectura.
LLUVIA DE IDEAS
Es
una técnica de grupo para generar ideas originales en un ambiente
relajado. Esta herramienta creada en el año 1941 por Alex Osborne,
cuando su búsqueda de ideas creativas resultó en un proceso interactivo
de grupo no estructurado de “lluvia de ideas” que generaba más y mejores
ideas que las que los individuos podian producir trabajando de forma
independiente.” NO ESTRUCTURADO (Flujo libre)
1. Escoger a alguien para
que sea el facilitador y apunte las ideas.
2. Escribir en un rotafolio o
en un tablero una frase que represente el problema y el asunto de
discusión.
3. Escribir cada idea en el menor número de palabras posible.
Verificar con la persona que hizo la contribución cuando se esté
repitiendo la idea. No interpretar o cambiar las ideas.
4. Establecer un
tiempo límite.
5. Fomentar la creatividad. Construir sobre las ideas de
otros. Los miembros del grupo de Lluvia de Ideas y el facilitador nunca
deben criticar las ideas.
6. Revisar la lista para verificar su
comprensión.
7. Eliminar las duplicaciones, problemas no importantes y
aspectos no negociables. Llegar a un consenso sobre los problemas que
parecen redundantes o no importantes. ESTRUCTURADO (En círculo) Tiene
las mismas metas que la Lluvia de Ideas No Estructurada. La diferencia
consiste en que cada miembro del equipo presenta sus ideas en un formato
ordenado (ej. de izquierda a derecha). No hay problema si un miembro
del equipo cede su turno si no tiene una idea en ese instante.
SILENCIOSA (lluvia de ideas escritas) Es similar a la Lluvia de Ideas,
los participantes piensan las ideas pero registran en papel sus ideas en
silencio. Cada participante pone su hoja en la mesa y la cambia por
otra hoja de papel. Cada participante puede entonces agregar otras ideas
relacionadas o pensar en nuevas ideas. Este proceso continua por cerca
de 30 minutos y permite a los participantes construir sobre las ideas de
otros y evitar conflictos o intimidaciones por parte de los miembros
dominantes.
PROTOTIPOS
Los
prototipos constituyen la manera más fácil de validar los
requerimientos del sistema dado que el usuario puede trabajar sobre un
elemento concreto y no abstracto como son los modelos. Según el área de
aplicación que se esté analizando el prototipo puede ser distinto. Por
ejemplo, en el caso de una aplicación interactiva la descripción de la
funcionalidad podría realizarse mediante la presentación de las
pantallas, menús, diálogos, etc. En el caso de una aplicación de
procesamiento de información el prototipo podría mostrar la información
de entrada y la información de salida, sin detallar, necesariamente, el
algoritmo asociado. En el caso de una aplicación web, el prototipo
podría incluir las páginas del sistema con una simulación de la
navegación deseada.
Cuando se utilizan prototipos para la identificación de los requerimientos del cliente, e incluye una funcionalidad mínima de tal manera que el usuario pueda utilizar el prototipo. Normalmente, durante el proceso de desarrollo, se deben construir varios prototipos. El análisis de requerimientos que debe realizarse previo a la elaboración de los prototipos dependerá exclusivamente de la naturaleza del problema a resolver. Es recomendable que los prototipos sean elaborados exclusivamente para la generación de un conjunto válido de requerimientos; una vez que éstos han sido identificados se deben documentar y continuar con el proceso de desarrollo. Es fundamental encontrar el prototipo adecuado para la presentación ante el cliente.
Cuando se utilizan prototipos para la identificación de los requerimientos del cliente, e incluye una funcionalidad mínima de tal manera que el usuario pueda utilizar el prototipo. Normalmente, durante el proceso de desarrollo, se deben construir varios prototipos. El análisis de requerimientos que debe realizarse previo a la elaboración de los prototipos dependerá exclusivamente de la naturaleza del problema a resolver. Es recomendable que los prototipos sean elaborados exclusivamente para la generación de un conjunto válido de requerimientos; una vez que éstos han sido identificados se deben documentar y continuar con el proceso de desarrollo. Es fundamental encontrar el prototipo adecuado para la presentación ante el cliente.
DESARROLLO CONJUNTO DE APLICACIONES ( JAD )
Técnica que se utiliza para promover la cooperación y el trabajo en
equipo entre usuarios y analistas. Consiste en realizar sesiones en las
que participan usuarios expertos del dominio junto a analistas de
software. La idea es aprovechar la dinámica de grupos aplicando un
proceso de trabajo sistemático y organizado, apoyado por elementos
visuales de comunicación y comprensión de soluciones.
Las razones que sirven de base a JAD son las siguientes:
• Las entrevistas requieren mucho tiempo, no solo en prepararlas y hacerlas sino también en redactar un conjunto de requisitos coherente a partir de opiniones diferentes de los distintos entrevistados.
• Es más difícil apreciar posibles errores en la especificación de requisitos, ya que sólo el analista revisa el documento. En el JAD todo el grupo puede actuar como revisor y detectar defectos.
• El JAD propugna una participación más profunda de los usuarios en el proyecto, hasta tal punto que los usuarios que participan adquieren un cierto sentido de propiedad en el sistema que se construye.
El JAD no se utiliza demasiado, debido a que requiere una mayor organización que las entrevistas y porque el ambiente o los métodos de trabajo convencionales en las empresas no facilitan este tipo de actividades (falta de tiempo, dificultad de coordinación de tanta gente, dificultad para convencer a la dirección, etc.). No obstante las empresas que han implantado este método han informado de importantes ahorros de tiempo en el desarrollo de software, así como de una mayor satisfacción de los usuarios con los sistemas construidos
Las razones que sirven de base a JAD son las siguientes:
• Las entrevistas requieren mucho tiempo, no solo en prepararlas y hacerlas sino también en redactar un conjunto de requisitos coherente a partir de opiniones diferentes de los distintos entrevistados.
• Es más difícil apreciar posibles errores en la especificación de requisitos, ya que sólo el analista revisa el documento. En el JAD todo el grupo puede actuar como revisor y detectar defectos.
• El JAD propugna una participación más profunda de los usuarios en el proyecto, hasta tal punto que los usuarios que participan adquieren un cierto sentido de propiedad en el sistema que se construye.
El JAD no se utiliza demasiado, debido a que requiere una mayor organización que las entrevistas y porque el ambiente o los métodos de trabajo convencionales en las empresas no facilitan este tipo de actividades (falta de tiempo, dificultad de coordinación de tanta gente, dificultad para convencer a la dirección, etc.). No obstante las empresas que han implantado este método han informado de importantes ahorros de tiempo en el desarrollo de software, así como de una mayor satisfacción de los usuarios con los sistemas construidos
TALLERES DE REQUERIMIENTOS
Los requisitos tienen a menudo necesidades 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, 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 para centrarse en el proceso de la definición de
los requisitos y para dirigir la discusión.
BOSQUEJOS
Es una revisión breve (expresada típicamente en palabras y frases en
lugar de oraciones completas) de los puntos principales de un texto,
organizada jerárquicamente de tal forma que los niveles de importancia,
al igual que el orden de las ideas, estén claramente indicados.
Se puede crear un bosquejo formal o informal, primero se debes utilizar las diferentes técnicas para la generación de ideas (la redacción libre, la lluvia de ideas, etcétera) y para la organización de ideas (el mapa semántico). Después puedes hacer el bosquejo. En otras palabras, no es bueno comenzar por el bosquejo, ya que esto puede restringir y limitar la exploración de un tema. Lo que le ayuda a la mayoría de la gente es escribir sus ideas en la forma en que se presentan en lugar de apegarse al orden de las ideas presentadas en un bosquejo. Es decir, primero inicias la generación de ideas; una vez que tengas las ideas y el mensaje, puedes crear el bosquejo con los puntos esenciales que piensas incluir en el texto.
Se puede crear un bosquejo formal o informal, primero se debes utilizar las diferentes técnicas para la generación de ideas (la redacción libre, la lluvia de ideas, etcétera) y para la organización de ideas (el mapa semántico). Después puedes hacer el bosquejo. En otras palabras, no es bueno comenzar por el bosquejo, ya que esto puede restringir y limitar la exploración de un tema. Lo que le ayuda a la mayoría de la gente es escribir sus ideas en la forma en que se presentan en lugar de apegarse al orden de las ideas presentadas en un bosquejo. Es decir, primero inicias la generación de ideas; una vez que tengas las ideas y el mensaje, puedes crear el bosquejo con los puntos esenciales que piensas incluir en el texto.
Comments
Post a Comment