Obtencion de Requerimientos del Dr. Pedro Mejia.

INGENIERIA DE SOFTWARE.
Dr. Pedro Mejia Alvarez. 2009.
Obtención de Requerimientos
En esta actividad se determina el dominio de la aplicación, se especifican los servicios que debe
proveer el sistema, la funcionalidad requerida del sistema, y las restricciones de hardware y
software. Es indispensable la participación de los usuarios y clientes para la identificación de los
requerimientos del sistema.
Como resultado de esta actividad se debe obtener un documento inicial de definición de los
requerimientos (DDR), en donde se definen las necesidades iniciales del sistema, o lo que se
conoce como requerimientos iniciales. Estos requerimientos pudieran no ser los definitivos, ni
tampoco todos los requerimientos. Nuevos requerimientos pueden ser agregados al documento
conforme se vayan descubriendo o incluso los requerimientos ya definidos pueden modificarse o
eliminarse.
En la obtención de los requerimientos existen las siguientes tareas a seguir (referencia):
1. Comprender el problema que se va a resolver, para lo cual es necesario estudiar el dominio
o entorno en el que el sistema va a operar.
2. Buscar y recolectar información acerca del sistema a desarrollar, de manuales de operación
y mantenimiento, de manuales organizacionales y políticas de operación.
3. Definir los límites y restricciones del sistema para determinar con precisión que es lo que el
sistema va a hacer y también especificar lo que no va a hacer.
4. Identificar a las personas o usuarios interesados en el sistema, ya que ellos conocen el
medio ambiente en que operará el sistema y pueden ayudar describiendo sus necesidades.
5. Recolectar y clasificar requerimientos, los desarrolladores pueden iniciar definiendo un
bosquejo general del sistema, su funcionamiento básico y estableciendo su alcance.
El desarrollo de las tareas de obtención de requerimientos es realizado de manera secuencial, sin
embargo cualquier tarea pudiera regresarnos a la anterior, sobre todo si no se descubre la
información necesaria en el primer recorrido del diagrama. La Figura 3.1 muestra esta relación.
La salida de esta actividad nos conduce hacia el análisis de requerimientos.
Figura 3.1 El proceso de obtención de requerimientos.
3.1. Comprensión del Problema
En todo proyecto de desarrollo de software, la primera actividad consiste en comprender el
problema que se desea resolver. El problema será resuelto mediante la construcción de un
producto o sistema de software. Para poder comprender el problema hay que establecer cuales
son los objetivos que persigue el cliente y su organización, cual es su visión del producto a
desarrollar y cuales son sus necesidades. Además, para comprender el problema es necesario
tener amplios conocimientos sobre el dominio de la aplicación y sobre el ambiente de operación.
Un proyecto que no tiene una dirección bien definida claramente llevara al desastre. Los
participantes del proyecto pueden tener objetivos y prioridades distintas a los definidos por el
70
cliente y con ello llevar al proyecto a no cumplir con la funcionalidad deseada. Todos los
involucrados en el proyecto, deben estar de acuerdo con los objetivos de proyecto así como en
sus alcances. Una consecuencia de que algunos de los involucrados no están de acuerdo con los
objetivos, es que los requerimientos se vuelven inestables. Esto causa frecuentes cambios en los
requerimientos.
Los detalles específicos del problema del cliente deben ser bien comprendidos. La descripción
del problema proviene de cliente, sin embargo, en ocasiones el problema es difícil de
documentar. Este problema ocurre por las siguientes razones:
•
El cliente no siempre define claramente el problema.
•
El analista de requerimientos y los desarrolladores no comprenden la naturaleza del problema.
•
El analista y los desarrolladores entienden el problema pero no saben como llevarlo a cabo.
•
El problema es muy amplio, vago, poco factible, o muy volátil.
Aunque el problema se comprenda, no será posible llevarlo a cabo si este no es factible. Por lo
tanto, después de comprender el problema y antes de comenzar el desarrollo, tanto el cliente
como los desarrolladores deben estar de acuerdo en su factibilidad. El problema de la factibilidad
se trata en el capítulo anterior.
Comúnmente, el problema no siempre es comprendido de forma inmediata, sino que requiere de
varias iteraciones. En cada iteración el cliente y los analistas de requerimientos llevan a cabo
entrevistas para aclarar el problema y sus implicaciones de desarrollo. En ocasiones el problema
es factible de desarrollar pero sus implicaciones en tiempo de desarrollo o costo pueden ser muy
altas. El tiempo y el costo son factores que siempre hay que tomar en cuenta cuando se describe
el problema. Lo que se desea finalmente en ésta fase, es que el problema esté bien descrito por
parte del cliente y bien comprendido por parte de los desarrolladores.
En esta actividad se describe el problema a solucionar. La organización que contrata un proyecto
de software, persigue unos objetivos con el desarrollo. Por ejemplo, el software pudiera
permitirle al cliente optimizar, automatizar o permitir documentar sus procedimientos
organizacionales. En una tienda departamental, por ejemplo, se podría requerir de la
automatización del proceso de venta, que antes se venia haciendo de forma manual. Este proyecto
podría consistir en la instalación de terminales de cómputo en cada punto de venta, y su conexión
con los departamentos de contabilidad y almacenes. El sistema de cómputo permitiría a un
71
operador de la tienda, cobrar e introducir datos sobre los productos vendidos. El objetivo de este
sistema de cómputo sería la automatización del proceso de venta de productos de la tienda
departamental.
3.7.1 Comprensión del dominio de la aplicación.
El conocimiento del dominio de la aplicación permite identificar el ambiente sobre el cual el
sistema de software estará operando y también el sistema que se encuentra actualmente en
operación. No es posible desarrollar ningún sistema si no se conoce el dominio. Los
requerimientos pueden ser mejor obtenidos y analizados si éste dominio es bien comprendido. El
dominio de la aplicación comprende varios aspectos.
•
Ambiente operacional. Permite definir el ambiente sobre el cual el sistema estará operando y
todos sus componentes. Este medio ambiente podría ser, un sistema distribuido, un sistema en
red de área local, un sistema robotizado, un sistema de manufactura computarizado o una
aplicación de comercio electrónico.
•
Sistemas de hardware. Estos sistemas comprenden, los sistemas de cómputo, las redes
utilizadas y sus protocolos, así como cualquier otros sistemas eléctricos y mecánicos.
•
Sistemas de Software. Estos sistemas comprenden los sistemas operativos, bases de datos,
lenguajes, sistemas de manejo de archivos, software de aplicación, sistemas de seguridad,
entre otros.
•
Interfaces Hombre-Maquina. Estos sistemas son aquellos con los que los usuarios tendrán
contacto directo para llevar a cabo sus labores.
•
Conexiones externas. Estos sistemas son aquellos que provienen del exterior del sistema y
que reciben datos del sistema o a quienes el sistema envía datos.
•
Procedimientos operacionales. Estos procedimientos definen las funciones que realiza el
sistema actual.
•
Capacidad del Sistema Actual. Este aspecto permite identificar cual es la capacidad de
procesamiento y de almacenamiento requeridos por el sistema.
Un gran número de sistemas no solo están compuestos por una computadora y un software
interno. Las industrias, las empresas bancarias, las empresas de telecomunicaciones o las
72
empresas de comercio electrónico, por mencionar solo algunas, tienen medios de operación muy
complejos que comprenden sistemas de cómputo, sistemas electro-mecánicos, robots, complejos
sistemas de tele-comunicaciones y sofisticadas interfaces de usuario. El desarrollo de sistemas de
software sobre éste tipo de ambientes, implica que especialistas de distintas disciplinas de la
Ingeniería se involucren en su especificación y diseño.
Podemos mencionar por ejemplo, el sistema de software que opera sobre los cajeros automáticos
de los bancos. Mediante este cajeros, es posible realizar diversas transacciones bancarias como
sacar dinero, hacer transferencias bancarias, consultar saldos o cambiar claves. Estos cajeros
contienen un sistema de cómputo el cual controla los dispositivos electro-mecánicos que
permiten almacenar y dar dinero a las personas con cuenta en el banco. Además, estos cajeros,
cuentan con sistema de comunicaciones, que les permiten enlazarse con los sistemas de cómputo
del banco. Cuando un cliente del banco introduce su tarjeta de crédito, para obtener dinero del
cajero, el sistema se comunica con el sistema de cómputo del banco para validar la tarjeta y para
obtener el estado de la cuenta del cliente.
Es necesario que los desarrolladores de este sistema cuenten con los conocimientos necesarios
sobre el dominio de la aplicación a desarrollar. Sin estos conocimientos el software sería difícil
de desarrollar o tendría fuertes implicaciones en el tiempo y costo de desarrollo. Esta parte debe
identificarse durante la fase de factibilidad, anteriormente descrita.
La información acerca del dominio de la aplicación no se recolecta de un solo lugar. Existe en
variedad de fuentes como, libros, manuales organizacionales, especialistas en el tema, o usuarios
que dominan una área de la ciencia.
3.7.2 Comprensión de las necesidades de los clientes y usuarios.
Además de la descripción del problema a resolver por parte del cliente, es necesario conocer los
problemas que la organización enfrenta cada día en sus procesos de negocio. Esta información
permitirá comprender mejor los objetivos planteados por el cliente y sus necesidades. En
ocasiones, el cliente no sabe como describir sus necesidades o no sabe como un sistema de
software puede ayudar a solucionar sus problemas. Por eso, esta fase de comprensión de
necesidades, puede ayudar a describir el tipo de software que mejor resolverá las necesidades de
la organización.
Las siguientes actividades ayudan a comprender las necesidades del cliente y los usuarios:
73
•
Identificar las tareas o funciones que describen las necesidades del cliente (identificar los
casos de uso).
•
Identificar los eventos del sistema y sus respuestas.
•
Observar a los usuarios en sus labores.
•
Observar reportes de problemas de los usuarios del sistema actual.
3.7.3 Requerimientos del negocio
Una vez comprendido el problema a solucionar o el sistema nuevo a desarrollar es necesario
entender cuales son los requerimientos del negocio. Los requerimientos del negocio describen los
beneficios que el nuevo sistema proveerá a la organización y a sus usuarios. Los proyectos de
desarrollo de software por lo general comienzan con la idea de que el nuevo producto de software
mejorará la situación del negocio del cliente de alguna forma. Para la definición de los
requerimientos del negocio es necesario detallar los siguientes aspectos:
1. Antecedentes. En los antecedentes se resumen las razones y el contexto del nuevo producto.
Proveen una descripción general de la historia o la situación que llevó a la decisión de
construir el producto o sistema.
2. Oportunidades de negocio. Para un producto comercial, describen la oportunidad de
mercado que existe y el mercado en el cual el producto estará compitiendo. Para un sistema a
implantar dentro de una organización, describe el problema del negocio que se pretende
solucionar o los procesos que se pretenden mejorar. Describe los problemas que existen y
que no pueden ser resueltos con la tecnología y los sistemas actualmente en operación. Aquí
se muestran también las tendencias del mercado, la evolución de la tecnología y la historia de
las decisiones organizacionales relacionadas al sistema por desarrollar.
3. Visión del producto. Es una descripción general de lo que se persigue con la construcción
del software y de los beneficios que se esperan. Resume de forma cuantitativa y cualitativa
los beneficios que el producto o el sistema aportará a la organización. En este aspecto es
importante que los clientes, usuarios y los directores de proyecto definan la forma en como se
medirá el éxito o el fracaso del desarrollo y los factores que afectarán o que tendrán mayor
impacto en el éxito del proyecto, incluyendo factores dentro o fuera de la organización.
74
4. Riesgos del negocio. En este aspecto, los riesgos definen los problemas que se contemplan
dentro del desarrollo del proyecto; una vez que el comienzo de éste ha sido ha sido aprobado.
Los tipos de riesgos que se pueden presentar son:
•
la habilidad de poder controlar y administrar efectivamente el desarrollo del proyecto,
•
la competencia del mercado,
•
el nivel de aceptación del usuario,
•
los posibles problemas con la implementación y operación del sistema, y
•
los posibles impactos negativos en la organización.
5. Alcances del proyecto a través de los requerimientos del negocio. Los alcances del
proyecto permiten al cliente y a los desarrolladores, identificar las implicaciones del
desarrollo como son, el tiempo de construcción, los costos y las personas involucradas en
desarrollo (por parte del cliente y por parte de los desarrolladores). En ocasiones, es difícil
para los desarrolladores estimar tiempos y costos de desarrollo, sin embargo, en la mayoría de
los proyectos, el cliente tiene un tiempo máximo permitido y un costo que no puede exceder
su presupuesto. Los conflictos que surjan por los tiempos y costos deben resolverse cuando la
etapa de factibilidad y de especificación de requerimientos estén terminadas. Hasta entonces,
se tendrá la información suficiente para llevar a cabo decisiones de contratación, o rechazo
del proyecto.
6. Comprensión del negocio. No es posible llevar a cabo ningún proyecto si no se conoce el
negocio que la organización del cliente lleva a cabo. En la comprensión del negocio es
necesario conocer:
1. La estructura organizacional.
2. Los procesos del negocio.
3. Los sistemas existentes, y
4. El personal clave relacionado con el proyecto.
75
3.2. Búsqueda y Recolección de Información
Para comprender el problema a solucionar, es importante contar con diversa información que
permita conocer la organización del cliente, sus necesidades y en general el dominio de la
aplicación. Esta información debe recolectarse de distintos manuales de la organización,
estándares y políticas, y manuales técnicos que describan las distintas partes del dominio de la
aplicación y los procesos y normas de la organización. La información recolectada sobre el
problema a resolver, debe organizarse coherentemente a fin de que pueda ser utilizada no solo
durante el proceso de Ingeniería de Requerimientos, sino también durante todo el ciclo de
desarrollo.
Algunos ejemplos de información que debe ser recolectada son los siguientes:
1. Información sobre el sistema actual. Esta información provee detalles sobre el sistema que
se quiere remplazar y que actualmente está en funcionamiento. Si se trata de un producto a
desarrollar de uso genérico, ésta información deberá ser aquella que describe los productos
similares actualmente en el mercado, contra quienes el producto tendrá que competir. Es
importante en este caso, recolectar información sobre la funcionalidad y restricciones del
producto competidor, su precio, el soporte que se ofrece y sus limites geográficos de
distribución.
2. Necesidades de los clientes y usuarios. La información recolectada anteriormente, derivada
de las entrevistas con los clientes, usuarios y con los interesados en el sistema, debe
documentarse.
3. Estándares organizacionales. Esta información comprende todos aquellos manuales de
procedimientos que la organización sigue en sus procesos.
4. Regulaciones Nacionales e Internacionales. Esta información es aquella que provea
estándares o normas para reglamentar al sistema o a los productos de software a construir.
Usualmente todo país cuenta con un organismo de gobierno que regula las actividades de las
organizaciones y que provee reglas de competencia y de calidad.
5. Información sobre el dominio de la aplicación. Esta información comprende toda aquella
información que permita descubrir el dominio.
76
3.3. Definición de Límites y Restricciones
Los limites definen el contexto de operación del sistema y definen su medio de operación. Las
restricciones definen las limitantes organizaciones, técnicas, económicas o de tiempos de
desarrollo impuestas para el proyecto o producto de software a desarrollar. Dentro de las
restricciones deben definirse las condiciones de confiabilidad, disponibilidad, desempeño,
seguridad e integridad, y en general los requerimientos no-funcionales que se le exigirán al
sistema. Esta información influirá significativamente en la definición de la arquitectura del
sistema (por definir en la etapa de diseño).
El diagrama de contexto (referencia) se utiliza para definir los límites y las conexiones entre el
sistema y el medio ambiente que lo rodea. Además, identifica interfaces que permiten comunicar
al sistema con su medio externo. En la información que sale o entra al sistema a través de las
interfaces se utilizan flujos de control, de datos y de materiales. El diagrama de contexto puede
utilizarse como el diagrama que se encuentra en lo mas alto de la jerarquía arquitectónica del
sistema. La Figura 3.2 muestra el diagrama de contexto de un sistema de inscripciones a una
Universidad. El sistema permite a alumnos acceder al sistema mediante la Internet para realizar
su inscripción a sus cursos. El sistema reside en una computadora servidora de web y la
información de los cursos es introducida por los profesores de la universidad.
Figura 3.2 Diagrama de Contexto de un Sistema de Inscripciones.
77
3.4 Definición de los interesados en el sistema
Los interesados en el sistema (“stakeholders”) son personas, grupos de personas o organizaciones
que están involucradas activamente en el proyecto, que son afectadas por sus salidas, o que
proveen entradas al sistema. El proceso de Ingeniería de requerimientos está dominado por
distintos factores personales, sociales y organizacionales, debido a que involucra a distinto tipo
de personas, con distintos conocimientos o provenientes de distintas organizaciones. Así mismo,
las distintas personas involucradas en el proceso pueden tener o no conocimientos técnicos
relevantes al proyecto, y pueden venir de distintas disciplinas técnicas. Este contrasta con otras
etapas del desarrollo, como por ejemplo la etapa de pruebas, en donde el personal involucrado
por lo general comparte el mismo interés y conocimiento técnico, y comparten el objetivo de
demostrar que el sistema cumple con sus especificaciones.
Los interesados deben clasificarse de acuerdo a su actividad y a su perfil. Ejemplos de distintos
tipos de interesados en el sistema son los siguientes:
1. Clientes: Estos normalmente son quienes contratan, financian o autorizan el desarrollo del
proyecto.
2. Usuarios: Estos son aquellos que terminarán operando el software requerido, después de que
el sistema esté completamente desarrollado.
3. Ingenieros de Desarrollo de Software: Son todos aquellos involucrados en el desarrollo del
software, en cualquiera de sus etapas (diseño, implementación, pruebas o mantenimiento).
4. Ingenieros del cliente. Son todos aquellos especialistas que asesoran o trabajan dentro de la
organización del cliente y que ayudan a especificar los detalles técnicos de la aplicación a
desarrollar.
5. Administradores o jefes del proyecto de software: Son aquellos que dirigen y/o
administran el proyecto de software.
6. Contratistas externos. Son aquellos desarrolladores externos a quienes se les contrata para
realizar una parte del sistema.
7. Reguladores externos: es todo aquel personal que indirectamente verifica que todo
reglamento o ley que aplique al desarrollo del proyecto se cumpla.
78
En general, en la Ingeniería de Requerimientos es importante identificar a todos los involucrados
en el proceso a fin de obtener y validar el proceso. El no llevar a cabo esta identificación, puede
llevar a diseñar el sistema sin contar con toda la información o sin contar con la valiosa opinión
de alguno de los actores que participan en el proceso.
El perfil de los interesados en el sistema debe incluir la siguiente información:
1. El valor o beneficio que recibirá el interesado del producto o del sistema y la forma en que el
producto satisfacerá al interesado. Los beneficios que podría obtener el interesado podrían
ser:
b. Mejoras en su productividad.
c. Reducción de trabajo redundante.
d. Ahorro de costos.
e. Mejoras en el proceso del negocio.
f. Automatización de tareas que previamente se realizaban de forma manual.
g. Aprendizaje de nuevas tareas.
h. Cumplimiento de estándares o normas.
i. Mejoras en la calidad con respecto a otros productos o sistemas.
2. Su disposición o actitud hacia el sistema.
3. La forma en como el sistema afectará a su trabajo en la organización.
4. Su rol o función en la organización.
Además de clasificar a los interesados en el sistema, es necesario proveer detalles acerca de los
tipos de usuarios que utilizaran directamente el sistema. A los usuarios de sistema de software se
les puede clasificar de acuerdo a los siguientes aspectos:
•
La frecuencia con la que usan el sistema.
•
Las funciones que usan del sistema y su frecuencia.
•
La experiencia en el dominio de la aplicación y su experiencia con otros sistemas similares.
•
El tipo de uso que le dan al sistema (operación, administración, mantenimiento, supervisión).
79
•
Las tareas que desempeñan en soporte de los procesos de la organización.
•
Sus privilegios de acceso o niveles de seguridad (tales como usuario invitado, administrador o
usuario de nivel interno).
•
Tipo de usuarios necesario para operar el sistema (persona, grupo de personas, robot, o otra
computadora).
La clasificación de usuarios del sistema ayuda a la obtención de requerimientos ya que define a
detalle las características de los usuarios y sus actividades. Es importante distinguir a los usuarios
que utilizan el sistema con frecuencia para sus labores en la organización de aquellos que lo
utilizan esporádicamente. Esto no solo permitirá definir su rol en la organización sino también su
nivel de experiencia. Algunos usuarios por su inexperiencia, solo utilizan cierta funcionalidad del
sistema que les es de mayor utilizad ó la cual conocen mejor. Otra parte de la funcionalidad del
sistema no la utilizan, por que la desconocen ó por que no la encuentran útil. Obtener esta
información permite definir con mayor precisión los requerimientos y diseñar interfaces de
usuario mas útiles y fáciles de usar.
Algunos usuarios del sistema no llegan a utilizar el sistema, sin embargo se ven indirectamente
influenciados por su operación. Este personal pueden ser los encargados de su mantenimiento,
los administradores del sistema o el personal de supervisión. Este personal es importante por que
permite verificar que las labores de los usuarios se lleven a cabo de forma eficiente y sin errores.
Algunos otros usuarios solo reciben los beneficios o los productos que entrega el sistema y
forman parte de la organización. Este tipo de personas pueden ser los integradores ó los
ingenieros de producto, los cuales se encargan de usar los productos que produce el sistema de
software. Algunos usuarios pueden tener mayor nivel de autorización para el acceso a ciertas
funciones o niveles de operación del sistema de software.
Por otro lado, los usuarios no necesariamente tienen que ser personas. Algunos sistemas se
operan de forma automática, mediante otros sistemas de cómputo, mediante robots o de forma
híbrida computadora-humano. Muchos sistemas de software industriales operan en ambiente con
un alto nivel de ruido, contaminación o de calor, por lo cual se requiere de un sistema
automatizado para operar el sistema.
80
3.4.1 Roles y Actividades
En general, los interesados involucrados en el proceso de Ingeniería de requerimientos son
personas afectadas por este proceso a quienes se les puede identificar por sus roles en la
organización. Usualmente es útil cuando se modela un proceso, asociar las actividades del
proceso con los roles del personal que está involucrado en el proceso.
Los roles del personal y sus correspondientes actividades dentro del proceso de Ingeniería de
Requerimientos se describen en la Figura 3.3.
Rol
Analista
de
Requerimientos,
Experto
Actividades
del Este personal estará a cargo de entender el
dominio, usuario
problema y su definición.
Analista de requerimientos, usuario
Están a cargo de especificar a detalle los
requerimientos.
Ingeniero
de
desarrollo
de
software, Están a cargo de seleccionar posibles prototipos
administrador del proyecto
del sistema.
Ingeniero de requerimientos, Ingeniero de Estarán a cargo de desarrollar el sistema o
desarrollo de software
prototipo.
Usuario, experto del dominio, analista de Estarán a cargo de evaluar el sistema final o
requerimiento e Ingeniero de Desarrollo
prototipo.
Figura 3.3. Roles en el proceso de Ingeniería de Requerimientos
81
3.5 Recolección de Requerimientos
Después de la descripción del problema por el cliente, el analista de requerimientos debe escribir
en un documento inicial (DDR), una lista de requerimientos específicos, que describen a detalle
el problema planteado por el cliente. Este documento debe ser analizado para darle consistencia
durante la fase de análisis de requerimientos. De forma general los requerimientos provienen de
las siguientes fuentes:
1. Los interesados en el sistema. Todos los interesados en el sistema, principalmente el cliente
y los usuario son quienes mas información deben proporcionar sobre los requerimientos.
2. El dominio de la aplicación. El dominio de la aplicación es una fuente de información que
permite ubicar el contexto del desarrollo. Permite obtener información acerca de las
características de funcionamiento del sistema de forma general, y permite establecer sus
restricciones.
3. La organización. No puede validarse la información de los requerimientos a no ser que esta
esté de acuerdo a los estándares utilizados en la organización. De hecho la organización
también provee algunos de los requerimientos funcionales y principalmente los nofuncionales,
por ejemplo, los requerimientos de calidad, confiabilidad y seguridad del
sistema.
Los requerimientos obtenidos deben de estar de acuerdo con los objetivos y planes de la
organización y aquellos requerimientos que no ayuden a lograr estos objetivos no deben ser
incluidos. Las fuentes de donde se obtienen los requerimientos dependen de la naturaleza del
producto a desarrollar y del ambiente de desarrollo. La necesidad de obtener los requerimientos
de múltiples fuentes implica que siempre debe existir una comunicación fluida e intensa entre
cliente/usuarios y desarrolladores.
A continuación se describen algunas de las fuentes potenciales y las formas de obtención de
requerimientos.
•
Entrevistas y discusiones con clientes y usuarios. La forma mas obvia de obtener
información acerca del sistema de software a desarrollar es directamente con el cliente. El
cliente describe una necesidad y el desarrollador debe saber interpretar éstos requerimientos y
analizar su factibilidad. El cliente por lo general define los requerimientos de forma general,
pero no siempre define la funcionalidad. Todo software tiene una cierta funcionalidad que lo
82
define. El desarrollador debe ser capaz de traducir los requerimientos del cliente en funciones
y restricciones que debe incluir el sistema por construir.
•
Documentos que describen sistemas actuales o productos de la competencia. La mayoría
de las organizaciones cuentan con documentos que describen los objetivos que persigue la
organización, los procedimientos y procesos que llevan a cabo para cumplir con estos
objetivos, así como los roles que desempeñan cada persona que labora en la organización. Así
mismo, la organización puede contar con documentos que describen los productos o sistemas
de otras organizaciones que producen productos similares.
•
Reportes de problemas técnicos del sistema actual. En muchas organizaciones, se
almacenan documentos que reportan problemas técnicos o errores de operación del sistema
actual. Estos documentos, pueden ser una fuente mediante la cual el cliente justifica la
necesidad de un nuevo sistema. Así mismo, estos documentos permiten a los desarrolladores,
conceptualizar el sistema requerido, su entorno de operación, y las habilidades del personal
que opera estos sistemas.
•
Estudio de la organización ó cuestionarios de usuarios. Para poder construir cualquier
sistema de software, es necesario estudiar el medio ambiente sobre el cual estará en
operación. Este estudio permitirá comprender mejor los requerimientos planteados por el
cliente y ayudará a diseñar un sistema que cumpla mejor con los objetivos de la organización,
y que se adapte mejor a las habilidades de los usuarios.
•
Observación de los usuarios futuros y de su medio ambiente. Una fuente importante de
datos proviene de los usuarios futuros del sistema. Los usuarios son quienes tienen la
experiencia en la operación de los procesos de la organización. Esta experiencia puede ayudar
a los desarrolladores a construir un sistema más fácil de usar y que les permita incrementar su
productividad. La información obtenida de los procesos de trabajo de los usuarios, permitirá
validar la información recolectada de los clientes, e identificar potenciales conflictos y nuevos
requerimientos. El no observar a los usuarios en la operación de los sistemas actuales, llevará
muy probablemente a construir un sistema con funcionalidad incompleta o difícil de usar.
También es necesario estudiar las habilidades individuales de cada usuario, a fin de diseñar
un sistema que mejor se adapte a sus capacidades.
•
Análisis de los escenarios de las tareas del usuario. La identificación de las tareas que el
usuario necesita llevar a cabo con el sistema, permitirá al analista de requerimientos obtener
83
algunos de los requerimientos funcionales. De esta identificación debe también obtenerse
toda la información consumida y generada por la tarea y sobre las fuentes de la información.
•
Análisis de Eventos y Respuestas. Este análisis permitirá identificar los eventos externos a
los cuales el sistema debe reaccionar y sus respuestas correspondientes. Este análisis es
especialmente útil en sistemas que deben responder a eventos externos y que requieren de
respuestas en plazos de tiempo cortos o en tiempos bien definidos.
3.6 Clasificación de Requerimientos
Es un hecho que cuando se recolectan los requerimientos de los clientes o los usuarios, estos no
los entregan de forma organizada o clasificada. El analista de requerimientos debe obtener los
requermientos y clasificarlos en varias categorías de acuerdo a la información que recibe de las
distintas fuentes, de forma que estos posteriormente puedan ser analizados eficientemente.
Requerimientos
del negocio
Ideas y
soluciones
Casos de
y escenarios
Definiciones
de datos
Reglas del
negocio
Restricciones
Requerimientos
de interfaces
externas
Atributos de
Calidad
Requerimientos
funcionales
y no-funcionales
Figura 3.4 Clasificación de los requerimientos.
84
En capítulos anteriores hemos dado distintas clasificaciones de los requerimiento, sin embargo
aquí daremos una clasificación general que permita distinguir los requerimientos capturados. La
Figura 3.4, muestra 9 de éstas posibles categorías.
La información que no se encuentre dentro de esta clasificación no debe considerarse, y puede ser
lo siguiente:
•
Un requerimiento no relacionado con el desarrollo de software, por ejemplo la necesidad de
entrenar a los usuarios en el nuevo sistema.
•
Una restricción del proyecto de desarrollo, por ejemplo el costo o el plan de ejecución (que no
se trate de restricciones de diseño e implementación).
•
Una suposición.
•
Un requerimiento de datos, el cual puede ser asociado con la funcionalidad del sistema, por
ejemplo que los datos deben ser almacenados en la computadora.
•
Información adicional de contexto histórico o informativo.
La siguiente clasificación proporciona algunas frases que permitirán identificar cada
requerimiento de acuerdo a la siguiente clasificación (referencia Libro Wiegers: chapter 7):
1. Requerimientos de negocio: Todo lo que describa beneficios de mercado, financieros o del
negocio para los clientes o su organización, y que sean obtenidos del producto de software.
Las frases que describen algunos de estos requerimientos son los siguientes:
•
Incrementa el porcentaje del mercado en 30 %.
•
Ahorra 20% en costos de producción por la automatización instalada.
•
Ahorra 40% en costos de mantenimiento.
2. Casos de uso y escenarios: Los casos de uso son descripciones generales de metas del cliente
o tareas del negocio que los usuarios deben realizar. Un patrón único del caso de uso se
conoce como escenario. Es necesario trabajar con los clientes y usuarios para extraer los
escenarios, y de aquí conceptualizar los casos de uso. Los casos de uso se pueden obtener
mediante la descripción de los flujos de trabajo de los procesos de negocio del cliente. Otra
forma de obtener los casos de uso es preguntando a los usuario sobre la descripción de sus
tareas o funciones. Un usuario que dice: “Tengo que <hacer algo>” esta probablemente
describiendo un caso de uso. Algunos ejemplos de casos de uso son los siguientes:
85
•
Yo necesito imprimir una etiqueta de correo para el paquete.
•
Yo necesito administrar una cola de reactivos químicos que esperan ser analizados.
•
Yo necesito calibrar las maquinas para control numérico.
Mas detalles de los casos de uso y los escenarios se describen mas adelante en la sección de
técnicas de obtención de requerimientos.
3. Reglas del negocio: Cuando un cliente dice que solo algunas clases de usuarios realizan
alguna actividad bajo condiciones especificas, podría estar describiendo una regla del
negocio. Se podrían derivar algunos requerimientos funcionales mediante estas reglas, pero es
importante considerar que éstas reglas no definen requerimientos no funcionales. De hecho
las reglas de negocio definen hechos, restricciones, acciones que habilitan funciones,
formulas de cómputo o inferencias. Las siguientes son algunas de las frases que sugieren
reglas del negocio:
•
Debe de seguir el estándar de acuerdo con alguna ley o política de la organización.
•
Si <algunas condiciones ocurren>, entonces <lo siguiente ocurre>.
•
Debe ser calculado de acuerdo a las siguientes formulas.
4. Requerimientos funcionales: Los requerimientos funcionales describen el funcionamiento
que el sistema observará bajo ciertas condiciones y las acciones que permitirá el sistema
llevar a cabo a los usuarios. Varios ejemplos de clasificación de requerimientos funcionales
fueron presentados en el capitulo anterior. A continuación se describen algunos ejemplos de
frases de requerimientos funcionales obtenidas de usuarios:
•
Si el voltaje rebasa los 20 v. enciende la alarma amarilla.
•
El sistema envía un e-mail de confirmación cuando recibe cualquier e-mail.
•
El sistema debe ordenar los productos del inventario en orden alfabético.
Algunos de los requerimientos funcionales podrían ser opcionales. Es decir que podrían
implementarse solo en el caso de que el tiempo o el presupuesto asignado lo permitiera. Los
requerimientos opcionales suelen presentarse con frecuencia, ya que es difícil predecir los
tiempos y los costos de desarrollo. Podrían considerarse también, a un precio por separado o
ser ignorados.
86
5. Atributos de calidad: Los atributos de calidad son requerimientos no-funcionales, los cuales
indican la forma en que el sistema debe realizar alguna actividad. Estos atributos se obtienen
de escuchar algunas frases o palabras que describen el comportamiento del sistema, tales
como: rápido, robusto, seguro, confiable, o eficiente. El analista de requerimiento tendrá que
estar de acuerdo con el cliente sobre el significado de estos términos de forma que se eviten
ambigüedades o descripciones subjetivas.
6. Requerimientos de interfaces externas: Los requerimientos de esta clase definen
conexiones entre el sistema y el mundo externo. Estas interfaces pueden ser interfaces de
usuarios, interfaces de hardware o software o redes de conexión. Las frases que indican que
se está describiendo una interfase externa podrían ser las siguientes:
•
Las señales de voltaje se leen de los convertidores analógico-digital.
•
Los mensajes se envían a través de la Internet.
•
El software debe controlar el tablero de diagramas eléctricos.
•
Los archivos recibidos electrónicamente deben leerse del disco externo
•
El usuario debe poder ver paginas de web amigables.
7. Restricciones: Las restricciones de diseño e implementación restringen las opciones del
desarrollador. Existen áreas y casos particulares en donde las restricciones son bastante
obvias. Por ejemplo, en aplicaciones de sistemas basados en web, es importante que el
servidor designado reciba peticiones de varios clientes de forma concurrente y las procese en
un tiempo limitado. Otro ejemplo son las aplicaciones de sistemas empotrados (“embedded”),
en donde es importante tener en cuenta las restricciones de peso, potencia, tamaño, y
limitaciones de memoria. Es importante, de acuerdo al dominio de la aplicación, dar
significado a cada restricción impuesta, verificando su origen y su valides. Hay algunas
restricciones mas severas que otras, por lo que en todo momento debe de verificarse su
valides y debe identificarse claramente cuando la restricción es claramente una limitación y
no una meta a seguir. Asignar demasiadas restricciones o restricciones innecesarias al
sistema, impone un límite a la funcionalidad del sistema y puede bloquear algún
requerimiento importante. Por otro lado, asignar pocas restricciones pueden hacer que el
sistema se salga de control y que acepte cualquier estado de funcionalidad sin ninguna
verificación. Es importante por lo tanto validar toda restricción y verificar que sea realista.
87
Las siguientes son ejemplos de algunas restricciones descritas por el cliente o el usuario:
•
Los archivos recibidos no deben exceder los 10 Mbytes.
•
La Base de Datos debe manejar archivos en formato relacional.
•
El envío de paquetes en la red, debe de usar encriptación de 128 Bits.
Otras frases que describen restricciones al diseño podrían ser las siguientes:
•
El software debe ser escrito en lenguaje Java.
•
El manejador de bases de datos a utilizar debe ser Oracle.
•
El sistema debe soportar el browser de Explorer.
Es importante distinguir entre las restricciones impuestas al sistema y las restricciones
impuestas al desarrollo.
8. Definiciones de datos: Las definiciones de datos permiten identificar formato de los datos o
archivos, rango de valores permitidos, valores por defecto, o estructura la base de datos.
Estas definiciones las puede proveer el cliente o pueden ser abstraídas por el analista (o por
cualquier desarrollador). Algunos ejemplos de definiciones de datos pueden ser las siguientes:
•
Los números enteros capturados no deben sobre pasar el valor de 10,000.
•
El numero de asientos inicial a vender por la aerolínea debe ser 400.
•
El valor de temperatura limite es de 40 grados centígrados.
9. Ideas de solución: Mucho de lo que los clientes presentan como requerimientos podría
considerarse mas bien como ideas de solución. Algún cliente que describe como debería
comportase el sistema ante el operador, tal vez solo está describiendo sus ideas sobre posibles
soluciones. Las ideas de solución podrían derivar en requerimientos, si estas son validadas y
son factibles de implementar, pero en otras ocasiones estas solo podrían ser alternativas de
diseño. Por ejemplo, un cliente podría indicar que para proporcionar seguridad al sistema ante
ataques externos, este debe pedir un pasword, o podría construirse un “firewall” o hacer que
los datos usen encriptación. En este caso, el cliente esta dando ideas sobre posibles soluciones
al problema de añadir seguridad al sistema.
88
3.6.1 Identificación de los Elementos del Sistema
Otra clasificación de los requerimientos del sistema puede darse mediante la identificación de los
elementos que la componen. Una vez ubicados los limites del sistema mediante su diagrama de
contexto, es importante identificar cada elemento que compone al sistema y sus características.
Los elementos del sistema son los siguientes:
1. Entradas al sistema: describen no solo el identificador y el contenido de la entrada, sino
también todos los detalles de funcionalidad de los dispositivos de entrada. Este elemento
puede ser muy complejo e involucrar dispositivos de manipulación, como ratón, joystick,
dispositivos para apuntar a la pantalla, teclados o superficies sensibles al tacto. Los
dispositivos de entrada como la pantalla o teclados, pueden ser muy complejos, como los que
existen en aplicaciones de multimedia, juegos por computadora o aplicaciones robotizadas de
la industria.
2. Salidas del sistema: describen los dispositivos de salida, que pueden ser dispositivos de
video o audio, así como la funcionalidad de los mismos.
3. Funciones del sistema: describen el mapeo de las entradas a las salidas, y sus distintas
combinaciones. Así mismo describen, los comandos que requiere cada función del sistema.
4. Atributos del sistema: describen los requerimientos no-funcionales necesarios para que el
sistema opere correctamente, como la confiabilidad, la usabilidad, la disponibilidad, la
mantenibilidad o el desempeño.
5. Atributos del ambiente del sistema: describe otros atributos requeridos del sistema, tales
como la máxima carga permitida, máxima temperatura permitida, restricciones de operación,
o compatibilidad.
89
3.7 Características de calidad de los requerimientos
Muchas de las características de calidad de los requerimientos han sido conocidas desde hace
muchos años, sin embargo aun hoy muchos proyectos carecen de algunas de éstas características
por lo cual producen productos de software con poca calidad. Para mejorar las características de
calidad de los requerimientos es necesario detallar los conceptos que permiten mejorar la calidad
de los requerimientos de software.
La calidad de los requerimientos está dada de acuerdo a sus características. Dicha calidad
permitirá garantizar a los desarrolladores y clientes su entendimiento y utilización. Estas
características son:
1. Entendible. Un requerimiento es entendible si es fácil de leer y entender. Su redacción
debe ser simple y clara para aquellos que lo consulten en un futuro. Con frecuencia los
requerimientos son definidos por desarrolladores que utilizan conceptos y terminología
técnica difícil de entender por otros interesados.
2. Necesario. Un requerimiento es necesario si su omisión provoca una deficiencia en el
sistema a construir y además en su capacidad. Representa características físicas o un
factor de calidad que no pueden ser reemplazados por otras capacidades del producto o
del proceso.
3. Consistente. Un requerimiento es consistente si no es contradictorio con otro
requerimiento. Un requerimiento inconsistente será muy difícil de implementar. Para
asegurar la consistencia de un requerimiento es útil verificar si cada requerimiento es
consistente con sus fuentes, y si es consistente con otros requerimientos y no los
contradice.
4. No ambiguo. Un requerimiento no es ambiguo cuando tiene una sola interpretación. El
lenguaje usado para su especificación no debe causar confusión al lector. Para que un
requerimiento no sea ambiguo, este debe ser claro y preciso, objetivo y entendible.
5. Completo. Un requerimiento es completo si no necesita ampliar detalles en su redacción,
y proporciona toda la información suficiente para su comprensión. Es relativamente fácil
omitir información cuando se obtienen requerimientos, y con ello hacer que estos resulten
incompletos. Además, es difícil verificar que cada requerimiento es completo ya que
90
requiere dedicar tiempo, presupuesto y esfuerzo adicional, lo cual no siempre está
disponible en todo proyecto.
Para asegurar que un requerimiento es completo se requiere verificar si este es autocontenido, sin información faltante y si este es realmente un solo requerimiento. En otro
caso, un requerimiento podría descomponerse en múltiples requerimientos. Además es útil
verificar que cada requerimiento contenga toda la información necesaria relevante, que no
requiere mayor clarificación o ampliación, y que provee la suficiente información como
para evitar ambigüedad y confusión (referencia: paper specifying good requirements:
firesmith).
6. Verificable. Es verificable cuando puede ser cuantificado de manera que nos permita
hacer uso de métodos de verificación (tales como inspección, análisis, demostración o
pruebas) para garantizar que cumple sus propósitos. Los requerimientos deben cumplir
con las necesidades de los interesados. Para asegurar que un requerimiento es verificable
es útil asegurar que cada requerimiento es lo que los clientes y usuarios realmente
necesitan.
7. Correctos. Los requerimientos son correctos si estos describen lo que el cliente o usuario
indican. Estos deben ser revisados por el cliente y el desarrollador, para asegurar que no
tienen errores. Los defectos en los requerimientos naturalmente llevarán a producir
defectos en el diseño y en la implementación. Para asegurar que algún requerimiento es
correcto es necesario verificar que es semánticamente correcto, que cumple con alguna de
las necesidades de los interesados, y que está correctamente escrito.
8. Reales. Todos los requerimientos deben ser revisados para asegurar que su
implementación es posible en el sistema. Esta característica también define si un
requerimiento es factible. Los requerimientos no tienen valor si no pueden ser
implementados. Si no existe a tecnología, el personal, la experiencia o el presupuesto para
implementarlo no será factible.
9. Rastreables. Los requerimientos pueden ser rastreables hacia atrás y hacia delante.
Rastreable hacia atrás significa que para cada requerimiento se conoce su origen.
Rastreable hacia delante significa que todo requerimiento está escrito de tal forma que
facilita la referencia a los requerimientos con los que se relaciona.
91
10. Modificable. Un requerimiento es modificable si permite realizar cambios de manera
fácil, completa y consistentemente.
11. No redundantes. No deben existir dos requerimientos que definan funciones iguales o
similares, de otra forma estaríamos observando un requerimiento redundante.
3.8 Factores
que
llevan
a
realizar
cambios
en
los
requerimientos
Los cambios en los requerimientos pueden ocurrir en cualquiera fase del ciclo de desarrollo del
software. Aun después de que el sistema entra en operación, pueden darse cambios en los
requerimientos. Estos cambios pueden ser inevitables y no necesariamente son el resultado de
una pobre práctica de la Ingeniería de Requerimientos, sino mas bien podrían ser el resultado de
los siguientes factores:
1. Errores en los requerimientos (conflictos e inconsistencias). A medida que los
requerimientos son analizados e implementados, los errores e inconsistencias deben ser
descubiertos y corregidos. Estos problemas pueden descubrirse durante las etapas de análisis
o después en las posteriores etapas del desarrollo.
2. Evolución del conocimiento del sistema del cliente/usuario o del analista. A medida que
los requerimientos se desarrollan, los clientes/usuarios o los analistas pueden entender mejor
el sistema y por lo tanto solicitar cambios en los requerimientos.
3. Problemas técnicos, de planificación o de costos. Pueden aparecer distintos problemas al
implementar algún requerimiento. Este requerimiento puede ser muy costoso de implementar
o puede tomar bastante tiempo para su implementación.
4. Cambios en las prioridades. Las prioridades del cliente pueden cambiar durante el
desarrollo del proyecto y pedir cambios. Esto puede deberse a cambios en la organización,
cambios en el ambiente operacional del producto, o cambios en el personal.
5. Cambios en el ambiente. El ambiente en el que se instalará el sistema puede cambiar su
estructura, lo cual demandará cambios en los requerimientos para mantener compatibilidad.
6. Cambios organizacionales. La organización que usará el sistema puede cambiar su
estructura y sus procesos lo cual demandará cambios en los requerimientos.
92
7. Poco involucramiento del cliente o del usuario. Los clientes con frecuencia no comprenden
por que es tan importante trabajar frecuentemente junto con el analista para definir con
precisión los requerimientos y asegurar su calidad. En ocasiones los clientes creen que en
pocas reuniones han sido ya capaces de transmitir toda la información necesaria acerca del
sistema que se desea construir. Sin embargo, los desarrolladores pueden no tener claro
muchos aspectos y requerir mas interacción. En ocasiones los clientes no están muy
disponibles o se encuentran en otras ciudades y la interacción con ellos se vuelve
problemática. Los clientes pueden creer que al escribir un documento en donde describen sus
necesidades los libera de perder su tiempo con los desarrolladores en la especificación. Sin
embargo, es claro que a pesar de que este documento esté muy completo (de acuerdo a la
definición del cliente), se pueden requerir múltiples entrevistas con el cliente a fin de aclarar
cualquier duda acerca de la definición de los requerimientos. En proyectos en donde existe
poca interacción con el cliente puede llevar a el descubrimiento tardío de requerimientos que
necesariamente provocarán retrasos en la entrega del software.
Es importante mencionar también que existen otros factores que contribuyen a que los procesos y
los requerimientos en si observen cierta variabilidad.
1. Madurez técnica. Las técnicas y métodos usados en el proceso de Ingeniería de
Requerimientos pueden cambiar y evolucionar conforme las tecnologías de cómputo y
sistemas evolucionen. De esta forma, los cambios tecnológicos podrían causar alteraciones a
los requerimientos.
2. Cultura organizacional. La cultura organizacional tiene un efecto importante en todos los
procesos de negocio, por lo cual cualquier cambio en la organización podría provocar
cambios en los requerimientos.
3. Dominio de la aplicación. Esta influye sustancialmente a la variabilidad de la aplicación, ya
que distintas aplicaciones podrían requerir distintos tipos de procesos.
4. Movimientos de personal. Los cambios y salidas del personal de la organización que
desarrolla el software pueden causar una fuerte influencia en el desarrollo. Si las personas
desarrollaban alguna actividad importante, podría ser que su salida produzca considerables
retrasos en la entrega del software. Además, esto podría causar cambios importantes en los
requerimientos debido a que las habilidades del personal que dejo la organización podrían no
ser fácil de encontrar, y por lo tanto el software podría sufrir limitaciones.
93
3.9 Dificultades para definir los requerimientos de software
Para conseguir un sistema de software de calidad se debe iniciar con la elaboración de
requerimientos correctos y precisos. La Ingeniería de Requerimientos es un proceso muy
complejo debido a la naturaleza y a la diversidad de ambientes de los sistemas. Existen una gran
variedad de dificultades a que se enfrentan los clientes y los analistas para lograr la obtención y
especificación de los requerimientos del sistema.
Algunas de estas dificultades (además de algunas ya mencionadas anteriormente) son las
siguientes.
1. Requerimientos confusos, vagos o ambiguos. Los usuarios o clientes del sistema no
siempre pueden describir con precisión y claridad lo que desean o necesitan. El termino
requerimientos puede tener distintos significados para distintas personas. Por parte del cliente,
un requerimiento puede ser expresado como un producto definido de forma muy general, o un
objetivo de su organización, mientras que para un desarrollador puede consistir en un diseño
detallado de las interfaces del usuario. Los requerimientos que provee el cliente en muchas
ocasiones representan ideas de la solución a su problema. En general un síntoma de que existe
confusión sobre los requerimientos es que distintas personas (clientes, usuarios, analista y
desarrolladores) tengan distinta visión, opinión o conocimiento sobre algún requerimiento o
función que debe realizar el sistema. Otro síntoma de este problema, se ve cuando los
usuarios proveen los requerimientos, pero los desarrolladores no tienen claro como estos
pueden implementarse. La ambigüedad es otra característica desastrosa en los requerimientos.
En la definición de un proyecto de software, la ambigüedad se descubre cuando un
requerimiento tiene distintos significados (para una o para distintas personas) y no se está
seguro de cual de todos estos es el correcto. Una forma de ambigüedad similar a ésta, se
presenta cuando distintos lectores interpretan un mismo requerimiento de distintas formas.
Cada lector concluye que su interpretación es la correcta y la ambigüedad permanece hasta
tiempo después; cuando su solución es mas costosa. Así mismo, puede detectarse cuando un
requerimiento es vago o incompleto cuando en el documento de requerimientos no existe
información que el cliente necesita para entender este requerimiento. Si los requerimientos no
se verifican para comprobar que lo dicho por los clientes está contenido en el documento, es
bastante probable que los requerimientos no estén suficientemente bien definidos. Los
desarrolladores pueden asumir incorrectamente que lo que capturaron de las necesidades del
94
cliente es definitivo y completo. Sin embargo esta suposición puede ser muy riesgosa. Es
necesario verificar que esto se lleva a cabo. El ultimo síntoma que lleva a determinar que los
requerimientos son vagos, se presenta cuando los desarrolladores hacen frecuentes preguntas
a los analistas sobre la forma de implementar los requerimientos y de su significado. En
algunos casos, en realidad los diseñadores o quienes programan el sistema hacen suposiciones
o tienen que adivinar que es lo que un requerimiento realmente define. Las implicaciones de
estas suposiciones o adivinanzas puede no notarse hasta que el sistema es probado, o peor aun
cuando este es puesto en operación. En este punto, se requerirá regresar varias etapas hacia
atrás en el desarrollo para reparar los requerimientos mal interpretados. Muchas de estas
anomalías se resuelven mediante el análisis de los requerimientos y su correspondiente
validación (los cuales serán descritos en los próximos capítulos).
2. Poca familiaridad con los términos técnicos. La descripción de las necesidades del cliente
pueden estar expresadas utilizando sus propios términos y suposiciones con las cuales los
desarrolladores pueden no estar familiarizados. Por otro lado, los desarrolladores tienen
también su propio lenguaje, y en la mayoría de las veces creen estar hablando en los mismos
términos con el cliente, cuando en realidad proveen significados diferentes al mismo término.
Este fenómeno, ocasiona que los requerimientos no sean claros y que incluso lleguen a ser
definidos de forma incorrecta, muy alejada de lo que el cliente realmente requiere. En este
punto, es recomendable que el cliente se auxilie de sus ingenieros para la definición de los
requerimientos y también con el fin de lograr una mejor comunicación con el analista de
requerimientos.
3. Distintas percepciones de un mismo requerimiento. Diferentes usuarios pueden tener
visiones contradictorias o con distintas prioridades de un mismo requerimiento. Así mismo,
pudiera existir confusión en la definición de los requerimientos haciendo que los
requerimientos funcionales, no funcionales y las metas del sistema estén descritos de forma
confusa y no claramente separada.
4. Incapacidad de transmitir los requerimientos o la problemática. Los usuarios conocen su
trabajo y su sistema actual, pero no siempre pueden describir sus problemas a personas
externas.
5. Demandas poco realistas. Los usuarios con frecuencia no conocen realmente lo que desean
del sistema, y piden demandas irreales debido a que ignoran el costo de sus requerimientos.
95
Esto puede deberse a diversos factores. Por ejemplo, las demandas poco realista pueden
derivarse del hecho de que los clientes encargados de hablar con los analistas o con los
desarrolladores pueden no tener experiencia directa en hacer el trabajo que hacen los usuarios
del sistema actual. Así mismo, esto puede deberse también a que los desarrolladores conocen
soluciones al sistema, pero no siempre saben como afectarán las estas soluciones a las
actividades de negocio de los clientes. Finalmente, si la comunicación no se da de forma
fluida o si no está cuidadosamente organizada y fomentada entre el equipo de desarrollo y los
clientes, puede suceder que los requerimientos sean mal entendidos, que terminen
incompletos o que sean poco realista.
6. Que no se entienda el carácter dinámico y evolutivo de los requerimientos. El entorno
económico y de negocio en el que se desarrolla el software es dinámico y la importancia de
ciertos requerimientos puede cambiar. Después que los sistemas se instalan a satisfacción del
cliente, estos inevitablemente tenderán a demandar cambios a fin de permanecer útiles y
eficientes a la organización. Una vez que se realiza la instalación del sistema, nuevos
requerimientos pueden emerger y requerimientos existentes demandarán cambios. La
tecnología de la computación presenta cambios demasiado frecuentes y los sistemas de
software deben compensar estos cambios adaptándose y realizando los cambios que permitan
no quedarse atrás. Así mismo, con el uso del sistema, es posible que algunos errores no
detectados durante el desarrollo emerjan y tengan que ser corregidos. Es un hecho que no
existen sistemas de software perfectos, lo cual causará constantes cambios en el sistema ya
instalado. La evolución del software y su consecuente mantenimiento son actividades las
cuales que el cliente debe conocer y estar siempre de acuerdo en llevar a cabo. De esta forma,
es un hecho que la relación del cliente con los desarrolladores del sistema no termina cuando
el sistema es terminado y aceptado. Podríamos comparar un sistema de software con un
automóvil. Una vez que un automóvil es construido y comprado por alguna persona, este
tendrá que ir al taller mecánico en innumerables ocasiones para realizar distintos tipos de
reparaciones, mantenimiento y cambio de partes. No es posible decir que un automóvil nunca
terminará en algún taller de mecánico durante algún momento de su vida útil. Lo mismo
ocurre con cualquier sistema de software. Lo que ocurre es que en la actualidad no existen
talleres para mantenimiento o reparación del software, y los clientes deberán recurrir a los
desarrolladores originales o contar con su propio equipo de ingenieros de mantenimiento de
software. La inversión que distintas organizaciones realizan en sistemas de software en la
96
actualidad es de millones de dólares, y no invertir en mantenimiento y evolución puede llevar
a la organización a desechar continuamente el software que tantos esfuerzos costó desarrollar.
De hecho distintos estudios indican , que el 90 % del costo del software se dedica a el
mantenimiento y la evolución de los sistemas de software.
7. Mínimas especificaciones. En muchas ocasiones la definición de los requerimientos es
incompleta. Es decir que no satisface completamente las necesidades del usuario. En muchos
proyectos de software, existe una gran presión por terminar a tiempo y dentro del presupuesto
asignado. Esto obliga a especificar, diseñar, codificar o realizar pruebas lo mas rápido
posible. Todo proyecto que es desarrollado bajo presión siempre termina incompleto, con
errores o con poca satisfacción para el cliente o usuario. Este puede ser un error de los
clientes, si estos no dedican suficiente tiempo a especificar, o del los desarrolladores si no
planearon el proyecto de forma adecuada. Es importante decir que un software con
requerimientos completos puede fallar o presentar deficiencias durante la operación. Pero un
software con requerimientos incompletos no podrá bajo ninguna circunstancia satisfacer las
necesidades del cliente.
Como consecuencia de las dificultades antes descritas, el sistema de software a entregar podría
presentar los siguientes problemas:
•
Los requerimientos no reflejan las necesidades reales de los usuarios o de los clientes. El
cliente y los usuarios podrían no estar satisfechos con el sistema o con algunas de sus
funciones. En consecuencia, podrían no usar (o utilizar con muchas dificultades) algunas
funciones del sistema.
•
Los requerimientos son inconsistentes y/o incompletos.
•
Es caro realizar cambios en los requerimientos después de que estos han sido implementados.
•
Existen malentendidos entre los clientes y los desarrolladores del sistema.
•
El sistema se entrega tarde y los costos exceden a lo originalmente presupuestado.
•
El sistema es ser poco confiable y producir errores durante su funcionamiento.
•
Si el sistema continua en uso, los costos del mantenimiento y de la evolución del sistema
podrían ser bastante altos.
97
3.10 El costo de los requerimientos
En general, el costo de la Ingeniería de los requerimientos depende del tamaño y tipo del sistema
por desarrollar, y también de las actividades que implican los requerimientos en el desarrollo. En
algunos casos los requerimientos no están suficientemente claros y detallarlos lleva bastante
tiempo. En otros casos, los requerimientos cambian o tienden a evolucionar, y esto también
implica costos y tiempos de desarrollo extra. Los estudios llevados a cabo en la actualidad
indican que el costo económico de los requerimientos es del 10 al 15 por ciento del costo total del
desarrollo (referencia). Estas cifras corresponden a un proyecto que es llevado a cabo e
implementado con éxito. Sin embargo, muchos proyectos fallan
o no cumplen con las
necesidades del usuario.
El costo de reparar un error en los requerimientos se ilustra en la Figura 3.5. Los costos de
desarrollo cuando los requerimientos son erróneos es bastante mayor que cuando estos no
requieren ninguna reparación. Además, entre mas avanzada este el desarrollo, el costo de reparar
los requerimientos es más alto. Reparar errores en los requerimientos puede requerir trabajar
nuevamente en el diseño, la implementación y las pruebas. Es mucho más económico reparar un
error o requerimiento ambiguo en la etapa de requerimientos, que hacerlo en la etapa de
programación. El problema es que si se detecta durante la fase de programación que existe un
error en los requerimientos será necesario regresar hacia todas las etapas anteriores a corregirlo y
de nuevo validar los requerimientos.
100
80
60
40
20
0
R equerim ientos
D iseno
C odificación
P ruebas
Fases del D esarrollo
Figura 3.5. Costos relativos de corregir los requerimientos.
98
O peración
3.11 Técnicas de Obtención de Requerimientos
Las técnicas de obtención de requerimientos son aquellas que nos permiten comprender el
dominio del sistema, buscar y recolectar información para definir sus límites y restricciones, e
identificar a las personas interesadas en el sistema. El resultado permite obtener una colección y
clasificación de los requerimientos del sistema, mediante la participación de los clientes y
usuarios.
3.11.1
Entrevistas
La entrevista es una técnica para obtener información mediante una conversación dirigida por los
analistas a clientes y usuarios, con el objetivo de entender el dominio del problema y sus
necesidades. Se basa en un formato de preguntas y respuestas. El desarrollador buscará obtener
las opiniones de los clientes o usuarios entrevistados, sus opiniones del sistema, sus metas
personales, de la organización y de los procedimientos informales.
Existen cinco puntos que deben tomarse en cuenta para preparar una entrevista [10]
•
Lectura de antecedentes. Se debe hacer un previo estudio de antecedentes de los
entrevistados y su ambiente de trabajo, con ello se logrará conocer el lenguaje empleado
dentro de la empresa.
•
Establecer objetivos de la entrevista. Se establecen los objetivos de la entrevista en base a
los antecedentes y la experiencia personal.
•
Selección de los entrevistados. Se entrevista a gente clave de todos los niveles del sistema.
•
Preparación del entrevistado. Se debe de contactar a la persona que se entrevistará con
tiempo para que pueda reflexionar acerca de la entrevista.
•
Selección del tipo y la estructura de las preguntas. Escribir las preguntas que cubran los
aspectos fundamentales del objetivo de la entrevista, eligiendo el tipo y la estructura adecuada
de las preguntas de la entrevista.
Las preguntas tienen ciertas estructuras básicas que se deben conocer. Los dos tipos básicos de
preguntas son abiertas y cerradas.
99
•
Las preguntas abiertas permiten al entrevistado expresar
de manera flexible y en
consideración de su experiencia responder a lo que se le pregunta.
•
Las preguntas cerradas limitan las respuestas disponibles de los entrevistados mediante una
lista de opciones o alternativas de respuestas.
La entrevista puede estructurarse de las siguientes maneras:
•
Estructura de pirámide. En este caso, el entrevistador inicia con preguntas detalladas, del
tipo de preguntas cerradas, y luego realiza preguntas abiertas, de respuestas más
generalizadas.
•
Estructura de embudo. El entrevistador comienza haciendo preguntas abiertas de carácter
general y más adelante va utilizando preguntas cerradas.
•
Estructura de diamante. Combina las estructuras anteriores, el entrevistador comienza de
una manera muy específica, luego examina aspectos muy generales y finalmente llega a una
conclusión muy específica.
Las entrevistas deben registrarse ya sea por un cuaderno de notas o utilizando una grabación. Es
importante que al final de la entrevista se escriba un informe con el fin de asegurar la calidad de
los datos de la entrevista.
3.11.2
Cuestionarios
Es una técnica para obtener información que permite a los desarrolladores del sistema recopilar
opiniones, posturas, conductas y características de los diversos usuarios que son encuestados y
que se encuentran involucrados en la operación del sistema actual o en la implantación de un
sistema nuevo. Los cuestionarios son eficaces si la gente de la organización se encuentra dispersa
o si mucha gente está involucrada en el proyecto de sistema [10]. Al igual que en la entrevista, un
cuestionario puede redactarse usando preguntas abiertas o preguntas cerradas y es importante
usar un vocabulario que refleje el lenguaje de los involucrados en la organización. El uso de
preguntas cerradas en los cuestionarios permite a los analistas medir los resultados mediante
gráficas. Esta técnica suele combinarse con las entrevistas para mejorar la obtención de
información del sistema.
100
3.11.3
Puntos de Vista
En cualquier sistema existen varios tipos de usuarios que tienen diferentes intereses en los
requerimientos del sistema, es decir, existen diferentes puntos de vista para un problema. El
enfoque orientado a puntos de vista toma en cuenta estos diferentes puntos de vista y los utiliza
para organizar y estructurar tanto el proceso de obtención como los requerimientos [2]. Se toma
en cuenta la existencia de diferentes perspectivas y proporciona un esquema para descubrir
problemas con los requerimientos propuestos por diferentes usuarios.
Los puntos de vista pueden ser considerados como:
•
Una fuente o consumidor de datos, son responsables de producir o consumir datos.
•
Un marco de trabajo de la representación, se considera un tipo particular del modelo del
sistema.
•
Un receptor de servicios, son externos al sistema y reciben servicios de este.
Las lluvias de ideas y los puntos de vista orientados a eventos son técnicas que utilizan este
enfoque.
a) Lluvias de ideas
En esta técnica se identifican los servicios potenciales y las entidades que interactúan con el
sistema. Se lleva a cabo mediante una reunión entre el equipo de desarrollo y la empresa que
solicita el software. Las personas involucradas generalmente son los usuarios del sistema y los
administradores. En esta reunión todos expresan sus ideas sobre el problema y la posible
solución. Cada persona participa sin ser interrumpida, las ideas son anotadas dentro de un
diagrama de burbuja en un pizarrón, y no pueden ser criticadas por los demás participantes. La
figura 3.6 demuestra como son capturadas las ideas dentro de los diagramas de burbujas del
sistema SIV. Al finalizar la sesión, se realiza una recolección de ideas sin duplicidad [2].
101
3.11.4
Observación
En la mayoría de las organizaciones se realiza algún trabajo en el cual se involucran distintos
grupos de personas que cooperan para llevar a cabo distintas tareas. La naturaleza de esta
cooperación es a menudo compleja
y varía dependiendo de las usuarios involucradas, del
ambiente físico y de la organización en donde se realiza el trabajo. Los usuarios con frecuencia
encuentran dificultades para expresar la forma en como realizan sus tareas en la organización y la
forma en como cooperan con otras personas, por lo cual son necesarias técnicas y herramientas
para describir las actividades de los usuarios en la organización.
La observación es una técnica en donde el analista se sumerge en el ambiente de trabajo de los
usuarios, para observar el trabajo diario que éstos realizan anotando los aspectos importantes y
observando factores sociales y organizacionales que afecten el sistema. Existen dos enfoques de
esta técnica las cuales son la etnografía y grabar lo observado [11].
Figura 3.6 Lluvia de ideas para el sistema SIV.
102
a) Etnografía
Generalmente los sistemas de información se encuentran dentro de un contexto social y
organizacional en donde los requerimientos del sistema se derivan y se restringen conforme a este
contexto. La etnografía es una técnica que se utiliza para entender estos tipos de requerimientos
sociales y organizacionales. El desarrollador se involucra en el entorno laboral donde se instalará
el sistema para observar y anotar las tareas reales que se llevan a cabo. Esta técnica descubre
requerimientos implícitos que reflejan los procesos reales más que los formales en donde la gente
está involucrada, y permite descubrir los factores sociales y organizacionales que puedan afectar
al sistema [2].
Es difícil detallar la forma de llevar a cabo un estudio etnográfico, sin embargo existen algunas
guías para el uso de esta técnica (referencia libro kotonya y somerville).
1. Asumir que la gente que se está estudiando son buenas en su trabajo y busca formas no
estándares de realizar el mismo trabajo (o la misma actividad). Esa observación permitirá
encontrar la eficiencia desarrollada por los usuarios la cual se debe a su experiencia.
2. Es importante dedicar tiempo a conocer a los usuarios y desarrollar una relación de confianza.
Si los usuarios no confían en quienes los observan, pueden llegar a realizar sus actividades de
forma que oculten sus habilidades o alguna información relacionada con el sistema actual.
Los usuarios pueden desconfiar de los observadores si detectan que el sistema en uso será
transformado o cambiado por otro sistema y que tal vez ellos no serán capaces de seguirlo
usando. A fin de desarrollar confianza entre los usuario y los observadores, en principio los
usuarios deben conocer los objetivos del nuevo sistema y las razones por las que están siendo
observados.
3. Se deben escribir notas detalladas acerca de las actividades de los usuarios y verificadas en
distintos días de trabajo. El observador (etnógrafo) debe sacar conclusiones de su observación
a fin de analizarlas. Esto permitirá conocer a detalle el sistema actual y los requerimientos
que solicita el cliente.
4. Podría ser necesario también entrevistar a los usuarios o sacar video de sus actividades para
complementar las notas.
103
3.11.5
Escenarios
Los escenarios son parte básica de algunos métodos de análisis orientados a objetos, y son
representaciones de la forma en que el usuario interactúa con el sistema. En este esquema se
representan gráficamente las entradas, la salidas, el flujo de datos y el comportamiento del
sistema [11]. Los escenarios pueden agregar detalles a alguna acción mediante el diseño de
ejemplos de interacción entre el usuario y el sistema. Existen dos esquemas para esta
representación: mediante escenarios de eventos ó casos de uso.
a) Escenarios de eventos
Este enfoque se utiliza para documentar el comportamiento del sistema ante eventos específicos.
Los escenarios de eventos incluyen una descripción del flujo de datos y las acciones del sistema,
y documenta las excepciones que pueden ocurrir. Un escenario de evento es una instancia de un
caso de uso, es decir, nos representa una secuencia de sucesos que podrían ocurrir en una
situación dada [2].
En la Figura 3.7 se representa un diagrama de escenario de eventos para un cajero automático, en
donde el flujo normal de eventos es de izquierda a derecha y cada rectángulo indica alguna
acción del usuario. El usuario del cajero automático entra en el sistema introduciendo su tarjeta
de crédito y su número de identificación personal del cliente (PIN). Las flechas de la parte de
arriba de la figura indican acciones de control y muestran con texto las condiciones que deben
cumplirse para que se pueda pasar a la siguiente acción. Por lo tanto, si la tarjeta es válida y el
usuario es valido, entonces el control pasa la etapa de “seleccionar servicio”. Las excepciones se
muestran en la parte inferior de la figura, utilizando rectángulos contiguos, en donde primero se
indica la excepción y después la acción para manejo de la excepción. En esta caso, son el usuario
interrumpe las acciones después de ingresar la tarjeta, se producirá la excepción interrupción y se
regresara la tarjeta. Así mismo, después de introducir la tarjeta el sistema podría indicar las
excepción tarjeta invalida, o tarjeta robada, con lo cual el sistema retendría la tarjeta de crédito. Si
la tarjeta es valida, se pide el PIN y se valida. La validación de PIN produce la excepción PIN
incorrecto, con lo cual se permite volver a introducir el PIN. Si en una segunda vez se detecta un
PIN incorrecto, se regresa la tarjeta al usuario.
104
Figura 3.7 Escenario de eventos para transacciones de un cajero automático.
De la figura 3.7 se puede observar que los escenarios deben contener la siguiente información
(referencia Libro Kotonya y somerville):
1. Una descripción del estado del sistema antes de entrar al escenario. En este estado el sistema
esta en espera de obtener información sobre la tarjeta de crédito y el PIN.
2. El flujo normal de los eventos en el escenario, el cual se observa en la figura 3.7.
3. Las excepciones al flujo normal de los eventos. Por ejemplo, interrupción, tarjeta invalida,
tarjeta robada o PIN incorrecto (y las correspondientes acciones de manejo de excepciones).
4. Información sobre otras actividades que pueden estar ocurriendo al mismo tiempo. Como son,
comunicaciones con la computadora del banco, manejo de motores para aceptar o rechazar
tarjetas de crédito, etc.
5.
Una descripción del estado del sistema después de terminar el escenario. Al final, el sistema
podrá aceptar la selección de servicios del cajero automático.
La aplicación de esta técnica requiere del analista de requerimientos así como de los usuarios
finales. Ambos interesados deben trabajar junto con los ingenieros del cliente para definir cada
105
escenario, tomando nota de los comentarios, problemas y sugerencias. Una vez terminado el
diseño de algún escenario, el usuario debe simularlo para verificar que partes del escenario son
incorrectas, incompletas o poco factibles de implementar. El analista debe preguntar al usuario
sobre las acciones que se llevan a cabo actualmente, la forma en como se realizan las tareas,
quienes están involucrados en las tareas, y que sucede si las tareas se llevan a cabo de distinta
forma.
El tiempo de desarrollo de los escenarios puede ser largo ya que involucra de interacción con los
usuario y de entender las actividades y tareas del sistema.
b) Casos de uso
Los casos de uso son una técnica que se basa en escenarios para la obtención de requerimientos
[2]. En los casos de uso se especifican una secuencia de acciones, incluyendo variantes que el
sistema puede llevar a cabo y que producen resultados observables de valor para un actor
determinado [5]. En un modelo de caso de uso se puede identificar a un conjunto de actores
involucrados y su relación con varios casos de uso. Un conjunto de casos de uso representan
todas las posibles interacciones que ocurrirán en los requerimientos del sistema. Los actores
pueden tener las siguientes representaciones: personas, sistemas o hardware y cualquier de las
tres representaciones puede estar relacionada con un caso de uso.
Los requerimientos funcionales pueden estar representados mediante casos de uso y muchos de
los requerimientos no funcionales pueden estar asociados a ellos. En la notación gráfica de UML
(referencia), se representa a un actor con un símbolo de una persona. Un caso de uso se
representa mediante una elipse y la relación entre ellos se representa mediante una línea que
puede indicar el sentido de la relación. La Figura 3.8 representa un modelo de casos de uso para
una biblioteca.
Algunos analistas describen los casos de uso añadiendo texto a los diagramas, anotando todos los
detalles que ocurren en cada escenario. Para detallar más a los casos de uso, en UML se utilizan
los diagramas de secuencia, diagramas de actividad, diagramas de colaboración y diagramas de
estados (referencia).
106
Figura 3.8 Representación de casos de uso para una biblioteca.
3.11.6
Prototipos
Un prototipo es un versión inicial de un sistema de software que se utiliza para demostrar los
conceptos, probar las opciones de diseño y de forma general enterarse más acerca del problema y
sus posibles soluciones. La Figura 5.20 muestra los dos tipos de prototipos existentes.
107
Figura 5.20 Construcción de prototipos evolutivos y desechables.
3.11.7
Análisis de Protocolos
El análisis de protocolos es una técnica aplicada a un grupo de usuarios representativos, a quienes
se les pide que describan en voz alta sus actividades dentro del sistema. Así el desarrollador
podrá identificar las metas y submetas del negocio apreciadas por los usuarios.
3.11.8
Maestro/Aprendiz
Es una técnica en donde el papel del aprendiz es representado por los analistas o desarrolladores
y los usuarios representan al maestro. Los desarrolladores participan en un entrenamiento con los
usuarios finales del sistema. El aprendiz hace uso de la observación y podrá cuestionar sobre el
origen y significado de las tareas que realice. También, el aprendiz podrá realizar algunos
trabajos bajo la supervisión del maestro con el fin de proponer ideas o alternativas de solución. El
principal objetivo es proporcionar detalles al aprendiz sobre tareas específicas del usuario final
[18].
108
3.11.9
Despliegue de la Función de Calidad
Esta técnica (también conocida como “Quality Function Deployment”) fue propuesta por los
japoneses para determinar los requerimientos de calidad en la industria automotriz, se concentra
en maximizar la satisfacción del cliente [3]. El enfoque principal de QFD es la Función de
Calidad, en la cual se muestran las relaciones entre los requerimientos del cliente y las
características del producto mediante una matriz, en donde las filas representa los requerimientos
y las columnas representan los casos de uso (Tabla 3.1).
Requerimientos
Caso de uso 1
R1
X
Caso de uso 2
Caso de uso n
X
X
R2
R3
Caso de uso 3
X
X
…
Rm
X
X
Tabla 3.1 Función de Calidad.
En la función de calidad se marca la intersección que existe entre un requerimiento y los casos de
uso que lo implementan, verificando que todo requerimiento sea implementado por algún caso de
uso y que todo caso de uso represente algún requerimiento. Además se deben revisar que no
existan elementos repetidos (redactadas de diferentes maneras) o contradictorias tanto en la lista
de requerimientos como en los casos de uso.
3.11.10
Talleres de Trabajo basados en Casos de Uso (Run Use Case
WorkShop)
Los talleres de trabajo basados en casos de uso se realizan entre el cliente/usuario y el equipo de
desarrolladores [13]. Esta técnica consiste en dos tareas principales:
109
1. Generar los escenarios, mediante la aplicación de los casos de uso se puede conversar con
los usuarios para extraerles los detalles que ocurren cuando se realiza un evento determinado.
De esta manera se podrán definir los actores que participan y los pasos que se realizan para
algún el caso de uso. Se debe verificar con los usuarios si los pasos están bien descritos, o si
estos pueden ser modificados y mejorados.
2. Al término de la etapa anterior el equipo de desarrolladores describe y deduce los
requerimientos a partir del conocimiento previamente adquirido.
3.11.11
Análisis de los Interesados en el Sistema
Los interesados en el sistema (stakeholders) son las personas involucradas de alguna manera en el
sistema y que permiten asegurar el éxito del proyecto, por ejemplo los usuarios finales y sus
administradores, clientes y dueños del negocio, ingenieros de sistemas y programadores [12]. Es
importante encontrar a todos los grupos de interesados y conocer sus intereses. Durante el análisis
de interesados se debe tratar de encontrar respuestas a las siguientes preguntas [11]:
•
¿Quiénes son los interesados en el sistema?
•
¿Qué objetivos visualizan para el sistema?
•
¿Cómo podrían contribuir en el sistema?
•
¿Qué riesgos y costos ven?
•
¿Qué tipo de soluciones observan para el sistema?
Hay varias maneras de obtener esta información, puede obtenerse mediante una reunión grupal,
donde todos los interesados conocidos estén representados ó pueden citarse grupos pequeños de
interesados a reuniones. En caso de que esto fallara, puede entrevistarse a uno por uno del grupo
de interesados identificados.
3.11.12
Demostración de Tareas
La técnica de demostración de tareas es una variante de la entrevista y la observación, y consiste
en preguntar a los usuarios como realizan una tarea específica del sistema. Es útil cuando los
usuarios no pueden explicar lo que hacen en su trabajo diario, pero si pueden demostrar como
110
realizan tareas específicas. La demostración de tareas es una manera poco frecuente de observar
tareas críticas. A los usuarios se les hace más fácil demostrar como realizan sus tareas, que
explicar con palabras como se desarrollan las cosas incluso antes de que sean introducidas al
sistema actual. Otra aplicación de la demostración de tareas es la identificación de problemas de
utilidad, para la identificación de problemas de utilidad en un sistema nuevo es necesario algún
tipo de demostración de tareas [12].
3.11.13
Enfoque Grupal
Esta técnica (también conocida como “Focus Groups”) consiste en reuniones grupales donde se
fomenta la discusión abierta entre los participantes. La discusión proporciona al analista ideas de
cómo los usuarios piensan y sienten acerca de los aspectos del sistema. El enfoque grupal puede
ser utilizado para obtener requerimientos basándose en lo que los usuarios piensan que el sistema
podría abarcar. Por otro lado, esta técnica también usada durante las demás etapas del desarrollo
para evaluar prototipos y proporcionar validación y verificación del producto [19].
3.11.14
Talleres Futuros (Future Workshops)
Esta técnica es similar al enfoque grupal, pero es más estructurada y muy concreta en su alcance.
Consiste en que los participantes definan el estado futuro deseado del ambiente del sistema. Los
interesados se aseguran de que el alcance del sistema sea definido y respetado, además permite a
los participantes discutir el estado final deseado del sistema [14].
3.11.15
Estudio de Documentos/Datos
Esta técnica consiste en estudiar los documentos existentes tales como formas, archivos de datos,
bitácoras, documentación y base de datos del sistema existente. Se pueden analizar las pantallas
desplegadas por el sistema en uso, y las distintas impresiones en papel. Otra función de esta
técnica, es la de verificar la información recabada en las entrevistas realizadas a los usuarios y
111
clientes del sistema. En general, lo que se desea lograr es determinar el contexto y la información
detallada del sistema en la que los requerimientos están basados [15].
112
INDICE DE CONTENIDO
3. Obtención de Requerimientos
3.1.Comprensión del Problema
3.1.1.Comprensión del dominio de la aplicación.
3.1.2.Comprensión de las necesidades de los clientes y usuarios.
3.1.3.Requerimientos del negocio
3.2.Búsqueda y Recolección de Información
3.3.Definición de Límites y Restricciones
3.4.Definición de los interesados en el sistema
3.4.1 Roles y Actividades
3.5.Recolección y Clasificación de Requerimientos
3.6.Clasificación de Requerimientos
3.6.1 Identificación de los Elementos del Sistema
3.7 Características de calidad de los requerimientos
3.8 Factores que llevan a realizar cambios en los requerimientos
3.9 Dificultades para definir los requerimientos de software
3.10 El costo de los requerimientos
3.11.Técnicas de Obtención de Requerimientos
3.11.1.Entrevistas
3.11.2.Cuestionarios
3.11.3.Puntos de Vista
3.11.4.Observación
3.11.5.Escenarios
3.11.6.Análisis de Protocolos
3.11.7.Maestro/Aprendiz
3.11.8.Despliegue de la Función de Calidad (Quality Function Deployment)
3.11.9.Talleres de Trabajo basados en Casos de Uso (Run Use Case WorkShop)
3.11.10.Análisis de Usuarios Interesados (Stakeholder)
3.7.11.Demostración de Tareas
3.11.12.Enfoque Grupal (Focus Groups)
3.11.13.Talleres Futuros (Future Workshops)
3.11.14.Estudio de Documentos/Datos
113
Verificar:
1. Directores de proyecto.
2. 3.11.13. Talleres Futuros (Future Workshops)
Que es facilitadores ?
3. Verificar si las secciones 3.6 a la 3.10 deben mandarse al primer capitulo.
4. Explicar mejor y con mas detalle algunas de las técnicas de la seccion 3.11.
5. Alunas secciones presentan ejemplos de los conceptos y otras no presentas ejemplos.
6. Verificar en donde dice Sistema SIV.
7. Algunas de las técnicas de obtención son muy cortas o muy escuetas o tienen poco detalle,
pero que tanto detalle debe dárseles ?
114