REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DE EDUCACIÓN SUPERIOR

UNIVERSIDAD BOLIVARIANA DE VENEZUELA
P.F.G. DE INFORMÁTICA PARA LA GESTIÓN SOCIAL
U.C. ANÁLISIS DE REQUERIMIENTOS

Guía Didáctica
Análisis de Requerimientos
 Septiembre, 2006
Índice

I. La Guía Didáctica...................................................................................................1
Introducción.....................................................................................................1
Objetivos de la Guía Didáctica........................................................................1
Instrucciones para el uso de la guía...............................................................1
II. La Unidad Curricular..............................................................................................1
Breve descripción de la Unidad Curricular.....................................................1
Objetivo General.............................................................................................2
Objetivos Específicos......................................................................................2
III. Contenido.............................................................................................................3
Tema I. Conceptos Básicos............................................................................3
Tema II. Elicitación de Requerimientos........................................................17
Tema III. Requerimientos Funcionales.........................................................51
Tema IV. Requerimientos No Funcionales...................................................60
Tema VI. Documento de Requerimientos.....................................................84
Tema VII. Estándares.................................................................................101

ii
iii
I. La Guía Didáctica
Introducción
El presente material ha sido desarrollado con la finalidad de proveer a los estudiantes,
documentación actualizada y relevante acerca del Análisis de Requerimientos. La guía
didáctica se elaboró partiendo de la recopilación de textos y publicaciones realizadas por
diversos autores, las cuales fueron, en muchos casos, traducidas y adaptadas al español
a fin de que pudiese ser comprendida por toda la comunidad estudiantil del Programa de
Informática para la Gestión Social.

Objetivos de la Guía Didáctica

Facilitar la comprensión de los conceptos asociados al Análisis de
Requerimientos de manera que los estudiantes puedan adquirir habilidades en la
recopilación de las necesidades del usuario. .

Instrucciones para el uso de la guía

La guía didáctica contiene inicialmente una breve descripción de la Unidad
Curricular para la cual fue diseñado el material así como los objetivos que se
plantean lograr. Posteriormente, se presenta el contenido temático indicando la
sección del documento donde se encuentra ubicado.
Se sugiere revisar correlativamente los temas de la Guía didáctica, partiendo
desde su introducción hasta sus últimos temas, de manera que pueda adquirir de
gradualmente las competencias necesarias para abordar las temáticas de mayor
complejidad. Sin embargo, si desea explorar de forma aleatoria el material, use el
índice general para ubicar el tema de su interés.

II. La Unidad Curricular

Breve descripción de la Unidad Curricular
El Análisis de Requerimientos comprende todas las actividades
involucradas en descubrir, documentar y mantener la mayor parte de la
información requerida para el desarrollo de un sistema de software. Se inicia
desde la primera etapa del proceso de desarrollo de software; reviste gran

1
importancia porque de ello depende, en buena medida, que el software responda
a las necesidades reales del usuario.

Objetivo General
Capacitar al estudiante para la obtención de la información en un dominio de
problema dado, haciendo uso de metodologías, técnicas y herramientas de la
Ingeniería de Requerimientos, como primer paso en el proceso de construcción
del Software.

Objetivos Específicos

▪ Adquirir una visión de la Ingeniería de Requerimientos como parte del proceso

de desarrollo de software, de su importancia, y de las diversas actividades que
la conforman.

▪ Emplear las diferentes técnicas del análisis de requerimientos para

comprender el dominio de un problema particular y recoger las necesidades de
los usuarios, en la Elicitación de requerimientos, en la documentación del
análisis, etc.

▪ Identificar los requerimientos funcionales y no funcionales que deberá cumplir

el sistema software a desarrollar. Expresar los requerimientos funcionales
mediante el modelo de casos de uso de UML.

▪ Comprender el proceso de Gestión de requerimientos, a fin de garantizar un

seguimiento a la solicitud de un cambio al software durante todo el ciclo de vida
del mismo, y compartir la información recogida en cada etapa con todos los
actores del proyecto.

▪ Definir la función y cada una de las partes del documento de requerimientos.

▪ Desarrollar un Documento de Requerimientos de Sistemas con base a un caso

de estudio.

2
▪ Aplicar los estándares para el modelado de sistemas, que permitan la
integración de diferentes sistemas.
III. Contenido

Tema I. Conceptos Básicos

Versión: 1.1

Éste tema es una traducción adaptada del libro:

Ian Sommerville y Pete Sawyer. Ingeniería de Requerimientos: Una buena guía
práctica. Jhon Wiley & sons,1998.

Realizado por: Profa. Mayra Pariata

Profa. Tahyca Pariata
Profa. Ana María Padrón

Revisado por: Prof. Nancy Zambrano UCV

Fecha: Septiembre de 2005

3
 Introducción
El desarrollo de sistemas basados en computadoras ha estado plagado de
problemas desde 1960. Los sistemas suelen ser entregados fuera del plazo
establecido, sobrepasar el presupuesto, no hacen lo que los usuarios realmente
desean y a menudo la gente nunca los utiliza a su máxima capacidad. Pocas
veces existe una sola razón para estos problemas, pero sabemos que un factor
que contribuye de manera importante es el relacionado con la investigación de los
requerimientos de los sistema que van a ser automatizados.
Los requerimientos del sistema definen cuáles servicios debe proporcionar
el sistema y precisan los posibles conflictos en su implementación. Los problemas
comunes que se presentan con los requerimientos del sistema son los siguientes:
1) Los requerimientos no reflejan las necesidades reales de los usuarios del
sistema.
2) Los requerimientos son inconsistentes y/o incompletos.
3) Es costoso hacer cambios a los requerimientos, luego que han sido
aprobados.
4) Hay malentendidos entre los usuarios, los que desarrollan los
requerimientos del sistema y los ingenieros de software que construyen o
mantienen el sistema.

La mejor manera de reducir estos problemas es mejorar el proceso de

elicitación, comprensión, negociación, descripción, validación y gestión de los
requerimientos del sistema. La mejor forma de hacerlo es gradualmente,
introduciendo o modificando los procedimientos, cada cierto periodo de tiempo.
Sugerimos que el cambio de proceso sea gradual. Es difícil determinar si un
proceso radicalmente diferente seria efectivo.
Por lo tanto, los principios que se plantean se piensan como un apoyo al
acercamiento gradual a los mejores procesos. Se basan en una buena práctica de

4
la ingeniería de requerimientos. Su rango va desde principios muy simples,
pudiera decirse que están basados en el sentido común (pero que son fáciles de
pasar por alto), pasando por las sugerencias para introducir nuevos métodos y
técnicas para descubrir y analizar los requerimientos del sistema.
Este capitulo introduce la noción de ingeniería de requerimientos 1 y mejoras
en el proceso de ingeniería de requerimientos. Para simplificar la presentación, se
organiza como un conjunto de preguntas y respuestas sobre el análisis de
requerimientos.

1.1 ¿Que son los requerimientos?

Son descripciones de cómo el sistema debería comportarse, o de una
propiedad o atributo que deba tener el sistema. Constituyen exigencias al inicio del
proceso de desarrollo de un sistema. Los requerimientos son definidos durante las
primeras etapas del desarrollo de sistemas como una especificación de lo que
debería ser implementado. Por lo tanto un requerimiento debería describir:
- La funcionalidad deseada por los usuarios.

- Un nivel de destreza del usuario (por ejemplo: “el procesador de palabras

debería incluir comandos para corrección de palabras”).

- Una característica muy general del sistema (por ejemplo: “el sistema debe
asegurarse que la información personal nunca esté disponible a un usuario
no autorizado”).

- Una necesidad específica del sistema (por ejemplo: “el tiempo de respuesta
de una operación debe ser inmediato”).

- Una necesidad tecnológica en el desarrollo del sistema (por ejemplo: “el

sistema se debe desarrollar usando a Java”).

1
El término Ingeniería de requerimientos es usado en la literatura y en particular en el libro
referenciado, sin embargo otros autores prefieren hablar de análisis de requerimientos y reservar el
término “ingeniería” para el área más general “ingeniería de software”. Aquí se utilizarán
indistintamente.

5
 Un requerimiento es una condición que debe incorporarse al sistema o
software a fin de dar respuesta a una problemática, satisfacer un estándar o una
especificación. La obtención de los requerimientos de un software, se produce a
través del empleo de diversas herramientas (técnicas de elicitación) que son
aplicadas a los usuarios y otros actores para conocer el flujo de la información. En
estos instrumentos se hace alusión a interrogantes como: ¿Qué es lo que se
hace?, ¿Cómo se hace?, ¿Con qué frecuencia se hace?, ¿Existe algún problema?
Los requerimientos deben manifestarse en forma concisa, precisa, identificable y
verificable a fin de que puedan contribuir a la definición de una solución óptima.
Algunas personas sugieren que los requerimientos siempre sean
descripciones de qué debe hacer el sistema, más que una descripción de cómo
debe hacerlo. Esta es una idea atractiva pero es demasiado simplista en la
práctica, ya que:
1) Los lectores de un documento de requerimientos pueden ser expertos, que
pueden relacionarse con las descripciones prácticas mucho mejor que con
descripciones muy abstractas del problema. En todo caso hay que escribir los
requerimientos de tal forma que sean comprensibles a esos lectores del
documento.
2) En casi todos los casos, el sistema que es especificado es solamente uno de
varios sistemas en un ambiente. Debe ser compatible con su ambiente, y
adaptarse a los estándares e inquietudes de la organización, puede que se
tengan políticas específicas de implementación las cuales limitan las opciones
de los analistas.

Por lo tanto, los requerimientos contienen invariablemente una mezcla de la

información del problema, las descripciones del comportamiento del sistema y las
características y las necesidades de diseño.

1.2 ¿Qué es la Ingeniería de requerimientos?

La ingeniería de requerimientos (o análisis de requerimientos) es una
actividad de la Ingeniería del Software en la cual se elicitan, recopilan, analizan,

6
verifican y mantienen las necesidades de los usuarios de manera clara, sin
ambigüedades, en forma consistente y completa. Esta actividad se realiza desde
la primera etapa en el proceso de desarrollo de software y a lo largo del todo el
proceso de desarrollo.
La Ingeniería de Requerimientos en un término relativamente nuevo el cual
se ha inventado para cubrir todas las actividades involucradas en la elicitación,
documentación, análisis, verificación y mantenimiento de un conjunto de
requerimientos para un sistema basado en computadoras. Esta actividad se sitúa
en el dominio del problema. El uso del término ingeniería implica que deben ser
usadas técnicas sistemáticas y repetibles para asegurar que los requerimientos
del sistema sean completos, consistentes, relevantes, entre otros. Es usual utilizar
los términos Ingeniería de Requerimiento y Análisis de requerimientos para
referirse al mismo concepto. En la literatura en español también se encuentra la
palabra requisitos en lugar de requerimientos.

1.3 ¿En que consiste la elicitación de requerimientos?

Consiste en el descubrimiento, la indagación, y la especificación de los
requerimientos de los usuarios y otros interesados en el sistema a desarrollar.
Requiere una comprensión del dominio del problema y técnicas que ayudan a
conseguir la información relevante.
Es el proceso donde se recogen los requerimientos de un sistema mediante
la comunicación con los usuarios y otros beneficiarios del sistema (stakeholder) 2.
Es la definición del sistema en función de lo quiere el usuario y lo que realmente
necesita.

1.4 ¿Qué es un Documento de Requerimientos?

El documento de requerimientos es usado para comunicar los
requerimientos del sistema a los usuarios, desarrolladores del software, clientes,
2
Una interpretación del término stakeholder pudiera ser usuarios y otros beneficiarios en el sistema
(clientes, directivos, desarrolladores, equipo de soporte técnico, etc.). En alguna literatura se le
traduce como actores, pero entra en conflicto con el significado del mismo término en el modelo de
casos de uso, sin embargo podría utilizarse, entendiendo el contexto.

7
directivos y a todos los interesados en el sistema. Se obtiene como resultado de la
actividad de análisis (elicitación, etc.) y es un material que permite plasmar
tangiblemente las actividades desarrolladas y su resultado.
Dependiendo de la organización, el documento de requerimientos puede
tener diversos nombres tales como la especificación funcional, la definición de los
requerimientos, la especificación de requerimientos del software, entre otros. Se
usará, en lo sucesivo, el término Documento de requerimientos.

1.5 ¿Cuál es la mejor forma de escribir requerimientos?

No existe “la mejor forma de escribir requerimientos”. Esto depende de la
práctica normal de la organización, de los usuarios finales y otros involucrados a
quienes va dirigido y de las notaciones que sean utilizadas por los escritores y los
lectores de los requerimientos. Los requerimientos se pueden describir en un
lenguaje que refleje el ambiente de la fuente del requisito. Si la fuente es un
ingeniero, puede ser escrito en términos de la ingeniería; si la fuente es un usuario
cualquiera, será escrito en lenguaje natural. Se escriben la mayoría de los
requerimientos en lenguaje natural complementadas con diagramas y tablas con la
información detallada.

1.6 ¿Cuan detallados deberían ser los requerimientos?

No hay una respuesta fácil a esta pregunta. Diferentes organizaciones
piensan de los requerimientos en formas diferentes y escriben sobre ellos en
distintos niveles de detalle. Un requerimiento para controlar un motor debe incluir
detalles sobre las señales de control que serán usadas; un requerimiento para
gestionar información para usuarios debería contener simplemente la información
a ser provista. El analista del sistema decide como organizar y presentar la
información.
El nivel del detalle que se necesita depende en gran parte de la práctica
normal en la organización, si el documento de requerimientos será la base de una
negociación para el desarrollo del software o no y del tipo de sistema que se esté

8
desarrollando. Puede que se requiera una especificación bastante general o una
especificación mucho más detallada.
En algunas organizaciones, los requerimientos primero se expresan como
descripción informal del alto nivel, que es desarrollada posteriormente en una
especificación más detallada. Los requerimientos generales son los
requerimientos de los usuarios y otros beneficiarios del sistema (todos los
involucrados o interesados en el sistema, usuarios finales, desarrolladores del
software, directivos involucrados, los que financian, etc.) y los requerimientos
detallados son una especificación de sistema más orientada a los desarrolladores.
1) Los requerimientos de los usuarios. Estos son requerimientos escritos desde el
punto de vista de todos los beneficiarios del sistema. Por lo general no son
expresados con gran detalle. Son descritos en lenguaje natural, diagramas
informales o usando alguna notación que es apropiada al problema que está
siendo solucionado.
2) Requerimientos del sistema. Estos son especificaciones más detalladas de los
requerimientos que pueden ser expresadas como un modelo abstracto del
sistema. Puede ser un modelo expresado mediante diagramas de UML. Estos
modelos siempre son comentados en lenguaje natural.
Generalmente es cierto que los requerimientos del sistema son más
detallados que los requerimientos orientados a los usuarios y otros interesados.
Sin embargo, hay excepciones y, en ambos casos, las exigencias pueden ser
descritas en detalle o de un modo abstracto o en cualquier forma intermedia.

1.7 ¿Cuál es la diferencia entre los Requerimientos Funcionales y No

Funcionales?
Los requerimientos funcionales describen lo que el sistema debería hacer.
Los requerimientos no funcionales son requerimientos de carácter técnico
relacionados con el diseño, operatividad y propiedades del sistema. Comprende
aspectos como comunicación, interfaz de usuario, y otras cualidades que debe
cumplir el sistema (portabilidad, confiabilidad, etc.). Los requerimientos no
funcionales incluyen las restricciones a las funcionalidades requeridas. Una

9
restricción limita la funcionalidad u operatividad de algún componente del software
en desarrollo.
Un requerimiento funcional podría establecer que el sistema debe realizar
una tarea (por ejemplo: autenticar la identidad del usuario del sistema); un
requerimiento no funcional podría establecer restricciones sobre esa tarea (por
ejemplo: que el proceso de autenticación deba ser completado en cuatro
segundos o menos).
Sin embargo, no siempre es tan simple. El mismo requerimiento funcional
de autenticación podría tener un requerimiento suplementario que establezca el
uso de un sistema específico de verificación de firma (el cual se sabe que trabaja
en menos de cuatro segundos) para la autenticación. Esto podría ser interpretado
como un requerimiento funcional o no funcional según la definición anterior. Los
requerimientos no funcionales de alto nivel a menudo son traducidos en
requerimientos funcionales del sistema.

1.8 ¿Quienes son los beneficiarios (stakeholders) del sistema?

Los beneficiarios del sistema son personas que serán afectadas por el
sistema y quienes tienen directa o indirectamente influencia sobre los
requerimientos del sistema. Esto incluye usuarios finales del sistema, directivos de
la organización y otras personas involucradas en el proceso organizacional al cual
va dirigido el sistema, usuarios de la organización, los cuales usaran el sistema
para realizar una tarea, entes externos como autoridades de regulación y
certificación, entre otros.
Por ejemplo, debe desarrollarse un sistema de información geográfica para
el Ministerio del Ambiente. Los posibles Beneficiarios son, entre otros:
- Geógrafos.
- Directivos del Ministerio del Ambiente.
- Analistas, desarrolladores de software y especialista en interacción
humano-computador.
- Los usuarios finales.

10
 Recomendamos que se realice una lista explicativa de beneficiarios en la
primera etapa de su proceso de análisis de requerimientos.

1.9 ¿El tamaño del sistema hace la diferencia?

El tamaño del sistema hace una tremenda diferencia. Los problemas en el
análisis de requerimientos se incrementan exponencialmente con el tamaño del
sistema. Muchos sistemas militares son gigantescos; en éstos, el documento de
requerimientos se organiza en varios volúmenes con miles de requerimientos
individuales. El problema de escala es importante. Muchos sistemas no soportan
ciertos niveles de escalamiento.
El análisis de requerimientos para estos sistemas de gran tamaño a
menudo requiere notaciones, herramientas y técnicas de propósito especial. Los
principios sugeridos son provechosos para todos los tipos de análisis de
requerimientos de sistemas, pero sabemos que algunos de ellos no aplican para
sistemas muy grandes. El problema del manejo de la información es tan grande
que los principios no pueden ser aplicados.

1.10 ¿Qué es el proceso de Ingeniería de Requerimientos?

Un proceso de análisis de requerimientos es un conjunto estructurado de
actividades las cuales se siguen para realizar, validar y mantener un documento
de requerimientos del sistema. Una descripción completa del proceso debe incluir
qué actividades se llevan a cabo, la estructura o listado de éstas, quien es el
responsable de cada una, las entradas y salidas de cada una y las herramientas
usadas para soportar el análisis de requerimientos.
Muchas organizaciones tienen un proceso de análisis de requerimientos
definido explícitamente y estandarizado. Ellos simplemente definen el resultado
del proceso de análisis de requerimientos en el Documento de Requerimientos.
Las personas envueltas en el proceso son responsables para decidir que hacer y
cuando hacerlo, que información necesitan, que herramientas podrían usar, entre
otros.

11
 La definición de un proceso de análisis de requerimientos apropiado para la
organización beneficiará a la misma. Una buena descripción del proceso
proporcionará una dirección a las personas implicadas y reducirá la probabilidad
que las actividades sean olvidadas o realizadas de un modo superficial.
1.11 ¿Como reconozco los problemas del Proceso de Ingeniería de
Requerimientos?
Puede reconocer problemas del proceso que sigue en el análisis de
requerimientos, con la información sobre el proceso y/o la información sobre el
producto.
Si su respuesta es “sí” para alguna o todas las preguntas siguientes, debe
mejorar el proceso del análisis de Requerimientos.
1. ¿Su proceso de análisis de requerimientos generalmente está sobre
presupuestado y/o toma más tiempo de lo estimado?
2. ¿Las personas implicadas en el análisis de requerimientos se quejan de
que no tienen suficiente tiempo o recursos para hacer su trabajo
correctamente?
3. ¿Hay quejas sobre la comprensión o el acabado de los Documentos de los
Requerimientos que se elaboran?
4. ¿Los diseñadores de sistema se quejan de tener que hacer cambios
constantemente como resultado de los errores en los requerimientos?
5. ¿Los usuarios de sus sistemas no pueden utilizar todas las capacidades del
sistema?
6. ¿Hay un volumen muy alto de peticiones de cambio inmediatamente
después que un sistema se entrega a los usuarios?
7. ¿Toma mucho tiempo modificar el sistema para nuevos requerimientos?
Si su respuesta es no a todas estas preguntas, puede parar de leer ahora.
No necesita los consejos de este libro.

12
 1.12 ¿Pueden sugerir un buen proceso de Ingeniería de Requerimientos?
No podemos sugerir nada sin conocer antes la organización3, sus
estándares, el proceso de desarrollo de software que adelantan y el tipo de
software a desarrollar. Hay muchos caminos posibles para organizar el proceso de
análisis de requerimientos y no se pueden pasar de una organización a otra. Para
definir un buen proceso de análisis de requerimientos, usted necesita involucrar a
las personas de su organización que están relacionadas con el sistema a
desarrollar. Debería buscar ayuda de otros especialistas, ellos pueden tener otra
perspectiva del sistema que aquellos involucrados en el proceso.
La mayoría de los estándares que se han desarrollado para la Ingeniería de
Requerimientos se refieren a salidas del proceso, tales como la estructura del
Documento de Requerimientos. Sin embargo, un buen proceso de la Ingeniería de
Requerimientos debe incluir las actividades siguientes:
1. Elicitación de requerimientos. Los requerimientos del sistema se descubren
con la consulta a los usuarios y otros beneficiarios, los documentos del
sistema, el conocimiento del dominio y de estudios de mercado.

2. Análisis y negociación de requerimientos. Los requerimientos se analizan

detalladamente, y los usuarios y otros beneficiarios deben participar en el
proceso para decidir cuales requerimientos serán aceptados.
3. Validación de requerimientos. Esto debe ser un chequeo cuidadoso de los
requerimientos para la consistencia y lo completo.
Para apoyar estas actividades, y para manejar los cambios a los
requerimientos se debe introducir un proceso de gestión de requerimientos.

3
A lo largo del tema nos hemos referido a las organizaciones en forma genérica, ello puede
significar empresas, instituciones, dependencias gubernamentales, educativas, etc., así como
organizaciones más informales: de las comunidades, organizaciones temporales en función de
objetivos inmediatos, etc.

13
 1.13 ¿Cómo se relaciona el análisis de requerimientos con las otras
actividades en el proceso de desarrollo del software?
La Ingeniería de Software posee etapas fundamentales que comprenden el:
análisis, diseño, programación, prueba y mantenimiento del Software. La etapa de
análisis es muy importante, ya que en ella se genera una fluida comunicación con
el usuario –y otros interesados en el sistema- y se revelan las necesidades del
sistema, se define el objetivo, los alcances, su factibilidad y se establecen todas
las funcionalidades. El proceso de desarrollo del software se basa en la
documentación producida en el análisis de requerimientos, y puede pensarse que
es la entrada al proceso, sin embrago a lo largo del mismo se pueden descubrir
nuevos requerimientos, o se modifican, constituyendo un proceso iterativo en este
sentido.

1.14 ¿Porqué es importante validar los requerimientos?

La validación de requerimientos es la etapa en donde se demuestra que los
requerimientos que se definen para el sistema son los que el usuario realmente
quiere y necesita. El proceso de validación es muy importante, ya que los costos
de errores en los requerimientos en las primeras etapas del desarrollo, son altos.
Al momento de chequear los requerimientos se pueden realizar las
siguientes preguntas:
- ¿Provee el sistema las funciones que mejor soporten las necesidades del
usuario?

- ¿Existen conflictos en los requerimientos?

- ¿Están incluidas todas las funcionalidades requeridas por el usuario?

- ¿Pueden los requerimientos ser implementados con la tecnología y el

presupuesto disponible?
La existencia de errores en los requerimientos después de realizado en
desarrollo de un proyecto, trae como consecuencias costos muy elevados en el
mantenimiento, por lo cual es muy importante la validación de los requerimientos.

14
 1.15 ¿En que consiste la gestión de requerimientos?
La gestión de requerimientos tiene que ver con todo el proceso involucrado
en los cambios de los requerimientos. Para ello se definen políticas para la gestión
de los cambios, se identifican los requerimientos volátiles, los requerimientos
globales, etc.
Una revisión regular puede ayudar mientras se realiza la definición de
requerimientos. Tanto el usuario como el equipo de desarrollo deben estar
involucrados en la revisión. Esta revisión debe ser formal (con los documentos
completos) o informal. Una buena comunicación entre desarrolladores y usuarios
puede resolver problemas en las primeras etapas.
Al momento de realizar la revisión de los requerimientos se pueden
responder, para cada requerimiento, las siguientes preguntas:
- ¿Es el requerimiento realmente necesario?

- ¿Es el requerimiento comprendido apropiadamente?

- ¿El origen del requerimiento está claramente establecido?

- ¿Puede el requerimiento ser cambiado sin causar un gran impacto en otros

- requerimientos?.

1.16 ¿Dónde se ajusta la ISO 9000?

Los estándares son pautas establecidas previamente en una organización o
ente para el desarrollo del proceso de análisis de requerimientos en sus diversas
etapas (elicitación, documentación, entre otras). Cada institución, empresa tiene
definido sus estándares.
La ISO 9000 es un estándar para los Procesos de la Gerencia de la
Calidad, y variantes de este estándar han sido desarrolladas para la Ingeniería de
Software. Sin embargo, la ISO 9000 no dice nada sobre la Ingeniería de
Requerimientos. Pero existe una tendencia natural en muchas organizaciones, en
orientar las actividades de acuerdo a los estándares ISO 9000. Nuestra opinión es
que los procesos se mejoran incluyendo buenas prácticas en los procesos
definidos. Todas nuestras sugerencias están conformes con estándares

15
existentes. Pueden ser introducidas sin comprometer ninguna certificación de la
ISO 9000.

Bibliografía
- Ian Sommerville y Pete Sawyer. Requirements Engineering. A Good
Practice Guide. Lancaster University. Ed. Jhon Wiley &sons,1998
- Senn, James A. Análisis y Diseño de Sistemas de Información. Segunda
Edición. McGraw Hill. 1992.
- Durán A. y Bernárdez B. Metodología para la Elicitación de Requisitos de
Sistemas Software Versión 2.3. Universidad de Sevilla. Abril 2002.
URL:
http://www.lsi.us.es/~amador/publicaciones/metodologia_elicitacion_2_3.pdf
.zip.
- Soren Lauesen. Software Requirements. Styles and Techniques.
Samfundslitteratur, 1999

Actividades sugeridas al grupo docente y a los estudiantes

1. Identificar las palabras clave del tema (terminología).
2. Asignar una investigación documental de la terminología básica.
3. Realizar una tormenta de ideas en relación con cada término.
4. Solicitar la elaboración de mapas conceptuales

Actividades propuestas al estudiante

1. Elaborar una ficha por cada término, asociándolo con palabras claves.
2. Leer la bibliografía sugerida a fin de profundizar el tema.
3. Describir las actividades que se realizan en el análisis de Requerimientos.
4. Relacionar la actividad de análisis de requerimientos con las otras
actividades que se desarrollan en el proceso de desarrollo de software.
5. Interpretar el siguiente diagrama:

16
 Tema II. Elicitación de Requerimientos
Versión: 1.2

Éste tema es una traducción adaptada del siguiente material:

1. Ian Sommerville y Pete Sawyer. Requirements Engineering. A Good
Practice Guide. Cap. 4. Lancaster University. Ed. Jhon Wiley &sons,
1998.
2. Soren Lauesen. Software Requirements. Styles and Techniques. Cap.4
Samfundslitteratur, 1999.

17
 3. Durán A. y Bernárdez B. Metodología para la Elicitación de Requisitos
de Sistemas Software Versión 2.3. Informe Técnico LSI-2000-10
(revisado). Universidad de Sevilla. Abril 2002.
URL:
http://www.lsi.us.es/~amador/publicaciones/metodologia_elicitacion_2_3.pdf.zip

Realizado por: Profa. Mayra Pariata

Profa. Tahyca Pariata
Profa. Ana María Padrón

Revisado por: Prof. Nancy Zambrano UCV

Fecha: 21 de Septiembre de 2005

2.1 Elicitación de Requerimientos

La Elicitación de requerimientos es el proceso mediante el cual se
descubren las necesidades y propiedades de un sistema a partir de la
comunicación con los usuarios y todos los beneficiarios del sistema (stakeholder)4.
Es la conceptualización del sistema en función de lo quieren los usuarios y otros
beneficiarios y lo que realmente necesitan. Esto requiere del conocimiento del
dominio de la aplicación y de los problemas específicos de la organización o
comunidad a la cual va dirigida la aplicación.
Los requerimientos deben expresarse en forma concisa, precisa, identificables y
verificables a fin de que puedan contribuir a la solución y, en particular deben ser
entendibles por los usuarios y otros beneficiarios del sistema.
La elicitación no es un proceso de un paso. Típicamente, primero se
investiga el dominio del problema y se recoge la información acerca del trabajo
actual y la situación presente, luego se detectan los problemas. Posteriormente, se

4
Una interpretación del término stakeholder pudiera ser usuarios y otros beneficiarios en el sistema
(clientes, directivos, desarrolladores, equipo de soporte técnico, etc.). En alguna literatura se le
traduce como actores, pero entra en conflicto con el significado del mismo término en el modelo de
casos de uso, sin embargo puede utilizarse, entendiendo el contexto.

18
muestran posibles soluciones y finalmente se establecen los requerimientos a
partir de la información recolectada.
El propósito del nuevo sistema es servir a los usuarios y otros beneficiarios,
generalmente de una organización5 entonces ¿Porqué no preguntarle, a ellos, que
necesitan?, desafortunadamente esto no es tan fácil, y de allí que se proponen
diversas técnicas.

2.2 Problemas en la Elicitación de requerimientos

- En la mayoría de los casos, muchos de los usuarios no tienen claro lo que
necesitan. En general sienten que tienen problemas. Hay también una
tendencia a exagerar problemas cotidianos y olvidar otros problemas más
serios. Incluso si ellos detectan bien los problemas, hay un proceso largo para
formular las necesidades. Como primer paso, el analista puede simplificar la
formulación de necesidades descartando los problemas no relevantes, en
unión con los usuarios y otros beneficiarios del sistema.
- Muchos usuarios pueden tener grandes dificultades para explicar las tareas
que ejecutan. Aún más difícil es explicar porque las hacen.
- A menudo los usuarios y otros beneficiarios especifican una solución en lugar
de un requerimiento.
- Puede suceder que los usuarios encuentren difícil imaginar nuevas formas de
hacer cosas, o imaginar las consecuencias de hacerlo de una manera
diferente. Por ejemplo, tomó tiempo internalizar que el problema de conectar
personas a través del teléfono podía solventarse, en parte, a través de una
nueva tecnología: el correo electrónico. Además, la introducción del correo
electrónico cambió los patrones de trabajo en una forma que nadie había
imaginado.
- A menudo diferentes actores tienen visiones en conflicto. Por ejemplo, para un
equipo de mercadotecnia los tiempos de entrega óptimos es un requerimiento
importante, mientras que para el equipo de producción ello puede incidir en
sobre tiempos de trabajo.
- Los usuarios pueden rechazar propuestas debido a una resistencia al cambio.
Por ejemplo, cuando el procesador de texto se introdujo como herramienta de
trabajo, las secretarias eran renuentes (dado que esto cambiaba la forma
tradicional de trabajo y era difícil de aprender). Sin embargo, posteriormente se

5
A lo largo del tema nos referimos a las organizaciones en forma genérica, ello puede significar
empresas, instituciones, dependencias gubernamentales, educativas, etc., así como
organizaciones más informales: de las comunidades, grupo de personas que se unen para fines
específicos, etc.

19
 transformó en una herramienta indispensable. Parte de la resistencia era
simplemente la dificultad de imaginar una nueva forma de trabajo.
- Una vez que el analista logra involucrar a los distintos grupos de usuarios y
otros beneficiarios en el proceso de identificación de los requerimientos, puede
surgir otro problema. Cada grupo establece requerimientos diferentes. algunos
de ellos son esenciales, otros son no relevantes. Puede ser difícil que todos los
actores estén de acuerdo en lo que es esencial y lo que no es. Son diferentes
visiones.
- Las demandas cambian con el tiempo, los factores externos cambian y las
prioridades también. Una vez que una necesidad es satisfecha, nuevas
demandas aparecen.

2.3 Cosas que elicitar

No es posible obtener los requerimientos directamente al inicio del proceso
de elicitación. Los requerimientos son el resultado final del proceso de elicitación,
y usualmente se requieren resultados intermedios. Esta es una lista de resultados
a obtenerse desde el inicio, durante y al final de la elicitación:
a) Comprensión del dominio del problema.
b) Una lista de problemas presentes en el dominio.
c) Una lista de exigencias y las metas críticas (requerimientos preliminares).
d) Ideas para el sistema futuro.
e) Posibilidades realistas.
f) Compromiso de los usuarios y otros beneficiarios.
g) Resolución de conflictos entre los usuarios y otros beneficiarios.
h) Requerimientos finales.
i) Priorizar los requerimientos.
j) Comprobar que los requerimientos son necesarios, estén completos.
Como analista, no se puede obtener todo en un solo paso. Inicialmente,
incluso pueden encontrarse algunos problemas aparentemente críticos y después
cambiarse esta prioridad. En la práctica, en el proceso se realizan muchos
cambios.

20
 Un producto de este trabajo muy importante es la lista de exigencias y
metas críticas. Estos son los requerimientos informales que serán luego serán
verificados.

2.4 Lineamientos para la elicitación de requerimientos.

Para realizar el proceso de la elicitación se sugieren una serie de
lineamientos:
1) Evaluar previamente la factibilidad del sistema.
Antes de realizar el análisis de los requerimientos del sistema, previamente se ha
debido realizar un estudio de factibilidad, A fin de evaluar si el sistema es en
realidad necesario y tecnológicamente realizable y si puede ser integrado al
ambiente de la organización.
Los beneficios de este estudio, para la realización del análisis de
requerimientos, son:
- Para realizar un estudio de factibilidad, necesitan plantearse los objetivos del
sistema de forma explícita. Los objetivos representan los motivos
fundamentales para el desarrollo de sistema. Los requerimientos que son
descubiertos durante el proceso de elicitación deben ser compatibles con estos
objetivos.
- El estudio probablemente revela las fuentes de información sobre el sistema
que deberían consultarse durante la elicitación de requerimientos.
Esta actividad es previa al análisis de los requerimientos y existen técnicas
sencillas y poco costosas para su realización.

2) Ser Sensible a las consideraciones políticas y organizacionales

Cuando realice la elicitación de los requerimientos, debe ser sensible a los
factores políticos y organizacionales ya que ello ayuda a comprender la cultura de
la organización, sus valores, la moral y otros aspectos concretos. Ello va a permitir
entender el porqué de algunos requerimientos que son demandados, porqué se
les da la mayor importancia, porqué otros son ocultados, etc..
La aplicación exitosa de este lineamiento depende de la sensibilidad de los
analistas involucrados en el proceso de elicitación. Algunas personas parecen
tener mayor conciencia acerca de las consideraciones políticas; otros tienen un

21
punto de vista más técnico y encuentran difícil el hecho de relacionarse con la
política intangible de organización.
Cuando se realice la elicitación de requerimientos, existen un número de
cosas que se deben observar, en particular aspectos políticos y de la organización
que pueden tener influencia sobre los requerimientos, puede señalarse:
- Metas conflictivas. Puede suceder que no todas las personas dentro de la
organización tengan las mismas metas. Trate de entender las razones.
- Las relaciones de poder y el impacto del nuevo sistema. Puede suceder que
este impacto signifique transferencias –o pérdidas- de responsabilidades en
algunos actores, ello puede revelarse en la elicitación de requerimientos por las
sugerencias de éstos. De allí que debe tratarse de entender la estructura de
poder en la organización.
- La Cultura Organizacional y si ella abarca a todo el colectivo o a partes de
éste.
- Actitudes de la Dirección y la moral de la organización. Si la organización pasa
por un período difícil, la gente puede ser hostil a esta Dirección y pueden estar
indispuestos a participar en el proceso de cambio.

3) Identifique y Consulte a todos los beneficiarios del sistema

Cuando se demanda un sistema, existen muchas personas, que de un
modo directo o indirecto se relacionan o se benefician con el sistema que va a ser
desarrollado, entre éstos podemos nombrar a los usuarios finales. Otros pueden
ser: gerentes, programadores, equipo técnico, especialistas del dominio,
educadores, etc. Como parte del proceso de elicitación de requerimientos, hay que
identificar a todos los potenciales beneficiarios y consultarlos para descubrir si
ellos plantean requerimientos específicos o si imponen restricciones específicas al
sistema.
Los beneficios de seguir este lineamiento son:
- Si no se considera a cada uno de los afectados por la introducción de un
sistema, probablemente se omitirán requerimientos importantes. El sistema
debería ser adaptado para incluir estos requerimientos en una etapa posterior
o, peor aun, ignorarlos.
- la identificación de los distintos grupos de beneficiarios puede ayudar a
descubrir puntos de vista distintos para estructurar los requerimientos del
sistema.

22
- Identificando los grupos de beneficiarios e incorporándolos al proceso de
análisis, con mayor probabilidad se logrará que sean comprensivos a la
introducción del sistema y colaboren dando información de interés y aportando
los requerimientos desde su punto de vista.

¿Cómo identificar a los grupos de beneficiarios?

-Descubriendo a los usuarios potenciales del sistema.
-Mediante discusiones iniciales con la dirección de organización donde se
pregunte quién será afectado por la introducción del sistema.
- Considerando a los usuarios de la organización que usará el sistema.
- Considerando al personal de desarrollo y mantenimiento del sistema.
- Considerando entes externos como reguladores y autoridades de
certificación que pueden desear colocar requerimientos sobre el sistema.
Recomendamos que en la documentación además de identificar a estos grupos de
beneficiarios, se explique porqué sus requerimientos probablemente sean
importantes.

2.5 Técnicas de Elicitación

Son un conjunto de técnicas empleadas para realizar la obtención de
información necesaria para desarrollar un software de calidad. Obtener un
software de calidad es una de las metas en el proceso de construcción de una
aplicación, y se expresa en términos de las cualidades deseadas: eficiencia,
flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad o usabilidad,
entre otras. La obtención de un software con calidad implica la utilización de
metodologías o procedimientos estándares para el análisis, diseño, programación
y prueba del software.
Aunque se explican muchas técnicas, no significa que deban usarse todas,
se eligen aquellas que respondan al propósito del sistema. Si dos técnicas sirven
para el mismo objetivo, se escoge la de menor costo. Si se quiere estar seguro de
cubrir todo, pueden usarse varias técnicas. Lo que pueda faltar en una, lo
complementará la otra.
Las técnicas más usuales en la elicitación de requerimientos son: las
entrevistas; el Desarrollo Conjunto de Aplicaciones (Joint Application Development

23
o JAD); la tormenta de ideas (brainstorming) y la utilización de escenarios. A estas
técnicas, que se describen en las siguientes secciones, se las suele apoyar con
otras técnicas complementarias como la observación in situ, el estudio de
documentación, los cuestionarios, la inmersión en el negocio del cliente, entre
otras.

2.5.1. Entrevistas

Las entrevistas son la técnica de elicitación más utilizada, y de hecho son

prácticamente inevitables en cualquier desarrollo ya que es una de las formas de
comunicación más natural entre personas. La entrevista es buena para obtener
conocimientos acerca del trabajo actual en el dominio dado y los problemas
presentes. No es tan buena para la identificación de las metas críticas. Pueden
dar, también, algunas ideas sobre el sistema futuro.

2.5.1.1 Tipos de entrevistas:

a) Entrevistas no estructuradas: permite que el entrevistador formule preguntas
no previstas durante la conversación. El entrevistador inquiere sobre diferentes
temas a medida que se presentan. En este tipo de entrevistas el entrevistador
tiene poco control sobre el proceso y las conversaciones son enfocadas hacia un
tema particular.
b) Entrevistas estructuradas: se basan en un marco de preguntas
predeterminadas. Las preguntas se establecen antes de que inicie la entrevista y
todo solicitante debe responderla.
Este enfoque mejora la calidad de la entrevista, pero no permite que el
entrevistador explore las respuestas interesantes o poco comunes. Por eso la
impresión del entrevistado y entrevistador es la de estar sometidos a un proceso
mecánico. Es posible incluso que muchos solicitantes se sientan desalentados al
participar en este tipo de proceso.

24
c) Entrevistas semiestructuradas: es una estrategia mixta, con preguntas
estructurales y con preguntas no estructurales. La parte estructurada proporciona
una base informativa. La parte no estructurada añade interés al proceso y permite
un conocimiento inicial de características específicas.

2.5.1.2 Fases de la entrevista:

En las entrevistas se pueden identificar tres fases: preparación, realización
y análisis.
1) Preparación de entrevistas
Las entrevistas no deben improvisarse, por lo que conviene realizar las
siguientes tareas previas:
• Estudiar el dominio del problema:
Conocer las categorías y conceptos de los usuarios y la
comunidad interesada es fundamental para poder entender las
necesidades de dicha comunidad y su forma de expresarlas.
Para conocer el dominio del problema se puede recurrir a técnicas de estudio de
documentación, a bibliografía sobre el tema, documentación de proyectos
similares realizados anteriormente, la inmersión dentro de la organización para la
que se va a desarrollar o a periodos de aprendizaje por partes de los analistas de
requerimientos.

•Seleccionar a las personas a las que se va a entrevistar:

Se debe minimizar el número de entrevistas a realizar, por lo que es fundamental
un proceso de selección. Normalmente se comienza por los actores que puedan
ofrecer una visión global, y se continúa con los futuros usuarios, que pueden
aportar información más detallada, y con el personal técnico, que aporta detalles
sobre el entorno operacional de la organización. Conviene también estudiar el
perfil de los entrevistados, buscando puntos en común con el entrevistador que

25
ayuden a romper el hielo. ¿A quién entrevistar para obtener información acerca del
trabajo actual y los problemas presentes?. Preferiblemente algunos miembros de
cada grupo de actores. Hay que entrevistar no solo a representantes oficiales, la
experiencia demuestra que muchos de estos representantes desconocen lo que
realmente sucede en la organización diariamente. Obtener información del
verdadero usuario final es importante.

•Determinar el objetivo y contenido de las entrevistas:

Para minimizar el tiempo de la entrevista es fundamental fijar el objetivo que se
pretende alcanzar y determinar previamente su contenido. Previamente a su
realización, se pueden enviar cuestionarios que los futuros entrevistados deben
rellenar y devolver, y un pequeño documento de introducción al proyecto de
desarrollo, de forma que el entrevistado conozca los temas que se van a tratar y
el entrevistador recoja información para preparar la entrevista. Es importante que
los cuestionarios, si se usan, se preparen cuidadosamente teniendo en cuenta
quién los va a responder y no incluir conceptos que se asuman conocidos cuando
puedan no serlo.

•Planificar las entrevistas:

La fecha, hora, lugar y duración de las entrevista deben fijarse teniendo en cuenta
siempre la agenda del entrevistado. En general, se deben buscar sitios
agradables donde no se produzcan interrupciones y que resulten naturales a los
entrevistados. La puntualidad es importante.

26
2) Realización de entrevistas
Dentro de la realización de las entrevistas se distinguen tres etapas: Apertura,
desarrollo y terminación.
• Apertura: el entrevistador debe presentarse e informar al entrevistado sobre la
razón de la entrevista, qué se espera conseguir, cómo se utilizará la
información, la mecánica de las preguntas, etc. Si se va a utilizar algún tipo de
notación gráfica o matemática que el entrevistado no conozca, debe explicarse
antes de utilizarse. Es fundamental causar buena impresión en la primera
entrevista.
• Desarrollo: la entrevista debe tener un lapso prefijado, distribuyendo el tiempo
en un 20% para el entrevistador y un 80% para el entrevistado. Se deben evitar
los monólogos y mantener el control por parte del entrevistador, contemplando
la posibilidad de que una tercera persona tome notas durante la entrevista o
grabar la entrevista en cinta de vídeo o audio, siempre que el entrevistado esté
de acuerdo. Hay aspectos éticos a considerar: si se va a grabar la entrevista,
se debe tener muy presente que el equipo de grabación debe estar en perfecto
estado y el entrevistador debe saber manejarlo y cuando se reproduce la
grabación no se pueden cambiar ni corregir las respuestas suministradas por
los entrevistas, bajo ninguna circunstancia. ¿Qué preguntar?. Inicialmente,
formular preguntas abiertas acerca del trabajo diario, y otros aspectos de la
lista de cosas a elicitar. Asegurándose de preguntar sobre las tareas críticas:
¿cuándo es realmente importante que los resultados sean 100% correctos?.
Difícilmente se pueden identificar estos detalles con la observación, hay que
preguntarles a los usuarios.
Durante esta fase se deben considerar los siguientes aspectos:
- Realizar preguntas abiertas, también denominadas de libre contexto, estas
preguntas no pueden responderse con un "sí" o un "no", permiten una
mayor comunicación y evitan la sensación de interrogatorio. Estas
preguntas se suelen realizar al comienzo de la entrevista, pasando
posteriormente a preguntas más concretas. En general, se debe evitar la
tendencia a anticipar una respuesta a las preguntas que se formulan.
- Utilizar palabras apropiadas, evitando tecnicismos que no conozca el
entrevistado y palabras o frases que puedan perturbar la comunicación.
- Mostrar interés en todo momento, cuidando la comunicación gestual
durante la entrevista: movimiento, expresión facial, etc. Por ejemplo, para
animar a alguien a hablar puede asentirse con la cabeza, decir "ya
entiendo", "sí", repetir algunas respuestas dadas, hacer pausas, poner una

27
 postura de atención, etc. Debe evitarse bostezar, reclinarse en el sillón,
mirar hacia otro lado, etc.
• Terminación: al terminar la entrevista se debe recapitular para confirmar que
no ha habido confusiones en la información recogida, agradecer al entrevistado
su colaboración y citarle para una nueva entrevista si fuera necesario, dejando
siempre abierta la posibilidad de volver a contactar para aclarar dudas que
surjan al estudiar la información o al contrastarla con otros entrevistados.

3) Análisis de las entrevistas

Una vez realizada la entrevista es necesario leer las notas tomadas,
pasarlas en limpio, reorganizar la información, contrastarla con otras entrevistas o
fuentes de información, entre otros. Una vez elaborada la información, se puede
enviar al entrevistado para confirmar los contenidos. También es importante
evaluar la propia entrevista para determinar los aspectos mejorables.
Una variante es la entrevista en grupos. Un grupo de usuarios de la misma
área puede decir más del trabajo actual, problemas, situaciones críticas que las
entrevistas individuales. El grupo inspira a los otros a recordar situaciones críticas,
describir el trabajo diario, etc. Una cosa importante cuando se conduce esta clase
de entrevistas es mantener un equilibrio entre participantes de modo que nadie
domine y todos se sientan seguros dando su opinión.

2.5.2 Desarrollo Conjunto de Aplicaciones (JAD)

La técnica denominada Joint Application Development, Desarrollo Conjunto de

Aplicaciones –JAD en lo sucesivo-, desarrollada por IBM en 1977, es una

28
alternativa a las entrevistas individuales que se desarrolla a lo largo de un conjunto
de reuniones en grupo durante un periodo de uno o varios días. En estas
reuniones se ayuda a los usuarios y otros beneficiarios a formular problemas y
explorar posibles soluciones, involucrándolos y haciéndolos sentirse partícipes del
desarrollo. Esta técnica se base en cuatro principios [Raghavan et al. 1994]:
- dinámica de grupo,
- el uso de ayudas visuales para mejorar la comunicación (diagramas,
transparencias, multimedia, herramientas CASE, etc.),
- mantener un proceso organizado y racional
- una filosofía de documentación WYSIWYG (What You See Is What You Get, lo
que tu ves es lo que tu encuentras), por la que durante las reuniones se trabaja
directamente sobre los documentos a generar.
El JAD tiene dos grandes pasos, el JAD/Plan cuyo objetivo es elicitar y
especificar requerimientos, y el JAD/Design, en el que se inicia el proceso de
diseño del software. En este documento sólo se verá con detalle el primero de
ellos. Debido a los aspectos de organización que requiere y a que no suele
adaptarse bien a los horarios de trabajo de los clientes y usuarios, esta técnica no
suele emplearse con frecuencia, aunque cuando se aplica suele producir buenos
resultados, especialmente para elicitar requerimientos en el campo de los
sistemas de información.
En comparación con las entrevistas individuales, presenta las siguientes
ventajas:
• Ahorra tiempo al evitar que las opiniones de los usuarios y otros beneficiarios
se contrasten por separado.
• Todo el grupo revisa la documentación generada, no sólo los analistas de
requerimientos.
• Implica más a los usuarios y otros beneficiarios en el desarrollo.

2.5.2.1 Participantes del JAD

Se pueden distinguir seis clases de participantes, con roles diferentes:
• Facilitador: es el responsable de todo el proceso y asume el control durante las
reuniones. Debe tener dotes de comunicación y liderazgo. Algunas habilidades

29
 importantes que debe poseer: entender y promover la dinámica de grupo,
iniciar y centrar discusiones, reconocer cuándo la reunión se está desviando
del tema y reconducirla, manejar las distintas personalidades y formas de ser
de los participantes, evitar que decaiga la reunión aunque sea larga y difícil,
etc.
• Analista: es el responsable de la producción de los documentos que se deben
generar durante las sesiones. Debe tener la habilidad de organizar bien las
ideas y expresarlas claramente por escrito. En el caso de que se utilizan
herramientas software durante las sesiones, debe ser capaz de manejarlas
eficientemente.
• Gerente o Directivo: es el que tiene la decisión final de que se lleve a cabo el
desarrollo. Debe proporcionar a los demás participantes información sobre la
necesidad del nuevo sistema y los beneficios que se espera obtener de él.
• Los usuarios: las personas que utilizarán el sistema
• Representantes de sistemas similares: son personas expertos en sistemas que
deben ayudar a los usuarios a comprender qué es o no factible con la
tecnología actual y el esfuerzo que implica.
• Especialistas: son personas que pueden proporcionar información detallada
sobre aspectos muy concretos, tanto del punto de vista de los usuarios, porque
conocen muy bien el funcionamiento de una parte de la organización, como
desde el punto de vista de los desarrolladores porque conocen ciertos
aspectos de la tecnología de la organización.

2.5.2.2 Fases del JAD

Se distinguen tres fases:
1) Adaptación: Es responsabilidad del facilitador, ayudado por uno o dos
analistas, adaptar la técnica del JAD para cada proyecto. La adaptación debe
comenzar por definir el proyecto a alto nivel, para lo cual pueden ser necesarias
entrevistas previas con algunos clientes y usuarios. También suele ser necesario
recabar información sobre la organización para familiarizarse con el dominio del
problema, por ejemplo utilizando técnicas complementarias como el estudio de
documentación o la observación in situ. Una vez obtenida una primera idea de los
objetivos del proyecto, es necesario seleccionar a los participantes, citarles para
las reuniones y proporcionarles una lista con los temas que se van a tratar en las
reuniones para que las puedan preparar.

30
 El facilitador debe decidir la duración y el número de sesiones a celebrar,
definir el formato de la documentación sobre la que se trabajará y preparar
transparencias introductorias y todo el material audiovisual que considere
oportuno.

2) Celebración de las sesiones JAD: Durante las sesiones, los participantes

exponen sus ideas y se discuten, analizan y refinan hasta alcanzar un acuerdo.
Los pasos que se recomienda seguir para este proceso son los siguientes:
a) Presentación: se presenta y se da la bienvenida a todos los participantes por
parte del Directivo y del facilitador. El Directivo expone brevemente las
necesidades que han llevado al desarrollo y los beneficios que se esperan
obtener. El facilitador explica la mecánica de las sesiones y la planificación
prevista.
b) Definir objetivos y requerimientos: el facilitador promueve la discusión para
elicitar los objetivos o requerimientos de alto nivel mediante preguntas como:
¿Por qué se construye el sistema?, ¿Qué beneficios se esperan del nuevo
sistema?, ¿Cómo puede beneficiar a la organización en el futuro?, ¿Qué
restricciones de recursos disponibles, normas o leyes afectan al proyecto?,
¿Es importante la seguridad de los datos?. A medida que se van elicitando
requerimientos, el analista los escribe en transparencias o en algún otro medio
que permita que permanezcan visibles durante la discusión. Una posibilidad es
utilizar para ello las plantillas descritas en la presente guía.
c) Delimitar el ámbito del sistema: una vez obtenido un número importante de
requerimientos, es necesario organizarlos y llegar a un acuerdo sobre el ámbito
del nuevo sistema. Es útil identificar a los usuarios potenciales y determinar
qué tareas les ayudará a realizar.
d) Documentar temas abiertos: aquellas cuestiones que hayan surgido durante la
sesión que no se han podido resolver, deben documentarse para las siguientes
sesiones y ser asignadas a una persona responsable de su solución para una
fecha determinada.
e) Concluir la sesión: el jefe del JAD concluye la sesión revisando con los demás
participantes la información elicitada y las decisiones tomadas. Se da la
oportunidad a todos los participantes de expresar cualquier consideración
adicional, fomentando por parte del jefe del JAD el sentimiento de propiedad y
compromiso de todos los participantes sobre los requerimientos elicitados.

31
3) Conclusión: Una vez terminadas las sesiones es necesario transformar las
transparencias, notas y demás documentación generada en documentos formales.
Se distinguen tres pasos:
a) Completar la documentación: los analistas recopilan la documentación
generada durante las sesiones en documentos conformes a las normas o
estándares vigentes en la organización para la que se desarrolla el proyecto.
b) Revisar la documentación: la documentación generada se envía a todos los
participantes para que la comenten. Si los comentarios son lo suficientemente
importantes, se convoca otra reunión para discutirlos.
c) Validar la documentación: una vez revisados todos los comentarios, el
facilitador envía el documento al patrocinador ejecutivo para su aprobación.
Una vez aprobado el documento se envían copias definitivas a cada uno de los
participantes.

2.5.3 Tormenta de ideas (Brainstorming)

La tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es
la generación de ideas en un ambiente libre de críticas o juicios. Las sesiones
suelen estar formadas por un número de cuatro a diez participantes, uno de los
cuales es el facilitador de la sesión, encargado más de comenzar la sesión que de
controlarla. Como técnica de elicitación de requerimientos, puede ayudar a
generar una gran variedad de vistas del problema y a formularlo de diferentes
formas, sobre todo al comienzo del proceso de elicitación, cuando los
requerimientos son todavía muy difusos.

El facilitador anota todas las ideas en una pizarra. Pronto cada idea
generará otras ideas, algunas interesantes, otras prometedoras y otras sin sentido
común. Una regla importante del juego es no criticar ningún planteamiento. Incluso
ideas aparentemente descartables pueden convertirse en la semilla de otras ideas
interesantes.
Durante la elicitación, el interés está puesto en ideas para el nuevo sistema. Si la
creatividad no surge en la sesión, el analista puede introducir ideas que han
surgido mediante otras técnicas. El facilitador puede culminar la sesión con una
ronda donde se prioricen las ideas.

32
 2.5.3.1 Ventajas de la Tormenta de Ideas sobre el JAD
- Es muy fácil de aprender
- Requiere poca organización, de hecho, hay propuestas de realización de
Tormentas de ideas por vídeo conferencia a través de Internet .
Por otro lado, al ser un proceso poco estructurado, puede no producir resultados
con la misma calidad o nivel de detalle que otras técnicas. Pero estimula
fuertemente la creatividad y pueden salir ideas innovadoras.

2.5.3.2 Fases de la Tormenta de ideas

En la tormenta de ideas se distinguen las siguientes fases:
1) Preparación: la preparación para una sesión requiere que se
seleccione a los participantes y al jefe de la sesión, citarlos y
preparar la sala donde se llevará a cabo la sesión. Los
participantes en una sesión de tormenta de ideas para elicitación
de requerimientos son normalmente los usuarios y otros beneficiarios, y, si es
necesario, algún experto en el dominio del problema.
2) Generación: el facilitador abre la sesión exponiendo un enunciado general del
problema a tratar, que hace de semilla para que se vayan generando ideas. Los
participantes aportan libremente nuevas ideas sobre el problema semilla, bien por
un orden establecido por el facilitador, bien aleatoriamente. El facilitador es
siempre el responsable de dar la palabra a cada participante. Este proceso
continúa hasta que el facilitador decide parar, bien porque no se están generando
suficientes ideas, en cuyo caso la reunión se pospone, bien porque el número de
ideas sea suficiente para pasar a la siguiente fase.
Durante esta fase se deben observar las siguientes reglas:
- Se prohíbe la crítica, de forma que los participantes se sientan libres de
formular cualquier idea.
- Se fomentan las ideas más innovadoras, que, aunque no sean factibles,
estimulan a los demás participantes a explorar nuevas soluciones más
creativas.

33
- Se debe generar un gran número de ideas, ya que cuantas más ideas se
presenten, más posibilidades de análisis se tendrá.
- Se debe alentar a los participantes a combinar o completar las ideas de otros
participantes. Para ello, es necesario, al igual que en la técnica del JAD, que
todas las ideas generadas estén visibles a todos los participantes en todo
momento. Una posibilidad es utilizar como semilla objetivos del sistema e ir
identificando requerimientos. Estos requerimientos se deben recoger en
plantillas para que los participantes tengan visibles las ideas que se van
generando.
3) Consolidación: en esta fase se deben organizar y evaluar las ideas generadas
durante la fase anterior. Se suelen seguir tres pasos:
a) Revisar ideas: se revisan las ideas generadas para clarificarlas. Es habitual
identificar ideas similares, en cuyo caso se unifican en un solo enunciado.
b) Descartar ideas: aquellas ideas que los participantes consideren no adecuadas
se descartan.
c) Priorizar ideas: se priorizan las ideas restantes, identificando las absolutamente
esenciales, las que estarían bien pero que no son esenciales y las que podrían
ser descartarse.

4) Documentación: después de la sesión, el facilitador produce la documentación

oportuna, conteniendo las ideas priorizadas y comentarios generados durante la
consolidación.

2.5.4 Estudio de documentos

El estudio de documentos es otra alternativa para obtener información. Es
también una vía rápida de conocer lo existente. El analista estudia documentos
existentes tales como formas, documentación del sistema actual, etc.

2.5.5 Observación
En las entrevistas el usuario puede dar explicaciones lógicas pero que no
se corresponden a la realidad. La observación sirve para comprobar la información
obtenida en entrevistas.
El analista puede pasar cierto tiempo con los usuarios, observando las
tareas diarias. En algunos casos, los analistas usan grabadores o cámaras de

34
vídeo (con el permiso de los usuarios) para prolongar el período de la observación.
Esto tiene la ventaja de que puede revisar las cintas con el usuario y aclarar
cualquier duda.
La observación mejora los conocimientos del trabajo actual y de algunos
problemas en el trabajo. Desafortunadamente, las situaciones y las tareas críticas
frecuentemente se escapan de la observación.
Una variante de la entrevista y la observación es la demostración de tareas.
Se le puede pedir al usuario que demuestre como ejecuta una tarea específica.

2.5.6 Cuestionarios
El cuestionario es una manera de obtener información de muchas personas.
Puede usarse de varias formas: para obtener evidencia estadística o reunir
opiniones y sugerencias.
En el segundo caso, formule preguntas abiertas. Esencialmente, puede
hacer las mismas preguntas como en una entrevista, ejemplo “¿Cuál es el mayor
problema en tu trabajo diario?” o “¿Cuáles son sus sugerencias para mejorar el
soporte tecnológico en tu trabajo diario?”. Estos resultados pueden ser un poco
difíciles de interpretar. Las personas consultadas pueden haber mal interpretado
las preguntas y de igual forma se puede mal interpretar las respuestas. Durante la
entrevista, se puede comprobar si se está entendiendo lo planteado y reformular
preguntas. También es difícil clasificar los resultados de las preguntas abiertas si
no ve conoce el contexto.
El riesgo de no comprender bien es aún mayor con preguntas de tipo
cerradas. Para reducir el riesgo, es esencial conocer bien el dominio.

2.5.7 Talleres (workshop)

Hay muchas clases de talleres y en ellos se pueden mezclar diversas
técnicas (tormenta de ideas, prototipaje, etc.). Se usan para cubrir casos donde los
usuarios y los desarrolladores se reúnen para diseñar o perfilar el sistema futuro.
El término “trabajo cooperativo” se aplica a esta técnica.

35
 El resultado de los talleres, puede ser un perfil o un prototipo, diagramas de
casos de uso, etc. Usualmente, el analista debe finalizar convirtiendo los
resultados en requerimientos. Como efecto secundario del taller, se pueden
identificar las metas y situaciones críticas.
Un problema con los talleres es que los participantes pueden
comprometerse mucho con la solución allí planteada. ¿Por qué esto es un
problema?: porque en su entusiasmo, ellos pueden olvidar otros aspectos, tales
como si la solución es técnicamente factible, o si otros actores entienden la
solución. Y ello puede causar conflictos con ellos.

2.5.8 Prototipaje
Un prototipo es una versión simplificada de parte del sistema final. Los
usuarios y otros beneficiarios experimentan con prototipos para tener una idea de
cómo funcionaría en la vida real. El prototipaje puede ser a nivel de la interfaz del
sistema, en este sentido se exploran los elementos de la interacción con el
usuario. Este prototipaje puede ser de baja o alta fidelidad. En el primer caso se
tendrán bocetos a lápiz y papel, en el segundo se tendría una interfaz elaborada
con las herramientas en que se desarrollará el sistema, aún cuando sea una
versión simplificada de la interfaz de usuario del sistema.
Otras partes del sistema pueden ser objeto de prototipaje. Como por
ejemplo, si el sistema debe comunicarse con otro producto existente, el prototipaje
de la comunicación puede revelar mucho: ¿cuáles son los tiempos de respuesta
real?, etc.

2.5.9 Pruebas pilotos

En muchos casos, el nuevo sistema puede ser un sistema estándar, quizás
con algunas funcionalidades adicionales. El costo para introducir el sistema puede
ser alto, pero el principal riesgo es si la organización puede adoptar el sistema y
usarlo para incrementar su desempeño. Los cambios organizacionales propios son
a menudo más costosos que el sistema mismo.

36
 En este caso, la mayoría de los riesgos pueden ser eliminados a través de
una prueba piloto. Una pequeña parte de la organización usa el nuevo sistema en
un período de prueba y cambia sus procedimientos de trabajo. El grupo de
analistas observa el resultado y evalúa el costo y beneficio del nuevo sistema.
Usualmente, dicho grupo sugiere también formas diferentes de hacerlo al ampliar
su uso a toda la organización.
Si el experimento es exitoso, se crea un acuerdo de compromiso. El grupo
de analistas también ayuda a identificar los requerimientos faltantes y las
prioridades.

2.5.10 Estudiar organizaciones similares

Una de las mejores fuentes de ideas es estudiar que hacen otras
organizaciones para manejar problemas similares. Un estudio de sus
procedimientos y la comparación con los de la organización actual puede dar
muchas ideas. Otras organizaciones similares pueden también tener experiencia
con el sistema que se considera. Más importante, una visita a esas organizaciones
hace más fácil imaginar como podría trabajar el nuevo sistema.
Un problema que se puede presentar es si las otras organizaciones están
dispuestas a compartir sus conocimientos. Hay otras formas de obtener
información acerca de los procedimientos de los competidores. Algunas auditorias
internacionales y compañías de consulta tienen una enorme base de datos de
patrones de prueba con el desempeño de otras compañías en el mismo dominio.

2.5.11 Negociación
El propósito de la negociación es resolver conflictos. Estos puede ser
conflictos entre el proveedor y el usuario, pero los conflictos más difíciles se
presentan frecuentemente entre los distintos grupos de beneficiarios del sistema,
dentro de la misma organización.
Los conflictos entre los proveedores y el usuario están usualmente
relacionados con costos, beneficios, y quién corre el riesgo. Los conflictos dentro

37
de la organización pueden ser de otra índole, como por ejemplo, conflictos de
poder, conflictos con otros proyectos.
En un grupo de discusión que trabaje en la resolución de los conflictos tiene
que participar miembros de cada grupo que interviene en el conflicto. Para que
sea productivo el encuentro, las partes en conflicto deben estar dispuestas a
dialogar y entenderse unos a otros, de otra manera el trabajo preliminar debe ser
elaborado en términos individuales o asignarles todas las responsabilidades a
personas de un nivel superior en la organización.
Hay muchas estrategias disponibles para resolver conflictos, por ejemplo
que cada grupo explique lo que ellos creen que los otros participantes quieren y
porqué.
Desde el punto de vista de los requerimientos, lo más importante es
analizar las metas de cada grupo. Habitualmente, los conflictos se centran en las
soluciones, auque cada grupo puede aceptar las metas de los otros grupos. La
estrategia es encontrar la solución que no genere conflicto, pero que apoye las
metas de todos (una situación de ganar-ganar).

2.5.12 Análisis orientado a las metas

El análisis de las metas comprende la relación entre las metas de alto nivel,
las metas de nivel bajo y los requerimientos. En general, el análisis de las metas
responde a estas preguntas:
- ¿Para cada meta, se tienen los requerimientos que aseguren el logro de ella?
- ¿Se explica por cada requerimiento cual el su propósito?
- ¿Están los requerimientos en el nivel adecuado o la meta debe ser un
requerimiento?
Esto puede denominarse técnica de chequeo, pero es una parte importante
de la elicitación que puede cambiar drásticamente los requerimientos. En muchos
casos, las metas importantes se olvidan durante la elicitación, incluso si se ha
hecho prototipaje. Lo que origina que los requerimientos no estén completos y
como resultado el sistema final no los asocia con meta alguna. El análisis permitirá
nuevas ideas en cuanto a las prioridades de los requerimientos. Esto sucede

38
cuando no se distingue el propósito de los requerimientos. Pueden eliminarse
requerimientos, si ninguna tarea parece necesitarlo. En otros casos el propósito
del requerimiento no es tan importante, luego se le puede dar una prioridad baja.

2.5.13 Despliegue de funciones de calidad (QFD por sus siglas en inglés)

QFD usa una notación sistemática para relacionar metas y soluciones. La
notación se fundamenta en una matriz donde las metas se colocan en un eje y las
soluciones en otro eje. En cada celda de la matriz, se especifica el grado de
relación entre la meta y la solución.
Una extensión de la matriz especifica el grado de conflicto o soporte entre
dos soluciones. Otras extensiones especifican los valores percibidos de las metas
y costos de la solución. La prioridad y la relación costo/beneficio de cada solución
puede ser calculado desde una base de datos.
Este enfoque es un buen complemento a otras técnicas. El problema
principal es mantener bajo el número de metas y soluciones, por ejemplo, diez
metas y diez soluciones permiten tener una matriz de 10*10 la cual es fácil de
manejar, pero una matriz de 20*20 puede convertirse en un problema.

2.4.14 Grupos focalizados

Los grupos de trabajo son similares a la tormenta de ideas, pero son más
estructurados. Los grupos de trabajo comienzan con una fase donde los
participantes identifican los problemas relacionados con el modo actual de hacer
las tareas. Luego viene la fase donde los participantes imaginan la forma ideal de
hacer las tareas. El grupo también trata de explicar porque esas ideas son buenas.
Esto ayuda a formular los objetivos del nuevo sistema. Muchos actores participan,
y al final de la sesión, cada grupo identifica sus prioridades. Luego cuando
se da prioridad a los requerimientos, es importante que cada grupo de
beneficiarios aporten soluciones para algunas de sus necesidades prioritarias.
En está técnica se motiva a las personas a plantear los problemas actuales
que tienen en cuanto al modo de hacer las cosas, las necesidades reales, y la
forma idónea de hacerlas. Los usuarios y otros beneficiarios participan e

39
identifican los problemas prioritarios por cada grupo. Estos grupos deben formarse
en los inicios del proyecto.
El analista debe conocer el área de aplicación (dominio) e identificar los
grupos de posibles beneficiarios del sistema.

Organizando un grupo focalizado

El grupo trabaja entre 2 y 5 horas. Los usuarios y otros beneficiarios más
importantes deben participar en este grupo. Si se está tratando de reunir ideas
para un nuevo producto, éstos podrían ser: usuarios finales, compradores
potenciales, distribuidores del producto, equipo soporte y programadores. Si está
tratando de reunir ideas para un sistema interno, ellos podrían ser: usuarios de los
departamentos afectados por el sistema, gerentes de esos departamentos,
personal de computación y de soporte al usuario.

Pasos a realizar:
1) Invitar participantes: Invitar entre 6 y 18 personas para un taller. Asegúrese que
cada grupo de beneficiarios esté representado (si invita a proveedores no debe
sobrepasar la tercera del parte del grupo de trabajo.
2) Iniciar la reunión: Al comienzo de la reunión presentar el tema, presentar a los
participantes y lograr un ambiente en el que se sientan cómodos.
3) Identificar malas experiencias: Conduzca la discusión hacia la discusión de las
malas experiencias apoyándose en productos, actividades del dominio, etc.
Registre los planteamientos. Su rol principal como facilitador es asegurar que
nadie domine al grupo y que todos tengan la oportunidad de formular su
planteamiento. Su propio equipo debe tener una participación discreta.
4) Imaginar el futuro: Cambie el escenario para imaginar la solución ideal. ¿Si
usted pudiese obtener lo que desea en ésta área, que solicitaría? Permita
ideas extravagantes. Trate de obtener una visión de porqué las personas
desean las metas planteadas, especialmente en caso de ideas extravagantes.
Pregunte: ¿desde cuándo desea eso?, ello puede llevar a descubrir la
verdadera necesidad que envuelve la idea formulada. Registre las ideas y su
justificación.
5) Liste las necesidades: En esta etapa se pueden recolectar muchas
necesidades. Elabore una lista de necesidades que sean requeridas por todos,
que contenga: ideas, aspectos negativos, requerimientos y justificación.

40
 Fusione necesidades casi idénticas. Esto es un trabajo arduo y toma algún
tiempo hacerlo. Permita a los participantes tomar un descanso entre tanto.
6) Priorizar las necesidades: Solicite a cada grupo de beneficiarios que seleccione
las 10 necesidades más importantes de la lista elaborada y las ordene según la
prioridad. Usted puede solicitarles elaborar una lista conjunta. La lista puede
comprender ideas, problemas a resolver, requerimientos.
7) Repase la lista: Finalice la sesión comentando las prioridades designadas por
los otros grupoide beneficiarios. Revise y combine los problemas y
necesidades.

Procesando los requerimientos

En la sesión siguiente seleccione los asuntos con los que trabajará. Trate
de plantear posibles soluciones a los problemas difíciles o deseos imposibles. ¿Es
imposible satisfacer los diez primeras problemas, entonces cuales son
importantes?
El punto crucial es satisfacer las demandas por cada grupo de beneficiarios.
Lo que no se debe hacer es sacar un promedio de las prioridades, pues se pueden
omitir aspectos esenciales para cada grupo. La selección final de los asuntos debe
basarse en ambas prioridades: las asignadas por los grupos de beneficiarios y el
costo que implica solucionarlo.

Estructurando los requerimientos

Al principio, las técnicas de elicitación generan listas de problemas, metas.
Estos tópicos son los aspectos preliminares, requerimientos informales.
Usualmente, estos no son verificables, así que se deben transformar en buenos
requerimientos. La información preliminar la constituyen los requerimientos
informales que se obtienen a partir de las técnicas de elicitación.
Como ejemplo, se pude tener un problema si un requerimiento es “el
sistema debe ser fácil de usar”. Dado que esto no es un requerimiento verificable,
se debe trasladar en buenos requerimientos. Una forma puede ser estructurando
el requerimiento:

41
R1: Después de una práctica de X horas, el usuario debe ser capaz de desarrollar
la tarea Y, en al menos Z minutos. El paso final es seleccionar los aspectos
faltantes, por ejemplo los valores de X, Y, Z.
A continuación se presenta una matriz que muestra la relación de las técnicas de
elicitación y su efectividad respecto a lo que se va elicitar.
Matriz técnicas de elicitación/ aspectos a elicitar

Posibilidades reales

Requerimientos Completos
Resolución de conflictos
Trabajo actual

Problemas presentes

críticasMetas/ y decisiones

ideas Sistema futuro

Requerimientos

Prioridades
Compromisos
Aspectos a
elicitar
Técnicas

Entrevista (en
grupo)
Observación
Demostración de
tareas
Estudio de
documentos
Cuestionarios
Tormenta de ideas
Grupos principales
Talleres
Prototipos
Pruebas pilotos
Estudio de
compañías
similares
Negociación
Análisis de metas
QFD
Necesidades-
Requerimientos

2.5.15 Plantillas para elicitación de requerimientos

Las plantillas y patrones lingüísticos que se presentan pueden utilizarse
para describir los resultados, para registrar y gestionar los requerimientos, y servir
de comunicación entre los usuarios y otros beneficiarios en el sistema.
Su objetivo es doble: por un lado intentar paliar la falta de propuestas concretas
sobre cómo expresar los requerimientos. Por otro lado, también pueden usarse
como elementos de elicitación y negociación durante las reuniones con los
usuarios y otros beneficiarios.

42
 Con el uso de patrones, se consigue que durante las sesiones de elicitación
los participantes manejen directamente la documentación final, favoreciéndose así
su implicación en el proceso. Como fruto de la experiencia de su utilización, para
algunos campos de las patrones se han identificado frases estándar que son
habituales en las especificaciones de requerimientos y que se han parametrizado.
Estas frases, a las que hemos denominado patrones lingüísticos, pueden usarse
para rellenar los campos de las plantillas dándole valores a los parámetros con la
información oportuna.

2.5.16 Las plantillas como elemento de elicitación y negociación

Ambos aspectos, la estructuración de la información en forma de plantilla y
la propuesta de frases estándar, facilita la redacción de los requerimientos,
permitiendo a los participantes en las actividades de elicitación centrarse en
expresar sus necesidades y no en cómo expresarlas.
En la notación usada para describir los campos de cada plantilla, la frase
entre los símbolos < x > deben ser convenientemente reemplazada, mientras que
la frase que se encuentren entre los símbolos [y] son opcionales, es decir pueden
aparecer o no. Las plantillas pueden ser de diversos tipos, de acuerdo a si se
diseñan para:
- objetivos
- requerimientos funcionales
- requerimientos no funcionales

43
- requerimientos de información
- conflictos.

Parte común de las plantillas para todos los tipos

Los campos que pueden estar presentes en todos los tipos de plantillas son 6,:
<tipo>
<id> <nombre significativo>
Versión <n° de la versión actual> <fecha versión actual>
Autores •<autor de la versión actual> <organización del autor>
•…..
Fuentes •<fuente versión actual> <organización de la fuente>
•…..
Descripción <<tipo> a cumplir por el sistema>
Importancia <importancia del <tipo>>
Urgencia <urgencia del <tipo>>
Estado <estado del <tipo>>
Estabilidad <Estabilidad del <tipo>>
Comentarios <Comentarios adicionales sobre el <tipo>>
Figura 1. Planilla –campos comunes-
Note que la expresión <tipo> de la segunda columna, se reemplaza en cada tipo
de plantilla por el tipo en cuestión (objetivo, requerimiento, etc.).

Explicación adicional de cada campo:

- <tipo>: indica el tipo de la plantilla: objetivos (OBJ.), requerimientos funcionales
(Req-F), requerimientos no funcionales (Req-NF), requerimientos de
información (Req-I), conflictos (C).
- Importancia: indica la importancia del objetivo (o requerimiento funcional o
requerimiento no funcional o requerimiento de información o del conflicto). Se
asigna un valor (vital, importante, quedaría bien o por determinar).
- Urgencia: igual que el anterior en cuanto a su urgencia, se asigna un valor
(inmediato, hay presión, puede esperar o por determinar).
- Estado: el estado en cuanto a su desarrollo –del objetivo, del requerimiento,
etc.-. Se califica con: en construcción, pendiente de negociación, pendiente de
verificación, pendiente de solución.

6
no todos los campos son obligatorios, depende del problema –y del nivel de la solución- cuales
considerar.

44
- Estabilidad: este campo indica una estimación de que pueda sufrir cambios en
el futuro. Se califica como: alta, media, baja o por determinar. Es muy
importante por cuando permite prever la anticipación al cambio, favoreciendo el
mantenimiento y la evolución del software.
- Comentarios: cualquier otra información.

A continuación se muestran los nuevos campos de acuerdo al tipo de

plantilla, o se ejemplifica la frase estándar que facilita la redacción (a fin que el
participante se centre en expresar las necesidades y no en cómo expresarlas).
Adicionalmente se presenta un ejemplo de cada tipo, considerando un caso de
estudio simplificado, la gestión de un video club, indicando solamente los campos
más importantes.

Plantillas para objetivos

Los objetivos del sistema pueden considerarse como requerimientos de alto
nivel, de forma que los requerimientos propiamente dichos serian la forma de
alcanzar los objetivos.
Adicional a la plantilla común (Figura 1), se agrega el campo sub-objetivos:

OBJ.
….. …….
Descripción El sistema deberá…..<objetivo a cumplir por el sistema>
Sub-objetivos •<nombre del sub-objetivo>
•…..
Figura 2. Planilla de objetivos

El significado del campo es el siguiente:

- Sub-objetivos: en este campo pueden indicarse los sub-objetivos que
dependen del objetivo que se está describiendo. En sistemas complejos puede
ser necesario establecer una jerarquía de objetivos previa a la identificación de
los requerimientos. En caso que esto no sea necesario, puede ignorarse este
campo.
- La frase estándar en el campo descripción sugiere que se comience por “el
sistema deberá…..”.

45
-
Ejemplo.
objetivo
O5 Gestión de socios
Descripción El sistema deberá mantener la información de los socios:
su inclusión, retiro y modificaciones
Estabilidad alta

Plantilla para requerimientos (funcionales y no funcionales)

Los sistemas deben proporcionar servicios. La plantilla de requerimientos
funcionales ayuda a los clientes y usuarios a responder la pregunta ¿qué debe
hacer el sistema para alcanzar los objetivos?.
Adicional a la plantilla común (Figura 1), se agregan los siguientes campos:

Req-F o
Req-NF
… ….
Objetivos •<nombre del objetivo>
asociados
•……
Requerimientos •<nombre del requerimiento>
asociados
•…..

Figura 3. Planilla para requerimientos (funcionales y no funcionales)

Siguiendo con un ejemplo:

Req-NF
06 Portabilidad
Descripción El sistema deberá ser portable a linux
Objetivos Independizarse de plataformas (obj-07)
asociados

46
 Urgencia alta

En el campo descripción debe indicarse la capacidad que debe presentar el

sistema.

Plantilla para requerimientos de información

La plantilla para requerimientos de información, que puede verse en la
figura 4, ayuda a los clientes y usuarios a responder a la pregunta ¿qué
información relevante debe ser almacenada por el sistema?. ¿Qué restricciones
debe cumplir dicha información
Adicional a la plantilla común (Figura 1), se agregan los siguientes campos:

Req-I
…. ……
Objetivos •<nombre del objetivo>
asociados
……
Requerimientos •<nombre del requerimiento>
asociados
…..
Descripción El sistema deberá almacenar la información
correspondiente a <concepto relevante>
Datos •<datos específicos sobre el concepto relevante>
específicos
•……
Tiempo de vida <tiempo medio>, <tiempo máximo>
Ocurrencias <n° medio de ocurrr. simult.>,
simultáneas < n° máximo de ocurrr. simult.>
Figura 4. Planilla para requerimientos de almacenamiento

Ejemplo:
Req-I
12 Información sobre socios
Objetivos Gestión de socios (obj-08)
asociados
Req •Retiro de socio (RF-04)
asociados •Ingreso de socio (RF-09)
•Modificación de los datos del socio (RF-10)

47
 •Consulta sobre socios (RF-12)
Descripción El sistema deberá almacenar la información de los socios
Datos •Número del socio
específicos •C.I.
•nombre y apellido
•dirección
•teléfono
•películas actualmente alquiladas
Estabilidad alta

Anotaciones importantes de algunos campos de la plantilla:

- Objetivos asociados: este campo debe contener una lista con los objetivos a
los que está asociado el requerimiento. Esto permite conocer qué
requerimientos harán que el sistema a desarrollar alcance los objetivos
propuestos y justifican de esta forma la existencia o propósito del
requerimiento.
- Requerimientos asociados: en este campo se indican otros requerimientos que
estén asociados por algún motivo con el requerimiento que se está
describiendo, permitiendo así tener una rastreabilidad horizontal
- Datos específicos: este campo contiene una lista de los datos específicos
asociados al concepto relevante, de los que pueden indicarse todos aquellos
aspectos que se considere oportunos (descripción, restricciones, ejemplos,
etc.).
- Tiempo de vida (el número medio o máximo que se espera para cada
ocurrencia del concepto) y ocurrencias simultáneas (el numero medio y
máximo de ocurrencias simultáneas del concepto relevante).

Plantilla para conflictos

Para documentar los conflictos y las soluciones adoptadas, se propone una
plantilla. Adicional a los campos de la plantilla de la Figura 1, se tienen::
Conflicto
….. ……
Objetivos <nombre del objetivo>
asociados …..
Requerimientos <nombre del requerimiento>
asociados …..
Figura 5. Planilla de conflictos

48
 Bibliografía
- Ian Sommerville y Pete Sawyer. Requirements Engineering. A Good Practice
Guide. Cap. 4. Lancaster University. Ed. Jhon Wiley &sons, 1998.
www.comp.lancs.ac.uk/computing/resources/re-gpg/
- Soren Lauesen. Software Requirements. Styles and Techniques. Cap. 4.
Samfundslitteratur, 1999
- Durán A. y Bernárdez B. Metodología para la Elicitación de Requisitos de
Sistemas Software Versión 2.3. Informe Técnico LSI-2000-20 (revisado).
Universidad de Sevilla. Abril 2002.
URL:
http://www.lsi.us.es/~amador/publicaciones/metodologia_elicitacion_2_3.pdf.zip
URL de interés:
- Universidad de Texas. JAD: Austin.
http://www.utexas.edu/hr/is/pubs/jad.html#what
- Caja de herramientas de Gestión MYPIME. Guatemala. Tormenta de ideas:
http://www.infomipyme.com/Docs/GT/Offline/inicioempresa/brainstormi.htm
- Potenciación Comunitaria. Tormenta de ideas: Phil Bartre phd.
http://www.scn.org/mpfc/modules/brn-ints.htm
- Universidad de Sevilla. 2005. (Curso sobre análisis de requerimientos):
http://www.lsi.us.es/docencia/pagina_asignatura_doc.php?id=20&cur=2004

Actividades propuestas al estudiante

1. Investigar que son las entrevistas y sus tipos.
2. Seleccione el tipo de entrevistas a realizar durante el mini proyecto.
3. Planifique y redacte las entrevistas preliminares para mini proyecto.
4. Investigue el procedimiento para llevar acabo cada una de las siguientes
técnicas: Estudio de documentos, Observación, Cuestionarios, talleres,
Prototipaje pruebas pilotos, estudio de organizaciones similares,
negociación, análisis orientado a metas QFD y grupos focalizados.
5. Determine cuales de las técnicas estudiadas puede emplearse para la
Elicitación en su mini proyecto.
6. Elaborar un cuadro comparativo de todas las Técnicas de Elicitación
estudiadas.
7. Realice un análisis de la siguiente figura:

49
50
 Tema III. Requerimientos Funcionales
Versión: 1.1

Realizado por:
Profa. Ana María Padrón

Revisado por:
Prof. Nancy Zambrano UCV

Fecha:
Mayo de 2006

51
 3.1 Requerimientos Funcionales
Los requerimientos funcionales definen el comportamiento interno del
software, es decir, sus tareas o funciones. Un requerimiento funcional se describe
con un nombre único, un breve resumen y una explicación, lo cual ayudará a
entender el requerimiento y hacerle seguimiento a lo largo del desarrollo del
software (trazabilidad). Al definir el requerimiento funcional se debe describir el
comportamiento que tendrá el software de forma clara y legible.

3.2 ¿Cómo obtener los Requerimientos Funcionales?

Para saber cual es el comportamiento que debe realizar el software, se
debe elicitar los requerimientos con los usuarios, stakeholders, y otros expertos
dentro de la organización haciendo uso de las técnicas de Elicitación.

3.3 ¿Características de los Requerimientos Funcionales?

Los requerimientos funcionales, al igual que los requerimientos en general,
deben ser claros, correctos, inequívocos, específicos, y comprobables.
Generalmente, los requerimientos funcionales se expresan mediante el modelo de
casos de uso.

3.3.1 Ejemplos
1) En el sistema telefónico celular algunos requerimientos funcionales son:
a) Recibir llamadas
b) Hacer llamadas
c) Enviar mensajes
d) Recibir mensajes
e) Conectarse a Internet

2) En un procesador de palabras algunos requerimientos funcionales son:

a) Incluir comandos para corrección de palabras
b) Guardar el documento
c) Copiar

52
 d) Pegar
e) Cambiar el formato al texto

3.4 Casos de Uso

Los casos de uso son una técnica para la especificación de requerimientos
funcionales propuesta inicialmente por Jacobson y que actualmente forma parte
de la propuesta de UML. Un caso de uso muestra la secuencia de interacciones
entre el sistema y uno o más actores, para lograr la funcionalidad expresada, en la
que se considera al sistema como una caja negra y en la que la que los actores
obtienen resultados observables. Los actores son personas u otros sistemas que
interactúan con el sistema cuyos requerimientos se están describiendo.
Los casos de uso presentan ciertas ventajas sobre la descripción
puramente textual de los requerimientos funcionales, en función a que permiten
expresar los requerimientos de una forma estándar. Además, pueden servir de
base a las pruebas del sistema y a la documentación para los usuarios.

3.5 Diagramas de casos de uso

Los casos de uso tienen una representación gráfica denominada diagramas
de casos de uso. En estos diagramas, los actores se representan en forma de
pequeños muñecos y los casos de uso se mediante elipses contenidas dentro de
un rectángulo que representa al sistema. La participación de los actores en los
casos de uso se indica mediante una flecha que une al actor y al caso de uso.
Cada caso de uso debe tener una descripción textual.
Los diagramas de casos de uso sirven para proporcionar una visión global
del conjunto de casos de uso de un sistema (todas sus funcionalidades) así como
de los actores y los casos de uso que intervienen. Las interacciones concretas
entre los actores y el sistema no se muestran en este tipo de diagramas.

53
 Sistema

Caso de uso A

Caso de uso B

Actor 1 Actor 2

Caso de uso C
Figura 1. Diagrama de casos de uso

3.6 Relaciones entre casos de uso

A veces conviene establecer un refinamiento de los casos de uso para
mostrar claramente las interacciones. Las dos relaciones posibles y sus
semánticas según UML son las siguientes:
▪ Includes: Se dice que un caso de uso A incluye al caso de uso B, cuando B es
parte del caso de uso A, es decir, el comportamiento expresado en B forma parte
del comportamiento de A. El caso de uso B se realiza siempre dentro del caso de
uso A. Además, siempre que ocurre A ocurre también B, por lo que se dice que B
es un caso de uso abstracto.
Un caso de uso es abstracto si no puede ser realizado por sí mismo, por lo
que sólo tiene significado cuando se utiliza para describir alguna funcionalidad que
es común a otros casos de uso. Por otra parte, un caso de uso será concreto si
puede ser iniciado por un actor y realizado por sí mismo. Se suele utilizar esta
relación cuando se detectan subsecuencias de interacciones comunes a varios
casos de uso.

54
 include B
A
Ir al cine Comprar
entrada

Figura 2. Relación de Inclusión (include) entre casos de uso

▪ Extends: Un caso de uso A extiende a otro caso de uso B, cuando A expresa un

comportamiento posible de B, que ocurre en una determinada circunstancia. El
caso de uso A puede realizarse o no cuando se realiza el caso de uso B, según
las circunstancias.

extend
B: Ir al A: Comprar
cine cotufas

Figura 3. Relación de extensión (extend) entre casos de uso

Figura 4. Representaciones de las relaciones includes y extendes

55
 3.7 Organización de casos de uso
En la mayoría de sistemas, el número de casos de uso es lo
suficientemente elevado como para que sea oportuno organizarlos de alguna
forma, en lugar de tener una lista plana por la que no es fácil navegar. Una posible
forma de organizar los casos de uso es recurrir a los paquetes descritos en UML.
De esta forma, los casos de uso pueden organizarse en niveles, facilitando así su
comprensión.
Cada paquete contiene a otros paquetes o a varios casos de uso. Cuando
los casos de uso se agrupan por criterios funcionales, los paquetes que los
contienen pueden denominarse subsistemas, como se ve en la siguiente figura:

Figura 5. Organización de los Casos de Uso

3.8 Ejercicios resueltos

1) Tomando como caso de estudio el Punto de venta en un supermercado,
realizar el diagrama de casos de uso.
Para realizar un caso de uso se deben realizar varios pasos:
a) Describir el procedimiento que se realiza en un punto de venta,
identificando los escenarios claves y las actividades que se realiza en cada
escenario: En éste caso, existen dos escenarios denominados Procesar
venta y Efectuar Pago. A continuación se identifican las actividades
propias de cada escenario:
Procesar venta
 El Cajero comienza una nueva venta inicializando una caja de la tienda
 El Cajero introduce por cada producto la identificación del producto y la
cantidad

56
 – El sistema registra y presenta la línea de venta de producto (la
descripción del artículo, precio y el total asi como el total
acumulado)
 El cajero finaliza la venta
– El sistema presenta el total con el impuesto calculado

Efectuar Pago
 El cajero muestra el total a cobrar, recibe el pago, cancela la venta (y
entrega ticket)
– El sistema maneja el pago.

b) Identificar los actores presentes: El actor de un punto de venta es el

Cajero.
c) Realizar el diagrama de casos de uso, indicando las interacciones del
actor (cajero) con el sistema:

a
ent
eV
ntod Iniciar
Pu
e
lud
i nc
Procesar
e
Venta
n c lud Introducir
i Id
e
lud
Cajero i nc
Introducir
Procesar cantidad
l ude
Pago inc

Totalizar

2) Caso de uso para el Juego del ahorcado. Los pasos a seguir son:

57
 a) Descripción del procedimiento: En el juego del ahorcado participan dos
personas, el jugador y el juez; el primero es quien solicita la palabra y dice
la letra y el segundo es quien evalúa el juego del jugador. El procedimiento
para jugar es el siguiente:
▪ El jugador solicita una palabra y el juez presenta el esquema de la palabra
▪ El jugador dice una letra y el juez la marca
▪ El juez examina si la letra existe o no en la palabra:
▪ Si la letra existe en la palabra se coloca en la o las posiciones
correctas: Si es la última letra de la palabra, el jugador gana el juego
▪ Si la letra no existe en la palabra, el juez coloca una parte de la horca.
Si es la última parte de la horca el jugador pierde el juego

b) Identificar los actores: El juez y el jugador

c) Realizar el Diagrama de Caso de Usos:

Nota: Los ejemplos de Casos de Uso presentados se extrajeron de un material

elaborado por la Prof. Nancy Zambrano (UCV)

58
 3.9 Ejercicios propuestos
Realice el caso de uso para los siguientes casos:
1) Creación de un grupo o comunidad virtual en yahoo.com
2) Compra del ticket del metro, tanto por taquilla como por la máquina
3) Comprar café en una máquina expendedora
4) Ingresar al comedor de la UBV

Bibliografía
▪ Durán A. y Bernárdez B. Metodología para la Elicitación de Requisitos de
Sistemas Software Versión 2.3. Universidad de Sevilla. Abril 2002.

▪ Functional Requirements. Disponible en el URL:

http://en.wikipedia.org/w/index.php?title=Functional_requirements&redirect=no

▪ Functional Requirements and Use Cases. Disponible en el URL:

http://www.bredemeyer.com/use_cases.htm

59
 Tema IV. Requerimientos No Funcionales
Versión: 1.2

Éste tema es una traducción adaptada del libro:

Soren Lauesen. Software Requirements. Styles and Techniques.
Samfundslitteratur, 1999. Realizándose una traducción (adaptada) del Capítulo 3.

Realizado por: Prof. Eduardo Muñoz

Complementado por: Profa. Tahyca Pariata

Profa. Ana María Padrón

Revisado por: Prof. Nancy Zambrano UCV

Fecha: Septiembre de 2005

60
 4.1 Requerimientos No Funcionales.
Los requerimientos son generalmente clasificados en requerimientos
funcionales y no funcionales. Los requerimientos funcionales describen los
servicios del sistema y su comportamiento. Los requerimientos no funcionales
describen propiedades del sistema y las restricciones que existen sobre éste.
Un subconjunto particular de requerimientos no funcionales puede indicar
ciertas cualidades que el sistema debe poseer, tales como adaptabilidad o
eficiencia, entre otros. Tales tipos de requerimientos son conocidos como
requerimientos de calidad. Ya que especifican la calidad requerida del sistema.
Estos requerimientos no funcionales especifican como el sistema debe realizar sus
funciones, por ejemplo, cuán rápido funciona, que tan fácil es aprender a usarlo,
cuán fácil es su mantenimiento, entre otros.
Los ingenieros de requerimientos plantean que los requerimientos no
funcionales son muy importantes, aunque generalmente se les presta poca
atención. La razón es que son difíciles de especificar y existe poca literatura
disponible al respecto. En este capítulo, discutiremos varios tipos de
requerimientos no funcionales. Nos centraremos en los requerimientos que
pueden ser verificados.
Uno de los problemas básicos con los requerimientos no funcionales es que
no son imprescindibles tal como lo son los requerimientos funcionales. Un
requerimiento funcional es, en la mayoría de los casos, algo que el usuario
necesita, sin ello, no respondería a sus necesidades. Los requerimientos no
funcionales son diferentes. Si un requerimiento no funcional no se logra, el usuario
puede, aún, usar el sistema -al menos en muchos casos-. Entonces, ¿es
verdaderamente un requerimiento?, posteriormente trataremos esto, utilizando un
ejemplo.

61
 4.2 Factores de Calidad
¿Cuáles son los factores de calidad?. Algunos autores y organismos de
estandardización han dado respuesta a esta pregunta. La Tabla 1 compara dos
clases de listas. En la Tabla 1, del lado izquierdo se presenta un estándar de una
empresa, del lado derecho se presenta el estándar ISO 9126 (Año 1991).
A la izquierda está el primer intento (titulado McCall7). La lista es una taxonomía
de dos niveles. En el nivel superior, se sitúan tres importantes usos del software:

⋅ Operación: El uso diario dado por los usuarios finales.

⋅ Revisión: Mantenimiento y extensión del software.

⋅ Transición: Uso del software en torno a nuevas técnicas.

Incluido en cada nivel, encontramos los siguientes factores de calidad:

Factores de calidad a nivel de Operación:

⋅ Integridad: Que tan bien el sistema maneja los cambios físicos (por ejemplo.
previene intentos maliciosos de acceso, etc. El término seguridad se usa
también para este factor.

⋅ Correctitud: Cuanto cumple la aplicación con las especificaciones planteadas

por el usuario.

⋅ Confiabilidad: Cuán frecuentemente el sistema responde como se espera.

⋅ Usabilidad: Cuán fácil es aprender a usar el sistema, cuan eficiente es para las
tareas diarias, etc.

⋅ Eficiencia: Qué tan rápido responde el sistema, cuántos recursos utiliza, cómo
procesa exactamente los valores, etc.

Factores de calidad a nivel de Revisión

⋅ Mantenibilidad: Cuán fácil es localizar y reparar fallas.

7
McCall y Matsumoto E.E.U.U., 1.980

62
⋅ Prueba: Que tan fácil es probar el sistema después de un cambio.

⋅ Flexibilidad: Cuán fácil es incorporar al sistema nuevas características, es

decir, extenderlo.
Factores de calidad a nivel de Transición:

⋅ Portabilidad: Que tan fácil es trasladar el sistema a una nueva plataforma de

hardware o software.

⋅ Interoperabilidad: Cuan fácil es para el sistema cooperar con otros sistemas,

por ejemplo transferir archivos hacia hojas de cálculo, incorporar unidades
accesorias de hardware, etc.

⋅ Reusabilidad: Cuán fácil es reutilizar parte del software en otros sistemas.

Los autores sugieren también mecanismos ideales para medir estos

factores de calidad. La flexibilidad, por ejemplo, se podría medir como el tiempo
promedio en el cual se incorpora al sistema una nueva característica. Los autores
reconocen, sin embargo, que tal esquema de medición no es real debido a que es
imposible definir una característica promedio para todos los casos.
En la Tabla 1, del lado derecho se presenta el estándar ISO 9126 (Año
1991). En el nivel superior, en el estándar ISO, se tienen seis factores de calidad:

⋅ Funcionalidad: Aquí se presenta una pequeña confusión pues los factores de

calidad se suponen ser requerimientos no funcionales. Varios aspectos de la
lista de McCall son colocados aquí, tales como seguridad e interoperabilidad.

⋅ Confiabilidad: Es similar a la confiabilidad de McCall, pero abarca también la

tolerancia a fallas (robustez) y capacidad de recuperación después de las
fallas.

⋅ Usabilidad, eficiencia y portabilidad: Similares a McCall.

⋅ Mantenibilidad: Similar a McCall. Este modelo indica más explícitamente que

es importante el tiempo de localización de fallas así como evitar la introducción
de nuevos errores (análisis y estabilidad).

63
McCALL ISO 9126
Operación Funcionalidad
Integridad (integrity) Exactitud (accuracy)
Correctitud (correctness) Seguridad (security)
Confiabilidad (reliability) Interoperabilidad
Usabilidad (usability) adecuado (suitability)
Eficiencia (Efficiency) Cumplimiento (compliance)
Revisión Confiabilidad
Mantenibilidad (maintainability) Madurez (maturity)
Prueba (testability) Robustez (fault tolerante)
Flexibilidad (flexibility) Recuperabilidad
(recoverability)
Usabilidad
Transición Eficiencia
Portabilidad (portability) Mantenibilida
d
Interoperabilidad Testeo (testability)
(interoperability))
Reusabilidad (reusability) Modificabilidad
(changeability)
Análizabilidad (analysability)
Estabilidad (stability)
Prueba
Portabilidad
Adaptabilidad (adaptability)
Instalabilidad (installability)
Conformidad (conformance)
Sustituibilidad
(replaceability)
Tabla 1: Factores de calidad

La Organización Internacional de Estándares (ISO) publicó un apéndice

“informativo” con sub-características, sin el cual los factores del nivel superior
serían muy abstractos y difíciles de entender.
Varios requerimientos no funcionales adquirieron nuevos nombres como se
muestra en la Tabla 1 (integridad-Seguridad, confiabilidad-madurez, flexibilidad-
modificabilidad, y portabilidad-adaptabilidad).

64
 De la lista de McCall han sido obviados en la lista ISO: correctitud (falta de
errores) y reusabilidad (capacidad de reutilizar segmentos del software).
Algunos nuevos aspectos de calidad han surgido en el apéndice informativo
de la ISO 9126:

⋅ Confortabilidad: Si el sistema soporta adecuadamente las tareas del usuario.

⋅ Cumplimiento y Conformidad: Que tan bien el sistema satisface los estándares

del dominio y los estándares técnicos.

⋅ Nuevos sub-factores: Confiabilidad, Mantenibilidad y Portabilidad tienen

nuevos sub-factores en la lista informativa.

4.3 ¿Qué lista utilizar?

Además de éstas, hay muchas otras listas de requerimientos no
funcionales, más o menos estándares, entonces, ¿cuál usar?, la respuesta es
simple: la que convenga, incluso cualquiera puede usarse como lista de chequeo,
según los aspectos a considerar en la aplicación en cuestión. Ayuda a ello
responder a las siguientes preguntas:
¿Cuáles requerimientos no funcionales son importantes en el proyecto?
Como ejemplo, en un sistema para un hotel, factores como la usabilidad y
confiabilidad puede ser sumamente importante, mientras que la portabilidad no es
determinante.
¿Cuál es el interés del cliente? En el sistema del hotel, la usabilidad es una
aspecto relevante debido a los cambios de personal que tiene poca experiencia en
el área de tecnología de información; la confiabilidad importa porque no se puede
ofrecer servicio a los usuarios cuando el sistema se cae (falla).
¿Cómo pueden traducirse estos intereses en requerimientos? Esta es la
parte más difícil, y muchos analistas desisten en este punto. Pero es usualmente
posible derivarlos en requerimientos no funcionales.
En algunos contextos, se sigue el estándar de una compañía, pero incluso
en estos casos es conveniente seguir los pasos señalados anteriormente. Se

65
pueden consultar otras listas de factores de calidad y usarlas como listas de
chequeo.

4.4 Requerimientos de Eficiencia

Los requerimientos de eficiencia son el tipo más simple de requerimientos
no funcionales. Especifican aspectos como tiempo de respuesta y espacio en
memoria.
Podemos especificar requerimientos de tiempo relacionados con un dominio
específico, por ejemplo, el tiempo máximo que debe tomarle a un usuario experto
realizar una tarea específica. Esto es un requerimiento muy relevante. El tiempo
total de las tareas consiste en los tiempos de respuesta del producto y las
acciones humanas. Por convención, los requerimientos relativos a tareas son
considerados requerimientos de usabilidad.

4.5 Requerimientos de tiempo.

66
 La Figura 1 contiene ejemplos de requerimientos de tiempo, detallados en

Requerimientos de tiempo:

R 1.1: El producto será capaz de procesar 100

transacciones de pago por segundo cuando
el sistema esta al máximo

R 1.2: El producto deberá ser capaz de procesar

una alarma en 1 segundo, 1000 alarmas en
5 segundos.

R 1.3: En un tiempo de trabajo estándar, el uso del

CPU debe ser menos del 50%, dejando otro
50% para otros trabajos.

R.1.4: Para las funciones de edición simples, el

tiempo de
respuesta debe ser menor a 1 segundo.
Para actualizaciones simples de la base de
datos menos de 5 segundos. Para reportes
sencillos por pantallas menos de 20
segundos. (Válido para el 95% de los casos
en actividad estándar)

R1.5: Buscar una página navegando arriba y abajo

en un documento de 200 páginas, debe
tomar como mínimo 1 segundo. Buscar
Figura 1: requerimientos
usando de eficiencia
una palabra clave (tiempo)
debe tomar a lo
mucho 5 segundos.

diversas maneras. Estos requerimientos significan:

R1.1: Proviene de un sistema que maneja transacciones de tarjetas de crédito.
Una transacción es un evento con datos asociados. Se especifica el rendimiento
¿Cubre todas las funciones
de procesamiento, del software?
en términos del número de eventos de entrada que el software
¿Qué figura? ¿2 minutos? ¿4 minutos?
puede manejar por unidad de tiempo.
R1.2: Proviene de un sistema que controla la fuente de energía eléctrica en un
área geográfica. Una alarma es un evento que indica un mal funcionamiento de la
fuente de energía en el área. El usuario tiene que decidir que hacer cuando se
dispara la alarma. Para un caso específico, el usuario esperaba cerca de 1500
alarmas al año, por tanto un segundo por alarma parecía suficiente, considerando
que el usuario pasaría varios segundos estimando que hacer.
R1.3: Proviene de un sistema de multitareas que pueda desarrollar varias
actividades simultánea-mente. El software no debe monopolizar el CPU. El 50%
del tiempo de uso del CPU debe estar disponible para otras actividades.

67
 R1.4: Surge de una típica aplicación de negocios. Tiene tres clases de
funciones y define un tiempo de respuesta máximo para cada clase de función
(una especificación más precisa de las tres clases puede ser necesaria en algunos
proyectos).
Dado que los tiempos de respuesta pueden variar, dependiendo de las
entradas y del estado del sistema, el requerimiento indica que solo el 95% de los
eventos se manejan dentro del límite, y solamente en una situación de actividad
estándar. Los tres límites 1, 5 y 20, están basados en estudios de la psicología
humana. Un tiempo de respuesta de 1 minuto después de corregir un campo en
un archivo puesto en pantalla no es percibido por la mayoría de los usuarios. Un
tiempo de respuesta de cinco minutos, cuando finaliza un registro, es el límite de
espera para la mayoría de los usuarios. Si tiene que esperar más de veinte
minutos buscará otra cosa que hacer.

4.5.1 Las restricciones, ¿cuáles valores les asociamos?

¿Tenemos que especificar el tiempo de respuesta, tiempo de
procesamiento, entre otros, para todas las funciones del software? Inicialmente si,
de lo contrario, tendríamos que aceptar un sistema cuyo tiempo de respuesta para
una función ordinaria no especificada, sea de una hora. Pero si esta función no es
realmente crítica, ¿Qué límite debemos especificar?: ¿Un segundo?, ¿Un
minuto?, ¿Cinco minutos?
Algunas veces, los requerimientos no funcionales no son realmente
obligatorios. Por ejemplo, asuma que el usuario ha especificado un tiempo de
respuesta promedio de dos minutos para una función de reporte. ¿Qué sucede si
no puede conseguir ese tiempo de respuesta, sino únicamente 4 minutos? En
muchos casos, el usuario lo aceptará de todos modos, particularmente si nadie
más puede satisfacer el resto de sus requerimientos a un precio razonable.
Aparentemente, el usuario puede permitirse este límite tan alto en el tiempo
de respuesta, entonces ¿por qué solicitó un tiempo de respuesta tan bajo? Él
debió especificar 4 minutos. Desafortunadamente, esto implica que el proveedor
no se vería obligado a hacer un esfuerzo para ofrecer tiempos cercanos a 2

68
minutos, de modo que el usuario obtendría un sistema con más deficiencias.
Además, si el usuario especifica 4 minutos, usando el mismo argumento, pudiese
verse obligado a aceptar un límite más alto de tiempo.

4.5.2 Métricas abiertas

Una salida para el usuario es especificar sus expectativas y preguntar al
proveedor lo que él puede ofrecer. Esto usualmente genera una discusión de lo
que es factible. Por otro lado, el usuario puede comparar varias ofertas y
seleccionar la “mejor” de acuerdo con una evaluación total.
El principio de preguntar al proveedor lo que puede ofrecer, en lugar de
especificar de forma estricta los requerimientos, es importante en muchos tipos de
proyectos. Se utiliza el término métricas abiertas para nominar esta política.

4.6 Requerimientos de Capacidad

Otro tipo de requerimientos de eficiencia lo constituyen los requerimientos
de capacidad. El termino capacidad se refiere a los recursos computacionales que
el software puede utilizar durante cierto tiempo. La Figura 2 presenta
requerimientos de eficiencia (capacidad). Se comentan los requerimientos allí
expresados:
R 2.1: Se origina en un sistema computarizado. Asume el hecho que
algunos programas no usen todo el espacio de memoria que esté disponible,
previniendo que otros programas puedan iniciarse.
R 2.2: La fuente es un sistema de administración pública con varios
departamentos, todos circunscritos a una misma base de datos. El número de
usuarios es esencial para definir como se instala el sistema, cómo se maneja la
comunicación de los datos, etc.
R 2.3: Se tomó el sistema de reservación de hotel. En él se especifica el
número de registros que el sistema puede almacenar. Especificar un factor de
crecimiento (del 20% al año) es propio de este tipo de sistemas. En principio, el
volumen de todas las tablas (entidades) debe especificarse. La especificación
permite al proveedor tener una apreciación de la escala.

69
 R 2.4: Extraído también del sistema de la reservación del hotel. Este
requerimiento surgió al considerar modelar virtualmente por pantalla casos
extremos. Esencialmente, el analista se preguntó a si mismo que mostraría la
Requerimientos de capacidad: pantalla virtual en los peores
R 2.1: El producto deberá utilizar menos de 16 MB casos, por ejemplo cuando la lista
de memoria incluso si hay mas disponibilidad.
de huéspedes está copada. El
R 2.2: Numero simultaneo de usuarios < 2000
análisis demostró que algunas
R 2.3: Volumen de base de datos:
N° de invitados < 10.000 con crecimiento del veces un huésped (el
20% por año.
N° de cuartos < 1.000 administrador de personal de una
R 2.4: La pantalla de huésped podrá mostrar por lo compañía grande), reserva 200
menos 200 cuartos reservados/ocupados por
día, ejemplo para un evento de la compañía cuartos en la misma época para la
con un solo "usuario".
celebración anual de ventas. Los
Requerimientos de rango y exactitud: nombres de cada huésped no se
R 3.1: El campo nombre tendrá 150 caracteres. podrían tener disponibles hasta
R 3.2: Las reservaciones se podrán hacer al menos
dos años antes. que no se registrasen. Muy
R 3.3: Los datos se almacenaran en 14 bits
exactamente, ampliándose a 18 bits en dos probablemente, tal situación debe
años.
ser considerada en el diseño.
Figura 2: requerimientos de eficiencia (capacidad)

4.7 Requerimientos de rango y exactitud

Los últimos tipos de requerimientos de eficiencia son de rango y exactitud.
Comprende el rango de los datos, cuan grandes y pequeños pueden ser estos,
que tan exactos tienen que ser los datos. La Figura 2 presenta ejemplos típicos.
Observe que algunos estándares de factores de calidad (ejemplo el estándar 9126
de la ISO) consideran a los requerimientos de exactitud como requerimientos
funcionales.
R 3.1 Especifica la longitud de los nombres para las personas, lo cual
influye sobre la base de datos, los campos de la pantalla, y otros aspectos. En
muchos casos no se enumeraría como un requerimiento, sino se especificaría en
un diccionario de los datos.

70
 R 3.2 Su fuente es el sistema del hotel. Provee un catálogo con las fechas
de las reservaciones. Considere esto como un requerimiento para controlar el
volumen de ocupación de cada habitación; tomando el caso de 1000 habitaciones
deberían haber 730 (2*365) registros del estatus por habitación. Sin embargo,
implementar esto depende del criterio a usar: los cuartos libres deben tener un
estatus en la base de datos, o la ausencia de este estatus indica que el cuarto
está libre. La demanda del usuario no se basa en el volumen de la base de datos,
sino en el catálogo de fechas de reservación.
R 3.3 Es extraído de un sistema automatizado de medidas. Estos sistemas
miden aspectos físicos mediante convertidores analógicos-digitales. El
requerimiento final podría haber sido un convertidor analógico-digital de 14 bits de
precisión. Muchos desarrolladores se alegraron, porque esta medida se ajusta a la
palabra de un computador de 16 bits. Sin embargo, se conocía de antemano que
la nueva generación de convertidores analógicos-digitales tendría de 16 a 18 bits
de exactitud. El requerimiento tomó esto en consideración, dejándole a los
desarrolladores la decisión de manejarlo a 18 bits desde el principio, o utilizar el
viejo código al principio y cambiarlo luego a 18 bits.

4.8 Usabilidad
Cuando el primer cajero automático (ATM por sus siglas en inglés) fue
instalado, la gente lo utilizó poco. Técnicamente trabajaban sin problemas,
entonces ¿porqué no se usaban?. Una razón simple: eran demasiado difíciles de
utilizar. Desde entonces, los desarrolladores han ido mejorando poco a poco el
uso del cajero automático, y hoy la mayoría de la gente los considera fáciles de
utilizar.
La usabilidad (facilidad de uso, simplificando) es de vital interés en la
mayoría de los sistemas. Los sistemas costosos han fallado por tener una baja
usabilidad; el proveedor podría no cargar con esta responsabilidad ya que el
sistema satisface los requerimientos funcionales, y no se le indicó nada respecto a
la usabilidad.

71
 Los requerimientos de usabilidad deben ser tangibles a fin que puedan
verificarse y monitorearse durante su desarrollo. Obtener todas estas metas es
difícil, en la práctica, pero existen técnicas que permiten, en un alto porcentaje,
aciertos, en particular si se seleccionan y combinan varios estilos de
requerimientos.

4.8.1 Factores de usabilidad

Antes de estudiar los diferentes estilos, discutiremos brevemente que es la
usabilidad. La usabilidad no tiene nada que ver con fallas del sistema. Asumimos
que el sistema trabaja según lo previsto por el diseñador. La usabilidad se refiere a
la forma como el usuario percibe y usa el sistema.
Hay muchas maneras de definir usabilidad, pero en lo que sigue, usaremos esta
definición:
La usabilidad consiste de cinco factores:
▪ Fácil de aprender. ¿Qué tan fácil es para varios grupos de usuarios aprender a
usar el sistema?
▪ Eficiencia de la tarea. ¿Qué tan eficiente es para el usuario común?
▪ Fácil de recordar. ¿Qué tan fácil de recordar es para un usuario casual?
▪ Fácil de entender. ¿Qué tan fácil es comprender lo que el sistema hace?
▪ Satisfacción subjetiva. ¿Qué tan satisfecho está el usuario con el sistema?
Los diferentes estilos de requerimientos especifican y miden estos factores
más o menos directamente.
Los desarrolladores dicen a menudo que es imposible hacer que un sistema
satisfaga por completo todos los factores de calidad. Esto puede ser verdad, y uno
de los propósitos de los requerimientos de la usabilidad es especificar el nivel
necesario para cada factor. Como por ejemplo, un sistema de control de vuelo y
un sistema basado en la Web para atraer nuevos clientes deben contemplar
diferentes factores de la usabilidad.

4.8.2 Problemas y mecanismos de prueba de la usabilidad

72
 Un hecho importante, validado por muchos experimentos, es que nadie
puede prever los problemas de usabilidad que puede tener un usuario– ni siquiera
un experto en usabilidad. Los expertos en esta materia pueden predecir muchos
problemas de usabilidad a nivel de diseño, pero alrededor de la mitad de los
problemas son falsos, en el sentido que los usuarios no sienten que esto sea un
problema. Lo que es peor, los expertos en usabilidad ignoran más de la mitad de
los problemas que los usuarios reales experimentan.
Solo algunos tipos de prueba con usuarios reales pueden revelar los
problemas de usabilidad. Para corregir los problemas, necesitamos identificarlos
durante la primera etapa del desarrollo. Consecuentemente, las especificaciones
de usabilidad que no pueden ser probadas durante el desarrollo, tendrán serias
debilidades.
El tipo de prueba necesaria para mostrar los problemas de usabilidad se
denomina prueba de usabilidad. Es un experimento donde los usuarios reales, con
un conocimiento apropiado, intentan desarrollar tareas verdaderas por medio del
sistema o de un prototipo. Los observadores registran los problemas encontrados
por el usuario y el tiempo de ejecución de las tareas.

4.8.3 Requerimientos de usabilidad

La Figura 3 presenta seis estilos para los requerimientos de usabilidad.
Para cada estilo, hemos indicado el riesgo para el usuario y el proveedor cuando
usan el estilo. El riesgo del usuario radica en que aunque pueda conseguir lo que
especificó, quizás no obtendrá lo que realmente necesita. El riesgo del proveedor
es que puede no ser capaz de alcanzar los requerimientos - o hacerlo a un costo
excesivo.

Riesgo
Usuario Proveedor
Seis estilos para usabilidad
Estilo de performance

73
 R.1: Los usuarios novatos deben ser capaces de realizar
las tareas Q y R en 15 minutos. Los usuarios expertos
deberán realizar las tareas Q,R, y S en 2 minutos.
Estilo de defectos
R.2: En promedio, un usuario novato encontrará menos
de 0,2 defectos serios en usabilidad al realizar las tareas
Q y R.
Estilo de procesos
R.3: Durante diseño, una secuencia de 3 prototipos
deberán realizarse. A cada prototipo se le hará pruebas
de usabilidad y se corregirán los principales defectos.
Estilo de subjetividad
R.4: El 80% de usuarios debe percibir al sistema fácil
aprender y eficiente para el uso diario.
Estilo de diseño
R.5: El sistema utilizará las ventanas diseñadas. (Se
acepta si la usabilidad del diseño ha sido probada)
Estilo de lineamientos
R.6: El sistema seguirá la guía de estilo de Microsoft
Windows. Los menús tendrán como máximo tres niveles

Figura 3: Estilos para requerimientos de usabilidad

Estilo de performance
R1: Los principiantes pueden ser capaces de realizar las tareas Q y R en 15
minutos. Los usuarios expertos son capaces de realizar las tareas Q, R, y S en 2
minutos.
En el estilo de performance especificamos cuan rápido los usuarios pueden
aprender varias tareas, con que rapidez pueden realizar sus labores después del
entrenamiento, entre otros. Podemos verificar estos requerimientos a través de
pruebas de usabilidad. Por medio de prototipos, podemos hacer pruebas de
usabilidad durante la primera etapa del desarrollo, de modo de proyectar los
requerimientos del diseño.
El estilo armoniza bien con los casos del uso. Las tareas pueden ser casos
de uso. Además, los requerimientos de performance podrían encontrar un lugar en
la descripción del caso de uso. El estilo captura bastante bien la esencia de la

74
usabilidad, lo que significa que si el software cumple los requerimientos, el usuario
consigue lo que necesita. El problema principal es seleccionar las tareas
adecuadas.
Sin embargo, el estilo es riesgoso para el proveedor. No hay garantía de
que se puedan recabar todos los requerimientos. Un factor como la eficiencia en el
uso diario puede ser difícil de verificar durante el desarrollo.
Sorprendentemente, cuando el usuario selecciona y compra un software
estándar, el estilo conlleva bajo riesgo para ambas partes. ¿Por qué? Porque el
software está terminado y se pueden tomar medidas antes de decidir comprarlo.

Estilo de Defectos
R2: En promedio, un usuario nuevo encontrará menos de 0,2 defectos de
usabilidad al realizar las tareas Q y R. Un problema serio de usabilidad es una
tarea que falla, es decir, una tarea que el usuario no puede terminar. Así que el
requerimiento debería definirse como que el 80% de los usuarios sean capaces de
terminar las tareas por si mismos.
El estilo de defecto se asemeja al estilo de performance, pero en lugar de
medir tiempos de ejecución de las tareas, identifica los defectos de usabilidad del
sistema y especifica con que frecuencia pueden ocurrir. Un defecto de usabilidad
puede hacer que el usuario incurra en equivocaciones o se sienta molesto. Por
ello se le solicita al usuario pensar en voz alta durante la prueba de usabilidad
mientras un observador registra los defectos.
La ventaja principal del estilo es que la lista de defectos provee a los
desarrolladores un excelente feedback, permitiéndoles corregir el diseño con
mayor facilidad. La desventaja es que estamos menos seguros de captar la
esencia de la usabilidad. Por ejemplo, el bajo rendimiento diario será reportado
como un defecto de usabilidad si el usuario se queja por ello.

Estilo de proceso
R3: Durante el diseño, se realizarán tres prototipos. Cada prototipo deberá
ser probado en cuanto a usabilidad y se corregirán los principales defectos.

75
 El estilo de proceso especifica el procedimiento de desarrollo a usarse para
asegurar la usabilidad. El estilo no dice nada acerca del resultado del desarrollo,
pero el usuario espera que el proceso genere un buen resultado. El ejemplo
especifica el desarrollo basado en un prototipo iterativo ya que se admite como un
proceso eficaz.
¿Cuántas iteraciones necesitamos hacer? Debemos especificar el criterio
de finalización del número de interacciones, por ejemplo continuar hasta no
detectar ningún defecto serio de usabilidad, pero entonces tendríamos un estilo de
defecto, en lugar de un estilo de procesos. Sin embargo, podríamos especificar
que las iteraciones serán negociadas entre el usuario y el proveedor después de
tres iteraciones. Esto aún estaría en el marco de estilo de procesos.
El usuario no puede estar seguro de tener lo que necesita, porque se deja
mucho en mano de los desarrolladores, quienes seleccionan a menudo las tareas
y los usuarios para la prueba de usabilidad, o hacen solamente cambios menores
a los prototipos en lugar de rediseñarlos. El resultado puede ser que la usabilidad
sigue siendo inaceptable después de tres iteraciones.

Estilo subjetivo
R4: El 80% de los usuarios deberá indicar que el sistema es fácil de
aprender y es eficiente para el uso diario.
Con el estilo subjetivo, preguntamos a los usuarios su opinión,
tradicionalmente a través de cuestionarios. Esto parece captar la esencia de
usabilidad. Desafortunadamente, los usuarios expresan a menudo satisfacción con
el sistema a pesar de tener evidencias de que el sistema es incómodo y les hace
perder mucho tiempo.
La satisfacción con el sistema está fuertemente influenciada por factores
organizacionales fuera del alcance del desarrollador del sistema. Otro problema
con el estilo subjetivo es que es difícil verificar el requerimiento durante el
desarrollo. Muchos expertos preguntan a los usuarios su opinión subjetiva
después de haber hecho pruebas de usabilidad del prototipo, pero esto no se
correlaciona con sus opiniones después del desarrollo del sistema.

76
 El resultado es que tanto el usuario como el proveedor corren un alto
riesgo.

Estilo de Diseño
R5: El sistema utilizará las pantallas diseñadas. El menú y los botones
trabajarán como se describe en…
El estilo de diseño describe los detalles de la interfaz del usuario.
Substancialmente, ello transforma los requerimientos de usabilidad en
requerimientos funcionales. Los requerimientos de usabilidad son fáciles de
verificar en el software final y fácil de observar durante el desarrollo. El proveedor
corre un riesgo bajo.
A través del diseño, los ingenieros de requerimientos han tomado toda la
responsabilidad de la usabilidad. El diseñador del sistema y el programador
pueden hacer pequeños cambios a la usabilidad. Si el ingeniero de requerimientos
ha hecho un cuidadoso trabajo con el análisis de las tareas, el prototipaje y las
pruebas de usabilidad, la usabilidad final lograda será adecuada y por ende el
usuario corre un bajo riesgo. De lo contrario, su riesgo es alto - él no conseguirá lo
que necesita.
Los prototipos que no son probados pueden usarse como ejemplos de lo
que el usuario piensa, más no como un requerimiento de usabilidad.

Estilo de Lineamientos
R6: El sistema podría seguir los lineamientos de Microsoft Windows. Los
menús deben tener como máximo tres niveles.
El lineamiento de estilo señala la apariencia general y la respuesta sobre la
interfaz de usuario. Puede interpretarse como un requerimiento funcional que se
aplica a cada ventana, etc. Los lineamientos pueden ser estándares, guías de
corporaciones o reglas basadas en la experiencia.

77
 Aunque los lineamientos generalmente mejoran la usabilidad, tienen poca
relación con la esencia de la usabilidad. En otras palabras, se puede tener un
sistema que los usuarios encuentren muy difícil de utilizar aún siguiendo los
lineamientos. (Dichos sistemas son realmente comunes, como se demuestra en
muchos programas que siguen las pautas de Microsoft Windows y aún así son
muy difíciles de utilizar). Como complemento de otros estilos, el estilo de
lineamientos es muy útil, particularmente para ayudar a los usuarios que alternan
entre aplicaciones.

4.9 Mantenimiento
La mayoría de los productos necesitan mantenimiento, debido a muchos
factores, tales como: los usuarios encuentran errores en ellos, la demanda crece,
el ambiente cambia. Muchos proveedores hacen muy buenos negocios en esta
área y los clientes se ven forzados a pagar por estos servicios. En algunos casos,
los proveedores venden la primera versión del producto a un precio accesible y
después obtienen muchos beneficios con el mantenimiento.
Los costos de mantenimiento pueden convertirse en una verdadera carga
para los clientes, esto debido a los honorarios cobrados por los proveedores y a
interrupciones en los negocios mientras que el mantenimiento se realiza; el
objetivo de los requerimientos de mantenimiento, es resguardarse de ambos
factores.

4.9.1 ¿Que es el Mantenimiento?

Usualmente los ingenieros de software distinguen entre tres tipos de
mantenimiento:
⋅ Mantenimiento correctivo: Corregir defectos en el producto.
⋅ Mantenimiento preventivo. Corregir los defectos que no han causado
problemas, pero que pudieran hacerlo más adelante. Un ejemplo típico es
cuando el proveedor corrige un defecto reportado, pero ignora que éste influye

78
 en algo más, de manera que causará problemas más adelante. Evitar defectos
relacionados es esencial para ambos: cliente y proveedor, ya que las
reparaciones adicionales resultan ser muy costosas para ambos.
⋅ Mantenimiento perfectivo. Extender el sistema para cubrir demandas
adicionales.
Los requerimientos de mantenimiento tratan con los tres tipos señalados.
Otro aspecto es cómo se definen los defectos y que tipo de reparación necesita el
cliente. Observe el ciclo de mantenimiento: ¿qué sucede con un defecto o un
pedido de cambio?.

Mantenimiento Mantenimiento
correctivo preventivo

Operación Producto Operación

Diaria Diaria

Nueva versión

Mantenimiento
perfectivo

Ciclo de mantenimiento:

Reportes de problemas
Análisis: ¿defecto, demanda?
Clasificar: ¿rechazo? ¿Labores?
¿Reparar? ¿Nueva versión?
Hacer cambio
Prueba
Instalar

4.9.2 Ciclo de Mantenimiento

Un problema es reportado al equipo de mantenimiento.
Se analiza el reporte. ¿Es un mal funcionamiento o un comportamiento previsto
del producto?, ¿es un pedido de cambio?, ¿dónde está el defecto que causa el
mal funcionamiento?, o ¿cuál es la necesidad real detrás del pedido de cambio?

79
 El reporte es clasificado: ¿es un defecto o un pedido de cambio?,
¿debemos rechazarlo porque no es realmente un problema del producto?, ¿lo
repararemos inmediatamente o se puede esperar el lanzamiento de la siguiente
versión del producto?.
Hacer un cambio del producto, sea como un parche a ser distribuido
inmediatamente o como parte de la próxima versión.
Testear el cambio. Tratar de encontrar y corregir defectos relacionados que
pudiesen presentarse mas adelante.
Instalar el cambio y asegure que los datos del usuario, configuraciones,
entre otros, son transferidos.
Muchos proveedores no tienen un ciclo de mantenimiento bien establecido
y parte de los requerimientos podrían ser que definan uno.

4.9.3 ¿Que es un Defecto?

Parte del ciclo de mantenimiento consiste en determinar si algo es un
defecto o un pedido de cambio, esto puede ser difícil en la práctica. Usualmente,
el contrato indica que el proveedor tiene que corregir defectos, mientras que el
cliente tiene que pagar por los cambios.
Para evitar malos entendidos los comités han estipulado que el contrato
podría contener una normativa en la cual los desacuerdos a cerca de los defectos
deberían ser decididos por algún árbitro entre ambas partes (proveedor y cliente).

4.9.4 Requerimientos de Mantenibilidad

A continuación se presentan cinco estilos para requerimientos de
Mantenibilidad, algunos de ellos ilustrados con más de un requerimiento.

Estilo de performance
R 1.1: El proveedor analiza y clasifica el 95% de reportes contenidos en dos
horas de trabajo. Los defectos urgentes serán reparados en las próximas 30 horas
del trabajo en el 95% de los casos.

80
 Limita el tiempo que el usuario tiene que esperar antes de conocer como
proceder después de un problema; en la mayoría de estos casos las reparaciones
se puede realizar de forma inmediata, pero existen otras reparaciones que son
garantizadas dentro de un periodo específico. Los requerimientos reconocen que
algunos problemas son más difíciles, pero su número es limitado. Por otra parte,
detalles acerca de qué se entiende por horas de trabajo, cómo se responde al
usuario, etc.; se deben especificar en el proyecto.
R1.2: Cuando se repara un defecto, los defectos relacionados no reparados
deberían ser menos de 0.5 en el promedio.
Trata con el mantenimiento perfectivo. Esto obliga al proveedor a encontrar
cuáles problemas están relacionados en lugar de realizar sólo un parche. Se
asume por supuesto que los reportes de defecto han sido recopilados y
analizados.
R1.3: Para un periodo de dos años, el proveedor aumentará el costo del
producto
Ello limita el costo del mantenimiento perfectivo. En esencia, esto indica que las
mejoras tendrán un costo proporcional a su tamaño. El costo ha sido fijado, y en el
ejemplo se le pide al proveedor especificarlo, de modo que el cliente pueda
comparar con otros proveedores.
El estilo de performance puede acercarse a las necesidades esenciales del
cliente; además este estilo es reconocido en algunos dominios como una forma de
medir el desarrollo de un trabajo independiente de técnicas de programación y
experiencia del programador.

Estilo de Procesos de soporte

R 2.1 La Instalación de una nueva versión debe dejar el contenido de la
base de datos y todos los registros personales inalterados.
Trata con una situación frecuente. El proveedor ha instalado una nueva
versión para la compañía, y todos los usuarios se ven en la necesidad de pasar

81
horas estableciendo todas las funcionalidades del nuevo sistema. Los
requerimientos no dicen si el proveedor tratará de forma manual los cambios o si
su producto realizará los ajustes automáticamente.
R 2.2: El proveedor colocará una estación de mantenimiento calificada para
los clientes.
Requiere exclusivamente de una persona que se encargue del
mantenimiento, de manera que un cliente no dependa de otros clientes.
R 2.3: El proveedor deberá depositar los códigos y toda la documentación
de cada versión y sus correcciones.
Es una medida de emergencia en caso que el proveedor suspenda las
negociaciones o no satisfaga los requerimientos de mantenimiento. En este caso,
el cliente puede encontrar a alguien más que realice el mantenimiento, la
codificación y documentación necesaria.
En el estilo de proceso asistido se especifican todas las cosas que suceden
durante el mantenimiento, pero no dice nada acerca de su duración.

Estilo de Proceso de Desarrollo

R3.1: Cada módulo del programa debe ser evaluado para su mantenimiento
de acuerdo a ciertos procedimientos. Al menos el 70% debe ser " altamente
mantenible" (y ninguno debe ser " pobremente”).
Se trata de asegurar que el mantenimiento puede ser realizado por terceras
partes.
R3.2: El proceso del desarrollo debe tener procedimientos de test
recurrentes que se realicen una y otra vez y que se continúen durante doce horas.
Trata con el problema frecuente de los desarrolladores cuando cambian
algo que resulta tener un efecto no esperado. Un test de regresión es un
procedimiento automatizado que prueba el producto con los primeros test de
prueba y relata cualquier desviación en la salida. El estilo de proceso de desarrollo
tratar de forzar un enfoque de desarrollo que facilite el mantenimiento del
producto.

82
 Actividades propuestas al estudiante
1) ¿Defina que es un requerimiento no funcional?
2) ¿Nombre los requerimientos no funcionales de su Caso de Estudio?
3) Determine cual sería el modelo de mantenimiento correctivo en su Caso de
Estudio.
4) Realice el ciclo de mantenimiento de su Caso de Estudio.

83
 Tema VI. Documento de Requerimientos
Versión: 1.3

Este material se basa en:

Durán A. y Bernárdez B. Metodología para la Elicitación de Requisitos de
Sistemas Software Versión 2.3. Universidad de Sevilla. Abril 2002.

Realizado por: Profa. Ana María Padrón

Revisado por: Prof. Nancy Zambrano UCV

Fecha: Septiembre de 2005

6.1 Concepto Documento de Requerimientos

Constituye uno de los elementos oficiales que se entrega al usuario con la
finalidad de informar acerca de los avances del software solicitado. Dicho
documento se enfoca en lo que el sistema debe hacer sin especificar como debe

84
hacerse. La presentación de la información contendida en el documento de
requerimientos depende del equipo desarrollador, del usuario, sin embargo existe
un modelo generalmente aceptado para el desarrollo de éste producto entregable.
El esquema comprende los siguientes tópicos:
 Portada
 Lista de cambios
 Índice
 Lista de figuras
 Lista de tablas
1. Introducción
2. Participantes en el proyecto
3. Descripción del sistema actual (opcional)
4. Objetivos del sistema
5. Catálogo de requerimientos del sistema
5.1. Requerimientos de almacenamiento de información
5.2. Requerimientos funcionales
5.2.1.Diagramas de casos de uso
5.2.2.Definición de actores
5.2.3.Casos de uso del sistema
5.3. Requerimientos no funcionales
6. Matriz de rastreabilidad objetivos/requerimientos
7. Conflictos pendientes de resolución (opcional)
8. Glosario de términos (opcional)
9. Apéndices

El esquema puede adaptarse a cada caso, lo que implica que puede

añadírsele nuevos aspectos así como omitir otros, todo dependerá del caso en
estudio y de los participantes.

6.2 Elementos del Documento de Requerimientos

6.2.1 Portada

85
 Debe contener el nombre del proyecto, la identificación del equipo
desarrollador, identificación del usuario, la fecha de publicación del documento y la
versión. Con relación a éste último aspecto, es de destacar que se compone de
dos números (x, y). El primer dígito (x) indica la versión del documento y se
incrementa cada vez que se hace una nueva entrega formal al usuario.
El segundo digito (y) denota cambios dentro de la misma versión, que aún
no ha sido entregada oficialmente al usuario. El valor de y varía en dos
escenarios:
1. Al publicar una versión del documento que refleja cambios en relación con
la última versión, más no ha sido entregada formalmente. Ejemplo: El
equipo desarrollador entregó al usuario la versión 1.0 del Documento de
Requerimientos, posteriormente se hicieron modificaciones plasmadas en
otro documento (conocido solo por los miembros del equipo desarrollador),
dando origen a la versión 1.1.
2. Cuando se elabora una nueva versión oficial del documento, el valor de x
se incrementa, quedando y con valor cero (0) para indicar que es la primera
entrega de esa versión. Ejemplo: Se consolidaron los cambios realizados
en la publicación 1.1, y se elaboró una nueva versión del documento de
requerimientos para entregársela al usuario, siendo ésta la versión 2.0.

86
 Proyecto [Nombre del Proyecto]

Documento de Requerimientos del

Sistema

Versión [x.y]
Fecha [día/mes/año]

Figura 1. Portada

Nota: La información que está dentro de los corchetes [ ], debe sustituirse con los
datos propios del caso de estudio.

6.2.2 Lista de cambios

El Documento de Requerimientos se entrega al usuario en diversas
oportunidades para mostrar los avances alcanzados así como las respectivas
modificaciones. Cada vez que se entrega al usuario otro documento se crea una
versión, así el primer Documento de Requerimientos que se entregue será la
versión 1.0, la segunda entrega formal corresponderá a la versión 2.0 y así
sucesivamente.
Cada uno de los cambios efectuados debe ser reflejado en la sección Lista
de Cambios, señalando el número de la orden, la fecha de la modificación, una
breve descripción de las modificaciones realizadas y el autor o autores que
efectuaron los cambios.

87
 Número
Fecha Descripción Autores
orden
Creador (es) del
0 Fecha inicial Versión (1.0). documento.
Describir el primer cambio:
Creador (es) del 1er
1 Fecha 1 cambio indicar la ubicación dentro del
er

cuerpo del documento y cual cambio

fue el cambio.
. . . .
. . . .
. . . .
Fecha del Creador (es) del
N Fecha del cambio n
cambio n cambio n

Tabla 1. Lista de cambios

6.2.3 Índice
El índice refleja la estructura del documento con su respectiva ubicación, es
decir, menciona el número de la página donde inicia cada aspecto. Para ayudar al
lector a comprender con mayor claridad la estructura del documento, se
recomienda identar o sangrar los temas y sus subtemas. Ver ejemplo

Índice General
Introducción............................................................. 1
Objetivos ……………………... ................................. 2
Identad Administrar Usuario ........................................... 3

o Administrar Equipo ............................................ 4

Requerimientos Funcionales ................................. 2
Registrar Usuario................................................ 3
Registrar Equipo................................................. 4
Requerimientos No Funcionales.............................. 9

Figura 2. Índice General

6.2.4 Lista de figuras y tablas

88
 El documento de requerimientos puede contener dentro de su cuerpo,
figuras y tablas que apoyan el desarrollo. Estos elementos deben ser listados en
un Índice de Figuras y un Índice de Tablas respectivamente. Por ser un índice
deben contener el nombre de la tabla o la figura y la página donde está ubicada.

Índice de Figuras

1 Caso de Uso Base .......................................... 1

2 Caso de Uso Registrar Usuario ...................... 2
3 Caso de Uso Registrar Máquina ..................... 3
4 Caso de Uso Modificar Usuario ...................... 10
5 Casos de uso Eliminar Usuario ..................... 12
6 Caso de Uso Modificar Máquina ................... 13
7 Caso de Uso Eliminar Máquina ..................... 15

Figura 3. Índice de Figuras

Índice de Tablas

1 Lista de cambios ............................................. 1

2 Lista de usuarios ............................................. 2
3 Cronograma de actividades ............................ 3
4 Lista de aportes .............................................. 5
5 Actores …. ........................................................ 6
6 Matriz de Rastreabilidad................................... 8

Figura 4. Índice de Tablas

6.2.5 Introducción

89
 Contiene el propósito del documento de requerimientos, el alcance del
software, las referencias, definiciones, acrónimos y abreviaturas usadas dentro del
documento. Asimismo, se puede incluir una descripción breve del caso de estudio
y cualquier otro elemento que permita comprender el contexto de desarrollo.

6.2.6 Participantes en el proyecto

Todas las personas inmersas en el proyecto, desarrolladores y usuarios se
presentan en ésta sección. La lista debe contener el nombre de cada miembro, la
organización a la cual pertenece, el rol que cumple dentro del proyecto y cualquier
otra información que se desee resaltar.

6.2.7 Descripción del sistema actual

Si el proyecto en curso ha abarcado el estudio de la situación presente,
antes del desarrollo del proyecto, se debe describir el funcionamiento de éste
sistema. Para ello se puede hacer uso de diversas técnicas, como por ejemplo el
Diagramas de Actividad de Bootch (1999), entre otros.
La descripción del sistema actual ubicará al usuario en el contexto de
partida y en su posterior transición al modelo de desarrollo.

6.2.8 Objetivos del sistema

Es la sección donde se describen los objetivos que se plantean alcanzar al
finalizar e implantar el software a desarrollar; engloba tanto los objetivos generales
como los objetivos específicos. Para su presentación, existe un formato modelo o
plantilla para objetivos como también se conoce, donde se detallan los atributos de
cada objetivo planteado. A continuación se indican los campos de la plantilla.

Objetivo Nº[ ] [Nombre descriptivo y código]

90
Versión [Número de la versión actual] ([fecha de la versión
actual])
Autores [Autores de la versión actual] ([Organización del autor])
Fuentes [Fuente de la versión actual: usuario, etc.]
([Organización del autor])
Descripción El sistema deberá [objetivo a cumplir]
Objetivos Específicos Planteamiento de los objetivos específicos
Importancia Indicar la importancia del objetivo; esto puede hacerse
asignando un número o una palabra (vital, relevante,
entre otros)
Urgencia Se puede indicar mediante un número o una frase:
urgente, inmediatamente, puede esperar
Estado Indica el avance: en construcción, pendiente de
negociación, pendiente de validación, validado.
Estabilidad Indica la posibilidad de cambiar el objetivo a futuro; se
puede usar números para indicar la estabilidad o
frases: alta, media, baja. Este campo ayuda a los
diseñadores a diseñar el software de manera que
pueda adoptarse a los posibles cambios.
Comentarios Cualquier descripción adicional.

Tabla 2. Plantilla de objetivos

6.2.9 Catálogo de requerimientos del sistema

Comprende la descripción de todos los requerimientos del sistema:

▪ Requerimientos de almacenamiento

91
 ▪ Requerimientos funcionales:

 Diagramas de casos de uso

 Definición de actores
▪ Requerimientos no funcionales.

6.2.10 Requerimientos de almacenamiento de información

Son aquellos elementos relevantes, que deben ser almacenados en el
sistema para su respectiva gestión y logro del objetivo planteado
En ésta sección se presentan, usando la plantilla, cada uno de los
requerimientos que almacenará la aplicación, especificando los objetivos a los
cuales están asociados, la descripción del requerimiento, los elementos
específicos a almacenar, la duración temporal y su importancia.
A continuación se presenta una plantilla para registrar los requerimientos de
información. Ésta plantilla es un modelo propuesto, cada organización puede
plantear un formato propio para documentar los requerimientos elicitados.

RI <identificación> [Nombre descriptivo y código del requisito]

Versión [Número de la versión actual] ([fecha de la versión actual])

92
Autores [Autores de la versión actual] ([Organización del autor])
[Fuente de la versión actual: usuario, usuario, etc.] ([Organización del
Fuentes
autor])
Obj. - X <Nombre>
[Se colocan los objetivos relacionados con el requisito señalado. De
Objetivos asociados
ésta manera se visualiza cuales son los requerimientos que se
requiere para lograr los objetivos planteados.]
Requerimientos Rx-y <nombre del requisito>
asociados [Otros requerimientos vinculados con el requisito que se describe.]
Descripción En esta parte se indican el concepto relevante del sistema.
Datos específicos <datos específicos del concepto relevante del campo anterior>
{pasado y presente, solo presente}
Las opciones reflejan el tiempo durante el cual la información es
Intervalo temporal relevante para el sistema. La frase "pasado y presente" indica que la
información es siempre relevante; "solo presente" se usa para
señalar que la información tiene un período determinado de validez.
Importancia Trascendencia del requerimiento: vital, relevante, etc.
Se puede indicar mediante un número o una frase: urgente,
Urgencia
inmediatamente, puede esperar.
Indica el avance: en construcción, pendiente de negociación,
Estado
pendiente de validación, validado.
Indica la posibilidad de cambiar el objetivo a futuro; se puede usar
Estabilidad números para indicar la estabilidad o frases: alta, media, baja. Este
campo ayuda a los diseñadores a prever cambios en el diseño.
Comentarios Cualquier descripción adicional.

Tabla 3. Plantilla para Requerimientos de Almacenamiento

6.2.11 Requerimientos funcionales

Los requerimientos funcionales son los procedimientos o funciones que
debe hacer el sistema para lograr el objetivo planteado. Comprende los
diagramas de casos de uso, la definición de actores y los casos de uso del
sistema.

93
UC <id> [Nombre descriptivo y código del requisito]
Versión [Número de la versión actual] ([fecha de la versión actual])
Autores [Autores de la versión actual] ([Organización del autor])
[Fuente de la versión actual: usuario, usuario, etc.] ([Organización del
Fuentes autor])
Obj. - X <Nombre>
Objetivos asociados [Se colocan los objetivos relacionados con el requisito señalado.
Requerimientos Rx-y <nombre del requisito>
asociados [Otros requerimientos vinculados con el requisito que se describe.]
Describen lo que hará el caso de uso. Pueden iniciar con la frase “El
Descripción sistema deberá comportarse tal como se describe en el siguiente
caso de uso”.
Precondición Condición previa que debe cumplirse para poder ejecutarse el CU
Paso Acción
P1 El actor o el sistema inicia….[Colocar la acción]
Secuencia Normal P2 Se realiza el caso de uso [Colocar Nº de caso de uso]
Si se cumple al siguiente condición, se realiza [colocar
P3
acción]
Poscondición Condición que resulta luego de aplicar el caso de uso.
Paso Acción
Describir la excepción que puede ocurrir de no sucederse con
P2
Excepciones normalidad el paso dos citado en la secuencia normal
Describir la excepción que puede ocurrir de no sucederse con
P3
normalidad el paso tres citado en la secuencia normal
Paso Tiempo
Rendimiento
q Cantidad de tiempo con su unidad. Ejemplo. 10 minutos
Frecuencia Nº de veces que ocurre el caso de uso / unidad de tiempo
Se puede indicar mediante un número o una frase: urgente,
Urgencia inmediatamente, puede esperar.
Indica el avance: en construcción, pendiente de negociación,
Estado pendiente de validación, validado.
Indica la posibilidad de cambiar el objetivo a futuro; se puede usar
Estabilidad números para indicar la estabilidad o frases: alta, media, baja.
Comentarios Cualquier descripción adicional.
Figura 5. Plantilla para recabar los Requerimientos Funcionales

El campo Precondición, se usa para denotar cuales condiciones deben

darse para que se pueda realizar el caso de uso. En el campo de Secuencia
Normal, se expresa en lenguaje natural las interacciones del caso de uso, de
forma sistemática, similar a un algoritmo.

94
 6.2.12 Diagramas de casos de uso
Un caso de uso es la descripción secuencial de interacciones entre el
sistema y las personas que interactúan con él (denominados actores). Los casos
de uso son una técnica tanto de Elicitación como de especificación de los
requerimientos funcionales. Su representación gráfica se realiza mediante
Diagramas de casos, en los cuales los actores son representados por pequeñas
figuras y los casos de uso por elipses diagramados dentro de un rectángulo que
viene a ser el sistema.

6.2.13 Definición de actores

Los actores son las personas que interactúan con el sistema. En ésta
sección se identifican y se señala cual es el rol que ocupan, usando como
referencia la plantilla de definición de actores.

Caso de uso A

Caso de uso B

Actor 1 Actor 2

Caso de uso C

Sistema

95
 Figura 7. Plantilla de Actores

6.2.14 Casos de uso del sistema

Se muestran los casos de uso identificados en el problema en estudio. Los
casos de uso pueden explicarse en la plantilla de Requerimientos Funcionales, de
hecho la plantilla que se presenta a continuación es un extracto de la plantilla de
Requerimientos Funcionales

Figura 8. Plantilla para Casos de Uso

6.2.15 Requerimientos no funcionales

Los requerimientos no funcionales asociados al software de desarrollo,
son listados en ésta parte.

96
 Figura 09. Plantilla de Requerimientos No Funcionales

6.2.16 Matriz de rastreabilidad objetivos/requerimientos

Con la finalidad de conocer con cuales requerimientos están asociado un
objetivo, se realiza una matriz donde se relacionan los objetivos con sus
respectivos requerimientos. La información se presenta mediante la matriz de
rastreabilidad.

Figura 10. Matriz de Rastreabilidad

6.2.17 Conflictos pendientes por resolver

Esta sección es opcional y en ella se registran los conflictos que se han
presentado durante el proceso de desarrollo y que aún no han sido resueltos. La
descripción se realiza usando como base la Plantilla para conflictos que se
presenta en al figura nº 10.

97
 Figura 10. Plantilla para Conflictos pendientes

6.2.18 Glosario de términos

Sección opcional en la que se presenta alfabéticamente la definición de
términos, acrónimos y abreviaturas empleadas en el documento que se considere
que no son comunes al lector.

6.2.19 Apéndices
Se usan para suministrar información referente a la documentación
obligatoria del documento de requerimientos.

Actividades sugeridas al docente

1. Dar ejemplos en los cuales el estudiante pueda visualizar como se compone la
versión del documento de requerimientos. Plantear varios escenarios donde
cambien los números de la versión: el primer dígito, el segundo, ambos.
2. Plantear la investigación documental acerca de técnicas de identificación y
formulación de objetivos.
3. Formar grupos de discusión para debatir acerca de lo investigado. Explicar
como se debe formular un objetivo.

98
4. Con base al caso de estudio modelo (Diseño de una página Web para la
Unidad Curricular) plasmar los siguientes elementos (los cuales se han
determinado en temas previos):
 Actores
 Requerimientos
 Funcionas del sistema actual (casos de uso)
 Objetivos del sistema propuesto

Actividades propuestas para el alumno

1) Identificar cual es la versión del documento de requerimientos en los siguientes

escenarios:
a) Un grupo de estudiantes de la UBV está desarrollando un software para
enseñar a señores de la tercera edad, de la Casa del Abuelo "Las tres
gaviotas", a navegar en Internet. Una vez recabados todos los elementos, el
equipo de desarrolladores entrega al usuario el Documento de
Requerimientos del Software.
Versión __ . ___

b) Los diseñadores del equipo de desarrollo del software para enseñar como
navegar en la web, realizaron cambios en la interfase con el usuario y
publicaron al resto del equipo un documento con la descripción de los
cambios respectivos.
Versión __ . ___

99
 c) Como consecuencia de los cambios de diseño, los programadores
efectuaron otras modificaciones al software, las cuales publicaron en un
documento.
Versión __ . ___

d) Finalmente se entrega al usuario un documento con todas las

modificaciones efectuadas tanto al nivel de diseño como programación.
Versión __ . ___

2) Diseñar una lista de cambios tomando como base los datos del ejercicio
anterior.

3) Elaborar un índice general donde se use la identación o sangrado de los

temas.

4) El Centro Nacional de Tecnologías de Información (CNTI) lideriza el proyecto

de la Academia de Software Libre, para formar al personal de las instituciones
públicas en el uso del software libre. Identifique el o los objetivos, los actores y
los casos de uso. Emplee las plantillas correspondientes.

5) Hacer un cuadro comparativo entre Requerimientos funcionales y no

funcionales.

100
 Tema VII. Estándares
Versión: 1.2

Este material se basa en el siguiente documento:

Rafael López Calero. “Desarrollo de un Servidor de Información con soporte
para acceso ubicuo a través de una red privada virtual”. Universidad de Castilla –
La Mancha. Escuela Superior de Informática. Ingeniería en Informática, Abril 2003.
http://alarcos.inf-cr.uclm.es/doc/pgsi/doc/trab/T9899_ICaballero.pdf
http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER04/Claudia_Ayala.pdf

Realizado por: Profa. Tahyca Pariata

Revisado por: Prof. Nancy Zambrano UCV

Fecha: 21 de Septiembre de 2005

101
 7.1 Introducción
En el proceso de construcción y desarrollo de proyectos se aplican métodos
y técnicas para resolver los problemas, la informática aporta herramientas y
procedimientos sobre los que se apoya la ingeniería de software. La Ingeniería de
Software permite: mejorar la calidad de los productos de software, aumentar la
productividad, facilitar el control del proceso de desarrollo de software, suministrar
a los desarrolladores las bases para construir software de alta calidad.
A partir de la Ingeniería de software se han introducido y popularizado una
serie de estándares para medir y certificar la calidad, tanto del sistema a
desarrollar, como del proceso de desarrollo en sí. Un número creciente de
herramientas automatizadas han surgido para ayudar a definir y aplicar un proceso
de desarrollo de software efectivo. En la actualidad la economía en casi todos sus
aspectos, depende más de sistemas automatizados que en el pasado; esto ha
llevado a los equipos de desarrollo a enfrentarse con una nueva década de
procesos y estándares de calidad.
Por medio de los estándares se pueden hacer las cosas más fáciles,
definiendo características de objetos y sistemas que se utilizan cotidianamente.
Todas las industrias funcionan con estándares, la industria informática también
utiliza estándares tanto para los componentes de Hardware (teclados, monitores,
entre otros) como los de Software.
Los estándares para software se aplican generalmente a características
básicas de la interfaz de usuario. Con el hecho de desarrollar estándares para la
interfaz se intenta conseguir un software más fácil y seguro, estableciendo unos
requisitos mínimos de fabricación y eliminando inconsistencias y variaciones
innecesarias en las interfaces.

7.2 Estándar
Un Estándar se puede definir como "lo que es establecido por la autoridad, la
costumbre o el consentimiento general". En este sentido se utiliza como sinónimo de
norma.

102
 7.3 Norma
Documento establecido por consenso y aprobado por un organismo reconocido,
que proporciona, para un uso común y repetido, reglas, directrices o características para
actividades o sus resultados, con el fin de conseguir un grado óptimo de orden en un
contexto dado.

7.4 Normalización

La normalización o estandarización es la redacción y aprobación de normas.

7.5 Tipos de Estándares

 Locales: Diseño o practica aceptada desde una industria, organización profesional o

entidad empresarial autorizados a nivel local.

 Nacionales: Es una convención aceptada por una amplia variedad de organizaciones

dentro de una nación.

 Internacionales: Es un consenso entre organizaciones de estándares a nivel mundial.

7.6 Clasificación de los Estándares

 Estándares de Ley (de iure o de jure): Estos estándares son generados por un
comité con estatus legal y están avalados por el apoyo de un gobierno o
institución para producir estándares.

En informática existen una serie de comités que han participado en la

creación de muchos estándares de iure, como por ejemplo: ANSI (American
National Standards Institute), IEC Comisión Electrónica Internacional (International
Electronical Commission), IEEE Instituto de Ingenieros Eléctricos y Electrónicos
(Institute of Electrical and Electronics Engineering), ISO Organización Internacional
para la Estandarización (International Organization for Standardization).

103
▪ Estándares de Facto: Se llama estándares de facto, a los estándares que nacen
a partir de productos de la industria que tienen un gran éxito en el mercado, o
bien a partir de desarrollos hechos por grupos de investigación de universidades
y que tienen una gran difusión. Estos productos o proyectos de investigación
llegan a tener un uso muy generalizado, convirtiéndose, por tanto, en estándares
de facto.

7.7 Estándares para el modelado de Sistemas

1) Lenguaje de Modelado Unificado (UML): El Lenguaje de Modelado Unificado
se ha convertido en el estándar de facto de la industria, debido a que ha sido
impulsado por los autores de los tres métodos más usados de orientación a
objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. En el proceso de
creación de UML han participado otras empresas de gran peso en la industria
como Microsoft, Hewlett-Packard, Oracle o IBM, así como grupos de analistas
y desarrolladores. Es un lenguaje de modelado visual que se usa para
especificar, visualizar, construir y documentar artefactos de un sistema de
software. Se usa para entender, diseñar, configurar, mantener y controlar la
información sobre los sistemas a construir.
Por medio de UML un sistema se modela como una colección de objetos
discretos que interactúan para realizar un trabajo que finalmente beneficia a un
usuario.
El lenguaje de modelado pretende unificar la experiencia pasada sobre
técnicas de modelado e incorporar las mejores prácticas actuales en un
acercamiento estándar. UML es tomado como estándar para el modelado de
sistemas de software principalmente, pero con posibilidades de ser aplicado a todo
tipo de proyectos.

2) Diagramas de UML: El UML esta compuesto por diversos elementos gráficos

que se combinan para conformar diagramas, existen reglas para combinar
tales elementos.

104
 La finalidad de los diagramas es presentar diversas perspectivas de un
sistema a las cuales se les conoce como modelo. En el modelo UML se describe
lo que se espera hará un sistema, pero no dice como será su implementación.

3) Tipos de Diagramas UML: Existen muchos diagramas UML entre los cuales
se encuentran:
▪ Diagrama de Casos de Uso: En este tipo de diagrama se presentan los
escenarios de uso del sistema, incluyendo los roles de los usuarios.
▪ Diagrama de Clases: Presenta las clases, junto con sus atributos, operaciones,
interfaces y relaciones. También presenta el agrupamiento de clases en paquetes
y las relaciones entre ellos.
▪ Diagrama de Objetos: Muestra instancias de clases (objetos) con valores en sus
atributos y relaciones.
▪ Diagrama de Estados: Representa los posibles estados, eventos y transiciones
entre las clases u objetos.
▪ Diagrama de Secuencias: El diagrama de secuencia forma parte del modelado
dinámico del sistema. Se modelan las llamadas entre clases desde un punto
concreto del sistema. Es útil para observar la vida de los objetos en sistema,
identificar llamadas a realizar o posibles errores del modelado estático, que
imposibiliten el flujo de información o de llamadas entre los componentes del
sistema.
▪ Diagrama de Componentes: Organización y dependencia entre componentes
físicos.

Existen muchas ventajas al implementar UML para el modelado de

sistemas, tales como: es un lenguaje visual de modelación centrado en objetos
que permite: especificar, construir y documentar software; permite la participación
de los usuarios; satisfacción de requerimientos;, adaptabilidad a cambios y
reutilización.

105
 7.8 Estándares de Calidad del Software
La calidad del Software se refiere a un conjunto de cualidades que lo
caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de
eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad,
usabilidad, seguridad e integridad.
La calidad del software es medible y varía de un sistema a otro o de un
programa a otro; esta medición se realiza después de elaborado el producto. Pero
esto puede resultar muy costoso si se detectan problemas derivados de
imperfecciones en el diseño, por lo que es imprescindible tener en cuenta tanto la
obtención de la calidad como su control durante todas las etapas del ciclo de vida
del software.

7.8.1 Especificación de Requerimientos del Sistema y Especificación de

Requerimientos de Software
Al desarrollar un Proyecto, se debe crear el SyRS: Especificación de
Requerimientos del sistema (System Requirements Specification) y el SRS:
Especificación de Requerimientos de Software (Software Requirements
Specification).
▪ Especificación de Requerimientos de Software (SRS): define de forma precisa el
producto de software que se va a construir. Las decisiones hechas escribiendo la
SRS están basados en información de los documentos de la propuesta del
proyecto y requerimientos del usuario. El conjunto de requerimientos de SRS
deben ser satisfechos en el diseño del sistema.
▪ Especificación de Requerimientos del Sistema (SyRS): El Sistema de
Especificación de Requerimientos (SyRS) es un documento que comunica los
requerimientos del cliente a la comunidad técnica que especificará y construirá el
sistema.
El objetivo del SyRS es proveer una descripción de lo que el sistema debe
hacer en términos de las interacciones e interfases del sistema con el exterior.
Permite organizar los requerimientos y la comunicación a dos audiencias por una
parte a la comunidad técnica involucrada en el proyecto para conocer y

106
comprender los requerimientos y por otra parte al cliente y usuarios del sistema,
para cerciorarse que efectivamente son esos y solo esos los requerimientos del
proyecto.

Actividades propuestas al estudiante

1. Explique con sus propias palabras cual es la importancia de utilizar estándares
en los proyectos.
2. Investigue acerca de los siguientes estándares:
Estándar std 830-1998.
Estándar IEEE/EIA 12207.1-1997
Estándar ISO/IEC 12207
3. Explique cual es según su criterio la vinculación que existe entre el Documento
de Requerimientos y los Estándares.
4. Establecer la importancia de la elaboración de estándares nacionales
relacionados con el Diseño de Software.
5. Investigue acerca de los Principales entes de Regulación Nacionales e
Internacionales.

107