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

70

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

71

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

72

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

73

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:

74

• 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.

75

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.

76

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.

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

78

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.

79

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).

80

• 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.

81

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 Actividades Analista de Requerimientos, Experto del

dominio, usuario

Este personal estará a cargo de entender el

problema y su definición.

Analista de requerimientos, usuario Están a cargo de especificar a detalle los

requerimientos.

Ingeniero de desarrollo de software,

administrador del proyecto

Están a cargo de seleccionar posibles prototipos

del sistema.

Ingeniero de requerimientos, Ingeniero de

desarrollo de software

Estarán a cargo de desarrollar el sistema o

prototipo.

Usuario, experto del dominio, analista de

requerimiento e Ingeniero de Desarrollo

Estarán a cargo de evaluar el sistema final o

prototipo.

Figura 3.3. Roles en el proceso de Ingeniería de Requerimientos

82

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 no-

funcionales, 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

83

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

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

84

Figura 3.4 Clasificación de los requerimientos.

Definiciones de datos

Restricciones

Reglas del negocio

Requerimientos funcionales

y no-funcionales

Casos de y escenarios

Ideas y soluciones

Requerimientos de interfaces

externas

Atributos de Calidad

85

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:

86

• 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.

87

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.

88

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.

89

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.

90

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

91

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 auto-

contenido, 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.

92

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.

93

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.

94

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

95

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.

96

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

97

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.

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.

Figura 3.5. Costos relativos de corregir los requerimientos.

100

80

60

40

20

0Requerim ientos Diseno Codificación Pruebas Operación

Fases del Desarrollo

100

80

60

40

20

0Requerim ientos Diseno Codificación Pruebas Operación

Fases del Desarrollo

98

99

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.

100

• 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.

101

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].

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

103

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.

104

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.

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

106

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).

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

109

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 Caso de uso 2 Caso de uso 3 Caso de uso n

R1 X X

R2 X

R3 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:

110

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

111

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

112

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].

113

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

114

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 ?