Determinacin de requisitos

Una de las primeras actividades de un analista es determinar los requisitos comerciales para
un nuevo sistema. Este captulo comienza presentando la definicin de requisitos, un
documento que enumera las capacidades del nuevo sistema. A continuacin, describe cmo
analizar los requisitos utilizando estrategias de anlisis de requisitos y cmo reunir requisitos
mediante entrevistas, sesiones de JAD, cuestionarios, anlisis de documentos y observacin.
El captulo tambin describe un conjunto de requisitos alternativos: tcnicas de
documentacin y describe el documento de propuesta del sistema que rene todo.
INTRODUCCIN
El proceso de desarrollo de sistemas ayuda a una organizacin a pasar del sistema actual (a
menudo llamado el sistema tal como est) al nuevo sistema (a menudo llamado el sistema
futuro). El resultado de la planificacin, discutido en el Captulo 2, es la solicitud del sistema,
que proporciona ideas generales para el sistema futuro, define el alcance del proyecto y
proporciona el plan de trabajo inicial. El anlisis toma las ideas generales en la solicitud del
sistema y las refina en una definicin detallada de requisitos (este captulo), modelos
funcionales (Captulo 4), modelos estructurales (Captulo 5) y modelos de comportamiento
(Captulo 6) que juntos forman la propuesta del sistema. La propuesta del sistema tambin
incluye entregas revisadas de la gestin del proyecto, como el anlisis de factibilidad y el
plan de trabajo (Captulo 2).
El resultado del anlisis, la propuesta del sistema, se presenta al comit de aprobacin, que
decide si el proyecto debe continuar. Si se aprueba, la propuesta del sistema pasa al diseo y
sus elementos (definicin de requisitos y modelos funcionales, estructurales y de
comportamiento) se utilizan como entradas para los pasos del diseo. Esto los refina an ms
y define con mucho ms detalle cmo se construir el sistema.
La lnea entre el anlisis y el diseo es muy borrosa. Esto se debe a que los entregables
creados durante el anlisis son realmente el primer paso en el diseo del nuevo sistema.
Muchas de las principales decisiones de diseo para el nuevo sistema se encuentran en los
resultados del anlisis. Es importante recordar que los resultados del anlisis son realmente
el primer paso en el diseo del nuevo sistema.
En muchos sentidos, porque es aqu donde emergen los principales elementos del sistema, el
paso de determinacin de requisitos es el paso ms crtico de todo el proceso de desarrollo
del sistema. Durante la determinacin de requisitos, el sistema es fcil de cambiar debido a
que se ha hecho poco trabajo todava. A medida que el sistema avanza en el proceso de
desarrollo del sistema, cada vez es ms difcil volver a la determinacin de requisitos y
realizar cambios importantes debido a todo el relanzamiento que est involucrado. Varios
estudios han demostrado que ms de la mitad de todas las fallas del sistema se deben a
problemas con los requisitos. Esta es la razn por la cual los enfoques iterativos de las
metodologas orientadas a objetos son tan efectivos: pequeos lotes de requisitos pueden
identificarse e implementarse en etapas incrementales, lo que permite que el sistema en
general evolucione con el tiempo.
REQUISITOS DETERMINACIN
El propsito de la determinacin de requisitos es convertir la explicacin de alto nivel de los
requisitos comerciales establecidos en la solicitud del sistema en una lista ms precisa de
requisitos que pueden usarse como entradas para el resto del anlisis (creacin de modelos
funcionales, estructurales y de comportamiento)) Esta expansin de los requisitos finalmente
conduce al diseo del sistema.
Definiendo un Requisito
Un requisito es simplemente una declaracin de lo que el sistema debe hacer o qu
caracterstica debe tener. Durante el anlisis, los requisitos se escriben desde la perspectiva
del empresario, y se centran en el "qu" del sistema. Debido a que se enfocan en las
necesidades del usuario comercial, generalmente se denominan requisitos comerciales (y, en
ocasiones, requisitos del usuario). Ms adelante en el diseo, los requerimientos del negocio
evolucionan para volverse ms tcnicos y describen cmo se implementar el sistema. Los
requisitos en el diseo se escriben desde la perspectiva del desarrollador, y generalmente se
denominan requisitos del sistema.
Queremos enfatizar que no existe una lnea en blanco y negro que divida un requerimiento
comercial y un requisito del sistema, y algunas compaas usan los trminos indistintamente.
Lo importante para recordar es que un requisito es una declaracin de lo que el sistema debe
hacer, y los requisitos cambiarn con el tiempo a medida que el proyecto se mueve desde el
inicio hasta la elaboracin y la construccin. Los requisitos evolucionan a partir de
declaraciones detalladas de las capacidades comerciales que un sistema debera tener para
detallar declaraciones sobre la manera tcnica en que se implementarn las capacidades en
el nuevo sistema.
Los requisitos pueden ser de naturaleza funcional o no funcional. Un requisito funcional se
relaciona directamente con un proceso que un sistema tiene que realizar o la informacin que
necesita contener.
Por ejemplo, los requisitos que establecen que un sistema debe tener la capacidad de buscar
el inventario disponible o informar los gastos reales y presupuestados son requisitos
funcionales. Los requisitos funcionales fluyen directamente en la creacin de modelos
funcionales, estructurales y de comportamiento que representa la funcionalidad del sistema
en evolucin (vanse los Captulos 4, 5 y 6).
Los requisitos no funcionales se refieren a las propiedades de comportamiento que el sistema
debe tener, como el rendimiento y la facilidad de uso. La capacidad de acceder al sistema
utilizando un navegador web se considera un requisito no funcional. Los requisitos no
funcionales pueden influir en el resto del anlisis (modelos funcionales, estructurales y de
comportamiento) pero a menudo lo hacen de forma indirecta; los requisitos no funcionales
se utilizan principalmente en el diseo cuando se toman decisiones sobre la base de datos, la
interfaz de usuario, el hardware y el software, y la arquitectura fsica subyacente del sistema.
Los requisitos no funcionales describen una variedad de caractersticas con respecto al
sistema: operativo, de rendimiento, de seguridad y cultural y poltico. Los requisitos
operacionales abordan cuestiones relacionadas con los requisitos fsicos y tcnicos en los que
operar el sistema. Los requisitos de rendimiento abordan cuestiones relacionadas con la
velocidad, la capacidad y la fiabilidad del sistema. Los requisitos de seguridad tratan los
problemas con respecto a quin tiene acceso al sistema y bajo qu circunstancias especficas.
Los requisitos culturales y polticos se refieren a cuestiones relacionadas con los factores
culturales, polticos y legales que afectan al sistema. Estas caractersticas no describen
procesos comerciales o informacin, pero son muy importantes para entender cmo debera
ser el sistema final. Los requisitos no funcionales afectan principalmente las decisiones que
se tomarn durante el diseo de un sistema. Volveremos sobre este tema ms adelante en el
libro cuando analicemos el diseo (vanse los Captulos 9, 10 y 11).
Un rea de desarrollo de sistemas de informacin que se enfoca en diferenciar los requisitos
funcionales y no funcionales es la calidad del software. Se han propuesto muchos modelos
diferentes para medir la calidad del software. Sin embargo, virtualmente todos ellos
diferencian los requisitos funcionales y no funcionales. Desde una perspectiva de calidad, la
calidad funcional se relaciona con el grado en que el software cumple con los requisitos
funcionales, es decir, qu parte del problema real se resuelve con la solucin de software
provista. Mientras que los requisitos no funcionales estn asociados con las dimensiones de
eficiencia, facilidad de mantenimiento, portabilidad, confiabilidad, reutilizacin, capacidad
de prueba y usabilidad. Como se indic anteriormente, las dimensiones no funcionales se
asocian principalmente con el diseo detallado y la implementacin del sistema.
Al considerar el cumplimiento con ISO 9000, las dimensiones de calidad se descomponen
an ms en aquellas que el usuario puede ver (externas) y aquellas que el usuario no puede
ver (internas). Las dimensiones externas no funcionales incluyen eficiencia, confiabilidad y
facilidad de uso, mientras que las dimensiones internas no funcionales incluyen capacidad de
mantenimiento, portabilidad, reutilizacin y capacidad de prueba.
Desde la perspectiva del usuario, las dimensiones externas son ms importantes. Si el sistema
es simplemente demasiado difcil de usar, independientemente de qu tan bien el sistema
resuelva el problema, el usuario simplemente no usar el sistema. En otras palabras, desde la
perspectiva de un usuario, para que un sistema de informacin sea exitoso, el sistema no solo
debe cumplir con la especificacin funcional, sino que tambin debe cumplir con las
especificaciones externas no funcionales. Desde la perspectiva del desarrollador, las
dimensiones internas tambin son importantes. Por ejemplo, dado que los sistemas exitosos
tienden a ser de larga duracin y multiplataforma, tanto las dimensiones de mantenimiento
como las de portabilidad pueden tener implicaciones estratgicas para el sistema que se est
desarrollando. Adems, dados los enfoques de desarrollo gil que se utilizan actualmente en
la industria, el desarrollo de software reutilizable y comprobable.
Tres temas adicionales que han influido en los requisitos del sistema de informacin son los
Ley Sarbanes-Oxley, cumplimiento de COBIT (Objetivos de control para la informacin y
tecnologa relacionada) y cumplimiento del Modelo de madurez de la capacidad. Segn el
sistema que se considere, estos tres temas podran afectar la definicin de los requisitos
funcionales de un sistema, los requisitos no funcionales o ambos. La Ley Sarbanes-Oxley,
por ejemplo, exige requisitos funcionales y no funcionales adicionales. Estos incluyen
preocupaciones de seguridad adicionales (no funcionales) y requisitos de informacin
especficos que la administracin debe proporcionar ahora (funcional). Al desarrollar
sistemas de informacin financiera, los desarrolladores de sistemas de informacin deben
asegurarse de incluir la experiencia de Sarbanes-Oxley en el equipo de desarrollo. Adems,
un cliente podra insistir en el cumplimiento de COBIT o que se haya alcanzado un nivel
especfico de Modelo de Madurez de Capacidades para que la empresa sea considerada como
un posible proveedor para suministrar el sistema bajo consideracin. Obviamente, este tipo
de requisitos se suman a los requisitos no funcionales.
Otro tema reciente que influye en los requisitos para algunos sistemas es la globalizacin.
Por ejemplo, una cadena de suministro de informacin global genera una gran cantidad de
requisitos adicionales no funcionales. Si no existen los entornos operativos necesarios para
que se desarrolle una solucin mvil, es importante adaptar la solucin al entorno local. O
bien, puede no ser razonable esperar implementar una solucin basada en alta tecnologa en
un rea que no cuenta con la infraestructura de comunicaciones y energa necesaria. En
algunos casos, es posible que tengamos que considerar apoyar algunas partes de la cadena de
suministro de informacin global con sistemas manuales en lugar de automatizados.
Los sistemas manuales tienen un conjunto completamente diferente de requisitos que crean
diferentes expectativas de rendimiento y preocupaciones de seguridad adicionales. Adems,
las preocupaciones culturales y polticas son potencialmente primordiales. Un ejemplo
simple que afecta el diseo de las interfaces de usuario es el uso adecuado del color en los
formularios (en una pantalla o papel). Las diferentes culturas interpretan diferentes colores
de forma diferente. En otras palabras, en un entorno empresarial global y multicultural,
abordar las inquietudes culturales va mucho ms all de simplemente tener una interfaz de
usuario multilinge.
Debemos ser capaces de adaptar la solucin global a las realidades locales. Friedman se
refiere a estas preocupaciones como glocalizacin.3 De lo contrario, simplemente crearemos
otro ejemplo de un proyecto de desarrollo de sistema de informacin fallido.
Definicin de requisitos
El informe de definicin de requisitos, por lo general llamado simplemente definicin de
requisitos, es un informe de texto sencillo que simplemente enumera los requisitos
funcionales y no funcionales en un formato de esquema. La Figura 3-1 muestra una definicin
de requisitos de muestra para un sistema de citas para un consultorio mdico tpico. Observe
que contiene requisitos funcionales y no funcionales. Los requisitos funcionales incluyen la
gestin de citas, la produccin de programas y el registro de la disponibilidad de los mdicos
individuales. Los requisitos no funcionales incluyen elementos tales como la cantidad de
tiempo que se espera para almacenar una nueva cita, la necesidad de admitir la impresin
inalmbrica y qu tipos de empleados tienen acceso a las diferentes partes del sistema.
Los requisitos estn numerados en un formato legal o de esquema para que cada requisito
est claramente identificado. Los requisitos se agrupan primero en requisitos funcionales y
no funcionales; dentro de cada uno de esos ttulos, se agrupan por el tipo de requisito no
funcional o por funcin.
A veces, los requisitos comerciales se priorizan en la definicin de requisitos. Pueden
clasificarse como de alta, mediana o baja importancia en el nuevo sistema, o pueden
etiquetarse con la versin del sistema que atender el requisito (por ejemplo, versin 1,
versin 2, versin 3). Esta prctica es particularmente importante cuando se usan
metodologas orientadas a objetos, ya que entregan sistemas de manera incremental.
El objetivo ms obvio de la definicin de requisitos es proporcionar la informacin que
necesitan los otros entregables en el anlisis, que incluye modelos funcionales, estructurales
y de comportamiento, y para apoyar las actividades de diseo. Sin embargo, el objetivo ms
importante de la definicin de requisitos es definir el alcance del sistema. El documento
describe a los analistas exactamente lo que el sistema necesita para terminar. Cuando surgen
discrepancias, el documento sirve como el lugar para buscar una aclaracin.
Determinar los requisitos
La determinacin de los requisitos para la definicin de requisitos es tanto una tarea
empresarial como una tarea de tecnologa de la informacin. En los comienzos de la
informtica, exista la presuncin de que los analistas de sistemas, como expertos en sistemas
informticos, estaban en la mejor posicin para definir cmo debera funcionar un sistema
informtico. Muchos sistemas fallaron porque no abordaban adecuadamente las verdaderas
necesidades comerciales de los usuarios. Poco a poco, la presuncin cambi para que los
usuarios, como expertos en negocios, fueran considerados como la mejor posicin para
definir cmo debera funcionar un sistema informtico. Sin embargo, muchos sistemas no
pudieron ofrecer beneficios de rendimiento porque los usuarios simplemente automatizaron
un sistema ineficiente existente y no pudieron incorporar las nuevas oportunidades que ofrece
la tecnologa.
Por lo tanto, el enfoque ms eficaz es que tanto los empresarios como los analistas trabajen
en conjunto para determinar los requisitos comerciales. A veces, sin embargo, los usuarios
no saben exactamente lo que quieren y los analistas deben ayudarlos a descubrir sus
necesidades. Se ha popularizado un conjunto de estrategias para ayudar a los analistas a
realizar anlisis de problemas, anlisis de causa raz, anlisis de duracin, costos basados en
actividades, evaluacin comparativa informal, anlisis de resultados, anlisis de tecnologa y
eliminacin de actividades. Los analistas pueden usar estas herramientas cuando necesitan
guiar a los usuarios a explicar qu se quiere de un sistema. Estas estrategias funcionan de
manera similar. Ayudan a los usuarios a examinar crticamente el estado actual de los
sistemas y procesos (el sistema tal como est), identifican exactamente qu debe cambiar y
desarrollan un concepto para un nuevo sistema (el sistema futuro).
Si bien estas estrategias permiten al analista ayudar a los usuarios a crear una visin para el
nuevo sistema, no son suficientes para extraer informacin sobre los requisitos comerciales
detallados que se necesitan para construirlo. Por lo tanto, los analistas utilizan una cartera de
tcnicas de recopilacin de requisitos para adquirir informacin de los usuarios. El analista
tiene muchas tcnicas para elegir: entrevistas, cuestionarios, observacin, desarrollo de
aplicaciones conjuntas (JAD) y anlisis de documentos. La informacin recopilada mediante
estas tcnicas se analiza crticamente y se utiliza para elaborar el informe de definicin de
requisitos.
Crear una definicin de requisitos
Crear una definicin de requisitos es un proceso iterativo y continuo mediante el cual el
analista recopila informacin con tcnicas de recopilacin de requisitos (por ejemplo,
entrevistas, anlisis de documentos), analiza crticamente la informacin para identificar los
requisitos empresariales apropiados para el sistema y agrega los requisitos a la definicin de
requisitos informe. La definicin de requisitos se mantiene actualizada para que el equipo de
proyecto y los usuarios comerciales puedan consultarla y obtener una comprensin clara del
nuevo sistema.
Para crear una definicin de requisitos, el equipo del proyecto primero determina los tipos de
requisitos funcionales y no funcionales que recopilarn sobre el sistema (por supuesto, estos
pueden cambiar con el tiempo). Estas se convierten en las secciones principales del
documento. A continuacin, los analistas utilizan una variedad de tcnicas de recopilacin
de requisitos para recopilar informacin y enumeran los requisitos comerciales que se
identificaron a partir de esa informacin. Finalmente, los analistas trabajan con todo el equipo
del proyecto y los usuarios comerciales para verificar, cambiar y completar la lista y ayudar
a priorizar la importancia de los requisitos que se identificaron. Este proceso contina durante
todo el anlisis, y la definicin de requisitos evoluciona con el tiempo a medida que se
identifican nuevos requisitos y a medida que el proyecto pasa a fases posteriores del proceso
unificado. Cuidado: la evolucin de la definicin de requisitos debe ser cuidadosamente
administrada.
El equipo del proyecto no puede seguir agregando a la definicin de requisitos, o el sistema
seguir creciendo y creciendo y nunca se terminar. En cambio, el equipo del proyecto
identifica cuidadosamente los requisitos y evala cules se ajustan al alcance del sistema.
Cuando un requisito refleja una necesidad comercial real pero no est dentro del alcance del
sistema actual o la versin actual, se agrega en una lista de requisitos futuros o se le da una
prioridad baja. La administracin de los requisitos (y el alcance del sistema) es una de las
partes ms difciles de administrar un proyecto.
Problemas del mundo real con la determinacin de los requisitos
Avison y Fitzgerald nos proporcionan una serie de problemas que pueden surgir con respecto
a determinar el conjunto de requisitos con los que se tratar. Primero, el analista podra no
tener acceso al conjunto correcto de usuarios para descubrir el conjunto completo de
requisitos. Esto puede llevar a que los requisitos se omitan, se tergiversen y / o se especifiquen
en exceso. En segundo lugar, la especificacin de los requisitos puede ser inadecuada. Esto
puede ser especialmente cierto con las tcnicas ligeras asociadas con las metodologas giles.
En tercer lugar, algunos requisitos simplemente no se conocen al comienzo de un proceso de
desarrollo. Sin embargo, a medida que se desarrolle el sistema, los usuarios y analistas
obtendrn una mejor comprensin tanto de los problemas de dominio como de la tecnologa
aplicable.
Esto puede causar que se identifiquen nuevos requisitos funcionales y no funcionales y que
los requisitos actuales evolucionen o se cancelen. Las metodologas de desarrollo iterativo e
incremental, como el Proceso unificado y gil, pueden ayudar en este caso. En cuarto lugar,
verificar y validar los requisitos puede ser muy difcil.
ESTRATEGIAS DE ANLISIS DE REQUISITOS
Antes de que el equipo del proyecto pueda determinar qu requisitos son apropiados para un
sistema dado, es necesario que haya una visin clara del tipo de sistema que se crear y el
nivel de cambio que aportar a la organizacin. El proceso bsico de anlisis se divide en tres
pasos: comprender el sistema tal como est, identificar mejoras y desarrollar requisitos para
el sistema futuro.
A veces, el primer paso (es decir, entender el sistema tal como est) se omite o se realiza de
manera superficial. Esto sucede cuando no existe un sistema actual, si el sistema y los
procesos existentes son irrelevantes para el sistema futuro, o si el equipo del proyecto est
utilizando una metodologa de desarrollo gil o RAD en la que el sistema tal como est no se
enfatiza. Las nuevas metodologas RAD, giles y orientadas a objetos, como desarrollo por
etapas, creacin de prototipos, creacin de prototipos desechables, programacin extrema y
Scrum (consulte el Captulo 1) se centran casi exclusivamente en las mejoras y los requisitos
del sistema, y pasan poco tiempo investigando el sistema actual tal como es.
Las estrategias de anlisis de requisitos ayudan al analista a guiar a los usuarios a travs de
los pasos de anlisis para que se pueda desarrollar la visin del sistema. Las estrategias de
anlisis de requisitos y las tcnicas de recopilacin de requisitos van de la mano. Los analistas
utilizan tcnicas de recopilacin de requisitos para recopilar informacin; Las estrategias de
anlisis de requisitos determinan el tipo de informacin que se recopila y cmo se analiza en
ltima instancia. Las estrategias de anlisis de requisitos y la recopilacin de requisitos
suceden simultneamente y son actividades complementarias.
Para mover a los usuarios del sistema tal como est al sistema futuro, un analista necesita
fuertes habilidades de pensamiento crticos. El pensamiento crtico es la capacidad de
reconocer fortalezas y debilidades y reformular una idea en una forma mejorada, y las
habilidades de pensamiento crtico son necesarias para comprender realmente los problemas
y desarrollar nuevos procesos comerciales. Estas habilidades tambin son necesarias para
examinar a fondo los resultados de la recopilacin de requisitos, identificar los requisitos del
negocio y traducir esos requisitos en un concepto para el nuevo sistema.
Anlisis del problema
La tcnica de anlisis de requisitos ms directa (y probablemente la ms utilizada) es el
anlisis de problemas. El anlisis de problemas significa pedirles a los usuarios y gerentes
que identifiquen problemas con el sistema tal como est y que describan cmo resolverlos en
el sistema futuro. La mayora de los usuarios tienen una muy buena idea de los cambios que
les gustara ver, y la mayora es muy elocuente al sugerirlos. La mayora de los cambios
tienden a resolver problemas en lugar de capitalizar las oportunidades, pero esto ltimo
tambin es posible. Las mejoras del anlisis de problemas tienden a ser pequeas e
incrementales (por ejemplo, proporcionan ms espacio para escribir la direccin del cliente,
proporcionan un nuevo informe que actualmente no existe).
Este tipo de mejora a menudo es muy eficaz para mejorar la eficiencia del sistema o la
facilidad de uso. Sin embargo, a menudo solo proporciona mejoras menores en el valor
comercial: el nuevo sistema es mejor que el anterior, pero puede ser difcil identificar
beneficios monetarios significativos del nuevo sistema.
Anlisis de causa raz
Las ideas producidas por el anlisis de problemas tienden a ser soluciones a los problemas.
Todas las soluciones hacen suposiciones sobre la naturaleza del problema, suposiciones que
pueden ser vlidas o no.
En nuestra experiencia, los usuarios (y la mayora de la gente en general) tienden a saltar
rpidamente a las soluciones sin tener en cuenta la naturaleza del problema. Algunas veces
las soluciones son apropiadas, pero muchas veces abordan un sntoma del problema, no el
verdadero problema o la causa raz misma.
Por ejemplo, supongamos que una empresa nota que sus usuarios informan
desabastecimientos de inventario. El costo de desabastecimiento de inventario puede ser
bastante significativo. En este caso, dado que ocurren con frecuencia, los clientes pueden
encontrar otra fuente para los artculos que estn comprando a la empresa. Es en inters de
la empresa determinar la causa subyacente y no simplemente proporcionar una reaccin
instintiva, como aumentar arbitrariamente la cantidad de inventario que se tiene a mano. En
el mundo de los negocios, el desafo radica en identificar la causa raz: pocos problemas del
mundo real son simples. Los usuarios generalmente proponen un conjunto de causas para el
problema bajo consideracin. Las soluciones que los usuarios proponen pueden abordar los
sntomas o las causas raz, pero sin un anlisis cuidadoso, es difcil determinar a cul se
dirige.
El anlisis de la causa raz, por lo tanto, se centra en los problemas, no en las soluciones. El
analista comienza haciendo que los usuarios generen una lista de problemas con el sistema
actual y luego prioricen los problemas en orden de importancia. Comenzando por el ms
importante, los usuarios y / o los analistas generan todas las posibles causas raz de los
problemas. Se investiga cada posible causa raz (empezando por la ms probable o ms fcil
de verificar) hasta que se identifiquen las verdaderas causas raz. Si se identifican posibles
causas raz para varios problemas, primero se deben investigar, porque hay una buena
posibilidad de que sean las verdaderas causas raz que inflen los problemas de los sntomas.
En nuestro ejemplo, hay varias causas posibles:
 Es posible que el proveedor de la empresa no est entregando los pedidos a la empresa de
manera oportuna.
Podra haber un problema con los controles de inventario de la empresa.
El nivel de re orden y las cantidades podran configurarse incorrectamente.
A veces, usar un diagrama jerrquico para representar las relaciones causales ayuda con el
anlisis.
Como muestra la Figura 3-2, hay muchas causas posibles que subyacen a las causas de nivel
superior identificadas. El punto clave en el anlisis de causa raz siempre es desafiar lo obvio.
Anlisis de duracin
El anlisis de duracin requiere un examen detallado de la cantidad de tiempo que lleva
realizar cada proceso en el sistema tal como est. Los analistas comienzan determinando la
cantidad total de tiempo que lleva, en promedio, realizar un conjunto de procesos comerciales
para una entrada tpica. A continuacin, cronometran cada uno de los pasos individuales (o
subprocesos) en el proceso comercial. El tiempo para completar el paso bsico se suma y se
compara con el total del proceso general. Una diferencia significativa entre los dos -y en
nuestra experiencia el tiempo total a menudo puede ser de 10 o incluso 100 veces ms que la
suma de las partes- indica que esta parte del proceso necesita urgentemente una revisin
general.
Por ejemplo, supongamos que los analistas estn trabajando en un sistema hipotecario y
descubren que, en promedio, el banco tarda treinta das en aprobar una hipoteca. A
continuacin, observan cada uno de los pasos bsicos del proceso (por ejemplo, entrada de
datos, verificacin de crdito, bsqueda de ttulos, evaluacin) y descubren que la cantidad
total de tiempo realmente gastada en cada hipoteca es de aproximadamente ocho horas.
Este es un fuerte indicio de que el proceso general est mal roto, ya que lleva treinta das
realizar un da de trabajo.
Estos problemas probablemente ocurren porque el proceso est muy fragmentado. Muchas
personas diferentes deben realizar diferentes actividades antes de que el proceso finalice. En
el ejemplo de la hipoteca, la aplicacin probablemente se encuentra en los escritorios de
muchas personas durante largos perodos de tiempo antes de que se procese.
Los procesos en los que muchas personas trabajan en partes pequeas de las entradas son los
principales candidatos para la integracin de procesos o la paralelizacin. La integracin del
proceso significa cambiar el proceso fundamental para que menos personas trabajen en la
entrada, lo que a menudo requiere cambiar los procesos y volver a capacitar al personal para
realizar una gama ms amplia de tareas. La paralelizacin de procesos significa cambiar el
proceso para que todos los pasos individuales se realicen al mismo tiempo.
Por ejemplo, en el caso de solicitud de hipoteca, probablemente no haya ninguna razn para
que la verificacin de crdito no pueda realizarse al mismo tiempo que la evaluacin y el
control de ttulo.
Costeo basado en actividades
Costeo basado en actividad es un anlisis similar; examina el costo de cada proceso principal
o paso en un proceso comercial en lugar del tiempo empleado. Los analistas identifican los
costos asociados con cada uno de los pasos o procesos funcionales bsicos, identifican los
procesos ms costosos y enfocan sus esfuerzos de mejora en ellos.
Asignar costos es conceptualmente simple. Los analistas simplemente examinan el costo
directo de la mano de obra y los materiales para cada entrada. Los costos de materiales se
asignan fcilmente en un proceso de fabricacin, mientras que los costos de mano de obra
generalmente se calculan en funcin de la cantidad de tiempo invertido en la entrada y el
costo por hora del personal. Sin embargo, como recordar de un curso de contabilidad
gerencial, existen costos indirectos, como alquiler, depreciacin, etc., que tambin se pueden
incluir en los costos de actividad.
Benchmarking informal
El benchmarking se refiere a estudiar cmo otras organizaciones realizan un proceso de
negocios para aprender cmo su organizacin puede hacer algo mejor. La evaluacin
comparativa ayuda a la organizacin al presentar ideas que los empleados quizs nunca hayan
considerado, pero que tienen el potencial de agregar valor.
La evaluacin comparativa informal es bastante comn para los procesos comerciales
orientados al cliente (es decir, los procesos que interactan con el cliente). Con benchmarking
informal, los gerentes y analistas piensan en otras organizaciones o las visitan como clientes
para observar cmo se realiza el proceso de negocios. En muchos casos, el negocio estudiado
puede ser un lder conocido en la industria o simplemente una empresa relacionada.
Anlisis de resultados
El anlisis de resultados se centra en la comprensin de los resultados fundamentales que
proporcionan valor a los clientes. Aunque estos resultados parecen lgicos, a menudo no lo
son. Por ejemplo, considere una compaa de seguros. Uno de sus clientes acaba de sufrir un
accidente automovilstico. Cul es el resultado fundamental desde la perspectiva del cliente?
Tradicionalmente, las compaas de seguro han respondido a esta pregunta asumiendo que
el cliente desea recibir el pago del seguro rpidamente. Para el cliente, sin embargo, el pago
es solo un medio para el resultado real: un automvil reparado. La compaa de seguros
podra beneficiarse extendiendo su visin del proceso comercial ms all de sus lmites
tradicionales para incluir no pagar las reparaciones, pero realizar las reparaciones o contratar
un taller autorizado para hacerlas.
Con este enfoque, los analistas de sistemas alientan a los gerentes y al patrocinador del
proyecto a pretender que son clientes y a pensar cuidadosamente sobre lo que los productos
y servicios de la organizacin les permiten a los clientes hacer y lo que podran permitir que
el cliente haga.
Anlisis de tecnologa
Muchos cambios importantes en los negocios desde el cambio de siglo han sido habilitados
por las nuevas tecnologas. El anlisis de tecnologa comienza haciendo que los analistas y
gerentes desarrollen una lista de tecnologas importantes e interesantes. Luego, el grupo
identifica sistemticamente cmo se podra aplicar cada tecnologa al proceso empresarial e
identifica cmo se beneficiara la empresa. Es importante tener en cuenta que el anlisis de
la tecnologa de ninguna manera implica la adopcin de tecnologa por el bien de la
tecnologa. Ms bien, el enfoque est en usar nuevas tecnologas para cumplir los objetivos
de la organizacin.
Eliminacin de actividad
La eliminacin de la actividad es exactamente lo que parece. Los analistas y los gerentes
trabajan en conjunto para identificar cmo la organizacin podra eliminar cada actividad en
el proceso de negocios, cmo la funcin podra funcionar sin ella y qu efectos pueden
ocurrir. Inicialmente, los gerentes son reacios a concluir que los procesos pueden ser
eliminados, pero este es un ejercicio de fuerza porque deben eliminar cada actividad. En
algunos casos, los resultados son tontos; no obstante, los participantes deben abordar cada
actividad en el proceso comercial.
TCNICAS DE RECOGIDA DE REQUISITOS
Un analista se parece mucho a un detective (y los usuarios de negocios a veces son
sospechosos escurridizos).
l o ella saben que hay un problema que resolver y, por lo tanto, debe buscar pistas que
descubran la solucin. Lamentablemente, las pistas no siempre son obvias (y a menudo se
pasan por alto), por lo que el analista debe notar los detalles, hablar con los testigos y seguir
las pistas al igual que Sherlock Holmes lo hubiera hecho. Los mejores analistas renen a
fondo los requisitos utilizando una variedad de tcnicas y se aseguran de que los procesos
comerciales actuales y las necesidades del nuevo sistema se entiendan bien antes de pasar al
diseo. Los analistas no quieren descubrir ms tarde que tienen los requisitos clave
equivocados: tales sorpresas al final del proceso de desarrollo pueden causar todo tipo de
problemas.
El proceso de recopilacin de requisitos se utiliza para generar apoyo poltico para el
proyecto y establecer confianza entre el equipo del proyecto que construye el sistema y los
usuarios que finalmente elegirn usar o no el sistema. Involucrar a alguien en el proceso
implica que los equipos del proyecto vean a esa persona como un recurso importante y
valoren sus opiniones. Todos los interesados clave (las personas que pueden afectar el
sistema o quin se ver afectado por el sistema) deben incluirse en el proceso de recopilacin
de requisitos. Las partes interesadas pueden incluir gerentes, empleados, miembros del
personal e incluso algunos clientes y proveedores. Si una persona clave no est involucrada,
esa persona puede sentirse desairada, lo que puede causar problemas durante la
implementacin (por ejemplo, cmo pudieron haber desarrollado el sistema sin mi aporte?).
El segundo desafo de la recopilacin de requisitos es elegir la forma en que se recopila la
informacin.s Existen muchas tcnicas para reunir requisitos que varan desde hacer
preguntas a las personas hasta verlas funcionar. En esta seccin, nos centramos en las cinco
tcnicas ms comnmente utilizadas: entrevistas, sesiones JAD (un tipo especial de reunin
grupal), cuestionarios, anlisis de documentos y observacin. Cada tcnica tiene sus propias
fortalezas y debilidades, muchas de las cuales son complementarias, por lo que la mayora
de los proyectos utilizan una combinacin de tcnicas.
Entrevistas
Una entrevista es la tcnica de recopilacin de requisitos ms comnmente utilizada. Despus
de todo, es natural: si necesita saber algo, por lo general le pregunta a alguien. En general,
las entrevistas se realizan individualmente (un entrevistador y un entrevistado), pero a veces,
debido a limitaciones de tiempo, se entrevista a varias personas al mismo tiempo. Hay cinco
pasos bsicos para el proceso de la entrevista: seleccin de los entrevistados, diseo de las
preguntas de la entrevista, preparacin para la entrevista, realizacin de la entrevista y
seguimiento posterior a la entrevista.8
El primer paso para entrevistar es crear un cronograma de entrevistas que enumere quin ser
entrevistado, cundo y con qu propsito (vea la Figura 3-3). El cronograma puede ser una
lista informal que se usa para ayudar a establecer horarios de reuniones o una lista formal
que se incorpora al plan de trabajo. Las personas que aparecen en el programa de entrevistas
se seleccionan en funcin de las necesidades de informacin del analista. El patrocinador del
proyecto, los usuarios comerciales clave y otros miembros del equipo del proyecto pueden
ayudar al analista a determinar quin en la organizacin puede brindar mejor informacin
importante sobre los requisitos. Estas personas figuran en el calendario de entrevistas en el
orden en que deben ser entrevistadas.
Las personas de diferentes niveles de la organizacin tienen diferentes perspectivas sobre el
sistema, por lo que es importante incluir tanto a los gerentes que administran los procesos
como al personal que realmente realiza los procesos para obtener perspectivas de alto y bajo
nivel sobre un problema. Adems, los tipos de temas de entrevista necesarios pueden cambiar
con el tiempo. Por ejemplo, al inicio del proyecto, el analista tiene una comprensin limitada
del proceso comercial tal como est. Es comn comenzar por entrevistar a uno o dos gerentes
para obtener una visin estratgica y luego pasar a gerentes de nivel medio que puedan
proporcionar informacin amplia y general sobre el proceso comercial y el rol esperado del
sistema que se est desarrollando. Una vez que el analista comprende bien el panorama
general, los gerentes de nivel inferior y el personal pueden completar los detalles exactos de
cmo funciona el proceso. Como la mayora de otras cosas sobre anlisis de sistemas, este es
un proceso iterativo, comenzando con los gerentes superiores, pasando a gerentes de nivel
medio, luego a miembros del personal, a gerentes de nivel medio, y dems, dependiendo de
la informacin que se necesite en el camino.
Es bastante comn que la lista de entrevistados crezca, a menudo entre un 50 y un 75 por
ciento. A medida que se entrevista a las personas, se identificar ms informacin y personas
adicionales que puedan proporcionar la informacin.
Hay tres tipos de preguntas de entrevista: preguntas cerradas, preguntas abiertas y preguntas
de prueba. Las preguntas cerradas son aquellas que requieren una respuesta especfica. Son
similares a preguntas de opcin mltiple o aritmticas en un examen (consulte la Figura 3-
4). Las preguntas cerradas se utilizan cuando un analista busca informacin especfica y
precisa (por ejemplo, cuntas solicitudes de tarjeta de crdito se reciben por da). En general,
las preguntas precisas son las mejores.
Por ejemplo, en lugar de preguntar, manejas muchas solicitudes? Es mejor preguntar,
cuntas solicitudes procesa por da? Las preguntas cerradas permiten a los analistas
controlar la entrevista y obtener la informacin que necesitan. Sin embargo, este tipo de
preguntas no descubren por qu la respuesta es como es, ni descubren informacin que el
entrevistador no piensa pedir con anticipacin.
Las preguntas abiertas son aquellas que dejan espacio para la elaboracin por parte del
entrevistado.
Son similares en muchos aspectos a las preguntas de ensayo que puede encontrar en un
examen (ver La Figura 3-4 para ejemplos). Las preguntas abiertas estn diseadas para reunir
informacin rica y darle al entrevistado ms control sobre la informacin que se revela
durante la entrevista.
A veces, la informacin que el entrevistado elige discutir descubre informacin tan
importante como la respuesta (por ejemplo, si el entrevistado habla solo de otros
departamentos cuando se le preguntan por problemas, puede sugerir que es reacio a admitir
su propia informacin). Problemas).
El tercer tipo de pregunta es la pregunta de sondeo. Las preguntas exploratorias dan
seguimiento a lo que se acaba de analizar para aprender ms, y a menudo se utilizan cuando
el entrevistador no tiene clara la respuesta del entrevistado. Animan al entrevistado a ampliar
o confirmar la informacin de una respuesta anterior, y sealan que el entrevistador est
escuchando y est interesado en el tema en discusin. Muchos analistas principiantes son
reacios a usar preguntas de sondeo porque temen que el entrevistado no termine siendo
cuestionado o porque creen que demuestra que no entendieron lo que dijo el entrevistado.
Cuando se hace cortsmente, las preguntas de sondeo pueden ser una herramienta poderosa
para reunir los requisitos.
En general, un entrevistador no debe hacer preguntas sobre la informacin que est
disponible de otras fuentes. Por ejemplo, en lugar de preguntar qu informacin se utiliza
para realizar una tarea, es ms simple mostrarle al entrevistado un formulario o informe (ver
la seccin sobre anlisis de documentos) y preguntar qu informacin se usa. Esto ayuda a
enfocar al entrevistado en la tarea y le ahorra tiempo, porque el entrevistado no necesita
describir los detalles de la informacin; solo necesita sealarlo en el formulario o informe.
Ningn tipo de pregunta es mejor que otro, y una combinacin de preguntas generalmente se
usa durante una entrevista. En la etapa inicial de un proyecto de desarrollo de SI, el proceso
tal como est no est claro, por lo que el proceso de entrevista comienza con entrevistas no
estructuradas, entrevistas que buscan informacin amplia y aproximadamente definida. En
este caso, el entrevistador tiene una idea general de la informacin necesaria, pero tiene pocas
preguntas cerradas que formular. Estas son las entrevistas ms difciles de realizar porque
requieren que el entrevistador haga preguntas abiertas y busque informacin importante
sobre la marcha.
A medida que avanza el proyecto, el analista comprende mucho mejor el proceso comercial
y necesita informacin muy especfica sobre cmo se realizan los procesos comerciales (por
ejemplo, cmo se aprueba la tarjeta de crdito de un cliente). En este momento, el analista
realiza entrevistas estructuradas, en las que se desarrollan conjuntos especficos de preguntas
antes de las entrevistas. Generalmente hay ms preguntas cerradas en una entrevista
estructurada que en el enfoque no estructurado.
Independientemente del tipo de entrevista que se realice, las preguntas de la entrevista deben
organizarse en una secuencia lgica para que la entrevista fluya correctamente. Por ejemplo,
al tratar de recopilar informacin sobre el proceso comercial actual, puede ser til moverse
en un orden lgico a travs del proceso o desde los asuntos ms importantes hasta los menos
importantes.
Hay dos enfoques fundamentales para organizar las preguntas de la entrevista: de arriba hacia
abajo o de abajo hacia arriba (vea la Figura 3-5). Con la entrevista de arriba hacia abajo, el
entrevistador comienza con cuestiones generales y generales y gradualmente trabaja hacia
otras ms especficas. Con la entrevista de abajo arriba, el entrevistador comienza con
preguntas muy especficas y pasa a preguntas amplias. En la prctica, los analistas mezclan
los dos enfoques, comenzando con cuestiones generales y generales, pasando a preguntas
especficas y luego volviendo a los problemas generales.
El enfoque de arriba hacia abajo es una estrategia apropiada para la mayora de las entrevistas
(sin duda es el enfoque ms comn). El enfoque de arriba hacia abajo permite que el
entrevistado se acostumbre al tema antes de que l o ella necesiten proporcionar detalles.
Tambin permite al entrevistador comprender los problemas antes de pasar a los detalles
porque el entrevistador puede no tener suficiente informacin al comienzo de la entrevista
para hacer preguntas muy especficas. Quizs lo ms importante es que el enfoque de arriba
hacia abajo permite al entrevistado plantear una serie de problemas de gran envergadura antes
de enredarse en detalles, por lo que es menos probable que el entrevistador se pierda
cuestiones importantes.
Un caso en el que la estrategia de abajo hacia arriba puede preferirse es cuando el analista ya
ha reunido mucha informacin sobre problemas y solo necesita completar algunos agujeros
con detalles.
Las entrevistas ascendentes pueden ser apropiadas si los miembros del personal de nivel
inferior se sienten amenazados o no pueden responder preguntas de alto nivel. Por ejemplo,
cmo podemos mejorar el servicio al cliente? Puede ser una pregunta demasiado amplia
para un empleado de atencin al cliente, mientras que una pregunta especfica es fcilmente
respondible (por ejemplo, cmo podemos acelerar las devoluciones de los clientes?). En
cualquier caso, todas las entrevistas deben comenzar con preguntas no controvertidas y luego
pasar gradualmente a cuestiones ms polmicas despus de que el entrevistador haya
desarrollado cierta relacin con el entrevistado.
Es importante prepararse para la entrevista de la misma manera que se preparara para una
presentacin. El entrevistador debe tener un plan de entrevista general en el que se enumeren
las preguntas que deben formularse en el orden apropiado, debe prever posibles respuestas y
proporcionarles seguimiento, y debe identificar las segmentaciones entre los temas
relacionados. El entrevistador debe confirmar las reas en las que el entrevistado tiene
conocimiento para no hacer preguntas que el entrevistado no pueda responder. Revise las
reas temticas, las preguntas y el plan de entrevistas, y decida claramente cules tienen la
mayor prioridad en caso de que el tiempo se agote.
En general, las entrevistas estructuradas con preguntas cerradas toman ms tiempo para
prepararse que las entrevistas no estructuradas. Algunos analistas principiantes prefieren las
entrevistas no estructuradas, pensando que pueden aletear. Esto es muy peligroso y, a
menudo, contraproducente, porque cualquier informacin no reunida en la primera entrevista
requerir esfuerzos de seguimiento, y a la mayora de los usuarios no les gusta ser
entrevistados repetidamente sobre los mismos problemas.
El entrevistador tambin debe asegurarse de preparar al entrevistado. Cuando se programa la
entrevista, se debe informar al entrevistado el motivo de la entrevista y las reas que sern
discutidas con suficiente anticipacin para que tenga tiempo de pensar en los problemas y
organizar sus pensamientos. Esto es particularmente importante cuando el entrevistador es
ajeno a la organizacin y para los empleados de nivel inferior, a quienes a menudo no se les
pide su opinin y quienes pueden estar inseguros acerca de por qu estn siendo
entrevistados.
El primer objetivo es establecer una buena relacin con el entrevistado, para que confe en el
entrevistador y est dispuesto a contar toda la verdad, no solo a dar las respuestas que l o
ella cree que se desean. El entrevistador debe parecer un buscador de informacin
profesional, imparcial e independiente. La entrevista debe comenzar con una explicacin de
por qu el entrevistador est all y por qu l o ella han elegido entrevistar a la persona;
entonces el entrevistador debe pasar a las preguntas de la entrevista planificada.
Es fundamental registrar cuidadosamente toda la informacin que proporciona el
entrevistado. En nuestra experiencia, el mejor enfoque es tomar notas cuidadosas: escriba
todo lo que dice el entrevistado, incluso si no parece relevante de inmediato. El entrevistador
no debe temer pedirle a la persona que reduzca la velocidad o hacer una pausa mientras
escribe, porque esto es una clara indicacin de que la informacin del entrevistado es
importante. Un tema potencialmente controvertido es si grabar o no una entrevista. La
grabacin garantiza que el entrevistador no pierda puntos importantes, pero puede ser
intimidante para el entrevistado. La mayora de las organizaciones tienen polticas o prcticas
generalmente aceptadas sobre la grabacin de entrevistas, por lo que deben determinarse
antes de una entrevista. Si el entrevistador est preocupado por la prdida de informacin y
no puede grabar la entrevista, puede llevar a una segunda persona para tomar notas detalladas.
A medida que avanza la entrevista, es importante comprender los problemas que se debaten.
Si el entrevistador no entiende algo, l o ella deben pedir una aclaracin.
El entrevistador no debe temer hacer preguntas estpidas, porque lo nico peor que parecer
tonto es ser tonto al no entender algo. Si el entrevistador no entiende algo durante la
entrevista, seguramente no lo entender despus. La jerga debe ser reconocida y definida;
cualquier jerga no comprendida debe ser aclarada. Una buena estrategia para aumentar la
comprensin durante una entrevista es resumir peridicamente los puntos clave que el
entrevistado est comunicando. Esto evita malentendidos y tambin demuestra que el
entrevistador est escuchando.
Finalmente, los hechos deben separarse de la opinin. El entrevistado puede decir, por
ejemplo,
Procesamos demasiadas solicitudes de tarjeta de crdito. Esta es una opinin, y es til seguir
con una pregunta de investigacin que solicita apoyo para la declaracin (por ejemplo,
cuntos procesas en un da?). Es til verificar los hechos porque cualquier diferencia entre
los hechos y las opiniones del entrevistado puede sealar reas clave de mejora. Supongamos
que el entrevistado se queja de un nmero elevado o creciente de errores, pero los registros
muestran que los errores han disminuido. Esto sugiere que los errores se consideran un
problema muy importante que el nuevo sistema debe abordar, incluso si estn disminuyendo.
A medida que la entrevista llega a su fin, el entrevistado debe tener tiempo para hacer
preguntas o proporcionar informacin que l o ella cree que es importante, pero que no forma
parte del plan de la entrevista.
En la mayora de los casos, el entrevistado no tiene preocupaciones o informacin adicional,
pero en algunos casos esto lleva a informacin no anticipada, pero importante. Del mismo
modo, puede ser til preguntar al entrevistado si hay otras personas que deberan ser
entrevistadas. La entrevista debe finalizar a tiempo (si es necesario, se pueden omitir algunos
temas o programar otra entrevista).
Como ltimo paso en la entrevista, el entrevistador debe explicar brevemente lo que suceder.
El entrevistador no debe prometer prematuramente ciertas caractersticas en el nuevo sistema
o en una fecha de entrega especfica, pero debe asegurar al entrevistado que su tiempo fue
bien empleado y muy til para el proyecto.
Una vez finalizada la entrevista, el analista debe preparar un informe de entrevista que
describa la informacin de la entrevista (Figura 3-6). El informe contiene notas de entrevistas,
informacin que se recopil en el transcurso de la entrevista y se resume en un formato til.
En general, el informe de la entrevista debe escribirse dentro de las cuarenta y ocho horas de
la entrevista, porque cuanto ms espere el entrevistador, es ms probable que olvide la
informacin.
A menudo, el informe de la entrevista se enva al entrevistado con una solicitud para leerlo e
informar al analista de las aclaraciones o actualizaciones. El entrevistado debe estar
convencido de que el entrevistador realmente quiere sus correcciones al informe. Por lo
general, hay pocos cambios, pero la necesidad de cambios importantes significa que se
requerir una segunda entrevista. Nunca distribuyas la informacin de alguien sin aprobacin
previa.
Desarrollo de aplicaciones conjuntas (JAD)
JAD es una tcnica de recopilacin de informacin que permite que el equipo del proyecto,
los usuarios y la administracin trabajen juntos para identificar los requisitos del sistema.
IBM desarroll la tcnica JAD a fines de la dcada de 1970 y, a menudo, es el mtodo ms
til para recabar informacin de los usuarios.
Capers Jones afirma que JAD puede reducir el creep del alcance en un 50 por ciento y evitar
que los requisitos del sistema sean demasiado especficos o demasiado vagos, lo que causa
problemas durante las etapas posteriores del proceso de desarrollo.
JAD es un proceso estructurado en el que de diez a veinte usuarios se renen bajo la direccin
de un facilitador experto en tcnicas JAD. El facilitador establece la agenda de la reunin y
gua la discusin, pero no se une a la discusin como participante. l o ella no proporcionan
ideas u opiniones sobre los temas en discusin para permanecer neutral durante la sesin. El
facilitador debe ser un experto tanto en tcnicas de proceso grupal como en anlisis de
sistemas y tcnicas de diseo. Uno o dos escribas ayudan al facilitador grabando notas,
haciendo copias, etc. A menudo, los escribas usan computadoras y herramientas CASE para
registrar informacin como los procedimientos de la sesin JAD.
El grupo JAD se rene durante varias horas, varios das o varias semanas hasta que se hayan
discutido todos los problemas y se haya recopilado la informacin necesaria. La mayora de
las sesiones de JAD se llevan a cabo en una sala de reuniones especialmente preparada, lejos
de las oficinas de los participantes, para que no se interrumpan. La sala de reuniones
generalmente est dispuesta en forma de U para que todos los participantes puedan verse
fcilmente. En la parte delantera de la sala (la parte abierta de la U), hay una pizarra, un
rotafolio y / o un retroproyector para que los utilice el facilitador que dirige el debate.
JAD sufre los problemas tradicionales asociados con los grupos: a veces las personas son
reacias a desafiar las opiniones de los dems (particularmente su jefe), algunas personas a
menudo dominan la discusin y no todos participan. En un grupo de quince miembros, por
ejemplo, si todos participan por igual, cada persona puede hablar solo cuatro minutos cada
hora y debe escuchar los restantes cincuenta y seis minutos, una forma no muy eficiente de
recopilar informacin.
Una nueva forma de JAD llamada Electronic JAD, o e-JAD, intenta superar estos problemas
mediante el uso de groupware. En una sala de reuniones de e-JAD, cada participante usa un
software especial en una computadora en red para enviar ideas y opiniones annimas a todos
los dems. De esta forma, todos los participantes pueden contribuir al mismo tiempo sin
temor a represalias de personas con opiniones diferentes. La investigacin inicial sugiere que
e-JAD puede reducir el tiempo requerido para ejecutar sesiones de JAD en un 50 a 80 por
ciento. Un buen enfoque JAD sigue un conjunto de cinco pasos.
Los participantes de JAD se seleccionan de la misma manera que los participantes de la
entrevista, con base en la informacin que pueden aportar para proporcionar una amplia
combinacin de niveles organizacionales y para generar apoyo poltico para el nuevo sistema.
La necesidad de que todos los participantes de JAD estn lejos de su oficina al mismo tiempo
puede ser un problema importante. Es posible que sea necesario cerrar la oficina u operar con
un personal mnimo hasta que se completen las sesiones de JAD.
Idealmente, los participantes que son liberados de sus deberes regulares para asistir a las
sesiones de JAD deben ser las mejores personas en esa unidad de negocios. Sin embargo, sin
un fuerte apoyo de la administracin, las sesiones de JAD pueden fallar porque los
seleccionados para asistir a la sesin de JAD son personas con menos probabilidades de
perderse (es decir, las personas menos competentes).
El facilitador debe ser alguien que sea experto en tcnicas JAD o e-JAD e, idealmente,
alguien que tenga experiencia con el negocio en discusin. En muchos casos, el
El facilitador de JAD es un consultor externo a la organizacin porque la organizacin podra
no tener una necesidad recurrente de experiencia en JAD o e-JAD. Desarrollar y mantener
esta experiencia interna puede ser costoso.
Las sesiones de JAD pueden durar desde medio da hasta varias semanas, dependiendo del
tamao y el alcance del proyecto. En nuestra experiencia, la mayora de las sesiones de JAD
tienden a durar de cinco a diez das, repartidas en un perodo de tres semanas. La mayora de
las sesiones de e-JAD tienden a durar de uno a cuatro das en un perodo de una semana. Las
sesiones de JAD y e-JAD generalmente van ms all de recopilar informacin y pasar al
anlisis.
Por ejemplo, los usuarios y los analistas colectivamente pueden crear productos de anlisis,
como los modelos funcionales o la definicin de requisitos.
Las sesiones de JAD generalmente se disean y estructuran usando los mismos principios
que las entrevistas.
La mayora de las sesiones de JAD estn diseadas para recopilar informacin especfica de
los usuarios, y esto requiere desarrollar un conjunto de preguntas antes de la reunin. Una
diferencia entre JAD y las entrevistas es que todas las sesiones de JAD estn estructuradas,
deben planificarse cuidadosamente.
En general, las preguntas cerradas rara vez se utilizan porque no desencadenan la discusin
franca y abierta que es tpica de JAD. En nuestra experiencia, es mejor proceder de arriba
hacia abajo en las sesiones de JAD al recopilar informacin. Por lo general, se asignan treinta
minutos a cada elemento de la agenda por separado, y se programan descansos frecuentes
durante todo el da porque los participantes se cansan fcilmente.
Al igual que con las entrevistas, es importante preparar a los analistas y participantes para
una sesin de JAD. Debido a que las sesiones pueden ir ms all de la profundidad de una
entrevista tpica y generalmente se realizan fuera del sitio, los participantes pueden estar ms
preocupados acerca de cmo prepararse. Es importante que los participantes entiendan lo que
se espera de ellos. Si el objetivo de la sesin JAD, por ejemplo, es desarrollar una
comprensin del sistema actual, los participantes pueden traer consigo manuales de
procedimientos y documentos. Si el objetivo es identificar mejoras para un sistema, antes de
que lleguen a la sesin de JAD, pueden pensar en cmo mejoraran el sistema.
La mayora de las sesiones de JAD siguen una agenda formal, y la mayora tienen reglas
bsicas formales que definen el comportamiento apropiado. Las reglas bsicas comunes
incluyen seguir el cronograma, respetar las opiniones de los dems, aceptar el desacuerdo y
garantizar que solo una persona hable a la vez.
El papel de un facilitador de JAD puede ser un desafo. Muchos participantes vienen a una
sesin de JAD con fuertes sentimientos sobre el sistema para ser discutidos. Canalizar estos
sentimientos para que la sesin avance en una direccin positiva y lograr que los participantes
reconozcan y acepten -pero no necesariamente estn de acuerdo- las opiniones y situaciones
diferentes de las suyas requiere una experiencia significativa en anlisis y diseo de sistemas,
JAD y habilidades interpersonales. Pocos analistas de sistemas intentan facilitar las sesiones
de JAD sin estar entrenados en las tcnicas de JAD, y la mayora de los aprendices con un
facilitador de JAD capacitado antes de intentar dirigir su primera sesin.
El facilitador JAD realiza tres funciones clave. Primero, l o ella aseguran que el grupo se
apegue a la agenda. La nica razn para desviarse de la agenda es cuando el facilitador, el
lder del proyecto y el patrocinador del proyecto vean con claridad que la sesin de JAD ha
producido informacin nueva que es inesperada y requiere que la sesin JAD (y tal vez el
proyecto) se muevan en una nueva direccin. Cuando los participantes intentan desviar la
discusin de la agenda, el facilitador debe ser firme pero corts al dirigir la discusin de
vuelta a la agenda y volver a encarrilar al grupo.
En segundo lugar, el facilitador debe ayudar al grupo a comprender los trminos tcnicos y
la jerga que rodea el proceso de desarrollo del sistema y ayudar a los participantes a
comprender las tcnicas de anlisis especficas utilizadas. Los participantes son expertos en
su rea, o su parte del negocio, pero no son expertos en anlisis de sistemas. El facilitador
debe, por lo tanto, minimizar el aprendizaje requerido y ensear a los participantes cmo
proporcionar efectivamente la informacin correcta.
En tercer lugar, el facilitador registra la entrada del grupo en un rea de visualizacin pblica,
que puede ser una pizarra, un rotafolio o una pantalla de computadora. l o ella estructuran
la informacin que el grupo proporciona y ayuda al grupo a reconocer los problemas clave y
las soluciones importantes. El facilitador debe permanecer neutral en todo momento y
simplemente ayudar al grupo a travs del proceso. En el momento en que el facilitador ofrece
una opinin sobre un tema, el grupo lo ver no como una parte neutral, sino como alguien
que podra estar tratando de influir al grupo en una solucin predeterminada.
Sin embargo, esto no significa que el facilitador no deba tratar de ayudar al grupo a resolver
los problemas. Por ejemplo, si dos elementos parecen ser los mismos para el facilitador, el
facilitador no debera decir: "Creo que estos pueden ser similares". En cambio, el facilitador
debera preguntar: "Son similares?"
Si el grupo decide que lo son, el facilitador puede combinarlos y seguir adelante. Sin
embargo, si el grupo decide que no son similares (a pesar de lo que crea el facilitador), el
facilitador debe aceptar la decisin y seguir adelante. El grupo siempre tiene la razn, y el
facilitador no tiene opinin.
Al igual que con las entrevistas, se prepara un informe posterior a la sesin de JAD que se
distribuye entre los asistentes a la sesin. El informe posterior a la sesin es esencialmente el
mismo que el informe de la entrevista en la Figura 3-6.
Debido a que las sesiones de JAD son ms largas y brindan ms informacin, generalmente
toma una o dos semanas despus de la sesin de JAD antes de que se complete el informe.
Cuestionarios
Un cuestionario es un conjunto de preguntas escritas utilizadas para obtener informacin de
individuos.
Los cuestionarios a menudo se usan cuando hay una gran cantidad de personas de quienes se
necesita informacin y opiniones. En nuestra experiencia, los cuestionarios son una tcnica
comn con sistemas destinados a ser utilizados fuera de la organizacin (por ejemplo, por
clientes o proveedores) o para sistemas con usuarios comerciales distribuidos en muchas
ubicaciones geogrficas.
La mayora de las personas piensan automticamente en el papel cuando piensan en los
cuestionarios, pero hoy se distribuyen ms cuestionarios en formato electrnico, ya sea por
correo electrnico o por correo electrnico.
Web. La distribucin electrnica puede ahorrar una cantidad significativa de dinero en
comparacin con la distribucin de cuestionarios impresos. Un buen proceso para usar al usar
cuestionarios sigue cuatro pasos.
Al igual que con las entrevistas y las sesiones de JAD, el primer paso es identificar a las
personas a quienes se enviar el cuestionario. Sin embargo, no es habitual seleccionar a todas
las personas que podran proporcionar informacin til. El enfoque estndar es seleccionar
una muestra, o subconjunto, de personas que sean representativas de un grupo completo. Las
pautas de muestreo se discuten en la mayora de los libros de estadsticas, y la mayora de las
escuelas de negocios incluyen cursos que cubren el tema, por lo que no lo discutiremos aqu.
El punto importante en la seleccin de una muestra, sin embargo, es darse cuenta de que no
todas las personas que reciben un cuestionario en realidad lo completarn. En promedio, solo
se devuelven del 30 al 50 por ciento de los cuestionarios en papel y por correo electrnico.
Las tasas de respuesta para los cuestionarios basados en la Web tienden a ser
significativamente ms bajas (a menudo solo del 5 al 30 por ciento).
Debido a que la informacin en un cuestionario no se puede aclarar de inmediato para un
encuestado confuso, el desarrollo de buenas preguntas es fundamental para los cuestionarios.
Las preguntas sobre los cuestionarios deben estar escritas muy claramente y dejan poco
margen para malentendidos, por lo que las preguntas cerradas tienden a ser las ms utilizadas.
Las preguntas deben permitir claramente al analista separar los hechos de las opiniones. Las
preguntas de opinin a menudo preguntan a los encuestados si estn de acuerdo o en
desacuerdo (p. Ej., Son comunes los problemas de red?), Mientras que las preguntas
objetivas buscan valores ms precisos (p. Ej., Con qu frecuencia ocurre un problema de
red: una vez por hora, una vez al da? una semana?). Consulte la Figura 3-7 para ver las
pautas sobre el diseo del cuestionario.
Quizs el problema ms obvio, pero que a veces se pasa por alto, es tener una comprensin
clara de cmo se analizar y utilizar la informacin recopilada del cuestionario. Este
problema debe abordarse antes de que se distribuya el cuestionario, porque es demasiado
tarde despus.
Las preguntas deben ser relativamente consistentes en estilo, de modo que el encuestado no
tenga que leer las instrucciones de cada pregunta antes de responderla. En general, es una
buena prctica agrupar preguntas relacionadas para que sean ms fciles de responder.
Algunos expertos sugieren que los cuestionarios deberan comenzar con preguntas
importantes para los encuestados, de modo que el cuestionario capte inmediatamente su
inters y los induzca a responderlo. Quizs el paso ms importante es hacer que varios
colegas revisen el cuestionario y luego lo prueben con unas pocas personas extradas de los
grupos a los que se enviar. Es sorprendente cmo muchas veces las preguntas aparentemente
simples pueden malinterpretarse.
El problema clave en la administracin del cuestionario es lograr que los participantes
completen el cuestionario y lo enven de vuelta. Se han escrito docenas de libros de
investigacin de marketing sobre formas de mejorar las tasas de respuesta. Las tcnicas
comnmente utilizadas incluyen una explicacin clara de por qu se realiza el cuestionario y
por qu se seleccion al encuestado, indicando una fecha en la que se debe devolver el
cuestionario, lo que ofrece un incentivo para completar el cuestionario (por ejemplo, un
bolgrafo gratis), y ofrece proporcionar un resumen de las respuestas al cuestionario.
Los analistas de sistemas tienen tcnicas adicionales para mejorar las tasas de respuesta
dentro de la organizacin, como entregar personalmente el cuestionario y contactar
personalmente a quienes no lo han devuelto despus de una semana o dos, as como solicitar
a los supervisores de los encuestados que administren los cuestionarios en un grupo reunin.
Es til procesar los cuestionarios devueltos y elaborar un informe del cuestionario poco
despus de la fecha lmite del cuestionario. Esto garantiza que el proceso de anlisis se realice
de manera oportuna y que los encuestados que solicitaron copias de los resultados los reciban
con prontitud.
Anlisis de documentos
Los equipos de proyecto a menudo usan el anlisis de documentos para comprender el
sistema tal como est. En circunstancias ideales, el equipo del proyecto que desarroll el
sistema existente habr producido documentacin que luego fue actualizada por todos los
proyectos posteriores. En este caso, el equipo del proyecto puede comenzar revisando la
documentacin y examinando el sistema en s.
Desafortunadamente, muchos sistemas no estn bien documentados porque los equipos de
proyecto no pueden documentar sus proyectos en el camino, y cuando los proyectos terminan,
no hay tiempo para volver atrs y documentar. Por lo tanto, es posible que no haya mucha
documentacin tcnica sobre los sistemas actuales disponibles o que no contenga
informacin actualizada sobre los cambios recientes en el sistema. Sin embargo, existen
muchos documentos tiles en una organizacin: informes en papel, memorandos, manuales
de polticas, manuales de capacitacin del usuario, organigramas, formularios y, por
supuesto, la interfaz del usuario con el sistema existente.
Pero estos documentos solo cuentan parte de la historia. Representan el sistema formal que
usa la organizacin. Muy a menudo, el sistema real o informal difiere del formal, y estas
diferencias, particularmente las grandes, dan fuertes indicaciones de lo que debe cambiarse.
Por ejemplo, los formularios o informes que nunca se usan probablemente deberan
eliminarse. Del mismo modo, las casillas o preguntas en formularios que nunca se rellenan
(o se utilizan para otros fines) deben reconsiderarse. Consulte la Figura 3-8 para ver un
ejemplo de cmo se puede interpretar un documento.
La indicacin ms poderosa de que el sistema necesita ser cambiado es cuando los usuarios
crean sus propios formularios o agregan informacin adicional a los existentes. Dichos
cambios demuestran claramente la necesidad de mejoras en los sistemas existentes. Por lo
tanto, es til revisar los formularios en blanco y completados para identificar estas
desviaciones. Del mismo modo, cuando los usuarios acceden a mltiples informes para
satisfacer sus necesidades de informacin, es una seal clara de que se necesita nueva
informacin o nuevos formatos de informacin.
Observacin
La observacin, el acto de observar los procesos que se realizan, es una herramienta poderosa
para reunir informacin sobre el sistema tal como es, ya que permite al analista ver la realidad
de una situacin, en lugar de escuchar a otros describirla en entrevistas o sesiones de JAD.
Varios estudios de investigacin han demostrado que muchos gerentes realmente no
recuerdan cmo funcionan y cmo asignan su tiempo. (Rpido, cuntas horas pasaste la
semana pasada en cada uno de tus cursos?) La observacin es una buena manera de verificar
la validez de la informacin recopilada de fuentes indirectas, como entrevistas y
cuestionarios.
En muchos sentidos, el analista se convierte en antroplogo a medida que camina por la
organizacin y observa el sistema de negocios a medida que funciona. El objetivo es
mantener un perfil bajo, no interrumpir a los que trabajan y no influir en los observados. No
obstante, es importante comprender que lo que los analistas observan puede no ser la rutina
diaria normal porque las personas tienden a ser extremadamente cuidadosas en su
comportamiento cuando se les est vigilando. Aunque la prctica normal puede ser romper
las reglas organizacionales formales, es poco probable que el observador vea esto.
(Recuerdas cmo manejaste la ltima vez que un coche de polica te sigui?) Por lo tanto,
lo que ves podra no ser lo que obtienes.
La observacin se usa a menudo para complementar la informacin de la entrevista. La
ubicacin de la oficina de una persona y su mobiliario da pistas sobre el poder e influencia
de la persona en la organizacin y puede usarse para respaldar o refutar la informacin
proporcionada en una entrevista. Por ejemplo, un analista puede volverse escptico respecto
de alguien que dice usar extensivamente el sistema informtico existente si la computadora
nunca se enciende mientras el analista visita. En la mayora de los casos, la observacin
respalda la informacin que los usuarios proporcionan en las entrevistas. Cuando no es as,
es una seal importante que se debe tener especial cuidado al analizar el sistema comercial.
Seleccionar las tcnicas apropiadas
Cada una de las tcnicas de recopilacin de requisitos discutidas anteriormente tiene
fortalezas y debilidades.
Ninguna tcnica es mejor que las dems, y en la prctica la mayora de los proyectos utilizan
una combinacin de tcnicas. Por lo tanto, es importante comprender las fortalezas y
debilidades de cada tcnica y cundo usar cada una (consulte la Figura 3-9). Un tema no
discutido es el de la experiencia de los analistas. En general, el anlisis y la observacin de
documentos requieren la menor cantidad de entrenamiento, mientras que las sesiones de JAD
son las ms desafiantes.
Tipo de informacin La primera caracterstica es el tipo de informacin. Algunas tcnicas
son ms adecuadas para usar en diferentes etapas del proceso de anlisis, ya sea para entender
el sistema tal como est, identificar mejoras o desarrollar el sistema futuro. Las entrevistas y
JAD se usan comnmente en las tres etapas. Por el contrario, el anlisis y la observacin de
documentos generalmente son ms tiles para comprender el tal como est, aunque
ocasionalmente brindan informacin sobre problemas actuales que deben mejorarse. Los
cuestionarios a menudo se utilizan para recopilar informacin sobre el sistema tal como est,
as como informacin general sobre las mejoras.
Profundidad de la informacin La profundidad de la informacin se refiere a qu tan rica y
detallada es la informacin que la tcnica generalmente produce y en qu medida la tcnica
es til para obtener no solo hechos y opiniones, sino tambin una comprensin de por qu
existen esos hechos y opiniones. Las entrevistas y las sesiones de JAD son muy tiles para
proporcionar una buena cantidad de informacin rica y detallada y para ayudar al analista a
comprender las razones detrs de ellas. En el otro extremo, el anlisis y la observacin de
documentos son tiles para obtener hechos, pero poco ms all. Los cuestionarios pueden
proporcionar una profundidad media de informacin, solicitando tanto hechos como
opiniones con poca comprensin de por qu existen.
Amplitud de la informacin La amplitud de la informacin se refiere a la variedad de fuentes
de informacin y de informacin que se pueden recopilar fcilmente utilizando la tcnica
elegida. Los cuestionarios y el anlisis de documentos son fcilmente capaces de solicitar
una amplia gama de informacin de un gran nmero de fuentes de informacin. En contraste,
las entrevistas y la observacin requieren que el analista visite cada fuente de informacin
individualmente y, por lo tanto, tome ms tiempo. Las sesiones de JAD estn en el medio
porque muchas fuentes de informacin se unen al mismo tiempo.
Integracin de la informacin Uno de los aspectos ms desafiantes de la recopilacin de
requisitos es integrar la informacin de diferentes fuentes. En pocas palabras, diferentes
personas pueden proporcionar informacin conflictiva. Combinar esta informacin e intentar
resolver las diferencias en opiniones o hechos generalmente lleva mucho tiempo, ya que
significa contactar a cada fuente de informacin, explicar la discrepancia y tratar de refinar
la informacin. En muchos casos, el individuo percibe errneamente que el analista est
desafiando su informacin, cuando de hecho es otro usuario de la organizacin quien lo est
haciendo.
Esto puede hacer que el usuario se ponga a la defensiva y dificulte la resolucin de las
diferencias.
Todas las tcnicas sufren problemas de integracin hasta cierto punto, pero las sesiones de
JAD estn diseadas para mejorar la integracin porque toda la informacin se integra
cuando se recopila, no despus.
Si dos usuarios proporcionan informacin conflictiva, el conflicto se vuelve inmediatamente
obvio, al igual que la fuente del conflicto. La integracin inmediata de la informacin es el
beneficio individual ms importante de JAD que lo distingue de otras tcnicas, y esta es la
razn por la cual la mayora de las organizaciones utilizan JAD para proyectos importantes.
Participacin del usuario La participacin del usuario se refiere a la cantidad de tiempo y
energa que los usuarios previstos del nuevo sistema deben dedicar al proceso de anlisis. En
general, se acepta que a medida que los usuarios se involucren ms en el proceso de anlisis,
aumentan las posibilidades de xito. Sin embargo, la participacin del usuario puede tener
un costo significativo, y no todos los usuarios estn dispuestos a contribuir con tiempo y
energa valiosos. Los cuestionarios, el anlisis de documentos y la observacin representan
la menor carga para los usuarios, mientras que las sesiones de JAD requieren el mayor
esfuerzo.
Costo: el costo es siempre una consideracin importante. En general, los cuestionarios, el
anlisis de documentos y la observacin son tcnicas de bajo costo (aunque la observacin
puede llevar bastante tiempo). El bajo costo no implica que sean ms o menos efectivos que
las otras tcnicas. Las entrevistas y las sesiones de JAD generalmente tienen costos
moderados. En general, las sesiones de JAD son mucho ms costosas inicialmente, porque
requieren que muchos usuarios estn ausentes de sus oficinas por perodos de tiempo
significativos, y a menudo involucran consultores altamente remunerados.
Sin embargo, las sesiones de JAD reducen significativamente el tiempo dedicado a la
integracin de la informacin y, por lo tanto, pueden costar menos a largo plazo.
Tcnicas de combinacin En la prctica, la recopilacin de requisitos combina una serie de
tcnicas diferentes.
La mayora de los analistas comienzan por utilizar entrevistas con el (los) gerente (es)
principal (es) para comprender el proyecto y los problemas generales. A partir de estas
entrevistas, queda claro si se prevn cambios grandes o pequeos. Estas entrevistas a menudo
se siguen con el anlisis de documentos y polticas para obtener una cierta comprensin del
sistema tal como est. Por lo general, las entrevistas se presentan a continuacin para
recopilar el resto de la informacin necesaria para la imagen tal como est.
En nuestra experiencia, la identificacin de mejoras se realiza ms comnmente utilizando
sesiones JAD porque la sesin JAD permite a los usuarios y partes interesadas clave trabajar
juntos a travs de una tcnica de anlisis y llegar a una comprensin compartida de las
posibilidades para el sistema futuro.
Ocasionalmente, estas sesiones de JAD son seguidas por cuestionarios enviados a un
conjunto mucho ms amplio de usuarios o usuarios potenciales para ver si las opiniones de
quienes participaron en las sesiones de JAD son ampliamente compartidas.
El desarrollo del concepto para el sistema futuro se hace a menudo a travs de entrevistas
con los gerentes principales, seguido de sesiones de JAD con usuarios de todos los niveles
para asegurar que las necesidades clave del nuevo sistema sean bien entendidas.
TCNICAS DE DOCUMENTACIN DE REQUISITOS ALTERNATIVOS
Algunas otras tcnicas muy tiles: recopilacin y documentacin incluyen la creacin de
prototipos, casos de uso, tarjetas CRC de roles con escenarios basados en casos de uso, mapas
conceptuales y la grabacin de historias de usuarios en tarjetas de historias y listas de tareas.
El prototipo descatalogado se describi en el Captulo 1. En esencia, se crean prototipos
desechables para comprender mejor algunos aspectos del nuevo sistema. En muchos casos,
se utilizan para probar algn aspecto tcnico de un requisito no funcional, como conectar una
estacin de trabajo cliente a un servidor. Si nunca ha hecho esto antes, ser mucho ms fcil
desarrollar un sistema de ejemplo muy pequeo para probar el diseo necesario de la
conexin desde la estacin de trabajo cliente hasta el servidor en lugar de intentar hacerlo la
primera vez con el sistema completo. Sistema soplado. La creacin de prototipos es muy til
para disear interfaces de usuario (ver Captulo 10).
Los casos de uso, como se describe en el Captulo 1, son el enfoque fundamental que utilizan
el Proceso Unificado y el Lenguaje de Modelado Unificado (UML) para documentar y reunir
requisitos funcionales.
Los describimos en el Captulo 4. Role-playing Las tarjetas CRC con escenarios basados en
casos de uso son muy tiles cuando se crean funciones (ver Captulo 4), estructurales (ver
Captulo 5) y comportamiento
(Ver el Captulo 6) modelos. Describimos este enfoque en el Captulo 5. El resto de esta
seccin describe el uso de mapas conceptuales que registran historias de usuarios en fichas y
listas de tareas.
Mapas conceptuales
Los mapas conceptuales representan relaciones significativas entre conceptos. Son tiles para
enfocar a las personas en el pequeo nmero de ideas clave en las que deben concentrarse.
Un mapa conceptual es esencialmente una representacin de nodo y arco, donde los nodos
representan los requisitos individuales y los arcos representan las relaciones entre los
requisitos.
Cada arco est etiquetado con un nombre de relacin. Los mapas conceptuales tambin se
han recomendado como una posible tcnica para respaldar los requisitos de modelado para
el desarrollo de sistemas orientados a objetos y sistemas de gestin del conocimiento. El
mapeo conceptual es una tcnica de psicologa educativa que se ha utilizado en escuelas,
corporaciones y agencias de atencin mdica para facilitar el aprendizaje, la comprensin y
la creacin de conocimiento. La ventaja del enfoque de mapeo conceptual para representar
los requisitos sobre el enfoque textual tpico (ver Figura 3-1) es que un mapa conceptual no
se limita a una representacin jerrquica. Los mapas conceptuales permiten representar
explcitamente las relaciones entre los requisitos funcionales y no funcionales.
La Figura 3-10 muestra un mapa conceptual que retrata la informacin contenida en la
definicin de requisitos que se muestra en la Figura 3-1. Al usar un mapa conceptual para
representar los requisitos en lugar del enfoque textual, la relacin entre los requisitos
funcionales y no funcionales puede hacerse explcita. Por ejemplo, los dos requisitos de
seguridad Only Doctors Set. Disponibilidad y solo los gerentes pueden Programar horario
estn vinculados explcitamente al registro
Los requisitos funcionales de Doctor Availability y Produce Schedule, respectivamente. Esto
es muy difcil de representar en una versin de solo texto de la definicin de requisitos.
Adems, al hacer que el usuario y el analista se centren en la distribucin grfica del mapa,
se pueden descubrir requisitos adicionales. Un problema obvio con este enfoque es que si el
nmero de requisitos se vuelve muchos y las relaciones entre ellos se vuelven complejas,
entonces el nmero de nodos y arcos se entrelazar tanto que se perder la ventaja de poder
ver explcitamente las relaciones. Sin embargo, al combinar las representaciones de texto y
de mapa conceptual, es posible aprovechar la fortaleza de las representaciones tanto textuales
como grficas para representar de forma ms completa los requisitos.
Historias de usuarios
Las historias de usuario, junto con sus historiales y listas de tareas asociadas, estn asociadas
con los enfoques de desarrollo gil. Las historias de los usuarios han demostrado ser muy
tiles para reunir requisitos de una manera no amenazante que respeta el punto de vista del
usuario. Por lo general, se capturan utilizando tarjetas de historia (fichas) y se registran en
una lista de tareas (o desde un Perspectiva de Scrum, en la cartera de pedidos del producto).
Tanto las fichas como las listas de tareas se consideran enfoques ligeros para documentar y
reunir los requisitos.14 Las historias captura los requisitos funcionales y no funcionales. Por
ejemplo, con respecto al ejemplo de cita del consultorio mdico, una historia basada en
requisitos funcionales podra ser:
Como secretaria, deseo poder programar citas para nuestros pacientes para que podamos
satisfacer las necesidades de nuestros pacientes.
Mientras que una historia operativa no funcional basada en requisitos podra ser:
Como secretaria, quiero poder imprimir el programa diario utilizando tecnologa inalmbrica
para que toda la impresin se pueda realizar utilizando una impresora compartida sin tener
que lidiar con los cables de la impresora que conectan todas las computadoras a la impresora.
Una vez que se escribe la historia, se discute para determinar la cantidad de esfuerzo que se
requerir para implementarla. Durante la discusin, se crea una lista de tareas para la historia.
Si la historia se considera demasiado grande, por ejemplo, hay demasiadas tareas en la lista
de tareas, la historia se divide en varias historias, cada una de las cuales se registra en su
propia tarjeta de historia y las tareas se asignan a las nuevas historias. En muchas tiendas,
una vez que se ha identificado un conjunto de tareas con una historia, la historia y sus tareas
se pegan en una pared para que todos los miembros del equipo de desarrollo puedan ver los
requisitos. La historia se puede priorizar por importancia colocando una calificacin en la
tarjeta. La historia tambin se puede evaluar para el nivel de riesgo asociado con ella. El nivel
de importancia y la cantidad de riesgo asociados con la historia se pueden usar para ayudar a
elegir qu requisitos implementar primero. La ventaja de utilizar tarjetas de historias y listas
de tareas para documentar los requisitos es que son muy poco tecnolgicas, de alto toque,
fcilmente actualizables y muy porttiles.
Determinacin de requisitos
Una propuesta de sistema rene en un nico documento integral el material creado durante
la planificacin y el anlisis. La propuesta del sistema generalmente incluye un resumen
ejecutivo, la solicitud del sistema, el plan de trabajo, el anlisis de factibilidad, la definicin
de los requisitos y las modelos en evolucin que describen el nuevo sistema. Los modelos en
evolucin incluyen modelos funcionales (Ver Captulo 4), modelos estructurales (ver
Captulo 5) y modelos de comportamiento (ver Captulo 6). Resumen ejecutivo proporciona
toda la informacin crtica en una forma muy concisa. Se puede pensar de como un resumen
de la propuesta completa. Su propsito es permitir que un ejecutivo ocupado rpidamente
lalo y determine qu partes de la propuesta necesita pasar ms a fondo. El resumen ejecutivo
generalmente no es ms que una pgina larga. La Figura 3-11 proporciona una plantilla para
una propuesta de sistema y referencias donde se describen las otras secciones de la propuesta.