c

DIRECTOR DE LA FCA
Mtro. Tomás Humberto Rubio Pérez

SECRETARIO GENERAL
Dr. Armando Tomé González

––––

COORDINACIÓN GENERAL
Mtra. Gabriela Montero Montiel
Jefa del Centro de Educación a Distancia y Gestión del
Conocimiento

COORDINACIÓN ACADÉMICA
Mtro. Francisco Hernández Mendoza
FCA-UNAM

COORDINACIÓN MULTIMEDIOS
L.A. Heber Javier Mendez Grajeda
FCA-UNAM

–––

AUTOR
Mtro. Rene Montesano Brand

REVISIÓN PEDAGÓGICA
Mayra Lilia Velasco Chacón

CORRECCIÓN DE ESTILO
Mtro. José Alfredo Escobar Mellado

DISEÑO DE PORTADAS
L.C.G. Ricardo Alberto Báez Caballero

DISEÑO EDITORIAL
L.D.yC.G. Griscell Ortiz Lezama
 .

Dr. Enrique Luis Graue Wiechers Mtro. Tomás Humberto Rubio Pérez
Rector Director

Dr. Leonardo Lomelí Vanegas Dr. Armando Tomé González

Secretario General Secretario General

Mtra. Gabriela Motero Montiel

Jefa del Centro de Educación a Distancia
y Gestión del Conocimiento
______________________________________________________
Informática II (Administración de requerimientos)
Apunte electrónico

Edición: noviembre 2018

D.R. © 2018 UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO

Ciudad Universitaria, Delegación Coyoacán, C.P. 04510, México, Ciudad de México.

Facultad de Contaduría y Administración

Circuito Exterior s/n, Ciudad Universitaria
Delegación Coyoacán, C.P. 04510, México, Ciudad de México.

ISBN: En trámite
Plan de estudios 2012, actualizado 2016.

“Prohibida la reproducción total o parcial por cualquier medio sin la autorización escrita del
titular de los derechos patrimoniales”

“Reservados todos los derechos bajo las normas internacionales. Se le otorga el acceso no exclusivo
y no transferible para leer el texto de esta edición electrónica en la pantalla. Puede ser reproducido
con fines no lucrativos, siempre y cuando no se mutile, se cite la fuente completa y su dirección
electrónica; de otra forma, se requiere la autorización escrita del titular de los derechos patrimoniales.”

Hecho en México
 OBJETIVO GENERAL
El alumno será capaz de identificar y especificar los requerimientos de los
involucrados en el desarrollo de un sistema de información a fin de orientar las
actividades de análisis y diseño de sistemas.

TEMARIO OFICIAL
(96 horas)

1. Introducción 16
2. Transmisión y comunicación de datos 24
3. Protocolos de comunicación 28
4. Valoración de la información en la organización 28

4 de 129
Segundo Semestre
 INTRODUCCIÓN

Esta asignatura aborda uno de los aspectos más significativos del ciclo de vida de
los sistemas de información que tiene lugar en la fase del análisis del sistema: la
gestión de requerimientos, la cual va desde la especificación y captura correctas de
estos requerimientos hasta su revisión, validación y control de cambios. Con esto,
tanto desarrolladores como clientes podrán establecer las características generales
que tendrá el sistema y sus funciones principales.

Una planificación clara y ordenada le permitirá al sistema cumplir satisfactoriamente

su objetivo: enfocar las acciones a producir lo que realmente se desea y sean
eficaces para la organización. Esto podrá realizarse a través de la especificación y
gestión de los requerimientos del sistema, cuya falta traería como consecuencia
problemas de funcionalidad en el sistema y de producción para la organización.

Con la información obtenida de la fase de recopilación, el desarrollador tendrá una

visión general del sistema que se pretende crear de acuerdo con las necesidades y
características del negocio. En esta etapa, es importante recalcar el contacto con
los usuarios finales del sistema, pues, a partir de sus necesidades, será posible
diseñar y conformar un sistema robusto y amigable que permita el cumplimiento de
sus actividades; incluso, con base en la información recabada, mejorarán los
procedimientos y métodos acostumbrados.

La fase de análisis de los requerimientos del sistema tiene el propósito de

proporcionar a los desarrolladores la información necesaria para determinar el
comportamiento general del sistema y sus funciones principales. De esta fase, se
obtiene información valiosa como las características de los equipos que operarán al

5 de 129
Segundo Semestre
sistema, tipo de estrategia de desarrollo (selección del modelo de desarrollo),
información a manejar, estructura general, etcétera.

La asignatura se distribuye en cuatro unidades, donde se ahondará de forma

específica el estudio de estas fases.

La unidad 1 (Introducción) proporcionará los fundamentos para crear un plan para

la administración de los requerimientos con base en su clasificación y el perfil de la
organización.

En la unidad 2 (Identificación de requerimientos), se definirán los métodos y

técnicas necesarios para identificar los requerimientos de un sistema de
información.

La unidad 3 (Especificación de requerimientos) ayudará a reconocer los

requerimientos funcionales y no funcionales que se obtuvieron de los métodos y
técnicas de identificación de requerimientos.

Por último, en la unidad 4 (Validación de requerimientos), se estudiará cómo,

recabada y analizada la información, se procede a verificar si los requerimientos
establecidos son acordes al perfil y necesidades de la organización.

6 de 129
Segundo Semestre
 ESTRUCTURA GENERAL

7 de 129
Segundo Semestre
 UNIDAD 1
INTRODUCCIÓN
 OBJETIVO PARTICULAR
El alumno desarrollará un plan para la administración de requerimientos tomando
como base los conceptos y clasificación de los requerimientos.

TEMARIO DETALLADO
(16 horas)

1. Introducción
1.1. Expectativas, necesidades, problemas y requerimientos
1.2. Definición de necesidades de negocio
1.3. Definición de requerimiento
1.4. Clasificaciones de requerimientos
1.5. Procesos para la administración de requerimientos
1.6. Planeación para administrar requerimientos
1.6.1. Plan de administración de requerimientos
1.6.2. Definición de atributos de los requerimientos

9 de 129
Segundo Semestre
 INTRODUCCIÓN

En el ámbito de desarrollo de sistemas de información, una de las fases más

importantes y de mayor impacto a lo largo de todo el ciclo de vida de los sistemas
comprende la especificación, redacción y administración de los requerimientos, los
cuales definen las características generales del sistema y cómo deberá
comportarse.

La administración de requerimientos es un proceso que debe comenzar con la

identificación de las necesidades de una organización y los problemas asociados a
ellas que, en un futuro próximo, la implementación de un sistema de información
habrá de cubrir y resolver.

Los requerimientos identificados serán especificados y redactados en un

documento que represente un acuerdo entre desarrolladores y clientes, que servirá
para su clasificación según su tipo y permitirá la implementación de un plan de
administración efectivo con el mínimo de errores de diseño y que facilite los cambios
en los requerimientos a lo largo del desarrollo del sistema.

10 de 129
Segundo Semestre
 1.1 Expectativas, necesidades,
problemas y requerimientos

El ciclo de vida de desarrollo de los sistemas informáticos está divido en ciertas

fases, donde se van realizando actividades específicas enlazadas todas ellas para
que el producto final sea el esperado. Para iniciar este proceso, es importante que,
en primera instancia, conozcas y diferencies algunos conceptos básicos.

De manera general, un problema es un conjunto de hechos

o circunstancias que dificultan la consecución de un fin.

Problemas En lo que toca a los sistemas de información, un usuario

puede identificar alguna situación que esté generando un
inconveniente en la organización (un problema) y hacerlo
del conocimiento de los demás desde su punto de vista; no
necesita proporcionar detalles al respecto ni mucho menos
dar soluciones.

Los sistemas son desarrollados para solucionar cierta

problemática dentro de la organización y ayudar así a la
agilización de los procesos internos de la organización; por
ejemplo, el manejo efectivo del inventario en un almacén o
el proceso de la información financiera de la organización.

11 de 129
Segundo Semestre
 Una expectativa es la esperanza de
realizar o conseguir algo.

En el caso de los sistemas de información,

es todo aquello que esperamos que el
sistema realice para facilitar las
actividades de la organización y la toma
Expectativas de decisiones.

Si las expectativas no se definen

claramente, se corre el riesgo de que no
se seleccionen las tecnologías apropiadas
o no funcionen como se desea; o si son
poco realistas, no se podrán identificar
ciertos riesgos o algunas oportunidades.

Una necesidad se define como la carencia o

falta de algo o alguien.

Desde el punto de vista de los sistemas de

información, son todas aquellas cosas y
personas que hacen falta para que el sistema
sea construido y puesto en marcha.
Necesidades
La identificación de las necesidades en una
organización es el primer paso del análisis de
un sistema; permite definir los faltantes y
diseñar un plan para el proyecto a desarrollar.
Normalmente, se realiza de forma grupal,
entre los desarrolladores y los responsables
del proyecto o de la institución.

12 de 129
Segundo Semestre
 Un requerimiento es la petición de una cosa que se
considera necesaria.

Todo aquello que es necesario para poder realizar una

tarea es un requerimiento. Por ejemplo, para preparar
una receta de cocina, se requieren ingredientes; para
escribir una carta, la hoja de papel con ciertas
características, etcétera.
Requerimiento
Los requerimientos de un sistema especifican qué
debe hacer éste y sus cualidades principales. Reflejan
las necesidades de los clientes y ayudan a resolver
algún problema.

Los requerimientos pueden ser de diversa naturaleza,

pero de manera general cuentan con ciertas
características únicas que ayudan a solventar una
necesidad específica.

Figura 1.1 Conceptos básicos del ciclo de vida de desarrollo de sistemas informáticos

Los cuatro conceptos anteriores se relacionan de tal forma que uno ayuda a definir
otro: a partir de la ubicación de un problema, se identifican carencias; éstas generan
expectativas y, para cuando sean solventadas, esas carencias se convertirán en
necesidades; finalmente, esas necesidades se vuelven requerimientos de las
herramientas o medios que ayudarán a su solución.

13 de 129
Segundo Semestre
 1.2. Definición
de necesidades de negocio

Cuando una empresa u organización decide poner a disposición de sus clientes un

producto o servicio, comienza un proceso conocido como negocio. El fin último de
cualquier empresa es generar utilidades, y para lograrlo es necesario que ofrezca
productos o servicios en un mercado interesado en ellos y, por ende, que se dé el
proceso de compra-venta de los productos o servicios ofertados.

A fin de que un producto o servicio nuevo tenga oportunidades de aceptación en un

mercado, lo más recomendable es elaborar previamente un documento formal, el
plan de negocios, que ayuda a la empresa a establecer el tipo de negocio que desea
realizar: venta de productos como lácteos, servicios de banca comercial, venta de
paquetes vacacionales, etcétera. A partir de la definición del tipo de negocio, se
definen los objetivos que la empresa persigue con ese negocio y las acciones que
deben realizarse para alcanzarlos.

Además, el plan de negocios es una guía que permite a la empresa identificar

aquellos aspectos que obstaculizan la realización del negocio, con el propósito de
implementar las acciones para solventarlos y tomar decisiones correctas. Asimismo,
ayuda a determinar si el negocio en cuestión es viable tanto económica como
financieramente, y aporta información importante relacionada con los recursos
humanos necesarios, estrategias para conseguir los objetivos planteados, el
mercado meta del negocio y todo el conjunto de actividades para poder efectuarlo
(parte operativa).

14 de 129
Segundo Semestre
Cuando se crea un plan de negocios, éste debe partir de una idea o iniciativa nacida
como respuesta a una necesidad de los clientes de la organización, la cual se
convierte en el objetivo fundamental del plan de negocios.

En un mercado encontramos personas que compran bienes o servicios para cubrir

sus necesidades básicas o específicas. Éstas, desde el punto de vista empresarial,
se vuelven oportunidades de negocio que las empresas buscan explotar para
satisfacerlas a cambio de una utilidad.

Existen diversos métodos que permiten satisfacer las necesidades de los clientes,
tan diferentes como los clientes mismos. En todo caso, estos métodos deben hacer
que las empresas respondan las siguientes preguntas:

 ¿En qué segmento de mercado estoy?

¿En qué segmento quiero estar?
¿A qué clientes quiero atender?
¿Con cuáles bienes o servicios?
 ¿Hacia cuál mercado me impulsan mi vocación y aptitudes?
¿Cómo va a crecer ese sector en los próximos años?
¿Qué estoy haciendo para ingresar en él?

Las preguntas anteriores llevan a la empresa a definir el curso de acción.

Precisamente, es en el plan de negocios donde se plantea de forma estratégica una
manera de trabajar razonada y bien fundamentada en la investigación del entorno
de la empresa.

Todo plan de negocios debe desarrollarse a partir de dos aspectos fundamentales:

la misión y visión de la empresa. La primera establece qué hace la organización y

15 de 129
Segundo Semestre
para qué tipo de cliente; la segunda muestra a dónde quiere llegar la organización
a largo plazo.

La misión es un enunciado que permite identificar, de forma general, qué hace la

empresa y para quién. Responde a las siguientes preguntas:

a. ¿Qué hacemos? (Oferta)

b. ¿Para quién lo hacemos? (Demanda)

c. ¿Por qué lo hacemos? (mercado)

Figura 1.2 Preguntas sobre la misión de un plan de negocios

Al definir una misión, la empresa establece una razón de ser y, por ende, puede
destinar sus recursos a sus actividades de modo más eficiente con el propósito de
cumplir con esa misión.

Ejemplos de la misión de diversas empresas:

“Refrescar al mundo en cuerpo, mente y espíritu.

Inspirar momentos de optimismo a través de nuestras marcas y acciones, para crear
valor y dejar nuestra huella en cada uno de los lugares en los que operamos.”

16 de 129
Segundo Semestre
”1. (Coca Cola Company, México).

“Proveer soluciones de calidad, a través de la iniciativa y respuesta de sus

integrantes, ofreciendo tecnologías de vanguardia y servicios de valor agregado
para asegurar la satisfacción de nuestros clientes”2. (Hewlett-Packard).

“Organizar la información del mundo y hacerla universalmente accesible y útil”3.

(Google).

Por otro lado, la visión de una empresa permite establecer un objetivo a largo plazo,
ya que contesta a la pregunta ¿dónde deseo estar?

1 Coca-Cola Company (2018). Párrafo 2º. Recuperado de: https://www.coca-

colamexico.com.mx/nuestra-compania/mision-vision-y-valores. 24/08/2018.
2Hewlett Packard, (s/a) Párrafo 1º. Recuperado de: http://hewlett-packard-
unaq.blogspot.com/p/analisis-del-entorno.html 24/08/2018.
3 Google (s/a). Párrafo 1º. Recuperado de: https://www.google.com/intl/es-419/about/our-company/
24/08/2018.

17 de 129
Segundo Semestre
 Ejemplos de visión4.

• Maximizar el retorno a los accionistas sin perder de vista la totalidad

 Utilidades: de nuestras responsabilidades.

• Ser un excelente lugar para trabajar, en donde nuestro personal se

Gente inspire para dar lo mejor de sí.

• Ofrecer al mundo una cartera de marcas de bebidas que se anticipan y

Cartera de
productos
satisfacen los deseos y las necesidades de las personas.

• Formar una red de socios exitosa y crear lealtad mutua.

Socios

• Ser un ciudadano global, responsable, que hace su aporte para un

 Planeta: mundo mejor”. (Coca Cola Company, México).

Figura 1.3 Ejemplos de visión

4 Coca-Cola Company (2018). Párrafo 8º. Recuperado de: https://www.coca-

colamexico.com.mx/nuestra-compania/mision-vision-y-valores. 24/08/2018.

18 de 129
Segundo Semestre
Otro ejemplo:

Visión:

Intel está superando los límites de la innovación para hacer que las vidas
de las personas sean más excitantes, más satisfactorias y más fáciles de
gestionar. Nuestra dedicación constante al avance de la tecnología ha
transformado el mundo a pasos agigantados.

Somos una empresa que siempre está en movimiento, alimentando a un

mercado que nunca descansa. Inspiramos a nuestros socios a que
desarrollen productos y servicios innovadores, agrupamos al mercado para
prestar asistencia a nuevos productos y promovemos estándares. Hacemos
todo esto para poder ofrecer colectivamente mejores soluciones con
mayores ventajas de forma más rápida5. (Intel).

El establecimiento correcto de la misión y visión en las empresas genera una guía

para sus acciones, ya que el objetivo principal es cumplir con su misión para
alcanzar su visión.

El plan de negocios facilita establecer los caminos para lograr los objetivos de la
empresa. Estos caminos, a su vez, ayudan a identificar los recursos con que se
cuenta y las carencias de la empresa, las cuales se convertirán en necesidades al
ser incorporadas a las estrategias que, a la postre, beneficiarán para que el negocio
sea exitoso.

5 Venezuelasite.com (1998-2018). Párrafo1º. Recuperado de:

https://www.venezuelasite.com/portal/Detalles/2561.html: 24/08/2018.

19 de 129
Segundo Semestre
 Figura 1.4 Misión y visión de una empresa

20 de 129
Segundo Semestre
 1.3. Definición de requerimiento
En el ámbito de los requerimientos, se manejan dos enfoques:

A. Dentro de la ingeniería de software, requerimientos son “declaraciones que

identifican atributos, capacidades, características y/o cualidades que necesita
cumplir un sistema (o un sistema de software) para que tenga valor y utilidad para
el usuario”6. Es decir, un requerimiento muestra todos los elementos necesarios
para la construcción del sistema.

B. Cuando nos referimos a software en general, un requerimiento es una serie de

elementos básicos indispensables para que las aplicaciones funcionen de manera
correcta, estos pueden ser cantidad de memoria, sistema operativo, tipo de
procesador, entre otros.

A fin de cuentas, los requerimientos indican lo que el sistema debe hacer, lo que el
cliente o usuario desea y espera que haga ese sistema, aunque en ese momento
no se indique el cómo.

La importancia de la definición de requerimientos se ve reflejada en el costo del

proyecto, sobre todo cuando corresponde reparar algún error u omisión en el
sistema que se pudo haber previsto.

6Alegsa (2018). Párrafo 2º. Recuperado de: http://www.alegsa.com.ar/Dic/requerimientos.php,

24/08/2018.

21 de 129
Segundo Semestre
 1.4. Clasificaciones de requerimientos

Requerimientos funcionales

Definen las capacidades que deberá tener el sistema a desarrollar describiendo los
procesos que llevan a la transformación de las entradas del sistema para obtener
las salidas deseadas (lo que el software debe o no hacer).

Requerimientos de datos o información

Requerimientos de interfaz (con el usuario)

Requerimientos de navegación.

Requerimientos de personalización.

Requerimientos transaccionales o funcionales internos.

Figura 1.5 Requerimientos funcionales

A su vez, los requerimientos funcionales se clasifican de la siguiente manera.

Requerimientos de datos o información. Hacen referencia al contenido o tipo de

información que manejará el sistema. Su objetivo es responder a qué información

22 de 129
Segundo Semestre
almacenará y administrará el sistema; por ejemplo, el sistema debe almacenar la
dirección completa de los trabajadores de la empresa.

Requerimientos de interfaz (con el usuario). Buscan determinar la forma como los

usuarios van a interactuarán con el sistema. El objetivo de definir los requerimientos
de interfaz es responder a cómo va a interactuar el usuario con el sistema; por
ejemplo, el sistema debe contener una pantalla donde los usuarios escriban su
nombre y contraseña para poder ingresar a su contenido.

Requerimientos de navegación. Están para determinar el modo como los usuarios

navegarán o se desplazarán dentro del sistema entre las diferentes secciones que
lo componen; por ejemplo, el sistema debe contener una pantalla de menú principal
que permita el acceso a los diversos módulos que conforman el sistema.

Requerimientos de personalización. Su propósito es describir cómo el sistema

deberá adaptarse a los diferentes tipos de usuario que interactuarán con él; por
ejemplo, los usuarios serán clasificados de acuerdo con su categoría dentro de la
empresa, y con base en esto podrán ingresar a todos los módulos del sistema o
solamente a algunos de ellos.

Requerimientos transaccionales o funcionales internos. Buscan definir la

funcionalidad interna del sistema, excluyendo los aspectos de interacción. Por
ejemplo, el sistema deberá generar un reporte de actividades de los usuarios
diariamente (se define el formato del reporte).

Requerimientos no funcionales

Definen las posibles causas o características que son limitantes del sistema, como
su rendimiento, disponibilidad de equipos, etcétera. Sommerville (2005: 125) indica

23 de 129
Segundo Semestre
que los requerimientos no funcionales, como su nombre sugiere, no se refieren
directamente a las funciones específicas proporcionadas por el sistema, sino que
están orientados más hacia las necesidades surgidas del usuario.

Para definir los requerimientos no funcionales, los desarrolladores se basan en el

estándar ISO/IEC 91267, ahora englobado en el proyecto SQuaRE para el desarrollo
de la norma ISO 25000, que define un modelo independiente de la tecnología para
caracterizar la calidad de software; considera las siguientes características:

 Funcionalidad. Define las características necesarias para alcanzar el

funcionamiento deseado del sistema, como la interoperabilidad con los
usuarios y la seguridad del sistema.

 Confiabilidad. Capacidad del sistema para mantener sus niveles de

rendimiento bajo ciertas condiciones específicas y en un tiempo de respuesta
dado. Por ejemplo, tolerancia a las fallas y la capacidad de recuperación del
sistema.

 Amabilidad (usabilidad). Describe el nivel de complejidad que puede

encontrar el usuario final para utilizar el sistema. Por ejemplo, curva de
aprendizaje, eficacia y eficiencia de los usuarios.

 Eficiencia. Características que definen la diferencia entre el rendimiento del

sistema y la cantidad de recursos que éste consume durante su
funcionamiento. Por ejemplo, cantidad de memoria RAM empleada, tiempo

7 González Pinzón Miguel Fernando (2013). Aplicación del estándar ISO/IEC 9126-3 en el modelo
de datos conceptual entidad-relación. Disponible en: http://www.scielo.org.co/scielo.ph
p?script=sci_arttext&pid=S0121-11292013000200010. 24/08/2018.

24 de 129
Segundo Semestre
 de respuesta, cantidad de procesos en el sistema operativo y recursos de red
empleados.

 Capacidad de mantenimiento. Capacidad del sistema para aceptar cambios

dentro de su estructura sin perder funcionalidad. Dentro de estos aspectos,
hallamos la estabilidad y validaciones de los diferentes módulos del sistema.

 Compatibilidad. Capacidad del sistema de ser instalado en diferentes

plataformas operativas sin presentar cambios en su funcionamiento. Por
ejemplo, adaptabilidad o capacidad de instalación.

 Portabilidad. Capacidad del software de ser transferido de un entorno a otro.

 Productividad. Capacidad del software de permitir a los usuarios gastar la

cantidad apropiada de recursos en relación con la efectividad obtenida.

 Seguridad. Capacidad del software para cumplir con los niveles de riesgo
permitidos para daños físicos y riesgos de datos.

 Satisfacción. Capacidad del software de cumplir con las expectativas de los

usuarios en un contexto determinado.

Los requerimientos no funcionales pueden catalogarse en tres categorías

principales:

Requerimiento del producto. Enfocados a las características que definen la forma

de comportarse del producto, en este caso el sistema de información. Entre ellos,
encontramos la rapidez del sistema, cantidad de memoria empleada, espacio de
almacenamiento en disco duro, etcétera.

25 de 129
Segundo Semestre
Requerimientos organizacionales. Se refieren principalmente a la observancia de
las políticas y procedimientos de la organización y los desarrolladores.

Requerimientos externos. Factores externos del sistema y del proceso de

desarrollo, como la interoperabilidad, es decir, la forma como el sistema
interactuaría con otros sistemas; o legislativos, vinculados con el acatamiento de las
leyes vigentes, como derechos de autor, propiedad intelectual, etcétera.

La siguiente figura muestra los tipos de requerimientos no funcionales, de acuerdo

con Ian Sommerville (2005: 126).

Figura 1.6 Tipos de requerimientos no funcionales

Procesos para la administración de requerimientos

26 de 129
Segundo Semestre
Cuando se desarrolla un nuevo sistema de información, la mala administración de
requerimientos es, en muchos casos, la causa principal de que no funcione
adecuadamente.

Dentro de los principales problemas debido a la mala administración de los

requerimientos, tenemos:

Dificultad para manejar

los cambios en los
requerimientos durante
el desarrollo del sistema.

Falta de detalle en los Mala definición de

requerimientos. requerimientos.

Falta de control de Mala organización de

requerimientos. requerimientos.

Figura 1.7 Problemas debido a la mala administración

La administración de requerimientos en el desarrollo de sistemas de información

está relacionada con diversas actividades que permiten realizar un levantamiento y
control adecuado de los requerimientos:

27 de 129
Segundo Semestre
 Definición de
Clasificación de Asignación requerimientos.
requerimientos. Consiste en
requerimientos. Se precisa Se determina en qué parte
identificar cada una de las
cuáles de los requerimientos del ciclo de desarrollo del
necesidades que tenga el
son de tipo funcional y no sistema debe entrar cada
negocio y definir cuáles son
funcional. requerimiento definido.
aplicables al sistema.

Control de requerimientos.
Seguimiento de
Se realizan acciones
requerimientos. Se realiza
enfocadas a minimizar los
un historial de la forma
impactos sufridos por
como se define cada
cambios en los
requerimiento, dónde se
requerimientos y en
usa y los cambios que sufre.
validarlos para su uso.

Figura 1.8 Requerimientos en el desarrollo de sistemas de información

Estas actividades comienzan durante la fase de análisis del sistema y continúan

durante todo su ciclo de vida. Su seguimiento correcto permite llevar un control y
monitoreo del proyecto adecuados y asegurar un producto de calidad.

El proceso de administración de requerimientos de RUP (rational unified process)

reúne varias de las mejores prácticas sobre desarrollo de software, por lo que sus
procesos son aplicables a un rango amplio de proyectos de software.

RUP es un proceso de desarrollo de software que, junto con el lenguaje unificado

de modelado (UML), constituye la metodología estándar más utilizada para el
análisis, implementación y documentación de sistemas de información, empleado
principalmente bajo el paradigma de programación orientada a objetos, pues ayuda
a definir con eficiencia los atributos y características de cada elemento que
conformará a los objetos y clases del sistema.

28 de 129
Segundo Semestre
El proceso de administración de requerimientos consiste en definir, organizar y
documentar las especificaciones funcionales del sistema, así como sus limitantes y
restricciones. Adicionalmente, da seguimiento y documenta las decisiones y
alternativas tomadas durante el desarrollo del sistema; también permite la captura
y comunicación de los requerimientos del negocio. El empleo de RUP en la
administración de requerimientos establece el uso de “casos de uso” y “escenarios”
para la captura de los requerimientos funcionales del sistema (temas que
abordaremos con más detalle en la unidad 3).

Los requerimientos del sistema son esenciales en el desarrollo del proyecto. Definen
a la perfección el modo como debe comportarse el sistema; por eso los usuarios
finales aceptarán y comprenderán todos los requerimientos que sean especificados.

Objetivos del proceso de administración de requerimientos:

Establecer un acuerdo
entre los clientes y Proporcionar un
usuarios involucrados mejor entendimiento
sobre lo que el de los requerimientos
sistema podrá hacer. a los desarrolladores.

Definir el ámbito del

sistema.

Definir una interfaz de Planear los contenidos

usuario acorde con sus técnicos de las
necesidades y metas. iteraciones.

Figura 1.9 Objetivos del proceso

29 de 129
Segundo Semestre
La identificación de los requerimientos es un proceso que demanda entrevistar a
todos los involucrados en el sistema, desde los clientes, desarrolladores, hasta los
usuarios finales. Consiste en anotar todas las peticiones y, a partir de ellas,
determinar las necesidades del proyecto y expresarlas como un requerimiento.

Uno de los factores de riesgo a lo largo de todo el desarrollo del sistema está en los
cambios; generalmente, se presenta desde el inicio hasta fases posteriores a la
puesta en marcha, donde se puede solicitar un cambio durante la etapa de
mantenimiento. La administración de los cambios adecuada y la configuración en
un proyecto de software son importantes debido a que los cambios impactan
directamente en los requerimientos: es necesario considerar su importancia, evaluar
su costo y determinar si es posible implementarlos.

Actividades del proceso de administración de requerimientos de RUP:

Definir la visión y Definir los

Analizar el problema. características del requerimientos de
producto. software.

Administrar el alcance del proyecto

(mantener la rastreabilidad de los Establecer un acuerdo y
requerimientos, la administración compromiso para el
de cambios y el análisis de su desarrollo.
impacto).

Figura 1.10 Actividades del proceso de administración de requerimientos de RUP

30 de 129
Segundo Semestre
En el análisis del problema, se busca comprender de mejor manera la problemática
y necesidades de los clientes, proponer una solución de alto nivel y establecer sus
límites.

En lo que se refiere a entender las necesidades de los clientes, se determinarán las

fuentes de información adecuadas que serán empleadas y la forma de obtener dicha
información. Además, cuando se desarrollan sistemas de información, es deseable
que, en las fuentes de información, se incluyan personas con experiencia dentro de
la organización y que, de una u otra forma, vayan a tener contacto con el sistema
(por ejemplo, el personal del área en donde se planea instalar el sistema),
inversionistas, directivos de la empresa, etcétera.

Existen múltiples técnicas que permiten obtener la información necesaria para

identificar las necesidades de nuestros clientes, como cuestionarios, entrevistas,
prototipos conceptuales, etcétera. El resultado de aplicar estas técnicas es la
generación de una lista de peticiones o necesidades que pueden ser descritas de
forma gráfica o textual, las cuales, al ser priorizadas, se convertirán en requisitos
del sistema.

La etapa de definición de las características del producto o del sistema consiste,

principalmente, en determinar a los actores que intervendrán en los casos de uso
que ayudarán en la definición de los requerimientos no funcionales del sistema. En
esta etapa, se recomienda realizar algunos prototipos conceptuales y modelos
según las peticiones de los clientes (recabadas en la etapa de análisis del
problema). El resultado generado en esta etapa es una descripción del
funcionamiento del sistema en forma gráfica y lenguaje natural.

31 de 129
Segundo Semestre
Con lo reunido en las etapas anteriores, será posible generar una visión común de
las características del sistema para los clientes y desarrolladores que permitirá
establecer acuerdos en lo referente a recursos y tiempos para su desarrollo.

El alcance del sistema se define a partir del conjunto de requerimientos obtenidos

en las etapas anteriores. La clave de esta etapa está concentrada en el
cumplimiento de los tiempos asignados para el sistema y la correcta administración
de los recursos destinados para ello. La definición de atributos de los requerimientos
como prioridad, esfuerzo y riesgo son técnicas útiles que permiten manejar el
alcance del proyecto de manera más eficiente.

Pasadas las etapas anteriores, será posible perfeccionar la definición de las

características del sistema. Esta definición estará detallada de tal manera que los
clientes puedan entenderla, lo que facilitará alcanzar acuerdos más fácilmente. La
definición perfeccionada comprende el cumplimiento de los requerimientos
funcionales y los de carácter legal o regulatorio, de usabilidad, fiabilidad,
rendimiento, soporte y mantenimiento. Es importante considerar que la redacción
de cualquier documento para definir las características del sistema y que será
presentado al cliente debe hacerse en forma simple, evitando el uso de terminología
técnica, a fin de que el cliente entienda claramente lo que se está proponiendo, y
con ello evitar errores en los datos de entrada del sistema. Para lograr lo anterior,
se recomienda emplear casos de uso en combinación de prototipos visuales que
ayuden a mostrar el funcionamiento del sistema y sus características, y a definir los
requerimientos con mayor claridad.

La etapa final en la administración de requerimientos es la administración de sus

cambios. A lo largo del desarrollo del sistema, pueden existir cambios en algunos
requerimientos, lo que posiblemente tenga impacto en uno o más requerimientos
asociados a éste. Para minimizar tales impactos, debemos asegurar que, al definir

32 de 129
Segundo Semestre
los requerimientos del sistema, éstos posean una estructura resistente a los
cambios, y emplear ligas que relacionen cada requerimiento con cada fase del ciclo
de desarrollo del sistema.

La administración del cambio incluye actividades como el establecimiento de una

línea base de trabajo, determinación de dependencias entre módulos y
requerimientos, trazabilidad entre objetos interconectados y control de cambios.

33 de 129
Segundo Semestre
 1.6. Planeación para
administrar requerimientos

1.6.1. Plan de administración de requerimientos

Establecer una administración de requerimientos correcta es indispensable para

poder desarrollar un sistema de información de forma eficiente y libre de errores. Un
plan de administración de requerimientos tiene que realizar las siguientes funciones:

Identificar los Por cada uno de

tipos de los
documentos (cada requerimientos Realizar una
Identificar los tipo de formales, matriz de
requerimientos documento identificar trazabilidad para
formales (no los maneja de forma atributos: saber cómo
documentos). predeterminada Prioridad rastrear los
un tipo de cambios.
requerimiento Riesgo
formal). Dificultad

Figura 1.11 Funciones para un plan de administración de requerimientos

El primer punto se enfoca al uso de diversas técnicas y herramientas que permitan

a los desarrolladores identificar y establecer los requerimientos del sistema. Por

34 de 129
Segundo Semestre
 ejemplo, entrevistas, cuestionarios, casos de uso, diagramas de flujo de datos,
etcétera. (En la unidad 2, se estudiarán con detalle algunas de estas técnicas).

La identificación del tipo de documento se refiere al documento que estará asociado

a cada requerimiento definido. De manera estandarizada, se emplea una plantilla
de documento bajo la norma IEEE-STD-830-1998,8 denominada especificación de
requerimientos del software (software requirements specification, SRS). Este
documento sirve a los desarrolladores para facilitar la comunicación entre ellos y los
clientes. Es decir, funciona como un contrato legal entre desarrolladores y clientes,
para realizar las estimaciones del proyecto en costos, tiempo y magnitud, como
herramienta de evaluación del sistema ya terminado y para tener una base para
controlar los cambios.

En lo que respecta a la trazabilidad, el documento SRS permite contar con una

fuente de información base que posibilita trazar los cambios.

Características del documento SRS:

Debe identificar las fuentes de los objetivos, requerimientos y

presunciones.

Debe relacionar requerimientos y presunciones con los

objetivos.

Debe facilitar referenciar requerimientos en documentación

futura (diseño, test, casos de test).

Figura 1.12 Características del documento SRS

8 (sin autor), (s/a). IEEE-STD-830-1998: Especificaciones de los requisitos del software. Disponible
en: http://blog.masterinprojectmanagement.net/gestion-de-requerimientos-vi-establecer-un-plan-de-
la-gestion-de-requisitos/ Recuperado: 22/08/2018.

35 de 129
Segundo Semestre
Un plan de administración de requerimientos ayuda a responder las siguientes
preguntas:

 ¿Cómo deben usarse las herramientas de gestión de

requerimientos?
 ¿Qué tipos de requerimientos serán trazados en el proyecto?
 ¿Cuáles son los atributos de estos requerimientos?
 ¿Dónde se crearán los requerimientos?, ¿en una base de datos o
sólo en documentos?
 ¿En qué requerimientos necesitamos implementar trazabilidad?
 ¿Qué documentos se requieren?
 ¿Qué requerimientos y documentos serán utilizados como contrato
con un proveedor?
 ¿Qué metodología será utilizada?
 ¿El cliente necesita algún documento específico para cumplir con
su proceso de desarrollo?
 ¿Cómo se implementará la gestión de cambios?
 ¿Qué proceso garantizará que todos los requerimientos serán
implementados y comprobados?
 ¿Qué requerimientos u opiniones necesitamos para generar
informes? (Ibáñez, 2009) 9

9 Ibañez, J. (2009) Gestión de requerimientos VI: establecer un plan de la gestión de requisitos

Disponible en: http://blogs.salleurl.edu/project-management/gestion-de-requerimientos-vi-
establecer-un-plan-de-la-gestion-de-requisitos/ Recuperado: 22/08/2018.

36 de 129
Segundo Semestre
1.6.2. Definición de atributos de los requerimientos

Como se mencionó en el punto anterior, definir los atributos de los requerimientos

es fundamental en el plan de administración de requerimientos.

Algunos atributos que pueden identificarse al definir los requerimientos de un

sistema de información:

 Disponibilidad. Tiempo en el que el sistema se encuentra trabajando.

 Integridad conceptual. Consistencia del sistema: diseño de sus componentes

y módulos (su codificación), y la definición y uso de variables.

 Flexibilidad. Capacidad del sistema para adaptarse a los cambios de

ambiente, políticas y reglas del negocio.

 Interoperabilidad. Capacidad del sistema para interactuar con componentes

de otros sistemas para intercambiar información de forma correcta.

 Capacidad de mantenimiento. Capacidad de los componentes del sistema

para permitir cambios en sus características cuando se realiza una
actualización del sistema, se cambian algunas funciones o se registran
modificaciones en los requerimientos.

 Capacidad de administración. Facilidad de administración del sistema. Por lo

general, este atributo emplea herramientas que facilitan el monitoreo para el
mejoramiento de su rendimiento y detectar errores.

37 de 129
Segundo Semestre
  Rendimiento. Permite medir la capacidad de respuesta del sistema al
ejecutar algunas acciones en un tiempo determinado.

 Confiabilidad. Hace que se mantenga el sistema operacional todo el tiempo.

Por lo regular, se mide a través de la probabilidad de que el sistema ejecute
las funciones para las que fue diseñado.

 Escalabilidad. Permite al sistema soportar cambios en su funcionamiento al

instalar nuevas funciones o al aumentar su carga de trabajo.

 Seguridad. Permite al sistema estar protegido contra la pérdida de

información y garantizar su funcionamiento.

 Riesgo. Define qué tan vulnerable es un requisito o qué tan difícil será su uso.

 Prioridad. Determina el nivel de importancia de cada requerimiento.

38 de 129
Segundo Semestre
 RESUMEN

La administración de requerimientos es una de las actividades más importantes

dentro del ciclo de vida de los sistemas de información. Involucra a desarrolladores,
clientes y usuarios.

La administración de requerimientos conjuga una serie de actividades que

comienzan con la detección de las necesidades del negocio; esto se logra a través
del establecimiento de un plan de negocios, principalmente de planeación
estratégica. Asimismo, permite identificar los recursos y carencias de la
organización que ayudarán a determinar las características que se desean
incorporar al sistema, y establecer las necesidades que, a la postre, definirán a los
requerimientos del sistema.

Dentro del proceso de administración, es importante clasificar los requerimientos

dividiendo los funcionales y los no funcionales, para priorizarlos y establecer con
ellos las características del sistema y definirlo.

En la definición del sistema, es indispensable documentar los requerimientos,

preferentemente bajo un documento estandarizado como la norma IEE-STD 830-
1998, Especificación de Requerimientos del Software (SRS), donde se describe a
detalle cada uno de ellos y sus atributos. Este documento sirve como base para el
control de cambios, pues dentro de cada documento se especifican las asociaciones
de cada requerimiento con los diversos módulos del sistema o con otros requisitos,
lo que facilitará el rastreo e impacto de los cambios solicitados y realizados.

39 de 129
Segundo Semestre
 BIBLIOGRAFÍA

Sugerida

Bruegge, B. y Dutoit Allen, H. (2002). Ingeniería de software orientada a objetos.

México: Pearson.
Joyanes Aguilar, L. (2003). Fundamentos de programación: algoritmos, estructuras
de datos y objetos (3.ª ed.). Madrid / México: McGraw-Hill.
Pfleeger, S. L. (2002). Ingeniería de software: teoría y práctica. México: Prentice
Hall.
Piattini Velthuis, M. y García, F. (Coord.). (2003). Calidad en el desarrollo y
mantenimiento de software. México: Alfaomega / Ra-Ma.
Piattini Velthuis, M., Calvo-Manzano Villalón, J., Cervera Bravo, J. y Fernández
Sanz, L. (2003). Análisis y diseño de aplicaciones informáticas de gestión.
México: Alfaomega / Ra-Ma.
Pressman Roger, S. (2002). Ingeniería de software: un enfoque práctico (5.ª ed.).
México / Madrid: McGraw-Hill.
Sommerville, I. (2001). Ingeniería de software (6.ª ed.). México: Pearson.
Weitzenfield, A. (2003). Ingeniería de software orientada a objetos con UML, Java
e Internet. México: Thomson.

40 de 129
Segundo Semestre
 UNIDAD 2
IDENTIFICACIÓN
DE REQUERIMIENTOS
 OBJETIVO ESPECÍFICO
El alumno seleccionará y aplicará los métodos y las técnicas más apropiadas para
identificar los requerimientos para la construcción de un sistema.

TEMARIO DETALLADO
(24 horas)

2. Administración de requerimientos
2.1. Métodos y técnicas estructurados para la identificación de
requerimientos
2.1.1. Entrevista
2.1.2. Cuestionario
2.1.3. Método Delphi
2.1.4. Desarrollo conjunto de aplicaciones
2.1.5. Diagrama causa-efecto de Ishikawa
2.2. Métodos y técnicas no estructurados para la identificación de
requerimientos
2.2.1. Observación
2.2.2. Revisión de documentos de la organización

Página 42 de 129
Segundo Semestre
 INTRODUCCIÓN

La etapa de análisis es fundamental para el buen desarrollo de cualquier sistema

de software. En este momento, se recaba toda la información necesaria para la
construcción del sistema, partiendo de los requisitos mínimos para su
funcionamiento, hasta la determinación de todas las variables que pueden afectar
su funcionalidad y limitar su rendimiento.

Para evitar omisiones en la recopilación de datos y asegurar mayor fiabilidad de los

mismos, conviene contar con personal de experiencia en el análisis y selección de
requerimientos.

En esta unidad, se revisarán algunas técnicas de recolección de información que

ayudan a los desarrolladores de software a identificar los requerimientos de los
sistemas de información.

Página 43 de 129
Segundo Semestre
 2.1. Métodos y técnicas estructurados
para la identificación
de requerimientos

Como se estudió en la unidad 1, un requerimiento manifiesta las características

solicitadas por los clientes que debe tener un sistema para atender y resolver algún
problema en particular, y se define a partir del análisis de las necesidades que se
haga del sistema deseado. Ahora bien, a fin de especificar las acciones para la
construcción del sistema, es importante que el analista distinga los tipos de
requerimientos que precisa, tanto funcionales como no funcionales, pues ello dará
pauta para establecer su funcionalidad y limitantes.

Una forma de identificar los requerimientos funcionales y no funcionales de un

sistema es mediante métodos de recopilación de información, que pueden ser
aplicados a los clientes y usuarios del sistema (fuente primaria de información).
Existen diferentes métodos que permiten obtener información amplia y exacta para
la construcción de los sistemas; por ejemplo, los estructurados y los no
estructurados.

Dentro del ciclo de desarrollo de un sistema, los métodos estructurados para la

identificación de requerimientos permiten a los desarrolladores conceptualizar un
modelo inicial del sistema que se pretende construir. Estos métodos fueron creados
en la década de 1970 y han ayudado a dar soporte a las etapas de análisis y diseño
de software.

Por lo regular, los métodos estructurados definen un proceso que puede ser
empleado para la generación de modelos de sistemas, proporcionando un marco
detallado de información para el análisis de requerimientos.

Página 44 de 129
Segundo Semestre
Contrario a los no estructurados, los métodos estructurados parten de un estándar
para su elaboración. Entre éstos, hallamos el método Delphi y los diagramas causa-
efecto de Ishikawa, los cuales ayudan a la identificación de los requerimientos
mediante una serie de acciones definidas dentro de cada uno.

A pesar de su utilidad, los métodos estructurados tienen una serie de desventajas:

2. No discriminan,
1. No
ya que no incluyen 3. A menudo 4. Los modelos
proporcionan un
guías que ayuden a generan producidos suelen
soporte efectivo
los usuarios de documentación ser muy detallados
para la
estos métodos a excesiva que y difíciles de
comprensión o el
decidir si un puede causar que comprender para
modelado de
método es el requerimiento el usuario.
requerimientos no
adecuado para un en sí pierda su (Sommerville,
funcionales del
problema objetividad. 2001: 170)
sistema.
concreto.

Figura 2.1 Serie de desventajas de los métodos estructurados

En la práctica, los desarrolladores e ingenieros no están restringidos a un método

en particular y pueden emplear varios de ellos, según sus necesidades.

Entre las técnicas comúnmente empleadas para recabar información de forma

estructurada, están los cuestionarios, entrevistas, JAD (desarrollo conjunto de

Página 45 de 129
Segundo Semestre
aplicaciones) y diagramas de causa-efecto, que permiten detectar ideas,
necesidades, preferencias, hábitos, problemas, causas, entre otros.

Página 46 de 129
Segundo Semestre
2.1.1. Entrevista

Centradas en la persona y su trabajo, las entrevistas son una técnica general y

sencilla de recabar información directa de personas o grupos. Es común que los
entrevistados formen parte del grupo de usuarios del sistema a desarrollar.

Debido a que las entrevistas son laboriosas y lleva tiempo su aplicación, no son el
método más empleado entre los diseñadores, pero sí una forma muy confiable de
recopilación de información, ya que es de individuo a individuo, lo que da pauta para
identificar reacciones corporales y tonos de voz.

Las entrevistas pueden clasificarse en estructuradas o dirigidas y no estructuradas

o no dirigidas. Estas últimas utilizan un formato pregunta-respuesta y son
apropiadas cuando el analista desea adquirir información general del sistema. Este
formato anima a los entrevistados a compartir sus sentimientos, ideas y creencias.

En cuanto a las entrevistas estructuradas, recurren a preguntas estándar en un

formato de respuesta abierta o cerrada. El primer formato permite que el
entrevistado responda las preguntas con sus propias palabras; el segundo, de
respuesta cerrada, se basa en un conjunto anticipado de respuestas. Cada enfoque
tiene sus ventajas y desventajas en la práctica, suelen manejarse las dos
modalidades a la vez.10

10 Build a free website of your own on TRIPOD (s/a), Título 11 Recuperado de: http://une-
senn.tripod.com/new_page_1.htm#Herramientas_para_determinar_requerimientos_de_sistemas 22/08/2018.

Página 47 de 129
Segundo Semestre
Pasos para preparar una entrevista:

Estudio del dominio del Selección de los Establecimiento de objetivos

problema o tema entrevistados. y contenido de la entrevista

Figura 2.2 Pasos para preparar una entrevista

1. Estudio del dominio del problema o tema. Es necesario que el entrevistador

estudie la temática a tratar. Para ello, es posible que consulte documentos de
proyectos o situaciones similares; también es recomendable que revise los
perfiles de los usuarios para abordarlos de mejor manera y ajustar las preguntas
de acuerdo con su categoría.

2. Selección de los entrevistados. Se deben evitar entrevistas que generen mucha

información y redundante, por lo que es recomendable limitar el número de
entrevistas y seleccionar un grupo representativo de cada tipo de usuarios. Se
sugiere comenzar con los directivos de las organizaciones para poder
establecer una visión general de lo que se desea en el sistema.

3. Establecimiento de objetivos y contenido de la entrevista. El entrevistador

establecerá los objetivos de cada entrevista y determinará su contenido. Se
aconseja, además, que envíe previamente un documento introductorio del
proyecto y un cuestionario a los candidatos que podrían ser entrevistados, para
que lo respondan y devuelvan; así, recopilará información de utilidad para la
entrevista.

Página 48 de 129
Segundo Semestre
Una entrevista se desarrolla en tres etapas principales:

1. Apertura. El entrevistador se presenta e informa al entrevistado sobre el

objetivo de la entrevista, lo que se pretende conseguir, el uso que se le dará
a la información, etcétera.

2. Desarrollo. Lo deseable es que la entrevista se desarrolle dentro de un tiempo

no mayor a dos horas, dándole 80% de tiempo como máximo al entrevistado
y 20% al entrevistador.

Es recomendable que el entrevistador tenga control completo sobre el

proceso para evitar caer en monólogos, y considere la intervención de una
tercera persona para la documentación de la entrevista. Dentro de esta
etapa, se sugiere lo siguiente:

Emplear preguntas abiertas.

Permite al entrevistado Utilizar un lenguaje apropiado.
expresarse libremente, sin Es deseable que las preguntas
restricciones. Ejemplos: ¿Cuál estén elaboradas en un
es el proceso de registro una lenguaje simple, libre de
compra? ¿Cómo doy tecnicismos que no pueda
seguimiento a un pedido de los entender el entrevistado.
clientes?

Mostrar interés en todo

momento. Se debe cuidar el
lenguaje corporal, tono de voz,
expresiones faciales, etcétera.

Página 49 de 129
Segundo Semestre
 Figura 2.3 Sugerencias para el entrevistador

3. Cierre. Resulta de gran ayuda recapitular los conceptos abordados en la

entrevista con el objetivo de que la información recabada esté libre de
errores, agradecer al entrevistado y dejar abierta la posibilidad de realizar
futuras entrevistas.

Realizada la entrevista, se procede a su análisis. Para ello, es necesario leer las

notas obtenidas, pasar en limpio la información, revisarla y contrastarla con otras
fuentes. Es recomendable que sea enviado el reporte en limpio al entrevistado para
que lo corroborare (Durán, 2000: 20-22).

Con la información reunida, se identifican los diferentes tipos de requerimientos y

se puede comenzar a elaborar el documento de especificación de requerimientos
(SRS).

Las entrevistas son la metodología más usual en el desarrollo de sistemas: a través

de ellas, suele iniciarse el contacto con todas las partes involucradas en el proyecto.

Página 50 de 129
Segundo Semestre
2.1.2. Cuestionario

El uso de cuestionarios permite a los analistas reunir información relacionada con

varios aspectos de un sistema de un grupo grande de personas. Aplicable tanto a
los clientes como a los usuarios finales, sirve como método de obtención de
información directo.

Los formatos estandarizados para las preguntas facilitan recoger datos más
confiables que otras técnicas. Por otra parte, su amplia distribución asegura el
anonimato de los encuestados, lo que puede conducir a respuestas más honestas.
Sin embargo, este método no permite al analista observar las excepciones o
reacciones de los encuestados. Asimismo, la respuesta puede ser limitada, ya que
es posible que no tenga mucha importancia para los encuestados llenar el
cuestionario. (Véase: cuestionarios)11

El cuestionario tiene ciertas características básicas (véase Osorio Rojas, El

cuestionario12, 2002):

 Es un procedimiento de investigación.
 Es una entrevista altamente estructurada.
 Un cuestionario consiste en un conjunto de preguntas respecto a una o más
variables a medir.

11 Build a free website of your own on TRIPOD (s/a), Título 11 Recuperado de: http://une-
senn.tripod.com/new_page_1.htm#Herramientas_para_determinar_requerimientos_de_sistemas
22/08/2018.
12 Osorio Rojas Ricardo Arturo (s/a) “El cuestionario” Recuperado de:
https://www.nodo50.org/sindpitagoras/Likert.htm 22/08/2018.

Página 51 de 129
Segundo Semestre
  Presenta la ventaja de requerir relativamente poco tiempo para reunir
información sobre grupos numerosos.
 El sujeto que responde proporciona por escrito información sobre sí mismo o
cualquier tema dado.
 Una desventaja es que quien conteste esconda la verdad o la altere. Además,
la uniformidad de los resultados podría ser aparente, una misma palabra ser
interpretada en forma diferente por personas distintas, o comprensible para
algunas y no para otras. Por otro lado, las respuestas pueden ser poco claras
o incompletas, haciendo muy difícil la tabulación.

Existen diversos tipos de cuestionarios. El primero, tal vez el más simple de generar,
es el restringido o cerrado. Éste se caracteriza por contener preguntas específicas
y delimitadas que anticipan la respuesta; en algunos casos, pueden reducirse a
respuestas como “sí” o “no”, “verdadero o falso”, donde se tienen preguntas con
varias opciones de respuestas y el encuestado selecciona una o varias opciones.
La ventaja de este tipo de cuestionarios radica en la facilidad de evaluar las
respuestas y su objetividad; difícilmente se sale del tema en cuestión.

Otro tipo de cuestionario es el abierto, donde las preguntas se formulan de manera

más natural, dejando que el encuestado exprese abiertamente sus ideas y con
mayor profundidad; es útil cuando se busca recabar información de algún tema poco
conocido. Su desventaja es que las respuestas requieren más tiempo de análisis
para su tabulación, resumen e interpretación.

Hay cuestionarios que combinan los tipos anteriores, y se aplican según el objetivo
que se persiga al formularlos.

Algunos criterios para elaborar un buen cuestionario:

Página 52 de 129
Segundo Semestre
  Hacer una lista de aspectos (variables) que se consideran importantes
de incluir.
 Determinar el propósito del cuestionario. Se refiere a un tema
significativo.
 Señalar el título del proyecto, del aspecto o tema a que se refiere, y una
breve indicación de su contenido. Las instrucciones deben ser claras y
completas.
 Especificar algunos datos generales: institución, fecha, nombre del
encuestador, etcétera.
 Establecer la mejor secuencia de dichos aspectos o temas.
 Los términos importantes deben estar definidos.
 El cuestionario no ha de ser demasiado largo.
 No es conveniente iniciar el cuestionario con preguntas difíciles o muy
directas.
 Escribir un esquema de posibles preguntas pensando lo que se pretende
averiguar con cada una de ellas, procediendo posteriormente, si es
necesario, a su reubicación, modificación o eliminación. Cada pregunta
implica una sola idea. Las preguntas deben ser objetivas, es decir, sin
sugerencias hacia lo que se desea como respuesta.

En relación con este punto, es conveniente plantear las siguientes

interrogantes:

o ¿Es necesario o útil hacer esta pregunta?

o ¿Es demasiado general?
o ¿Es excesivamente detallada?
o ¿La pregunta debería ser subdividida en otras preguntas más
pequeñas y ser más concreta, específica?
o ¿La pregunta se refiere preferentemente a un solo aspecto?
o ¿Se refiere a un tema sobre el cual las personas encuestadas poseen
la información necesaria?
o ¿Es posible contestarla sin cometer errores?
o ¿Son suficientemente simples las palabras como para ser
comprendidas por el encuestado?
o ¿La estructura de la frase es fácil y breve?
o ¿Las instrucciones son claras y precisas?
o ¿Es necesario clarificarla con alguna ilustración?
o ¿Es posible que tal pregunta incomode al encuestado?

Página 53 de 129
Segundo Semestre
 o ¿La pregunta induce la respuesta? "Las preguntas no pueden
apoyarse en instituciones, ideas respaldadas socialmente ni en
evidencia comprobada"13.

Como ya se mencionó en el tema de la entrevista, los cuestionarios pueden ser de

ayuda para su preparación o recabar información de un gran número de usuarios
que lleve a identificar requerimientos desde su punto de vista. En este caso, al igual
que en la entrevista, es necesario resumir y pasar en limpio la información para
analizarla de modo eficiente.

2.1.3. Método Delphi

El método Delphi es un método estructurado de comunicación grupal que posibilita

a un grupo de individuos (generalmente especialistas en el tema) analizar y resolver
un problema complejo.

Características principales de este método:

13 Osorio Rojas, Ricardo Arturo. (s/a) “El cuestionario”. Recuperado de:

https://www.nodo50.org/sindpitagoras/Likert.htm. 24/08/18

Página 54 de 129
Segundo Semestre
 Anonimato de los participantes

Retroalimentación controlada

Respuesta estadística grupal

Figura 2.4 Características principales del método Delphi

En esencia, este método consiste en recabar las opiniones de todos los

participantes del grupo sobre la problemática en cuestión. El anonimato ayuda a
que las opiniones no sean sesgadas y se consideren diversos puntos de vista que
ayuden a enriquecer el conocimiento organizacional, y a resolver el problema de
forma efectiva. El método se repite cuantas veces sea necesario hasta encontrar
una solución adecuada.

Cuando se emplea la metodología Delphi, se utiliza la siguiente terminología.

Circulación Sucesión de cuestionarios que se aplican a los

integrantes del grupo.
Cuestionario Documentos que se hacen llegar a los integrantes del
grupo. Los cuestionarios no sólo contienen una serie de
preguntas como los tradicionales, sino que en Delphi se
usan como herramientas de interacción entre los
participantes, ya que en ellos se presentan los
resultados de las circulaciones realizadas.

Página 55 de 129
Segundo Semestre
 Panel Conjunto de participantes en el grupo de trabajo. Se
recomienda que los integrantes sean expertos en el
tema.
Moderador Persona encargada de regular las interacciones del
grupo. Prepara los cuestionarios, recoge las respuestas
de cada circulación y realiza las circulaciones.

Antes de emplear la metodología Delphi, se recomienda:

1. Delimitar el contexto y establecer los tiempos de duración de cada circulación.

2. Realizar la selección del panel o grupo, procurando que sean expertos en el
área donde se presenta la problemática. Es recomendable que los expertos
establezcan un compromiso con el trabajo y procuren dar respuestas
universales para evitar el sesgo en la información que se pretende obtener.
3. Explicar la metodología de trabajo Delphi y sus objetivos a los participantes,
para que se preparen adecuadamente y expongan previsiones fiables.

La metodología Delphi considera cuatro circulaciones como base para poder

alcanzar un resultado en consenso. Si no se logra lo anterior, se procede a realizar
más circulaciones.

Las cuatro circulaciones de Delphi iniciales se describen a continuación.

Página 56 de 129
Segundo Semestre
 Se genera un cuestionario sin estructura (más
abierto) con el objetivo de que los participantes
expongan sus argumentos sobre los eventos y
tendencias más importantes en el área del tema
 Primera en cuestión. Al final de la circulación, el
circulación moderador recoge los cuestionarios y sintetiza la
información, seleccionando aquellos eventos
coincidentes que permiten una mejor definición
y manejo (a partir de esos eventos se estructura
el cuestionario de la segunda circulación).

Los cuestionarios estructurados con los eventos obtenidos

de la primera circulación son proporcionados a los
participantes y se les pide que den un pronóstico sobre la
fecha en que ocurrirán dichos eventos. Después de
responderlos, el moderador recoge los cuestionarios y, de
nueva cuenta, analizará y sintetizará la información. Ésta se
analiza de forma estadística centrando los resultados en la
 Segunda
mediana (la mediana representa que hay un 50% de
circulación
probabilidad de que el evento suceda en la fecha señalada);
el primer cuartil o valor inmediato inferior representa la
probabilidad del 25%, y el cuartil superior, el 75%. La
información obtenida del análisis estadístico es la que va a
servir de base para estructurar el siguiente cuestionario, que
incluirá la lista de eventos obtenidos de la primera
circulación y sus valores estadísticos de la segunda.

Página 57 de 129
Segundo Semestre
 El grupo recibe el cuestionario obtenido de la circulación
anterior y se le solicita que realice nuevos pronósticos. Si el
nuevo pronóstico se reafirma y queda entre los cuartiles
superior o inferior, se pide al participante que explique las
razones de su pronóstico y que diga las razones por las que
cree que los pronósticos de los demás participantes son
 Tercera incorrectos. Al garantizar el anonimato, el método Delphi
circulación permite que los participantes se expresen de modo más
abierto y libre. El moderador recoge los resultados y realiza
un nuevo análisis estadístico de ellos, organiza los
argumentos de los participantes que dieron un pronóstico
por arriba o debajo de la mediana. El cuestionario que será
preparado para la siguiente circulación contendrá el nuevo
análisis estadístico y los argumentos de los participantes.

Se solicita a los participantes leer los argumentos

presentados y realizar un nuevo pronóstico;
adicionalmente, se les pide un parecer sobre las
opiniones discrepantes. Al finalizar, de nueva cuenta el
moderador analiza la información y sintetiza las
opiniones.
 Cuarta
circulación Cuando las opiniones y pronósticos tienden a
centralizarse en un valor, se puede decir que el proceso
ha concluido; sólo queda pendiente que el moderador
elabore un reporte con las fechas de los pronósticos y
los comentarios. De no existir coincidencias en los
comentarios y pronósticos, el método continúa con más
circulaciones hasta alcanzar un consenso.

Figura 2.5 Las cuatro circulaciones de Delphi iniciales

Página 58 de 129
Segundo Semestre
 Revisa el Anexo 1. Empleo del método Delphi. En él encontrarás un ejemplo de
la aplicación del método Delphi presentado en el congreso EDUCTEC llevado a
cabo en Pachuca, Hidalgo, en 201114.

2.1.4. Desarrollo conjunto de aplicaciones

El desarrollo conjunto de aplicaciones (joint application development, JAD) es una

técnica desarrollada por IBM que se basa en la entrevista y se apoya en la dinámica
de grupos. Consiste en realizar una serie de reuniones en un periodo comprendido
entre dos y cuatro días.

Principios del desarrollo conjunto de aplicaciones:

1. Dinámicas grupales. Permiten la integración del grupo de trabajo.

2. Uso de ayudas audiovisuales. Algunos problemas o conceptos requieren de
soporte audiovisual como diagramas, diapositivas, pizarrones, etcétera, para
tener una visión amplia del problema y mejorar su comprensión.
3. Modo de trabajo sistemático. Los participantes definirán la forma de trabajo y de
analizar y solucionar el problema. Este modo de trabajo debe ser aceptado por
todos los participantes.
4. Generación de documentos bajo el modelo WYSIWYG. Todos los documentos
producidos en las actividades de trabajo son previsualizados de manera
inmediata, dando una idea de cómo quedará el contenido final.

14 Cabero, J. e Infante, A. (2014) Empleo del método Delphi y su empleo en la investigación en

comunicación y educación. EDUTEC, Revista Electrónica de Tecnología Educativa, 48. Disponible
en: http://www.edutec.es/revista/index.php/edutec-e/article/viewFile/187/18. Recuperado el 22 de
mayo de agosto de 2018.

Página 59 de 129
Segundo Semestre
La metodología JAD tiene dos partes: el JAD/plan, enfocado a la obtención de
requerimientos; y el JAD/design, encaminado al diseño de la aplicación. En nuestro
caso, nos concentraremos en la primera.

La metodología JAD cuenta con un grupo de participantes, donde hay de ocho a 12

usuarios finales del sistema y los desarrolladores. A los participantes se les asigna
uno de los siguientes roles:

Jefe de JAD

Analista

Patrocinador.

Representantes de los usuarios

Desarrolladores

Especialistas.

Figura 2.6 Roles de la metodología JAD

1. Jefe de JAD. Encargado de dirigir las reuniones. Es deseable que cuente con
características de liderazgo y facilidad de comunicación; será capaz de lidiar
con los conflictos que se puedan presentar para evitar que las sesiones se
alejen de los objetivos.

Página 60 de 129
Segundo Semestre
2. Analista. Responsable de recabar la información resultante de las sesiones y
ponerla por escrito. Se recomienda que tenga dominio pleno del tema en
cuestión y sepa utilizar de forma adecuada las herramientas de apoyo elegidas
por el grupo.
3. Patrocinador. Se trata de los clientes, generalmente dueño(s) del negocio. Será
capaz de decidir sobre el desarrollo del sistema. Su función principal es informar
sobre las necesidades que debe cubrir el sistema.
4. Representantes de los usuarios. Usuarios finales del sistema de los clientes que
aportarán una visión general de lo que debe realizar el sistema.
5. Desarrolladores. Grupo de personas con experiencia en el desarrollo de
software. Su tarea principal es identificar e informar de problemas en la
implementación de las características del sistema.
6. Especialistas. Personas que tienen conocimientos y experiencia suficientes
como para ser considerados autoridad en el ámbito de desarrollo de sistemas.
Su papel consiste en asesorar sobre aspectos específicos tanto de parte de los
usuarios como de los desarrolladores.

Determinados los roles, se procede a realizar las fases de trabajo. En el JAD/Plan

hay tres fases principales:

Adaptación

Sesiones JAD

Organización de la documentación

Figura 2.7 Fases principales del JAD/Plan

Página 61 de 129
Segundo Semestre
1. Adaptación. Durante esta fase, la carga recae sobre el jefe del JAD,
responsable de adaptar las sesiones de trabajo de acuerdo con las
características del proyecto.

En esta fase, el jefe del JAD tiene las siguientes actividades:

 Obtener información sobre la empresa y el proyecto a desarrollar.

 Organizar las sesiones considerando su número, lugar y duración, así como
los participantes en cada una. Es recomendable que las sesiones sean
programadas fuera de la empresa para evitar cualquier tipo de distracción.

2. Sesiones JAD. Una vez que el jefe del JAD decide la forma de llevar a cabo las
reuniones, éstas se realizan con los siguientes pasos:

 Presentación. Tanto el jefe del JAD como el patrocinador se presentan ante

el grupo de trabajo. El patrocinador explicará los motivos y características
generales del proyecto, y el jefe del JAD describirá la mecánica de la reunión.
 Definición de requerimientos de alto nivel. Se comienza a recabar
información clave para el desarrollo del sistema; se responde a preguntas
como: ¿qué beneficios se esperan del sistema?, ¿cuáles son los recursos
disponibles?, ¿en qué tiempos se desarrollará?, etcétera. La información
reunida se muestra en una pizarra u otro medio que la haga visible a todos
los participantes.
 Definición del ámbito del sistema. Recabados los requerimientos, se definen
las características y alcances del sistema.
 Documentación de temas abiertos. Cuando se generan temas sin resolver en
las sesiones de trabajo, deben ser documentados; se asignará un

Página 62 de 129
Segundo Semestre
 responsable para su análisis y solución, y serán discutidos en otra sesión de
trabajo.
 Conclusión. El jefe del JAD recopila la información de la sesión y realiza un
repaso de la misma ante el grupo. En este paso, se hacen correcciones o
añadidos a la información reunida.

3. Organización de la documentación. Recogida la información en la sesión de

trabajo, el jefe del JAD generará un documento formal, atendiendo los
siguientes pasos:

 Compilación. La información generada se redactará en un documento

estandarizado como el SRS o especificación de requerimientos del software
(SRS, software requirements specification).15
 Revisión. Elaborado el documento, se envía a los participantes de la sesión
para su revisión y corrección.
 Validación. El patrocinador revisa el documento y decide su aprobación.

El proceso se repite cuantas veces sea necesario para recopilar todos los requisitos
del sistema a desarrollar.

Ventajas del empleo de la metodología JAD en el proceso de desarrollo de sistemas:

 Los requerimientos son validados casi inmediatamente porque, al estar todos

los involucrados con el sistema, la información se puede corregir y validar
más rápido y de forma concreta.

15 Consulta el siguiente artículo como un ejemplo de documento SRS en la siguiente dirección:

López, C. Documento SRS (Software Requirements Specification)-IEEE830 Disponible en:
http://es.scribd.com/doc/63229261/Documento-SRS-Final. 22/08/2018.

Página 63 de 129
Segundo Semestre
  La inclusión de clientes y usuarios finales reduce la resistencia al cambio, ya
que se les involucra activamente en el proceso de desarrollo.
Si bien es eficiente e incluyente, la metodología JAD también puede ser difícil de
implementar debido, principalmente, a que los participantes no siempre están
disponibles al mismo tiempo para organizar las sesiones de trabajo (Durán, 2002,
pp. 20-22).

2.1.5. Diagrama causa-efecto de Ishikawa

También conocido como “de pescado” por su particular parecido a un esqueleto de

pescado, el diagrama causa-efecto de Ishikawa es una forma gráfica de representar
las diferentes teorías de las causas que provocan un problema. Por lo regular, se
emplea para realizar diagnósticos sobre las problemáticas y analizar y solucionar
sus posibles causas.16

Esta técnica requiere la formación de un grupo de trabajo de especialistas sobre el

ámbito del problema. Se realiza el trazado de un rectángulo, donde se escribe el
problema: del lado izquierdo las principales causas que pueden ocasionar el
problema, y del derecho sus efectos derivados.

16 Los diagramas de causa-efecto también pueden tener una estructura diferente. Revisa los
ejemplos que se presentan en: Education Oasis. Resources for teachers by teachers (2003-2017)
Cause and Effect Graphic Organizers [Título tercero]
http://www.educationoasis.com/curriculum/GO/cause_effect.htm. Recuperado: 22/08/2018.

Página 64 de 129
Segundo Semestre
 Figura 2.8 Diagrama de causa y efecto de Ishikawa17

Uno de los principales problemas de los diagramas causa-efecto es que las causas
por lo general son mutuamente excluyentes; no se relacionan entre sí. Esta
situación puede ser solventada tratando de encontrar relación entre las causas y
escribirlas en el mismo diagrama, con el objetivo de obtener una mejor perspectiva
del problema.

Los diagramas de causa-efecto comprenden tres pasos principales:

Identificación de
Generación de
Construcción del las causas y
posibles
diagrama efectos más
soluciones.
probables

Figura 2.9 Pasos principales del diagrama de causa –efecto

17 (Sin autor) (s/a) Ejemplo de diagrama Causa efecto. Disponible en:

http://www.cyta.com.ar/biblioteca/bddoc/bdlibros/herramientas_calidad/causaefecto.htm.
Recuperado: 24/08/18

Página 65 de 129
Segundo Semestre
1. Construcción del diagrama

 Formación del grupo de trabajo. Se integra un grupo con especialistas en el

contexto del problema, que no exceda los 15 participantes. En este grupo de
trabajo, se nombrará a un facilitador que se encargue de organizar y dirigir la
sesión.

 Planteamiento del problema. El facilitador explicará la forma de trabajo y

solicitará a los participantes que expliquen el problema. Se debe especificar
con detalle el problema para no generar ambigüedades. Definido el
problema, se escribe en un rectángulo: se traza una flecha del lado izquierdo
con sentido de izquierda a derecha, terminando con la punta señalando al
problema.

Figura 2.10 Planteamiento de problema

Elaboración propia

 Identificación de las posibles causas y su clasificación. A través de una lluvia

de ideas de los participantes, se busca establecer las posibles causas que
generan el problema en cuestión. Las causas identificadas se van
escribiendo en un pizarrón en forma de lista para su posterior clasificación
según su peso.

Página 66 de 129
Segundo Semestre
  Agrupación de las causas de acuerdo con su clasificación. Las causas
identificadas en el paso anterior se agrupan de acuerdo con la clasificación
asignada, buscando aquellas que tengan mayor impacto en el problema.
Este proceso también ayuda a ubicar causas repetidas o similares y
depurarlas.

 Construcción del diagrama. Clasificadas las causas de mayor a menor, se

procede a generar el diagrama, escribiendo las causas mayores en un
extremo unido por una línea a la flecha dibujada señalando al problema. Las
causas menores y subcausas se unen a las causas mayores a través de
líneas conectadas a la línea de la causa mayor. Es importante que los
participantes estén convencidos de que las causas anotadas estén
plenamente asociadas al problema.

Figura 2.11 Construcción de diagrama

Elaboración propia

Página 67 de 129
Segundo Semestre
2. Identificación de las causas y efectos más probables. Dibujado el diagrama,
se procede a seleccionar las causas que sean más probables (se puede realizar
por votación directa). En este punto, es importante que los participantes estén
realmente convencidos de que las causas seleccionadas son las de mayor
impacto en el problema.

3. Generación de posibles soluciones. Identificadas las causas principales del

problema, se procede a proponer posibles soluciones. Estas soluciones se
analizan, y se genera un documento donde se exponga(n) la(s) más viable(s)
para su aplicación y evaluación.

El uso de diagramas de causa-efecto en el desarrollo de sistemas de información

es una herramienta que permite identificar la problemática dentro de la organización
que se desea resolver, y detectar las soluciones más viables a implementar a través
del sistema.

En el Anexo 2. Herramientas de calidad18 puedes consultar varios ejemplos de

casos de aplicación del diagrama causa-efecto de Ishikawa.

Como ya se ha mencionado, los desarrolladores no están sujetos al empleo de una

técnica en particular o varias de ellas; dependerá en gran medida de las
características del proyecto y del criterio de los desarrolladores.

18 Ruiz Falcó Rojas, A. (2009) Herramientas de Calidad. Madrid: Universidad Pontificia.

Página 68 de 129
Segundo Semestre
 2.2. Métodos y técnicas
no estructurados para
la identificación de requerimientos

Los métodos no estructurados de recopilación de información no tienen una

estructura previa, como una encuesta o cuestionario. Entre los más empleados,
están la observación (participativa y dirigida), entrevistas (más profundas, como la
de un psicólogo), estudio de la documentación del negocio, etcétera.

2.2.1. Observación

La observación permite al analista ganar información que no se puede

obtener por otras técnicas. Por medio de la observación, el analista obtiene
información de primera mano sobre la forma en que se efectúan las
actividades. El método es más útil cuando el analista necesita observar, por
un lado, la forma en que se manejan los documentos y se llevan a cabo los
procesos y, por otro, si se siguen todos los pasos especificados. Los
observadores experimentados saben qué buscar y cómo evaluar la
significancia de lo que observan. (Senn, Observación).19

Ventajas:

 No hay necesidad de intermediarios. Se aprovecha el papel de cada

participante en el proyecto para recolectar datos.
 Aporta información sobre prácticas reales en la organización.

19 Build a free website of your own on TRIPOD (s/a), Título 13. Recuperado de:
http://une-
senn.tripod.com/new_page_1.htm#Herramientas_para_determinar_requerimientos_de_sistemas:
22/08/2018.

Página 69 de 129
Segundo Semestre
  Permite verificar hechos.
 No se requiere de muchos recursos.
 Permite comprender la forma de interacción de los grupos observados y las
normas de la organización.
 Permite una mejor comprensión del entorno del proyecto.
 El análisis de datos es más sencillo y objetivo.

Desventajas:

 Puede ser necesario aprender un idioma específico o tecnicismos para

interactuar con las personas.
 Es posible pasar por alto datos debido a una mala planeación de la
observación.
 Requiere una inversión alta de tiempo.
 Algunos campos de estudio pueden ser difíciles o imposibles (violencia de
género, prácticas sexuales, etcétera).

Observación participativa

Se caracteriza por la existencia de un conocimiento previo entre observador y

observado, y una permisividad en el intercambio, lo cual da lugar a una iniciativa por
parte de cada uno de ellos en su interrelación con el otro. El observado puede
dirigirse al observador, y el observador al observado, en una posición de mayor
cercanía psicológica, pero con un nivel de participación bajo o nulo.

Esta clase de observación consiste en convivir con la gente que uno estudia, llegar
a conocerlos en cuanto a su lenguaje y formas de vida a través de una interacción
continua con ellos en la vida diaria. Su mecanismo radica en buscar una regularidad
en las interacciones y una amplitud constante, manteniendo y creando relaciones.

Página 70 de 129
Segundo Semestre
Normas de la observación participante:

1. No bajar 2. Prestar 3. Tener 4. Realizar

la guardia atención a experiencias un registro
dando las los aspectos desde sistemático
cosas por culturales de dentro y de la
supuestas. la situación. fuera. observación.

Figura 2.12 Normas de la observación participante

Observación dirigida o sistémica

Esta clase de observación se enfoca a un terreno o hechos específicos como objeto

de estudio, alternando entre sesiones de observación en el campo o terreno de
interés y sesiones de reflexión sobre lo observado. Posterior a estas sesiones de
reflexión, se redactan las conclusiones sobre el asunto de interés.

Requiere una planificación donde se establezcan los tiempos de observación y los

objetivos a estudiar. Luego de cualquier sesión de observación, se realizará un
trabajo de redacción a modo de diario que reúna todos los datos recopilados para
su análisis formal.

La observación es una técnica empleada en el sitio donde va a funcionar el sistema,

por lo que es una herramienta excelente para determinar requerimientos no

Página 71 de 129
Segundo Semestre
funcionales vinculados principalmente con el ámbito del sistema. Una de las
ventajas de la observación es que cualquier miembro del equipo de desarrollo puede
aplicarla, previa planificación por parte de todos los participantes, incluyendo a los
clientes.

2.2.2. Revisión de documentos de la organización

Según García Gutiérrez:

El análisis documental es una forma de investigación técnica, un conjunto

de operaciones intelectuales, que buscan describir y representar los
documentos de forma unificada y sistemática para facilitar su recuperación.
Comprende el procesamiento analítico-sintético que, a su vez, incluye la
descripción bibliográfica y general de la fuente, la clasificación, indización,
anotación, extracción, traducción y la confección20.

En el caso de la recopilación de información para los sistemas de información, este

tipo de análisis ayuda a reunir información a través de documentos ya existentes
que faciliten la construcción del sistema. Algunos documentos susceptibles de
análisis son la documentación sobre sistemas similares, manuales de la
organización, manuales de procedimientos, etcétera.

El análisis documental se realiza en dos fases: análisis formal y análisis de

contenido. En el primero, se recolecta toda la información objetiva del documento
que permite conocer aquellos datos que permiten diferenciar un documento de otro,
como tipo de documento, autores, título de la obra, editorial, fechas, idiomas,
número de páginas, entre otros.

20 Fuente: Análisis documental y de información: dos componentes de un mismo proceso.

Dulzaines Iglesias, Maria E. Molina Gómez, Ana María. Disponible en:
http://eprints.rclis.org/5013/1/analisis.pdf. Recuperado el 24/08/18.

Página 72 de 129
Segundo Semestre
El análisis documental permite realizar un control e identificación de los diversos
documentos en una colección de los mismos realizando dos operaciones básicas,
catalogación y descripción documental (Solís, 2003).

La catalogación tiene como objetivo principal establecer un listado de todos aquellos

documentos que integran una colección, separando perfectamente los temas,
autores y tipos de documentos. El resultado final de esta fase es el catálogo de
documentos, instrumento que sirve de vínculo entre los usuarios de la colección y
los documentos que contiene.

En cuanto a la descripción documental, es el proceso por el cual se describen los

documentos de acuerdo con sus características internas y externas. Aquí, se
consideran atributos como autor, título, lugar de edición, editor, año de publicación,
entre otros.

La descripción documental está sujeta a normas que permiten manejar la

información de forma precisa, además de facilitar su clasificación y posterior
búsqueda dentro de la colección de documentos. Las normas de catalogación más
extendidas son las ISBD (International Standard Bibliographic Description) y las
Normas de Catalogación Angloamericanas.

En el análisis de contenido, se realizan acciones que posibilitan la descripción del

contenido o temática de un documento generando tres resultados que facilitan el
mejor manejo de la información: clasificación, indización y resumen.

Página 73 de 129
Segundo Semestre
 Clasificación
Es un conjunto ordenado de conceptos que se
Indizar presentan distribuidos sistemáticamente en
clases conformando una estructura. La creación
Es extraer una serie de conceptos
de catálogos e índices ha sido de mucha ayuda
que responden a los temas
a lo largo de la historia de la humanidad para
tratados en el documento, y que
buscar y recuperar información. Las
servirán como puntos de acceso
clasificaciones más extendidas en el mundo son
para su recuperación. (Rubio,
la CDU (Clasificación Decimal Universal), la
2004, p. 5).
Clasificación Decimal Dewey y la LCC
(Clasificación de la Biblioteca del Congreso de
Washington).

Resumen
El es una representación abreviada y precisa del contenido de un
documento, sin interpretación crítica ni mención del autor del documento
(ISO) (Rubio, 2004, p. 9). En otras palabras, es una visión general
sintetizada del contenido completo de un documento elaborado en un
lenguaje natural. Los resúmenes ayudan a los usuarios a determinar si la
información que buscan se encuentra en el documento; de esta forma, es
posible que el usuario seleccione los documentos que le son útiles, y
descarte los que no.

Figura 2.13 Análisis de contenido

El análisis documental implica el conocimiento del documento, su análisis, síntesis,

representación y recuperación.

El análisis documental permite a los desarrolladores conocer el historial de la

organización, sus operaciones y estructura interna. Con lo anterior, es posible
identificar necesidades internas y de operación que ayuden al desarrollo del sistema
de información.

Página 74 de 129
Segundo Semestre
 RESUMEN
La identificación de requerimientos es una fase del ciclo de vida de los sistemas de
información, que facilita reconocer las necesidades de la organización y determinar
las funciones que el sistema realizará.

El proceso de identificación de requerimientos puede emplear diversos métodos o

técnicas, que involucran tanto a los desarrolladores del sistema como a los dueños
y directivos de la organización, así como a los empleados que serán los usuarios
finales y a expertos que aporten su experiencia en el reconocimiento de problemas
y necesidades.

Dentro de las diversas formas para la identificación de requerimientos, hay métodos

estructurados: cuestionarios, entrevistas, diagramas de causa-efecto, etcétera, los
cuales llevan a establecer una forma perfectamente dirigida a la obtención de cierta
información en particular. También encontramos métodos no estructurados, como
la observación y el análisis documental, que conducen a obtener información sobre
el entorno en que se desempeñará el sistema y las expectativas del mismo.

Página 75 de 129
Segundo Semestre
 BIBLIOGRAFÍA

BIBLIOGRAFÍA SUGERIDA

Bruegge, B. y Dutoit, A. H. (2002). Ingeniería de software orientada a objetos.

México: Pearson.
Durán Toro, A. (2000). Metodología para la elicitación de requisitos de sistemas de
software. Visualización previa: http://es.scribd.com/doc/49567897/15/Joint-
Application-Development. Recuperado el 9 de noviembre de 2012.
Ince, D. (1993). Ingeniería de software. México: Addison-Wesley.
Joyanes Aguilar, L. (2003). Fundamentos de programación: algoritmos, estructuras
de datos y objetos (3.ª ed.) Madrid / México: McGraw-Hill.
Kendall, K. (1990). Análisis de diseño de sistemas. México: Prentice Hall.
Larman, C. (1999). UML y patrones: introducción al análisis y diseño orientado a
objetos. México: Prentice-Hall.
Márquez Vite, J. M. (2002). Sistemas de información por computadora, metodología
de desarrollo. México: Trillas.
Meyer, B. (1999). Construcción de software orientado a objetos. Madrid: Prentice-
Hall.
Osorio Rojas, R. (2002). El cuestionario. Magister Educación, disponible en línea:
http://www.nodo50.org/sindpitagoras/Likert.htm. Recuperado el 8 de
octubre de 2012.
Pfleeger, S. L. (2002). Ingeniería de software: teoría y práctica. México: Prentice
Hall.

Página 76 de 129
Segundo Semestre
Piattini Velthuis, M. y García, F. (Coord.). (2003). Calidad en el desarrollo y
mantenimiento de software. México: Alfaomega / Ra-Ma.
Piattini Velthuis, M., Calvo-Manzano Villalón, J., Cervera Bravo, J. y Fernández
Sanz, L. (2003). Análisis y diseño de aplicaciones informáticas de gestión.
México: Alfaomega / Ra-Ma.
Pressman, R. S. (2002). Ingeniería de software: un enfoque práctico (5.ª ed.).
México / Madrid: McGraw-Hill.
Rubio Liniers, M. C. (2004). El análisis documental: indización y resumen en bases
de datos especializadas. Disponible en línea:
http://eprints.rclis.org/6015/1/An%C3%A1lisis_documental_indizaci%C3%
B3n_y_resumen.pdf Recuperado el 9 de noviembre de 2012.
Senn, J. A. (S. f.). “Primera fase: Análisis”. Análisis y diseño de sistemas de
información. Disponible en línea: http://une-
senn.tripod.com/new_page_1.htm#Herramientas_para_determinar_requeri
mientos_de_sistemas. Recuperado el 20 de marzo de 2011.
Sommerville, I. (2001). Ingeniería de software (6.ª ed.). México: Pearson.
Weitzenfield, A. (2003). Ingeniería de software orientada a objetos con UML, Java
e Internet. México: Thomson.

Página 77 de 129
Segundo Semestre
 UNIDAD 3
ESPECIFICACIÓN
DE REQUERIMIENTOS
 OBJETIVO PARTICULAR
El alumno registrará el detalle de los requerimientos funcionales y no funcionales.

TEMARIO DETALLADO
(28 horas)

3. Especificación de requerimientos
3.1. Estándares para especificar requerimientos
3.2. Normas para la redacción de requerimientos funcionales
3.3. Generación de la lista de requerimientos
3.4. Especificación de requerimientos funcionales
3.4.1. Especificación de casos de uso
3.5. Especificación de requerimientos no funcionales

Página 79 de 129
Segundo Semestre
 INTRODUCCIÓN

La especificación de los requerimientos de un sistema de información es una de las

partes más importantes en el ciclo de vida del mismo. De ella depende, en gran
medida, cómo funcionará el sistema y se comportará con su entorno.

La especificación de requerimientos ayuda a los desarrolladores a identificar “qué

debe hacer el sistema” y “cómo debe ser”, y se logra a partir de los requerimientos
funcionales y no funcionales asociados a tal sistema.

Una mala especificación de requerimientos conlleva un diseño deficiente y costoso

de un sistema de información. Para evitarlo, se han establecido formas
estandarizadas que resumen las mejores prácticas en el diseño de sistemas para
especificar sus requerimientos.

A lo largo de esta unidad, revisaremos los principales estándares y formas para

especificar correctamente los requerimientos de un sistema.

Página 80 de 129
Segundo Semestre
 3.1. Estándares para
especificar requerimientos
La estandarización es un proceso mediante el cual se busca alcanzar la calidad de
los productos o servicios. Podemos decir que, cuando uno estandariza un proceso,
se asegura de que todo lo que se realice dentro de ese proceso siempre entregará
el mismo resultado con las mismas características, evitando con ello diferencias y,
por tanto, variaciones.

En el caso de la ingeniería de software, cumple con una serie de normativas para

estandarizar los procesos que integran el ciclo de vida de los sistemas.

El Instituto de Ingeniería Eléctrica y Electrónica (IEEE, por sus siglas en inglés) es

una institución sin fines de lucro, dedicada a la promoción y desarrollo de la
innovación tecnológica. Es una de varias instituciones21 alrededor del mundo que
se encarga de emitir normas para la estandarización de las formas para desarrollar
nuevas tecnologías. Entre sus estándares más conocidos,

21 Otra es la norma de la OSI, enfocada al factor de calidad, que se aplica en la parte de pruebas de
sistemas y como modelos de referencia para redes. Un consorcio más es el de Fuerza de Tarea de
Internet (IETF), encargado de otras áreas de la informática.

Página 81 de 129
Segundo Semestre
 encontramos:

IEEE 1394. Estándar para la entrada y salida de datos (conocido como firewire).

IEEE 488. Estándar bus de datos digital de corto rango

IEEE 754. Estándar para aritmética de punto flotante

Figura 3. 1 Normas de estandarización

Página 82 de 129
Segundo Semestre
En nuestro caso, nos enfocaremos al estándar IEEE 830 (sobre la especificación de
requerimientos de software), que busca generar un buen contenido y especificación
de requerimientos de software a través de diversos esquemas. Su objetivo es
puntualizar los requerimientos del software a desarrollar y establecer un acuerdo
documentado entre el cliente y los desarrolladores de sistemas sobre el sistema a
construir. Con base en esto, la plantilla del documento SRS (especificaciones de
requerimiento de software)22, contiene las siguientes secciones:

1. Introducción
2. Descripción general
3. Requerimientos específicos
4. Apéndices

La introducción del documento SRS, generado a partir del estándar IEEE 830,
comprenderá los siguientes apartados:
Definiciones, acrónimos y
Ámbito del sistema. abreviaturas. Es una
Propósito. Describe el
Describe el entorno en el especie de glosario, donde
objetivo que se persigue al
cual operará el sistema a se encuentra toda la
construir el sistema y su
desarrollar. terminología técnica que
análisis.
se empleará durante el
desarrollo del sistema.

Referencias. Documentos Visión general del

de consulta que serán documento. Describe de
empleados a lo largo del manera general el
desarrollo del documento. contenido del documento.

Figura 3.2 Introducción de documentos SRS

22 Jason Robins (2003). Ejemplo de Especificación de requerimientos de software, Disponible en:

http://readyset.tigris.org/nonav/es/templates/srs.html Recuperado: 22/08/2018.

Página 83 de 129
Segundo Semestre
La descripción general contiene:

 Perspectiva del producto. Descripción de los resultados esperados al final

del desarrollo del sistema, acordes con los requerimientos provistos por el
cliente.
 Funciones del producto. Describe la forma como el sistema funcionará de
manera particular (en cada módulo) y general.
 Características de los usuarios. Define los perfiles y características
generales de todos los usuarios que tendrán contacto directo o indirecto con
el sistema.
 Restricciones. Describe las limitaciones que tendrán tanto el sistema como
sus usuarios.
 Suposiciones y dependencias. Se describen los objetos (interfaces,
requerimientos, usuarios, etcétera) que pueden presentar una dependencia
de otros objetos durante el desarrollo del sistema.
 Requisitos futuros. Algunas características o funciones adicionales que el
usuario podría necesitar a futuro.

Dentro de la sección de requerimientos, encontramos los siguientes apartados:

 Interfaces externas. Se presentan aquellos requerimientos que describen la

forma como se realizará la comunicación entre el sistema y su entorno
(incluyendo a los usuarios).
 Funciones. En esta parte, la más extensa del documento, se especifican todas
las funciones que deberán ser ejecutadas por el sistema. Dichas funciones se
expresan con enunciados concretos, como “el sistema deberá…”; se pueden
emplear herramientas gráficas para ayudar en su definición, pero siempre
llegando a un enunciado. El estándar IEEE 830 permite dividir esta sección en
varios segmentos:

Página 84 de 129
Segundo Semestre
  Tipo de usuarios. Aquí, se organiza a los usuarios por jerarquías y
dependiendo del tipo de interacción que tendrán con el sistema.
Posteriormente, se especifican los requerimientos funcionales
asociados a cada uno de ellos que tengan relación con sus actividades.
 Por objetos. Según el paradigma orientado a objetos, cada objeto es
una representación de entidades del mundo real con atributos y
funciones concreto. Los objetos pueden agruparse en clases y cada una
de ellas definir una serie de requerimientos funcionales asociados a
ellos.
 Por objetivos. A partir de los objetivos definidos al planificar la
construcción del sistema, se deciden las entradas requeridas para
alcanzar dicho objetivo y la salida deseada (lo que debe hacer el
sistema). Por cada objetivo se establecerán las funciones necesarias
para alcanzarlo.
 Por jerarquía funcional. Se prioriza cada una de las funciones que realizará el
sistema con el objetivo de jerarquizarlas, especificando cuáles comparten
entradas y salidas de datos y detallando cada función de manera minuciosa
para fijar sus requerimientos.

 Requisitos de rendimiento. Se trata de los requerimientos asociados al

desempeño del sistema, como tiempos de respuesta, formas de
almacenamiento de datos, entre otros.
 Restricciones de diseño. Factores que limiten el diseño del sistema; por
ejemplo, hardware, otros estándares o la normativa de la organización.
 Atributos del sistema. Dentro de este apartado, se describen los atributos que
definen la calidad del sistema; por ejemplo: fiabilidad, mantenibilidad,
seguridad, etcétera. Es necesario detallar cómo serán implementados los
atributos, como formatos de nombre de usuario y contraseña, restricciones
de acceso a los usuarios, mecanismos de recuperación de datos, entre otros.

Página 85 de 129
Segundo Semestre
  Otros requisitos. Se describen aquellos requerimientos funcionales que no
pueden ser englobados en las secciones anteriores.

En la sección de apéndices, se coloca toda la información necesaria para la

construcción del sistema que no se encuentra considera en el documento SRS,
como entrevistas, informes, análisis de tiempos, costos, etcétera.

Para consolidar el tema, consulta el Anexo 3. Ejemplo de especificación de

requerimientos para sesion23. En él encontrarás un ejemplo de un documento SRS
desarrollado por Tania Isadora Mora (2007), de la Universidad del Valle, en Santiago
de Cali, Colombia.

23 Mora, Tania Isadora. (2007) Ejemplo de especificación de requerimientos, Santiago de Cali:

Universidad del Valle. Disponible en
http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:pis:ejemplo_de_especificacion_de_requeri
mientos_-_para_sesion_9.pdf (Recuperado el 24 de agosto de 2018).

Página 86 de 129
Segundo Semestre
 3.2. Normas para la redacción
de requerimientos funcionales

Al redactar un documento de especificación de requerimientos funcionales, se

cuidará que reúna las siguientes características (derivadas de la norma IEEE 830).

No ambiguo Se debe asegurar que todos los requerimientos tengan una

sola interpretación.
Completo Incluir todo aquello que se desea del sistema. La
“completitud” consiste en que deben describirse todas las
posibles opciones de respuesta que una entrada al sistema
pueda generar y todas las situaciones que puedan enfrentar
en el ámbito del sistema.
Correcto Todo requerimiento especificado debe ayudar a resolver
una necesidad real.
Comprensible Cualquier persona con acceso a la lectura de un SRS debe
poder interpretarlo sin dificultad.
Verificable Se debe establecer un procedimiento que permita
demostrar que cada requerimiento será satisfecho por el
sistema al ser construido.
Consistencia No deben existir requerimientos contradictorios.
interna
Consistencia Ninguno de los requerimientos deberá estar en
externa contradicción con otros documentos de especificaciones
superiores o del mismo nivel del SRS. Ejemplo: las
especificaciones del hardware no deben ir en contradicción
con las del software.

Página 87 de 129
Segundo Semestre
 Realizable El requerimiento especificado en el documento SRS debe
poder implementarse con los recursos actuales.
Conciso La redacción del documento SRS debe ser lo más breve
posible sin afectar los atributos de calidad marcados.
Independiente del El documento SRS debe enfocarse a la funcionalidad
diseño general del sistema, siendo independiente de la
metodología de diseño e implementación del sistema
seleccionadas.
Trazable Cada requerimiento debe poder ser referenciado de forma
única y sin equivocación, para ayudar a determinar qué
requerimientos son implementados en cada fase.
Modificable Los cambios realizados deben implementarse con facilidad.
Almacenables Es deseable que cada documento redactado pueda
electrónicamente almacenarse en un medio electrónico como un archivo o
registro en una base de datos (de preferencia con
herramientas para la administración de requisitos).
Anotado por Se debe clasificar el requisito con un calificativo como
importancia “obligatorio”, “deseable” u “opcional”, que ayude a la
relativa. asignación de recursos y su implementación.
Anotado por Cada requerimiento debe tener asignada una probabilidad
estabilidad denominada de cambio, lo que ayudará a determinar si será
relativa estable o volátil en su implementación.
Versionado Se recomienda establecer por escrito qué requerimientos
serán satisfechos en una versión específica del sistema o
número de prototipo.
No redundante Cada requerimiento debe redactarse en un solo lugar del
documento SRS, sin repeticiones.

Página 88 de 129
Segundo Semestre
 Abstracto El nivel de detalle de cada requerimiento debe ser el
suficiente para ser comprendido, sin excesos o carencias
de detalles.
Preciso Se sugiere emplear una notación numérica para calificar las
características del sistema (aunque esto depende de la
tecnología empleada para hacerlo, y no siempre es
posible).
Reutilizable El documento determina si algunas partes del SRS son
reusables en otros requerimientos.
Trazado El documento identifica claramente la fuente que originó el
requerimiento.
Organizado El lector del documento debe localizar fácilmente la
información contenida en él.
Con referencias Se establecerá claramente si los requerimientos tienen
cruzadas relación entre otros, o entre otras secciones del documento.

Tabla 3.1 Características (derivadas de la norma IEEE 830).

Aunque es imposible tener un documento perfecto, si se elabora uno de gran

calidad, se disminuirán o eliminarán errores de implementación.

Página 89 de 129
Segundo Semestre
 3.3. Generación de la lista
de requerimientos

Una de las formas de documentación de requerimientos son los listados. Por lo

regular, estas listas describen los requerimientos funcionales del sistema desde un
punto de vista global.

La lista debe tener las siguientes características:

Identificador único Número asociado a cada requerimiento

identificado para el sistema.
Nombre del Nombre asociado que permita identificar de forma
requerimiento sencilla el requerimiento listado.
Necesidad Se refiere a la categoría que va a recibir: esencial,
opcional, condicional, etcétera.
Estado Indica si el requerimiento ha sido definido
perfectamente y es lo suficientemente claro para
su uso (cerrado), o si es necesario detallar más el
requerimiento (abierto).
Versión Referente a la cantidad de cambios que ha sufrido
el requerimiento a lo largo del proceso de
desarrollo del sistema.

Tabla 3.2 Lista de requerimientos

Página 90 de 129
Segundo Semestre
 Identificador Nombre Necesidad Estado Versión
1 Esencial/Opcional/Condicional Cerrado/Abierto 3

Independientemente de estas características, algunos autores agregan otras, tantas

como sean o consideren necesarias para registrar y manejar los requerimientos
capturados.

Puedes consultar un ejemplo de listado de requerimientos en Pérez Pedraza, A.

(2004). “Apéndice B: Lista de requerimientos24”. Implementación y explotación de
un datawarehouse empresarial para la toma de decisiones: aplicación a la empresa
Textiles Carmelita. Tesis de licenciatura, UDLA.

24
Pérez Pedraza, A. 2004. Implementación y explotación de un datawarehouse empresarial para la
toma de decisiones: aplicación a la empresa Textiles Carmelita. Tesis Licenciatura. Ingeniería en
Sistemas Computacionales. Departamento de Ingeniería en Sistemas Computacionales, Escuela de
Ingeniería, Universidad de las Américas Puebla. Mayo. Disponible en línea para consulta en:
http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/perez_p_a/portada.html. (Recuperado el
24/08/18)

Página 91 de 129
Segundo Semestre
 3.4. Especificación
de requerimientos funcionales

Los requerimientos funcionales describen las funciones del sistema, es decir,

especifican qué hará el sistema de acuerdo con sus características, tipo de usuarios
y enfoque organizacional; por ejemplo, el formato que debe tener un reporte de
almacén, la estructura y composición de una consulta financiera, etcétera.

Ejemplos de requerimientos funcionales:

1. “El usuario podrá consultar la base de datos del sistema en todo momento”.
2. “El sistema deberá generar reportes en un formato compatible con un procesador
de texto”.
3. “Cada operación realizada en el sistema deberá registrarse y contener un
identificador único”.

Figura 3.3 Ejemplos de requerimientos funcionales

Cuando algunos requerimientos establecidos por los usuarios tienden a ser poco
claros o muy generales, deberán examinarse y detallarse. Por ejemplo, en el
requerimiento 2, que solicita reportes compatibles con un procesador de texto, se
debe especificar con más claridad en cuanto a los formatos de los reportes y el
procesador de texto que se va a usar para evitar problemas de compatibilidad.

En general, cuando se especifican requerimientos funcionales, se busca que se

tengan las siguientes características:

Página 92 de 129
Segundo Semestre
  Completos. Todas las funciones solicitadas por el usuario deben estar
perfectamente definidas.
 Consistentes. Las definiciones de los requerimientos no serán
contradictorias, para evitar confusiones.
 Claros. Deben de ser redactados de tal forma que los usuarios comprendan
con puntualidad lo que se solicita.
 Funcionales. Establecen las características externas del sistema y su
comportamiento; no se deben establecer características de diseño.
 Priorizados. Los requerimientos deben jerarquizarse para que los
desarrolladores puedan establecer cuáles serán obligatorios, deseables u
opcionales.

Ejemplo de un requerimiento mal especificado:

“Para facilitar el uso del editor gráfico, se podrá activar y desactivar una rejilla que
permitirá alinear las figuras del diagrama. Cuando se ajuste la figura al tamaño de
la pantalla, se reducirá el número de líneas de la rejilla para que no se dificulte la
visualización del diagrama.”25

Figura 3.4 Ejemplo de un requerimiento mal especificado:

En la especificación anterior, notamos que dentro del enunciado hay varios

requerimientos; la especificación queda muy abierta o vaga.

La forma correcta de la especificación puede ser:

25 Anexo 4. Requirements. Berzal (s/a) Especificación de requerimientos. Granada: Universidad de

Granada. P. 14. Disponible en: http://elvex.ugr.es/idbis/db/docs/design/2-requirements.pdf
(Recuperado: 24/08/2018).

Página 93 de 129
Segundo Semestre
“El editor permitirá el uso de una rejilla de líneas horizontales y verticales que
aparecerán dibujadas tras el diagrama”. 26

Justificación:
La rejilla facilita la creación de diagramas cuidados en los que las figuras se puedan
alinear con facilidad.

En la especificación anterior, el requerimiento es completo y consistente, y cuenta

con una justificación que refuerza la función solicitada.

Algo muy útil para especificar requerimientos funcionales, es el empleo de casos de

uso, que revisaremos a continuación.

3.4.1. Especificación de casos de uso

Los diagramas de caso de uso son documentos que describen cómo deberá
comportarse el sistema desde el punto de vista de los usuarios. Son la fuente
principal de información que ayuda a los diseñadores de sistemas a determinar los
requerimientos funcionales del sistema: representan las funciones que el sistema
puede ejecutar.

Una de las principales ventajas de los diagramas de casos de uso es la facilidad

para ser interpretados, haciendo más sencilla la comunicación entre desarrolladores
y clientes.

26 Anexo 4. p. 15.

Página 94 de 129
Segundo Semestre
A continuación, se describen los elementos principales que integran un diagrama
de caso de uso.

Actores
Los actores son la representación gráfica de los diversos tipos de
usuarios del sistema (un usuario es toda entidad externa que tiene
interacción con el sistema, sean personas, departamentos de una
empresa, otros sistemas de información, etcétera).

Para desarrollar de forma efectiva un diagrama de caso de uso, es

recomendable independizar a los actores de acuerdo con la forma en
que actúan con el sistema. Por ejemplo, en un sistema de consulta, el
usuario que solamente consulta la información del sistema no realiza las
mismas tareas que el usuario encargado de alimentar dicha información
dentro del sistema.

En un diagrama de casos de usos, los actores representan papeles que

una entidad juega al interactuar con el sistema; estos papeles o roles –
como también se les denomina– pueden representar a más de un
usuario. Volviendo al ejemplo del sistema de consulta, la forma de
interactuar de dicho usuario con el sistema puede representar a más de
una persona que realiza la misma acción. Por ejemplo, en las páginas
de Internet del Gobierno Federal, como la de Hacienda, existen
diferentes usuarios que utilizan su portal para enviar declaraciones
anuales; en un diagrama de caso de uso, no representamos a cada
individuo, sino a ese conjunto de usuarios como una sola entidad que
ejecuta una tarea genérica.

Página 95 de 129
Segundo Semestre
 Símbolo para representar a los actores:

Figura 3.5 Elementos principales que integran un diagrama de caso de uso.

Caso de uso. Representa de

forma gráfica una tarea o función
que el usuario puede realizar
apoyándose en el sistema a
desarrollar. Los casos de uso se
representan habitualmente
mediante un texto, encerrado en
un óvalo, que describe la
actividad.

Figura 3.6 Caso de uso descriptivo

Elaboración propia
AAa

Asociaciones. Son líneas rectas que relacionan

cada caso de uso con los actores que realizan
dicha tarea. Para cada usuario existirá al
menos una asociación con una acción o caso
de uso, lo que dependerá de la forma como se
interactúe con el sistema.

Figura 3.7 Asociaciones

Página 96 de 129
Segundo Semestre
 Elaboración propia

Página 97 de 129
Segundo Semestre
 Escenarios
Son la representación de una interacción entre un usuario y el sistema.
Dentro de la fase de diseño del sistema, pueden surgir múltiples
escenarios que describan la forma como diferentes usuarios
interactuarán con el sistema.

Ejemplos:

Escenario 1 Escenario 2
Cliente consultando su saldo en un Capturista ingresando datos personales
cajero automático. para su registro en una base de datos.

En el proceso de documentación del sistema, todos los escenarios

generados deben registrarse en un diagrama denominado de secuencia,
cuyo objetivo es numerar e indicar la interacción de los usuarios con el
sistema en todas las formas posibles.

Al especificar un caso de uso, se busca realizar una descripción de cada una de las
partes definidas en él, para lograr establecer una descripción a detalle del mismo.

Cuando se especifican casos de uso, se debe considerar lo siguiente:

Interacciones
Describir la forma de participación de los actores primarios y secundarios a lo largo
de todo el caso de uso.

Página 98 de 129
Segundo Semestre
Eventos
Describir cada uno de los eventos que tiene ocurrencia en el caso de uso. Por
ejemplo, la captura de datos, consulta de datos, compra y pago de algo,
etcétera.

Nivel de detalle
Describir lo mejor posible las funciones que realizará el sistema a lo largo del
desarrollo del caso de uso, lo que ayudará a extraer los requerimientos
funcionales con mayor precisión.

Escenarios
Describir cada uno de los escenarios que considere el caso de uso,
estableciendo un flujo de acciones principales y flujos secundarios y
extraordinarios que puedan aparecer.

Claros y enfocados en el usuario

En la redacción, emplear un lenguaje simple y sin tecnicismos, para que puedan ser
interpretados por clientes y usuarios. (Anexo 4. Requirements)27

Podemos emplear la siguiente plantilla para redactar las especificaciones de

los casos de uso.

Caso de uso Nombre e identificador único para el caso de uso.

Fuentes Nombre de los clientes o usuarios que proporcionan
información para la elaboración del caso de uso.

27 Anexo 4. pp. 9-21.

Página 99 de 129
Segundo Semestre
 Actores Nombre de los actores e identificadores asociados
a cada uno para su seguimiento. Ejemplo: Cliente
C1, Vendedor de mostrador VM1, etcétera.
Descripción Descripción del caso de uso.
Flujo principal Descripción de las acciones realizadas en el caso
de uso. Se recomienda redactarlo en forma de lista:
Paso 1: descripción
Paso 2: descripción
Flujos alternos o Descripción de las acciones secundarias derivadas
extraordinarios del flujo principal.
Condiciones Descripción de la situación antes de comenzar el
previas caso de uso.
Condiciones Descripción de la situación posterior al caso de uso.
posteriores
Requerimientos Listado y descripción de los requerimientos
trazados funcionales identificados en el caso de uso.
Puntos de Elementos del caso de uso que son empleados en
inclusión otros casos de uso.
Puntos de Descripción de los enlaces que permiten extender la
extensión funcionalidad de un caso de uso a uno o varios
puntos dentro del flujo principal.
Notas Información adicional que ayude a la comprensión y
análisis del caso de uso.

Tabla 3.3 Cómo especificar casos de usos28

28 Anexo 4. pp. 23-30.

Página 100 de 129

Segundo Semestre
En la siguiente dirección electrónica, encontrarás un ejemplo del empleo de casos
de uso y su especificación en el desarrollo de un sistema de gestión de artículos
deportivos, desarrollado por el Departamento de Sistemas Informáticos y
Computación de la Universidad Politécnica de Valencia, España:

Ejemplo de desarrollo software con la metodología RUP. Disponible en:

http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/Casos_Uso.html.
Recuperado el 22 de agosto de 2018.

Página 101 de 129

Segundo Semestre
 3.5. Especificación
de requerimientos no funcionales

Los requerimientos no funcionales definen las propiedades que debe tener el

sistema, como fiabilidad, tiempo de respuesta y capacidad de
almacenamiento. También ayudan a determinar las restricciones del sistema:
capacidad de los dispositivos de entrada/salida (almacenamiento, cantidad
de consultas por usuario, etcétera) y la forma de representación de los datos
en las interfaces del sistema para su interpretación por los usuarios (formatos
de reportes, formato de pantalla, etcétera).

Los requisitos no funcionales se redactan de manera cuantitativa siempre que

sea posible, con la finalidad de que puedan evaluarse objetivamente.

A continuación, se presenta una tabla con algunas métricas sugeridas por Ian
Sommerville (2001: 114) para especificar un requerimiento no funcional.

Página 102 de 129

Segundo Semestre
 Rapidez Portabilidad
-Transacciones procesadas por segundo. -Porcentaje de instrucciones u objetos
-Tiempo de respuesta del sistema hacia dependientes de otros.
el usuario o un evento determinado. -Número de sistemas objeto.
-Tiempo de actualización de pantalla.

Robustez
Tamaño -Tiempo de reinicio después de fallos.
-Cantidad de Kilobytes de un archivo -Porcentaje de eventos que provocan
generado o de un registro en la base fallos.
de datos. -Probabilidad de corrupción de datos
-Número de placas de memoria RAM. después de fallos.

Fiabilidad
Facilidad de uso -Tiempo de recuperación entre fallos.
-Tiempo de formación. -Probabilidad de no disponibilidad.
-Número de pantallas de ayuda. -Tasa de ocurrencia de fallos.
-Disponibilidad (24/7, 365/24, etcétera).

Figura 3.8 Tabla métrica sugerida por Ian Sommerville

Elaboración propia.

Ejemplo de especificación de un requerimiento no funcional:

“Cuando haya hasta 100 usuarios accediendo simultáneamente al sistema, su

tiempo de respuesta no será en ningún momento superior a 2 segundos”. P. 17).29

La especificación anterior cuenta con una métrica que permitirá evaluar el

requerimiento una vez implementado.

29 Anexo 4. p. 17.

Página 103 de 129

Segundo Semestre
 RESUMEN

La especificación de requerimientos se refiere a la forma correcta de expresar las

necesidades de un sistema de información. Estos requerimientos pueden ser
funcionales o no funcionales, y se especificarán dependiendo de su naturaleza.

En los enfoques del desarrollo de software –empleando cualquier paradigma, el

orientado a objetos, en cascada, estructural, etcétera–, encontramos diversas
metodologías para identificar requerimientos, pero se recomienda seguir un proceso
estandarizado establecido por la norma IEEE 830, donde figura un formato estándar
para la especificación de requerimientos de software, conocido como SRS. En este
documento, se conjugan las buenas prácticas para la especificación de
requerimientos.

Aunque se cuenta con plantillas y normas que nos ayudan a documentarlos y

resguardarlos, los requerimientos no siempre son redactados de forma adecuada;
la mala redacción conlleva problemas de claridad y redundancia en la información,
lo que genera una mala implementación del requerimiento en el sistema.

Una redacción de requerimientos precisa comienza con el empleo de un lenguaje

natural y libre de terminología técnica, tomando en cuenta que el documento de
especificación de requerimientos servirá a la vez como un contrato entre clientes y
desarrolladores para definir las características y funciones del sistema.

Adicionalmente, los requerimientos serán concretos, simples, completos y

trazables, y tendrán características que faciliten su implementación, evaluación y
seguimiento.

Página 104 de 129

Segundo Semestre
Cada tipo de requerimiento, según sea funcional o no funcional, deberá ajustarse a
una serie de formatos sugeridos para su especificación. También será posible
emplear herramientas, como los casos de uso, para obtener información más
detallada en la especificación de requerimientos.

Página 105 de 129

Segundo Semestre
 BIBLIOGRAFÍA

BIBLIOGRAFÍA SUGERIDA

Bruegge, B. y Dutoit, A. H. (2002). Ingeniería de software orientada a objetos.

México: Pearson.
Joyanes, L. (2003). Fundamentos de programación: algoritmos, estructuras de
datos y objetos (3.ª ed.). Madrid / México: McGraw-Hill.
Pfleeger, S. L. (2002). Ingeniería de software: teoría y práctica. México: Prentice
Hall.
Piattini Velthuis, M. y García, F. (Coord.). (2003). Calidad en el desarrollo y
mantenimiento de software. México: Alfaomega / Ra-Ma.
Piattini Velthuis, M., Calvo-Manzano Villalón, J., Cervera Bravo, J. y Fernández
Sanz, L. (2003). Análisis y diseño de aplicaciones informáticas de gestión.
México: Alfaomega / Ra-Ma.
Pressman, R. S. (2002). Ingeniería de software: un enfoque práctico (5.ª ed.).
México / Madrid: McGraw-Hill.
Sommerville, I. (2001). Ingeniería de software (6.ª ed.). México: Pearson.
Weitzenfield, A. (2003). Ingeniería de software orientada a objetos con UML, Java
e Internet. México: Thomson.

Página 106 de 129

Segundo Semestre
 UNIDAD 4
VALIDACIÓN DE REQUERIMIENTOS
 OBJETIVO PARTICULAR
El alumno seleccionará los requerimientos que están alineados con las necesidades
del negocio.

TEMARIO DETALLADO
(28 horas)

4. Validación de requerimientos
4.1. Identificación de dependencias entre requerimientos
4.2. Validación de requerimientos contra objetivos de la organización, del
proyecto y del sistema
4.3. Control de cambios a los requerimientos

Página 108 de 129

Segundo Semestre
 INTRODUCCIÓN

La validación de requerimientos es un proceso muy similar al de análisis, con la

diferencia principal que el objetivo de la validación es revisar y seleccionar los
requerimientos completos que son útiles para el desarrollo del sistema. El proceso
de validación es crucial debido a que, si existe algún error en los requerimientos,
éstos pueden ocasionar costos excesivos que impacten en la construcción del
sistema.

Aunque resulte difícil demostrar que un conjunto de requerimientos es de utilidad

para el usuario, sin éstos el sistema no podrá ponerse en marcha. Pero para realizar
dicha demostración, será necesario validar los requerimientos. Para tal fin, se
tomarán en cuenta los siguientes aspectos, que estudiaremos en esta unidad:

1. Identificación de dependencias entre requerimientos. Buscaremos aquellos

requerimientos que se encuentren enlazados con otros y pudieran causar
problemas.
2. Validación de requerimientos contra objetivos de la organización. Se
verificará que los requerimientos establecidos sean acordes con lo que
buscan los clientes y adecuados para el sistema a desarrollar.
3. Control de cambios a los requerimientos. Se encargará de garantizar la
integridad de los requerimientos si es que alguno de ellos requiere
modificación.

Página 109 de 129

Segundo Semestre
 4.1. Identificación de dependencias
entre requerimientos

Una característica fundamental en la especificación de requerimientos es su

trazabilidad o rastreabilidad: se deben identificar todas las partes del sistema
relacionadas con un requisito. De manera general, todos los requerimientos serán
rastreables o trazables para poder mantener consistencia con el resto de los
requerimientos y elementos del sistema.

La trazabilidad proporciona esta información:

Origen. Quién
propuso el
requerimiento.

Relación con
otros elementos. Necesidad.
Dependencia. Razón de ser del
requerimiento.

Relación con otros

requerimientos.
Dependencia.

Figura 4.1 Información de trazabilidad

Elaboración propia

Página 110 de 129

Segundo Semestre
Las matrices de trazabilidad ayudan a establecer los puntos anteriores de manera
eficiente y controlada. Un tipo de matriz muy empleado para la trazabilidad es la
matriz “hacia adelante/hacia atrás”.

La matriz “hacia adelante” ayuda a enlazar los requisitos con las etapas de diseño
e implementación; la llamada “hacia atrás” vincula los requerimientos con sus
fuentes.

Formato de este tipo de matriz:

Tabla 4.1 Formato de matriz de trazabilidad hacia atrás/hacia adelante

Fuente: INTECO, 2008, p. 16.

Dentro de la matriz, se registran todos los requerimientos de la organización. Por

cada uno de éstos, se identifican los requerimientos de los usuarios, y de cada uno
de éstos se identifican los del sistema asociados, y así sucesivamente. Por ejemplo,
si la organización pide que el sistema entregue una consulta con las ventas del
último mes ordenadas por fecha y tipo de operación, este requerimiento se puede
asociar con los usuarios del departamento de ventas que solicitan a los
desarrolladores implementar un catálogo de tipo de operación que se despliegue
en forma de lista para hacer más eficiente la captura de los registros de ventas.

Página 111 de 129

Segundo Semestre
Para identificar la relación entre cada requerimiento, se emplea la matriz de
dependencia, ilustrada a continuación.

Requerimientos (A)
1 2 3 4 5
1 *
2 *

Requerimientos 3 * *
(B) 4 *
5 *

Tabla 4.2 Formato de matriz de dependencia

Fuente: INTECO, 2008, p. 17.

Los requerimientos (A) representan aquellos que dieron origen a las dependencias;
los requerimientos (B) dependen de otros requerimientos.

Por ejemplo, de la matriz anterior, podemos leer que los requerimientos (B) 2 y 5
dependen del requerimiento (A) 3, el 1 (B) del 2 (A), el 3 (B) del 1 (A) y del 4(A) y el
4 (B) del 5 (A).

La matriz ayuda a los desarrolladores a entender de mejor manera cómo se

relacionan los requerimientos, lo que permite un análisis más preciso al momento
de manejar los cambios en los mismos.

Página 112 de 129

Segundo Semestre
Un formato alternativo más simple de la matriz de dependencia es:

Requisito Depende de:

R1 R3, R4
R2 R5, R2
R3 R4, R5
R4 R2
R5 R1

Tabla 4.3 Formato alternativo de matriz de dependencia

Es importante que, una vez determinadas las matrices de trazabilidad, se elabore

un documento complementario al de especificación de requerimientos (SRS), un
manual de trazabilidad. Éste incluye las políticas de trazabilidad establecidas en el
desarrollo del sistema y toda la información sobre la trazabilidad de los
requerimientos (las políticas se fijan según los objetivos de la organización para la
cual se desarrollan el sistema y la forma de trabajo de los desarrolladores).

Algunos factores que influyen en el establecimiento de las políticas de trazabilidad:

 Número de requerimientos. Entre más requerimientos sean especificados,

mayor será la necesidad de establecer políticas formales de trazabilidad.
 Tiempo de vida estimado del producto. Entre mayor sea el tiempo de vida
proyectado del sistema o software, será necesario emplear políticas de
trazabilidad más comprensibles.
 Nivel de madurez de la organización. Entre más experiencia tenga la
organización, será más madura: la implementación de las políticas de
trazabilidad será más simple.

Página 113 de 129

Segundo Semestre
  Tamaño y estructura del equipo de desarrollo. Dependiendo de la diversidad
y número de integrantes del equipo de desarrollo, será necesario
implementar políticas de trazabilidad acordes con sus perfiles.
 Tipo de producto. Según el tipo de sistema a desarrollar, se emplearán
políticas de trazabilidad en correspondencia con él; es decir, entre mayor
importancia e impacto en las operaciones de la organización, las políticas
deberán ser más específicas e indicar los parámetros para realizar la
trazabilidad del requerimiento.

Algunas ventajas de manejar un manual de trazabilidad:

Facilidad para Información

localizar e de
identificar las trazabilidad
políticas de ordenada y
trazabilidad localizable.
establecidas
para el
proyecto.

Figura 4.2 Ventajas de manejar un manual de trazabilidad

El manual de trazabilidad, así como las matrices, deben actualizarse

constantemente, por ello es recomendable asignar a un responsable de dicha tarea.

Página 114 de 129

Segundo Semestre
 4.2. Validación de requerimientos
contra objetivos de la organización,
del proyecto y del sistema

A partir de los requerimientos adquiridos, es necesario realizar una comprobación

de su validez, haciendo una comparación con las descripciones iniciales y
verificando si el modelo seleccionado corresponde a lo solicitado.

La fase de validación de requerimientos suele darse a partir de una simulación que

permita comprobar que el modelo de sistema elegido responde a la forma que ha
solicitado el cliente. Otra manera de validar los requerimientos es verificar con el
cliente si el modelo es de su conveniencia. A veces, dependiendo del modelo de
solución empleado, será necesario construir prototipos con una funcionalidad similar
que se aproxime al resultado final.

La revisión de requisitos es uno de los métodos de validación más eficiente.

Mediante esta revisión, es posible:

Descubrir inconsistencias y defectos en los requisitos.

Disminuir los costos en la fase de desarrollo del sistema en alrededor del 30%.

Reducir los tiempos de la fase de pruebas hasta en un 50%.

Figura 4.3 Revisión de requisitos

Página 115 de 129

Segundo Semestre
El proceso de revisión de requisitos consiste, principalmente, en realizar reuniones
planificadas entre los clientes y desarrolladores para corroborar que los
requerimientos seleccionados poseen los atributos necesarios para garantizar la
calidad del sistema.

Como parte de los integrantes de las reuniones, además del cliente y el

desarrollador, conviene incluir a personas externas al proyecto con experiencia en
el manejo de requerimientos, para que la selección de éstos sea imparcial.

Las reuniones de revisión comprenden seis etapas principales:

Establecimiento del plan de revisión

Distribución de documentos para revisión
Preparación de la reunión.
Realización de la reunión
Identificación de
defectos

Figura 4.4 Etapas de la reunión de revisiones

1. Establecimiento del plan de revisión. Establecer las tareas a realizar en la

reunión, los participantes de la misma y la planificación temporal.

2. Distribución de documentos para revisión. El documento generado en las

especificaciones de requerimientos es el centro de la revisión, pero es necesario
complementar a los participantes con otros documentos que faciliten su
comprensión y análisis.

Página 116 de 129

Segundo Semestre
3. Preparación de la reunión. Se definen la logística de la reunión, tiempos y
formas de realizarla. Adicionalmente, cada participante revisará de forma
individual la documentación recibida para exponer las diferencias que
encuentren en los diversos requerimientos.

4. Realización de la reunión. Es la ejecución de lo planificado en el paso 3.

5. Identificación de defectos. Realizada la reunión, antes de finalizarla, es

deseable listar y especificar los defectos en los requerimientos identificados en
la revisión. La lista puede ser conformada a manera de tabla como se muestra
a continuación.

6. Correcciones de documentos. En esta fase, el desarrollador tiene que evaluar y

realizar los cambios convenientes, resultado del análisis obtenido en la reunión,
y notificar los cambios a los participantes para su aprobación.

No. de Defectos
Acciones recomendadas
requisito detectados
1 Error de estilo que Modificar el texto del requerimiento de tal forma
lleva a que diga algo como “El sistema deberá permitir
ambigüedad el registro de los fondos bibliográficos”.
2 Ídem Ídem.
11 Ambigüedad Precisar la duración de las reservas.
12 Concisión No se han identificado diferencias entre
profesores y alumnos a lo largo de la lista de
requisitos. Este requisito se deberá eliminar, ya
que no proporciona ningún tipo de información
relevante.
15 Realizabilidad El sistema no puede realizar automáticamente
los préstamos. Quizás se refiere a que debe
proporcionar el máximo de automatización.
Precisar, en este caso, o eliminar por irreal.

Página 117 de 129

Segundo Semestre
 17 Concisión Separar lo referido a libros prestados de lo
referido a libros reservados.

Tabla 4.4 Formato recomendado para listar defectos de requerimientos

Fuente: Validación de requisitos, UPM, 2011.

Durante la preparación y realización de la reunión, se aconseja emplear un listado

de revisión o requirements review checklist. Éste es un documento estándar
establecido en la norma IEEE-730-2002 para asegurar la calidad que se debe
generar a partir de la obtención de los requerimientos, para revisarlos y aprobarlos
en la fase de validación.

La lista de revisión de requerimientos30 debe contener una serie de preguntas para

su validación, las cuales se agruparán con base en los siguientes criterios (Criterio
de validación de requerimientos, 2010):

Fuente: Tbh creative:

http://2.bp.blogspot.com/-
a7Ajq9ViAF8/UGoNxhaf8RI/AAAAAAAAAdw/UvXwfhNGJxc/s1600/checklist.jpg

30Un ejemplo de listado de revisión de requerimientos se expone en: Choque David (2018). Lista de
chequeo requerimientos. Recuperado de: http://es.scribd.com/doc/55686224/Lista-de-Chequeo-
Requerimientos. 22/08/2018.

Página 118 de 129

Segundo Semestre
1. Necesario (determina si el requerimiento a validar es indispensable
para el desarrollo del sistema)
¿La omisión del
 ¿Es necesario el ¿Es clara la importancia
requerimiento provocaría
requerimiento para el del requerimiento dentro
una deficiencia en el
objetivo de la aplicación? de la organización?
sistema?

2. No ambiguo (determina si el requerimiento está claro tanto para

clientes como para desarrolladores, y evita repeticiones)

¿El requerimiento se ¿Está claramente ¿La redacción del

interpreta igual al ser leído requerimiento es simple y
definida la funcionalidad?
por más de una persona? clara?

3. Verificable (ayuda a determinar la fuente de origen

del requerimiento)
¿Existen soportes que ¿Se encuentra definido ¿Se puede hacer una
ayuden a comprender el un método de verificación trazabilidad del documento
requerimiento? para cada funcionalidad? hasta su origen?

Página 119 de 129

Segundo Semestre
 4. Completo (ayuda a determinar si se incluye todo aquello que se
espera que el sistema deba hacer)

¿Se encuentran
¿Están definidas las ¿Están definidas todas las
identificadas las
entradas y salidas? funcionalidades que se
funcionalidades que
¿Están definidos los necesitan?
involucran al requerimiento?
límites operativos de las ¿Están definidos los
¿Están definidas las
funcionalidades? requerimientos de prueba?
interfaces requeridas?

5. Correcto (permite determinar si el requerimiento ayuda a resolver una

necesidad real de la organización)

¿El documento se ¿En el requerimiento se

¿Están bien definidos los
encuentra libre de errores identifican casos de prueba
acrónimos?
ortográficos y gramaticales? o vivencias reales?

6. Priorizable (ayuda a determinar la importancia del requerimiento en

forma jerárquica)
¿Los requerimientos que
¿Se encuentra incluida la ¿Se estableció un orden están relacionados unos
prioridad de implementación jerárquico en la definición con otros se encuentran
del requerimiento? de los requerimientos? identificados con un nivel de
impacto o importancia?

Página 120 de 129

Segundo Semestre
 7. Viable (determina si el requerimiento se puede implementar)

¿Los requerimientos ¿Hay identificación de ¿Hay consistencia con

están dentro del ámbito del riesgos en los las políticas de la
sistema? requerimientos? organización del cliente?

8. Consistente (ayuda a definir si el requerimiento

no tiene contradicciones)

¿El requerimiento está

duplicado o en conflicto con
¿El esquema general es otro requerimiento?
¿El documento se consistente con los
encuentra bien organizado? requerimientos de alto ¿Las referencias o
nivel? relaciones con otros
requerimientos se
encuentran bien definidas?

Página 121 de 129

Segundo Semestre
 4.3. Control de cambios
a los requerimientos
El proceso de control o gestión de cambios a los requerimientos se aplica a cada
cambio propuesto en los requerimientos. Es un proceso formal que ayuda a tratar
los cambios consistente y controladamente.

Este proceso comprende tres etapas:

1. Análisis del problema y especificación del cambio. Comienza con la

identificación del problema en algún requerimiento o con la propuesta por parte
del cliente o el desarrollador para el cambio en un requerimiento. La propuesta
o problema se analiza para verificar su validez; luego, se entrega el resultado
del análisis a quien identificó el problema o solicitó el cambio.

2. Análisis del cambio y análisis de costos. Los efectos del cambio propuesto se
evalúan empleando la información de rastreo y el conocimiento general de los
requerimientos del sistema. El costo del cambio se determina en términos de la
modificación del documento de requerimientos (SRS) y con base en el impacto
en el diseño y la implementación del sistema. Realizado el análisis, se decide si
se debe continuar con el cambio.

3. Implementación del cambio. Si se continúa con el cambio en el requerimiento,

debe efectuarse en el documento de requerimientos y, de ser necesario, en el
diseño e implementación del sistema. El documento de requerimientos estará
organizado de tal forma que sea posible modificar su contenido sin tener que
redactar grandes apartados de él. Los cambios en el documento se realizan
minimizando las referencias externas y haciendo el documento tan modular

Página 122 de 129

Segundo Semestre
 como sea posible para permitir el cambio de alguna sección sin afectar otras
partes del documento.

Es importante poner atención en el control de cambios de los requerimientos, debido

a que se puede desfasar la especificación de los requerimientos y la implementación
del sistema.

Problema identificado o
solicitud de cambio

Análisis del problema y

especificación del cambio

Análisis del cambio y

cálculo de costos

Implementación
del
cambio

Requerimientos
revisados

Figura 4.5 Proceso de control de cambios en los requerimientos

Página 123 de 129

Segundo Semestre
 RESUMEN

La validación de requerimientos es una fase crucial en el desarrollo de los sistemas

de información. Desde el inicio del análisis del sistema, se recaban requerimientos
que, a la postre, se prueban y validan para determinar si son de utilidad.

El objetivo de la validación de requerimientos es detectar los requerimientos con

inconsistencias o errores, y que son de difícil implementación. Lo anterior será
registrado en un documento en forma de lista que permita a los desarrolladores
identificar y corregir esos requerimientos.

La primera fase de la validación comienza con el establecimiento de la dependencia

de los requerimientos, ya sea entre ellos o con otros elementos del sistema. Esto
se logra mediante el empleo de matrices de trazabilidad que ayudan a establecer
las relaciones existentes entre los mismos requerimientos y elementos en la fase
de diseño e implementación.

Definidas las relaciones, es necesario hacer una revisión conjunta con el cliente y,
de ser posible, con expertos en desarrollo de sistemas ajenos al proyecto. Esto con
la finalidad de revisar y verificar la validez de los requerimientos para que estén
acordes tanto con el proyecto como con las necesidades del cliente.

Con frecuencia, de la revisión de requerimientos se derivan cambios en los mismos.

Definir un control de cambios formal permitirá minimizar efectos en el diseño e
implementación del proyecto y sus costos.

Página 124 de 129

Segundo Semestre
 BIBLIOGRAFÍA

BIBLIOGRAFÍASUGERIDA

Bruegge, B. y Dutoit, A. H. (2002). Ingeniería de software orientada a objetos.

México: Pearson.
Joyanes, L. (2003). Fundamentos de programación: algoritmos, estructuras de
datos y objetos (3.ª ed.). Madrid / México: McGraw-Hill.
Pfleeger, S. L. (2002). Ingeniería de software: teoría y práctica. México: Prentice
Hall.
Piattini Velthuis, M. y García, F. (Coord.). (2003). Calidad en el desarrollo y
mantenimiento de software. México: Alfaomega / Ra-Ma.
Piattini Velthuis, M., Calvo-Manzano Villalón, J., Cervera Bravo, J. y Fernández
Sanz, L. (2003). Análisis y diseño de aplicaciones informáticas de gestión.
México: Alfaomega / Ra-Ma.
Pressman, Roger S. (2002). Ingeniería de software: un enfoque práctico (5.ª ed.).
México / Madrid: McGraw-Hill.
Sommerville, I. (2001). Ingeniería de software (6.ª ed.). México: Pearson.
Weitzenfield, A. (2003). Ingeniería de software orientada a objetos con UML, Java
e Internet. México: Thomson.

Página 125 de 129

Segundo Semestre
 REFERENCIAS BIBLIOGRÁFICAS
BIBLIOGRAFÍA SUGERIDA

Bruegge, B. y Dutoit Allen, H. (2002). Ingeniería de software orientada a objetos.

México: Pearson.
Durán Toro, A. (2000). Metodología para la elicitación de requisitos de sistemas de
software. Visualización previa: http://es.scribd.com/doc/49567897/15/Joint-
Application-Development. Recuperado el 9 de noviembre de 2012.
Ince, D. (1993). Ingeniería de software. México: Addison-Wesley.
Joyanes Aguilar, L. (2003). Fundamentos de programación: algoritmos, estructuras
de datos y objetos (3.ª ed.). Madrid / México: McGraw-Hill.
Kendall, K. (1990). Análisis de diseño de sistemas. México: Prentice Hall.
Larman, C. (1999). UML y patrones: introducción al análisis y diseño orientado a
objetos. México: Prentice-Hall.
Márquez Vite, J. M. (2002). Sistemas de información por computadora, metodología
de desarrollo. México: Trillas.
Meyer, B. (1999). Construcción de software orientado a objetos. Madrid: Prentice-
Hall.
Osorio Rojas, R. (2002). El cuestionario. Magister Educación, disponible en línea:
http://www.nodo50.org/sindpitagoras/Likert.htm. Recuperado el 8 de
octubre de 2012.
Pfleeger, S. L. (2002). Ingeniería de software: teoría y práctica. México: Prentice
Hall.
Piattini Velthuis, M. y García, F. (Coord.). (2003). Calidad en el desarrollo y
mantenimiento de software. México: Alfaomega / Ra-Ma.
Piattini Velthuis, M., Calvo-Manzano Villalón, J., Cervera Bravo, J. y Fernández
Sanz, L. (2003). Análisis y diseño de aplicaciones informáticas de gestión.
México: Alfaomega / Ra-Ma.

Página 126 de 129

Segundo Semestre
Pressman Roger, S. (2002). Ingeniería de software: un enfoque práctico (5.ª ed.).
México / Madrid: McGraw-Hill.
Rubio Liniers, M. C. (2004). El análisis documental: indización y resumen en bases
de datos especializadas. Disponible en línea:
http://eprints.rclis.org/6015/1/An%C3%A1lisis_documental_indizaci%C3%
B3n_y_resumen.pdf Recuperado el 9 de noviembre de 2012.
Senn, J. A. (S. f.). “Primera fase: Análisis”. Análisis y diseño de sistemas de
información. Disponible en línea: http://une-
senn.tripod.com/new_page_1.htm#Herramientas_para_determinar_requeri
mientos_de_sistemas. Recuperado el 20 de marzo de 2011.
Sommerville, I. (2001). Ingeniería de software (6.ª ed.). México: Pearson.
Weitzenfield, A. (2003). Ingeniería de software orientada a objetos con UML, Java
e Internet. México: Thomson.

BIBLIOGRAFÍA BÁSICA

Bisantz, A. M., Burns, C. M., & Fairbanks, R. J. (2015). Cognitive systems:

engineering in health care. Florida: CRC Press.

Fernández del Busto, R., Mata, G., & Vázquez, C. (2013). Análisis y diseño de
sistemas de control digital. México: McGraw Hill.

Flórez, H. A. (2014). Sistemas digitales: principios, análisis y diseño. Colombia:

Ediciones de la U.

Kendall, K. E., Kendall, J. E. & Romero, A. (2011). Análisis y diseño de sistemas.

México: Prentice Hall.

Pantaleo, G., Lis, L. (2015). Ingeniería de Software. México: Alfaomega.

Página 127 de 129

Segundo Semestre
 BIBLIOGRAFÍA COMPLEMENTARIA

Cantone, D. (2012). Administración de storage y backups. México: Alfaomega.

Flórez, H. A. (2014). Sistemas digitales: principios, análisis y diseño. Colombia:

Ediciones de la U.

Morfín, J. A. (2013). Sistemas digitales: una perspectiva de diseño. México:

Universidad Iberoamericana.

Página 128 de 129

Segundo Semestre
 Página 129 de 129
Segundo Semestre