Guía Didáctica Requisitos

ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
Informática
SEGUNDO
BIMESTRE
SOLUCIONARIO
Modalidad Abierta y a Distancia
BIBLIOGRÁFICAS
REFERENCIAS
Ingeniería de Requisitos
Texto-Guía
ANEXOS
4 créditos
Ciclo Titulación
6 ¡ Informática
La Universidad Católica de Loja
Facultad de Ingenieria y Arquitectura

ÍNDICE
PRELIMINARES
MODALIDAD ABIERTA Y A DISTANCIA
Facultad de Ingenierias y Arquitectura

Departamento de Ciencias de la Computación y Electrónica
BIMESTRE
PRIMER
Ingeniería de Requisitos
Texto-Guía
4 Créditos
SEGUNDO
BIMESTRE
Titulación Ciclo
SOLUCIONARIO
Informática VI
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS
Autor:
Manuel Sucunuta
La Universidad Católica de Loja

Asesoría virtual:
www.utpl.edu.ec
ÍNDICE
PRELIMINARES
Universidad Técnica Particular de Loja
BIMESTRE
PRIMER
INGENIERÍA DE REQUISITOS
Texto-Guía
Sucunuta España Manuel Eduardo
SEGUNDO
BIMESTRE
Diagramación y diseño digital:
Ediloja Cía. Ltda.

Telefax: 593-7-2611418.
SOLUCIONARIO
San Cayetano Alto s/n.
www.ediloja.com.ec
edilojacialtda@ediloja.com.ec
Loja-Ecuador
BIBLIOGRÁFICAS
REFERENCIAS
Primera edición
ISBN digital - 978-9942-25-153-4
Reconocimiento-NoComercial-CompartirIgual ANEXOS
4.0 Internacional (CC BY-NC-SA 4.0)
Usted acepta y acuerda estar obligado por los términos y condiciones de esta Licencia, por lo que, si existe el
incumplimiento de algunas de estas condiciones, no se autoriza el uso de ningún contenido.
Los contenidos de este trabajo están sujetos a una licencia internacional Creative Commons Reconocimiento-
NoComercial-CompartirIgual 4.0 (CC BY-NC-SA 4.0). Usted es libre de Compartir — copiar y redistribuir el material en
cualquier medio o formato. Adaptar — remezclar, transformar y construir a partir del material citando la fuente, bajo los
siguientes términos: Reconocimiento- debe dar crédito de manera adecuada, brindar un enlace a la licencia, e indicar si
se han realizado cambios. Puede hacerlo en cualquier forma razonable, pero no de forma tal que sugiera que usted o su
uso tienen el apoyo de la licenciante. No Comercial-no puede hacer uso del material con propósitos comerciales. Compartir
igual-Si remezcla, transforma o crea a partir del material, debe distribuir su contribución bajo la misma licencia del original.
No puede aplicar términos legales ni medidas tecnológicas que restrinjan legalmente a otras a hacer cualquier uso
permitido por la licencia. https://creativecommons.org/licenses/by-nc-sa/4.0/
30 de marzo, 2017
2. Índice
ÍNDICE
PRELIMINARES
2. Índice............................................................................................................................................................. 4
3. Introducción............................................................................................................................................. 7
4. Bibliografía............................................................................................................................................... 9
4.1. Básica..................................................................................................................................................................... 9
4.2. Complementaria............................................................................................................................................... 9
BIMESTRE
PRIMER
5. Orientaciones generales para el estudio.............................................................................. 11
6. Proceso de enseñanza – aprendizaje para el logro de competencias.............. 13
PRIMER BIMESTRE
SEGUNDO
BIMESTRE
6.1. Competencias genéricas de la UTPL........................................................................................................ 13
6.2. Planificación para el trabajo del alumno............................................................................................... 13
6.3. Sistema de evaluación de la asignatura (primer y segundo bimestres)................................. 16
6.4. Orientaciones específicas para el aprendizaje por competencias.............................................. 17
SOLUCIONARIO
UNIDAD 1. FUNDAMENTO DE INGENIERÍA DE REQUISITOS.......................................................... 17
1.1. Requisitos de software................................................................................................................................... 17
1.2. Ingeniería de requisitos................................................................................................................................. 19
1.3. Desarrollo y gestión de Requisitos............................................................................................................ 21
BIBLIOGRÁFICAS
1.4. Causas para establecer malos requisitos................................................................................................ 24
REFERENCIAS
1.5. Beneficios de un proceso de requisitos de alta calidad................................................................... 26
1.6. Buenas prácticas para la Ingeniería de Requisitos............................................................................ 27
1.7. Los requisitos funcionales y no funcionales.......................................................................................... 29
Autoevaluación 1 ................................................................................................................................ 32
UNIDAD 2. Interesados........................................................................................................................ 34
ANEXOS
2.1. Introducción........................................................................................................................................................ 34
2.2. Interesados.......................................................................................................................................................... 34
2.3. Análisis de interesados................................................................................................................................... 45
Autoevaluación 2 ................................................................................................................................ 49
UNIDAD 3. REQUISITOS DE NEGOCIO................................................................................................. 51

3.1. Caso práctico....................................................................................................................................................... 51
3.2. Definir los requisitos de negocio................................................................................................................ 53
3.3. Visión del producto y alcance del proyecto........................................................................................... 54
3.4. Técnicas para representar el alcance........................................................................................................ 58
3.5. Visión y alcance en proyectos ágiles......................................................................................................... 61
Autoevaluación 3 ................................................................................................................................ 63
UNIDAD 4. Obtención de requisitos................................................................................................. 65
4.1. Obtención............................................................................................................................................................. 65
ÍNDICE
4.2. Técnicas de Obtención de requisitos........................................................................................................ 66
4.3. Planificar la obtención del proyecto......................................................................................................... 76
4.4. Preparación para la obtención.................................................................................................................... 78
4.5. Realizar las actividades de obtención..................................................................................................... 80
PRELIMINARES
4.6. Seguimiento después de la obtención................................................................................................... 81
4.7. Clasificando el aporte de los clientes....................................................................................................... 81
Autoevaluación 4 ................................................................................................................................ 87
SEGUNDO BIMESTRE
BIMESTRE
PRIMER
6.5. Competencias genéricas de la UTPL........................................................................................................ 89
6.6. Planificación para el trabajo del alumno............................................................................................... 89
6.7. Orientaciones específicas para el aprendizaje por competencias............................................... 92
UNIDAD 5. ANÁLISIS DE REQUISITOS................................................................................................ 92
SEGUNDO
BIMESTRE
5.1. El análisis de requisitos................................................................................................................................... 92
5.2. El ciclo de análisis de requisitos.................................................................................................................. 93
5.3. Los modelos de análisis................................................................................................................................. 94
5.4. Herramientas de análisis de requisitos................................................................................................... 97
5.5. Los diagramas UML......................................................................................................................................... 112
SOLUCIONARIO
5.6. Entendiendo los requisitos de usuario.................................................................................................... 113
5.7. Caso de uso.......................................................................................................................................................... 115
5.8. Reglas de negocio............................................................................................................................................ 122
Autoevaluación 5 ................................................................................................................................ 131
BIBLIOGRÁFICAS
REFERENCIAS
UNIDAD 6. ESPECIFICACIÓN DE REQUISITOS................................................................................... 133
6.1. Documentando los requisitos..................................................................................................................... 133
6.2. La especificación de requisitos.................................................................................................................... 135
6.3. Etiquetado de requisitos............................................................................................................................... 136
6.4. La interfaz de usuario y el ERS.................................................................................................................... 138
6.5. Plantilla para especificar requisitos de software................................................................................ 139
6.6. Características de excelentes requisitos.................................................................................................. 147 ANEXOS
6.7. Directrices para la redacción de requisitos............................................................................................ 150

Autoevaluación 6 ................................................................................................................................ 156
UNIDAD 7. VALIDANDO LOS REQUISITOS......................................................................................... 158

7.1. Necesidad de validación................................................................................................................................ 158
7.2. Verificación y validación................................................................................................................................ 159
7.3. Revisión de los requisitos.............................................................................................................................. 160
7.4. Prototipos............................................................................................................................................................. 167
7.5. Probando los requisitos................................................................................................................................. 168
7.6. Validación de requisitos con criterios de aceptación......................................................................... 169
Autoevaluación 7 ................................................................................................................................ 173
UNIDAD 8. GESTIÓN DE REQUISITOS................................................................................................. 175
8.1. El proceso de gestión de requisitos........................................................................................................... 175
ÍNDICE
8.2. La línea base de los requisitos..................................................................................................................... 176
8.3. Control de versiones de requisitos............................................................................................................. 177
8.4. Atributos de requisito..................................................................................................................................... 178
8.5. Seguimiento al estado de los requisitos................................................................................................. 179
PRELIMINARES
Autoevaluación 8 ................................................................................................................................ 182
7. Solucionario.............................................................................................................................................. 184
8. Referencias bibliográficas.............................................................................................................. 192
9. Anexos........................................................................................................................................................... 193
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS
Texto-Guía: Ingeniería de Requisitos PRELIMINARES
3. Introducción
ÍNDICE
La asignatura de Ingeniería de Requisitos se imparte en el sexto ciclo de la titulación de Ingeniería en
Informática, de la Universidad Técnica Particular de Loja, modalidad de estudios Abierta y a Distancia. Es
un componente académico troncal de carrera y tiene una valoración de 4 créditos.
PRELIMINARES
Esta asignatura le ayudará a conocer sobre las actividades relacionadas con el proceso de desarrollo y
gestión de requisitos de software, permitiendo que pueda adquirir destrezas y habilidades en la obtención
de las necesidades de los interesados, en el uso modelos de análisis, en estrategias de especificación de
requisitos y en técnicas de validación de requisitos en un proyecto de desarrollo de software.
BIMESTRE
Considerando que la calidad de los proyectos de desarrollo de software depende en gran medida de
PRIMER
la calidad de las especificaciones de software, no importa la clase de proyecto que esté desarrollando,
ni tampoco si el proceso de desarrollo es ágil o pesado, si no se logra una correcta comprensión de los
requerimientos por parte de los analistas y se asegura que el cliente también los comprende, el producto
y el proyecto fallarán. Por lo tanto, el propósito de este componente es instruir a los estudiantes en las
técnicas, metodologías y estándares para descubrir y especificar requisitos basados en el proceso de
SEGUNDO
BIMESTRE
desarrollo y gestión de requisitos.
Al mismo tiempo se desarrollará un trabajo colaborativo para socializar los diferentes criterios sobre los
casos de estudio que se propondrán en el Entorno Virtual de Aprendizaje. El componente está formado
por ocho unidades, distribuidas en 4 para el primer bimestre y 4 para el segundo bimestre.
SOLUCIONARIO
En la primera unidad, se abordan los fundamentos teóricos de la Ingeniería de Requisitos, partiendo
de los niveles y categorías de requisitos, el proceso de ingeniería de requisitos, la importancia de la
ingeniería de requisitos en el contexto de la ingeniería de software y se finaliza con las buenas prácticas.
En la segunda unidad se analiza uno de los componentes principales en las actividades de especificación
BIBLIOGRÁFICAS
REFERENCIAS
de requisitos, los participantes que de acuerdo a la clasificación y análisis se los denomina interesados.
Se indica las principales funciones que tienen de cara al desarrollo del proyecto, como de las habilidades
que deben de tener para realmente ser aporte en los proyectos.
En la tercera unidad, podrá conocer cómo definir el visionamiento y alcance del proyecto, mediante la
aplicación de técnicas de obtención y modelos de representación de la información desde el punto de
vista del usuario, con el fin de que se pueda interactuar de forma directa.
ANEXOS
En la cuarta unidad, podrá conocer sobre las diferentes estrategias para realizar la actividad de obtención
de requisitos, con criterios debidamente organizados, lo que permitirá aprovechar de forma coherente
cada uno de los recursos y sobre todo interactuar de forma directa con los usuarios.
En el segundo bimestre, la unidad cinco y seis le permitirá conocer sobre los diferentes modelos de
análisis y la forma de documentar los requisitos de acuerdo a lineamientos de organización. Se aborda
los lineamientos para documentar caso de uso al detalle y la Especificación de requisitos de Software.
En la unidad siete, se finaliza el proceso de desarrollo de requisitos mediante el análisis de las estrategias
para validar requisitos, en base a las especificaciones realizadas.
Finalmente, en la unidad ocho se abordan los temas relacionados con la gestión de requisitos, como es:
el proceso, la línea base, control de cambios y seguimiento de los requisitos.
7 MODALIDAD ABIERTA Y A DISTANCIA

Estimado estudiante sea constante en el estudio ya que a través de esta asignatura podrá centrar las bases
para construir un sistema de calidad acorde a las necesidades reales de los usuarios. Es muy grato poder
ÍNDICE
compartir conocimientos y vivencias con ustedes a fin de que logren alcanzar los objetivos planteados.
¡Bienvenidos una vez más y éxitos en el ciclo académico!
PRELIMINARES
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS

4. Bibliografía
ÍNDICE
4.1. Básica
PRELIMINARES
Sucunuta, M. (2017). Ingeniería de Requisitos. Loja, Ecuador: UTPL.
Texto Guía elaborado para el estudio de la asignatura de Ingeniería de Requisitos en la titulación de

Ingeniería en Informática de la Modalidad Abierta y a Distancia de la Universidad Técnica Particular de
Loja. Se cubre el proceso de desarrollo de requisitos: Obtención, análisis, especificación y validación; así
como también aquellas actividades de gestión de requisitos. En cada uno de los temas que se abordan
BIMESTRE
PRIMER
se proponen cuestionarios y ejemplos que permiten la adecuada comprensión por parte del estudiante.
4.2. Complementaria
SEGUNDO
BIMESTRE
• Gottesdiener, E. (2005), The Software Requirements Memory Jogger. New york, United States: Goal
QPC Inc.
El autor presenta una guía de las principales actividades y elementos que permiten llevar a cabo
el desarrollo y gestión de requisitos; proporciona a cada miembro del equipo del proyecto las
SOLUCIONARIO
herramientas y técnicas para fomentar la comunicación entre las empresas y los equipos de
desarrollo sobre los requisitos necesarios para la producción de software con éxito.
• Lamsweerde, A. (2009). Requirements Engineering: from system goals to UML models to software
Specifications. Chichester, Inglaterra: Wiley.
BIBLIOGRÁFICAS
REFERENCIAS
En este libro en la primera parte da una visión general del proceso de desarrollo de requisitos, en
las partes siguientes se profundizan los temas relacionados tanto con el desarrollo como la gestión
de requisitos. Se da especial énfasis a modelos que permiten justificar el uso de los diferentes
modelos.
• Martín, J. y López, L. (2014). UML Práctico: Aprende UML paso a paso. New york, United States:
Amazon.
ANEXOS
El texto es de mucha ayuda, debido a que permite conocer sobre el modelado mediante UML,
específicamente para construir modelos de análisis que se utilizarán tanto para definir el alcance
del proyecto, como para especificar actividades al detalle mediante el uso de diagramas.
• Wiegers, K. y Beatty, J. (2013). Software Requirements. Best practices. Washington, United States:
Microsoft Press.
Texto muy bien estructurado, que define claramente las actividades de desarrollo y gestión de los
requisitos. Se ha considerado la estructura de éste texto para desarrollar el presente texto- guía.

• Robertson, S. y Robertson J. (2013) Mastering the requierements Process. Massachusetts, United

States: Addison Wesley.
ÍNDICE
Este texto en sus primeros capítulos presenta de forma general al proceso de desarrollo y gestión.
Posteriormente profundiza cada uno de los temas utilizando el modelo de Volere, un modelo que
es utilizado especialmente en el espacio europeo. A través del sitio web que propone el texto se
puede acceder a diverso recurso como es el caso de las plantillas y publicaciones adicionales.
PRELIMINARES
• Bourque, P. y Fairley, R. (2014). Guide to the Software Engineering Body of Knowledge, Version 3.0.
Recuperado de http://www.swebok.org
La guía SWEBOK (cuerpo de conocimiento de la ingeniería de software), describe el conocimiento

general que acepta la ingeniería de software. Consta de 15 áreas de conocimiento entre ellos la
“Ingeniería de requisitos”, que aporta con una descripción general de las actividades de desarrollo
BIMESTRE
PRIMER
y gestión de requisitos.
OCW (Recurso Educativo Abierto)
• García, F. J., Conde, M. Á., & Bravo, S. (2008). Ingeniería del Software, Introducción a la Ingeniería
de Requisitos. Recuperado de http://ocw.usal.es/ensenanzas-tecnicas/ingenieria-del-software/
SEGUNDO
BIMESTRE
contenidos/Tema3-IntroduccionalaIR-1pp.pdf
Este tema relacionado con los requisitos, presenta una panorámica de todos los temas que se
relacionan con el desarrollo y especificación de requisitos.
SOLUCIONARIO
• Ros J., Alvarez A. (2009). Fundamentos de Ingeniería del Software. Recuperado de http://ocw.um.es/
ingenierias/fundamentos-de-ingenieria-del-software/
Recurso Educativo Abierto que cubre todo el proceso de la ingeniería del software y de la ingeniería
de requisitos.
BIBLIOGRÁFICAS
REFERENCIAS
DIRECCIONES ELECTRÓNICAS:
• Carnegie Mellon University. (2017). Software Engineering Institute. Pittsburgh: United States.
Recuperado de http://www.sei.cmu.edu/.
Instituto de Ingeniería del Software, tiene como objetivo apoyar a las organizaciones a mejorar las
capacidades en ingeniería del software de tal forma que el desarrollo y adquisición del software
sea adeacuado, libre de defectos, dentro del presupuesto. Para lo cual brinda soluciones en la ANEXOS
adquisición, seguridad, desarrollo de software, manejo de procesos, riesgos y diseño de sistemas.
• Nasa Online Directives Information. (2017). Nodis Library. EEUU. Recuperado de nodis.hq.nasa.gov
Sitio donde se dan lineamientos sobre la Ingeniería de Requisitos de Software.
• Bredemeyer Consulting. (2016). Resources for Software and Systems Architects. Recuperado de
http://www.bredemeyer.com
Sitio que cuenta con una gran variedad de recursos en temas de arquitectura para las aplicaciones
software, siendo de gran ayuda para los arquitectos de aplicaciones a profundizar y comprender
su función en el desarrollo de los proyectos.

5. Orientaciones generales para el estudio
ÍNDICE
Estudiar a distancia es un reto que requiere esfuerzo, dedicación y sobre todo de organización, por ello
debe hacer de esta actividad un trabajo continuo y sistemático, organice su tiempo de manera que
pueda verdaderamente aprovechar los contenidos que se le están ofreciendo. Le sugerimos hacer vida
PRELIMINARES
esta frase, que, aunque le puede parecer trillada, es la que más se adapta a la realidad de las personas
que estudian a distancia: “No deje para mañana lo que puede y debe hacer hoy”.
Le proponemos algunas orientaciones que le servirán en su proceso de aprendizaje:
Materiales
BIMESTRE
PRIMER
Recuerde que los materiales con los que trabajará son este texto guía que le irá orientando sobre cómo
y qué temas estudiar, además contiene ejemplos, ejercicios y autoevaluaciones que le permitirán medir
su grado de comprensión y la necesidad de tutoría por parte del docente. Además, se podrá apoyar en
la bibliografía complementaria.
SEGUNDO
BIMESTRE
Para reforzar el proceso de aprendizaje usted tiene de un profesor-tutor que le guiará en el ciclo
académico; al cual podrá hacer las consultas que requiera en un horario que oportunamente se estará
publicando. Las tutorías las puede hacer mediante el EVA, correo electrónico o directamente a través de
la línea telefónica, así que aproveche esta alternativa que la UTPL pone a su disposición.
SOLUCIONARIO
Los trabajos a distancia: Son actividades teóricas y prácticas que acompañan a la guía didáctica de cada
una de las materias, le permiten aplicar y reforzar los conocimientos adquiridos mediante su desarrollo,
y debe enviarlos mediante el EVA. La entrega de estos trabajos es obligatoria y no recuperable, su
valoración es de 6 puntos; la misma que se compone de una parte objetiva, y una parte de ensayo, para
esto revise las evaluaciones a distancia que acompañan a esta guía en donde se especifica exactamente
las actividades que debe desarrollar.
BIBLIOGRÁFICAS
REFERENCIAS
¿Cómo estudiar?
Programe un horario de estudio diario; para esta asignatura es necesario que dedique al menos una hora
diaria de autoestudio.
Para ayudarse en el proceso de aprendizaje utilice las técnicas de estudio que más se adapten a su
manera de aprender: subrayado, resúmenes, cuadros sinópticos y trate, en lo posible, de estudiar en un ANEXOS
horario y ambiente adecuado.
Como una estrategia de aprendizaje le sugiero realice todas las autoevaluaciones y ejercicios que se
plantean en el presente texto-guía, ya que esto le permitirá poner en práctica los conocimientos teóricos
de la asignatura. No olvide que, si surge alguna inquietud con respecto a estos ejercicios, puede pedir
asesoría al profesor-tutor.
En este texto-guía por cada bimestre existe la “planificación del trabajo del alumno” en donde
especialmente se indica el tiempo que debe dedicar a la asignatura por cada tema que comprende el
plan de asignatura, esto le permitirá avanzar organizadamente en el estudio y no tener problemas de
acumulación de trabajo al final. Recuerde que esta es una asignatura troncal de carrera y por lo tanto el
tiempo a dedicarle debe ser el necesario.

Apoyo Tecnológico e Interactividad
Como parte del proceso de enseñanza se dispone del Entorno Virtual de Aprendizaje (EVA), de la
ÍNDICE
biblioteca virtual, repositorio de documentos (OCW), entre otros por lo que es fundamental que revise
continuamente estos recursos con el fin de ponerse al tanto de los materiales de su asignatura. Preste
especial interés al EVA ya que con este recurso el profesor-tutor publicará algunos casos y ejercicios
que le ayuden a reforzar los conocimientos, así como también de su participación ya sea en foros,
PRELIMINARES
cuestionarios y chat. Revise los recursos ROA, ya que el profesor tutor estará publicando presentaciones,
videos, archivos, etc., que tengan relación con la asignatura. Por lo que le animo a que ingrese de forma
periódica para que esté al tanto del avance del estudio de la asignatura.
Esperamos que todas y cada una de estas recomendaciones contribuyan al aprendizaje exitoso de esta
asignatura. Como ayuda gráfica a la presente guía se utilizan los siguiente focalizadores:
BIMESTRE
PRIMER
Figura Descripción
Importante
Se utiliza para dar realce cierto concepto y que debe poner especial interés en analizar
detenidamente lo que se especifica.
SEGUNDO
BIMESTRE
Duda
Son interrogantes que se plantean para aclarar los ciertos temas y dar un enfoque de análisis.
No es una actividad que debe responder, sino de reflexión.
SOLUCIONARIO
Actividad recomendada
Actividad que se plantea para reforzar los conocimientos y el estudiante pueda entender el
enfoque del tema
Cuestionario
BIBLIOGRÁFICAS
REFERENCIAS
Preguntas que se plantean al final de cada unidad como estrategia de aprendizaje, el
estudiante debe contestar y luego comparar con las respuestas que se encuentran al final
de la guía.
Buscar en la web
Actividad que se le plantea al estudiante para que busque en la web, se facilitará la dirección
ANEXOS
URL o los temas para que encuentre determinados recursos.

6. Proceso de enseñanza – aprendizaje para el logro de competencias
13
PRIMER BIMESTRE
6.1. Competencias genéricas de la UTPL
• Capacidad para organización y planificación del tiempo

Texto-Guía: Ingeniería de Requisitos
• Habilidades para buscar, procesar y analizar información procedente de fuentes diversas

• Capacidad para identificar, plantear y resolver problemas
6.2. Planificación para el trabajo del alumno
Competencias Competencias
Tiempo de
específicas de la específicas de la Contenidos Actividades de aprendizaje Indicadores de aprendizaje
dedicación
titulación asignatura
Definir, planificar Conoce la Unidad 1. Fundamentos de la ingeniería de • Leer comprensivamente la • Comprende la importancia de la Semana 1
y controlar importancia de la requisitos unidad 1 del texto guía. ingeniería de requisitos en el contexto
4 horas de
proyectos de TI Ingeniería de de desarrollo de proyectos de software.
1.1. Requisitos de software • Subrayar o separar lo más autoestudio
Requisitos en el
1.2. Ingeniería de requisitos importante. • Diferencias las actividades de desarrollo
proceso de 4 horas de
de requisitos con las actividades de
Desarrollo de 1.3. Desarrollo y gestión de Requisitos • Desarrollar la actividad interacción
gestión que se dan en un proyecto de
Software recomendada.
1.4. Causas para establecer malos requisitos software.
1.5. Beneficios de un proceso de requisitos • Responder a la autoevaluación 1.
• Comprende la importancia de un
de alta calidad • Iniciar con el desarrollo del proceso ordenado para la especificación
1.6. Buenas prácticas para la Ingeniería de trabajo a distancia de requisitos de software.
Requisitos • Interactuar en el EVA. • Analiza las buenas prácticas que se
1.7. Los requisitos funcionales y no recomiendan para lograr el éxito en los
PRIMER BIMESTRE
• Desarrollar el cuestionario de proyectos de software

funcionales refuerzo 1 en el EVA.

REFERENCIAS SEGUNDO PRIMER
ANEXOS SOLUCIONARIO PRELIMINARES ÍNDICE
BIBLIOGRÁFICAS BIMESTRE BIMESTRE
Tiempo de
dedicación
14
Identifica y asigna Unidad 2. Interesados • Leer comprensivamente la • Identifica y clasifica a los interesados del Semana 2
roles a los 2.1. Introducción unidad 2 del texto guía. producto
4 horas de
principales
2.2. Interesados • Subrayar o separar lo más • Reconoce las funciones que deben autoestudio
involucrados en el
importante. cumplir cada interesado en el desarrollo
desarrollo de un 2.3. Patrocinador 4 horas de
del proyecto
proyecto de • Desarrollar la actividad interacción
2.4. El analista de negocio
software recomendada. • Comprende la importancia del analista
2.5. El cliente de negocio en la definición y
• Responder a la autoevaluación 2.
2.6. El usuario especificación de requisitos de software
• Continuar con el desarrollo del
2.7. Otros interesados
trabajo a distancia
2.8. Análisis de interesados
• Interactuar en el EVA.
• Participar en el foro Académico.
• Desarrollar el cuestionario de
refuerzo 2 en el EVA.
Analizar Utiliza técnicas de Unidad 3. Requisitos de negocio • Leer comprensivamente la • Diferencia entre los requisitos de Semana 3 y
problemas de captura y 3.1. Caso práctico unidad 3 del texto guía. negocio, usuario y software 4
programación y especificación de
3.2. Definir los requisitos de negocio • Subrayar o separar lo más • Establece el visionamiento y alcance de 8 horas de
plantear requisitos en el
importante. un proyecto de desarrollo de software autoestudio
soluciones desarrollo de 3.3. Visión del producto y alcance del
mediante proyectos de proyecto • Desarrollar la actividad • Utiliza el modelo adecuado para 8 horas de
métodos software recomendada. representar el alcance del proyecto interacción
computacionales 3.4. Técnicas para representar el alcance
3.5. Visión y alcance en proyectos ágiles • Responder la autoevaluación 3.
trabajo a distancia
• Participar en el Chat académico
PRIMER BIMESTRE

Tiempo de
dedicación
15
Identifica la Unidad 4. Obtención de requisitos • Leer comprensivamente la • Identifica la técnica más adecuada para Semana 5 y
estrategia de 4.1. Obtención unidad 4 del texto guía. obtener información de los interesados 6
obtención de
4.2. Técnicas de obtención de requisitos • Subrayar o separar lo más • Reconoce el proceso para aplicar 8 horas de
información
importante. estrategias de obtención de requisitos autoestudio
adecuada que 4.3. Planificar la obtención
permita capturar los • Desarrollar la actividad • Analiza los aportes realizados por los 8 horas de
4.4. Preparación para la obtención
requisitos recomendada. interesados para definir los requisitos interacción
4.5. Realizar las actividades de obtención
4.6. Seguimiento
• Finalizar el desarrollo del trabajo
4.7. Clasificando el aporte de los clientes
a distancia y registrar en el EVA
Unidades 1 a la 4 • Revisar los contenidos como Semana 7 y

preparación para la evaluación 8
presencial
8 horas de
autoestudio
8 horas de
interacción
TOTAL DE 64
HORAS
PRIMER BIMESTRE

Texto-Guía: Ingeniería de Requisitos PRIMER BIMESTRE
6.3. Sistema de evaluación de la asignatura (primer y segundo bimestres)
ÍNDICE
Formas de evaluación 2. Heteroevaluación
Evaluación a Evaluación
distancia presencial
1. Autoevaluación *
3. Coevaluación
Interacción en el
PRELIMINARES
Parte de ensayo
Prueba objetiva
Parte objetiva
EVA***
Competencia: criterio
Comportamiento ético
BIMESTRE
PRIMER
Cumplimiento, puntualidad,
Actitudes
responsabilidad
Esfuerzo e interés en los trabajos
Respeto a las personas y a las normas
de comunicación
SEGUNDO
BIMESTRE
Creatividad e iniciativa
Habilidades
Contribución en el trabajo
colaborativo y de equipo
Presentación, orden y ortografía
SOLUCIONARIO
Emite juicios de valor
argumentadamente
Dominio del contenido
Conocimientos
Investigación (cita fuentes de

consulta)
Aporta con criterios y soluciones
BIBLIOGRÁFICAS
REFERENCIAS
Análisis y profundidad en el
desarrollo de temas
PORCENTAJE 10% 20% 30% 70%
puntos en cada
presenciales y en el
Estrategia de
aprendizaje
Actividades
en el EVA: 3
bimestre
Actividades
EVA
Puntaje 2 4 6 14
ANEXOS
TOTAL 20 puntos
Para aprobar el componente se requiere obtener un puntaje mínimo de 28/40 puntos, que equivale al 70%.
* Son estrategias de aprendizaje, no tienen calificación; pero debe responderlas con el fin de autocomprobar su
proceso de aprendizaje.
** Recuerde: que la evaluación a distancia del primero y segundo bimestre consta de dos partes: una objetiva y otra de
ensayo, debe desarrollarla y enviarla a través del EVA según las fechas establecidas.
*** Estrategias de aprendizaje opcionales y de tipo colaborativa: foro, chat y video colaboración con una valoración de
un punto cada una.
Señor estudiante:
Tenga presente que la finalidad de la valoración cualitativa es
principalmente formativa.

6.4. Orientaciones específicas para el aprendizaje por competencias.
ÍNDICE
UNIDAD 1. FUNDAMENTO DE INGENIERÍA DE REQUISITOS
PRELIMINARES
Estimado estudiante.
Iniciamos el estudio del componente académico de Ingeniería de Requisitos con los conceptos
fundamentales de los requisitos en el contexto del desarrollo y gestión de los sistemas de software, así
como la importancia de la Ingeniería de requisitos de software como área de la Ingeniería de Software.
BIMESTRE
En la actualidad la mayoría de proyectos de desarrollo de software enfrentan diversos problemas
PRIMER
que repercuten en el tiempo, gastos y características del software, por lo tanto, es necesario que se
canalicen de forma correcta las diferentes necesidades de los clientes y usuarios en lo que se denomina
la “Especificación de Requisitos de Software”, razón principal del componente.
SEGUNDO
1.1. Requisitos de software
BIMESTRE
Cuando un grupo de personas comienzan a discutir sobre requisitos, a menudo asoma el problema de
la terminología. Diferentes personas podrían describir una sencilla declaración como un requisito de
usuario, requisito de software, requisito de negocio, requisito funcional, requisito de sistema, requisito
SOLUCIONARIO
de producto, requisitos de proyecto, historia de usuario, característica o restricción. Los nombres que
utilizan para diversos entregables de los requisitos también varían, por lo tanto, esta diversidad de
entendimiento lleva a confusión y frustración.
Muchas décadas después de la invención de la programación de la computadora, profesionales de

software inician intensos debates acerca de lo que un “Requisito” es exactamente. A continuación, se
BIBLIOGRÁFICAS
REFERENCIAS
indican algunas definiciones que se consideran útiles.
“Los requisitos son una especificación de lo que podría ser implementado. Son descripciones de: cómo
el sistema podría comportarse o de las propiedades y atributos del sistema” (Sommerville y Sawyer,
1997, p.68).
Esta definición reconoce los diversos tipos de información que son referidos como “los requisitos”. Los
requisitos abarcan tanto la vista del usuario mediante el comportamiento externo del sistema, como la ANEXOS
vista del desarrollador de algunas características internas. Incluyen tanto el comportamiento del sistema
bajo condiciones específicas como las propiedades que hacen que el sistema sea el adecuado y talvez
agradable para su uso.
“Un requisito del software es una característica que debe exhibir para solucionar cierto problema del
mundo real. Por lo tanto, un requisito del software es una característica que debe exhibir el software
desarrollado o adaptado para solucionar un problema particular” (Bourque y Fairley, 2014, p.24).
El software que se desarrolla puede ser algo que ya está construido y que de acuerdo a los requisitos
puede implementarse en la organización, o construir algún producto nuevo de acuerdo a los requisitos
que se defina.

“Los requisitos son descripciones de las necesidades y propiedades de un producto que satisface las
necesidades del cliente” (Gottesdiener, 2005, p.1).
ÍNDICE
Los requisitos son declaraciones de lo que el sistema debe hacer, cómo debe comportarse, las
propiedades que debe presentar, las cualidades que debe poseer, así como las limitaciones que el
sistema y su desarrollo deben satisfacer. La IEEE1 define a un requisito como:
PRELIMINARES
(1) Condición o capacidad que necesita un usuario para resolver un problema o lograr un objetivo.
(2) Condición o capacidad que tiene que ser alcanzada o poseída por un sistema o componente de
un sistema para satisfacer un contrato, estándar, u otro documento impuesto formalmente. (3) Una
representación en forma de documento de una condición o capacidad como las expresadas en (1) o en
(2). (IEEE, 2002, p.12)
Los requisitos de software incluyen la dimensión de tiempo. Pueden estar en tiempo presente
BIMESTRE
PRIMER
describiendo las capacidades del sistema actual, o podrían ser a corto plazo (alta prioridad), medio plazo
(prioridad media), o futuro hipotético (baja prioridad). Pueden estar en tiempo pasado refiriéndose a
necesidades que estaban antes especificadas y luego desechadas.
Debido a que existen diferentes tipos de requisitos de información, es necesario un conjunto coherente
de adjetivos para modificar el sobrecargado término “requisito”. En la tabla 1 se describen de forma
SEGUNDO
BIMESTRE
general algunos de los términos comúnmente utilizados en el dominio de los requisitos.
Tabla 1.
Términos asociados a los requisitos
SOLUCIONARIO
Término Definición
Representan los objetivos de alto nivel de la organización o del cliente que

requiere el sistema. Los requerimientos de negocio típicamente provienen del
patrocinador principal del proyecto, el cliente, el administrador de los usuarios
actual o el departamento de mercadotecnia. El documento donde se registran los
Requerimientos de negocio
BIBLIOGRÁFICAS
REFERENCIAS
Requerimientos de Negocio es conocido como:
•• Visión y Alcance
•• Project Charter
•• Documento de requerimientos de mercado.
Incluyen políticas corporativas, regulaciones de gobierno, estándares industriales,
prácticas contables y algoritmos computacionales. Estas reglas no son en sí
Reglas de negocio
requerimientos de software porque estás existen fuera de los límites de cualquier
ANEXOS
especificación del sistema de software.
Es una restricción que se impone a las opciones disponibles para el desarrollador
Constraint
en el diseño y construcción de un producto.
Requerimiento de interfaz Descripción de una conexión entre un sistema software y un usuario, otro sistema
externa software, o un dispositivo hardware.
Una o más capacidades lógicamente relacionadas que proporcionan valor a un
Característica
usuario y que son descritas por un conjunto de requisitos funcionales.
Es una descripción del comportamiento que un sistema exhibirá en condiciones
Requisito funcional
específicas.
Es una descripción de una propiedad o característica que un sistema debe exhibir
Requisito no funcional
o una restricción que debe respetar.
Un tipo de requisito no funcional que describe un servicio o ejecuta la característica
Atributos de calidad
de un producto.
1 Instituto de Ingenieros Eléctricos y Electrónicos

Término Definición
ÍNDICE
Un requisito de alto nivel para un producto que contiene múltiples sistemas, que
Requisitos del sistema
podría ser todo el software o software y hardware.
Una meta o tarea específica de usuario que puede ejecutar con un sistema o un
Requisitos de usuario
atributo del producto.
PRELIMINARES
Una vez definidos algunos términos relacionados con los requisitos se procederá a analizar los niveles
de los requisitos; incluyen tres niveles distintos: Requisitos de negocio, requisitos de usuario y requisitos
funcionales, adicionalmente cada sistema tiene una variedad de requisitos no funcionales. En la figura
1 se presenta un modelo con los diferentes tipos de requisitos. Este modelo no es completo, pero
proporciona un esquema útil para organizar el conocimiento de los requisitos que se encontrará.
BIMESTRE
PRIMER
Requisitos de
Negocio Reglas de Negocio
Documento de Visión y Alcance
SEGUNDO
BIMESTRE
Requisitos de Atributos de Calidad
Usuario
SOLUCIONARIO
Documento de Requisitos de Usuario
Interfaces e
Externas Restricciones
Requisitos de Requisitos
Sistema Funcionales
BIBLIOGRÁFICAS
REFERENCIAS
Especificación de Requisitos de Software
Figura 1. Relación entre los diferentes tipos de requisitos

Fuente: Wiegers y Beatty (2013).
Los óvalos de la figura 1, representan tipos de requisitos y los rectángulos indican documentos en los que ANEXOS
almacenará la información. Las flechas sólidas indican que un cierto tipo de información normalmente se
almacena en el documento indicado (Las reglas de negocio y los requisitos del sistema se almacenan por
separado de los requisitos de software, como en un catálogo de reglas de negocio o una especificación
de requisitos del sistema, respectivamente). Las flechas de puntos indican que un tipo de información es
el origen o influye en otro tipo de requisito.
En las secciones siguientes se detallarán los diferentes tipos de requisitos que se identifican al desarrollar
el proyecto de software.
1.2. Ingeniería de requisitos
Para liberar un producto de software de forma satisfactoria, se requiere: desarrollar, documentar y validar
los requisitos de software. Comprender adecuadamente los requisitos le permitirá “empezar con lo que

realmente tiene en mente” y lo fundamental para lograr el éxito en la implementación del software.
Después de todo, el propósito del desarrollo del software es satisfacer las necesidades del usuario, y
ÍNDICE
estas necesidades son precisamente las que definen los requisitos.
El precio es sumamente alto cuando no se definen los requisitos o no se está haciendo bien. Requisitos mal
definidos resultan en “Requisitos defectuosos”, que pueden ser por requisitos incorrectos, incompletos,
faltantes o contradictorios.
PRELIMINARES
Los requisitos defectuosos pueden resultar en:
• Costos excesivos
• Trabajo costoso
• Calidad pobre
BIMESTRE
PRIMER
• Entrega tardía
• Clientes insatisfechos
• Miembros del equipo agotados y desmoralizados.
La corrección de los requisitos defectuosos representa casi la mitad del costo del desarrollo del proyecto
SEGUNDO
y es el tipo de error más caro del desarrollo para solucionarlo.
BIMESTRE
Los requisitos defectuosos se multiplican en número y gravedad propagándose a través de múltiples
componentes en el diseño, la codificación y las pruebas. Como resultado se tiene que un excesivo trabajo,
con costos de diez a cien veces más para encontrar el defecto luego en el desarrollo. Para reducir el alto
riesgo de fracaso de los proyectos software y grandes costos asociados a los requisitos defectuosos,
SOLUCIONARIO
deben definir requisitos apropiados tempranamente en el proceso de desarrollo de software.
Al construir un proyecto de desarrollo de software, el objetivo como ingeniería de requisitos es investigar

el contexto del problema. Esto nos lleva a considerar dos versiones del mismo sistema:
• El “system-as-is”. El sistema cómo es, antes del desarrollo del mismo. Se denominará como “sistema
BIBLIOGRÁFICAS
REFERENCIAS
actual”
• El “system-to-be”. El sistema a hacer, cuando se pueda construir y operar. Se denominará el sistema
futuro.
Considere que siempre hay un sistema actual, por ejemplo, un proyecto para desarrollar un software de
control para un reproductor MP4. El sistema actual, es el sistema convencional que le permite escuchar
su música favorita en un subsistema de alta fidelidad. El sistema futuro está destinado a simular las ANEXOS
condiciones del sistema actual y que convenientemente provea en cualquier lugar y hora acceso a su
música.
Para asegurar que una solución software resuelva satisfactoriamente un problema particular, se debe
primeramente entender y definir qué problema necesita ser solucionado. Esto parece de sentido
común a primera vista. Sin embargo, como ya se verá, averiguar el problema correcto puede ser
sorprendentemente difícil. Se necesita descubrir, entender, formular, analizar y acordar sobre qué (what)
problema debe ser resuelto, por qué (why) tal problema necesita ser resuelto y quien (who) podrían ser
el responsable de solucionar el problema. (Gottesdiener, 2005)

ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
Figura 2. Relación entre los diferentes tipos de requisitos
Fuente: Lamsweerde (2009)
A continuación, se detalla cada una de las dimensiones que se indican en la figura 2.
SEGUNDO
La dimensión Why
BIMESTRE
La razón fundamental para que una nueva versión de un sistema deba hacerse, explícitamente se lo
realizará en términos de los objetivos a ser satisfechos por ésta. Tales objetivos deben ser identificados
con respecto a las limitaciones del sistema actual y de las oportunidades a ser explotadas. Esto requiere
de un análisis cuidadoso.
SOLUCIONARIO
La dimensión What
Esta dimensión de especificación de requisitos está preocupada por los “Servicios Funcionales” que
el sistema a futuro podría proveer para satisfacer los objetivos identificados a través de la dimensión
Why. Tales servicios a menudo se basan en especificaciones supuestas del sistema para trabajar
BIBLIOGRÁFICAS
REFERENCIAS
adecuadamente. Ellos necesitan reunir restricciones relacionadas al funcionamiento, seguridad,
usabilidad, interoperabilidad, costo entre otros. Algunos de los servicios podrían ser implementados por
el software futuro (software-to-be) en tanto que otros pueden ser realizados a través procedimientos
manuales u operaciones de dispositivo.
La dimensión Who
ANEXOS
Esta dimensión de Especificación de Requisitos direcciona la asignación de responsabilidades para
lograr el objetivo, servicios y restricciones a través de los componentes del sistema futuro – humanos,
dispositivos o software. Las decisiones acerca de la asignación de responsabilidades son a menudo
críticas; un importante objetivo, servicio o restricción podría no ser alcanzado si la responsabilidad del
componente del sistema deja de comportarse como corresponde.
1.3. Desarrollo y gestión de Requisitos
La confusión del término “requisitos” se extiende también a cómo llamar a toda esta disciplina. Algunos
autores llaman a todo este dominio como la “Ingeniería de Requisitos”, pero otros se refieren como la
gestión de requisitos y otros se refieren a estas actividades como un subconjunto de un dominio mucho
más amplio de análisis de negocio.

ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
Figura 3. Disciplinas de la Ingeniería de requisitos de software
Fuente: Wiegers y Beatty (2013)
En concreto la Ingeniería de requisitos se divide en el desarrollo de requisitos y la gestión de requisitos
SEGUNDO
BIMESTRE
tal como se indica en la figura 3 independientemente del ciclo de vida de desarrollo del proyecto que
esté siguiendo, esto es: cascada pura, incremental, interactivo, ágil o algún híbrido.
Adicional a ésta clasificación en el anexo 1, se indican tres propuestas de las actividades de desarrollo y
gestión de requisitos propuestas por: SWEBOK (2014), Gottesdiener (2004) y Volere (2012).
SOLUCIONARIO
1.3.1. Desarrollo de Requisitos
Como se puede observar en la figura 3, el desarrollo de requisitos se subdivide en: Obtención, Análisis,
Especificación y Validación. Estas sub-disciplinas incluyen todas las actividades relacionadas con
exploración, evaluación, documentación y confirmación de los requisitos para un producto.
BIBLIOGRÁFICAS
REFERENCIAS
1. Obtención
La obtención o elicitación abarca todas las actividades involucradas con el descubrimiento de los
requisitos, tales como: entrevistas, talleres, análisis de documentos, creación de prototipos, etc., las
acciones clave son:
• Identificar las clases de usuarios y otros interesados del producto. ANEXOS

• Comprender las tareas y objetivos del usuario y los objetivos de negocio con la que estas tareas
se alinean.
• Aprender sobre el ambiente en el que se utilizará el nuevo producto.
• Trabajar con individuos que representan a cada clase de usuario para entender sus necesidades de
funcionalidad y sus expectativas de calidad.
2. Análisis
El análisis de requisitos implica llegar a una comprensión más efectiva y precisa de cada requisito y
representando categorías de requisitos de múltiples maneras. Las siguientes son las principales
actividades:

• Analizar la información recibida de los usuarios para distinguir sus objetivos de trabajo de los
requisitos funcionales, las expectativas de calidad, las reglas de negocio, las soluciones sugeridas,
ÍNDICE
y otra información.
• Descomposición de requisitos de alto nivel a un nivel de detalle apropiado.
• Derivación de los requisitos funcionales de otros requisitos de información.
• Comprensión de la importancia relativa de los atributos de calidad.
PRELIMINARES
• Distribuir los requisitos a los componentes de software definidos en la arquitectura del sistema.
• Negociar las prioridades de implementación.
• Identificar las carencias en requisitos o requisitos innecesarios que se relacionan con el alcance
definido.
3. Especificación
BIMESTRE
PRIMER
La especificación de requisitos consiste en representar y almacenar el conocimiento de los requisitos
recogidos de una manera persistente y bien organizada. La actividad principal es:
• Traducir el conjunto de necesidades de usuario escribiendo requisitos y diagramas apropiados

para comprender, revisar y utilizar por un público específico.
SEGUNDO
BIMESTRE
4. Validación
La validación confirma que se dispone del conjunto de requisitos de información correctos que permitirá
a los desarrolladores crear una solución que satisfaga los objetivos del negocio. Las actividades centrales
SOLUCIONARIO
son:
• Revisar los requisitos documentados para corregir algún problema antes que el grupo de desarrollo
los acepte.
• Desarrollar pruebas y criterios de aceptación para confirmar que un producto basado en
BIBLIOGRÁFICAS
requerimientos podría satisfacer las necesidades del cliente y lograr los objetivos del negocio.
REFERENCIAS
Importante
Estimado estudiante, recuerde que nunca se va a lograr obtener requisitos perfectos.
Desde un punto de vista práctico, el objetivo del desarrollo de requisitos es acumular
un conocimiento compartido de los requisitos lo suficientemente bueno para la
construcción del sistema ya sea de una parte o la totalidad. El principal riesgo a evitar
es el excesivo trabajo no planificado debido a que el equipo no tiene el suficiente
conocimiento del trabajo a desarrollar antes del diseño y construcción. ANEXOS
1.3.2. Gestión de Requisitos
La gestión de requisitos es un conjunto de actividades que le permiten al equipo de desarrollo identificar,

controlar y dar seguimiento a los requisitos y los cambios en cualquier momento. Implica gestionar los
cambios de requisitos y mantener la consistencia entre los requisitos y otros productos de trabajo del
proyecto. Las actividades de gestión de requisitos son las siguientes:
• Definir la línea base de los requisitos: un instante en el tiempo que representa un acuerdo revisado
y aprobado de un conjunto de requisitos funcionales y no funcionales, muchas veces está dado
por el lanzamiento de un producto específico o iteración de desarrollo.
• Evaluar el impacto de cambio a los requisitos propuestos e incorporar los cambios aprobados en
el proyecto de una manera controlada.

• Mantener planes del proyecto actualizados con los requisitos a medida que éstos evolucionan.
• Negociar los nuevos compromisos basados en la estimación del impacto de los cambios en los
ÍNDICE
requisitos.
• Definir las relaciones y dependencias que existen entre los requisitos.
• Seguimiento individual a los requisitos con su correspondiente diseño, código fuente y pruebas.
• Seguimiento del estado de los requisitos y actividad de cambio a todo el proyecto.
PRELIMINARES
El objetivo de la gestión de requisitos no es reprimir o hacer difícil el cambio, sino la de anticiparse y
adaptarse a los cambios reales con el fin de minimizar su impacto perjudicial en el proyecto.
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
Figura 4. El límite entre el desarrollo y gestión de requisitos
BIBLIOGRÁFICAS
REFERENCIAS
Buscar en la web
Estimado estudiante, consulte en el sitio http://www.computer.org (Bourque & Fairley, 2014)
acerca de la Guía del Cuerpo de Conocimiento de la Ingeniería de Software (SWEBOK).
Descargue el documento en PDF y ubique el capítulo relacionado a la Ingeniería de Requisitos.
Analice detenidamente las actividades que se recomienda tanto para el desarrollo de los
requisitos como las actividades de gestión.
ANEXOS
1.4. Causas para establecer malos requisitos
La principal causa del problema de los requisitos es la reelaboración, cuando se está realizando el
desarrollo o después de la liberación. Es hacer de nuevo algo que se creía ya estaba hecho. La reelaboración
a menudo consume del 30 al 50 por ciento del costo total del desarrollo y los errores de los requisitos
pueden representar entre el 70 al 85 por ciento del costo de la reelaboración.
Algunas reelaboraciones agregan valor y mejoras al producto, pero de forma excesiva es derrochador
y frustrante. El costo de corregir un defecto que se determina muy tarde en el proyecto es muy costoso
con respecto a solucionarlo poco después de su creación.
Las deficiencias en la práctica de los requisitos plantean muchos riesgos para el éxito del proyecto,
dónde el éxito significa entregar un producto que satisface las expectativas funcionales y de calidad del

usuario a un costo y plazo acordados. A continuación, se describen algunos de los riesgos de requisitos
más comunes.
ÍNDICE
• Insuficiente involucramiento del usuario
Los clientes a menudo no entienden por qué es tan importante destinar un gran esfuerzo para obtener
requisitos de calidad. Los desarrolladores pueden no ver la necesidad de la participación de los usuarios,
PRELIMINARES
debido a que piensan que ya entienden lo que los usuarios necesitan. En algunos casos es difícil acceder
a personas que realmente utilizarán el producto y aquellos que los reemplazan no siempre entienden lo
que los usuarios realmente necesitan. La participación insuficiente de los usuarios conduce a requisitos
de última hora que generan reelaboración y retrasan la finalización.
• Planificación incorrecta
BIMESTRE
PRIMER
Por ejemplo, si algún interesado manifiesta “Aquí está mi idea para un nuevo producto; ¿Cuándo se
terminará?” Nadie podrá responder a esta pregunta hasta que se conozca más sobre el problema que se
está discutiendo. Los requisitos imprecisos y mal entendidos conducen a estimaciones excesivamente
optimistas, que ocasionan un excesivo sobrecosto. Los principales factores que contribuyen a la mala
estimación de costos del software son: los cambios frecuentes en los requisitos, los requisitos faltantes,
la comunicación insuficiente con los usuarios, la escasa especificación de requisitos y el insuficiente
SEGUNDO
BIMESTRE
análisis de requerimientos. La estimación del esfuerzo del proyecto y la duración basada en los requisitos
significa que usted necesita saber algo sobre el tamaño de sus necesidades y la productividad del equipo
de desarrollo.
• La expansión de los requisitos de usuario
SOLUCIONARIO
A medida que evoluciona el desarrollo de los requisitos, los proyectos a menudo exceden los horarios
y presupuestos planificados. Para manejar la expansión del alcance, es necesario empezar con una
declaración clara de los objetivos del negocio del proyecto, la visión estratégica, el alcance, las limitaciones
y los criterios de éxito. Todas las nuevas funciones propuestas o requisitos de cambio deberán evaluarse
BIBLIOGRÁFICAS
con respecto a ésta referencia. En vista que normalmente los requisitos cambiarán y crecerán, el gerente
REFERENCIAS
del proyecto deberá desarrollar planes de contingencia que no descarrilen el calendario.
• Requisitos ambiguos
Un sinónimo de ambigüedad en los requisitos es que un lector puede interpretar una declaración de varias
formas. Otro síntoma es que múltiples lectores de requisitos lleguen a tener diferente comprensión de
ANEXOS
lo que lo que realmente significa. La ambigüedad conduce a diferentes expectativas de los interesados,
quienes a su vez se ven sorprendidos con lo que se entrega. Los requisitos ambiguos provocan un tiempo
perdido cuando los desarrolladores implementan una solución para el problema incorrecto.
• Gold plating
El término Gold plating, hace referencia a una mala práctica que se da cuando un desarrollador añade
funcionalidades que no estaban en la especificación de requisitos, pero que el desarrollador cree
que lo va a necesitar. Si los usuarios no lo necesitan o utilizan esta funcionalidad, el tiempo dedicado
a su implementación es en vano. En lugar de simplemente implementar nuevas características, los
desarrolladores y analistas de negocio deberían presentar a los interesados ideas creativas y ponerlas a
consideración. Los desarrolladores deben preocuparse por la flexibilidad y simplicidad, sin ir más allá de
lo que los interesados han aprobado.

Los clientes a veces solicitan ciertas características o elaboración de interfaces de usuario que parecen
atractivas, pero añaden poco valor al producto. Todo lo que se construye cuesta tiempo y dinero por lo
ÍNDICE
que necesita maximizar el valor entregado. Para reducir la amenaza del Gold plating, es necesario rastrear
cada actividad de la funcionalidad de nuevo con su origen y sus necesidades de negocio para que todos
conozcan de porqué está incluido. Asegúrese de que lo que está especificado y desarrollándose se
encuentra dentro del alcance del proyecto.
PRELIMINARES
• Omitir interesados
La mayoría de los productos tienen varios grupos de usuarios que podrían utilizar diferentes subconjuntos
de características, tener diferentes frecuencias de uso o tener diferentes niveles de experiencia. Si no
identifica las clases de usuario importantes para su producto desde el principio, no se cumplirán algunas
de las necesidades del usuario. Después de identificar todas las clases de usuario, asegúrese de que
cada una de ellas tenga voz. Además de los usuarios obvios, piense en el personal de mantenimiento y
BIMESTRE
PRIMER
en el de soporte técnico que tienen sus propios requisitos, tanto funcionales como no funcionales. Las
personas que tienen que convertir datos de un sistema heredado tendrán requisitos de transición que
no afectan al software del producto final, pero que sin duda influyen en el éxito de la solución. Es posible
que haya Interesados que ni siquiera saben que el proyecto existe, como las agencias gubernamentales
que exigen normas que afectan su sistema, pero necesita saber sobre ellas y su influencia en el proyecto.
SEGUNDO
BIMESTRE
1.5. Beneficios de un proceso de requisitos de alta calidad
Las personas consideran equivocadamente que el tiempo dedicado a discutir sobre los requisitos
SOLUCIONARIO
simplemente retrasa la entrega y que no hay retorno de inversión, sin embargo, en la actualidad la
inversión en buenos requisitos será siempre más beneficioso.
Especificar requisitos conlleva un trabajo colaborativo que involucra a los interesados a lo largo del
desarrollo del proyecto. La obtención de requisitos permite que el equipo de desarrollo tenga una
mejor comprensión de la comunidad de usuarios y de mercado, un factor crítico de éxito. Al involucrar
BIBLIOGRÁFICAS
REFERENCIAS
al usuario se reduce la diferencia de expectativas entre lo que el cliente realmente necesita y lo que el
desarrollador entrega.
Nadie puede prometer un retorno de inversión utilizando sofisticadas y sonadas prácticas de requisitos,
más bien se podría utilizar un proceso de pensamiento analítico para imaginar cómo mejorando los
requisitos se podría ayudar a los equipos. El costo de mejores requisitos incluye el desarrollo de nuevos
procedimientos, plantillas de documentos, entrenamiento del equipo y compra de herramientas. La
mayor inversión es el tiempo que gastan los equipos del proyecto en tareas de ingeniería de requisitos. ANEXOS
El potencial beneficio incluye:
• Menos defectos en los requisitos y en la entrega del producto.

• Reducción de rehacer el desarrollo.
• Fácil desarrollo y entrega.
• Reducir características innecesarias e inútiles.
• Bajo costo en las mejoras.
• Menos problemas de comunicación.
• Reducción del arrastre en el alcance.
• Reducción del caos en el proyecto.
• Satisfacción de los altos ejecutivos y miembros del equipo.
• El producto hace lo que se supone debe hacer.

Como puede ver, existen excelentes beneficios cuando se desarrollan buenos requisitos, de allí lo
importante de seguir un proceso ordenado realizando las actividades que lo recomienda el proceso
ÍNDICE
tanto de desarrollo como de gestión de requisitos.
1.6. Buenas prácticas para la Ingeniería de Requisitos
PRELIMINARES
Cada profesional de software necesita de un conjunto de técnicas que le permita abordar cada desafío en
el proyecto. Un profesional que carece de este conjunto de técnicas se ve obligado a inventar un enfoque
basado en lo que parezca razonable en ese momento, esto rara vez producen buenos resultados. Algunas
personas abogan por metodologías de desarrollo específico o conjunto de técnicas empaquetadas que
pretenden proporcionar soluciones integrales a los desafíos del proyecto, sin embargo, se considera que
es más eficaz identificar y aplicar las mejores prácticas de la industria. El enfoque de las mejores prácticas
BIMESTRE
dispone de un kit de herramientas software que con una variedad de técnicas pueden aplicar a una
PRIMER
variedad de problemas. (Wiegers y Beatty, 2013).
La idea de mejores prácticas es debatible: ¿quien decide qué es “mejor” y en base a qué? Una forma es la
de convocar a un grupo de expertos de la industria para analizar proyectos de muchas organizaciones, y
que en base a consensos sobre actividades que producen buenos resultados etiquetarlas como mejores
SEGUNDO
BIMESTRE
prácticas.
A continuación, se indica las buenas prácticas agrupadas en siete grupos (4 de desarrollo y 3 de gestión)
(Wiegers y Beatty, 2013).
SOLUCIONARIO
Obtención
• Definir la visión y el alcance

• Identificar las clases de usuario
• Seleccionar al “product champions”
• Dirigir los grupos focales
BIBLIOGRÁFICAS
REFERENCIAS
• Identificar requisitos de usuario
• Identificar los eventos y las respuestas del sistema
• Mantener entrevistas
• Mantener talleres de facilitación
• Observar a los usuarios realizando su trabajo
• Distribuir cuestionarios ANEXOS
• Realizar el documento de análisis
• Examinar los reportes de problemas
• Reusar requisitos existentes
Análisis
• Modelar el entorno de la aplicación

• Crear prototipos
• Analizar la factibilidad
• Priorizar los requisitos
• Crear el diccionario de datos
• Modelar los requisitos

• Analizar las interfaces

• Distribuir los requisitos a los subsistemas
ÍNDICE
Especificación
• Adoptar una plantilla para documentos los requisitos

• Determinar el origen de los requisitos
PRELIMINARES
• Etiqueta única para cada requisito
• Registrar las reglas de negocio
• Especificar los requisitos no funcionales
Validación
BIMESTRE
PRIMER
• Revisar los requisitos
• Probar los requisitos
• Definir los criterios de aceptación
• Simular los requisitos
SEGUNDO
BIMESTRE
Gestión de requisitos
• Establecer un proceso para la gestión del cambio

• Analizar el impacto del cambio
• Establecer una línea base y control de versiones de los requisitos
SOLUCIONARIO
• Mantener un historial de los cambios
• Seguimiento del estado de los requisitos
• Seguimiento de los temas de los requisitos
• Mantener la matriz de trazabilidad de requisitos
BIBLIOGRÁFICAS
• Usar una herramienta para la gestión de requisitos
REFERENCIAS
Conocimiento
• Formar al analista de negocio

• Capacitar a los interesados acerca de los requisitos
• Capacitar a los desarrolladores acerca del dominio de aplicación
• Definir un proceso de Ingeniería de Requisitos ANEXOS
• Crear un glosario
Gestión del proyecto
• Elegir un ciclo de vida apropiado

• Plan de aproximación de requisitos
• Estimar el esfuerzo de los requisitos
• Planes de base en los requisitos
• Identificar los requisitos de toma de decisiones
• Negociar compromisos
• Gestionar los requisitos de riesgo
• Seguimiento del esfuerzo de los requisitos
• Revisar las lecciones aprendidas del pasado
1.7. Los requisitos funcionales y no funcionales
ÍNDICE
Cuando se especifica o describe un Requisito en algunos casos, un requisito puede ser expresado
simplemente como un enunciado abstracto de alto nivel o puede ser expresado como una definición
detallada y formal de una función del sistema. Cualquiera sea el nivel de detalle, su utilidad está en función
de quien hará uso de la información. Uno de los problemas que surgen en el proceso de ingeniería de
requisitos es el de no diferenciar en el nivel de detalle que se requiere para la descripción. Comúnmente
PRELIMINARES
se distingue entre “Requisitos de usuario” y “Requisito del sistema”. (Sommervile, 2011)
Los requisitos de usuario, son enunciados expresados en lenguaje natural y/o diagramas que describen
acerca de los servicios que ofrece el sistema y de las restricciones sobre las cuales debe operar. Se utilizan
para representar los requisitos abstractos de alto nivel. Los lectores de este tipo de requisitos, entre
otros son los: gerentes del cliente, usuarios finales del sistema, ingenieros del cliente, gerentes de los
BIMESTRE
PRIMER
contratistas y arquitectos del sistema.
Los requisitos del sistema son descripciones más detalladas de las funciones, servicios y restricciones
operacionales del sistema de software, es decir se enfoca en lo que el sistema debe hacer. También se
conocen como requisitos de software. (Sommervile, 2011)
SEGUNDO
BIMESTRE
A los requisitos se los clasifican en funcionales y no funcionales. A continuación, se indican sus principales
características.
1. Requisitos Funcionales
SOLUCIONARIO
En un sistema los requisitos funcionales describen lo que el sistema debe hacer. Estos requisitos dependen
del tipo de software que se desarrolle, de los posibles usuarios del software y del enfoque general
tomado por la organización al redactar requerimientos. Cuando se expresan como requerimientos del
usuario, habitualmente se describen de una forma bastante abstracta. Sin embargo. los requerimientos
funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etc.
A continuación, se listan las características más importantes.
BIBLIOGRÁFICAS
REFERENCIAS
• Describen lo que un sistema software debe hacer.
• Dependen del tipo de software que se está desarrollando.
• De los usuarios esperados del software.
• Del enfoque general que adopta la organización cuando se escriben los requisitos.
• Cuando se expresan como requisitos de usuario, describen de forma abstracta para que entiendan
los usuarios del sistema. ANEXOS
• Cuando se describen de forma más específica detallan las funciones del sistema, sus entradas y
salidas, sus excepciones, etc.
Los requisitos funcionales del sistema varían desde requisitos generales que cubren lo que tiene que
hacer el sistema, hasta requisitos muy específicos que reflejan maneras locales de trabajar o los sistemas
existentes de una organización.
2. Requisitos no funcionales
Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que éste debe
reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos
casos, los requisitos funcionales de los sistemas también pueden declarar explícitamente lo que el
sistema no debe hacer.

• No se relacionan directamente con los servicios específicos que el sistema da a los usuarios.
• Puede relacionarse con propiedades emergentes del sistema como: fiabilidad, tiempo de respuesta
ÍNDICE
y uso de almacenamiento.
• Alternativamente puede definir restricciones sobre la implementación del sistema, como es:
capacidad de los dispositivos o la representación de los datos que se intercambian con otros
sistemas.
PRELIMINARES
La implementación de los requisitos no funcionales puede propagarse a lo largo del sistema, por dos
razones:
1. Afectan más a la arquitectura global del sistema. Por ejemplo, si se desea mayor rendimiento, a lo
mejor sea necesario evitar la comunicación entre componentes.
2. Podría generar algunos requisitos funcionales, que incluso definan nuevos servicios del sistema,
BIMESTRE
PRIMER
así como generar requisitos que restrinjan los ya existentes.
Los Requisitos no funcionales surgen de las necesidades del usuario o factores externos como por ejemplo
regulaciones de seguridad o legislación sobre privacidad. En la figura 5, se muestra la clasificación de los
requisitos no funcionales.
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
Figura 5. Clasificación de los requisitos no funcionales
ANEXOS
A continuación, se definen los tres grupos de requisitos no funcionales.
• Requisitos del producto. Especifican el comportamiento del producto; como los requerimientos
de desempeño en la rapidez de ejecución del sistema y cuánta memoria se requiere; los de
fiabilidad que fijan la tasa de fallas para que el sistema sea aceptable; los de portabilidad y los de
usabilidad.
• Requisitos organizacionales. Se derivan de las políticas y procedimientos existentes en la

organización del cliente y en la del desarrollador: estándares en los procesos que deben utilizarse;
requerimientos de implementación como los lenguajes de programación o el método de diseño
a utilizar y los requerimientos de entrega que especifican cuándo se entregará el producto y su
documentación.

• Requisitos externos. Se derivan de los factores externos al sistema y de su proceso de desarrollo.

Incluyen los requerimientos de interoperabilidad que definen la manera en que el sistema
ÍNDICE
interactúa con los otros sistemas de la organización; los requerimientos legales que deben seguirse
para asegurar que el sistema opere dentro de la ley y los requerimientos éticos. Estos últimos son
impuestos al sistema para asegurar que será aceptado por el usuario.
Crear un equipo colaborativo.
PRELIMINARES
Los proyectos de software a veces experimentan relaciones tensas entre analistas, desarrolladores,
usuarios, administradores y marketing. Las partes no siempre confían en las motivaciones del otro o
aprecian las necesidades y limitaciones del otro. Sin embargo, los productores y consumidores de un
producto de software comparten objetivos comunes. Para el desarrollo de sistemas de información
corporativa, todas las partes trabajan para la misma empresa, por lo que todos se benefician de las
mejoras a los resultados corporativos. Para los productos comerciales, los clientes felices generan
BIMESTRE
PRIMER
ingresos para el productor y la satisfacción de los desarrolladores.
El analista de negocios tiene la responsabilidad principal de forjar una relación de colaboración entre
los representantes de los usuarios y otras partes interesadas del proyecto. Un analista efectivo aprecia
los desafíos que enfrentan tanto los actores empresariales como técnicos y demuestra respeto por sus
SEGUNDO
BIMESTRE
colaboradores en todo momento. El analista conduce a los participantes del proyecto hacia un acuerdo
de requisitos que conduce a un resultado de ganar-ganar-ganar de las siguientes maneras:
• Los clientes están encantados con el producto.

• La organización en desarrollo está satisfecha con los resultados del negocio.
SOLUCIONARIO
• Todos los miembros del equipo están orgullosos del buen trabajo que realizaron en un proyecto
desafiante y gratificante.
ACTIVIDAD RECOMENDADA
BIBLIOGRÁFICAS
REFERENCIAS
Hemos finalizado el estudio de la unidad 1 y para reforzar los conocimientos, se recomienda el
desarrollo de las siguientes actividades:
•• Revise las actividades de la unidad 1 “Requisitos de software” del SWEBOK y elabore un mapa
conceptual de las actividades de desarrollo y gestión de requisitos
•• Recopile los conceptos relacionados a la definición de requisitos, en el proceso de desarrollo ANEXOS
de un producto software
•• Elabore una tabla en la que liste los principales riesgos que pueden ocurrir al inicio de un
proyecto. Indique el nombre del riesgo, las causas y las posibles estrategias para mitigarlos
Estrategias de desarrollo:
•• Para los riesgos, imagine un proyecto para implementar un software para realizar ofertas y
promociones de una tienda en línea a clientes que han adquirido productos en el último año.
•• Consultar en la guía didáctica de fundamentos de ingeniería de software
Se recomienda utilizar los siguientes recursos
•• Bourque, P., & Fairley, R. (2014). Guide to the Software Engineering Body of Knowledge, Version
3.0 SWEBOK. IEEE Computer Society. (obtener del sitio http://www.computer.org)
•• Sommervile, I. (2011). Ingeniería de Software (Vol. Novena). México: Pearson.
•• http://ocw.usal.es/ensenanzas-tecnicas/ingenieria-del-software/contenidos/Tema3-
IntroduccionalaIR-1pp.pdf

Autoevaluación 1
ÍNDICE
Estimado estudiante, hemos finalizado el estudio de la presente unidad, por lo que se
PRELIMINARES
recomienda realizar la autoevaluación que se indica a continuación con el propósito de
comprobar el conocimiento adquirido. Recuerde que al final de la guía se han incluido las
soluciones a estas autoevaluaciones; sin embargo, deberá revisarlas sólo después de haber
obtenido sus propias respuestas, lo que le permitirá saber si los temas están o no entendidos.
Lea detenidamente cada una de las preguntas y seleccione la alternativa correcta según corresponda.
BIMESTRE
PRIMER
1. Cuando el proyecto está en etapa de Implementación y los directivos deciden incorporar un nuevo
requerimiento, entonces tenemos:
a. Mala calidad del producto

b. Proyecto cancelado
SEGUNDO
BIMESTRE
c. Retraso en la entrega y sobrecosto del producto
2. Cuando los interesados continuamente están cambiando las necesidades durante el desarrollo
del proyecto, tenemos:
SOLUCIONARIO
a. Clientes descontentos
b. Proyecto viable
c. Miembros del equipo de desarrollo desmoralizados
3. Cuando se han definido requisitos que no reflejan las necesidades reales de los clientes, se debe a:
BIBLIOGRÁFICAS
REFERENCIAS
a. Documentos mal redactados
b. La metodología de desarrollo no es la apropiada
c. No se ha recolectado la información necesaria
4. Al proceso de establecer los servicios que el cliente requiere de un sistema y los límites bajo los
cuales opera y se desarrolla, se conoce como:
ANEXOS
a. Ingeniería de servicios
b. Ingeniería de software
c. Ingeniería de requisitos
5. Cuando el equipo de desarrollo se asegura que el software satisface los requisitos especificados,
se conoce como:
a. Validación
b. Verificación
c. Requerimiento

6. Demostrar que las necesidades del cliente se cumplen, es una actividad que se la conoce como:
a. Validación
ÍNDICE
b. Verificación
c. Requerimiento
7. Los requerimientos no funcionales se los puede clasificar en:
PRELIMINARES
a. Usuario y sistema
b. Producto y organización
c. Producto, organización y externos
8. A las especificaciones de los servicios y restricciones que el sistema debe considerar, se conoce
BIMESTRE
PRIMER
como requerimiento:
a. Funcional de usuario
b. Funcional de sistema
c. No funcionales
SEGUNDO
BIMESTRE
9. A las declaraciones en lenguaje natural y en diagramas, de los servicios que se espera que el sistema
provea y de las restricciones bajo las cuales se debe operar, se conoce como requerimiento:
SOLUCIONARIO
c. No funcionales
10. A las propiedades que el producto debe tener y que no es evidente para el usuario, incluyendo
atributos de calidad, acciones e interfaces externas, se conoce como requerimiento:
BIBLIOGRÁFICAS
REFERENCIAS
c. No funcionales
Verifique sus respuestas en el solucionario que se encuentra al final del presente texto guía.
ANEXOS
Ir a solucionario

UNIDAD 2. Interesados
ÍNDICE
Estimado estudiante
Una vez revisados los conceptos básicos relacionados con la Ingeniería de Requisitos, nos enfocamos
en una importante fuente de información para definir requisitos, las personas; que dependiendo de las
PRELIMINARES
funciones que desempeñan ya sea de forma directa e indirecta con las actividades de la organización
cumplen con un rol específico, y que es tarea del analista, descubrir sus principales aportes al desarrollo
del proyecto. En el campo del desarrollo de software se los conoce como Interesados, y como su nombre
claramente lo describe, sus intereses están orientados a conseguir un producto eficiente y que cumpla
con sus expectativas. El aporte de los interesados permitirá en su momento determinar el alcance del
proyecto en base a sus necesidades (intereses). Por tal motivo lo invito a que analice detenidamente los
BIMESTRE
roles que cumplen las personas y el papel que juegan en el desarrollo del proyecto de software.
PRIMER
2.1. Introducción
El alcance no sólo es todo lo que existe para conseguir el éxito del proyecto, sino que es necesario
SEGUNDO
BIMESTRE
entender la extensión del trabajo; las personas que lo hacen, lo influyen o lo saben y el resultado que
estas personas están tratando de lograr. Tal como se muestra en la figura 6.
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
Figura 6. La trinidad: el alcance, los interesados y las metas
Fuente: Robertson y Robertson, (2012)
ANEXOS
El alcance es la extensión del área de negocio afectada por el producto. Debido a que se está definiendo
una parte de real de la organización, el alcance apunta a los interesados - las personas que tienen un
interés en el éxito del trabajo. Los interesados, a su vez, deciden los objetivos, con que se mejora el
negocio cuando el producto se instala. No hay una orden particular para decidir cuáles deben ser estos
factores. La mayoría de los proyectos empiezan con el ámbito de aplicación, pero no es obligatorio.
Tienen que iterar entre los tres factores hasta que estén estabilizados, pero esto es casi siempre un
proceso corto cuando la organización sabe por qué quiere invertir en el proyecto.
2.2. Interesados
El Interesado o Stakeholder (equivalente en inglés) es una persona, grupo u organización que participa
activamente en el proyecto, y que se ve afectado o influye en el proceso o resultado. El propietario es
el interesado más obvio, pero hay otros. Por ejemplo, los usuarios del producto que están interesados
en tener un producto que haga su trabajo correctamente. Un experto en la materia es un interesado

obvio. Un experto en seguridad es un interesado menos obvio, pero es quien bebe ser considerado para
cualquier producto que considere información confidencial o financiera. Recuerde que está tratando de
ÍNDICE
establecer el valor óptimo para el propietario, y probablemente tenga que hablar con muchas personas,
todos ellos son potenciales fuentes de requisitos. En la figura 7 se identifican las clases comunes de
interesados que podrían estar representados por una o más funciones del proyecto. (Robertson y
Robertson, 2012)
PRELIMINARES
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
Figura 7. Mapa de interesados
Fuente: Robertson y Robertson (2012)
En Wiegers y Beatty (2013) se manifiesta que los interesados pueden ser internos o externos al equipo
del proyecto o la organización. En la figura 8 se identifican algunos de los potenciales interesados en
ANEXOS
estas categorías, pero dependiendo del proyecto o situación se definirán. El análisis de Interesados es
una parte importante en el desarrollo de requisitos. En la búsqueda de posibles interesados para un
proyecto en particular, analice coherentemente sobre una amplia red de interesados para evitar pasar
por alto alguna comunidad importante.

Fuera de la organización en desarrollo

Usuario directo Director de negocio Consultor
Usuario indirecto Oficial de contratación Auditor
ÍNDICE
Adquirente Agencia del gobierno Certificador
Personal de adquisición Experto en la materia Cuerpo regulador
Personal legal Director del programa Proveedor de software
Contratista Probador beta Proveedor de materiales
Subcontratista Publico en general Capitalista de riesgo
Organización en desarrollo
PRELIMINARES
Director de desarrollo Personal de ventas Sponsor ejecutivo
Marketing Instalador Jefe de la oficina de proyectos
Personal de soporte operativo Mantenedor Fabricante
Personal legal Director del programa Personal de entrenamiento
Arquitecto de información Experto en usabilidad Arquitecto de portafolio
Dueño de la compañía Experto en la materia Personal de soporte de infraestructura
Equipo del Proyecto

Director del proyecto Tester
Analista de negocio Director del producto
Arquitecto de aplicaciones Personal de contro de calidad
BIMESTRE
Diseñador Escritor de documentación
PRIMER
Desarrollador Administrador de Base de Datos
Propietario del producto Ingeniero de Hardware
Modelador de datos Analista de Infraestructura
Analista de procesos Arquitecto de soluciones empresariales
Figura 8. Potenciales interesados

SEGUNDO
BIMESTRE
Importante
Estimado estudiante, tenga presente que el desarrollo y gestión de requisitos
involucra muchos Interesados en numerosos roles. La cooperación de los interesados
es fundamental en la construcción de un conocimiento compartido del problema a
ser resuelto. A continuación, se describe algunos interesados que son comunes en los
SOLUCIONARIO
proyectos.
2.2.1. Patrocinador (Sponsor)
Típicamente un proyecto de software empieza con un Patrocinador, quien aprueba las bases para
BIBLIOGRÁFICAS
el proyecto y de ese modo autoriza el desarrollo del producto. Como se ha indicado anteriormente,
REFERENCIAS
el producto debe proveer un valor optimo a su propietario, y en muchos de los casos esto no es así.
Muchos proyectos son desarrollados para organizaciones comerciales que son de estricta propiedad de
los accionistas. Naturalmente no se puede hablar con todos los accionistas, ni es probable que se tenga
acceso a la junta directiva. En este caso es necesario nombrar un Patrocinador para el proyecto que
represente a los intereses del propietario. (Robertson y Robertson, 2012)
El patrocinador es el que paga por el producto, por lo que es quien tiene la última palabra en cuanto a ANEXOS
¿Qué hace el producto?, ¿Cómo lo hace? y ¿Cómo elaborar?. En otras palabras, el patrocinador es quien
es el árbitro final de que producto tiene un valor óptimo.
No se puede proceder sin patrocinador, si nadie está representando el interés de la organización,

entonces no tiene mucho sentido proceder con el proyecto. El patrocinador probablemente debe estar
en la reunión de inicio (arranque del proyecto) y por lo tanto sea la persona que represente a:
• Administrador de usuario
Si construye un producto para consumo interno, el patrocinador más idóneo es el director, gerente o
administrador de los empleados o usuarios que operarán el producto. Su departamento o su trabajo son
los beneficiados del producto, por lo que es razonable que el costo de construcción sea asumido por el
gerente departamental.

• Departamento de marketing
Si construye productos para la venta a personas fuera de su organización, el departamento de marketing
ÍNDICE
debe asumir el rol de patrocinador y representante del propietario eventual del producto.
• Desarrollador del producto
PRELIMINARES
Si construye software para la venta, el presupuesto para este desarrollo podría ser con el gerente de
producto o gerente del programa estratégico. Uno de estos debería ser el que hace de patrocinador.
Interrogantes
Estimado estudiante, imagine una empresa y determine la organización, su estructura y
responsabilidades laborales y analice las siguientes interrogantes:
•• ¿Qué persona podría ser el mejor representante?
BIMESTRE
•• ¿Quién paga por el desarrollo del producto?
PRIMER
•• ¿Quién o qué, cosecha los beneficios de las ventajas comerciales que el producto trae?
•• ¿Cuáles son los valores que tiene que considerar cuando se determina qué debe hacer el
producto final?
Al contestar estas interrogantes le permitirá saber cuál es el patrocinador de proyecto.
SEGUNDO
BIMESTRE
Es necesario hacer todo lo necesario para encontrar al patrocinador, caso contrario el proyecto no tendrá
un final satisfactorio.
2.2.2. El analista de negocio
Actualmente muchas organizaciones están reconociendo que el rol del analista de negocio es táctico y
SOLUCIONARIO
estratégico. El Analista de Negocio es la persona que traduce las necesidades del cliente (en función de
los objetivos estratégicos) y dan origen entre otras cosas a los proyectos de tecnología informática. De
esta forma el analista de negocio representa un factor crítico para lograr un proyecto exitoso actuando
como enlace, entre las personas del negocio que necesitan una solución a un problema que no le permite
alcanzar sus objetivos, y el equipo del proyecto que desarrolla una solución.
BIBLIOGRÁFICAS
REFERENCIAS
De acuerdo a Wiegers y Beatty (2013) el analista de negocio es el individuo que tiene la principal
responsabilidad para obtener, analizar, documentar y validar las necesidades de los interesados
del proyecto. El analista ejerce de interprete principal entre la comunidad del cliente y el equipo de
desarrollo de software, tal como se puede observar en la figura 9. Pero también existen otras formas
de comunicación, es importante diferenciar entre las actividades del analista de negocio y el director
del proyecto, el primero desempeña un papel central en la recopilación y difusión de información
relacionado con el producto mientras que el director del proyecto se encarga de comunicar la información ANEXOS
relacionada con el proyecto.

ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
Figura 9. Relación de comunicación del analista de negocio con los interesados del proyecto
La etiqueta de analista de negocio y analista de sistemas o funcional son la misma cosa, debido a que el
SEGUNDO
BIMESTRE
rol de análisis cumple varias funciones: de negocio, sistemas, requisitos, procesos, etc., en definitiva, todas
están involucradas dentro de la definición de análisis del negocio. La separación de estas funciones y
responsabilidades referentes al análisis dependerá del tamaño del proyecto o de la organización. Dichos
rótulos fueron creados por organizaciones, empresas u organismos de capacitación.
SOLUCIONARIO
En los 90 no existían muchos estándares con respecto a las carreras en sistemas, ni mucho menos el
negocio de las certificaciones, solo existía el programador, el programador hacía todo. Luego fueron
apareciendo los roles de analista-programador, que fue creado para promover la carrera universitaria
de analista de sistemas. Posteriormente fueron apareciendo los ingenieros de sistemas, ingenieros de
software, etc. Muchos de estos roles son simples etiquetas que se encuentran en las metodologías para
desarrollar sistemas de información.
BIBLIOGRÁFICAS
REFERENCIAS
En conclusión, el analista de negocio tiende a centrarse más del lado del negocio y cómo utilizar las TI
para alcanzar los objetivos de negocio, mientras que un analista de sistemas está más preocupado por el
diseño e implementación del software. En las grandes organizaciones ambos papeles suelen ser títulos
de trabajo separados, mientras que en las organizaciones medianas y pequeñas suelen ser realizadas por
la misma persona. (Wiegers y Beatty, 2013)
El analista de negocio es un rol del proyecto y no necesariamente un título de trabajo. Al analista de ANEXOS
negocio también se lo conoce como:
• Analista de requisitos
• Analista de sistemas
• Ingeniero de requisitos
• Administrador de requisitos
• Analista de aplicación
• Analista de sistemas de negocio
• Analista de negocio de TI
• Analista

Estos roles o títulos se utilizan de forma indistinta de una organización a otra. Uno o más especialistas
podrían desempeñar el rol en un proyecto dado o podrían ser asignados miembros de equipo que
ÍNDICE
también desempeñan otras funciones en el proyecto. Estos miembros del equipo incluyen: al gerente
del proyecto gerente del producto, propietario del producto, experto en el tema, desarrollador y a veces
hasta el usuario.
Es importante señalar que cuando una persona que tienen un rol en el proyecto y que también se
PRELIMINARES
desempeña como analista de negocio, está desempeñando dos trabajos distintos. Es el caso del gerente
del proyecto que también es el analista de negocio en un proyecto. Un gerente de proyecto necesita
crear y manejar planes, incluyendo programaciones y necesidades de recursos basados en el trabajo
que desarrollan los analistas de negocio. El director del proyecto debe ayudar a administrar el alcance y
hacer frente a los cambios de programación a medida que el proyecto evoluciona. Podría desempeñar el
rol de gerente del proyecto en un minuto, luego cambiar el rol para ejecutar las prácticas de analista en
BIMESTRE
el siguiente minuto. Son roles distintos, que requieren de conjunto de habilidades diferentes. (Wiegers
PRIMER
y Beatty, 2013)
En organizaciones que desarrollan productos de consumo, el rol de analista suele ser responsabilidad del
gerente de producto o del personal de marketing. Básicamente el gerente de producto actúa analista de
negocio, a menudo con énfasis adicional en la comprensión del panorama del mercado y la anticipación
SEGUNDO
BIMESTRE
de las necesidades de los usuarios externos. Si el proyecto tiene un gerente de producto y un analista de
negocio, normalmente el gerente del producto se concentra en el mercado externo y las demandas de
los usuarios y el analista de negocio los convierte en requisitos funcionales.
Los proyectos ágiles también necesitan de las habilidades de un analista de negocio, es probable que
SOLUCIONARIO
exista un rol del proyecto como propietario de producto que realice algunas de las tareas tradicionales
del analista de negocio. El analista de negocio puede ayudar a representar a los usuarios y a entender sus
necesidades, mientras que realiza sus tareas adicionales.
Importante
Estimado estudiante, tenga presente que independientemente del título que tenga en
BIBLIOGRÁFICAS
REFERENCIAS
el proyecto, la persona que realiza las tareas de analista debe tener las habilidades, el
conocimiento y la personalidad para desempeñar de mejor manera el rol.
Un analista talentoso puede hacer la diferencia entre un proyecto exitoso y uno que sea conflictivo. Una
compañía descubrió que podría inspeccionar las especificaciones de requisitos escritas por analistas
experimentados dos veces más rápido que las escritas por los principiantes porque contenían menos
errores. En el modelo Cocomo II para la estimación de proyectos la experiencia y la capacidad del analista ANEXOS
tienen una gran influencia en el esfuerzo y costo del proyecto. (Boehm, Abts, Winsor, Sunita y Bradford,
2000) El uso de analistas altamente experimentados puede reducir el esfuerzo general del proyecto en
un tercio en comparación con proyectos similares con analistas inexpertos.
En analista primero debe conocer los objetivos de negocio para el proyecto, y luego definir los requisitos
de usuario, funcionales y de calidad que permitan a los equipos estimar y planificar el proyecto como
también diseñar, construir y verificar el producto.
El analista de negocio también tiene la habilidad de ser un líder y comunicador, convirtiendo nociones
vagas del cliente en especificaciones claras que guían el trabajo del equipo de software. A continuación,
se describen algunas de las actividades comunes que realiza el analista de negocio mientras cumple con
su rol.

• Define requisitos de negocio

• Planifica el enfoque de requisitos
ÍNDICE
• Identifica a los interesados del proyecto y a las clases de usuarios.
• Obtiene requisitos
• Analiza requisitos
• Documenta requisitos
PRELIMINARES
• Comunica requisitos
• Dirige la validación de requisitos
• Facilita la priorización de requisitos
• Gestiona requisitos
Las personas no pueden desempeñar las funciones de analista sin la suficiente capacitación, orientación
BIMESTRE
PRIMER
y experiencia, pues no harán un buen trabajo y la experiencia será frustrante. El trabajo requiere de
habilidades que están más orientadas a las personas que a técnicas. Los analistas necesitan saber cómo
utilizar una variedad de técnicas de obtención y cómo representar la información en formas distintas
al texto en leguaje natural. Un analista de negocio combina una fuerte comunicación, facilitación y
habilidades interpersonales con el conocimiento técnico y dominio del negocio y la personalidad
SEGUNDO
BIMESTRE
adecuada para el proyecto. La paciencia y el deseo sincero de trabajar con la gente son factores claves
del éxito. En Young (2004), se indica una tabla de habilidades que son apropiadas para analistas de
requisitos a nivel bajo, medio y alto. A continuación, se listan las más importantes:
• Habilidad de escuchar.
SOLUCIONARIO
• Habilidad para entrevistar y cuestionar
• Pensando en los intereses
• Habilidades analíticas
• Habilidad de pensamiento en sistemas
• Habilidades de aprendizaje
BIBLIOGRÁFICAS
REFERENCIAS
• Habilidades de facilitación
• Habilidades de liderazgo
• Habilidades de observación
• Habilidades de comunicación
• Habilidades de organización
• Habilidades de modelado ANEXOS
• Habilidades interpersonales
• Creatividad
Además de tener capacidades específicas y características personales, los analistas de negocios necesitan
una amplia gama de conocimientos, muchos de los cuales se obtienen a través de la experiencia.
Necesitan entender las prácticas actuales de ingeniería de requisitos y cómo aplicarlas en el contexto de
diversos ciclos de vida de desarrollo de software. Necesitan educar y convencer a aquellos que no están
familiarizados con las prácticas de requisitos. Un verdadero analista dispone de un conjunto de técnicas
que sabe cuándo debe y cuando no debe usar cada una.
Los analistas de negocio necesitan orientar las actividades de desarrollo y gestión de los requisitos
durante toda la vida útil del proyecto. Un analista con una sólida comprensión de la gestión de proyectos,
los ciclos de vida de desarrollo, la gestión de riesgos y la ingeniería de calidad puede ayudar a prevenir

problemas de requisitos que afecten al proyecto. En un entorno de desarrollo comercial, el analista de

negocio se beneficiará del conocimiento de los conceptos de gestión de productos. Los analistas de
ÍNDICE
negocio se benefician de un nivel básico de conocimiento sobre la arquitectura y el entorno operativo,
para que puedan entablar conversaciones técnicas sobre prioridades y requisitos no funcionales.
El conocimiento del negocio, la industria y la organización son activos poderosos para un analista de
negocio efectivo. El analista experto en negocios puede minimizar las comunicaciones erróneas con los
PRELIMINARES
usuarios. Los analistas que entienden a la organización y los dominios de negocio a menudo detectan
supuestos no expresados y requisitos implícitos. Pueden sugerir maneras en que los usuarios pueden
mejorar sus procesos de negocio o proponer funcionalidades valiosas que ningún otro interesado haya
pensado. Entender el dominio de la industria puede ser particularmente útil en un entorno comercial
para que los analistas puedan ofrecer análisis de mercado y de productos competitivos.
BIMESTRE
PRIMER
Buscar en la web
Estimado estudiante, busque en la web el artículo “¿Analista de Negocio, de Sistemas, o de
Procesos?” de Norberto Figuerola y analice detenidamente los conceptos relacionados al
Analista de negocio desde distintos puntos de vista.
SEGUNDO
BIMESTRE
2.2.3. El cliente
El cliente es el que compra el producto una vez que ha sido desarrollado, convirtiéndose en el nuevo
propietario del producto. Para convencer al cliente de que compre el producto, tiene que construir algo
SOLUCIONARIO
que su cliente encuentre valioso, útil y satisfactorio.
Puede ser que conozca los nombres de los clientes, o talvez son cientos o miles de personas desconocidas
que podrían ser persuadidos a pagar por su producto. En cualquier caso, debe entender lo suficientemente
bien a lo que ellos encuentran valioso y que podrían comprar.
BIBLIOGRÁFICAS
Hay una diferencia entre los clientes que compran un producto para su propio uso y los que compran
REFERENCIAS
para el uso de otros. Cuando el producto es un producto de venta al por menor y el cliente y el propietario
son la misma persona, entonces los valores propios de esa persona son de suma importancia para el
analista. El cliente siempre busca comodidad por lo tanto el analista tiene que descubrir lo que el cliente
está haciendo y lo más conveniente.
Cuando los clientes compran para el uso de otros, el propietario es presumiblemente un cliente de la
organización. Su interés radica en lo que la organización está haciendo y en lo que considera valioso. ANEXOS
Es decir, ¿qué puede hacer su producto para que los usuarios dentro de la organización sean más
productivos, eficientes, más rápidos o cualquier otro elemento calidad que esté buscando?
Incluso si está desarrollando software de código abierto, todavía tiene un cliente; La diferencia es
simplemente que ningún dinero cambia de manos.
Usted debe entender lo que atrae a sus clientes, y lo que valoran. ¿Qué encontrarán útiles? ¿Qué pagarán?
Entender correctamente a su cliente hace una gran diferencia en el éxito de su producto.
Como hay un solo cliente (en esta etapa), sería aconsejable invitarlo a participar como interesado en el
proyecto. Esto daría lugar a que el cliente participe activamente en la selección de los requisitos que
son útiles, eligiendo entre requisitos en conflicto, y haciendo que los analistas de necesidades sean
conscientes de sus valores, problemas y aspiraciones.

Está claro que el cliente siempre debe estar representado en el proyecto. Cuando existen muchos clientes
potenciales, se debe encontrar una forma de representarlos en el proyecto. Esta representación puede
ÍNDICE
provenir del departamento de marketing, de usuarios experimentados de uno o más de sus clientes
clave o una combinación de expertos en el tema y usabilidad dentro de su organización.
2.2.4. El usuario
PRELIMINARES
Se utiliza el término usuarios para hacer referencia a las personas que en última instancia serán los
operadores prácticos del producto. En (Robertson y Robertson, 2012) a los usuarios también se los conoce
como operadores normales, operadores de apoyo operativo y operadores de mantenimiento. Para los
productos internos, los usuarios suelen ser las personas que trabajan para el patrocinador del proyecto.
Para los productos de ordenadores personales o dispositivos móviles, el usuario y el propietario suelen
ser la misma persona.
BIMESTRE
PRIMER
Identificar los usuarios es el primer paso para entender el trabajo que realizan, después de todo, el
producto está destinado a mejorar este trabajo. Además, es necesario entender qué tipo de personas
son para poder proporcionar la experiencia de usuario adecuado. Se tiene que crear un producto que los
usuarios puedan y quieran usar. Obviamente, cuanto mejor se comprende a los usuarios, mejor tendrá la
oportunidad de especificar un producto adecuado para ellos.
SEGUNDO
BIMESTRE
Los diferentes usuarios hacen diferentes demandas para el producto. Por ejemplo, un piloto de línea
aérea tiene requisitos de usabilidad muy diferentes, al de un viajero comprando un billete en un sistema
ferroviario.
Cuando se desarrollan productos de consumo, software de mercado o sitios web, debe considerar el uso
SOLUCIONARIO
de una persona como el usuario. Una persona es una persona virtual que es representativo de la mayoría
de los usuarios. Al determinar las características de esta persona en un grado suficiente, el equipo de
requisitos puede conocer los requisitos correctos para satisfacer a cada uno de los personajes.
Considerar a los usuarios potenciales es vital para el desarrollo ágil. Muchos equipos operan con un sólo
BIBLIOGRÁFICAS
usuario que se le pide que suministre los requisitos para un producto y poca o ninguna consideración a lo
REFERENCIAS
que ocurrirá cuando el producto se lance a un público más amplio. Es importante que considere siempre
el espectro más amplio de usuarios y, como mínimo, elija usuarios interesados de ambos extremos.
Para cada categoría de usuario, escriba una sección en su especificación para describir, tan completamente
como el tiempo lo permita, los atributos de sus usuarios. Considere estas posibilidades:
ANEXOS
• Experiencia en el tema: ¿Cuánta ayuda necesitan?
• Experiencia tecnológica: ¿Pueden operar el producto? ¿Qué términos técnicos se deben utilizar?
• Habilidades intelectuales: ¿Deberían simplificarse las tareas? ¿O dividido en un nivel inferior?
• Actitud hacia el trabajo: ¿Cuáles son las aspiraciones de los usuarios?
• Educación: ¿Qué puede esperar que su usuario sepa?
• Habilidades lingüísticas: No todos los usuarios hablan o leen el lenguaje nativo.
• Y lo más importante, ¿qué es lo que más desean mejorar en su trabajo?
Además, para cada categoría de usuario, identifique los atributos particulares que el producto debe
satisfacer:
• Personas con discapacidades: Considere todas las discapacidades. Esto, en algunos casos, es un
requisito legal.

• No leídos: Considere las personas que no saben leer y las personas que no hablan el lenguaje
nativo.
ÍNDICE
• Personas que necesitan lentes de lectura: Esto es particularmente utilizado por la mayoría de
personas.
• Personas que no pueden resistirse a cambiar cosas como fuentes, estilos, etc.
• Personas que seguramente llevarán equipaje, paquetes grandes o un bebé.
PRELIMINARES
• Personas que normalmente no utilizan una computadora.
• Personas que podrían estar enojadas, frustradas, presionadas o con prisa.
Escribir todo esto parece una tarea difícil y tediosa, sin embargo, se debe tomar el tiempo necesario para
registrar para que otras personas puedan leerlo. Los usuarios son tan importantes para su causa que
usted debe entender qué tipo de personas son y qué capacidades tienen.
BIMESTRE
PRIMER
En esta etapa, los usuarios que identifique son usuarios potenciales. Es decir, aún no conoce con precisión
el alcance del producto, se determinará posteriormente en el proceso de requisitos, por lo que está
identificando a las personas que podrían utilizar, mantener y dar soporte al producto. Recuerde que las
personas que no sean los usuarios podrían terminar teniendo contacto directo con el producto. Es mejor
identificar a los usuarios superfluos que dejar de encontrarlos todos porque cada categoría de usuario
SEGUNDO
BIMESTRE
diferente tendrá algunos requisitos diferentes.
SOLUCIONARIO
Estimado estudiante, considerando el proyecto de venta de productos en línea. Elabore un listado
de los diferentes usuarios que podrían hacer uso del sistema. Considere las especificaciones que
se han indicado en este apartado.
BIBLIOGRÁFICAS
REFERENCIAS
2.2.5. Otros interesados
Hay más personas con las que tiene que hablar para poder encontrar todos los requisitos, su contacto
con estas personas puede ser fugaz, pero es necesario. Cualquiera de ellos puede tener potenciales
requisitos para el producto.
ANEXOS
El problema que a menudo se enfrentan en los proyectos de requisitos es que no se descubre a todos
los interesados, y por lo tanto no se pueden descubrir sus necesidades. Esta deficiencia puede resultar
en una serie de peticiones de cambio cuando el producto se libera a una audiencia que es más amplia
de lo que se pensaba. Naturalmente, las personas que pasaron por alto no serán felices. Además, debe
tener en cuenta que cuando se instala un nuevo sistema, alguien gana y alguien pierde poder: Algunas
personas encuentran que el producto les aporta nuevas capacidades y algunas personas no son capaces
de hacer su trabajo de la forma en que lo hacían. La moraleja de la historia es clara: encontrar todas las
partes que serán afectadas por el producto, y encontrar sus requisitos.
Adicional a los interesados analizados anteriormente existen otros roles tal como se puede ver en la
figura 7. A continuación se describen algunos de ellos.
• Consultores. Los consultores, tanto internos a la organización como externos, son personas que
tienen la experiencia que se necesita. Los consultores tal vez nunca tocan o ven el producto, pero

su conocimiento se convierte en parte de ello. Por ejemplo, si está construyendo un producto

financiero, un experto en seguridad es un interesado. Puede que nunca vea el producto, pero su
ÍNDICE
experiencia y su participación en los requisitos, determina que el producto es seguro.
• Administración. Considere cualquier categoría de gestión. Estos grupos aparecen en el mapa

de interesados como clases como beneficiario funcional, beneficiario político y beneficiario
financiero. ¿Es un producto estratégico? ¿Existen otros gestores que no sean los directamente
PRELIMINARES
involucrados? Los gerentes de producto y los administradores de programas son fuentes obvias
de requisitos. Los gerentes de proyecto o líderes que son responsables de la gestión cotidiana del
proyecto también tienen contribuciones a realizar.
• Expertos en la materia. Esta división puede incluir analistas de dominios, consultores de negocios,
analistas de negocios, o cualquier otra persona que tenga algún conocimiento especializado del
tema del negocio. Como consecuencia, estos expertos son una fuente principal de información
BIMESTRE
PRIMER
sobre el trabajo.
• Equipo central. El equipo principal está formado por las personas que forman parte del esfuerzo
de construcción del producto. Pueden incluir diseñadores de productos, desarrolladores,
probadores, analistas de negocio, analistas de sistemas, arquitectos de sistemas, escritores
SEGUNDO
BIMESTRE
técnicos, diseñadores de bases de datos y cualquier otra persona involucrada en la construcción.
También puede considerar a la comunidad de código abierto como interesados ya que tienen
conocimientos sobre tecnología y tendencias en la mayoría de las áreas del software. Puede ponerse
en contacto con estas personas a través de foros de código abierto. Por lo general, ellos están muy
SOLUCIONARIO
entusiasmados y listos para compartir el conocimiento con usted.
• Inspectores. Considere a los auditores, inspectores gubernamentales, cualquier tipo de inspectores

de seguridad, inspectores técnicos, o incluso posiblemente la policía. Puede ser necesario crear
capacidades de inspección en su producto. Si el producto está sujeto a leyes gubernamentales, o
a cualquiera de los otros actos reglamentarios, la inspección es crucial, al igual que los requisitos
BIBLIOGRÁFICAS
de los inspectores.
REFERENCIAS
• Las fuerzas del mercado. Las personas del departamento de marketing son probablemente los
interesados que representan el mercado. Cuando usted está construyendo un producto para la
venta comercial, las tendencias en el mercado son una fuente potente de requisitos, así como un
conocimiento profundo de los probables consumidores. Tenga en cuenta la velocidad a la que se
están moviendo los mercados de teléfonos inteligentes y tabletas. Permanecer delante de la curva
es vital para cualquier producto de consumo. ANEXOS
• Expertos legales. Cada año el mundo está lleno de más y más leyes, cumplir con todas ellas es
desalentador pero necesario. Los abogados son los interesados para la mayoría de los requisitos
legales.
• Interesados negativos. Los interesados negativos son personas que no quieren que el proyecto
tenga éxito. Aunque pueden ser los individuos menos cooperativos, debe considerarlos y
convertirlos en aliados. También se deben considerar a las personas que amenazan al producto,
como son: los hackers, los defraudadores y otras personas malévolas. No se conseguirá ninguna
cooperación de ellos, pero debe considerar cómo pueden maltratar el producto.
• Opinión pública. ¿Existen grupos de usuarios para su producto?, sin duda serán una fuente
importante de requisitos. Para cualquier producto destinado al dominio público, considere la

posibilidad de encuestar a los miembros del público. Pueden hacer demandas en su producto
que podría significar la diferencia entre la aceptación y el rechazo.
ÍNDICE
• Gobierno. Algunos productos deben interactuar con agencias gubernamentales para propósitos
de informes, o recibir información de una agencia gubernamental; Otros productos tienen
requisitos que requieren consultar con el gobierno. Aunque el gobierno no puede asignar a una
persona a tiempo completo al proyecto, debe nombrar a la agencia pertinente como interesado.
PRELIMINARES
En el caso de nuestro país por ejemplo el SRI cuando se intenta desarrollar un producto que tenga
que ver con facturación, o el IESS cuando se deben cumplir con las obligaciones de los empleados.
• Grupos de interés especial. Considere a los grupos con discapacidades, los organismos
ambientales, las personas extranjeras, los ancianos, los interesados relacionados con el género, o
casi cualquier otro grupo que pueda entrar en contacto con su producto.
BIMESTRE
PRIMER
• Expertos Técnicos. Los expertos técnicos no construyen necesariamente el producto, pero casi
seguramente serán consultados sobre alguna parte de él. Como interesados de este grupo, se debe
considerar expertos en usabilidad, consultores de seguridad, personas de hardware, expertos en
tecnologías que pueda utilizar, especialistas en productos de software o expertos de cualquier
campo técnico que el producto pueda utilizar.
SEGUNDO
BIMESTRE
• Intereses culturales. Esta circunscripción se aplica a los productos destinados al dominio público,
y especialmente cuando el producto se vende o se ve en otros países. Además, siempre es posible
en estos tiempos políticamente correctos que su producto podría ofender a alguien. Si hay alguna
posibilidad de que los intereses religiosos, étnicos, culturales, políticos, de género u otros intereses
SOLUCIONARIO
humanos puedan verse afectados por el producto o entrar en contacto con él, debe considerar a
representantes de estos grupos como interesados para el proyecto.
• Sistemas adyacentes. Los sistemas adyacentes en su diagrama de contexto de trabajo son los
sistemas, personas o áreas de trabajo que interactúan directamente con el trabajo que está
estudiando. Es necesario analizar cada sistema adyacente: ¿Quién representa sus intereses, o
BIBLIOGRÁFICAS
quién tiene conocimiento de ello? Cuando el sistema adyacente es un sistema automatizado,
REFERENCIAS
¿quién es su jefe de proyecto o mantenedor? Si no están disponibles, es posible que tenga que
leer la documentación del sistema adyacente, o su código, para descubrir si tiene alguna demanda
especial para interactuar con su producto. Para cada sistema adyacente es necesario encontrar al
menos un actor.
2.3. Análisis de interesados ANEXOS
Cada interesado debe pertenecer a una categoría y en función de esa categoría el grado de responsabilidad
en el proyecto de desarrollo. En la tabla 2, se indican algunos roles con su respectiva participación en el
proyecto.

Tabla 2.
Categoría de los interesados
ÍNDICE
DESARROLLO DE REQUERIMIENTOS
GESTIÓN DE
ROL Desarrolla Especifica
Define requisitos REQUERIMIENTOS
requisitos de requisitos de
PRELIMINARES
del negocio
usuario software
Sponsor del Propietario
Revisor Aprobador Aprobador
proyecto Aprobador
Gerente del
Productor Revisor Revisor Revisor
proyecto o producto
BIMESTRE
Analista Revisor Productor Productor Productor
PRIMER
Propietario,
Propietario
Usuario experto Revisor Aprobador, Propietario
Revisor
Productor
Desarrollador y
Revisor Revisor Revisor Productor Revisor
SEGUNDO
tester de software
BIMESTRE
Fuente: (Gottesdiener, 2005)
El análisis de interesados implica definir el perfil mediante una descripción que caracteriza a cada
interesado y explica su relación con el proyecto. Es necesario para entender los intereses, preocupaciones
SOLUCIONARIO
y criterios de éxito del producto para cada interesado, para descubrir las posibles fuentes de conflicto y
para poner de relieve temas relacionados con los requisitos que pueden requerir más tiempo y atención.
Los perfiles de los interesados también pueden revelar los posibles obstáculos para la implementación
exitosa del producto además le ayudará a definir la cantidad de interesados que debe considerar para el
levantamiento de requisitos.
BIBLIOGRÁFICAS
REFERENCIAS
Para definir el perfil de los interesados es necesario seguir los siguientes pasos:
1. Escribir un perfil básico para cada interesado, con la siguiente información:
a. Rol: Listar la categoría del interesado (por ejemplo, patrocinador, Product Champion,
usuario directo, usuario indirecto, asesor o proveedor) al que pertenece.
b. Responsabilidades: Describa brevemente el rol de cada interesado en relación con el ANEXOS
proyecto.
c. Intereses: Liste las necesidades de los interesados, deseos y expectativas para el producto
(por ejemplo, los intereses de un patrocinador pueden incluir aumento de los ingresos,
reducción de costos, mejora de los servicios y el cumplimiento de las normas reglamentarias).
d. Los criterios de éxito: Describir las características o capacidades que el producto debe tener
para ser considerado como exitoso.
e. Preocupaciones: Listar todos los obstáculos, limitaciones, o factores limitantes que puedan
impedir o inhibir al interesado a aceptar el producto.
f. Capacidad técnica: Describir al usuario directo el grado de familiaridad con la tecnología.
g. Características del entorno de trabajo y limitaciones: Describir las condiciones de trabajo
relevante que pueda afectar el uso del sistema (por ejemplo, un entorno de trabajo ruidoso
o el uso del móvil o al aire libre).

2. Incluir los perfiles de los interesados en

el documento de requerimientos de usuario (si se utiliza)
y el documento de especificaciones de requisitos de software
ÍNDICE
a. Si los perfiles contienen gran cantidad de información, documente un perfil por cada
interesado en una tabla o sección en el documento de requisitos correspondientes.
En la tabla 3, se describe un ejemplo del perfil de algunos interesados.
PRELIMINARES
Tabla 3.
Ejemplo de la definición del perfil de los interesados
Criterios de Competencias
Interesado Roles Responsabilidad Intereses Preocupación
éxito técnicas
•• Construya
BIMESTRE
•• Satisfacer las
PRIMER
•• Sponsor un sistema •• Tiempo de
Director de la •• Aprobar necesidades
•• Usuario de acuerdo construcción de •• N/A
MAD (proyecto) de los
indirecto a las normas la aplicación
estudiantes
de la MAD
•• Trámites
registrados
SEGUNDO
•• Involucramiento
BIMESTRE
en cada
de los actores
•• Usuario centro.
•• Perfeccionar que intervienen •• Liberación
Coordinación directo •• Aprobar •• Cada actor
y validar los en el proceso. del
Académica •• Product proceso realiza las
procesos •• No se registre de producto.
champion actividades.
forma apropiada
•• Satisfacción
SOLUCIONARIO
la información
de los
estudiantes
BIBLIOGRÁFICAS
REFERENCIAS
Hemos finalizado el estudio de la unidad 2 y para reforzar el análisis de requisitos, se recomienda
el desarrollo de las siguientes actividades:
•• Analice los diferentes roles que se definen en el desarrollo de requisitos que propone Volere
ANEXOS
•• Complete la tabla 4, con la categoría de los interesados
•• Complete la tabla 5, con el perfil de los interesados
Estrategias de desarrollo
Se recomienda como base utilizar los siguientes recursos:
•• Robertson, S., & Robertson, J. (2012). Mastering the Requirements Process:Getting
Requirements Right. Addison-Wesley.
•• Gottesdiener, E. (2005). The Software Requirements - Memory Jogger. GOAL/QPC (Para
completar la tabla 4 y 5)

Tabla 4.
Casos de categoría de los interesados
ÍNDICE
DESARROLLO DE REQUERIMIENTOS
Define Desarrolla Especifica GESTIÓN DE
ROL
requisitos del requisitos de requisitos de REQUERIMIENTOS
negocio usuario software
PRELIMINARES
Auditor
Comprador
Administrador de la base de datos
Analista de documentación
BIMESTRE
Experto financiero
PRIMER
Invitado
Especialista en Help desk
Experto legal
SEGUNDO
Consultor
BIMESTRE
Instalador del producto
Especialista en ventas
Programador
SOLUCIONARIO
Tabla 5.
Ejemplos de la definición del perfil de los interesados
Criterios de Competencias
Interesado Roles Responsabilidad Intereses Preocupación
éxito técnicas
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS

Autoevaluación 2
ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
1. En un proyecto sobre “Punto de venta” que cuenta con el recurso humano necesario, se ha
levantado información preliminar y se ha elaborado el documento de visión y alcance, mismo que
debe ser aprobado. ¿Quién debería aprobar?
a. Gerente del proyecto
SEGUNDO
BIMESTRE
b. Sponsor del proyecto
c. Experto en la materia
2. La UTPL, ha decidido implementar un nuevo sistema de matrícula en línea para lo cual se están
definiendo el equipo de trabajo. El estudiante ¿Qué rol desempeñaría?
SOLUCIONARIO
a. Usuario
b. Cliente
c. Usuario y Cliente
BIBLIOGRÁFICAS
3. A las personas u organizaciones que tienen influencia directa, indirecta o se ven influenciados por
REFERENCIAS
un proceso de software, se los conoce como:
a. Gestores
b. Analistas
c. Interesados
4. Al que actúa como enlace entre el equipo de software y el administrador del negocio, se lo conoce ANEXOS
como:
a. Sponsor del proyecto

b. Gerente del proyecto
c. Analista
5. Al que define o aprueba la visión y alcance del producto, se lo conoce como:
a. Sponsor del proyecto

c. Analista

6. En general a los que deciden los objetivos cuando se mejora el negocio al hacer uso del producto
software, se los conoce como:
ÍNDICE
a. Interesados
b. Desarrolladores
c. Analistas
PRELIMINARES
7. Desde el punto de vista de desarrollo del producto software, a los interesados son importantes
debido a que son:
a. Los que pagan el producto

b. Potenciales fuentes de requisitos
c. Interactúan con el sistema
BIMESTRE
PRIMER
8. El que tiene la principal responsabilidad para obtener, analizar, documentar y validar las
necesidades de los interesados del proyecto, se conoce como:
a. Patrocinados
SEGUNDO
BIMESTRE
c. Analista de negocio
9. Al que se encarga de comunicar las actividades e información del proyecto se conoce como:
a. Patrocinados
SOLUCIONARIO
c. Analista de negocio
10. El analista, al desarrollar un producto. ¿Qué es lo que tiene que considerar para que el usuario
compre o acepte el producto de software?
BIBLIOGRÁFICAS
REFERENCIAS
a. Que no sea costoso
b. Que la organización se adapte al software
c. Que el producto se valioso, útil y satisfactorio
Estimado estudiante:
Recuerde que el solucionario se encuentra al final del presente texto guía. ANEXOS
Ir a solucionario

UNIDAD 3. REQUISITOS DE NEGOCIO
ÍNDICE
Estimado estudiante
Una vez aclarado los conceptos preliminares relacionados con la especificación de requisitos, vamos
a empezar a definir los requisitos a nivel de negocio en base a los interesados que se identifiquen. Los
PRELIMINARES
requisitos de negocio representan el nivel más alto de la cadena de requisitos. Se encargan de definir la
visión del producto y el alcance del proyecto que implementará la solución. Los requisitos de usuario y
los requisitos funcionales deben alinearse con el contexto y los objetivos que los requisitos de negocio
establecen. Por lo tanto, los requisitos que no ayudan al proyecto a alcanzar sus objetivos de negocio no
deben ser implementados.
BIMESTRE
En cuanto a la gestión, un proyecto sin una dirección claramente definida y bien comunicada invita al
PRIMER
desastre. Los participantes del proyecto pueden trabajar involuntariamente con fines contradictorios si
tienen diferentes objetivos y prioridades. Los interesados nunca llegarán a un acuerdo sobre los requisitos
si carecen de un entendimiento común de los objetivos de negocio del proyecto. Sin este entendimiento
por adelantado, los plazos del proyecto probablemente se perderán y los presupuestos probablemente
serán superados a medida que el equipo se esfuerza por entregar el producto adecuado.
SEGUNDO
BIMESTRE
En esta unidad se describe el documento de visión y alcance, un entregable que contiene los requisitos
del negocio del proyecto.
3.1. Caso práctico
SOLUCIONARIO
Estimado estudiante, con el fin de canalizar de forma apropiada y coherente las diferentes actividades
que a partir de la presente unidad se abordarán, pongo a disposición un caso de estudio, que servirá para
ir desarrollando a lo largo de la presente guía algunos componentes que requieran especial atención. El
caso en si es hipotético bastante apegado a la realidad de la UTPL. La información que se indica en este
BIBLIOGRÁFICAS
REFERENCIAS
caso, en parte es tomada del portal de la universidad, de proyectos realizados y otra que se asume. Este
caso es publicado exclusivamente con fines académicos. A continuación, se describe el caso.
Desarrollo de un sistema para la gestión de trámites en la UTPL

Acerca de la UTPL
La UTPL es una entidad autónoma con finalidad social y pública, pudiendo impartir enseñanza, desarrollar
investigaciones con libertad científica-administrativa, y participar en los planes de desarrollo del país, otorgar,
reconocer y revalidad grados académicos y títulos profesionales; y en general, realizar las actividades propias ANEXOS
para la consecución de sus fines. Empezó sus actividades en 1971, contando en la actualidad con 72 centros
distribuidos en todo el Ecuador, 3 internacionales y su sede en la ciudad de Loja.

Desarrollo de un sistema para la gestión de trámites en la UTPL

Situación actual
ÍNDICE
La UTPL ofrece dos modalidades de estudio para estudios de pre-grado, la modalidad abierta y a distancia (MAD)
y la modalidad presencial. La modalidad a distancia ofrece carreras que llega a todos los lugares del Ecuador e
incluso a estudiantes que por diferentes motivos han migrado a lugares como Madrid y New York. Para los estudios
de post-grado se ofertan maestrías, tanto profesionalizantes como de investigación. Existen 4 Vicerrectorados
que son los que se encargan de planificar y controlar el desarrollo normal de cada una de las actividades de los
PRELIMINARES
diferentes procesos.
Las carreras de modalidad presencial se ofrecen en la sede en Loja. Los estudios se realizan de forma semestral,
aquellos que ingresar por primera vez tienen que acogerse al proceso de admisión y luego proceder con la
matrícula conjuntamente con los estudiantes antiguos.
Para las actividades de gestión la UTPL dispone de varios sistemas que comparten entre si información de interés.
Los sistemas más importantes que actualmente están funcionando son:
•• Gestión académica
•• Recursos Humanos
BIMESTRE
PRIMER
•• Nómina
•• Contabilidad
•• Becas
•• Inventarios
Problemática
La Dirección Académica se encarga de gestionar todos los trámites que los estudiantes de la MAD realizan desde
SEGUNDO
BIMESTRE
cualquier centro y que tienen que ver con:
•• Cambios de centro.
•• Cambios de lugar y fecha de evaluación.
•• Registro de notas que el profesor olvidó registrar o registró de forma incorrecta.
•• Gestionar una beca.
•• Anulación de matrícula.
SOLUCIONARIO
•• Anulación de asignaturas.
•• Solicitud de diferentes tipos de certificados académicos
•• Cambio de carrera
•• Reconocimiento de estudios
Cada uno de estos trámites requiere de documentos que deben ser entregados en el centro al que pertenece
el estudiante y estos a su vez son enviados a la sede en Loja. Dependiendo del trámite, la dirección académica
BIBLIOGRÁFICAS
REFERENCIAS
canaliza a las instancias correspondientes para que se proceda a resolver tal solicitud. Cada uno de los trámites
requiere de diferente tipo de documentación, de diferentes actores y por ende de diferentes actividades desde que
empieza hasta que finaliza mediante la emisión de una resolución. Entre los problemas más conocidos están:
•• El estudiante no tiene un conocimiento real del proceso del trámite
•• El estudiante desconoce de los requisitos para presentar la solicitud de determinado trámite
•• En los centros asociados no disponen de la información suficiente para asesorar al estudiante
•• Una vez que el estudiante presenta la solicitud del trámite, transcurre demasiado tiempo hasta que se enteran
ANEXOS
del reclamo las instancias correspondientes
•• Sobrecarga de trámites en la dirección académica
•• No se notifica al estudiante sobre requisitos que hacen falta para proceder con la resolución del trámite
•• Muchos de los actores no se enteran oportunamente que tienen que resolver algún trámite
•• Perdida de documentación
•• La resolución del trámite se da a destiempo, etc.
Todos estos trámites al hacerlo de forma manual, requiere de tiempo y el uso de varios recursos. El más afectado es
el estudiante ya que tiene que esperar un tiempo excesivamente largo para saber si le aprobaron o no la solicitud.
Ante esta situación la dirección académica ha creído conveniente desarrollar un sistema para automatizar
estos procesos, donde el estudiante sea el que registre su solicitud en línea, adjuntando toda la documentación
que se requiere de forma digital, y que el sistema gestione de acuerdo al trámite para que se notifique a quien
corresponda el análisis y resolución del mismo.
Con esto se quiere evitar el molestoso envío de la documentación de forma física para ahorrar tiempo, y que al
momento que se registre la solicitud, se notifique de la misma a quienes son responsables del caso; esto permitiría
al estudiante y demás interesados consultar en el sistema del estado del trámite.

3.2. Definir los requisitos de negocio
ÍNDICE
Los requisitos de software operan en tres niveles. Los requisitos relacionados con el negocio, aquellos
relacionados con los usuarios y aquellos que describen al software. En la figura 10, se establecen los
niveles de los requisitos
Los requisitos de negocio se refieren a un conjunto de información que, en conjunto, describe una
PRELIMINARES
necesidad que conduce a uno o más proyectos para entregar una solución y los resultados finales de
negocio deseados. Las oportunidades de negocio, los objetivos de negocio, las métricas de éxito y una
declaración de visión conforman los requisitos del negocio.
Los problemas de requisitos de negocio deben resolverse antes de que los requisitos funcionales y no
funcionales puedan ser completamente especificados. Una declaración del alcance y las limitaciones del
BIMESTRE
proyecto ayuda en gran medida con discusiones sobre las características propuestas y los lanzamientos
PRIMER
de objetivos. Los requisitos del negocio proporcionan una referencia para tomar decisiones sobre los
cambios y mejoras de los requisitos propuestos. Recomendamos presentar los objetivos de negocio,
la visión y los aspectos destacados del alcance en cada sesión de obtención de requisitos para que el
equipo pueda juzgar rápidamente si un requisito propuesto está dentro o fuera del alcance.
SEGUNDO
BIMESTRE
Los requisitos de negocio establecen el contexto y permiten la medición de los beneficios que la empresa
espera obtener de la realización de un proyecto. Las organizaciones no deben iniciar ningún proyecto
sin una comprensión clara del valor que agregará al negocio. Establezca objetivos medibles con los
objetivos de negocio y, a continuación, establezca métricas que le permitan medir si está en camino de
alcanzar esos objetivos.
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS
Figura 10. Niveles de los requisitos

Fuente: Johnson (1995)
Los requisitos de negocios pueden provenir de patrocinadores de fondos, ejecutivos corporativos,

gerentes de marketing o visionarios de productos. Sin embargo, puede ser difícil identificar y comunicar
los beneficios empresariales. Los miembros del equipo a veces no están exactamente seguros de lo
que el proyecto pretende lograr. A veces, los patrocinadores no quieren fijar objetivos de una manera
mensurable y luego ser responsabilizados por lograrlos. Podría haber múltiples actores importantes que
no están de acuerdo en cuáles deberían ser los objetivos. El analista de negocios debe asegurarse que

los interesados estén estableciendo los requisitos del negocio y faciliten la obtención, priorización y
resolución de conflictos.
ÍNDICE
El beneficio del negocio tiene que representar un verdadero valor para los patrocinadores del proyecto
y para los clientes del producto. Por ejemplo, la simple fusión de dos sistemas en uno no es un objetivo
comercial razonable. Los clientes no les importa si están usando una aplicación que involucre 1, 5 o
incluso 10 sistemas. Se preocupan por cuestiones como el aumento de los ingresos y la disminución
PRELIMINARES
de los costos. La fusión de dos sistemas podría ser parte de la solución, pero rara vez es el verdadero
objetivo del negocio. Los proyectos de cumplimiento normativo y legal también tienen objetivos
comerciales claros. A menudo, los objetivos se formulan como evitar el riesgo, posiblemente para evitar
ser demandado o ser puesto fuera del negocio. (Wiegers y Beatty, 2013)
3.3. Visión del producto y alcance del proyecto
BIMESTRE
PRIMER
Dos elementos básicos de los requisitos de negocio son la visión y el alcance. La visión del producto
describe sucintamente el producto final que logrará los objetivos de negocio. Este producto podría
servir como la solución completa para los requisitos del negocio o como sólo una porción de la solución.
La visión del producto asegura que todos conozcan dónde eventualmente se espera ir. El alcance del
SEGUNDO
BIMESTRE
proyecto asegura que todos estén hablando de lo mismo para el proyecto inmediato o la iteración.
Importante
Estimado estudiante, tenga presente que la visión describe lo que el producto es y lo que en
última instancia podría llegar a ser. Proporciona el contexto para tomar decisiones a lo largo
de la vida del producto y alinea a todos los interesados en una dirección común. El alcance
SOLUCIONARIO
del proyecto identifica qué parte de la visión final del producto abordará el proyecto actual o
la iteración de desarrollo. La declaración de alcance dibuja el límite entre lo que está dentro y
lo que está fuera de este proyecto.
La visión se aplica al producto como un todo. La visión cambia con relativa lentitud a medida que el
BIBLIOGRÁFICAS
posicionamiento estratégico de un producto o los objetivos de negocio de una empresa evolucionan
REFERENCIAS
con el tiempo. El alcance se refiere a un proyecto específico o iteración que implementará el siguiente
incremento de la funcionalidad del producto.
El alcance es más dinámico que la visión porque los interesados ajustan el contenido de cada versión
dentro de sus limitaciones de horario, presupuesto, recursos y calidad. El alcance de la versión actual
debe ser claro, pero el alcance de las futuras versiones será más borroso cuanto más lejos se mire. El
objetivo del equipo es administrar el alcance de un proyecto específico de desarrollo o mejora como un ANEXOS
subconjunto definido de la visión estratégica para el producto.
Como resultado del visionamiento se obtiene:
• Asegurar que las definiciones y problemática del producto se alinea con las metas y objetivos del
negocio.
• Identificar los Interesados del producto en forma general.
• Descripción del estado del negocio y cómo los usuarios se beneficiarán cuando el proyecto
termine.
• Facilitar a los miembros del equipo dar una descripción sencilla del proyecto.

Estimado estudiante, para tener una idea más clara de ésta actividad, es necesario responder
a ciertas inquietudes que justifiquen y definan el visionamiento.
ÍNDICE
•• ¿Quién comprará o usará este producto?
•• ¿Qué hará el producto para sus Interesados?
•• ¿Cuáles son las razones para comprar o utilizar este producto?
•• ¿Cuál será el estado operacional o de negocios cuando el producto esté disponible?
•• ¿Cómo se distinguirá en el mercado?
PRELIMINARES
Al responder podríamos tener una idea más clara de la definición de la visión del producto.
En Gottesdiener (2005) se indica una guía para definir de forma adecuada el visionamiento, mediante
los siguientes pasos:
1. Definir los siguiente:
BIMESTRE
PRIMER
• Cliente Objetivo (Target customer
• Declaración de necesidad u oportunidad
• Nombre del producto:
• Categoría del producto:
• Los principales beneficios o las razones convincentes para comprar
SEGUNDO
BIMESTRE
• Principal alternativa competitiva, sistema actual, o proceso manual actual
• Declaración de la diferencia de los productos primarios:
2. Crear la declaración de la visión mediante la introducción de los términos definidos en la siguiente
SOLUCIONARIO
plantilla.
• Para <Cliente objetivo> quien <declaración de la necesidad u oportunidad>, el <nombre

del producto> es un <categoría del producto> que <principales beneficios o razones
convincentes para comprar>.
• A diferencia de <principal alternativa competitiva, sistema actual, o proceso manual
BIBLIOGRÁFICAS
REFERENCIAS
actual>, nuestro producto <declaración de las diferencias del producto primario>.
3. Revisar la declaración de la visión y verificar que se alinea con las metas y objetivos de la
organización.
Adicionalmente es necesario definir la declaración del problema, que consiste en una descripción del
problema actual que la empresa está experimentando y aclara lo que una solución exitosa podría ser. Esto
es útil cuando la solución incluye la ampliación de un software existente o cuando la implementación ANEXOS
del producto crea una necesidad para un proceso de cambio del negocio. Use la siguiente plantilla para
hacer una declaración del problema.
El problema de <Insertar el planteamiento del problema> afecta <nombre de las personas afectadas,
organización, o grupo de clientes>. El impacto de esto es <nombre del impacto (por ejemplo, malas
decisiones, los sobrecostos, información o procesos erróneos, tiempo de respuesta lento a los clientes,
etc)>. Una solución exitosa sería <describir la solución>.
Ejemplo
Estimado estudiante, analice el ejemplo que se indica a continuación en base al caso
práctico. Con esto no quiero decir que es la única forma de hacer la definición de la
visión, sino más bien una de las alternativas para su análisis.

1. Visión
Para personal administrativo y estudiantes de la modalidad de estudios a distancia de la Universidad
ÍNDICE
Técnica Particular de Loja quienes registran y resuelven los trámites que se generan en cada centro
asociado el Sistema de Automatización de trámites es un una aplicación Web que registra las solicitudes
de trámites directamente en el sistema desde cualquier centro, define un flujo de documentación desde
los centros asociados a la sede central, notifica a las personas involucradas en el trámite sobre las tareas
PRELIMINARES
que debe realizar y permite conocer sobre el estado de un trámite en cualquier momento.
A diferencia del proceso actual que requiere que los trámites existentes tienen que enviarse de forma
física a la sede en Loja, no existe un flujo de actividades debidamente controlado para cada trámite y
tanto el estudiante como los involucrados en el trámite no conocen a ciencia cierta sobre el estado del
mismo.
BIMESTRE
PRIMER
2. Problemática
El problema de La atención de trámites académicos y contables que generan los estudiantes no tienen
una adecuada atención, lo que genera excesiva demora en la resolución de los mismos debido a que no
existe un flujo definido para el envío-recepción y a la falta de políticas para su ejecución.
SEGUNDO
BIMESTRE
Afecta a: Estudiantes, Directora MAD, Director Administrativo Financiero, Coordinación Académica
MAD – Loja, Coordinación Académica MAD – CRQ, Directores de Escuela, Contabilidad MAD, Gestión de
Procesos, Atención al Estudiante y Secretarías.
Cuyo impacto es:
SOLUCIONARIO
• El promedio de tiempo para resolver un trámite es alto.
• El estudiante requiere mucha gestión para obtener el resultado de su trámite, causando malestar
e insatisfacción.
• Se desperdicia tiempo, en tareas relacionadas a tratar de ubicar un trámite y conseguir su estado.
BIBLIOGRÁFICAS
REFERENCIAS
• Algunos trámites causan congestión en el proceso de matrículas, pues al no poderse resolver
ágilmente, los estudiantes deben regresar al centro universitario varias veces entorpeciendo
procesos de trabajo importantes (Matrículas).
Una solución satisfactoria permitirá, qué:
• La atención de los casos se realice mediante un sistema de fácil uso, de tal forma de que se dé
solución a todos los trámites. ANEXOS
• Las solicitudes de trámites sean registradas directamente en un sistema.
• Las solicitudes de trámites fluyan electrónicamente hacia a las diferentes personas que deban
revisarlo antes de su resolución.
• La documentación relacionada al trámite esté asociada a éste de forma digital de manera que
pueda ser visualizada directamente en el sistema.
• Se pueda conocer el estado en que se encuentra un trámite.
• Se pueda disponer de estadísticas que permitan tomar decisiones para optimizar los procesos
relacionados.
• Exista seguimiento adecuado de los trámites, estableciendo tiempos de respuesta.

3.3.1. Conflicto en los Requisitos de negocio
Los requisitos empresariales recopilados de fuentes múltiples pueden entrar en conflicto. Los objetivos
ÍNDICE
de los diversos actores a veces están alineados. Sin embargo, algunos objetivos de negocio podrían
entrar en conflicto. El cliente quiere gastar menos tiempo en comprar bienes y servicios, pero el
minorista preferiría que los clientes permanecieran en la tienda y gastaran más dinero. La tensión entre
los interesados con diferentes objetivos y limitaciones puede afectar a los requisitos del negocio. Los
PRELIMINARES
responsables de la toma de decisiones del proyecto deben resolver estos conflictos antes que detallen
los requisitos.
Los responsables de la toma de decisiones del proyecto no deben esperar que el equipo de software
resuelva los conflictos entre los interesados. A medida que aumenten los grupos con intereses diversos,
el alcance crecerá. La expansión incontrolada del alcance en la que los interesados superponen el nuevo
sistema en un intento de satisfacer todos los intereses, puede hacer que el proyecto se derrumbe bajo
BIMESTRE
PRIMER
su propio peso.
Un Analista de negocio puede ayudar a superar potenciales áreas de conflicto y supuestos diferentes,
marcar los objetivos de negocio contradictorios, anotar cuando las características solicitadas no alcanzan
esos objetivos y facilitar la resolución de conflictos. Resolver estas cuestiones es a menudo una lucha
SEGUNDO
BIMESTRE
política y de poder, que requiere de mucha atención.
Los proyectos de larga duración a menudo experimentan un cambio en los encargados de tomar
decisiones a medio camino. Si esto le sucede, revise inmediatamente la línea base de los requisitos
de negocio con los nuevos tomadores de decisiones. Tienen que ser conscientes de los requisitos de
SOLUCIONARIO
negocio existentes, que pueden querer modificar. Si es así, el director del proyecto tendrá que ajustar los
presupuestos, los horarios y los recursos, mientras que el Analista de negocio puede necesitar trabajar
con los interesados para actualizar los requisitos de usuario y funcionales y restablecer sus prioridades.
3.3.2. Documento de Visión y Alcance
BIBLIOGRÁFICAS
El documento de visión y alcance recoge los requisitos del negocio en un único entregable que
REFERENCIAS
prepara el terreno para el posterior trabajo de desarrollo. Algunas organizaciones crean una carta de
proyecto o un documento de Caso de negocios que tiene un propósito similar. Las organizaciones que
construyen software comercial a menudo crean un documento de requisitos de mercado (o marketing).
Un documento de requisitos de mercado considera al detalle los segmentos de mercado objetivo y los
temas que se refieren al éxito comercial.
El propietario del documento de visión y alcance es el patrocinador ejecutivo del proyecto, la autoridad ANEXOS
de financiación o alguien que desempeñe un papel similar. Un analista de negocios puede trabajar con
este individuo para articular los requisitos del negocio y escribir el documento de visión y alcance. Las
entradas para los requisitos de negocio deben venir de las personas que tiene un sentido claro de porqué
están emprendiendo el proyecto. Estas personas pueden incluir a la alta dirección de la organización de
desarrollo o al cliente, un visionario del producto, un gerente de producto, un experto en la materia o
miembros del departamento de marketing.
En concreto el visionamiento es una declaración concisa que resume el propósito a largo plazo y la
intensión del nuevo producto. Esta declaración podría reflejar una vista equilibrada que satisface las
necesidades de diversos Interesados. Desde un punto de vista general puede verse como algo idealista,
pero debe basarse en realidades propias de la organización en la cual se va a desarrollar el producto. Este
visionamiento puede ser parte de otros documentos como por ejemplo en el documento de inicio del
proyecto, en alguna carta del proyecto, pero principalmente en el documento de visión del proyecto.

En la tabla 7 se sugiere una plantilla para la visión y alcance. Como con cualquier plantilla, ésta se puede
adaptar para satisfacer las necesidades específicas de los proyectos. Si ya existe algo de esta información
ÍNDICE
en otro lugar, no lo duplique en el documento de visión y alcance. Algunos elementos del documento
de visión y alcance pueden ser reutilizables de un proyecto a otro, tales como los objetivos de negocio,
los riesgos de negocio y los intereses de los interesados. El Anexo 2 se incluye un ejemplo de documento
de visión y alcance escrito de acuerdo con esta plantilla.
PRELIMINARES
Tabla 6.
Plantilla sugerida para documentar la visión y alcance del proyecto
•• Requisitos de negocio
ÂÂ Antecedentes
ÂÂ Oportunidad de negocio
ÂÂ Objetivos de negocio
BIMESTRE
PRIMER
ÂÂ Métricas de éxito
ÂÂ Declaración de la visión
ÂÂ Suposiciones y dependencias de negocio
•• Alcance y limitaciones
ÂÂ Características principales
ÂÂ Alcance y versión inicial
SEGUNDO
ÂÂ Alcance y liberación posterior
BIMESTRE
ÂÂ Limitaciones y exclusiones
•• Contexto de negocio
ÂÂ Perfil de los interesados
ÂÂ Prioridades del proyecto
ÂÂ Consideraciones de despliegue
SOLUCIONARIO
Buscar en la web
Examine otras plantillas que se utilizan para documentar la visión del producto, considere
procesos de desarrollo y metodologías, por ejemplo, la plantilla que utiliza RUP.
BIBLIOGRÁFICAS
REFERENCIAS
3.4. Técnicas para representar el alcance
Existe diferentes modelos que se pueden utilizar para representar el alcance del proyecto de varias
ANEXOS
maneras. No es necesario crear todos los modelos; Considere cuáles proporcionan la visión más útil para
cada proyecto. Los modelos pueden incluirse en el documento de visión y alcance o almacenarse en otro
lugar y referenciarse según sea necesario.
El propósito de herramientas como el diagrama de contexto, el mapa del ecosistema, el árbol de

características y la lista de eventos es fomentar una comunicación clara y precisa entre los interesados del
proyecto. Esa claridad es más importante que adherirse dogmáticamente a las reglas para un diagrama
“correcto”. Sin embargo, le recomendamos encarecidamente que adopte las normas ilustradas en los
siguientes ejemplos como normas para dibujar los diagramas. Por ejemplo, en un diagrama de contexto,
supongamos que utiliza un triángulo para representar el sistema en lugar de un círculo, y óvalos en lugar
de rectángulos para entidades externas. Sus colegas tendrían dificultad para leer un diagrama que sigue
sus preferencias personales en lugar de un estándar de equipo.
Los diagramas de contexto, mapas de ecosistemas, árboles de características y listas de eventos son
las formas más comunes de representar visualmente el ámbito. Sin embargo, también se utilizan otras
técnicas. A continuación, se detallan estas técnicas.

3.4.1. Diagrama de contexto
En la descripción del alcance se establecen los límites y las conexiones entre el sistema que está
ÍNDICE
desarrollando y todo lo demás en el universo. El diagrama de contexto ilustra visualmente este límite.
Identifica entidades externas fuera del sistema que interactúan con él de alguna manera, así como
datos, control y flujos de materiales entre las entidades y el sistema. Un diagrama de contexto muestra
al sistema en su entorno, con las entidades externas (es decir, personas y sistemas) que proporcionan y
PRELIMINARES
reciben información o material desde y hacia el sistema. El diagrama de contexto es el nivel superior en
un diagrama de datos desarrollado de acuerdo con los principios del análisis estructurado, pero es un
modelo útil para todos los proyectos.
El diagrama de contexto se lo utiliza para que los Interesados ayuden de forma rápida y simple a definir
el alcance del proyecto, y centrarse en los insumos que necesita el sistema, así como las salidas que
ofrece. El diagrama de contexto ayuda al equipo de desarrollo a obtener modelos de requisitos (por
BIMESTRE
PRIMER
ejemplo, los actores, casos de uso, y la información de los datos del modelo) y pueden surgir posibles
problemas de alcance como nuevas entidades externas.
En la Figura 11 se ilustra el diagrama de contexto para el Sistema de Gestión de Trámites de la UTPL

(SGT-UTL). Todo el sistema se representa con un solo círculo; El diagrama de contexto no proporciona
SEGUNDO
BIMESTRE
deliberadamente visibilidad de los objetos, procesos o datos internos del sistema. El “sistema” dentro
del círculo podría abarcar cualquier combinación de software, hardware y componentes humanos. Por
lo tanto, podría incluir operaciones manuales como parte de todo el sistema. Las entidades externas
en los rectángulos pueden representar clases de usuario (Estudiante, Profesor y Secretaria MAD),
organizaciones (Entidad bancaria), otros sistemas (SGA) o dispositivos de hardware. Las flechas en el
SOLUCIONARIO
diagrama representan el flujo de datos (como Datos estudiante) o artículos físicos entre el sistema y sus
entidades externas.
SGA
BIBLIOGRÁFICAS
Entidad bancaria
REFERENCIAS
Actualizar expediente
Datos estudiante
Orden de pago
Estudiante Documentos
Detalle del pago
Notifica el estado
SGT-UTPL ANEXOS
Factura Contabilidad
Estadísitcas
Resolución
Parámetros para trámite

Notifica sobre trámite
Secretaría MAD Profesor
Simbología
Flujo de datos Sistema Entidad externa
Figura 11. Diagrama de contexto para el sistema de trámites de la UTPL

En Gottesdiener (2005) se especifica los siguientes pasos para construir un diagrama de contexto:
1. Dibuje un circulo para representar al sistema y etiquete con el nombre del sistema.
ÍNDICE
2. Identifique las entidades externas.
• Identifique las personas o cosas (comúnmente otros sistemas o dispositivos físicos), que
PRELIMINARES
obtienen alguna cosa del sistema, o que aportan con alguna cosa al sistema. Dibuje estas
entidades externas como cajas y etiquételas.
• Revise el nombre de los usuarios directos e indirectos de la lista de interesados por posibles
entidades externas.
3. Añadir los flujos de información
BIMESTRE
PRIMER
• Dibuje una línea con punta de flecha para representar un flujo de información, consulta u
objeto (por ejemplo: reportes, datos, facturas, etc.) que entran o salen del sistema, por cada
entidad.
• Etiquete usando los flujos de información.
• Busque múltiples flujos de entrada y entidades externas con similares etiquetas, ya que
SEGUNDO
BIMESTRE
podrían ser la misma cosa que pueden ser generalizados en una sola etiqueta.
4. Luego de construir otros modelos de análisis (como es: glosario, tabla evento-respuesta, tabla
de actores y casos de uso) verifique estos contra el diagrama de contexto y de ser necesario
corregirlos.
SOLUCIONARIO
• Involucre al patrocinador, especialistas, y usuarios directos en la revisión.
• Asegúrese que cada flujo de entrada y el correspondiente flujo de salida es necesario para
alcanzar los objetivos del proyecto.
• Actualice la lista de Interesados por cada nuevo usuario directo o indirecto.
BIBLIOGRÁFICAS
• Defina algún nuevo nombre o flujo de información en el glosario.
REFERENCIAS
Importante
Estimado estudiante, recuerde que un cambio en el diagrama de contexto implica un cambio
en el alcance, que puede afectar al plan del proyecto, cumplimiento de fechas, y recursos
del proyecto. Tiene que estar seguro que el patrocinador, especialista y gerentes están de
acuerdo de cualquier cambio y que los procesos de control de cambio de requisitos manejen
esta situación.
ANEXOS
El diagrama de contexto, con respecto a otros modelos:
• Los flujos de entrada equivalen a los eventos de negocio en la tabla evento-respuesta.

• Los flujos de salida equivalen a las respuestas en la tabla evento-respuesta.
• Las entidades humanas externas pueden convertirse en actores.
• Los flujos de entrada pueden estar asociados con uno o más casos de uso.
• Los nombres de las etiquetas de los flujos pueden convertirse en entidades de datos o atributos
en el modelo de datos.
• Los nombres en los flujos de entrada pueden convertirse en nombres generalizados que son
detallados en el diccionario de datos.

Para proyectos grandes o aquellos en que el alcance no es claro, crear un diagrama de contexto
independiente que represente a toda la lista de entidades externas y flujos de información que los
ÍNDICE
usuarios podrían gustarles ver incluidos en el proyecto. Seguidamente revise los objetivos del proyecto
y la declaración de la visión y filtre aquellas entidades externas y los flujos de información que considere
no permiten obtener logros. Actualice el diagrama de contexto como el sistema “va a ser”.
3.4.2. Mapa de ecosistema
PRELIMINARES
Un mapa del ecosistema muestra todos los sistemas relacionados con el sistema de interés que interactúan
entre sí y la naturaleza de esas interacciones. Un mapa del ecosistema representa el alcance de todos los
sistemas que se interconectan y que por lo tanto necesitarán ser modificados para acomodarse al nuevo
sistema.
Los mapas del ecosistema difieren de los diagramas de contexto, ya que muestran otros sistemas
BIMESTRE
PRIMER
que tienen una relación con el sistema en el que está trabajando, incluyendo aquellos que no tienen
interfaces directas. Puede identificar los sistemas afectados determinando cuáles consumen datos de su
sistema. Cuando llegue al punto en que su proyecto no afecta a los datos adicionales, ha identificado el
límite del ámbito de los sistemas que participan en la solución.
3.4.3. Árbol de características
SEGUNDO
BIMESTRE
Un árbol de características es una representación visual de las características del producto organizadas
en grupos lógicos, subdividiendo jerárquicamente cada característica en otros niveles de detalle. El
árbol de características proporciona una vista concisa de todas las características planificadas para un
proyecto, lo que lo convierte en un modelo ideal para mostrar a los ejecutivos que quieren un rápido
SOLUCIONARIO
vistazo al alcance del proyecto. Un árbol de características puede mostrar hasta tres niveles de funciones,
comúnmente llamadas nivel 1 (L1), nivel 2 (L2) y nivel 3 (L3). Las características L2 son sub-funciones de
las características L1 y las características L3 son sub-funciones de las características L2.
3.4.4. Lista de eventos
BIBLIOGRÁFICAS
REFERENCIAS
Una lista de eventos identifica eventos externos que pueden provocar un comportamiento en el sistema.
La lista de eventos representa el límite del ámbito para el sistema al nombrar eventos empresariales
posibles desencadenados por usuarios, eventos temporales (temporales) o eventos de señal recibidos
de componentes externos, como dispositivos de hardware. La lista de eventos sólo nombra los eventos;
Los requisitos funcionales que describen cómo responde el sistema a los eventos se detallarán en el SRS
mediante el uso de tablas de evento-respuesta.
ANEXOS
Buscar en la web
Estimado estudiante, busque en la web, herramientas que permitan hacer modelado
UML en las cuales se puedan construir los diagramas de contexto. Analice las diferentes
representaciones que utilizan.
3.5. Visión y alcance en proyectos ágiles
La gestión del ámbito en un proyecto ágil, en el que el desarrollo se lleva a cabo en una serie de
iteraciones de horario fijo, adopta un enfoque diferente. El alcance de cada iteración consiste en historias
de usuarios seleccionadas de un backlog dinámico de productos, basadas en su prioridad relativa y en la
capacidad de entrega estimada del equipo para cada timebox. En lugar de intentar reducir el alcance, el

equipo prioriza los nuevos requisitos contra los elementos existentes en el backlog y los asigna a futuras
iteraciones. El número de iteraciones -y por lo tanto la duración total del proyecto- sigue dependiendo
ÍNDICE
de la cantidad total de funcionalidad que se va a implementar, pero el alcance de cada iteración se
controla para asegurar oportuna su finalización. (Wiegers y Beatty, 2013)
Algunos proyectos ágiles fijan la duración total del proyecto, pero están dispuestos a modificar el ámbito.
El número de iteraciones podría permanecer igual, pero el ámbito tratado en las iteraciones restantes
PRELIMINARES
cambia de acuerdo con las prioridades relativas de las historias de usuarios existentes y definidas
recientemente.
El equipo puede definir un itinerario de iteraciones de alto nivel al comienzo del proyecto, pero la
asignación de la historia del usuario para una iteración se realizará al comienzo de cada iteración. Hacer
referencia a los requisitos del negocio a medida que el equipo establece el alcance de cada iteración
ayuda a asegurar que el proyecto entrega un producto que cumpla con los objetivos de negocio.
BIMESTRE
PRIMER
Aunque en los proyectos ágiles no crean un documento formal de visión y alcance, el contenido de la
plantilla de la tabla 6 es relevante y esencial para desarrollar un producto exitoso. Muchos proyectos
ágiles realizan una iteración de planificación inicial (iteración cero) para definir la visión general del
producto y otros requisitos del negocio para el proyecto.
SEGUNDO
BIMESTRE
Los requisitos de negocios deben definirse para todos los proyectos de software, independientemente
de su enfoque de desarrollo. Los objetivos de negocio describen el valor esperado que se obtendrá del
proyecto, y en un proyecto ágil, se utilizan para ayudar a priorizar el backlog para entregar el mayor
valor de negocio en las iteraciones más tempranas. Las métricas de éxito deben definirse de manera que
SOLUCIONARIO
a medida que las emisiones iterativas se activen, se puede medir y el resto del backlog se ajuste. Una
declaración de la visión describe el plan a largo plazo para lo que será el producto después de que todas
las iteraciones estén completas. (Wiegers y Beatty, 2013)
BIBLIOGRÁFICAS
REFERENCIAS
Hemos finalizado el estudio de la unidad 3, se recomienda el desarrollo de las siguientes
actividades
•• Identifique y describa un “caso local”. Redacte un documento en el que conste información
ANEXOS
general (Tome como referencia el caso práctico definido en el literal 3.1)
•• Parametrice el documento de Visión, que utiliza RUP
•• Desarrolle el diagrama de contexto del caso local
•• Defina el visionamiento y problemática del caso local
Estrategias de desarrollo
•• Busque en la web, la plantilla RUP.
•• Lamsweerde, A., (2009). Requirements Engineering: from system goals to UML models to
software Specifications. Inglaterra. Editorial Wiley
•• Wiegers, K., & Beatty, J. (2013). Software Requirements. Washington: Microsoft Press.
•• Martín, J., López, L. (2014). UML Práctico: Aprende UML paso a paso. Primera edición.

Autoevaluación 3
ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
1. En el visionamiento el “Cliente objetivo”, se refiere a:
a. Describir lo que hace el cliente

b. Las personas que usarán o comprarán el software
c. Quienes afecta el problema
SEGUNDO
BIMESTRE
2. En la definición de la problemática en la parte de “Afecta a:”, se debe incluir:
a. Los sistemas afectados

b. Los analistas
SOLUCIONARIO
c. Personas, organización o clientes
3. Cuando el analista describe las definiciones y la problemática del producto de acuerdo a las metas
y objetivos del negocio, entonces ha logrado realizar:
a. El visionamiento
BIBLIOGRÁFICAS
REFERENCIAS
b. La especificación
c. la validación
4. Cuando se ha detectado el riesgo “Expectativas poco realistas de los clientes”, la mejor alternativa
para mitigar sería:
a. Crear la visión del producto ANEXOS

b. Priorizar requerimientos
c. Formalizar el documento de visión
5. Cuando se ha detectado el riesgo “Falta de participación del usuario”, la mejor alternativa para
mitigar sería:
a. Crear un plan de participación de interesados

b. Desarrollar modelos de alcance
c. Formalizar el documento de visión

Lea detenidamente cada una de las declaraciones, y responda con V si es Verdadera o una F si es
Falsa.
ÍNDICE
6. ( ) Los requisitos de negocio y usuario se definen desde la perspectiva del usuario
7. ( ) El patrocinador del proyecto es uno de los que define los requisitos de negocio
PRELIMINARES
8. ( ) La declaración de la problemática como una ampliación al visionamiento es necesario
cuando la solución que va a desarrollar necesita hacer un cambio en el proceso actual.
9. ( ) El visionamiento y la problemática para proyecto pequeños y medianos son la misma

cosa
10. ( ) El diagrama de contexto permite determinar los procesos de negocio de la
BIMESTRE
PRIMER
organización
Recuerde que el solucionario se encuentra al final del presente texto guía.
SEGUNDO
BIMESTRE
SOLUCIONARIO
Ir a solucionario
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS

UNIDAD 4. Obtención de requisitos
ÍNDICE
Estimado estudiante
Una de las actividades más cruciales y desafiantes en el desarrollo de proyectos de software es la obtención
de la información necesaria para especificar los requisitos para la aplicación propuesta. En esta unidad se
PRELIMINARES
abordará la primera fase del proceso de desarrollo de requisitos, la Obtención o Elicitación que consiste
en identificar las fuentes de obtención de información, para luego utilizar la técnica más apropiada que
permita cumplir con el objetivo. La obtención de requisitos es una actividad humana intensa que se basa
en la participación de los Interesados, como fuente principal de obtención de requisitos.
4.1. Obtención
BIMESTRE
PRIMER
El núcleo del desarrollo de los requisitos es la obtención, el proceso de identificación de las necesidades
y limitaciones de los distintos grupos de interés para un sistema de software. obtención no es lo mismo
que “recolectar los requisitos”. Tampoco es una simple cuestión de transcribir exactamente lo que dicen
los usuarios. La obtención es un proceso colaborativo y analítico que incluye actividades para recolectar,
SEGUNDO
BIMESTRE
descubrir, extraer y definir requisitos. La obtención se utiliza para descubrir los requisitos de negocio, de
usuario, funcionales y no funcionales, junto con otros tipos de información. La obtención de requisitos
es quizá el aspecto más desafiante, crítico, propenso a errores y de comunicación intensiva del desarrollo
de software.
SOLUCIONARIO
Involucrar a los usuarios en el proceso de obtención es una forma de obtener soporte y apoyo para el
proyecto. Si usted es el analista de negocios, trate de entender los procesos de pensamiento detrás
de los requisitos de los usuarios. Recorrer los procesos que los usuarios siguen para tomar decisiones
sobre su trabajo, y extraer la lógica subyacente. Asegúrese de que todo el mundo entiende por qué el
sistema debe realizar ciertas funciones. Busque los requisitos propuestos que afectan a procesos o reglas
empresariales obsoletos o ineficaces que no deben ser incorporados en el nuevo sistema.
BIBLIOGRÁFICAS
REFERENCIAS
Los analistas de negocio deben crear un entorno propicio para una exploración minuciosa del producto
que se especifique. Para facilitar una comunicación clara, utilice el vocabulario del dominio empresarial
en lugar de forzar a los clientes a entender la jerga técnica. Registre términos significativos de dominio
de aplicación en un glosario, en lugar de asumir que todos los participantes comparten las mismas
definiciones. Los clientes deben entender que una discusión acerca de la posible funcionalidad no es un
compromiso para incluirla en el producto. La lluvia de ideas y la imaginación de las posibilidades es un
ANEXOS
asunto aparte del análisis de prioridades, la viabilidad y las realidades restrictivas.
El resultado del desarrollo de los requisitos es una comprensión común de las necesidades por las
diversas partes interesadas del proyecto. Cuando los desarrolladores entienden esas necesidades,
pueden explorar soluciones alternativas para abordarlas. Los participantes en la obtención deben resistir
la tentación de diseñar el sistema hasta que entiendan el problema. De lo contrario, pueden esperar
hacer considerables reelaboraciones de diseño a medida que los requisitos se vuelvan más adecuados.
Enfatizar las tareas del usuario en lugar de las interfaces de usuario y centrarse en las necesidades reales
más que en los deseos expresados, ayudan a evitar que el equipo se desvíe al especificar prematuramente
los detalles del diseño.

ÍNDICE
PRELIMINARES
Figura 12. El ciclo natural de los requisitos
Como se muestra en la figura 12, la naturaleza del desarrollo de requisitos es cíclica. Usted hará una
cierta obtención, estudiará lo qué aprendió, escribirá algunos requisitos, quizás determinará que está
BIMESTRE
PRIMER
faltando cierta información, entonces realice la obtención, y así sucesivamente. No espere sólo hacer un
par de talleres de obtención y luego declarar la victoria y seguir adelante. En la figura 4.2 se muestra las
actividades para realizar la obtención, desde la planificación de las actividades hasta la organización de
los resultados.
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
Figura 13. Actividades para una única sesión de obtención de requisitos
Fuente: Gottesdiener (2005)
Antes de analizar al detalle los pasos para realizar la obtención, vamos a estudiar algunas de las técnicas
más eficaces para hacer la Obtención.
ANEXOS
4.2. Técnicas de Obtención de requisitos
Numerosas técnicas de obtención se pueden emplear en proyectos de software. De hecho, ningún

equipo de proyecto debe esperar utilizar sólo una técnica de obtención. Siempre hay muchos tipos
de información que hay que descubrir, y diferentes actores prefieren diferentes enfoques. Un usuario
podría ser capaz de articular claramente cómo utiliza el sistema, mientras que puede que tenga que
observar a otro que realiza su trabajo para alcanzar el mismo nivel de comprensión.
Las técnicas de obtención incluyen las actividades facilitadoras en las que se intercala con los interesados
para obtener requisitos, también están las actividades independientes en las que se trabaja por su cuenta
para descubrir información. Las actividades facilitadoras se centran principalmente en descubrir las
necesidades del negocio y los usuarios. Trabajar directamente con los usuarios es necesario porque los
requisitos del usuario abarcan las tareas que los usuarios necesitan para llevar a cabo con el sistema. Para

obtener los requisitos del negocio, tendrá que trabajar con personas como el patrocinador del proyecto.
Las técnicas de obtención independientes complementan los requisitos que los usuarios presentan y
ÍNDICE
revelan la funcionalidad necesaria que los usuarios finales podrían no ser conscientes. La mayoría de
los proyectos utilizarán una combinación de actividades de obtención facilitadas e independientes.
Cada técnica ofrece una exploración diferente de los requisitos o incluso podría revelar requisitos
completamente diferentes. A continuación, se describen varias técnicas comúnmente utilizadas para
obtener los requisitos.
PRELIMINARES
4.2.1. Entrevistas
La manera más obvia de encontrar lo que necesitan los usuarios de un sistema de software es preguntarles.
Las entrevistas son consideradas una de las técnicas de mayor importancia para la captura de requisitos
ya que es una de las formas de comunicación más naturales entre las personas. El propósito de una
entrevista está orientado a establecer un enfoque sistemático diseñado para obtener información de
BIMESTRE
PRIMER
una persona o grupo de personas en un ambiente formal o informal, haciendo preguntas pertinentes
y apropiadas. Las entrevistas son conversaciones cara a cara en la que un entrevistador hace preguntas
para obtener información del entrevistado. De acuerdo con Gottesdiener (2005) las entrevistas pueden
ser de dos tipos: estructuradas (con preguntas preparadas con anterioridad), o no estructuradas (sin
preguntas predefinidas).
SEGUNDO
BIMESTRE
Entrevistas estructuradas
Se dan cuando el entrevistador ha elaborado un conjunto de preguntas acorde a un propósito asociado

con el entrevistado. Algunas de las preguntas pueden ser abiertas o preguntas en donde la respuesta
SOLUCIONARIO
tenga un conjunto de posibilidades conocidas.
Entrevistas no estructuradas
Donde el entrevistado y el entrevistador sin ninguna pregunta predefinida discuten de temas de interés
abiertamente.
BIBLIOGRÁFICAS
REFERENCIAS
Para que una entrevista sea exitosa depende de los siguientes factores:
• Nivel de comprensión del dominio por parte del entrevistador

• La experiencia del entrevistador
• Habilidad del entrevistador en la documentación de los debates
• Disposición del entrevistado para proporcionar la información pertinente
• Grado de claridad del entrevistado acerca de lo que la empresa requiere del sistema ANEXOS
• Armonía entre el entrevistador y el entrevistado
Los pasos para realizar una entrevista son:
1. Identificar las personas que le gustaría entrevistar
• Elija una parte representativa de personas. Incluya al patrocinador, clientes, y usuarios con
experiencia en el tema.
• Asegúrese que los entrevistadores se sentirán a gusto entrevistando a directivos y clientes,

y viceversa.

2. Prepare las preguntas de la entrevista
• Aclare el objetivo de cada entrevista (por ejemplo: para obtener información de antecedente
ÍNDICE
y características de alto nivel del software, o para obtener un conocimiento detallado del
flujo de trabajo del usuario o las necesidades de datos).
• Elabore las preguntas de la entrevista desde lo general a lo más particular. Organice de forma
PRELIMINARES
fácil empezando con preguntas de hecho. (por ejemplo: ¿Cuál ha sido su participación en
el proyecto hasta la fecha? Al final las preguntas más difíciles como por ejemplo preguntas
de interpretación. En este aspecto debe adaptar las preguntas para captar la atención del
entrevistado. Para un alto ejecutivo o a los clientes, pregunte, “¿Por qué es este proyecto (o
software) importante para usted (o sus clientes)?” O “¿Qué debe hacer este producto para
que usted lo llame exitoso?, Para los usuarios que van a interactuar directamente con el
software, por ejemplo, “¿Hábleme de su forma ideal de <realizar una tarea>?”.
BIMESTRE
PRIMER
• Incluya preguntas de contexto libre (preguntas de alto nivel sobre el producto y el proceso)
al inicio de la entrevista y todas las entrevistas abiertas. Esto permite entender el panorama.
Por ejemplo:
§§ ¿Qué problema resuelve este sistema?  
SEGUNDO
BIMESTRE
§§ ¿Qué problemas puede crear este sistema?  
§§ ¿Cuál es el ambiente que se encuentra este sistema?  
§§ ¿Qué grado de precisión es requerido o deseado en este producto?  
SOLUCIONARIO
• Incluir meta-preguntas (preguntas acerca de preguntas) que le permitan ajustar sus
preguntas durante la entrevista. Por ejemplo:
§§ ¿Estoy haciendo demasiadas preguntas?

§§ ¿Mis preguntas son relevantes?
BIBLIOGRÁFICAS
§§ ¿Es usted la persona adecuada para responder estas preguntas?
REFERENCIAS
§§ ¿Quién más podría responder estas preguntas?
§§ ¿Hay algo más que le podría preguntar o responder?
3. Programe la entrevista y organice la logística para la reunión.
• Encuentre un lugar donde la entrevista no sea interrumpida.

ANEXOS
• Prepare a los entrevistados. Indique el objetivo de la entrevista, si es posible proporcione
las preguntas de la entrevista con uno o más días de anticipación. Además, pídales a reunir
todos los documentos que pueden ser útiles para consultar durante la entrevista (por
ejemplo, manuales, referencias, planes o informes).
• Asegúrese de que los entrevistadores están familiarizados con la terminología de la empresa.

Comparta un glosario con los entrevistados para asegurar que están de acuerdo con los
términos y definiciones.
• Asegúrese de comunicar al entrevistado cuánto tiempo tomará la entrevista. Típicamente

una entrevista debería durar entre 45 y 60 minutos.

4. Realizar la entrevista
• Preséntese y realice una pregunta inicial.  
ÍNDICE
• Indique a las personas entrevistadas que usted tomará notas durante la entrevista.  
• Practique la escucha activa. Por ejemplo, repetir las respuestas en sus propias palabras y
PRELIMINARES
mantenga sus ojos comprometidos con el entrevistado.  
• Evite preguntas capciosas (Por ejemplo, ¿No cree usted que...? O ¿por qué no hace sólo ...?  
• Sea flexible, haciendo las preguntas necesarias.  
• Finalice la entrevista con un agradecimiento, e indique los siguientes pasos que realizará.
BIMESTRE
Pida permiso para hacer el seguimiento de las preguntas si fuera necesario. 
PRIMER
5. Documente los resultados
• Revise sus notas inmediatamente después de la entrevista, cuando la información está aún
“fresca” en su mente.  
SEGUNDO
BIMESTRE
• Conjuntamente con los entrevistados para resolver algún conflicto de información.  
• Analizar sus notas de varias entrevistas para descubrir patrones y conflictos.  
• Generar un conjunto de modelos o necesidades de forma textual para revisiones preliminares
SOLUCIONARIO
por parte del equipo, basado en las entrevistas.
Importante
Estimado estudiante, recuerde que hacer una grabación de audio y video puede
parecer eficaz, pero generalmente no lo son. El tiempo que tarda en escuchar o ver cada
entrevista y tomar notas es mal utilizado. Use cinta solo si desea aprender sobre estilos
BIBLIOGRÁFICAS
REFERENCIAS
de entrevista o si los comentarios incluidos son importantes para su proyecto. Si usted
decide grabar las entrevistas debe obtener el permiso del entrevistado previamente.
4.2.2. Talleres
Los talleres fomentan la colaboración de los interesados en la definición de los requisitos. Gottesdiener
(2005) define un taller de requisitos como “una reunión estructurada” en la que un grupo cuidadosamente
seleccionado de interesados y expertos en el tema trabajan juntos para definir, crear, refinar y alcanzar los ANEXOS
entregables de cierre (como modelos y documentos). Los talleres son sesiones facilitadas con múltiples
actores y roles formales, como es el facilitador y el escritor. Los talleres a menudo incluyen varios
tipos de interesados, desde usuarios hasta desarrolladores y probadores. Se utilizan para obtener los
requisitos de múltiples Interesados simultáneamente. Trabajar en un grupo es más eficaz para resolver
los desacuerdos que hablar con las personas individualmente. Además, los talleres son útiles cuando se
necesita un cambio urgente de obtención debido a restricciones de horario.
El facilitador juega un papel crítico en la planificación del taller, seleccionando a los participantes y
guiándolos hacia un resultado exitoso. Los analistas de negocios frecuentemente facilitan talleres de
obtención. Cuando un equipo está comenzando con nuevos enfoques para la obtención de requisitos,
considere la posibilidad de tener un facilitador externo o un segundo analista de negocio para los talleres
iniciales.

De esta manera, el analista de negocio puede dedicar toda su atención a la discusión. Si el único analista
de negocio también actúa como facilitador, debe tener en cuenta cuándo habla como facilitador y
ÍNDICE
cuando participa en la discusión. Un escritor ayuda al facilitador capturando los puntos que surgen
durante la discusión. Es extremadamente difícil facilitar, escribir, y participar simultáneamente y hacer
un buen trabajo de los tres.
Los talleres pueden ser intensivos en recursos, a veces se requiere de numerosos participantes durante
PRELIMINARES
varios días a la vez. Deben estar bien planificados para evitar perder tiempo. Minimizar el tiempo
perdido al entrar en un taller con borradores de materiales preparados con antelación. Por ejemplo,
puede redactar casos de uso que pueden revisarse como un grupo en lugar de que el grupo completo
los prepare juntos. Rara vez tiene sentido iniciar un taller con una pizarra completamente en blanco.
Utilizar otras técnicas de obtención antes de los talleres, y luego reunir a los interesados para trabajar
sólo en las áreas necesarias.
BIMESTRE
PRIMER
Para tener éxito en la realización de un taller, en Gottesdiener (2005) se recomienda seguir los siguientes
pasos:
1. Determinar el propósito del taller y los participantes
• Escribir una declaración concisa del propósito del taller (Por ejemplo: “Para definir el alcance”
SEGUNDO
BIMESTRE
o “Para detallar los requisitos de usuario”).
• Elabore un subconjunto de declaración de requisitos o modelos de análisis antes del taller.
• Definir los roles (por ejemplo: participantes: usuarios y expertos en la materia, facilitador,
SOLUCIONARIO
grabadora, patrocinador y observadores) que las personas podrían desempeñar en el taller.
• Mantenga talleres pequeños. Preferible una docena o menos participantes.
• Utilice un experto, facilitador neutral, especialista si dispone de un grupo grande o hay

muchos problemas políticos o conflictos. Un facilitador con alta experiencia podría
BIBLIOGRÁFICAS
REFERENCIAS
anticiparse a los obstáculos y planificar de forma coordinada.
• Haga que el facilitador entreviste algunos o todos los participantes antes del taller, aprenda
lo suficiente para planificar el taller y confirme el propósito.
2. Identifique las reglas del taller
• Pida al facilitador que indique las reglas de los participantes al inicio del taller. Las reglas ANEXOS
más comunes, por ejemplo:
§§ Iniciar y finalizar a tiempo

§§ Estar preparados
§§ Centrarse en los intereses y no en las posiciones
§§ Compartir toda la información relevante
§§ ¡Participa!
• Confirmar las reglas. Asegúrese que los propios participantes hagan cumplir las reglas, con
la ayuda del facilitador.
• Defina reglas de decisión y un proceso de toma de decisiones para el taller. Por ejemplo: “La
persona a cargo toma la decisión final después de consultar al grupo”.

3. Defina los entregables del taller
• Incluya entregables tangibles (como son los modelos de análisis), como también modelos
ÍNDICE
intangibles (como son las decisiones).
• Determine cómo va a saber cuándo los entregables son bastante buenos. Hacer que los
resultados sean lo suficientemente específicos.
PRELIMINARES
4. Diseñe la agenda
• Crear una agenda que abra el taller, conduzca actividades de descubrimiento de

requerimientos, y cierre el taller.
• Envíe la agenda a los participantes antes del taller.
BIMESTRE
PRIMER
• Pida a los participantes traer los documentos importantes de la empresa.
5. Conduzca la sesión
• Pregunte al patrocinador del proyecto o al interesado senior del proyecto abrir la reunión
SEGUNDO
BIMESTRE
con una breve descripción del propósito del taller.
• Planifique utilizar varios modos de interacción con el participante. Haga que interactúen
con todo el grupo y en grupos pequeños. También haga que los participantes trabajen
solos a veces para enumerar, priorizar o revisar las entregas del grupo. Haga que la gente
SOLUCIONARIO
trabaje en diferentes grupos pequeños para aprender de aquellos que tienen experiencia.
A medida que el participante se vuelve más productivo, use múltiples subgrupos de forma
simultanea para obtener modelos de requisitos.
• Use una variedad de medios y herramientas para captar el interés de las personas durante
la reunión.
BIBLIOGRÁFICAS
REFERENCIAS
• Usar escenarios (para transmitir ejemplos o historias de uso del sistema) para pasar por
otros modelos de requisitos (como es casos de uso, reglas de negocio y modelos de datos)
y ayudar a descubrir los requisitos faltantes y erróneos durante el taller.
• Use herramientas adecuadas (portátil, proyector e impresora) para que los participantes
puedan revisar la información inmediatamente y compartir en el grupo.
ANEXOS
• Hacer una corta retrospectiva de forma periódica en el taller para tener una retroalimentación
del mismo.
• Imprima las entregas de los talleres a medida que las crea compruebe que las entregas sean
completas y comprensivas antes de agregar más detalles a las mismas.
• Pedir al sponsor e interesados clave para que se unan al final del taller para permitir a los
participantes presentar los resultados y compartir problemas que necesitan ser resueltos.
• Cierre el taller asignando cuestiones pendientes a participantes específicos con fechas de

vencimiento y planes de comunicación. Defina los siguientes pasos a seguir y realice una
retrospectiva final del taller.

6. Seguimiento a los hechos, próximos pasos y acciones
• Hacer responsables a los participantes de dar seguimiento a las tareas asignadas.
ÍNDICE
• Evaluar el taller luego de completar la obtención de requisitos. Analizar su utilidad para
el proceso de obtención de requisitos y su valor para el proyecto en general. Use esta
información para adaptar sus prácticas de talleres de requisitos.
PRELIMINARES
4.2.3. Grupo de enfoque
Un grupo de enfoque es un conjunto representativo de usuarios que se reúnen en una actividad

facilitadora para generar información e ideas sobre los requisitos funcionales y de calidad de un
producto. Las sesiones de grupo de enfoque deben ser interactivas, permitiendo a todos los usuarios
la oportunidad de expresar sus pensamientos. Los grupos focales son útiles para explorar las actitudes,
BIMESTRE
PRIMER
impresiones, preferencias y necesidades de los usuarios. Son especialmente valiosos si está desarrollando
productos comerciales y no tiene acceso fácil a los usuarios finales dentro de su empresa.
A menudo, tendrás una base de usuarios amplia y diversa para escoger, así que seleccione cuidadosamente
a los miembros del grupo de enfoque. Incluya a los usuarios que hayan utilizado versiones anteriores o
productos similares a los que está implementando. Seleccione un grupo de usuarios del mismo tipo (y
SEGUNDO
BIMESTRE
mantenga varios grupos de enfoque para las diferentes clases de usuario) o seleccione un grupo que
represente el espectro completo de clases de usuario para que todos estén igualmente representados.
Los grupos focales deben ser facilitados. Usted tendrá que mantenerlos en el tema, pero sin influir en las
opiniones que se expresan. Es posible que desee grabar la sesión para que pueda volver atrás y escuchar
SOLUCIONARIO
atentamente los comentarios. No esperen análisis cuantitativos de los grupos focales, sino más bien
mucha retroalimentación subjetiva que puede ser evaluada y priorizada a medida que se desarrollan los
requisitos. Las sesiones de sensibilización con grupos focales se benefician de muchos de los mismos
consejos descritos anteriormente para los talleres. Normalmente, los participantes en los grupos focales
no tienen autoridad para tomar decisiones sobre los requisitos.
BIBLIOGRÁFICAS
REFERENCIAS
Para utilizar ésta estrategia, se debe realizar lo siguiente:
1. Definir los objetivos y los participantes del grupo de enfoque.

2. Planificar y organizar la logística para la sesión.
3. Dirigir el grupo de enfoque.
4. Analizar y documentar la información recogida.
ANEXOS
4.2.4. Observación
Cuando pida a los usuarios que describan cómo hacen sus trabajos, es probable que tengan dificultades
para ser precisos, ya que los detalles podrían faltar o ser incorrectos. A menudo esto es porque las tareas
son complejas y es difícil recordar cada detalle de forma minuciosa. En otros casos, es porque los usuarios
están tan familiarizados con la ejecución de una tarea que no pueden articular todo lo que hacen. Tal vez
la tarea es tan habitual que ni siquiera piensan en ello. A veces se puede aprender mucho observando
exactamente cómo los usuarios realizan sus tareas.
Las observaciones consumen mucho tiempo, por lo que no son adecuadas para cada usuario o para
cada tarea. Para evitar interrumpir las actividades de trabajo asignadas regularmente por los usuarios,
limite cada tiempo de observación a dos horas o menos. Seleccione tareas importantes o de alto riesgo

y varias clases de usuario para las observaciones. Si utiliza observaciones en proyectos ágiles, haga que
el usuario muestre únicamente las tareas específicas relacionadas con la próxima iteración.
ÍNDICE
La observación del trabajo de un usuario en el entorno de tareas permite al analista de negocio validar la
información recolectada de otras fuentes, identificar nuevos temas para entrevistas, ver problemas con
el sistema actual e identificar maneras en que el nuevo sistema puede apoyar mejor el trabajo. El analista
de negocio debe abstraer y generalizar más allá de las actividades del usuario observado para asegurar
PRELIMINARES
que los requisitos capturados se aplican a la clase de usuario en conjunto, y no sólo a ese individuo. Un
analista de negocio hábil también puede a menudo sugerir ideas para mejorar los procesos de negocio
actuales del usuario.
Las observaciones pueden ser silenciosas o interactivas. Las observaciones silenciosas son apropiadas
cuando los usuarios ocupados no pueden ser interrumpidos. Las observaciones interactivas permiten al
analista de negocio interrumpir al usuario a mediados de la tarea y hacer una pregunta. Esto es útil para
BIMESTRE
PRIMER
entender inmediatamente por qué un usuario hizo una elección o preguntarle en qué estaba pensando
cuando tomó alguna acción. Documente lo que observa para un análisis posterior después de la sesión.
También puede considerar la grabación de vídeo de la sesión, si las políticas lo permiten, para que pueda
actualizar la memoria más tarde.
SEGUNDO
BIMESTRE
Para realizar ésta estrategia es necesario realizar lo siguiente:
1. Preparar la observación
• Consiste en determinar las personas a las cuales se les observará. En grandes empresas se
tendrá que escoger apropiadamente la muestra de personas. Además, como parte de esta
SOLUCIONARIO
fase se debe elaborar los cuestionarios que se aplicarán durante o después del desarrollo
de la actividad.
2. Observar
• El observador indica a la persona que está siendo observada, y:
BIBLIOGRÁFICAS
REFERENCIAS
§§ Asegura al usuario que su trabajo no está siendo cuestionado, sino que la observación
de su trabajo y documentación servirá para el análisis de requisitos.  
§§ Se informa al usuario que el observador está presente sólo para estudiar sus procesos
y se abstendrá de intervenir.  
§§ Indicar al usuario que puede detener el proceso de observación en cualquier
momento si consideran que está interfiriendo con su trabajo.   ANEXOS
§§ Sugerir al usuario que puede “pensar en voz alta” cuando esté trabajando, esto como
una manera de compartir sus intenciones, retos y preocupaciones.
En cuanto a la conducta de la observación.
• Tomar notas detalladas.
• Si se utiliza la observación con el enfoque activo, hacer preguntas deductivas acerca de por
qué son así los procesos y tareas que se llevan a cabo.  

3. Post observación, documentación y confirmación:
• Obtener respuestas a las preguntas nuevas que surgieron durante la observación.  
ÍNDICE
• Proporcionar al usuario un resumen de las notas lo antes posible para su revisión y aclaración. 
• Revisar los hallazgos con todo el grupo para asegurarse que los detalles finales representan
PRELIMINARES
a todo el grupo y no solamente a los individuos seleccionados.
4.2.5. Cuestionarios
Los cuestionarios son una forma de encuestar a grandes grupos de usuarios para entender sus
necesidades. Son baratos, por lo que es una opción lógica para obtener información de las grandes
poblaciones de usuarios, y pueden administrarse fácilmente a través de las fronteras geográficas. Los
BIMESTRE
PRIMER
resultados analizados de los cuestionarios se pueden utilizar como insumo para otras técnicas de
obtención. Por ejemplo, puede utilizar un cuestionario para identificar los puntos de mayor preocupación
de los usuarios con un sistema existente, luego usar los resultados para discutir la priorización con los
tomadores de decisiones en un taller. También puede utilizar cuestionarios para encuestar a los usuarios
de productos comerciales para recibir comentarios.
SEGUNDO
BIMESTRE
Preparar preguntas bien escritas es el mayor reto con los cuestionarios. Muchos consejos están
disponibles para escribir cuestionarios, se sugiere los más importantes aquí:
• Proporcione opciones de respuesta que cubran el conjunto completo de posibles respuestas.
SOLUCIONARIO
• Haga que las opciones de respuesta sean mutuamente excluyentes (sin superposiciones en rangos
numéricos) y exhaustivas (Enumere todas las opciones posibles y / o tenga un lugar de escritura
para una opción que no pensó).
• No formule una pregunta de manera que implique una respuesta “correcta”.
BIBLIOGRÁFICAS
• Si utiliza escalas, utilícelas de manera consistente en todo el cuestionario.
REFERENCIAS
• Utilice preguntas cerradas con dos o más opciones específicas si desea utilizar los resultados del
cuestionario para el análisis estadístico. Las preguntas abiertas permiten a los usuarios responder
de la manera que quieran, por lo que es difícil buscar puntos en común en los resultados.
• Considere la posibilidad de consultar con un experto en diseño de cuestionarios y la administración

para asegurarse de que usted haga las preguntas correctas a las personas adecuadas. ANEXOS
• Siempre pruebe un cuestionario antes de distribuirlo. Es frustrante descubrir demasiado tarde

que una pregunta fue redactada de forma ambigua o darse cuenta de que se omitió una pregunta
importante.
• No haga demasiadas preguntas o la gente no responderá.
Son varias las ventajas que nos ofrecen los cuestionarios ya que nos permite obtener información
subjetiva de forma rápida, a un bajo costo, de forma remota a un gran número de personas.
La forma de aplicar el cuestionario también es diversa, desde una forma tradicional mediante un papel
impreso hasta utilizando herramientas tecnológicas con diseños acordes al grupo que se desea aplicar.

Contrariamente una de las desventajas de los cuestionarios es que la información obtenida sea sesgada
por diversos motivos, como, por ejemplo, la muestra de personas que se escogieron para aplicar el
ÍNDICE
cuestionario, las personas que estaban dispuestos a responder, no hay una relación directa con los
encuestados por lo que no se puede contextualizar las preguntas, preguntas ambiguas, etc.
Para diseñar y aplicar los cuestionarios (o encuestas), se debe hacer lo siguiente:  
PRELIMINARES
1. Identifique el propósito del cuestionario.  
2. Determinar la muestra (grupo) y el método de recolección.  
3. Diseñe las preguntas del cuestionario.  
4. Pruebe el cuestionario antes de distribuirlo.  
5. Aplique el cuestionario.  
6. Analice y documente los datos.  
BIMESTRE
PRIMER
4.2.6. Análisis de la interfaz del sistema
El análisis de interfaces es una técnica de extracción independiente que implica el examen de los sistemas
a los que se conecta el sistema. El análisis de la interfaz del sistema revela los requisitos funcionales
SEGUNDO
relativos al intercambio de datos y servicios entre sistemas. Los diagramas de contexto y los mapas de
BIMESTRE
ecosistemas son una opción obvia para comenzar las interfaces para un estudio posterior. De hecho, si
tiene una interfaz que tiene requisitos asociados y que no está representada en uno de estos diagramas,
los diagramas están incompletos.
Para cada sistema que interactúa con el que se va a construir, identifique la funcionalidad en el otro
SOLUCIONARIO
sistema que podría dar lugar a requisitos para su sistema. Estos requisitos podrían describir qué datos
transmitir al otro sistema, qué datos se reciben de él y reglas sobre esos datos, como los criterios de
validación. También puede descubrir la funcionalidad existente que no necesita implementar en su
sistema. Supongamos que pensaba que necesitaba implementar reglas de validación para un pedido de
carrito de compras en un sitio de comercio electrónico antes de pasarlo a un sistema de administración
BIBLIOGRÁFICAS
de pedidos. A través del análisis de la interfaz del sistema, puede aprender cómo otros sistemas pasan
REFERENCIAS
las órdenes al sistema de gestión de pedidos, cómo se realiza la validación, y por qué no es necesario
crear esta función.
4.2.7. Análisis de interfaz de usuario
El análisis de la interfaz de usuario (UI) es una técnica de extracción independiente en la que se estudian
los sistemas existentes para descubrir los requisitos de usuario y funcionales. Lo mejor es interactuar ANEXOS
con los sistemas existentes directamente, pero si es necesario puede utilizar capturas de pantalla. Los
manuales de usuario para las implementaciones de software empaquetado compradas a menudo
contienen capturas de pantalla que funcionarán como punto de partida. Si no existe un sistema, es
posible que pueda ver interfaces de usuario de productos similares.
Al trabajar con soluciones empaquetadas o con un sistema existente, el análisis de la interfaz de usuario
puede ayudarle a identificar una lista completa de pantallas que le permitan descubrir características
potenciales. Al navegar por la interfaz de usuario existente, puede conocer los pasos comunes que los
usuarios toman en el sistema y los casos de uso preliminar para revisarlos con los usuarios. Análisis de la
interfaz de usuario puede revelar piezas de datos que los usuarios necesitan ver. Es una gran manera de
ponerse al día sobre cómo funciona un sistema existente (a menos que necesite mucho entrenamiento
para hacerlo). En lugar de preguntar a los usuarios cómo interactúan con el sistema y qué pasos toman,
tal vez usted puede llegar a un entendimiento inicial usted mismo.

No asuma que ciertas funcionalidades son necesarias en el nuevo sistema sólo porque usted lo encontró
en un sistema existente. Por otra parte, no asuma que debido a que la interfaz de usuario es de esa
ÍNDICE
manera en el sistema actual debe ser implementado de esa misma manera en el futuro sistema.
4.2.8. Análisis de documentos
El análisis de documentos implica examinar cualquier documentación existente sobre los posibles
PRELIMINARES
requisitos de software. La documentación más útil incluye especificaciones de requisitos, procesos
empresariales, colecciones aprendidas por experiencia y manuales de usuario para aplicaciones
existentes o similares. Los documentos pueden describir los estándares corporativos o de la industria
que deben ser seguidos o las regulaciones con las cuales el producto debe cumplir. Al reemplazar un
sistema existente, la documentación pasada puede revelar la funcionalidad que podría necesitar ser
retenida, así como la funcionalidad obsoleta.
BIMESTRE
PRIMER
Para la implementación de soluciones empaquetadas, la documentación del proveedor menciona la
funcionalidad que sus usuarios pueden necesitar, pero es posible que tenga que explorar más a fondo
cómo implementarla en el entorno de destino. Las revisiones comparativas señalan deficiencias en otros
productos que usted podría dirigir para ganar una ventaja competitiva. Los informes de problemas y las
solicitudes de mejoras recopiladas de los usuarios por el personal de asistencia y el personal de soporte
SEGUNDO
BIMESTRE
técnico pueden ofrecer ideas para mejorar el sistema en futuras versiones.
El análisis de documentos es una manera de ponerse al día en un sistema existente o en un nuevo

dominio. Hacer algunas investigaciones y redactar algunos requisitos de antemano reduce el tiempo
necesario para la reunión. El análisis de documentos puede revelar información que la gente no le dice,
SOLUCIONARIO
ya sea porque no piensa en ella o porque no la conoce. Por ejemplo, si está creando una nueva aplicación
de centro de llamadas, puede encontrar alguna lógica empresarial complicada descrita en el manual del
usuario para una aplicación existente. Tal vez los usuarios ni siquiera saben acerca de esta lógica. Usted
puede utilizar los resultados de este análisis como entrada a las entrevistas del usuario.
Un riesgo con esta técnica es que los documentos disponibles pueden no estar actualizados. Es posible
BIBLIOGRÁFICAS
que los requisitos hayan cambiado sin que se actualicen las especificaciones o se pueda documentar la
REFERENCIAS
funcionalidad que no se necesita en un nuevo sistema.
4.3. Planificar la obtención del proyecto
Un plan de obtención incluye las técnicas que usará, cuando planea usarlas y con qué propósito. Al igual
que con cualquier plan, úselo como guía y recordatorio durante todo el proyecto, pero comprenda que ANEXOS
puede ser necesario cambiar el plan a lo largo del proyecto. Su plan debe abordar los siguientes temas:
• Objetivos de la Obtención
• Planificar los objetivos de obtención para todo el proyecto y los objetivos para cada actividad de
extracción planificada.
• Estrategia de obtención y técnicas planificadas
• Decida qué técnicas usar con diferentes grupos de interesados. Puede utilizar una combinación
de cuestionarios, talleres, visitas al cliente, entrevistas individuales y otras técnicas, dependiendo
del acceso que tenga a los interesados, las limitaciones de tiempo y su conocimiento del sistema
existente.

• Calendario y estimaciones de recursos
• Identifique tanto a los clientes como a los participantes en el desarrollo para las diversas actividades
ÍNDICE
de obtención, junto con las estimaciones del esfuerzo y el tiempo calendario requerido. Puede
que solo sea capaz de identificar las clases de usuario y no individuos específicos de antemano,
pero eso permitirá a los gerentes comenzar a planificar las necesidades de recursos que vayan
surgiendo. Estime el tiempo del analista del negocio, incluyendo el tiempo para prepararse para la
PRELIMINARES
obtención y para realizar el análisis de seguimiento.
• Documentos y sistemas necesarios para la obtención independiente
• Si está realizando análisis de documento, interfaz de sistema o de interfaz de usuario, identifique

los materiales necesarios para asegurarse de que los tiene cuando los necesita.
BIMESTRE
PRIMER
• Producto esperado de los esfuerzos de la obtención
• Sabiendo que va a crear una lista de casos de uso, un ERS, un análisis de los resultados del
cuestionario, o especificaciones de atributos de calidad ayuda a asegurar que usted apunta a los
interesados directos, temas y detalles durante la obtención.
SEGUNDO
BIMESTRE
• Riesgos de obtención
• Identifique los factores que podrían obstaculizar su capacidad de completar las actividades de
inducción según lo previsto, estimar la gravedad de cada riesgo y decidir cómo puede mitigarlo
o controlarlo.
SOLUCIONARIO
Muchos analistas de negocio tienen su técnica de “excusarse”, comúnmente en entrevistas y talleres, y
no piensan en usar otras técnicas que podrían reducir las necesidades de recursos o aumentar la calidad
de la información descubierta. Rara vez un analista de negocio obtiene los mejores resultados mediante
el uso de una sola técnica de obtención en un proyecto. Las técnicas de obtención se aplican a todo
el espectro de enfoques de desarrollo. La selección de las técnicas de obtención debe basarse en las
BIBLIOGRÁFICAS
REFERENCIAS
características del proyecto.
En la Figura 14 se sugiere las técnicas de obtención que son más probables de ser útiles para varios
tipos de proyectos. Seleccione la fila o las filas que representan las características de su proyecto y lea
a la derecha para ver qué técnicas de obtención tienen más probabilidades de ser útiles (marcadas con
una X). Por ejemplo, si está desarrollando una nueva aplicación, es probable que obtenga los mejores
resultados con una combinación de entrevistas los interesados, talleres y análisis de la interfaz del
sistema. ANEXOS
La mayoría de los proyectos pueden hacer uso de entrevistas y talleres. Los grupos focales son más
apropiados que los talleres para el software de mercado masivo porque tiene una gran base de usuarios
externos, pero acceso limitado a los representantes. Estas sugerencias para las técnicas de obtención son
sólo eso: sugerencias.

ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
Figura 14. Técnicas de obtención sugeridas por características del proyecto
4.4. Preparación para la obtención
SEGUNDO
BIMESTRE
Las sesiones de obtención requieren de preparación para hacer mejor uso del tiempo de cada uno.
Cuanto mayor es el grupo que participa en la sesión, más importante es la preparación. Prepárese para
cada sesión decidiendo el alcance de la misma, comunicando una agenda, preparando preguntas y
SOLUCIONARIO
redactando materiales que podrían ser útiles durante la sesión. Los siguientes consejos le ayudarán a
prepararse para la obtención.
• Planifique el alcance y la agenda de la sesión.
Decidir sobre el alcance de la sesión de obtención, teniendo en cuenta cuánto tiempo está disponible.
BIBLIOGRÁFICAS
REFERENCIAS
Puede definir el ámbito de la sesión mediante un conjunto de temas o preguntas, o puede enumerar un
conjunto específico de procesos o casos de uso a explorar. Alinee el alcance de la sesión con el alcance
general del proyecto definido en los requisitos del negocio para poder mantener la conversación sobre
el tema. El orden del día debe detallar qué temas serán cubiertos, el tiempo disponible para cada tema y
los objetivos específicos. Comparta la agenda de la sesión con los interesados con antelación.
• Preparar recursos
ANEXOS
Programe los recursos físicos necesarios, como salas, proyectores, números de teleconferencia y equipos
de videoconferencia. Además, programe con los participantes, siendo sensibles a las diferencias de zona
horaria si no están todos en la misma ubicación. Para grupos geográficamente dispersos, cambie el
horario cada vez que se reúna para que las sesiones no siempre molesten a las mismas personas en una
parte particular del mundo. Recopilar la documentación de varias fuentes. Tener acceso a los sistemas
según sea necesario. Tome capacitación en línea para aprender sobre los sistemas existentes.
• Conozca las partes interesadas
Identifique a los interesados relevantes para la sesión (Tratado en la unidad 2). Conozca las preferencias
culturales y regionales de los interesados para las reuniones. Si algunos de los participantes no
son hablantes nativos del idioma en el que se llevará a cabo la sesión, considere proporcionarles
documentación de apoyo, como diapositivas, antes de tiempo para que puedan leer adelante o seguir

adelante. Las diapositivas pueden enumerar preguntas específicas que usted estará preguntando o
simplemente proporcionar contexto para la sesión que también podría explicar verbalmente. Evite crear
ÍNDICE
una tensión entre “nosotros” y “ellos”.
• Preparar las preguntas
Vaya a cada sesión de obtención facilitada con un conjunto de preguntas preparadas. Utilice las áreas
PRELIMINARES
de incertidumbre en los modelos de hombre de paja (descritos en la siguiente sección) como fuente
de preguntas. Si se está preparando para una entrevista o taller, use los resultados de otras técnicas de
obtención para identificar preguntas sin resolver.
Como analista, debe investigar en base a los requisitos que los clientes presentan para comprender sus
verdaderas necesidades. Si pregunta a los usuarios, “¿Qué quieres?” genera una masa de información
aleatoria que deja al analista desconcertado. “¿Qué necesitas hacer?” Es una pregunta mejor. Preguntar
BIMESTRE
PRIMER
“por qué” varias veces puede mover la discusión de una solución presentada a una comprensión sólida del
problema que necesita ser resuelto. Haga preguntas abiertas para ayudarle a comprender los procesos
de negocio actuales de los usuarios y ver cómo el nuevo sistema podría mejorar su rendimiento.
Imagínese aprendiendo el trabajo del usuario, o realizando el trabajo bajo la dirección del usuario. ¿Qué
tareas realizaría usted? ¿Qué preguntas haría usted? Otro enfoque consiste en desempeñar el papel de
SEGUNDO
BIMESTRE
un aprendiz aprendiendo de un usuario maestro. El usuario que está entrevistando a continuación, guía
la discusión y describe lo que él considera como los temas importantes para la discusión.
Explore alrededor de las excepciones: ¿Qué podría impedir al usuario completar satisfactoriamente una
tarea? ¿Cómo debe el sistema responder a diversas condiciones de error?
SOLUCIONARIO
Haga preguntas que comiencen con “¿Qué más podría. . . ,”“Que pasa cuando . . . , “” ¿Alguna vez necesitarás.
. . ,” “Donde consigues . . . , “” ¿Por qué usted (o no). . . , “Y” ¿Alguna vez alguien. . . “. Documente el origen
de cada requisito para que pueda obtener más información si es necesario y rastrear las actividades de
desarrollo de nuevo a los orígenes específicos del cliente.
BIBLIOGRÁFICAS
REFERENCIAS
Como con cualquier actividad de mejora, la insatisfacción con la situación actual proporciona excelentes
argumentos para el nuevo y mejorado estado futuro. Cuando esté trabajando en un proyecto de
reemplazo para un sistema heredado, pregunte a los usuarios: “¿Cuáles son las tres cosas que más le
molestan en el sistema existente?” Esta pregunta determina las expectativas que los usuarios tienen para
el sistema subsiguiente.
ANEXOS
Las preguntas preparadas son para ayudarte si te quedas atascado. Las preguntas deben parecer
naturales y cómodas, como una conversación, no un interrogatorio. A cinco minutos de una sesión,
quizá sepa que se perdió un área importante para la discusión. Esté listo para abandonar sus preguntas
si es necesario. Al final de su sesión, pregunte “¿Hay algo más que esperaba que yo le preguntara?” Para
tratar de plantear problemas que usted simplemente no pensaba.
• Preparar modelos de Straw man.
Los modelos de análisis se pueden utilizar durante las sesiones de inducción para ayudar a los usuarios a
proporcionar mejores requisitos. Algunos de los modelos más útiles son los casos de uso y los procesos,
porque se alinean estrechamente con la forma en que la gente piensa en hacer su trabajo. Un hombre de
paja sirve como punto de partida que le ayuda a aprender sobre el tema e inspira a sus usuarios a pensar
en ideas. Es más fácil revisar un modelo de borrador que crear uno desde cero.

Si es nuevo en el dominio del proyecto, puede ser difícil crear un modelo de borrador por su cuenta. Utilice
otras técnicas de obtención para recoger suficiente conocimiento para trabajar. Lea los documentos
ÍNDICE
existentes, examine los sistemas existentes para los modelos que puede reutilizar como punto de partida
o realice una entrevista individual con un experto en la materia para aprender lo suficiente para empezar.
Luego dígale al grupo con el que está trabajando: “Este modelo probablemente estará equivocado. Por
favor decirme cómo debería ser”.
PRELIMINARES
4.5. Realizar las actividades de obtención
Ejecutar la actividad de obtención en sí es relativamente obvio: si está entrevistando, entonces está

hablando con la gente; Si está realizando análisis de documentos, lee el documento. Sin embargo, al
facilitar una actividad de obtención, los siguientes consejos pueden ser útiles.
BIMESTRE
PRIMER
• Educar a los interesados
Enseñe a los interesados acerca de su enfoque de obtención y por qué lo eligió. Explique las técnicas
de exploración que utilizará, como casos de uso o procesos, y cómo pueden ayudar los interesados
a proporcionar mejores requisitos. También describa cómo va a capturar su información y enviarles
SEGUNDO
BIMESTRE
materiales para su revisión después de la sesión.
• Tomar buenas notas
Asigne a alguien que no está participando activamente en la discusión para que sea el escritor
responsable de tomar notas. Las notas de la sesión deben contener una lista de asistentes, invitados
SOLUCIONARIO
que no asistieron, decisiones tomadas, acciones a tomar y quién es responsable de cada uno, asuntos
pendientes y los puntos altos de discusiones clave. Desafortunadamente, los analistas de negocio a
veces mantienen sesiones de obtención facilitadas sin un escritor dedicado y tienen que llenar el papel
ellos mismos. Si se encuentra en esta situación, debe estar preparado para escribir taquigrafía, escribir
rápidamente o usar un dispositivo de grabación (si los participantes están de acuerdo). También puede
BIBLIOGRÁFICAS
usar pizarras y papel en las paredes y fotografiarlos.
REFERENCIAS
Prepare preguntas con anticipación para eliminar algunos de los pensamientos in situ necesarios para
mantener la conversación. Llegue con una notación abreviada para capturar una pregunta que viene a
la mente mientras alguien está hablando, así que rápidamente puede volver a ella cuando tenga una
oportunidad. No trate de capturar diagramas complicados mediante un software, basta con dibujar
diagramas rápidamente con la mano.
ANEXOS
• Aprovechar el espacio físico
La mayoría de las habitaciones tienen cuatro paredes, así que úselas durante la facilitación para dibujar
diagramas o crear listas. Si no hay pizarras disponibles, coloque grandes hojas de papel en las paredes.
Tenga notas adhesivas y marcadores disponibles. Invite a otros participantes a levantarse y contribuir
también; Moverse ayuda a mantener a la gente comprometida. En Gottesdiener (2005) se refiere a
esta técnica como el patrón de colaboración “Wall of Wonder”. Si existen artefactos a considerar (como
modelos de hombre de paja, requisitos existentes o sistemas existentes) proyéctelos en la pared.
Facilitar sesiones de colaboración con los participantes en múltiples ubicaciones requiere más creatividad.
Puede utilizar herramientas de conferencia en línea para compartir diapositivas y permitir interacciones.
Si hay varios participantes en la misma sala, utilice herramientas de videoconferencia para mostrar a los
participantes remotos lo que hay en las paredes y pizarras.

4.6. Seguimiento después de la obtención
ÍNDICE
Después de que cada actividad de obtención está completa, todavía hay mucho que hacer. Necesita
organizar y compartir sus notas, documentar problemas abiertos y clasificar la información recopilada.
• Organizar y compartir las notas
PRELIMINARES
Si dirigió una entrevista o un taller, la organización de sus notas probablemente requiere más esfuerzo
que si organizó la información como la encontró durante una actividad de obtención. Consolide sus
aportaciones desde múltiples fuentes. Revise y actualice sus notas poco después de que la sesión esté
completa, mientras que el contenido todavía está fresco en su mente.
La edición de las notas de obtención es un riesgo. Es posible que se recuerde incorrectamente lo que
BIMESTRE
significaba algo, por lo tanto, sin saberlo, cambiar el significado. Mantenga un conjunto de las notas
PRIMER
en bruto para hacer referencia más adelante si es necesario. Poco después de cada entrevista o taller,
comparta las notas consolidadas con los participantes y pídales que las revisen para asegurarse de que
representan con precisión la sesión. La revisión temprana es esencial para el desarrollo exitoso de los
requisitos, porque sólo las personas que suministraron los requisitos pueden juzgar si fueron capturados
correctamente. Mantenga discusiones adicionales para resolver cualquier inconsistencia y para llenar
SEGUNDO
BIMESTRE
cualquier espacio en blanco. Considere la posibilidad de compartir las notas consolidadas con otros
interesados del proyecto que no estuvieron presentes en la sesión, para que conozcan el progreso. Esto
les da la oportunidad de cualquier problema o inquietud inmediatamente.
• Documentación de problemas abiertos
SOLUCIONARIO
Durante las actividades de obtención, es posible que haya encontrado elementos que necesitan ser
explorados más adelante en una fecha posterior o las brechas de conocimiento que necesita cerrar. O
puede que haya identificado nuevas preguntas al revisar sus notas. Examinar todos los lugares de las
sesiones de obtención para los problemas que todavía están abiertos y registrarlos en una herramienta
de seguimiento de problemas. Para cada emisión, registre todas las notas relevantes relacionadas con la
BIBLIOGRÁFICAS
REFERENCIAS
resolución de los problemas, el progreso ya realizado, el propietario y la fecha de vencimiento. Considere
la posibilidad de utilizar la misma herramienta de seguimiento de problemas que utilizan los equipos de
desarrollo y pruebas.
4.7. Clasificando el aporte de los clientes
No espere que los clientes presenten una lista sucinta, completa y bien organizada de sus necesidades. ANEXOS
Los analistas deben clasificar la múltiple cantidad de información de requisitos que escuchan en varias
categorías para que puedan documentar y utilizarla apropiadamente.

Requisitos de
negocio
ÍNDICE
Requisitos de
Ideas de usuario
solución
PRELIMINARES
Requisitos de Reglas de
datos negocio
BIMESTRE
PRIMER
Requisitos
Restricciones funcionales
SEGUNDO
BIMESTRE
Atributos de
Requisitos de
calidad
interfaz externa
SOLUCIONARIO
Figura 15. Categoría de aporte de los clientes
En la figura 15 se ilustran nueve categorías de este tipo. Durante las actividades de obtención, haga
anotaciones rápidas en sus notas si detecta que un poco de información es uno de estos tipos. Por
ejemplo, escriba “DD” en un pequeño círculo sí reconoce una definición de datos.
BIBLIOGRÁFICAS
REFERENCIAS
Al igual que con muchas categorizaciones, la información recolectada podría no encajar precisamente en
estos nueve grupos. Probablemente tendrás fragmentos de información después de esta clasificación.
Cualquier cosa que no entra en una de estas categorías podría ser:
• Un requisito del proyecto no relacionado con el desarrollo del software, como la necesidad de
capacitar a los usuarios en el nuevo sistema.
ANEXOS
• Una restricción de proyecto, como una restricción de costo o de programación (en oposición a las
restricciones de diseño o implementación).
• Una suposición o una dependencia.
• Información adicional de carácter histórico, contextual o descriptivo.
• Información extraña que no agrega valor.
Los participantes en la obtención no simplemente le dirán, “Aquí está un requisito de negocio.” Como
analista, necesita determinar qué tipo de información representa.
En la tabla 7, se presentan algunas definiciones agrupadas de acuerdo a cada categoría.

Tabla 7.
Ejemplo de declaraciones de requisitos de diferente tipo
ÍNDICE
Categoría Ejemplo
•• "Aumentar la cuota de mercado en la región Central por el 15 por ciento
dentro de los 6 primeros meses."
Requisitos de negocio
•• "Ahorre $ 500 por año en electricidad que actualmente es desperdiciada
PRELIMINARES
por unidades ineficientes".
•• "Necesito imprimir una etiqueta de correo para un paquete."
Requisitos de usuario •• "Como operador principal de la máquina, necesito calibrar el controlador de
la bomba a primera hora de la mañana".
•• "Un nuevo cliente debe pagar el 30 por ciento de la cuota estimada de
consultoría y los gastos de viaje por adelantado".
Regla de negocio
•• "Las aprobaciones de tiempo libre deben cumplir con la política de
BIMESTRE
PRIMER
vacaciones de recursos humanos de la empresa."
•• "Si la presión excede 40.0 psi, la luz de advertencia de alta presión debe
encenderse".
•• "El usuario debe ser capaz de ordenar la lista de proyectos en orden
alfabético hacia delante y hacia atrás."
Requisito funcional Estas declaraciones ilustran cómo los usuarios suelen presentar requisitos
SEGUNDO
BIMESTRE
funcionales, pero no representan buenas maneras de escribir requisitos
funcionales. El analista de negocio tendrá que elaborar estos en especificaciones
más precisas. Más adelante estaremos enfocando el tema de escritura de
requisitos.
•• "El software móvil debe responder rápidamente a los comandos de touch."
SOLUCIONARIO
Atributo de calidad •• "El mecanismo del carro de compra tiene que ser simple de utilizar así los
nuevos clientes no abandonarán la compra."
•• "El sistema de ejecución de fabricación debe controlar el wafer sorter".
Requisito de interfaz
•• "La aplicación móvil debe enviar la imagen de cheque al banco después de
externa
que fotografíe el cheque que estoy depositando."
•• "Los archivos enviados electrónicamente no pueden superar los 10 MB de
BIBLIOGRÁFICAS
tamaño".
REFERENCIAS
Restricciones
•• "El navegador debe utilizar cifrado de 256 bits para todas las transacciones
seguras."
•• "El código postal tiene cinco dígitos, seguido por un guion opcional y cuatro
dígitos que por defecto a 0000."
Requisitos de datos •• "Una orden consiste en la identidad del cliente, información de envío y uno
o más productos, cada uno de los cuales incluye el número de producto, el
número de unidades, el precio unitario y el precio total".
•• "Entonces selecciono el estado donde deseo enviar el paquete de una lista ANEXOS
drop-down."
Ideas de solución
•• "El teléfono tiene que permitir al usuario deslizar con un dedo para navegar
entre las pantallas."
La clasificación del aporte del cliente es sólo el comienzo del proceso para crear especificaciones de
requisitos. Aún necesita reunir la información en colecciones de requisitos claramente establecidas y
bien organizadas.
¿Cómo sabes cuándo termina la Obtención?
Ninguna señal simple indicará cuándo ha completado la obtención de los requisitos. De hecho, nunca
estará completamente, sobre todo si está deliberadamente implementando un sistema de forma

incremental, como en proyectos ágiles. Las siguientes señales sugieren que está alcanzando el punto
máximo sobre la obtención de los requisitos, al menos por ahora. Tal vez usted está terminando si:
ÍNDICE
• Los usuarios no pueden pensar en más casos de uso o historias de usuarios. Los usuarios tienden
a identificar los requisitos del usuario en secuencia de importancia decreciente.
• Los usuarios proponen nuevos escenarios, pero no conducen a nuevos requisitos funcionales.
PRELIMINARES
Un “nuevo” caso de uso podría ser realmente un flujo alternativo para un caso de uso que ya ha
capturado.
• Los usuarios repiten problemas que ya cubrieron en discusiones anteriores.
• Las nuevas características sugeridas, los requisitos del usuario o los requisitos funcionales se
consideran fuera del alcance.
BIMESTRE
PRIMER
• Los nuevos requisitos propuestos tienen poca prioridad.
• Los usuarios proponen capacidades que podrían incluirse “en algún momento de la vida útil del
producto” en lugar de “en el producto específico del que estamos hablando ahora”.
SEGUNDO
BIMESTRE
• Los desarrolladores y probadores que revisan los requisitos para un área plantean pocas preguntas.
Organizar y llevar un control de los numerosos requisitos de diferentes usuarios sin usar un esquema de
organización estructurado, como los casos de uso o las secciones en una plantilla ERS, prácticamente
es imposible. A pesar de sus mejores esfuerzos para descubrir todos los requisitos, no lo hará, siempre
SOLUCIONARIO
será necesario hacer cambios a medida que avance la construcción. Recuerde, su meta es acumular
una comprensión compartida de los requisitos que sea lo suficientemente buena para permitir que la
construcción de la próxima liberación o incremento se realice a un nivel de riesgo aceptable.
La habilidad para conducir discusiones de obtención está dada por la experiencia y el conocimiento en
entrevistas, facilitación de grupo, resolución de conflictos y actividades similares. Sin embargo, algunas
BIBLIOGRÁFICAS
REFERENCIAS
precauciones disminuirán la curva de aprendizaje.
• Balancear la representación de los interesados

• Definir un alcance adecuado
• Evitar el argumento de requisitos versus diseño
• Investigar con la razón
ANEXOS
Nunca se podrá documentar el 100 por ciento de los requisitos de un sistema. Sin embargo, los requisitos
que no se especifica plantean el riesgo de que el proyecto ofrezca una solución diferente de lo que los
interesados esperan. Existen dos posibles culpables:
• Los requisitos asumidos que son aquellos que las personas esperan sin haberlos expresado
explícitamente. Lo que usted asume como obvio puede no ser lo mismo que las suposiciones que
hacen varios desarrolladores.
• Los requisitos implícitos que son necesarios debido a otro requisito, pero no están explícitamente
establecidos. Los desarrolladores no pueden implementar funciones que no conocen.
Para reducir estos riesgos, trate de identificar los vacíos de conocimiento esperando a ser llenado por
las necesidades implícitas y asumidas. Pregunte, “¿Qué estamos asumiendo?” durante las sesiones de
obtención para tratar de superar esos pensamientos ocultos. Si se encuentra con una suposición durante

las discusiones de requisitos, grabarlo y confirmar su validez. La gente a menudo asume que las cosas
tienen que ser la forma en que siempre han sido porque están tan familiarizados con un sistema existente
ÍNDICE
o un proceso de negocio. Si está desarrollando un sistema de reemplazo, revise las características del
sistema anterior para determinar si realmente son necesarias en el reemplazo.
Para identificar los requisitos implícitos, estudiar los resultados de las sesiones iniciales para identificar
las áreas de incompletas. ¿Se necesita un requisito vago y de alto nivel para que todos los interesados
PRELIMINARES
lo entiendan? ¿Es un requisito que podría formar parte de un conjunto lógico (por ejemplo, guardar
un formulario web incompleto) sin su contraparte (recuperar un formulario guardado para un trabajo
posterior)? Es posible que necesite volver a entrevistar a algunas de las mismas partes interesadas para
que busquen los requisitos que faltan. (Wiegers y Beatty, 2013) Además, piense en los nuevos interesados
que conocen el tema y pueden detectar las lagunas.
Lea entre líneas para identificar características que los clientes esperan que se incluyan sin haberlo
BIMESTRE
PRIMER
dicho. Haga preguntas sin contexto, preguntas de alto nivel y abiertas que generen información sobre
las características globales tanto del problema como de la solución. La respuesta del cliente a preguntas
como “¿Qué tipo de precisión se requiere en el producto?” O “¿Puede usted ayudarme a entender por qué
no está de acuerdo con la respuesta de Miguel?” Puede conducir a ideas que respondan a las preguntas
con estándar sí/no o A/B/C.
SEGUNDO
BIMESTRE
Por otro lado, los requisitos que faltan constituyen un tipo común de defecto, debido a que son difíciles
de detectar porque son invisibles. Las siguientes técnicas le ayudarán a detectar requisitos previamente
no descubiertos:
SOLUCIONARIO
• Descomponer requisitos de alto nivel al detalle para revelar exactamente lo que se solicita. Un
requisito vago y de alto nivel que deja mucho a la interpretación del lector conducirá a una brecha
entre lo que el solicitante tiene en mente y lo que el desarrollador construye.
• Asegúrese de que todas las clases de usuario han proporcionado la información apropiada.
Asegúrese de que cada requisito de usuario tenga al menos una clase de usuario identificada que
BIBLIOGRÁFICAS
reciba valor del requisito.
REFERENCIAS
• Rastrear los requisitos del sistema, los requisitos de los usuarios, las listas de eventos/respuesta y
las reglas de negocio con sus requisitos funcionales correspondientes para asegurarse de que se
derivó toda la funcionalidad necesaria.
• Compruebe los valores límite para los requisitos que faltan. Supongamos que un requisito dice:
“Si el precio de la orden es menor de $ 100, el cargo de envío es de $ 5.95” y otro dice: “Si el precio ANEXOS
de la orden es mayor de $ 100, los gastos de envío es el 6 por ciento del total del precio de la
orden”. Pero, ¿cuál es el costo de envío de un pedido con un precio de exactamente $ 100? No se
especifica, por lo que falta un requisito, o por lo menos podemos decir que está mal escrito.
• Represente la información de requisitos de más de una manera. Es difícil leer una masa de texto
y notar el elemento que está ausente. Algunos modelos de análisis representan visualmente los
requisitos a un alto nivel de abstracción. En el capítulo siguiente se analizan algunos modelos de
análisis.
• Los conjuntos de requisitos con lógica booleana compleja (AND, OR y NOT) a menudo están
incompletos. Si una combinación de condiciones lógicas no tiene un requisito funcional
correspondiente, el desarrollador tiene que deducir lo que el sistema debe hacer o perseguir una
respuesta. La condición “Else” con frecuencia se pasa por alto. Debe representar la lógica compleja
usando tablas de decisión o árboles de decisión para cubrir todas las situaciones posibles.

• Crear una lista de verificación de áreas comunes funcionales a considerar para sus proyectos. Los
ejemplos incluyen registro de errores, respaldo y restauración, seguridad de acceso, informes,
ÍNDICE
impresión, capacidades de vista previa y configuración de las preferencias del usuario. Compare
periódicamente esta lista con las funciones que ya ha especificado para buscar brechas.
• Un modelo de datos puede revelar la falta de funcionalidad. Todas las entidades de datos que
el sistema manipulará deben tener la funcionalidad correspondiente para crearlas, leerlas desde
PRELIMINARES
una fuente externa, actualizar los valores actuales y/o eliminarlas. El acrónimo CLAE (Crear Leer
Actualizar y eliminar), se utiliza a menudo para referirse a estas cuatro operaciones comunes.
Asegúrese de identificar la funcionalidad de su aplicación para realizar estas operaciones en todas
las entidades que las necesiten.
BIMESTRE
PRIMER
Hemos finalizado el estudio de la unidad 4 y para reforzar los conocimientos teóricos y modelos
SEGUNDO
de obtención analizados, se recomienda el desarrollo de las siguientes actividades:
BIMESTRE
•• Considerando el “Caso local”, Planifique las técnicas de obtención que se podrán aplicar para
recolectar información.
•• Aplique las técnicas planificadas
•• Liste y describa lo principales procesos encontrados
•• Elabore un mapa de procesos por cada proceso.
SOLUCIONARIO
Estrategia de desarrollo:
•• Considere la clasificación de interesados realizado en la unidad 2.
•• Revise el mapa de proceso general desarrollado en la unidad 3.
•• La planificación debe constar de las actividades que se indican en el literal 4.3 y 4.4.
•• Para la elaboración de los mapas de procesos utilice herramientas de modelado.
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS

Autoevaluación 4
ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
1. La obtención es un:
a. Proceso colaborativo y analítico

b. Actividad de gestión de requisitos
c. Herramienta de modelado
SEGUNDO
BIMESTRE
2. La obtención permite descubrir requisitos:
a. Negocio
b. Usuario
SOLUCIONARIO
c. Negocio, usuario funcionales y no funcionales
3. A la reunión de interesados cuidadosamente seleccionadas que trabajan bajo la guía de un experto

neutral que produce y documenta modelos de requerimientos, se la conoce como:
a. Entrevista
BIBLIOGRÁFICAS
REFERENCIAS
b. Prototipos
c. Taller
4. El primer paso que se debe hacer para realizar una entrevista es:
a. Preparar las preguntas de la entrevista

b. Identificar las personas que se entrevistará ANEXOS
c. Realizar la entrevista
5. En el enfoque pasivo de la observación, el ingeniero de requisitos:
a. Se involucra en las tareas, pasando a formar parte del equipo de trabajo

b. Realiza el análisis en base a notas, videos, etc.
c. Realiza el análisis en base a documentos.
6. En un taller, la primera actividad que se debe realizar es:
a. Identificar las reglas

b. Conducir la reunión
c. Determinar el propósito y los participantes

Conteste una V si considera que la afirmación es correcta, o con una F considera que es falsa.
7. ( ) El usuario no interviene en el proceso de obtención
ÍNDICE
8. ( ) Cuando se realiza la entrevista no estructurada, no es necesario una comprensión por
parte del entrevistador
PRELIMINARES
9. ( ) Una meta-pregunta que el entrevistador podría utilizar es: ¿Estoy haciendo
demasiadas preguntas?
10. ( ) Cuando realiza las actividades de obtención “Educar a los interesados” es una de las
actividades a realizar
BIMESTRE
PRIMER
Recuerde que el solucionario se encuentra al final del presente texto guía.
SEGUNDO
BIMESTRE
Ir a solucionario
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS

SEGUNDO BIMESTRE
89
6.5. Competencias genéricas de la UTPL
• Capacidad de organización y planificación del tiempo

• Capacidad para identificar, plantear y resolver problemas
6.6. Planificación para el trabajo del alumno

Competencias específicas Competencias específicas Tiempo de

Contenidos Actividades de aprendizaje Indicadores de aprendizaje
de la titulación de la asignatura dedicación
Construir modelos de Crea modelos de requisitos Unidad 5. Análisis de requisitos • Leer comprensivamente la unidad • Identifica las actividades para Semana 1
software adecuados que que representen las 5.1. El análisis de requisitos 5 del texto guía. realizar el análisis de requisitos
4 horas de
permitan validar un necesidades de los
5.2. El ciclo de análisis de requisitos • Subrayar o separar lo más • Identifica la mejor estrategia autoestudio
producto previo a su usuarios
importante. para desarrollar el modelo de
implementación 5.3. Los modelos de análisis 4 horas de
análisis
5.4. Herramientas de análisis de • Desarrollar la actividad interacción
recomendada. • Identifica la herramienta
requisitos
apropiada para desarrollar el
5.5. Los diagramas UML • Responder a la autoevaluación 5
modelo de análisis
5.6. Entendiendo los requisitos de • Iniciar con el desarrollo del
• Identifica escenarios que
usuario trabajo a distancia
permitan detallar casos de uso
5.7. Caso de uso • Interactuar en el EVA.
• Identifica las reglas de negocio
5.8. Reglas de negocio • Desarrollar el cuestionario de que aportan a la definición de
refuerzo 1 en el EVA requisitos de software
SEGUNDO BIMESTRE

90
Unidad 6. Especificación de • Leer comprensivamente la unidad • Reconoce las actividades que Semana 2 y
requisitos 6 del texto guía. permiten especificar requisitos 3
6.1. Documentando los requisitos • Subrayar o separar lo más • Define los requisitos 8 horas de
6.2. La especificación de requisitos importante. funcionales y no funcionales autoestudio
6.3. Etiquetado de requisitos • Desarrollar la actividad • Utiliza de forma coherente la 8 horas de
recomendada. plantilla para documentar interacción
6.4. La interfaz de usuario y el ERS
requisitos
6.5. Plantilla para especificar • Responder a la autoevaluación 6.
• Identifica las características
requisitos de software • Continuar con el desarrollo del
que definen a un excelente
6.6. Características de excelentes trabajo a distancia
requisito
requisitos • Interactuar en el EVA.
• Utiliza las directrices de
6.7. Directrices para la redacción de
• Participar en el foro Académico redacción para documentar

requisitos requisitos de calidad
refuerzo 2 en el EVA
Aplica técnicas de Unidad 7. Validando requisitos • Leer comprensivamente la unidad • Comprende la importancia de Semana 4 y
validación de acuerdo a los 7.1. Necesidad de validación 7 del texto guía. la validación de los requisitos 5
modelos de requisitos para
• Subrayar o separar lo más • Diferencia entre verificación y 8 horas de
lograr requisitos de calidad 7.2. Verificación y Validación
importante. validación autoestudio
7.3. Revisión de los requisitos
7.4. Prototipos • Desarrollar la actividad • Elije la estrategia adecuada 8 horas de
recomendada. para validar los requisitos de interacción
7.5. Probando los requisitos software
7.6. Validación de requisitos
trabajo a distancia
• Participar en el Chat académico
SEGUNDO BIMESTRE

91
Reconoce las actividades Unidad 8. Gestión de requisitos • Leer comprensivamente la unidad • Reconoce la importancia de las Semana 6
de gestión de requisitos 8.1. El proceso de gestión de 8 del texto guía. actividades de gestión en el
4 horas de
que se ejecutan desarrollo del proyecto
requisitos • Subrayar o separar lo más autoestudio
paralelamente al desarrollo
8.2. La línea base de los requisitos importante. • Determina la línea base de los
y especificación 4 horas de
requisitos
8.3. Control de versiones • Desarrollar la actividad interacción
recomendada. • Utiliza la estrategia adecuada
8.4. Atributos de los requisitos
para dar seguimiento a los
8.5. Seguimiento al estado de los • Responder a la autoevaluación 8.
requisitos cuando ocurren
requisitos • Finalizar el desarrollo del trabajo a cambios y actualizaciones
distancia y registrar en el EVA
Unidades 5 a la 8 • Revisión de contenidos como Semana 7 y

preparación para la evaluación 8
presencial
8 horas de
autoestudio
8 horas de
interacción
TOTAL DE HORAS 64
SEGUNDO BIMESTRE

Texto-Guía: Ingeniería de Requisitos SEGUNDO BIMESTRE
6.7. Orientaciones específicas para el aprendizaje por competencias
ÍNDICE
UNIDAD 5. ANÁLISIS DE REQUISITOS
PRELIMINARES
Estimado estudiante
Recalcar que el requisito previo necesario para diseñar software que satisfaga las necesidades de los
usuarios es entender lo que los usuarios pretenden hacer con él. Algunos equipos adoptan un enfoque
centrado en el producto. Se centran en definir las características para implementar en el software, con
BIMESTRE
la esperanza de que esas características serán atractivas para los clientes potenciales. En la mayoría de
PRIMER
los casos, sin embargo, es mejor tomar un enfoque centrado en el usuario y centrado en el uso de la
obtención de los requisitos. Centrarse en los usuarios y su uso anticipado ayuda a revelar la funcionalidad
necesaria, evita la implementación de características que nadie va a utilizar, y ayuda con la priorización.
Por lo tanto, en la presente unidad vamos a realizar el análisis de la información mediante modelos de
SEGUNDO
BIMESTRE
análisis que permitan entender los intereses de los interesados clave. El análisis incluye la descomposición
al detalle de requisitos de alto nivel, la construcción de prototipos, evaluación de viabilidad, y la
negociación de prioridades.
5.1. El análisis de requisitos
SOLUCIONARIO
El análisis da lugar a un modelo del sistema que pretende ser correcto, completo, coherente e inequívoco.
Los desarrolladores formalizan la especificación de los requisitos producida durante la obtención de
los requisitos y examinan con más detalle las condiciones de los límites y los casos excepcionales. Los
desarrolladores validan, corrigen y aclaran la especificación de requisitos si se encuentran errores o
BIBLIOGRÁFICAS
REFERENCIAS
ambigüedades. El cliente y el usuario normalmente participan en esta actividad cuando se debe cambiar
la especificación de requisitos y cuando se debe recopilar información adicional (Bern y Allen, 2012).
Los analistas han empleado durante mucho tiempo los escenarios de uso para obtener los requisitos de
los usuarios. La perspectiva centrada en el uso se formalizó en el enfoque del caso de uso para modelar
los requisitos. Más recientemente, los defensores del desarrollo ágil introdujeron el concepto de “historia
del usuario”, una declaración concisa que articula una necesidad del usuario y sirve como punto de
partida para las conversaciones al detalle. ANEXOS
El objetivo es desarrollar los requisitos con el suficiente calidad y detalle de tal manera que los gerentes
pueden construir estimaciones realistas del proyecto y el personal técnico pueda proceder con el diseño,
construcción y pruebas.
A menudo es útil representar algunos de los requisitos de múltiples maneras: por ejemplo, tanto en
forma textual y gráfica. Los resultados del análisis están en los modelos de requisitos. Los modelos de
requisitos (también conocidos como modelos de análisis) son los requisitos de usuario representados por
diagramas, texto estructurado (por ejemplo, listas, tablas o matrices), o combinados. El análisis también
implica dar prioridad a las necesidades mediante el análisis de los requisitos para tomar decisiones sobre
su importancia y oportunidad.

Los requisitos obtenidos desde los interesados y articulados usando modelos de análisis necesitan ser
lo suficientemente claros y completos para posteriormente validar el proceso de requerimientos de
ÍNDICE
software.
El análisis de los requisitos es principalmente responsabilidad del analista, pero puede involucrar a los
actores clave, tales como: usuarios, clientes y personal técnico quienes son necesarios para entender las
necesidades del usuario.
PRELIMINARES
Es importante crear el modelo de requisitos porque le ayudará a:
• Facilitar la comunicación entre personal técnico y empresarios. Los modelos permiten que el
equipo vea diferentes aspectos de las necesidades del usuario desde diferentes perspectivas.  
• Descubrir requisitos faltantes, erróneos, ambiguos y contradictorios. Los modelos de requisitos se
BIMESTRE
PRIMER
enlazan, lo que permite al equipo dar a conocer los requisitos relacionados e inconsistentes entre
modelos. Descubrir y corregir estos errores resulta en requisitos de alta calidad.  
• Hacer que el proceso de desarrollo de requisitos sea más interesante y atractivo para los interesados.
El uso de modelos textuales y visuales ofrece y permite a los interesados entender los requisitos
desde diferentes ángulos.  
SEGUNDO
BIMESTRE
• Utilice los diferentes modos de pensamiento humano. Algunas personas piensan con más
precisión con las palabras, mientras que otras son más capaces de entender los conceptos con
los diagramas. Utilice los dos tipos de representación aprovechando los diferentes modelos de
pensamiento.
SOLUCIONARIO
5.2. El ciclo de análisis de requisitos
BIBLIOGRÁFICAS
REFERENCIAS
Figura 16. El ciclo de análisis de requisitos ANEXOS
Es importante analizar los requisitos a medida que se realice la obtención de las personas, documentos
y fuentes externas. Para analizar los requisitos deberá:
1. Modelo de negocio (si es necesario)
• Determine si el modelado de negocio es necesario.

• Elija uno o más modelos de negocio
• Desarrolle los modelos, verificando su exactitud a medida que evoluciona.

2. Defina el alcance del proyecto
• Crear una combinación de modelos para describir el alcance del proyecto.
ÍNDICE
• Compruebe los modelos entre sí para descubrir los defectos de los requisitos.
• Revisar y obtener un acuerdo con el patrocinador del proyecto.
3. Crear los modelos de requisitos de usuario al detalle
PRELIMINARES
• Seleccione varios modelos que ayudan a los usuarios expresar sus necesidades.
• Repetidamente refinar los modelos, validando sus correcciones.
• Aproveche el plan de obtención de Interesados para hacer mejor uso del tiempo de las
• personas.
• Revisar el alcance de los modelos cuando surjan nuevas necesidades.
BIMESTRE
PRIMER
4. Priorizar los requisitos
• Organizar los requisitos para que fácilmente puedan ser priorizados.

• Reunir a los Interesados para negociar los requisitos.
SEGUNDO
BIMESTRE
• Determinar criterios para la toma de decisiones acerca de la importancia relativa de los
requisitos.
• Priorizar los requerimientos basados en estos criterios.
5. Repita los pasos 3 y 4 a medida que surjan los detalles de los requisitos o se revisen.
SOLUCIONARIO
5.3. Los modelos de análisis
Como lo señaló Alan Davis, ninguna visión de los requisitos proporciona una comprensión completa. Se
necesita una combinación de representaciones de requisitos textuales y visuales en diferentes niveles de
BIBLIOGRÁFICAS
REFERENCIAS
abstracción para tener una imagen completa del sistema deseado. Las vistas de requerimientos pueden
incluir listas de requisitos funcionales, tablas, modelos de análisis visual, prototipos de interfaz de
usuario, pruebas de aceptación, árboles de decisión, tablas de decisión, fotografías, videos y expresiones
matemáticas. (Wigers, 2006)
Idealmente, diferentes personas crearán diversas representaciones de requisitos. El analista de negocios

podría escribir los requisitos funcionales y dibujar algunos modelos, mientras que el diseñador de
ANEXOS
interfaz de usuario construye un prototipo y el jefe de prueba escribe casos de prueba. La comparación
de las representaciones de requisitos creadas a través de diversos procesos de pensamiento y diversas
notaciones revela inconsistencias, ambigüedades, suposiciones y omisiones que son difíciles de detectar
desde una sola vista.
Los diagramas comunican ciertos tipos de información más eficientemente que el texto. Las imágenes
ayudan a superar barreras lingüísticas y de vocabulario entre los miembros del equipo. El analista de
negocio inicialmente podría tener que explicar el propósito de los modelos y las anotaciones utilizadas
a otros interesados. Hay muchos diagramas diferentes y técnicas de modelado para elegir para crear
representaciones visuales de los requisitos.
Los analistas de negocios podrían esperar encontrar una técnica que combine todo en una representación
holística de los requisitos de un sistema. Desafortunadamente, no hay un diagrama que lo abarque
todo. De hecho, si pudiera modelar todo el sistema en un solo diagrama, ese diagrama sería tan

inutilizable como una larga lista de requisitos por sí solo. Un objetivo temprano del análisis estructurado
de sistemas fue sustituir la especificación funcional clásica por diagramas y anotaciones que son más
ÍNDICE
formales que el texto narrativo. Sin embargo, la experiencia ha demostrado que los modelos de análisis
deberían aumentar -y no reemplazar- una especificación de requisitos escrita en lenguaje natural. Los
desarrolladores y probadores siguen beneficiándose del detalle y la precisión que ofrecen la escritura de
los requisitos.
PRELIMINARES
Los modelos de requisitos visuales pueden ayudarle a identificar los requisitos que faltan, extraños e
incoherentes. Dadas las limitaciones de la memoria humana a corto plazo, es casi imposible analizar
una lista de mil requisitos por inconsistencias, duplicación y requisitos extraños. En el momento en que
usted alcance el decimoquinto requisito, es probable que haya olvidado los primeros que lee. Es poco
probable que encuentre todos los errores simplemente revisando los requisitos textuales.
Los modelos de requisitos visuales que se describen incluyen:
BIMESTRE
PRIMER
• Diagramas de flujo de datos
• Diagramas de procesos
• Diagramas de estado-transición y tablas de estado
• Mapas de dialogo
SEGUNDO
BIMESTRE
• Tablas de decisión y árboles de decisión
• Tablas evento/respuesta
• Árboles de características
• Diagramas de casos de uso
SOLUCIONARIO
• Diagramas de actividad
• Diagramas entidad-relación
Las anotaciones presentadas aquí proporcionan un lenguaje común estándar de la industria para el uso
de los participantes del proyecto. Inventar sus propias notaciones de modelado presenta más riesgo de
BIBLIOGRÁFICAS
mala interpretación que si adopta las notaciones estándar.
REFERENCIAS
Estos modelos son útiles para elaborar y explorar los requisitos, así como para diseñar soluciones de
software. Si los está utilizando para el análisis o para el diseño depende del momento y la intención del
modelado. Utilizados para el análisis de requisitos, estos diagramas permiten modelar el dominio del
problema o crear representaciones conceptuales del nuevo sistema. Representan los aspectos lógicos
de los componentes de datos, transacciones y transformaciones del dominio del problema, objetos del
mundo real y cambios en el estado del sistema. Puede basar los modelos en los requisitos de texto para ANEXOS
representarlos desde diferentes perspectivas o puede derivar requisitos funcionales de modelos de alto
nivel que se basan en la entrada del usuario.
Durante el diseño, los modelos representan cómo se pretende implementar el sistema: la base de datos
real para crear, las clases de objetos para instanciar y los módulos de código que se van a desarrollar.
Debido a que los diagramas de análisis y diseño utilizan las mismas anotaciones, identifique claramente
cada una de ellas como un modelo de análisis (los conceptos) o un modelo de diseño (lo que se pretende
construir).
Las técnicas de modelado de análisis descritas a continuación están soportadas por una variedad de
herramientas de modelado comercial, herramientas de gestión de requisitos y herramientas de dibujo
como Microsoft Visio. Las herramientas de modelización especializadas ofrecen varios beneficios sobre
las herramientas de dibujo de propósito general. En primer lugar, facilitan la mejora de los diagramas a

través de la iteración. Casi nunca obtendrá un modelo justo la primera vez, por lo que la iteración es una
clave para modelar con éxito.
ÍNDICE
Las herramientas también pueden hacer cumplir las reglas para cada método de modelado que soportan.
Pueden identificar errores de sintaxis e incoherencias que las personas que revisan los diagramas
podrían no ver. Las herramientas de gestión de requisitos que soportan el modelado le permiten rastrear
los requisitos de los modelos. Algunas herramientas enlazan varios diagramas juntos y sus requisitos
PRELIMINARES
funcionales y de datos relacionados. El uso de una herramienta con símbolos estándar puede ayudarle a
mantener los modelos coherentes entre sí.
A menudo se escucha argumentos en contra del uso de modelos de requisitos que van desde “Nuestro
sistema es demasiado complejo para modelar” hasta “Tenemos un calendario de proyecto apretado; No
hay tiempo para modelar los requisitos “. Si no puede manejar la complejidad del modelo, ¿cómo podrá
manejar la complejidad del sistema? La creación de la mayoría de los modelos no requiere mucho más
BIMESTRE
PRIMER
tiempo de lo que pasaría escribiendo las instrucciones de los requisitos y analizándolos por problemas.
Cualquier tiempo extra que se gaste usando modelos de análisis de requisitos debe ser más que
compensado por la captura de errores de requisitos antes de la construcción del sistema. Los modelos,
o porciones de modelos, a veces pueden ser reutilizados de un proyecto a otro, o al menos servir como
un punto de partida para la obtención de requisitos en un proyecto posterior.
SEGUNDO
BIMESTRE
Al escuchar atentamente cómo los clientes presentan sus requisitos, el analista de negocios puede
seleccionar palabras clave que se traducen en elementos específicos del modelo. En la tabla 8 se sugiere
posibles asignaciones de las opciones de palabras de los clientes en los componentes del modelo,
que se describen más adelante en este capítulo. A medida que evolucione la entrada del cliente en
SOLUCIONARIO
los requisitos y modelos escritos, debería ser capaz de vincular cada componente del modelo con un
requerimiento específico del usuario.
Tabla 8.
Relación del cliente con los componentes del modelo de análisis
BIBLIOGRÁFICAS
REFERENCIAS
Tipo de palabra Ejemplo Componentes del modelo de análisis
•• Entidades externas, almacenes de datos, o
flujo de datos.
Personas, organizaciones, sistemas de
•• Actores (diagramas de casos de uso)
Sustantivo software, elementos de datos, u objetos
•• Entidades o sus atributos
que existen
•• Canales (Mapa de procesos)
•• Objetos con estados
•• Procesos ANEXOS
•• Pasos del proceso (Mapa de procesos)
Acciones, cosas que un usuario o un •• Casos de uso (Diagrama de casos de uso)
Verbo sistema puede hacer, o eventos que •• Relaciones (Diagrama entidad-relación)
pueden tener lugar •• Transición (Diagrama de estado-transición)
•• Actividades (Diagrama de actividades)
•• Eventos (Tabla evento-respuesta)
•• Decisión (árbol de decisión, tabla de
Declaración lógica condicional, como es decisión, o diagrama de actividad)
Condicional
Si/entonces •• Derivación (Mapa de procesos o diagrama
de actividad)

5.4. Herramientas de análisis de requisitos
ÍNDICE
Rara vez un equipo necesita crear un conjunto completo de modelos de análisis para todo un sistema.
Enfoque su modelado en las partes más complejas y riesgosas del sistema y en aquellas partes más
sujetas a ambigüedad o incertidumbre.
Entonces, ¿Qué modelo crear?
PRELIMINARES
Existen diferentes puntos de vista para utilizar el modelo adecuado. Gottesdiener (2005) indica que se
puede usar una variedad de modelos de requisitos de usuarios para analizar los requisitos. Los modelos
representan respuestas a las preguntas “4W’s + H” (Who? What? When? Why? + How?) (¿Quién? ¿Qué?
¿Cuándo? ¿Por qué? y ¿Cómo?).
BIMESTRE
Tabla 9.
PRIMER
Modelos de requisitos basados en el enfoque del usuario
Enfoque de la Modelo de requisitos de usuario para este

Ejemplo de pregunta
pregunta enfoque
•• ¿Quienes son los interesados del proyecto? •• Categoría de interesados
SEGUNDO
BIMESTRE
•• ¿Quiénes interactuaran directamente con
•• Tabla de actores o personas
¿Quién? el sistema?
•• ¿Quién supervisará la interactividad con el
•• Mapa de dialogo
sistema?
•• ¿Qué hace importante el significado de los
SOLUCIONARIO
•• Glosario
términos de negocio?
•• ¿Qué funciones de la organización •• Mapa de relaciones (un modelo de
interactúan para compartir información? negocio)
¿Qué?
•• ¿Qué información entra y sale del sistema? •• Diagrama de contexto
•• ¿Qué son los elementos de datos estáticos
BIBLIOGRÁFICAS
que se deben almacenar y cómo se •• Modelo de datos
REFERENCIAS
relacionan?
•• ¿Cuándo el sistema necesita responder o
•• Tabla evento-respuesta
actuar?
¿Cuándo?
•• ¿Cuándo se realizaron las tareas y cuando
•• Diagrama de estado
se cambia la información?
•• ¿Por qué estamos motivados para hacer
cumplir las normas, políticas, reglamentos •• Políticas de negocio ANEXOS
y legislación?
¿Por qué?
•• ¿Por qué son las decisiones las que influyen
en el comportamiento y hacen valer la •• Reglas del negocio
estructura empresarial?
•• ¿Cómo hacer operar los procesos en el
•• Mapa de procesos (Un modelo de
negocio para alcanzar los objetivos de
negocio)
negocio?
•• Utilice casos de uso y posiblemente los
¿Cómo? mapas de casos de uso y los paquetes
•• ¿Cómo son las tareas realizadas y en qué de caso (complementado o sustituido
secuencia? por escenarios, historias, diagramas de
actividad de casos de uso, o diagramas
de flujo de datos.

Una quinta “W – Where” ante todo provee información acerca de los requisitos no funcionales,
especialmente aquellos relacionados con el futuro operativo y ambiente de despliegue.
ÍNDICE
Ciertos modelos son más apropiados para determinar los requisitos de ciertos dominios de negocio. Se
escoge el modelo de acuerdo a una pregunta de enfoque que se indica en la tabla 9. (¿Quién? ¿Qué?
¿Cuándo? ¿Por qué? y ¿Cómo?), que proporcione una potencial comprensión entre los requisitos y el
desarrollo del modelo. Por ejemplo:
PRELIMINARES
• Dominios transaccionales de negocio:
Que manejan procesos de negocio y tareas tales como: operaciones de negocios y administración,
procesamiento de pedidos y gestión de inventario. Son muy adecuadas para los modelos “¿Cómo?”. Por
ejemplo, casos de uso y escenarios. Relacionados con modelos “¿Quién? y ¿Por qué?”, que también son
útiles para estos dominios. Por ejemplo: los actores y reglas de negocio.
BIMESTRE
PRIMER
• Dominios estructurales:
Existen para almacenar y analizar datos, tales como: sistemas de minería de datos, generar consultas
e informes. Son adecuados los modelos “¿Qué?”. Por ejemplo, modelos de datos. También se puede
complementar con los modelos “¿Por qué?”. Por ejemplo, con reglas de negocio.
SEGUNDO
BIMESTRE
• Dominios dinámicos:
Que responden a los acontecimientos en constante cambio para almacenar datos y actuar en función
de su estado en un punto en el tiempo. Por ejemplo: los sistemas que gestionan el tráfico en la red, la
SOLUCIONARIO
adjudicación, las operaciones de un dispositivo mecánico, y otras operaciones en tiempo real. Es muy
adecuado los modelos “¿Cuándo?”. Por ejemplo: tablas de evento-respuesta y diagramas de estado.
También se pueden incluir los modelos: “¿Por qué?” (por ejemplo, con reglas de negocio), modelos “¿Qué?”
(por ejemplo, con modelos de datos), y con modelos “¿Quién?” cuando el usuario está involucrado con
interfaces de usuario.
BIBLIOGRÁFICAS
REFERENCIAS
• Dominios orientados al control:
Evalúan las condiciones para tomar medidas o decisiones como la logística, la detección de fraudes,
la configuración del producto, y el diagnóstico. La mejor forma de describir es utilizando los modelos
“¿Por qué?”. Por ejemplo: reglas de negocio y tablas de decisión. Debe ser complementado con modelos
“¿Qué?”. Por ejemplo, modelos de datos.
Importante ANEXOS
Estimado estudiante, tenga presente que estas son sólo directrices. Cada dominio es
diferente por lo que debe determinar qué modelos son los más útiles en el desarrollo
de un subconjunto de modelos en forma preliminar y validación de ellos, y luego
ajustar sus selecciones. No es necesario usar todos los modelos de requerimientos.
Puede escoger un subconjunto que sea adecuado al dominio del problema. Ahorre
tiempo a los interesados elaborando unos modelos de alto nivel, y luego consulte si
son útiles.
Sea claro si cada modelo representa la situación “as-is” o “to-be”. Cuando el proceso actual, datos o sistema
no es bien entendido, primero cree uno o más modelos “as-is”. Evite la parálisis del análisis al redactar
la situación de “tal cual” como un ámbito o nivel alto, tan sólo lo suficiente para comprender el entorno
actual, al mismo tiempo que se garantiza que los requisitos importantes satisfechos por el sistema actual
también serán incluidos en el nuevo sistema.

En Wiegers y Beatty (2013) se sugiere qué técnicas de representación utilizar en base al tipo de
información que se intenta mostrar, analizar o descubrir. También se consideran sugerencias adicionales
ÍNDICE
sobre qué modelos de requisitos se deben crear en función de las fases del proyecto, las características
del proyecto y el público objetivo de los modelos.
Tabla 10.
Técnicas de representación de acuerdo a la información expresada
PRELIMINARES
Información
Técnicas de representación
representada
•• El diagrama de contexto y el diagrama de casos de uso identifican objetos fuera del
sistema que se conectan a él. El diagrama de contexto y los diagramas de flujo de datos
ilustran las entradas y salidas del sistema con un alto nivel de abstracción. El mapa del
ecosistema identifica posibles sistemas que interactúan, pero incluye algunos que no
BIMESTRE
PRIMER
interfieren directamente también. Los mapas de proceso muestran lo que ocurre en las
Interfaces externas
interacciones entre los sistemas.
del sistema
•• Los detalles de la interfaz externa pueden ser grabados en los formatos de archivo
de entrada y salida o en las presentaciones de informes. Los productos que incluyen
componentes de software y hardware a menudo tienen especificaciones de interfaz con
definiciones de atributo de datos, tal vez en la forma de una interfaz de programación de
SEGUNDO
BIMESTRE
aplicaciones o señales específicas de entrada y salida para un dispositivo de hardware.
•• Un diagrama de flujo de datos de nivel superior representa cómo un proceso de
negocio maneja datos en un alto nivel de abstracción. Los mapas de proceso muestran
los roles que participan en la ejecución de los diversos pasos en un flujo de procesos
Flujo de procesos de negocio.
de negocio •• Niveles refinados de diagramas de flujo de datos o mapa de proceso pueden representar
SOLUCIONARIO
los procesos de negocio con un considerable detalle. De forma similar, los diagramas
de flujo y los diagramas de actividad pueden usarse en niveles de abstracción altos o
bajos, aunque lo más comúnmente se usan para definir los detalles de un proceso.
•• El diagrama entidad-relación muestra las relaciones lógicas entre los objetos de datos
(entidades). Los diagramas de clases muestran las conexiones lógicas entre las clases
Definición de
de objetos y los datos asociados a ellas.
BIBLIOGRÁFICAS
datos y relación de
REFERENCIAS
•• El diccionario de datos contiene definiciones detalladas de estructuras de datos y
objetos de datos
elementos de datos individuales. Los objetos de datos complejos se descomponen
progresivamente en sus elementos de datos constitutivos.
•• Los diagramas de transición de estado y las tablas de estado representan una vista de
alta abstracción de los posibles estados de un sistema u objeto y los cambios entre
estados que pueden tener lugar en determinadas circunstancias. Estos modelos son
útiles cuando varios casos de uso pueden manipular (y cambiar el estado de) ciertos
ANEXOS
objetos.
Estado del sistema •• Algunos analistas crean una tabla de evento-respuesta como una herramienta de
y del objeto alcance, identificando eventos externos que ayudan a definir el límite de alcance del
producto. También puede especificar requisitos funcionales individuales con una tabla
de evento-respuesta detallando cómo debe comportarse el sistema en respuesta a
cada combinación de evento externo y estado del sistema.
•• Los requisitos funcionales proporcionan los detalles que describen exactamente qué
comportamientos de usuario y sistema conducen a cambios de estado.
•• Un árbol de decisiones muestra los posibles resultados de un conjunto de decisiones o
condiciones relacionadas. Una tabla de decisiones identifica los requisitos funcionales
Lógica compleja
únicos asociados con las diversas combinaciones de resultados verdaderos y falsos
para una serie de decisiones o condiciones.

Información
Técnicas de representación
representada
ÍNDICE
•• El mapa de diálogo proporciona una vista de alto nivel de una interfaz de usuario
propuesta o real, mostrando los diversos elementos de visualización y posibles rutas
de navegación entre ellos.
•• Los guiones gráficos y los prototipos de baja delicadeza muestran el mapa de diálogo
mostrando lo que cada pantalla contendrá sin describir detalles precisos. Los modelos
PRELIMINARES
Interfaz de usuario de respuesta a la acción describen los requisitos de visualización y comportamiento de
cada pantalla.
•• Los diseños de pantalla detallados y los prototipos de alta precisión muestran
exactamente cómo se verán los elementos de la pantalla. Las definiciones de campo
de datos y las descripciones de control de interfaz de usuario proporcionan detalles
adicionales.
•• Las historias de usuarios, los escenarios y las especificaciones de casos de uso describen
BIMESTRE
PRIMER
tareas de usuario en varios niveles de detalle.
•• Los diagramas de Swimlane ilustran el proceso de negocio o la interacción entre
múltiples actores y el sistema. Los diagramas de flujo y los diagramas de actividad
representan visualmente el significado del diálogo de casos de uso y se ramifican en
Descripción de
flujos y excepciones alternativos.
tareas de usuario
•• Los requisitos funcionales proporcionan descripciones detalladas de cómo el sistema
y el usuario interactuarán para lograr resultados valiosos. Los casos de prueba
SEGUNDO
BIMESTRE
proporcionan una vista alternativa de baja abstracción, que describe exactamente qué
comportamiento del sistema se debe esperar bajo condiciones específicas de entradas,
estado del sistema y acciones.
Requisitos no
funcionales
•• Los atributos y restricciones de calidad suelen escribirse en forma de texto en lenguaje
SOLUCIONARIO
(atributos
natural, pero a menudo resulta en una falta de precisión e integridad.
de calidad,
restricciones)
A continuación, vamos a describir algunas de las herramientas que permiten al analista de negocio a
realizar el análisis dependiendo del nivel de detalle.
BIBLIOGRÁFICAS
REFERENCIAS
5.4.1. Diagrama de flujo de datos
El diagrama de flujo de datos (DFD) es la herramienta básica del análisis estructurado. Un DFD identifica
los procesos de transformación de un sistema, las colecciones (almacenes) de datos o materiales físicos
que manipula el sistema, y los datos o materiales entre procesos, almacenes y el mundo exterior. El
modelado de datos toma un enfoque de descomposición funcional para el análisis de sistemas,
rompiendo problemas complejos en niveles progresivos de detalle. Esto funciona bien para los sistemas ANEXOS
de procesamiento de transacciones y otras aplicaciones de uso intensivo de funciones. A través de la
adición de elementos de control, la técnica DFD se ha extendido para permitir el modelado de sistemas
en tiempo real (Hatley, Hruschka, & Pirbhai, 2000).
Los DFD proporcionan una visión general de cómo los datos se mueven a través de un sistema. Varias
personas y sistemas ejecutan procesos que usan, manipulan y producen datos, por lo que cualquier caso
de uso único o mapa de proceso no puede mostrarle el ciclo de vida completo de una pieza de datos.
Además, se pueden extraer múltiples piezas de datos y transformarlas mediante un proceso (por ejemplo,
el contenido del carrito de la compra más la información de envío más la información de facturación se
transforman en un objeto de pedido). Una vez más, esto es difícil de mostrar en otros modelos. Sin
embargo, los DFD no son una técnica de modelado único. Los detalles sobre cómo se transforman los
datos se muestran mejor mediante pasos en un proceso que utiliza casos de uso o mapas de proceso.

Los diagramas de flujo de datos pueden representar sistemas en un amplio rango de abstracción. Los DFD
de alto nivel ofrecen una visión holística de los datos y componentes de procesamiento en una actividad
ÍNDICE
de varios pasos, que complementa la visión precisa y detallada incorporada en los requisitos funcionales.
El diagrama de contexto (que se indica en el literal 3.3.1) representa el nivel más alto de abstracción
del DFD. El diagrama de contexto representa todo el sistema como un único proceso de caja negra,
representado como un círculo (una burbuja). También muestra las entidades externas, o terminadores,
que se conectan al sistema, y los flujos de datos o materiales entre el sistema y las entidades externas.
PRELIMINARES
Los flujos en un diagrama de contexto a menudo representan estructuras de datos complejas, que se
definen en el diccionario de datos.
En la figura 11 se muestra un DFD nivel 0 para el Sistema de Gestión de Trámites de la UTPL. Este
modelo utiliza la notación DFD de Yourdon-DeMarco. Hay notaciones alternativas que utilizan símbolos
ligeramente diferentes, tal como se indica en la figura 17, el único círculo que representó todo el “SGT-
BIMESTRE
UTPL” en el diagrama de contexto se ha subdividido en cuatro procesos principales (Las burbujas de
PRIMER
proceso). Como con el diagrama de contexto, las entidades externas se muestran en rectángulos.
Todos los flujos de datos (flechas) del diagrama de contexto también aparecen en el nivel 0 del DFD.
Además, el diagrama de nivel 0 contiene varios almacenes de datos, representados como un par de
líneas horizontales paralelas, que son internas al sistema y por lo tanto no aparecen en el diagrama de
contexto. Un flujo de una burbuja a un almacén indica que los datos se están colocando en el almacén,
SEGUNDO
BIMESTRE
un flujo del almacén muestra una operación de lectura y una flecha bidireccional entre un almacén y una
burbuja indica una operación de actualización.
Cada proceso que aparece como una burbuja separada en el diagrama de nivel 0 puede ampliarse aún
más en un DFD separado para revelar más detalles sobre su funcionamiento. El analista de negocio
SOLUCIONARIO
continúa este proceso progresivo hasta que los diagramas de nivel más bajo contienen sólo operaciones
primitivas del proceso que pueden ser claramente representadas en el texto narrativo, pseudocódigo,
un mapa de proceso o un diagrama de actividad.
Los requisitos funcionales definirán precisamente lo que sucede dentro de cada proceso primitivo. Cada
nivel del DFD debe ser equilibrado y consistente con el nivel por encima de él para que todos los flujos
BIBLIOGRÁFICAS
REFERENCIAS
de entrada y salida en el diagrama secundario coincidan con los flujos en su matriz. Las estructuras
de datos complejas en los diagramas de alto nivel pueden dividirse en sus elementos constitutivos, tal
como se definen en el diccionario de datos, en los DFD de nivel inferior.
ANEXOS

ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRÁFICAS
Figura 17. Diagrama de flujo de datos para el “SGT-UTPL”
REFERENCIAS
A continuación, se presentan varias convenciones para dibujar diagramas de datos. No todo el mundo
se adhiere a las mismas convenciones, pero les resulta útil. El uso de los modelos para mejorar la
comunicación entre los participantes del proyecto es más importante que la conformidad dogmática
con estos principios.
• Los procesos se comunican a través de almacenes de datos, no por medio de operaciones directas ANEXOS
de un proceso a otro. De manera similar, los datos no pueden pasar directamente de un almacén
a otro o directamente entre entidades externas y almacenes de datos; Debe pasar a través de una
burbuja de proceso.
• No trate de implicar la secuencia de procesamiento usando el DFD.
• Nombrar cada proceso como una acción concisa: verbo más objeto (como “generar informes”).
Utilice nombres que sean significativos para los clientes y pertinentes para el negocio o el dominio
del problema.
• Numere los procesos de forma única y jerárquica. En el diagrama de nivel 0, numera cada proceso
con un entero. Si crea un DFD hijo para el proceso 3, numere los procesos en ese diagrama
secundario 3.1, 3.2 y así sucesivamente.

• No muestre más de 8 a 10 procesos en un solo diagrama o será difícil dibujar, cambiar y entender.
Si tiene más procesos, introduzca otra capa de abstracción agrupando los procesos relacionados
ÍNDICE
en un proceso de nivel superior.
• Las burbujas con flujos que sólo entran o sólo salen son sospechosas. El procesamiento que una
burbuja de DFD representa normalmente requiere flujos de entrada y salida.
PRELIMINARES
Cuando los representantes de clientes revisan un DFD, deben asegurarse de que todos los procesos
de manipulación de datos conocidos y relevantes están representados y que los procesos no tienen
entradas o salidas que faltan o son innecesarias. Las revisiones de DFD a menudo revelan clases de
usuario no reconocidas previamente, procesos de negocio y conexiones a otros sistemas.
5.4.2. Mapa de procesos
BIMESTRE
PRIMER
A los mapas de proceso, también se los conoce como: diagramas de Swimlane, mapa de procesos
interfuncional (cross-functional) o modelo de línea de visibilidad (LOVEM). Estos diagramas proporcionan
una forma de representar los pasos involucrados en un proceso de negocio o las operaciones de un sistema
de software propuesto. Son una variación de diagramas de flujo, subdivididos en subcomponentes
visuales llamados carriles. Los carriles pueden representar diferentes sistemas o actores que ejecutan los
pasos del proceso. Los mapas de proceso se usan más comúnmente para mostrar procesos de negocios,
SEGUNDO
BIMESTRE
flujos de trabajo o interacciones entre el sistema y el usuario. Son similares a los diagramas de actividad
de UML.
Estos diagramas permiten mostrar lo que sucede dentro de las burbujas de proceso de DFD. Ayudan a
unir los requisitos funcionales que permiten a los usuarios realizar tareas específicas. También se pueden
SOLUCIONARIO
utilizar para realizar un análisis detallado para identificar los requisitos que soportan cada paso del
proceso. (Beatty y Chen, 2012)
El mapa de procesos es uno de los modelos más fáciles para que los interesados entiendan porque la
notación es simple y de uso general. La redacción de procesos empresariales en éstos diagramas puede
BIBLIOGRÁFICAS
ser un buen punto de partida para las conversaciones de obtención. Los mapas de proceso pueden
REFERENCIAS
contener formas adicionales, pero los elementos más utilizados son:
• Pasos del proceso, mostrados como rectángulos.
• Transiciones entre etapas del proceso, mostradas como flechas conectando pares de rectángulos
• Decisiones, mostradas como diamantes con múltiples ramas que salen de cada diamante. Las
opciones de decisión se muestran como etiquetas de texto en cada flecha que sale de un diamante. ANEXOS
• Carriles para subdividir el proceso, mostrado como líneas horizontales o verticales en la página.
Los carriles son más comúnmente funciones, departamentos o sistemas. Muestran quién o qué
está ejecutando los pasos en un carril dado.
Para construir un mapa de procesos, realice lo siguiente:
1. Nombre el proceso de negocio a ser modelado, comenzando con un verbo de acción.
2. Defina el evento de negocio que dispara o empieza el proceso. Para nombrar el evento de negocio
utilice el formato “sujeto + verbo + objeto”.
3. Nombre el punto final o el resultado del proceso. Asigne un nombre simple y directo, expresado
en positivo

4. Enumere a los participantes en el proceso de negocio (por ejemplo: áreas funcionales,

departamentos o roles) en una columna a lo largo del lado izquierdo del diagrama
ÍNDICE
5. Cree filas horizontales o carriles para cada participante, para representar a la entidad organizacional
o rol dónde el trabajo el hecho.
• Coloque el carril más involucrado en el proceso como el carril superior en la página.
PRELIMINARES
• Utilice carriles que tengan aproximadamente el mismo nivel de detalle.
• Use roles de trabajo (en lugar de departamentos o funciones) como carriles para flujos de
trabajo menos complejos.
6. Identifique todos los pasos del proceso que ocurren entre el evento desencadenante y el resultado.
Utilice los elementos que se indican anteriormente.
BIMESTRE
PRIMER
7. Identifique las salidas de cada paso
• Dibujar líneas que conectan las cajas de proceso que proporcionan resultados a otras cajas
de procesos. Añada una punta de flecha, mostrando su dirección a otro proceso.
• Etiquetar cada línea usando nombres de alto nivel
SEGUNDO
BIMESTRE
8. Revise el diagrama como sea necesario
• Asegúrese de que todos los pasos se aproximan al mismo nivel de detalle y que cada paso
es necesario para producir el resultado.
SOLUCIONARIO
En la figura 18 de presenta un ejemplo de acuerdo al caso práctico, para el proceso “Asentamiento de
nota”, es importante que analice cada una de las actividades que se realizan y quien las ejecuta. Este
mapa se puede validar con el usuario y tener una retroalimentación para hacer los ajustes necesarios si
fiera el caso.
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS

ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS
Figura 18. Mapa de procesos para el “SGT-UTPL”
5.4.3. Diagrama de transición de estados y tabla de estados
Los sistemas de software implican una combinación de comportamiento funcional, manipulación

de datos y cambios de estado. Los sistemas en tiempo real y las aplicaciones de control de procesos
pueden existir en uno de un número limitado de estados en un momento dado. Un cambio de estado
sólo puede tener lugar cuando se satisfacen criterios bien definidos, como recibir un estímulo de
entrada específico bajo ciertas condiciones. Un ejemplo es una intersección de carreteras que incorpora
sensores de vehículos, carriles de giro protegidos y botones y señales para peatones. Muchos sistemas

de información se ocupan de los objetos de negocio -las órdenes de venta, las facturas, los artículos de
inventario y similares- con ciclos de vida que implican una serie de posibles estados o estados.
ÍNDICE
Describir un conjunto de cambios de estado complejos en lenguaje natural crea una alta probabilidad de
pasar por alto un cambio de estado permitido o incluir un cambio no permitido. Dependiendo de cómo
se organice un ERS, los requisitos que pertenecen al comportamiento impulsado por el estado pueden
ser esparcidos a través de él. Esto hace difícil llegar a una comprensión general del comportamiento del
PRELIMINARES
sistema.
Los diagramas de estado de transición y tablas de estado son dos modelos de estado que proporcionan
una representación concisa, completa y sin ambigüedad de los estados de un objeto o sistema. El
diagrama de transición de estado (STD) tal como se indica en la figura 19, muestra las posibles transiciones
entre estados visualmente. Una técnica relacionada es el diagrama de máquina de estado incluido en el
UML, que tiene un conjunto más rico de anotaciones y que modela los estados que un objeto atraviesa
BIMESTRE
PRIMER
durante su vida. El STD contiene tres tipos de elementos:
• Posibles estados del sistema, mostrados como rectángulos. Algunas anotaciones utilizan círculos
para representar el estado. Los círculos o rectángulos funcionan bien; Sólo sea consistente en lo
que elija utilizar.
SEGUNDO
BIMESTRE
• Cambios o transiciones de estado permitidos, mostrados como flechas conectando pares de
rectángulos.
• Eventos o condiciones que hacen que cada transición tenga lugar, mostrada como etiquetas
de texto en cada flecha de transición. La etiqueta puede identificar el evento y la respuesta del
SOLUCIONARIO
sistema correspondiente.
El STD para un objeto que pasa a través de un ciclo de vida definido tendrá uno o más estados de
terminación, que representan los valores finales de estado que un objeto puede tener. Los estados de
terminación tienen flechas de transición entrando, pero ninguna saliendo. Los clientes pueden aprender
BIBLIOGRÁFICAS
a leer un STD con sólo un poco de entrenamiento sobre la notación, esto es sólo cajas y flechas.
REFERENCIAS
ANEXOS

ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
Figura 19. Ejemplo de diagrama de estado
5.4.4. Mapa de diálogo
El mapa de diálogo representa un diseño de interfaz de usuario con un alto nivel de abstracción. Muestra
los elementos de diálogo en el sistema y los enlaces de navegación entre ellos, pero no muestra los
diseños de pantalla detallados. Una interfaz de usuario puede considerarse como una serie de cambios ANEXOS
de estado. Sólo un elemento de diálogo (como un menú, un área de trabajo, un cuadro de diálogo,
un indicador de línea o una pantalla táctil) está disponible en cualquier momento para la entrada del
usuario. El usuario puede navegar a otros elementos de diálogo basándose en la acción que toma en la
ubicación de entrada activa. El número de rutas de navegación posibles puede ser grande en un sistema
complejo, pero el número es finito y las opciones son usualmente conocidas. Un mapa de diálogo es
realmente sólo una interfaz de usuario modelada en forma de un diagrama de transición de. Existe
una técnica similar llamada mapa de navegación, que incluye un conjunto más rico de notaciones para
representar diferentes tipos de elementos de interacción y transiciones de contexto. Un flujo de interfaz
de usuario es similar a un mapa de diálogo, pero muestra las rutas de navegación entre las pantallas de
interfaz de usuario en un formato de mapa de proceso. (Beatty y Chen, 2012)
Un mapa de diálogo le permite explorar conceptos hipotéticos de interfaz de usuario basados en su

comprensión de los requisitos. Los usuarios y desarrolladores pueden estudiar un mapa de diálogo para

alcanzar una visión común de cómo el usuario puede interactuar con el sistema para realizar una tarea.
Los mapas de diálogo también son útiles para modelar la arquitectura visual de un sitio web. Los enlaces
ÍNDICE
de navegación que se crean en el sitio web aparecen como transiciones en el mapa de diálogo. Por
supuesto, el usuario tiene opciones de navegación adicionales a través de los botones de retroceso y
avance del navegador, así como el campo de entrada de URL, pero el mapa de diálogo no los muestra.
Los mapas de diálogo están relacionados con los guiones gráficos del sistema, que también incluyen
una breve descripción del propósito de cada pantalla.
PRELIMINARES
Los mapas de los diálogos capturan la esencia de las interacciones entre el sistema y el usuario sin afectar
al equipo en los diseños detallados de la pantalla. Los usuarios pueden rastrear a través de un mapa de
diálogo para encontrar navegación faltantes, incorrectas o innecesarias y, por lo tanto, los requisitos
faltantes, incorrectos o innecesarios. El mapa de diálogo conceptual abstracto formulado durante el
análisis de requisitos sirve como guía durante el diseño detallado de la interfaz de usuario.
BIMESTRE
PRIMER
Al igual que en los diagramas de transición de estados ordinarios, el cuadro de diálogo muestra cada
elemento de diálogo como un estado (rectángulo) y cada opción de navegación permitida como una
transición (flecha). La condición que activa la navegación de la interfaz de usuario se muestra como una
etiqueta de texto en la flecha de transición. Existen varios tipos de condiciones de disparo:
SEGUNDO
BIMESTRE
• Una acción del usuario, como pulsar una tecla de función, hacer clic en un hipervínculo o hacer un
gesto en una pantalla táctil.
• Un valor de datos, tal como un valor de entrada de usuario no válido que activa una visualización
de mensaje de error
SOLUCIONARIO
• Una condición del sistema, como detectar que la impresora no tiene papel
• Algunas combinaciones de éstas, como escribir un número de opción de menú y presionar la tecla
<<Enter>>
Los mapas de diálogo son muy parecidos a los diagramas de flujo, pero sirven a un propósito diferente.
BIBLIOGRÁFICAS
REFERENCIAS
Un diagrama de flujo muestra explícitamente los pasos de procesamiento y los puntos de decisión, pero
no la interfaz de usuario. Por el contrario, el mapa de diálogo no muestra el procesamiento que tiene
lugar a lo largo de las líneas de transición que conectan un elemento de diálogo a otro. Las decisiones de
ramificación (por lo general las opciones de usuario) se ocultan detrás de las pantallas de visualización
que se muestran como rectángulos en el mapa de diálogo, y las condiciones que conducen a mostrar
una pantalla u otra aparecen en las etiquetas de las transiciones.
ANEXOS
Para simplificar el cuadro de diálogo, omita las funciones globales, como pulsar la tecla F1 para abrir
una pantalla de ayuda desde cada elemento de diálogo. La sección del ERS en las interfaces de usuario
debe especificar que esta funcionalidad estará disponible, no es necesario mostrar un montón de
cuadros de pantalla de ayuda en el mapa de diálogo ya que desordena el modelo y agrega poco valor.
Del mismo modo, al modelar un sitio web, no es necesario incluir los vínculos de navegación estándar
que aparecerán en cada página del sitio. También puede omitir las transiciones que invierten el flujo
de una secuencia de navegación de página web porque el botón Atrás del explorador web maneja esa
navegación.
Un mapa de diálogo tal como se muestra en la figura 20, es una excelente manera de representar las
interacciones entre un actor y el sistema que describe un caso de uso. El cuadro de diálogo puede
representar flujos alternativos como ramas del flujo normal. Para los casos de uso y los procesos que ya
están completos, compárelos con los mapas de diálogo para asegurarse de que se pueden acceder a
todas las funciones necesarias para ejecutar los pasos en la navegación de la interfaz de usuario.

ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
Figura 20. Ejemplo de mapa de diálogo
5.4.5. Tablas de decisión y árboles de decisión ANEXOS
Un sistema de software a menudo se rige por lógica compleja, con varias combinaciones de condiciones
que conducen a diferentes comportamientos del sistema. Por ejemplo, si el conductor presiona el botón
de aceleración en el sistema de control de crucero de un automóvil y el coche está actualmente de
crucero, el sistema aumenta la velocidad del coche, pero si el coche no cruza, la entrada se ignora. Los
desarrolladores necesitan requisitos funcionales que describen lo que el sistema debe hacer bajo todas
las posibles combinaciones de condiciones. Sin embargo, es fácil pasar por alto una condición, lo que
resulta en un requisito que falta. Estas brechas son difíciles de detectar revisando una especificación
textual.
Las tablas de decisión y los árboles de decisión son dos técnicas alternativas para representar lo que el
sistema debe hacer cuando se aplican una lógica y decisiones complejas. Una tabla de decisión enumera
los diferentes valores para todos los factores que influyen en el comportamiento e indica la acción
esperada del sistema en respuesta a cada combinación de factores. Los factores se pueden mostrar como

afirmaciones con posibles condiciones de verdadero y falso, como preguntas con posibles respuestas de
sí y no, o como preguntas con más de dos valores posibles.
ÍNDICE
5.4.6. Tablas evento-respuesta
Los casos de uso e historias de usuarios no siempre son útiles o suficientes para descubrir la funcionalidad
que los desarrolladores deben implementar. Esto es particularmente cierto para sistemas en tiempo real.
PRELIMINARES
Considere una intersección de carreteras complejas con numerosos semáforos y señales para peatones.
No hay muchos casos de uso para un sistema como este. Un conductor puede querer pasar a través
de la luz o girar a la izquierda o a la derecha. Un peatón quiere cruzar la carretera. Tal vez un vehículo
de emergencia quiere ser capaz de activar las señales de tráfico verde en su dirección para que pueda
acelerar su camino a las personas que necesitan ayuda. Las fuerzas de seguridad podrían tener cámaras
en la intersección para fotografiar las matrículas de los violadores de luz roja. Esta información por sí sola
no es suficiente para que los desarrolladores construyan la funcionalidad correcta.
BIMESTRE
PRIMER
Otra forma de abordar los requisitos de los usuarios es identificar los eventos externos a los que el sistema
debe responder. Un evento es algún cambio o actividad que tiene lugar en el entorno del usuario que
estimula una respuesta del sistema de software. Una tabla de eventos de respuesta (también llamada
tabla de eventos o lista de eventos) detalla todos estos eventos y el comportamiento que se espera que
SEGUNDO
BIMESTRE
el sistema presente en reacción a cada evento. Hay tres clases de eventos del sistema, como se muestra
en la Figura 21:
• Evento de negocios
Un evento de negocio es una acción de un usuario humano que estimula un diálogo con el software,
SOLUCIONARIO
como cuando el usuario inicia un caso de uso. Las secuencias de respuesta a eventos corresponden a las
etapas de un caso de uso o mapa de proceso.
• Evento de señal
Un evento de señal se registra cuando el sistema recibe una señal de control, lectura de datos o
BIBLIOGRÁFICAS
REFERENCIAS
interrupción desde un dispositivo de hardware externo u otro sistema de software, como cuando se
cierra un interruptor, un voltaje cambia, otra solicita un servicio o un usuario pasa su En la pantalla de
una tableta.
• Evento temporal
Un evento temporal se desencadena en el tiempo, como cuando el reloj de la computadora alcanza

un tiempo especificado (por ejemplo, para iniciar una operación de exportación automática de datos a ANEXOS
medianoche) o cuando una duración predeterminada ha pasado desde un evento anterior (como en un
sistema que registra la Temperatura leída por un sensor cada 10 segundos).

Actor
Sensor
ÍNDICE
Iniciar
Evento de negocio transacción
Evento de señal
Continuar Lectura de
transacción datos
PRELIMINARES
Sistema Dispositivo
Señales de
Tiempo control
predeterminado
Datos
generados
BIMESTRE
PRIMER
Base de datos
Evento temporal externa
Figura 21. El sistema responde a eventos de negocio, de señales y temporales

Fuente: Wiegers y Beatty (2013
SEGUNDO
BIMESTRE
El análisis de eventos funciona especialmente bien para especificar sistemas de control en tiempo real. Para
identificar eventos, considere todos los estados asociados con el objeto que está analizando e identifique
cualquier evento que pueda hacer que el objeto se transforme en esos estados. Revise los diagramas de
contexto para cualquier entidad externa que pueda iniciar una acción (activar un evento) o requerir
SOLUCIONARIO
una respuesta automática (necesita un evento temporal activado). La tabla 11 contiene una muestra de
tabla de eventos-respuesta que describe parcialmente el comportamiento de los limpiaparabrisas de un
automóvil. Aparte del evento 6, que es un evento temporal, estos son todos los eventos de señal. Tenga
en cuenta que la respuesta esperada depende no sólo del evento, sino también del estado del sistema
en el momento en que se produce el evento. Por ejemplo, los eventos 4 y 5 en la Tabla 6 dan como
resultado comportamientos ligeramente diferentes dependiendo de si los limpiaparabrisas estaban
BIBLIOGRÁFICAS
REFERENCIAS
encendidos en el momento en que el usuario ajustó el control del limpiaparabrisas al ajuste intermitente.
Una respuesta podría simplemente alterar alguna información interna del sistema o podría resultar en
un resultado visible externamente. La otra información que desee agregar a una tabla de respuesta a
eventos incluye:
• La frecuencia del evento (cuántas veces el evento tiene lugar en un período de tiempo determinado,
o un límite a cuántas veces puede ocurrir).
• Elementos de datos necesarios para procesar el evento. ANEXOS
• El estado del sistema después de la ejecución de las respuestas al evento.
Tabla 11.
Tabla parcial de eventos-respuesta para un sistema de limpiaparabrisas de automóviles
ID Evento Estado del sistema Respuesta del sistema

Ajuste el control del Limpiador apagado, en alta Ajuste el motor del limpiaparabrisas a
1
limpiaparabrisas a baja velocidad velocidad, o en intermitente baja velocidad
Ajuste el control del Limpiador apagado, en baja Ajuste el motor del limpiaparabrisas a
2
limpiaparabrisas a alta velocidad velocidad, o en intermitente alta velocidad
Limpiado en alta velocidad, 1. Ciclo completo de limpieza actual
Ajuste el control del
3 en baja velocidad, o en 1. Desactiva el motor del
limpiaparabrisas a apagado
intermitente limpiaparabrisas

ID Evento Estado del sistema Respuesta del sistema

1. Realice un ciclo de limpieza
ÍNDICE
2. Lea el ajuste intermitente del tiempo
Ajuste el control del
4 Limpiador apagado de limpieza
limpiaparabrisas a intermitentes
3. Inicializar el temporizador del
limpiaparabrisas
1. Completar el ciclo actual de limpieza
PRELIMINARES
Ajuste el control del Limpiador a baja velocidad o
5 4. Leer el ajuste del intervalo de limpieza
limpiaparabrisas a intermitentes alta velocidad
5. Inicializar el temporizador de limpieza
El intervalo de tiempo de
1. Ejecuta un ciclo de limpieza a baja
6 limpieza que ha pasado desde Limpiador intermitente
velocidad
que se completó el último ciclo
Cambiar el intervalo intermitente 1. Leer el ajuste del intervalo de limpieza
7 Limpiador intermitente
del limpiaparabrisas 6. Inicializar el temporizador de limpieza
BIMESTRE
PRIMER
Cambiar el intervalo intermitente Limpiador apagado, a baja
8 No responde
del limpiaparabrisas velocidad o alta velocidad
9 La señal de limpieza recibida Limpiador apagado Ejecutar un ciclo a baja velocidad
SEGUNDO
BIMESTRE
Listar los eventos que cruzan el límite del sistema es una técnica de alcance útil. Una tabla de eventos-
respuesta que defina todas las combinaciones posibles de evento, estado y respuesta, incluyendo las
condiciones de excepción, puede servir como parte de los requisitos funcionales de la porción del
sistema. Puede modelar la tabla de respuesta a eventos en una tabla de decisiones para asegurarse de
que se analizan todas las combinaciones posibles de eventos y estados del sistema. Sin embargo, el
SOLUCIONARIO
analista de negocio debe suministrar requisitos adicionales funcionales y no funcionales. ¿Cuántos ciclos
por minuto realiza el limpiaparabrisas en los ajustes de limpieza lenta y rápida? ¿El ajuste intermitente
es continuamente variable, o tiene ajustes discretos? ¿Cuáles son los tiempos de retardo mínimo y
máximo entre las toallitas intermitentes? Si omite este tipo de información, el desarrollador tiene que
rastrearla o tomar las decisiones por sí mismo. Recuerde, el objetivo es especificar los requisitos con la
BIBLIOGRÁFICAS
suficiente precisión para que un desarrollador sepa qué construir y un probador pueda determinar si se
REFERENCIAS
ha construido correctamente.
Observe que los eventos enumerados en la Tabla 5.3 describen la esencia del evento, no los detalles de
la implementación. La Tabla no muestra nada sobre cómo se ven los controles del limpiaparabrisas o
cómo el usuario los manipula. El diseñador podría satisfacer estos requisitos con cualquier cosa, desde
los controles de la escobilla montados tradicionales hasta el reconocimiento de comandos hablados:
“limpiaparabrisas”, “limpiaparabrisas más rápido”, “limpiar una vez”. Los escritores de requisitos en este ANEXOS
nivel evitan imponer restricciones de diseño innecesarias. Sin embargo, registre cualquier restricción de
diseño conocida para guiar el pensamiento del diseñador.
5.5. Los diagramas UML
Muchos proyectos utilizan análisis, diseño y métodos de desarrollo orientado a objetos. Los objetos
normalmente corresponden a los elementos del mundo real en el negocio o en el dominio del problema.
Representan instancias individuales derivadas de una plantilla genérica llamada clase. Las descripciones
de las clases abarcan tanto los atributos (datos) como las operaciones que se pueden realizar en los
atributos. Un diagrama de clases es una forma gráfica de representar las clases identificadas durante el
análisis orientado a objetos y las relaciones entre ellas.

Los productos desarrollados utilizando métodos orientados a objetos no exigen enfoques de desarrollo
de requisitos únicos. Esto se debe a que el desarrollo de requisitos se centra en lo que los usuarios deben
ÍNDICE
hacer con el sistema y la funcionalidad que debe contener, no con la forma en que se construirá. Los
usuarios no se preocupan por los objetos o clases. Sin embargo, si sabe que va a construir el sistema
utilizando técnicas orientadas a objetos, puede ser útil comenzar a identificar clases y sus atributos y
comportamientos durante el análisis de requisitos. Esto facilita la transición del análisis al diseño, ya que
el diseñador asigna los objetos del dominio del problema a los objetos del sistema y detalla los atributos
PRELIMINARES
y las operaciones de cada clase.
El lenguaje de modelado orientado a objetos estándar es el Lenguaje de Modelado Unificado. El UML

se utiliza principalmente para crear modelos de diseño. A nivel de abstracción que es apropiado para el
análisis de requisitos, varios modelos UML pueden ser útiles: (Booch, Rumbaugh y Jacobson, 1999)
• Diagramas de clases, para mostrar las clases de objetos que pertenecen al dominio de la aplicación;
BIMESTRE
PRIMER
sus atributos, comportamiento y propiedades; y relaciones entre clases. Los diagramas de clases
también se pueden usar para el modelado de datos.
• Diagramas de casos de uso, para mostrar las relaciones entre actores externos al sistema y los
casos de uso con los que interactúan.
SEGUNDO
BIMESTRE
• Diagramas de actividad, para mostrar cómo se entrelazan los diversos flujos en un caso de uso, o
qué roles realizan ciertas acciones (como en un mapa de proceso), o para modelar el flujo de los
procesos de negocio.
• Diagramas de estado (o máquina de estado), para representar los diferentes estados de un sistema
SOLUCIONARIO
u objeto de datos que puede tomar y las transiciones permitidas entre los estados.
5.6. Entendiendo los requisitos de usuario
BIBLIOGRÁFICAS
Un requisito previo necesario para diseñar software que satisfaga las necesidades de los usuarios es
REFERENCIAS
entender lo que los usuarios pretenden hacer con él. Algunos equipos adoptan un enfoque centrado
en el producto. Se centran en la definición de las características para implementar en el software, con
la esperanza de que esas características serán de interés para los posibles clientes. En la mayoría de
los casos, sin embargo, es mejor tomar un enfoque centrado en el usuario y centrado en el uso para
la obtención de los requisitos. Centrarse en los usuarios y su uso anticipadamente ayuda a revelar la
funcionalidad necesaria, evita la implementación de características que nadie va a utilizar, y ayuda con
la priorización. ANEXOS
Los requisitos del usuario se encuentran en el segundo nivel de requisitos que usted vio en la figura 1
en el capítulo 1. Están entre los requisitos de negocio que establecen los objetivos para el proyecto y los
requisitos funcionales que describen lo que los desarrolladores deben implementar. Dos de las técnicas
más utilizadas para explorar los requisitos de los usuarios son los casos de uso e historias de usuarios.
Los analistas han empleado durante mucho tiempo los escenarios de uso para obtener los requisitos de
los usuarios. La perspectiva centrada en el uso se formalizó en el enfoque del caso de uso para modelar
los requisitos. Más recientemente, los defensores del desarrollo ágil introdujeron el concepto de “historia
del usuario”, una declaración concisa que articula una necesidad del usuario y sirve como punto de
partida para que las conversaciones realicen los detalles.
La intención de los casos de uso y las historias de usuario es describir las tareas que los usuarios necesitarán
realizar con el sistema o las interacciones entre el usuario y el sistema, lo que resultará en un resultado

valioso para algunos interesados. Esa comprensión lleva al analista de negocio a derivar la funcionalidad
necesaria que debe implementarse para permitir esos escenarios de uso. También conduce las pruebas
ÍNDICE
para verificar si la funcionalidad se implementó correctamente. Las estrategias de obtención centradas
en el uso le acercarán a la comprensión de los requisitos del usuario en muchas clases de proyectos que
cualquier otra técnica que hemos mencionado.
Los casos de uso y las historias de usuarios funcionan bien para explorar los requisitos de aplicaciones
PRELIMINARES
empresariales, sitios web, quioscos y sistemas que permiten al usuario controlar una pieza de hardware.
Sin embargo, son inadecuados para comprender los requisitos de ciertos tipos de aplicaciones.
Aplicaciones tales como procesos por lotes, sistemas de computación intensiva, análisis de negocios
y almacenamiento de datos podrían tener sólo unos cuantos casos de uso. La complejidad de estas
aplicaciones radica en los cálculos realizados, los datos encontrados y compilados, o los informes
generados, no en las interacciones usuario-sistema.
BIMESTRE
PRIMER
Tampoco son casos de uso e historias de usuarios suficientes para especificar muchos sistemas embebidos
y otros sistemas en tiempo real. Considere un lavado de autos automatizado. El conductor del coche sólo
tiene un objetivo: lavar el coche, quizá con algunas opciones: aerosol de la carrocería, cera selladora, pulir.
Sin embargo, el lavado de autos tiene mucho que hacer. Tiene un mecanismo de accionamiento para
mover su coche; Numerosos motores, bombas, válvulas, interruptores, diales y luces; Y temporizadores o
SEGUNDO
BIMESTRE
sensores para controlar la activación de estos componentes físicos.
También tiene que preocuparse por la funcionalidad de diagnóstico, como notificar al operador cuando
un tanque de líquido está casi vacío, así como la detección de fallas y los requisitos de seguridad. ¿Qué
sucede si el mecanismo de accionamiento falla mientras un auto está en el túnel o si el motor de un
SOLUCIONARIO
soplador falla? Una técnica de requisitos a menudo usada para sistemas en tiempo real es listar los
eventos externos a los cuales el sistema debe reaccionar y las respuestas correspondientes del sistema.
Un caso de uso describe una secuencia de interacciones entre un sistema y un actor externo que resulta
en que el actor sea capaz de lograr algún resultado de valor. Los nombres de casos de uso se escriben
siempre en forma de un verbo seguido de un objeto. Seleccione nombres fuertes y descriptivos para que
BIBLIOGRÁFICAS
REFERENCIAS
sea evidente a partir del nombre que el caso de uso entregará algo valioso para algún usuario.
Como se utiliza en los proyectos de desarrollo ágil, una historia de usuario es una “descripción breve y
sencilla de una característica contada desde la perspectiva de la persona que desea la nueva capacidad,
usualmente un usuario o cliente del sistema”.
En este nivel, los casos de uso se parecen mucho a las historias de usuarios. Ambos se centran en la
comprensión de lo que los diferentes tipos de usuarios necesitan para lograr a través de las interacciones ANEXOS
con un sistema de software. Sin embargo, los dos procesos se mueven en diferentes direcciones de estos
puntos de partida similares, como se ilustra en la figura 22. Ambos enfoques también pueden producir
otros resultados, como los modelos de análisis visual.

ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
Figura 22. Requisitos desde el enfoque de casos de uso e historias de usuario
5.7. Caso de uso
SEGUNDO
BIMESTRE
Como se mencionó anteriormente, un caso de uso describe una secuencia de interacciones entre un
sistema y un actor externo que resulta en algún resultado que proporciona valor al actor. Un actor es una
persona o a veces otro sistema de software o un dispositivo de hardware que interactúa con el sistema
para realizar un caso de uso.
SOLUCIONARIO
Un caso de uso, puede expresar que es uno de los usos que se quiere dar al sistema, lo cual también
se puede saber respondiendo a la pregunta ¿Para qué usaríamos el sistema?, para efectos del ejemplo,
piense en un sistema que todos conocemos, como un teléfono celular inteligente (Smartphone), y
hagamos la pregunta ya mencionada ¿Para qué usaría un teléfono inteligente?, piénselo un momento y
haga su propia lista de posibles respuestas.
BIBLIOGRÁFICAS
REFERENCIAS
Ahora bien, la lista podría ser extensa sobre todo por las posibilidades de aplicaciones que se pueden
incluir, sin embargo, hagamos una lista básica de cosas que se podrá hacer con este sistema.
1. Recibir llamadas
2. Realizar llamadas
3. Leer mensajes de texto.
4. Escribir mensajes de texto. ANEXOS
5. Capturar fotografías.
6. Capturar video.
7. Enviar mensajes de correo electrónico.
8. Recibir mensajes de correo electrónico.
9. Navegar en internet.
10. Reproducir música.
11. Reproducir video.
12. Manejar agenda de actividades diarias con alarmas.

Si lo analiza un poco y aunque la lista podría estar incompleta, piense por un momento en cada ítem de
esta lista, todos representan algo que el usuario puede hacer con el teléfono celular. Cada uno de estos
ÍNDICE
ítems es lo que conocemos como casos de uso.
Note que esta lista no incluye aspectos demasiado generales que no nos dejen claro lo que hace o
debería hacer el sistema, por ejemplo “gestionar llamadas telefónicas” o “administrar mensajes de correo
electrónico”, tampoco acciones específicas que el usuario debe hacer para obtener el resultado, como
PRELIMINARES
por ejemplo presionar la tecla llamar (Send), de hecho el presionar la tecla es un paso del caso de uso
“Realizar llamadas”, por tanto las acciones o interacciones con el caso de uso según la definición deben
dar valor al trabajo del usuario, y desde esta óptica sólo pueden ser casos de uso las tareas que se puede
hacer con el sistema.
Los nombres de los casos de uso deben ser expresiones verbales que describen algún comportamiento
del vocabulario del sistema que se está modelando, es muy común al menos al inicio colocar nombres
BIMESTRE
PRIMER
que describen las actividades necesarias para completar el funcionamiento de un caso de uso, o por el
contrario definir nombres muy amplios que reflejan módulos completos de una aplicación y reflejan
ninguna acción específica del sistema.
Ejemplos de nombres de casos uso pueden ser: registrar matrícula, crear ficha de estudiante, anular
SEGUNDO
BIMESTRE
matrícula, solicitar matrícula; como nombres incorrectos por ser actividades tendríamos: Ingresar
datos personales, validar contraseña, ingresar fecha de nacimiento, fijar monto a depositar, seleccionar
contacto; y finalmente ejemplos de nombres incorrectos demasiado generales: Gestión académica,
cobranzas, realizar inventario.
SOLUCIONARIO
La notación que usa UML para representar los casos de uso es una figura de óvalo. En la figura 23 se
muestra algunos de los casos de uso identificados para el teléfono celular. Tenga en cuenta los nombres
que se han colocado para cada uno de los casos de uso.
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS
Figura 23. Representación gráfica de los casos de uso que implementa un teléfono celular
Ahora bien, los casos de uso, siempre van asociados a un actor que podríamos decir que es un usuario,
un dispositivo u otro sistema que está en condiciones de interactuar con la funcionalidad que representa
el caso de uso.

Si analizamos la definición siguiente “un actor representa un conjunto coherente de roles los usuarios de
los casos de uso representan al interactuar con estos. Normalmente, un actor representa un rol que es
ÍNDICE
desempeñado por un humano, un dispositivo de hardware o cualquier otro sistema al interactuar con
nuestro sistema”2, podemos llegar a las siguientes conclusiones:
• Un actor no es necesariamente una persona, es un rol o un conjunto de roles, por lo tanto, no hace
referencia a un individuo en particular, sino a varios individuos representados en el mismo rol.
PRELIMINARES
• Una misma persona puede jugar varios roles, pero el actor en cada caso es diferente.
• La relación que une al actor con el caso de uso se denomina interacción, y este siempre es de dos
vías, es decir está en condiciones de enviar o recibir mensajes desde y hacia los casos de uso.
• Un actor es un elemento externo al sistema, es decir nunca forma parte del mismo.
Un actor se representa con un monigote, y por tratarse de un rol, se lo describe en singular. La figura 24
BIMESTRE
PRIMER
representa la relación entre un actor y varios casos de uso.
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
Figura 24. Representación gráfica de los casos de uso con un actor
El modelado de casos de uso es una técnica que no se limita a un proceso de desarrollo o a una tecnología
específica, por el contrario, pueden usarse para cualquier paradigma de desarrollo de software, esto por
la sencilla razón de que los casos de uno especifican el qué, no el cómo. ANEXOS
Hasta ahora hemos identificado tres componentes del modelo: los actores, los casos de uso y las
asociaciones, veamos un ejemplo que nos permita comprender el significado de cada uno de estos
elementos, notará que más allá de la definición, lo que importa es la interpretación que se le debe dar a
cada uno de ellos.
El comportamiento de un caso de uso se especifica describiendo flujos de eventos en forma textual,

el cual debe ser expresado en un lenguaje que favorezca la comprensión de todos los involucrados en
el sistema incluyendo cliente, usuarios analistas, programadores, etc. En esta descripción se especifica
cómo inicia y cuando acaba el caso de uso, además de describir la interacción entre los diferentes
elementos del sistema para producir el resultado deseado.
2 Booch et Al (2006). Ob. cit. p. 247

En la figura 25, podemos apreciar algunas de las funcionalidades de un iPod3 video.
ÍNDICE
Reproducir
música
PRELIMINARES
Jugar
Audífono
Usuario
Reproducir
video
BIMESTRE
PRIMER
Crear lista de
reproducción
iTunes
Sincronizar
SEGUNDO
BIMESTRE
información
Figura 25. Modelo de casos de uso para un reproductor de audio y video
SOLUCIONARIO
Un caso de uso además incluye todas las situaciones que pueden darse al momento de ejecutarlo, a
cada una de estas situaciones se la conoce como una instancia del caso de uso y entre estas instancias
podemos distinguir el flujo básico de eventos al cual también podemos decir que es el flujo normal
y las demás instancias se pueden definir como flujos alternos o excepcionales. A la combinación de
flujo normal con uno o más flujos alternos se conoce como escenario, y los escenarios representan por
tanto todo lo que puede darse en el caso de uso y en la gran mayoría de las veces es preciso definir los
BIBLIOGRÁFICAS
REFERENCIAS
escenarios exitosos y los escenarios fallidos.
La especificación de los flujos de eventos y escenarios se verá con detalle más adelante. Mientras tanto
avancemos estudiando algunos otros elementos del modelado de casos de uso.
Actores
Conforme se ha indicado anteriormente, un actor es un rol que representa un usuario, un dispositivo u ANEXOS
otro sistema que se comunica con nuestro sistema. Este rol puede ser desempeñado por varias personas,
y a su vez una persona puede ejecutar varios roles. Gráficamente se representa con un monigote como
se aprecia en las figuras anteriores. Ejemplo, en un centro universitario, el coordinador del centro puede
ingresar al sistema con el rol de coordinador y hacer las cosas que le competen en ese rol, y a la vez como
estudiante puede ingresar al sistema con ese rol, quedando claro de que no puede usar sus dos roles a
la vez, ver figura 26.
3 Reproductor de audio y video fabricado por Apple

ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
Figura 26. Un usuario desempeñando varios roles
Elaboración: Autor
Cuando hablamos de comunicación, decimos que es el paso de mensajes entre el actor y el caso de uso.
Un actor siempre es externo al sistema, es decir no forma parte del mismo, es preciso tenerlo en cuenta
al momento de definirlos.
SOLUCIONARIO
La única relación posible entre casos de uso y actores es la asociación, en la figura 27 se aprecia las
relaciones entre actor y caso de uso. La asociación es una relación bidireccional por lo tanto el actor y el
caso de uso pueden enviar o recibir información.
Las puntas de flecha determinan el origen de la comunicación, normalmente es un detalle que se suele
BIBLIOGRÁFICAS
REFERENCIAS
pasar por alto, pero puede ser valioso al momento de modelar las demás partes del sistema.
Relaciones entre actores
Los actores no se relacionan directamente, por el hecho de ser externos, no se representan relaciones
entre ellos, sino únicamente la relación de estos con los casos de uso. Sin embargo pueden existir
categorías generales de actores así como también categorías especializadas, las cuales se representan
a través de una relación de generalización, que en principio tiene las mismas características que en los ANEXOS
modelos de clases y se representa con una flecha que va desde el actor especializado hacia el actor
general, como se aprecia en la figura 27, Donde se ve que un actor docente puede especializar como
investigador, y esto en el sistema significa que el docente investigador puede trabajar con las casos de
uso de docente, mas los específicos de investigador.

ÍNDICE
PRELIMINARES
Figura 27. Relación de generalización entre actores
A continuación, pongo a disposición el diagrama de casos de uso para el caso de Registro de trámites
BIMESTRE
PRIMER
en la UTPL.
Registro de trámite
SEGUNDO
BIMESTRE
Digitalizar
documentos
SOLUCIONARIO
Estudiante
Buscar trámite
Consultar
BIBLIOGRÁFICAS
expediente Secretaria
REFERENCIAS
Gestionar
asignación de
Profesor trámite
ANEXOS
Figura 28. Casos de uso para “Registro de trámite”
Un caso de uso describe una actividad discreta e independiente que un actor puede realizar para lograr
algún resultado de valor. Un caso de uso puede abarcar una serie de actividades relacionadas que tienen
un objetivo común. Un escenario es una descripción de una sola instancia de uso del sistema. Un caso
de uso es, por lo tanto, una colección de escenarios de uso relacionados, y un escenario es una instancia
específica de un caso de uso. Al explorar requisitos de usuario, puede comenzar con una instrucción
de caso de uso general y desarrollar escenarios de uso más específicos, o puede generalizar desde un
ejemplo de escenario específico al caso de uso más amplio.

La Figura 29. muestra una plantilla para detallar los casos de uso. Al igual que con todas las plantillas, no
completa esto de arriba a abajo, y no necesariamente necesita toda la información de la plantilla para
ÍNDICE
cada caso de uso. La plantilla es simplemente una estructura en la cual almacenar la información que
encuentre durante una discusión de caso de uso de una manera organizada y consistente. La plantilla le
recuerda toda la información que debe contemplar con respecto a cada caso de uso. Si la información
que pertenece a la plantilla ya existe en otro lugar, simplemente apunte a que incluya esa información
por referencia. Por ejemplo, no incorporar el texto real de cada regla de negocio que afecta el caso de
PRELIMINARES
uso en la plantilla; Simplemente liste los identificadores de las reglas de negocio relevantes para que el
lector pueda encontrar esa información cuando sea necesario.
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS
Figura 29. Plantilla para detallar cada caso de uso
Los elementos esenciales de un caso de uso son los siguientes:
• Un identificador único y un nombre sucinto que indica el objetivo del usuario

• Una breve descripción textual que describe el propósito del caso de uso
• Una condición de disparo que inicia la ejecución del caso de uso
• Cero o más condiciones previas que deben satisfacerse antes de que el caso de uso pueda
comenzar

• Una o más post-condiciones que describen el estado del sistema después de que el caso de uso
se ha completado con éxito
ÍNDICE
• Una lista numerada de pasos que muestra la secuencia de interacciones entre el actor y el sistema
-un diálogo- que conduce desde las precondiciones a las postcondiciones.
5.8. Reglas de negocio
PRELIMINARES
Cada organización opera de acuerdo con un amplio conjunto de políticas, leyes y estándares de la
industria. Industrias como la banca, la aviación y la fabricación de dispositivos médicos deben cumplir con
volúmenes de las regulaciones gubernamentales. Tales principios de control se conocen colectivamente
como reglas de negocio o lógica de negocio. En la figura 30 se muestra mediante un gráfico cómo
mediante los objetivos del negocio, se obtienen las reglas de negocio a través de las políticas de negocio.
BIMESTRE
PRIMER
Las reglas de negocio a menudo se aplican mediante la implementación manual de políticas y
procedimientos. En muchos casos, sin embargo, las aplicaciones de software también necesitan hacer
cumplir estas reglas.
Antes de continuar con las reglas de negocio, es necesario analizar las políticas de negocio. Las políticas
SEGUNDO
BIMESTRE
de negocio son las directrices, normas y reglamentos que rigen o condicionan la conducta de un
negocio. Las políticas son la base para la toma de decisiones y el conocimiento que se implementan en
el software y en los procesos manuales. Ya sea impuesta por una agencia externa o desde dentro de la
empresa, las políticas de negocio se usan para agilizar las operaciones, aumentar la satisfacción y lealtad
del cliente, reducir el riesgo, mejorar los ingresos, y cumplir con los requisitos legales (y por lo tanto
SOLUCIONARIO
mantenerse en el negocio).
Las políticas asignadas al software deben estar explícitamente definidas como reglas de negocio
y deben estar incluidas al final de la especificación de requisitos de software. Las reglas de negocio
evolucionan a partir de políticas de alto nivel que a su vez proceden de los objetivos de negocio. Las
políticas se originan ya sea desde el interior de una organización o de una entidad externa, como una
BIBLIOGRÁFICAS
REFERENCIAS
agencia gubernamental.
Como se indicó la mayoría de las reglas de negocio se originan fuera del contexto de cualquier aplicación
de software específica. La política corporativa que requiere entrenamiento anual en el manejo de
productos químicos peligrosos se aplica incluso si todas las compras y dispensación de productos
químicos se hacen manualmente. Las prácticas contables estándar estaban en uso mucho antes de que
se inventara la computadora digital.
ANEXOS
Debido a que las reglas de negocio son una propiedad de la empresa, no son requisitos de software en sí
mismos. Sin embargo, las reglas de negocio son una fuente rica de requisitos porque dictan propiedades
que el sistema debe poseer para ajustarse a las reglas.

ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
Figura 30. Clasificación de las reglas, políticas y objetivos del negocio
SEGUNDO
BIMESTRE
Como se dijo en el capítulo 1, las reglas de negocio pueden ser el origen de varios tipos de requisitos.
La tabla 12 ilustra y proporciona ejemplos de cómo las reglas de negocio influyen en varios tipos de
requisitos.
SOLUCIONARIO
Tabla 12.
Influencia de las reglas de negocio en varios tipos de requisitos de software
Tipo de
Influencia de las reglas de negocio Ejemplo
requisito
El Sistema de Seguimiento de Productos Químicos debe
BIBLIOGRÁFICAS
Las regulaciones gubernamentales
REFERENCIAS
Requisitos permitir el cumplimiento de todas las regulaciones
pueden conducir a los objetivos de
de negocio federales y estatales sobre el uso de químicos y la
negocio necesarios para un proyecto.
eliminación de residuos en un plazo de cinco meses.
Las políticas de privacidad determinan Sólo los gerentes de laboratorio están autorizados a
Requisitos
qué usuarios pueden y no pueden generar informes de exposición química para cualquier
de usuario
realizar ciertas tareas con el sistema. persona que no sean ellos mismos.
La política de la compañía es que Si se recibe una factura de un proveedor no registrado, el
Requisito todos los proveedores deben estar Sistema de proveedores enviará por correo electrónico las ANEXOS
funcional registrados y aprobados antes de que versiones editables en PDF del proveedor del formulario
se pague una factura. de admisión del proveedor y del formulario W-9.
Las regulaciones de agencias
El sistema debe mantener registros de entrenamiento
gubernamentales, como OSHA y EPA,
Atributos de seguridad, que debe verificar para asegurar que los
pueden dictar requisitos de seguridad,
de calidad usuarios estén debidamente capacitados antes de que
los cuales deben ser implementados a
puedan solicitar un producto químico peligroso.
través de la funcionalidad del sistema.
A veces, las personas confunden las reglas de negocio con los procesos de negocio o los requisitos de
negocio. Como se dijo en secciones anteriores, un requisito de negocio establece un resultado deseable
o un objetivo de alto nivel de la organización que construye o adquiere una solución de software. Los
requisitos de negocio sirven como justificación para emprender un proyecto. Un proceso de negocio
describe una serie de actividades que transforman los insumos en resultados para lograr un resultado
específico.

Los sistemas de información a menudo automatizan los procesos de negocio, lo que podría dar lugar
a eficiencias y otros beneficios que cumplen con los requisitos de negocio establecidos. Las reglas de
ÍNDICE
negocio influyen en los procesos de negocio estableciendo vocabulario, imponiendo restricciones,
desencadenando acciones y gobernando cómo se llevan a cabo los cálculos. La misma regla de negocio
podría aplicarse a varios procesos manuales o automatizados, lo cual es una de las razones por las que es
mejor tratar las reglas de negocio como un conjunto separado de información.
PRELIMINARES
Importante.
Estimado estudiante, tenga presente que tener reglas de negocios indocumentadas
y que son conocidas sólo por ciertos expertos resulta en un vacío de conocimiento
cuando esos expertos abandonan la organización.
El Grupo de Reglas de Negocio4 (GRN) proporciona definiciones para las reglas de negocio desde las
BIMESTRE
PRIMER
perspectivas tanto del negocio como de sus sistemas de información:
• Desde la perspectiva del negocio: “Una regla de negocios es la guía de que hay una obligación en
cuanto a conducta, acción, práctica o procedimiento dentro de una actividad o esfera particular”.
(Debe haber una motivación explícita para la regla, así como los métodos de aplicación Y una
comprensión de cuáles serían las consecuencias si la regla se rompiera.)
SEGUNDO
BIMESTRE
• Desde la perspectiva del sistema de información: “Una regla de negocios es una declaración que
define o restringe algún aspecto del negocio. Se pretende afirmar la estructura del negocio o
controlar o influir en el comportamiento del negocio “.
SOLUCIONARIO
Se han desarrollado metodologías completas basadas en el descubrimiento y la documentación de
reglas de negocio y su implementación en sistemas automatizados de reglas de negocio. A menos que
esté construyendo un sistema que está fuertemente orientado por reglas, no necesitas una metodología
elaborada. Simplemente identifica y documente las reglas que pertenecen al sistema y vincularlas con
los requisitos específicos que las implementan.
BIBLIOGRÁFICAS
REFERENCIAS
Restricciones
Hechos
Acciones
ANEXOS
habilitadoras
Calculos Inferencias
Figura 31. Una taxonomía de reglas de negocio

4 Business Rules Group http://www.businessrulesgroup.org

Se han propuesto numerosos esquemas de clasificación para organizar las reglas de negocio. La
taxonomía simple que se muestra en la figura 31, con cinco tipos de reglas que funcionará para la mayoría
ÍNDICE
de las situaciones. Adicional se puede considerar una sexta categoría que considera términos, palabras
definidas, frases y abreviaturas que son importantes para el negocio. Se podría agrupar términos con
reglas empresariales fácticas. Un glosario es otro lugar conveniente para definir los términos.
Registrar las reglas de negocio de una manera consistente es más importante que tener acaloradas
PRELIMINARES
discusiones sobre cómo clasificar cada una de ellas. Sin embargo, una taxonomía es útil para identificar
las reglas de negocio que usted no pudo haber pensado de otra manera. La clasificación de las reglas
también le da una idea de cómo puede aplicarlas en una aplicación de software. Por ejemplo, las
restricciones a menudo llevan a la funcionalidad del sistema que impone las restricciones, y los activadores
de la acción conducen a la funcionalidad para hacer que algo suceda bajo ciertas condiciones. Veamos
algunos ejemplos de estos cinco tipos de reglas de negocio. (Wiegers y Beatty, 2013)
BIMESTRE
PRIMER
Hechos
Los hechos son afirmaciones verdaderas acerca del negocio. Los hechos describen asociaciones o
relaciones entre los términos del negocio. Cabe indicar que los hechos no se traducen en requisitos
funcionales. Los hechos son verdades inmutables por cuanto definen los datos y sus atributos. A
SEGUNDO
BIMESTRE
continuación, tenemos algunos ejemplos:
• Cada contenedor de productos químicos tiene un código de barras de identificador único.

• Cada orden debe tener un cargo de envío.
• Cada elemento de línea en un pedido representa una combinación específica de químicos, grado,
SOLUCIONARIO
tamaño del envase, y el número de contenedores.
• De que los boletos no reembolsables sin pagar tasa alguna cuando el comprador cambia el
itinerario.
• Los impuestos no se calculan sobre los gastos de envío.
BIBLIOGRÁFICAS
Restricciones
REFERENCIAS
Una restricción es una sentencia que restringe las acciones que el sistema o sus usuarios pueden realizar.
Alguien que describe una regla de negocio restrictiva podría decir que ciertas acciones deben o no
deben o no ser realizadas, o que sólo ciertas personas o roles pueden realizar acciones particulares. A
continuación, se presentan algunos ejemplos de restricciones de diversos orígenes.
ANEXOS
• Política organizacional
üü Un solicitante de préstamo que es menor de 18 años de edad debe tener un padre o un

tutor legal como cosignatario en el préstamo.
üü Un patrón de la biblioteca puede tener un máximo de 10 artículos en espera en cualquier

momento.
üü La correspondencia de seguro no puede mostrar más de cuatro dígitos del número de

Seguro Social del asegurado.
• Regulaciones gubernamentales
üü Todas las aplicaciones de software deben cumplir con las regulaciones gubernamentales
para su uso por personas con impedimentos visuales.

üü Los pilotos de aerolíneas deben recibir por lo menos 8 horas continuas de descanso en cada
período de 24 horas.
ÍNDICE
üü Las declaraciones de impuestos federales individuales deben ser mataselladas antes de la
medianoche del primer día hábil después del 14 de abril a menos que se haya otorgado una
extensión.
PRELIMINARES
• Estándares de la industria
üü Los solicitantes de préstamos hipotecarios deben satisfacer las normas de calificación de la

Autoridad Federal de Vivienda.
üü Las aplicaciones Web no pueden contener ninguna etiqueta HTML ni ningún atributo que
se deprecie de acuerdo con el estándar HTML 5.
BIMESTRE
PRIMER
Acción facilitadora
Las acciones facilitadoras son aquellas posibilidades en las que desencadena una regla bajo determinadas
condiciones. La norma podría dar lugar a la especificación de algunas funciones de software, cuyas
condiciones conducen a la acción de complejas combinaciones de valores lógicos.
SEGUNDO
BIMESTRE
En Wieger y Beatty (2006) se indica que las tablas de decisión son una buena alternativa para documentar
las reglas de negocio que consideran cuestiones lógicas. Cuando se realiza una declaración de la forma
“Si- entonces” es un indicio de que se está especificando una acción facilitadora.
SOLUCIONARIO
A continuación, se presentan algunos ejemplos de acciones facilitadoras.
• Si el almacén tiene el producto A que se solicita en stock, entonces se ofrece el producto en

existencia al solicitante.  
• Si la fecha de vencimiento del producto A en stock ha expirado, entonces notificar al personal
BIBLIOGRÁFICAS
encargado de bodega.  
REFERENCIAS
Inferencias
La inferencia (también llamada inferir el conocimiento), consiste en la generación de nuevo conocimiento

en base a unas reglas que cumplen con ciertas condiciones. Una inferencia permite crear un hecho
nuevo a partir de otros hechos o cálculos.  Una inferencia también consiste en declararla usando la
forma “si - entonces” de acuerdo a las acciones que permitan las reglas de negocio. Para este caso la ANEXOS
cláusula “entonces” implica un hecho o parte de información, no una acción a tomar. Algunos ejemplos
de inferencias son:  
• Si el pago no es recibido dentro de los 30 días calendario a partir de la fecha, entonces la cuenta
está en mora.  
• Si no se puede enviar el pedido en un plazo de 10 días a partir de la notificación de pago, entonces

el pedido está en estado pendiente de envío.  
Cálculos
Esta clase de reglas de negocio se ejecutan usando fórmulas matemáticas o algoritmos. Muchos cálculos
se derivan de reglas externas a la organización, como es el caso, en nuestro medio las retenciones por
concepto de venta. Estas reglas de cálculo permiten especificar requerimientos de software de acuerdo

a como se las va descubriendo. Las reglas de cálculo pueden ser expresadas en formato de texto o
alternativamente representarse de forma simbólica, a continuación, se especifican algunos ejemplos:  
ÍNDICE
• Hay un descuento a los productos de categoría A:
üü del 5% al valor unitario cuando el pedido está entre 10 y 15 unidades,
PRELIMINARES
üü del 10% al valor unitario cuando el pedido está entre 16 y 20 unidades y
üü del 15% al valor unitario cuando son más de 20 unidades.
• El envío de la orden dentro de la localidad y que pesa hasta 2 kilos es de 12.50 dólares, a partir de
allí 15 centavos por cada 100 gramos.
BIMESTRE
Debido a que las reglas de negocio pueden influir en múltiples aplicaciones, las organizaciones deben
PRIMER
administrar sus reglas como activos de nivel empresarial. Un catálogo simple de reglas de negocio será
suficiente inicialmente. Si está utilizando una herramienta de gestión de requisitos, puede almacenar
reglas empresariales como un tipo de requisito, siempre y cuando sean accesibles a todos sus proyectos
de software. Las grandes organizaciones o aquellas cuyas operaciones y sistemas de información están
fuertemente impulsados por las reglas de negocio deben establecer una base de datos de reglas de
SEGUNDO
BIMESTRE
negocio. Las herramientas de gestión de reglas comerciales se vuelven valiosas si su catálogo de reglas
supera una solución utilizando un procesador de textos, una hoja de cálculo, un wiki u otra herramienta
de colaboración. Algunos sistemas de gestión de reglas de negocio contienen motores de reglas, que
pueden automatizar la implementación de las reglas en sus aplicaciones.
SOLUCIONARIO
El Grupo de reglas de negocio mantiene una lista de productos para la administración de reglas de
negocio. A medida que identifica nuevas reglas mientras trabaja en una aplicación, agréguelas al
catálogo en lugar de incrustarlas en la documentación para esa aplicación específica o, peor, sólo en su
código. Las normas relacionadas con la seguridad o el cumplimiento normativo representan el mayor
riesgo si no se administran y aplican de manera adecuada.
BIBLIOGRÁFICAS
REFERENCIAS
A medida que adquiera experiencia en la identificación y documentación de reglas de negocio, puede
aplicar plantillas estructuradas para definir reglas de diferentes tipos. Estas plantillas describen patrones
de palabras clave y cláusulas que estructuran las reglas de una manera consistente. También facilitan el
almacenamiento de las reglas en una base de datos, una herramienta comercial de gestión de reglas de
negocio o un motor de reglas de negocio.
Los conjuntos de reglas relacionadas también se pueden representar usando herramientas tales como
árboles de decisión y tablas de decisión (particularmente cuando está involucrada una lógica compleja) ANEXOS
y matrices de roles y permisos. La plantilla para documentar las reglas deberá tener los siguientes datos:
• Un identificador.
• Una definición de la regla.
• Pertenecer a una categoría (Hecho, Restricción, Acción facilitadora, Inferencia o Cálculo).
• Pertenecer a un grupo.
• Identificar si es estática o dinámica.
• Fecha en que será efectiva (si es el caso) Fuente (de ser necesario)
• En qué caso de uso se utiliza (en el momento apropiado).

Tabla 13.
Ejemplo de reglas de negocio
ÍNDICE
Estática o
ID Definición de la regla Categoría Grupo
Dinámica
Cada contenedor de productos químicos tiene un Política
HEC-001 Hecho Estática
código de barras de identificador único. corporativa
PRELIMINARES
Cada elemento de línea en un pedido representa
Política
HEC-002 una combinación específica de químicos, grado, Hecho Estática
corporativa
tamaño del envase, y el número de contenedores.
Todas las aplicaciones de software deben cumplir
Política
REC-012 con las regulaciones gubernamentales para el uso Restricción Dinámica
corporativa
por personas con discapacidad visual
BIMESTRE
PRIMER
Dar a cada regla de negocio un identificador único le permite vincular los requisitos a una regla
específica. Por ejemplo, algunas plantillas para casos de uso contienen un campo para reglas de negocio
que influyen en el caso de uso. En lugar de incluir la definición de regla en la descripción del caso de
uso, simplemente ingrese los identificadores para las reglas relevantes. Cada ID sirve como un puntero
a la instancia maestra de la regla de negocio. De esta manera, no tiene que preocuparse de que la
SEGUNDO
BIMESTRE
especificación de caso de uso se vuelva obsoleta si la regla cambia.
Al igual que preguntar “¿Cuáles son sus requisitos?” No ayuda mucho al obtener los requisitos de los
usuarios, preguntar a los usuarios “¿Cuáles son sus reglas de negocio?” No te lleva muy lejos. A veces
se inventan las reglas de negocio a medida que avanza, a veces se plantean durante las discusiones de
SOLUCIONARIO
requisitos, ya veces es necesario buscarlos. Los siguientes son varios lugares comunes y maneras de
buscar reglas. (Boyer y Mili, 2011)
• “Conocimiento común” de la organización, a menudo recogido de las personas que han trabajado
con el negocio durante mucho tiempo y conocen los detalles de cómo funciona.
BIBLIOGRÁFICAS
REFERENCIAS
• Sistemas legados que incorporan reglas de negocio en sus requisitos y código. Esto requiere
la lógica de la ingeniería inversa detrás de los requisitos o el código para entender las reglas
pertinentes. Esto a veces produce un conocimiento incompleto sobre las reglas de negocio.
• Modelado de procesos de negocio, que lleva al analista a buscar reglas que puedan afectar a
cada paso del proceso: restricciones, eventos desencadenantes, reglas computacionales y hechos
relevantes.
ANEXOS
• Análisis de la documentación existente, incluyendo especificaciones de requisitos de proyectos
anteriores, regulaciones, estándares de la industria, documentos de política corporativa, contratos
y planes de negocios.
• Análisis de datos, como los diversos estados que un objeto de datos puede tener y las condiciones
bajo las cuales un usuario o un evento del sistema pueden cambiar el estado del objeto. Estas
autorizaciones también podrían representarse como una matriz de roles y permisos.
• Departamentos de cumplimiento en empresas que desarrollan sistemas sujetos a regulación.
El hecho de encontrar algunas reglas de negocio en estas diversas fuentes no significa que necesariamente
se aplican a su proyecto actual o que aún son válidos. Las fórmulas computacionales implementadas
en el código de aplicaciones heredadas podrían ser obsoletas. Asegúrese de confirmar si es necesario
actualizar las reglas recogidas de los documentos y aplicaciones más antiguos. Evalúe el alcance de la

aplicabilidad de las reglas que descubra. ¿Son locales al proyecto, o abarcan un dominio de negocio o
toda la empresa?
ÍNDICE
Políticas
Modelos de
PRELIMINARES
Regulaciones
¿Porqué hacer datos
esto así?
¿Cómo estas
¿Qué necesita
piezas de datos
el gobierno?
se relacionan
¿Cómo se ¿Qué podría

Reglas de Decisiones
BIMESTRE
Fórmulas calcula el hacer el usuario
PRIMER
número?
negocio de actores
luego?
¿Qué causa un ¿Qué se puede

cambio en el o no hacer?
estado del ¿Cómo sabe el
objeto? sistema que
SEGUNDO
BIMESTRE
Ciclo de vida hacer luego? Eventos
objetos
Sistemas de
decisión
SOLUCIONARIO
Figura 32. Descubrir reglas de negocio mediante preguntas
Fuente: Lamsweerde (2009)
A menudo, los interesados del proyecto ya conocen las reglas de negocio que influirán en la aplicación.
Ciertos empleados a veces tratan con tipos particulares o clases de reglas. Si ese es el caso en su entorno,
averiguar quién son esas personas y llevarlos a la discusión. El analista de negocio puede recoger
BIBLIOGRÁFICAS
REFERENCIAS
las reglas de negocio durante las actividades de obtención que también definen otros requisitos de
artefactos y modelos.
Durante las entrevistas y talleres, el analista de negocio puede hacer preguntas para investigar la
justificación de los requisitos y limitaciones que los usuarios presentan. La figura 32 muestra varios
orígenes potenciales de las reglas. También sugiere algunas preguntas que un analista de negocio puede
hacer cuando se discuten varias cuestiones de requisitos con los usuarios.
ANEXOS
Luego de identificar y documentar las reglas de negocio, determine cuáles deben ser implementadas
en el software. Las reglas de negocio y los requisitos funcionales correspondientes a veces se parecen
mucho. Sin embargo, las reglas son declaraciones externas de políticas que deben aplicarse al software,
impulsando así la funcionalidad del sistema.
Cada analista de negocio debe decidir qué reglas pertenecen a su aplicación, cuáles deben ser aplicadas
en el software, y cómo hacerlas cumplir.

ÍNDICE
Hemos finalizado el estudio de la unidad 5 y es necesario que profundice sus conocimientos en
PRELIMINARES
cuanto a los modelos de análisis, se recomienda el desarrollo de las siguientes actividades:
•• Desarrolle el diagrama de casos de uso. Considere el “Caso local” y los documentos generados
en la unidad anterior.
•• Detalle la menos dos casos de uso. Elija los procesos más representativos que involucre alto
grado de interacción del usuario.
•• Revise los procesos definidos en la unidad anterior, mediante los mapas de proceso y
determine los diferentes escenarios para construir el diagrama de casos de uso.
BIMESTRE
PRIMER
•• Utilice la plantilla que se recomienda en la figura 5.12, para detallar los casos de uso
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS

Autoevaluación 5
ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
1. El modelo que permite conocer quienes interactúan directamente con el sistema, es:
a. Tabla de actores
b. Glosario
c. Casos de uso
SEGUNDO
BIMESTRE
2. Cuando se requiere modelar el negocio, es necesario:
a. Establecer políticas de negocio

b. Combinar entre mapa de relaciones y/o mapa de procesos
SOLUCIONARIO
c. Priorizar requerimientos
3. Cuando se desea adicionar detalle a los requerimientos de usuario, es conveniente desarrollar:
a. Casos de uso
BIBLIOGRÁFICAS
b. Diagrama de contexto
REFERENCIAS
c. Políticas de negocio
4. Un mapa de procesos permite mostrar:
a. El tipo de información y productos que se intercambian entre clientes externos

b. Una secuencia de pasos, entradas y salidas necesarias para manejar un proceso de negocio
c. El sistema en su entorno ANEXOS
5. Son reglas que sirven para limitar las acciones que el sistema o los usuarios deben realizar. Se las
conoce como:
a. Restricciones
b. Hechos
c. Inferencias

6. Cuando existe un caso de uso padre del cual uno o más casos de uso hijos heredan sus características
y especializan cierto comportamiento, se da una relación de:
ÍNDICE
a. Inclusión
b. Extensión
c. Generalización
PRELIMINARES
7. La tabla de actores, permite
a. Identificar interesados
b. Identificar y clasificar a los usuarios del sistema en términos de sus funciones y
responsabilidades
c. Establecer una correspondencia entre actores y detalle de casos de uso
BIMESTRE
PRIMER
8. A los diagramas que muestran al sistema en su entorno, con las entidades externas que
proporcionan y reciben información o material desde y hacia el sistema, se los conoce como:
a. Mapa de procesos
b. Mapa de relación
SEGUNDO
BIMESTRE
c. Diagramas de contexto
9. Un ejemplo de política de negocio es:
a. Incrementar la cantidad de estudiantes nuevos en un 15% en el próximo período
SOLUCIONARIO
b. Ofrecer descuentos a los estudiantes en su matrícula de acuerdo al período de tiempo en
que realice la matrícula
c. A los estudiantes que pagan al contado su matrícula reciben un descuento del 10%
10. Las reglas que se ejecutan usando fórmulas matemáticas o algorítmicas. Se las conoce como:
BIBLIOGRÁFICAS
REFERENCIAS
a. Restricciones
b. Hechos
c. Cálculos
Estimado estudiante
Recuerde que al final del presente texto guía se encuentran las respuestas a ésta autoevaluación ANEXOS
Ir a solucionario

UNIDAD 6. ESPECIFICACIÓN DE REQUISITOS
ÍNDICE
Estimado estudiante
Una vez que se han aplicado las técnicas de obtención, considerando los distintos escenarios en los
que se debe aplicar las estrategias de obtención y aplicados los modelos de análisis correspondientes,
PRELIMINARES
es hora de especificar los requisitos. Muchos asocian a esta actividad con el simple hecho de llenar una
plantilla, pero ese no es el objetivo de la especificación. Se requiere de todo el conocimiento y habilidades
del analista para definir los requisitos apropiados y que cumplan con las características de una buena
definición. Si es importante que se documenten y para ello están las plantillas que ayudan y aportan
con la información que se debe registrar. El lenguaje natural nos permite hacer la descripción de las
diferentes partes de la documentación, pero a veces la ambigüedad es un problema que, si no se pone la
BIMESTRE
atención adecuada, puede ocurrir y por lo tanto la calidad de las especificaciones no sean las adecuadas.
PRIMER
Para ello están las directrices que ciertos autores recomiendan se utilicen con el único fin, lograr una
especificación y documentación de los requisitos que cumplan con niveles de calidad aceptable.
6.1. Documentando los requisitos
SEGUNDO
BIMESTRE
La comunicación clara y eficaz es el principio básico del desarrollo de requisitos: la comunicación de
las personas con necesidades a las personas que pueden concebir soluciones, luego a las personas que
pueden implementar y verificar esas soluciones. Un analista de negocios calificado elegirá la forma más
eficaz de comunicar cada tipo de información de requisitos a cada audiencia.
SOLUCIONARIO
El resultado del desarrollo de requisitos es un acuerdo documentado entre los Interesados sobre el
producto a ser construido. Como se vio en los capítulos anteriores, el documento de visión y alcance
contiene los requisitos del negocio y los requisitos de los usuarios pueden ser capturados en forma de
casos de uso o historias de usuarios. Los requisitos funcionales y no funcionales del producto a menudo
se almacenan en la especificación de requisitos de software, o ERS (su equivalente en inglés SRS), que
BIBLIOGRÁFICAS
REFERENCIAS
se entrega a aquellos que deben diseñar, construir y verificar la solución. Los requisitos se registran de
forma organizada para que los interesados clave del proyecto puedan ayudar a revisar y asegurar están
de acuerdo.
Este capítulo trata el propósito, estructura y contenido del ERS. Describiremos el ERS como un documento,
pero no tiene que ser en forma de un documento tradicional de procesamiento de textos. De hecho, los
documentos presentan numerosas limitaciones:
ANEXOS
1. Es difícil almacenar atributos descriptivos junto con los requisitos.
2. La gestión del cambio es torpe.
3. Es difícil conservar las versiones históricas de los requisitos.
4. No es fácil sub-conjugar una parte de los requisitos que se asignan a una iteración en particular o
hacer un seguimiento de los que fueron aprobados, pero luego diferidos o cancelados
5. Es difícil rastrear los requisitos de otros artefactos de desarrollo.
6. La duplicación de un requisito que se ajusta lógicamente en varios lugares provoca problemas de
mantenimiento.
Como alternativa, puede almacenar información en una hoja de cálculo (que tiene muchas de las mismas
limitaciones que un documento), una Wiki, una base de datos o una herramienta de administración de
requisitos. Piense en éstos como diferentes repositorios o contenedores posibles para la información de

los requisitos. No importa qué forma de repositorio de requisitos utilice, siempre necesitará el mismo
tipo de información. La plantilla ERS es una guía útil de información que se recopilará y cómo podría
ÍNDICE
organizarse.
No todo el mundo está de acuerdo en que vale la pena dedicarle tiempo para documentar los requisitos.
Y en proyectos exploratorios o altamente volátiles en los que no se está seguro de con qué solución va a
terminar, tratar de mantenerse al día con los cambios en los detalles de los requisitos añade poco valor.
PRELIMINARES
Sin embargo, el costo de registrar el conocimiento es pequeño comparado con el costo de adquirir ese
conocimiento o regenerarlo en algún momento en el futuro. Los actos de especificación y modelización
ayudan a los participantes del proyecto a reflexionar y precisamente a exponer cosas importantes que
en una discusión verbal puede resultar ambiguas. Si está 100% seguro de que ningún interesado nunca
necesitará una información específica más allá de la duración de sus propios recuerdos a corto plazo,
entonces no necesita grabarlo. De lo contrario, guárdelo en algún tipo de memoria de grupo.
BIMESTRE
PRIMER
Nunca obtendrá los requisitos perfectos. Recuerde que está escribiendo requisitos para ciertas
audiencias. La cantidad de detalles, el tipo de información que usted proporciona y la forma en que
lo organiza deben ser todos destinados a satisfacer las necesidades de sus audiencias. Los analistas,
naturalmente, escriben los requisitos desde su propio punto de vista, pero realmente se deben escribir lo
más significativo para aquellos que tienen que entender los requisitos y hacer el trabajo basado en ellos.
SEGUNDO
BIMESTRE
Por eso es importante que los representantes de esas audiencias revisen los requisitos para asegurarse
de que satisfarán sus necesidades.
El reajuste progresivo de los detalles es un principio clave para el desarrollo efectivo de los requisitos.
En la mayoría de los proyectos no es ni realista ni necesario establecer al detalle todos los requisitos
SOLUCIONARIO
al principio del proyecto. En cambio, piensa en términos de capas. Necesita aprender lo suficiente
sobre los requisitos para luego poder priorizarlos y asignarlos a las próximas versiones o iteraciones. A
continuación, puede detallar los grupos de requisitos a tiempo para dar a los desarrolladores información
suficiente para que puedan evitar el excesivo e innecesario trabajo.
No espere ni siquiera la mejor documentación de requisitos para reemplazar las discusiones en curso a lo
BIBLIOGRÁFICAS
REFERENCIAS
largo del proyecto. Mantenga abiertas las líneas de comunicación entre el analista de negocio, el equipo
de desarrollo, los representantes de los clientes y otras partes interesadas para que puedan abordar
rápidamente los innumerables problemas que se presentarán.
Puede representar los requisitos de software de varias maneras, incluyendo:
1. Lenguaje natural bien estructurado y cuidadosamente escrito.

2. Modelos visuales que ilustran procesos de transformación, estados del sistema y cambios entre ANEXOS
ellos, relaciones de datos, flujos lógicos, y similares.
3. Especificaciones formales que definen requisitos mediante el uso de lenguajes de especificación
matemáticamente precisos.
Las especificaciones formales proporcionan el mayor rigor y precisión, pero pocos desarrolladores de
software y aún menos los clientes están familiarizados con ellos. La mayoría de los proyectos no exigen
este nivel de formalidad, pero ciertamente que los diseñadores de sistemas de alto riesgo como los
sistemas de control de centrales nucleares usen métodos de especificación formal. El lenguaje natural
estructurado, aumentado con modelos visuales y otras técnicas de representación (tales como tablas,
maquetas, fotografías y expresiones matemáticas), sigue siendo la forma más práctica para la mayoría de
los proyectos de software de documentar sus necesidades.

6.2. La especificación de requisitos
ÍNDICE
A la especificación de requisitos de software se lo conoce con muchos nombres en distintas organizaciones,
aunque las organizaciones no utilizan estos términos de la misma manera. A veces se denomina
documento de requisitos de negocio (DRN), especificación funcional, especificación del producto,
especificación del sistema o simplemente documento de requisitos. Debido a que la “Especificación de
Requisitos de Software” es un término estándar de la industria se utilizará éste término (ISO/IEC/IEEE,
PRELIMINARES
2011).
El ERS establece las funciones y capacidades que un sistema de software debe proporcionar, sus
características y las restricciones que debe respetar. Debe describir completamente como sea necesario
los comportamientos del sistema en diversas condiciones, así como las cualidades del sistema deseadas
tales como rendimiento, seguridad y usabilidad. El ERS es la base para la posterior planificación, diseño y
BIMESTRE
PRIMER
codificación del proyecto, así como la base para las pruebas del sistema y la documentación del usuario.
Sin embargo, no debe contener detalles de diseño, construcción, pruebas o gestión de proyectos que
no sean las limitaciones de diseño y ejecución conocidas. Incluso las personas que trabajan en proyectos
ágiles necesitan el tipo de información que se encuentra en un buen ERS. Normalmente no recopilan
toda esta información de forma coherente, pero una plantilla de ERS proporciona un recordatorio
práctico de qué tipo de conocimiento se debe explorar.
SEGUNDO
BIMESTRE
Una entrega única de requisitos a menudo no puede satisfacer las necesidades de todas las audiencias.
Algunas personas necesitan saber sólo los objetivos del negocio, otros quieren sólo una imagen de alto
nivel, otros quieren ver sólo la perspectiva del usuario, y otros necesitan todos los detalles. Esta es una de
las razones por las que abogamos por crear los productos que llamamos documento de visión y alcance,
SOLUCIONARIO
documento de requisitos de usuario y especificación de requisitos de software. No espere que todos sus
representantes de usuario lean el ERS detallado y no espere que los desarrolladores aprendan todo lo
que necesitan de un conjunto de casos de uso o historias de usuarios.
Numerosas son las audiencias que se basan en el ERS, entre las que tenemos:
BIBLIOGRÁFICAS
REFERENCIAS
1. Los clientes, el departamento de marketing y el personal de ventas necesitan saber qué producto
pueden esperar para ser entregados.
2. Los administradores de proyectos basan sus estimaciones de calendario, esfuerzo y recursos en
los requisitos.
3. Los equipos de desarrollo de software necesitan saber qué construir.
4. Los probadores lo utilizan para desarrollar pruebas basadas en requisitos, planes de prueba y
procedimientos de prueba. ANEXOS
5. El personal de mantenimiento y el personal de soporte lo usan para entender lo que cada parte
del producto se supone que debe hacer.
6. Escritores de documentación, manuales de usuario y pantallas de ayuda se basan en el ERS y el
diseño de interfaz de usuario.
7. El personal de capacitación utiliza el ERS y la documentación del usuario para desarrollar materiales
educativos.
8. El personal jurídico asegura que los requisitos cumplen con las leyes y regulaciones.
9. Los subcontratistas basan su trabajo en los requisitos especificados y pueden ser considerados
legalmente.
Si una capacidad o calidad deseada no aparece en algún lugar del acuerdo de requisitos, nadie debería
esperar que aparezca en el producto.

No tiene que escribir el ERS para todo el producto antes de comenzar el desarrollo, pero debe capturar
los requisitos para cada incremento antes de crear ese incremento. El desarrollo incremental es
ÍNDICE
apropiado cuando se desea obtener rápidamente alguna funcionalidad de manos de los usuarios. La
retroalimentación de usar los primeros incrementos dará forma al resto del proyecto. Sin embargo, cada
proyecto debe basar un acuerdo para cada conjunto de requisitos antes de que el equipo los implemente.
La línea base es el proceso de transición de un ERS en desarrollo en uno que ha sido revisado y aprobado.
Trabajar con un conjunto acordado de requisitos minimiza la falta de comunicación y la repetición
PRELIMINARES
innecesaria.
Es importante organizar y escribir el ERS para que los diversos actores puedan entenderlo. Tenga en
cuenta las siguientes sugerencias de legibilidad:
• Utilice una plantilla apropiada para organizar toda la información necesaria.
BIMESTRE
• Etiquetar y diseñar secciones, subsecciones y requisitos individuales de forma consistente.
PRIMER
• Utilice el énfasis visual (negrita, subrayado, cursiva, color y fuentes) de manera consistente y
juiciosa. Recuerde que el resaltado del color puede no ser visible para las personas con ceguera de
color o cuando se imprime en escala de grises.
• Crear una tabla de contenido para ayudar a los lectores a encontrar la información que necesitan.
SEGUNDO
BIMESTRE
• Numere todas las figuras y tablas, póngales subtítulos, y refiérase a ellos por número.
• Si está almacenando los requisitos en un documento, defina la facilidad de referencia cruzada
del procesador de textos en lugar de la páginas codificadas o números de sección para hacer
referencia a otras ubicaciones dentro de un documento.
• Si está utilizando documentos, defina hipervínculos para que el lector salte a las secciones
SOLUCIONARIO
relacionadas en el SRS o en otros archivos.
• Si está almacenando los requisitos en una herramienta, utilice vínculos para que el lector navegue
en la información relacionada.
• Incluir representaciones visuales de la información cuando sea posible para facilitar la comprensión.
• Recurrir a un editor especializado para asegurarse de que el documento es coherente y utiliza un
BIBLIOGRÁFICAS
REFERENCIAS
vocabulario y plan coherente.
6.3. Etiquetado de requisitos
Cada requisito necesita un identificador único y persistente. Esto le permite referirse a requisitos
específicos en una solicitud de cambio, una historia de modificaciones, una referencia cruzada o una
matriz de trazabilidad de requisitos. También permite reutilizar los requisitos en múltiples proyectos. Los ANEXOS
requisitos de identificación única facilitan la colaboración entre los miembros del equipo cuando están
discutiendo los requisitos, como en una reunión de revisión por pares. Las listas simples numeradas o con
viñetas no son adecuadas para estos propósitos. Echemos un vistazo a las ventajas y las deficiencias de
varios requisitos-métodos de etiquetado. Seleccione la técnica que tenga más sentido para su situación.
Número secuencial
El enfoque más simple da a cada requisito un número de secuencia único, como UC-9 o FR-26. Las
herramientas de gestión de requisitos comerciales asignan tal identificador cuando un usuario añade
un nuevo requisito a la base de datos de la herramienta. El prefijo indica el tipo de requisito, como FR
para requisitos funcionales. Un número no se reutiliza si se elimina un requisito, por lo que no tiene
que preocuparse por un lector que confunde el FR-26 original con un nuevo FR-26. Este enfoque
de numeración simple no proporciona ningún agrupamiento lógico o jerárquico de los requisitos

relacionados, el número no implica ningún tipo de ordenación, y las etiquetas no dan ninguna pista
en cuanto a lo que cada requisito se trata. Facilita la retención de un identificador único si mueve los
ÍNDICE
requisitos en un documento.
Numeración jerárquica
Lo más común, si los requisitos funcionales aparecen en la sección 3.2 de su ERS, todos ellos tendrán
PRELIMINARES
etiquetas que comienzan con 3.2. Más dígitos que indican un requisito más detallado, de menor nivel, por
lo que usted sabe que 3.2.4.3 es un requisito hijo de 3.2.4. Este método es simple, compacto y familiar. Su
procesador de textos probablemente puede asignar los números automáticamente. Las herramientas
de gestión de requisitos generalmente también admiten la numeración jerárquica.
Sin embargo, la numeración jerárquica plantea algunos problemas. Las etiquetas pueden crecer hasta
muchos dígitos incluso en un ERS de tamaño mediano. Las etiquetas numéricas no le dicen nada sobre
BIMESTRE
PRIMER
la intención de un requisito. Si está utilizando un procesador de textos, normalmente este esquema no
genera etiquetas persistentes.
Si inserta un nuevo requisito, se incrementarán los números de los siguientes requisitos en esa sección.
Elimine o mueva un requisito y los números que le siguen en esa sección se reducirán. Eliminar, insertar,
combinar o mover secciones enteras y cambiar muchas etiquetas. Estos cambios interrumpen cualquier
SEGUNDO
BIMESTRE
referencia a esos requisitos en otras partes del sistema.
Una mejora sobre la numeración jerárquica consiste en numerar las secciones principales de los requisitos
de forma jerárquica e identificar los requisitos funcionales individuales en cada sección con un código de
texto breve seguido de un número de secuencia. Por ejemplo, el ERS podría contener “Sección 3.5-Editor
SOLUCIONARIO
de Funciones”, y los requisitos en esa sección podrían ser etiquetados ED-1, ED-2, y así sucesivamente.
Este enfoque proporciona cierta jerarquía y organización al mismo tiempo que mantiene las etiquetas
cortas, algo significativas y menos dependientes de la posición. Sin embargo, no resuelve totalmente el
problema del número de secuencia.
BIBLIOGRÁFICAS
Etiquetas de texto jerárquicas
REFERENCIAS
Existe una sugerencia de un esquema de etiquetado jerárquico basado en texto para etiquetar los
requisitos individuales. Tenga en cuenta este requisito: “El sistema pedirá al usuario que confirme
cualquier solicitud para imprimir más de 10 copias”. Este requisito podría ser etiquetado como Print.
Con rmCopies. Esto indica que forma parte de la función de impresión y se refiere al número de copias
que se van a imprimir. Las etiquetas textuales jerárquicas están estructuradas, son significativas y no se
ven afectadas añadiendo, eliminando o moviendo otros requisitos. Este método también es adecuado ANEXOS
para etiquetar reglas de negocio si las mantiene manualmente, en lugar de hacerlo en un repositorio o
herramienta de reglas de negocio dedicado.
El uso de etiquetas de texto jerárquico ayuda a resolver el problema de las relaciones padre-hijo entre los
requisitos. Si el padre está escrito como un requisito funcional, la relación entre los hijos y el padre puede
ser confusa. Una buena convención es escribir el requerimiento de los padres para que parezca un título,
un encabezado o un nombre de entidad, en lugar de parecer un requisito funcional en sí mismo. Los
requisitos de los hijos de ese padre, en conjunto, entregan la capacidad descrita en el padre. En la figura
33 se presenta un ejemplo que contiene un encabezado y requisitos funcionales.

ÍNDICE
PRELIMINARES
Figura 33. Etiqueta de requisitos de forma jerárquica
BIMESTRE
PRIMER
Como se puede ver la única ID completa de cada requisito se construye añadiendo la etiqueta de
cada línea a las etiquetas de los padres encima de ella. La declaración de producto se escribe como un
encabezado, no como un requisito discreto.
El primer requisito funcional se etiqueta Producto.Carro. El ID completo para el tercer requisito es
SEGUNDO
BIMESTRE
Producto.Descuento.Error. Este esquema jerárquico evita los problemas de mantenimiento con la
numeración jerárquica, pero las etiquetas son más largas y hay que pensar en nombres significativos
para ellos, tal vez construyendo a partir del nombre entidades relevantes. Puede ser difícil mantener
la singularidad, especialmente si tiene varias personas trabajando en el conjunto de requisitos. Puede
simplificar el esquema combinando la técnica de nomenclatura jerárquica con un sufijo de número
SOLUCIONARIO
de secuencia para pequeños conjuntos de requisitos: Producto.Carro.01, Producto.Carro.02 y así
sucesivamente. Muchos esquemas pueden trabajar.
6.4. La interfaz de usuario y el ERS
BIBLIOGRÁFICAS
REFERENCIAS
La incorporación de diseños de interfaces de usuario en el ERS tiene tanto beneficios como inconvenientes.
En el lado positivo, explorar posibles interfaces de usuario con prototipos de papel, maquetas de trabajo,
wireframes o herramientas de simulación hace que los requisitos sean tangibles tanto para los usuarios
como para los desarrolladores. Si los usuarios del producto tienen expectativas de cómo las partes del
producto podrían verse y sentirse y, por lo tanto, podrían estar decepcionados si sus expectativas no
estaban satisfechas, esas expectativas pertenecen al ámbito de los requisitos.
ANEXOS
En el lado negativo, las imágenes de pantalla y las arquitecturas de interfaces de usuario describen
soluciones y pueden no ser realmente requisitos. Incluirlos en el ERS hace que el documento sea más
grande, y los grandes documentos de requisitos asustan a algunas personas. Retrasar la línea base del
ERS hasta que el diseño de la interfaz de usuario esté completo puede ralentizar el desarrollo y probar
la paciencia de las personas que ya están preocupadas por pasar demasiado tiempo en los requisitos.
Incluir el diseño de interfaz de usuario en los requisitos puede resultar en el diseño visual que conduce a
los requisitos, que a menudo conduce a las lagunas funcionales. Las personas que escriben los requisitos
no están necesariamente bien calificadas para diseñar interfaces de usuario. Además, después de que
las partes interesadas vean una interfaz de usuario en un ERS (o en cualquier otro lugar), no lo “verán”.
La visualización temprana puede aclarar los requisitos, pero también puede conducir a la resistencia a
mejorar la IU con el tiempo.
Los diseños de pantallas no reemplazan los requisitos escritos del usuario y funcionales. No espere
que los desarrolladores deduzcan la funcionalidad subyacente y las relaciones de datos de las capturas

de pantalla. Si realmente desea implementar determinada funcionalidad con controles específicos

de interfaz de usuario y diseños de pantalla, es apropiado e importante incluir esa información en el
ÍNDICE
ERS como restricciones de diseño. Las restricciones de diseño limitan las opciones disponibles para el
diseñador de interfaz de usuario. Sólo asegúrese de que no impone restricciones innecesarias, prematura,
o por las razones equivocadas. Si el ERS está especificando una mejora a un sistema existente, a menudo
tiene sentido incluir figuras de pantalla exactamente cómo se van a implementar. Los desarrolladores
ya están limitados por la realidad actual del sistema existente, por lo que es posible saber de antemano
PRELIMINARES
cómo deberían verse las modificaciones, y tal vez también las nuevas.
Un equilibrio razonable es incluir imágenes conceptuales de pantallas seleccionadas en los requisitos

sin exigir que la implementación siga con precisión esos modelos. Vea la Figura 6.2 para un bosquejo de
página web de ejemplo. La incorporación de dichos bocetos en el ERS comunica de manera útil otra vista
de los requisitos, pero deja claro que los bocetos no son los diseños de pantalla comprometidos. Por
BIMESTRE
ejemplo, un bosquejo preliminar de un cuadro de diálogo complejo ilustrará la intención detrás de un
PRIMER
grupo de requisitos, pero un diseñador visual podría convertirlo en un cuadro de diálogo con pestañas
para mejorar la facilidad de uso.
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
Figura 34. Ejemplo de un “boceto” de interfaz de usuario adecuado para su inclusión en un documento ANEXOS
de requisitos
Los equipos que trabajan en proyectos que tienen muchas pantallas podrían encontrar más manejable
para documentar los detalles de diseño de la interfaz de usuario en una especificación de interfaz de
usuario independiente o mediante herramientas de diseño UI o herramientas de creación de prototipos.
Utilice técnicas tales como modelos de visualización-acción-respuesta para describir los nombres de los
elementos de pantalla, sus propiedades y su comportamiento en detalle. (Beatty y Chen, 2012)
6.5. Plantilla para especificar requisitos de software
Cada organización de desarrollo de software debe adoptar una o más plantillas ERS estándar para sus
proyectos. Varias plantillas ERS están disponibles (por ejemplo: ISO/IEC/IEEE 2011, Robertson y Robertson

2013). Si su organización aborda varios tipos o tamaños de proyectos, como un nuevo desarrollo de
sistemas grandes, así como pequeñas mejoras a los sistemas existentes, adopte una plantilla ERS para
ÍNDICE
cada clase de proyecto principal. La figura 35 ilustra una plantilla ERS que funciona bien para muchos
tipos de proyectos. En el Anexo 3 se propone un ejemplo de ERS que sigue esta plantilla, con instrucciones
de uso incrustadas en cada sección.
PRELIMINARES
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS
Figura 35. Plantilla para especificar requisitos de software


A veces un pedazo de información podría lógicamente ser registrado en varias secciones de la plantilla.
Escoja una sección y úsela consistentemente para ese tipo de información en su proyecto. Evite duplicar
ÍNDICE
la información en varias secciones, incluso si lógicamente caben en más de una. Las referencias cruzadas
y los hipervínculos pueden ayudar a los lectores a encontrar la información que necesitan.
Al crear documentos de requisitos, utilice prácticas y herramientas de control de versiones eficaces para
asegurarse de que todos los lectores saben qué versión están leyendo. Incluya un historial de revisiones
PRELIMINARES
para proporcionar un registro de los cambios hechos en el documento, que hizo cada cambio, cuando
se hizo, y la razón de ello.
Puede incorporar material por referencia a otros documentos de proyecto existentes en lugar
de duplicar información en el ERS. Los hipervínculos entre documentos son una forma de
hacerlo, al igual que los enlaces de trazabilidad definidos en una herramienta de gestión de
BIMESTRE
PRIMER
requisitos. Un riesgo con hipervínculos es que pueden romperse si la jerarquía de la carpeta
de documentos cambia.
A continuación, vamos a realizar una descripción breve de la plantilla para ERS.
1. Introducción
SEGUNDO
BIMESTRE
La introducción presenta una visión general para ayudar al lector a entender cómo se organiza el ERS y
cómo usarlo.
1.1. Propósito
SOLUCIONARIO
Identificar el producto o la aplicación cuyos requisitos se especifican en este documento, incluyendo
el número de revisión o liberación. Si este ERS pertenece sólo a una parte de un sistema complejo,
identifique esa porción o subsistema. Describir los diferentes tipos de lectores a los que se destina
el documento, tales como desarrolladores, gestores de proyectos, personal de marketing, usuarios,
probadores y documentadores.
BIBLIOGRÁFICAS
REFERENCIAS
1.2. Convenciones de documentos
Describa todas las normas o convenciones tipográficas utilizadas, incluyendo el significado de estilos
de texto específicos, resaltados o anotaciones. Si está etiquetando manualmente los requisitos, puede
especificar el formato aquí para cualquier persona que necesite agregar uno más tarde.
1.3. Alcance del proyecto ANEXOS
Proporcione una breve descripción del software especificado y su propósito. Relacionar el software con
los objetivos del usuario o de la empresa y con los objetivos y estrategias de negocio. Si se dispone
de una visión separada y un alcance o documento similar, consulte el mismo en lugar de duplicar su
contenido aquí. Un ERS que especifica una liberación incremental de un producto en evolución debe
contener su propia declaración de alcance como un subconjunto de la visión estratégica a largo plazo
del producto. Puede proporcionar un resumen de alto nivel de las principales funciones que contiene la
versión o las funciones significativas que realiza.
1.4. Referencias
Haga una lista de los documentos u otros recursos a los que se refiere este ERS. Incluya hipervínculos a
ellos si están en una ubicación persistente. Estos pueden incluir guías de estilo de interfaz de usuario,
contratos, normas, especificaciones de requisitos del sistema, especificaciones de interfaz o ERS para

un producto relacionado. Proporcione suficiente información para que el lector pueda acceder a cada
referencia, incluyendo su título, autor, número de versión, fecha, fuente, ubicación de almacenamiento
ÍNDICE
o URL.
2. Descripción general
Esta sección presenta una visión general de alto nivel del producto y el entorno en el que se utilizará, los
PRELIMINARES
usuarios anticipados y las restricciones, suposiciones y dependencias conocidas.
2.1. Perspectiva del producto
Describa el contexto y el origen del producto. ¿Es el siguiente miembro de una línea de productos en
crecimiento, la próxima versión de un sistema maduro, un reemplazo para una aplicación existente o un
producto completamente nuevo? Si este ERS define un componente de un sistema más grande, indique
BIMESTRE
PRIMER
cómo se relaciona este software con el sistema general e identifique las interfaces principales entre los
dos. Considere la posibilidad de incluir modelos visuales, como un diagrama de contexto o un mapa del
ecosistema para mostrar la relación del producto con otros sistemas.
2.2. Clases y características de usuario
SEGUNDO
BIMESTRE
Identifique las diferentes clases de usuarios que usted anticipa que usará este producto, y describa
sus características pertinentes. Algunos requisitos pueden referirse sólo a ciertas clases de usuario.
Identifique las clases de usuario favorecidas. Las clases de usuario representan un subconjunto de
las partes interesadas descritas en el documento de visión y alcance. Las descripciones de clase de
usuario son un recurso reutilizable. Si está disponible un catálogo maestro de clases de usuario, puede
SOLUCIONARIO
incorporar descripciones de clase de usuario simplemente señalándolas en el catálogo en lugar de
duplicar información.
2.3. Entorno operativo
Describir el entorno en el que operará el software, incluida la plataforma de hardware; Sistemas operativos
BIBLIOGRÁFICAS
REFERENCIAS
y versiones; Ubicaciones geográficas de usuarios, servidores y bases de datos; Y las organizaciones que
alojan las bases de datos, servidores y sitios web relacionados. Enumere cualquier otro componente o
aplicación de software con el que el sistema debe coexistir pacíficamente. Si se requiere un extenso trabajo
de infraestructura técnica en conjunto con el desarrollo del nuevo sistema, considere la posibilidad de
crear una especificación de requisitos de infraestructura separada para detallar ese trabajo.
2.4. Restricciones de diseño e implementación

ANEXOS
Hay ocasiones en las que se debe utilizar cierto lenguaje de programación, se debe utilizar una biblioteca
de códigos en particular que ya ha invertido tiempo para desarrollarla, y así sucesivamente. Describa
cualquier factor que restrinja las opciones disponibles para los desarrolladores y la justificación para
cada restricción. Los requisitos que incorporan o se escriben en la forma de ideas de solución en lugar
de las necesidades están imponiendo limitaciones de diseño, a menudo innecesariamente, así que ten
cuidado con ellos.
2.5. Suposiciones y dependencias
Una suposición es una afirmación que se cree que es verdadera en ausencia de pruebas o de conocimiento
negativo. Pueden surgir problemas si los supuestos son incorrectos, obsoletos, no se comparten o
cambian, por lo que ciertos supuestos se traducirán en riesgos del proyecto. Un lector de ERS podría
asumir que el producto se ajustará a una convención de interfaz de usuario particular, mientras que otro

podría asumir algo diferente. Un desarrollador podría asumir que un determinado conjunto de funciones
se escribirá por encargo para esta aplicación, mientras que el analista de negocios podría asumir que se
ÍNDICE
reutilizarán de un proyecto anterior y el director de proyecto podría esperar obtener una biblioteca
de funciones comerciales. Los supuestos a incluir aquí son los relacionados con la funcionalidad del
sistema; Los supuestos empresariales aparecen en el documento de visión y alcance.
Identificar las dependencias que el proyecto o sistema que se está construyendo tiene sobre factores
PRELIMINARES
externos o componentes fuera de su control. Por ejemplo, si se debe instalar Microsoft .NET Framework
4.5 o una versión más reciente antes de que se pueda ejecutar el producto, se trata de una dependencia.
3. Características del sistema
La plantilla que se indica en la Figura 6.2 muestra los requisitos funcionales organizados por la
característica del sistema, que es sólo una forma posible de organizarlos. Otras opciones organizativas
BIMESTRE
PRIMER
incluyen la organización de los requisitos funcionales por área funcional, proceso de uso, caso de uso,
modo de operación, clase de usuario, estímulo y respuesta. También son posibles combinaciones
jerárquicas de estos elementos, como los casos de uso dentro de las clases de usuario. No hay una sola
elección correcta; Seleccione un método de organización que facilite a los lectores la comprensión de las
capacidades previstas del producto. Describiremos el esquema de características como ejemplo.
SEGUNDO
BIMESTRE
3.x Función del sistema X
Indique el nombre de la función en pocas palabras, como “3.1 Registrar trámite”.
3.x.1 Descripción
SOLUCIONARIO
Proporcione una breve descripción de la característica e indique si es de alta, media o baja prioridad. Las
prioridades suelen ser dinámicas, cambiando a lo largo del proyecto. Si está utilizando una herramienta
de gestión de requisitos, defina un atributo de requisito para la prioridad
3.x.2 Requisitos funcionales
BIBLIOGRÁFICAS
REFERENCIAS
Describa los requisitos funcionales específicos asociados con esta característica. Estas son las capacidades
de software que deben implementarse para que el usuario realice los servicios de la característica o
para realizar un caso de uso. Describa cómo el producto debe responder a las condiciones de error
previstas y a las entradas y acciones no válidas. Etiquetar de manera única cada requisito funcional,
como se describió anteriormente en este capítulo. Si está utilizando una herramienta de administración
de requisitos, puede crear varios atributos para cada requisito funcional, como la justificación, el origen
y el estado. ANEXOS
4. Requerimientos de datos
Los sistemas de información proporcionan valor mediante la manipulación de datos. Utilice esta sección
de la plantilla para describir varios aspectos de los datos que el sistema consumirá como entradas,
procesará de alguna manera o creará como salidas. Algunos autores describen muchos patrones para
documentar con precisión los requisitos de datos (también conocidos como información).
4.1. Modelo de datos lógicos
Un modelo de datos es una representación visual de los objetos de datos y colecciones que el sistema
procesará y las relaciones entre ellos. Existen numerosas anotaciones para el modelado de datos,
incluyendo diagramas entidad-relación y diagramas de clases UML. Puede incluir un modelo de datos

para las operaciones de negocio que está siendo abordado por el sistema o una representación lógica de
los datos que el sistema manipulará. Esto no es lo mismo que un modelo de datos de implementación
ÍNDICE
que se realizará en forma de diseño de base de datos.
4.2. Diccionario de datos
El diccionario de datos define la composición de las estructuras de datos y el significado, el tipo de
PRELIMINARES
datos, la longitud, el formato y los valores permitidos para los elementos de datos que constituyen esas
estructuras. Las herramientas de modelado de datos comerciales a menudo incluyen un componente
de diccionario de datos. En muchos casos, es mejor guardar el diccionario de datos como un artefacto
independiente, en lugar de incrustarlo en el medio de un ERS. Esto también aumenta su potencial de
reutilización en otros proyectos.
4.3. Informes
BIMESTRE
PRIMER
Si su aplicación genera informes, identifíquelos aquí y describa sus características. Si un informe debe
ajustarse a un diseño predefinido específico, puede especificarlo aquí como una restricción, tal vez con
un ejemplo. De lo contrario, enfóquese en las descripciones lógicas del contenido del reporte, secuencia
de clasificación, niveles de total y así sucesivamente, diferir el diseño detallado del informe en la etapa
de diseño.
SEGUNDO
BIMESTRE
4.4. Adquisición, integridad, retención y eliminación de datos
Si es relevante, describa cómo se obtienen y mantienen los datos. Por ejemplo, al iniciar un inventario de
datos, es posible que necesite hacer un volcado inicial de todos los datos de inventario al sistema receptor
SOLUCIONARIO
y luego tener que alimentar sólo los cambios. Exponga cualquier requisito relativo a la necesidad de
proteger la integridad de los datos del sistema. Identificar cualquier técnica específica que sea necesaria,
como copias de seguridad, puntos de verificación, reflejo o verificación de exactitud de datos. Políticas
de estado que el sistema debe aplicar para retener o deshacerse de datos, incluidos datos temporales,
metadatos, datos residuales (como registros eliminados), datos almacenados en caché, copias locales,
BIBLIOGRÁFICAS
archivos y copias de seguridad provisionales.
REFERENCIAS
5. Requisitos de la interfaz externa
Esta sección proporciona información para garantizar que el sistema se comunique correctamente con
los usuarios y con elementos externos de hardware o software. El logro de un acuerdo sobre interfaces de
sistemas externos e internos ha sido identificado como una mejor práctica de la industria del software.
ANEXOS
Un sistema complejo con múltiples subcomponentes debería crear una especificación de interfaz o una
especificación de arquitectura de sistema separada. La documentación de la interfaz podría incorporar
material de otros documentos por referencia. Por ejemplo, podría apuntar a un manual de dispositivo de
hardware que enumera los códigos de error que el dispositivo podría enviar al software.
5.1. Interfaces de usuario
Describir las características lógicas de cada interfaz de usuario que el sistema necesita. Algunas
características específicas de las interfaces de usuario podrían aparecer en la sección 6.1 Usabilidad.
Algunos puntos a tratar aquí son:

1. Referencias a estándares de interfaz de usuario o guías de estilo de línea de producto

que se deben seguir
ÍNDICE
2. Estándares para fuentes, iconos, etiquetas de botones, imágenes, esquemas de color,
secuencias de tabulación, controles de uso común, gráficos de marca, avisos de
copyright y privacidad y similares
3. Restricciones de tamaño, disposición o resolución de pantalla
PRELIMINARES
4. Botones, funciones o vínculos de navegación estándar que aparecerán en todas las
pantallas, como un botón de ayuda
5. Teclas de atajo
6. Convenciones de presentación de mensajes y frases
7. Directrices de validación de datos (como restricciones de valores de entrada y cuándo
validar los contenidos de campo)
BIMESTRE
PRIMER
8. Estándares de diseño para facilitar la localización de software
9. Alojamiento para usuarios con impedimentos visuales, ciegos de color o con otras
limitaciones
5.2. Interfaces de software
SEGUNDO
BIMESTRE
Describir las conexiones entre este producto y otros componentes de software (identificados por
nombre y versión), incluyendo otras aplicaciones, bases de datos, sistemas operativos, herramientas,
bibliotecas, sitios web y componentes comerciales integrados. Indique el propósito, los formatos y el
contenido de los mensajes, datos y valores de control intercambiados entre los componentes de software.
SOLUCIONARIO
Especifique las asignaciones de datos de entrada y salida entre los sistemas y cualquier traducción que
se necesite hacer para que los datos pasen de un sistema a otro. Describir los servicios necesarios para
o desde componentes de software externos y la naturaleza de las comunicaciones entre componentes.
Identifique los datos que se intercambiarán o compartirán entre componentes de software. Especifique
los requisitos no funcionales que afectan a la interfaz, como los niveles de servicio para los tiempos
de respuesta y las frecuencias, o los controles y restricciones de seguridad. Parte de esta información
BIBLIOGRÁFICAS
REFERENCIAS
podría especificarse como requisitos de datos en la sección 4 o como requisitos de interoperabilidad en
la sección 6, Atributos de calidad.
5.3. Interfaces de hardware
Describir las características de cada interfaz entre los componentes de software y los componentes de
hardware, si los hay, del sistema. Esta descripción puede incluir los tipos de dispositivos soportados, los
datos y las interacciones de control entre el software y el hardware y los protocolos de comunicación ANEXOS
que se utilizarán. Enumere las entradas y salidas, sus formatos, sus valores o rangos válidos y cualquier
problema de sincronización que los desarrolladores tengan que tener en cuenta. Si esta información es
extensa, considere la posibilidad de crear un documento de especificación de interfaz separado.
5.4. Interfaces de comunicaciones
Indique los requisitos para cualquier función de comunicación que el producto utilice, incluido correo
electrónico, navegador web, protocolos de red y formularios electrónicos. Defina cualquier formato de
mensaje pertinente. Especifique la seguridad de la comunicación y los problemas de cifrado, las tasas de
transferencia de datos, la sincronización y los mecanismos de sincronización. Indique las restricciones en
torno a estas interfaces, como si ciertos tipos de archivos adjuntos de correo electrónico son aceptables
o no.

6. Atributos de calidad
Esta sección específica los requisitos no funcionales distintos de las restricciones, que se registran en
ÍNDICE
la sección 2.4, y los requisitos de la interfaz externa, que aparecen en la sección 5. Estos requisitos de
calidad deben ser específicos, cuantitativos y verificables. Indique las prioridades relativas de varios
atributos, como la facilidad de uso sobre la facilidad de aprendizaje, o la seguridad sobre el rendimiento.
Una rica notación de especificaciones como Planguage aclara los niveles necesarios de cada calidad
PRELIMINARES
mucho mejor que las simples descripciones.
6.1. Usabilidad
Los requisitos de usabilidad se refieren a la facilidad de aprendizaje, la facilidad de uso, la evitación y

recuperación de errores, la eficiencia de las interacciones y la accesibilidad. Los requisitos de usabilidad
especificados aquí ayudarán al diseñador de interfaz de usuario a crear la experiencia óptima del usuario.
BIMESTRE
PRIMER
6.2. Rendimiento
Especifique los requisitos de rendimiento específicos para las distintas operaciones del sistema. Si
diferentes requerimientos funcionales o características tienen diferentes requisitos de rendimiento,
es apropiado especificar esos objetivos de rendimiento correctamente con los requisitos funcionales
SEGUNDO
BIMESTRE
correspondientes, en lugar de recopilarlos en esta sección.
6.3. Seguridad
Especifique cualquier requisito relacionado con cuestiones de seguridad o privacidad que restrinjan
SOLUCIONARIO
el acceso o uso del producto. Estos pueden referirse a la seguridad física, de datos o de software. Los
requisitos de seguridad a menudo se originan en las reglas de negocio, así que identifique las políticas
o regulaciones de seguridad o privacidad a las cuales el producto debe cumplir. Si están documentados
en un repositorio de reglas de negocio, solo refiérase a ellos.
6.4. Seguridad externa
BIBLIOGRÁFICAS
REFERENCIAS
Especifique los requisitos que se refieren a posibles pérdidas, daños o daños que pudieran resultar
del uso del producto. Definir las salvaguardias o acciones que deben tomarse, así como las acciones
potencialmente peligrosas que deben evitarse. Identifique las certificaciones de seguridad, políticas o
reglamentos a los cuales el producto debe cumplir.
6.x [Otros]
ANEXOS
Cree una sección separada en el ERS para cada atributo adicional de calidad del producto para describir
las características que serán importantes para los clientes o para los desarrolladores y mantenedores.
Las posibilidades incluyen disponibilidad, eficiencia, instalación, integridad, interoperabilidad,
modificabilidad, portabilidad, fiabilidad, reutilización, robustez, escalabilidad y verificabilidad.
7. Requisitos de internacionalización y localización
Los requisitos de internacionalización y localización aseguran que el producto sea adecuado para su uso
en naciones, culturas y ubicaciones geográficas distintas de aquellas en las que se creó. Esos requisitos
podrían abordar las diferencias de divisas; formato de fechas, números, direcciones y números de
teléfono; Idioma, incluyendo las convenciones nacionales de ortografía dentro del mismo idioma (como
el inglés americano versus inglés británico), los símbolos utilizados y los conjuntos de caracteres; Nombre
y apellido; zonas horarias; Reglamentos y leyes internacionales; Culturales y políticos; Tamaños de papel

utilizados; pesos y medidas; Voltajes eléctricos y formas de enchufe; y muchos otros. Los requisitos de
internacionalización y localización podrían ser reutilizables en todos los proyectos.
ÍNDICE
8. [Otros requisitos]
Defina cualquier otro requisito que no esté cubierto en otras partes del ERS. Ejemplos de ello son los
requisitos legales, reglamentarios o normativos; Requisitos para la instalación, configuración, puesta en
PRELIMINARES
marcha y cierre del producto; Y registros, monitoreo y auditoría. En lugar de simplemente combinar
todos estos en “Otro”, agregue cualquier nueva sección a la plantilla que sea pertinente
A su proyecto. Omita esta sección si todos sus requisitos se acomodan en otras secciones. Los requisitos
de transición que son necesarios para migrar de un sistema anterior a uno nuevo podrían incluirse aquí
si involucran software escrito (como para programas de conversión de datos), o en el plan de gestión de
proyecto si no lo hacen.
BIMESTRE
PRIMER
Apéndice A: Glosario
De todos los términos especializados que un lector necesita saber para entender el ERS, incluyendo
acrónimos y abreviaturas. Escriba cada acrónimo y proporcione su definición. Considere la posibilidad
de construir un glosario reutilizable a nivel de empresa que abarque múltiples proyectos e incorporando
SEGUNDO
BIMESTRE
por referencia cualquier término que pertenezca a este proyecto. Cada ERS sólo definiría los términos
específicos de un proyecto individual que no aparecen en el glosario de nivel empresarial. Tenga en
cuenta que las definiciones de datos pertenecen al diccionario de datos, no al glosario.
Apéndice B: Modelos de análisis
SOLUCIONARIO
Esta sección opcional incluye o apunta a modelos de análisis pertinentes, tales como diagramas de flujo
de datos, árboles de características, diagramas de transición de estado o diagramas entidad-relación.
A menudo, es más útil para el lector si incorpora ciertos modelos en las secciones pertinentes de la
especificación en lugar de recogerlos al final.
BIBLIOGRÁFICAS
REFERENCIAS
6.6. Características de excelentes requisitos
El mejor repositorio de requisitos en el mundo es inútil si no contiene información de alta calidad. Por lo
tanto, vamos a describir las características deseables de los requisitos y de los documentos de requisitos.
La mejor manera de saber si sus requisitos poseen los atributos deseados es que varios interesados los
ANEXOS
revisen. Diferentes actores identificarán diferentes tipos de problemas.
6.6.1. Características de las declaraciones de requisitos
En un mundo ideal, cada requisito de negocio, usuario, funcional y no funcional debe contar con las
cualidades descritas en las siguientes secciones.
• Completo
Cada requisito debe contener toda la información necesaria para que el lector la entienda. En el caso de
los requisitos funcionales, significa proporcionar la información que el desarrollador necesita para poder
implementarla correctamente. Si sabe que le falta cierta información, use TBD (a determinar) como un
indicador estándar para resaltar estas lagunas, o regístrelas en un sistema de seguimiento de problemas
para hacer un seguimiento. En adelante resolver todos los TBDs en cada parte de los requisitos antes de
que los desarrolladores continúen con la construcción de esa porción.

• Correcto
Cada requisito debe describir con precisión una capacidad que satisfaga la necesidad de algún interesado
ÍNDICE
y debe describir claramente la funcionalidad que se construirá. Usted tendrá que ir a la fuente del
requisito para comprobar su corrección. Éste podría ser un usuario que proporcionó el requisito inicial,
un requisito de sistema de nivel superior, un caso de uso, una regla de negocio u otro documento. Un
requisito de bajo nivel que entra en conflicto con su matriz no es correcto. Para evaluar la exactitud de
PRELIMINARES
los requisitos de los usuarios, los representantes de los usuarios o sus sustitutos deben revisarlos.
• Factible
Debe ser posible implementar cada requisito dentro de las capacidades y limitaciones conocidas del
sistema y su entorno operativo, así como dentro de las limitaciones de tiempo, presupuesto y personal
del proyecto. Un desarrollador que participa durante la obtención puede proporcionar una verificación
BIMESTRE
PRIMER
de la realidad de lo que se puede y no se puede hacer técnicamente y lo que se puede hacer sólo a
un costo excesivo o esfuerzo. Los enfoques de desarrollo incremental y los prototipos de prueba de
concepto son dos maneras de evaluar la factibilidad de los requisitos. Si un requerimiento necesita ser
cortado porque no es factible, entienda el impacto en la visión y alcance del proyecto.
• Necesario
SEGUNDO
BIMESTRE
Cada requisito debe describir una capacidad que proporcione al interesado el valor comercial por
anticipado, que diferencie el producto en el mercado o que se requiera para la conformidad con una
norma, política o norma externa. Cada requisito debe provenir de una fuente que tiene la autoridad
para proporcionar los requisitos. Trace los requisitos funcionales y no funcionales de nuevo a la entrada
SOLUCIONARIO
específica de voz del usuario, como un caso de uso o una historia de usuario. Usted debe ser capaz de
relacionar cada requisito con un objetivo de negocio que indica claramente por qué es necesario. Si
alguien pregunta por qué se incluye un requisito particular, debe haber una buena respuesta.
• Priorizado
BIBLIOGRÁFICAS
REFERENCIAS
Priorizar los requisitos de negocio según cuáles son los más importantes para alcanzar el valor deseado.
Asigne una prioridad de implementación a cada requisito funcional, requerimiento del usuario, caso de
uso o función para indicar cuán esencial es para un lanzamiento de producto en particular. Si todos los
requisitos son igualmente importantes, el director del proyecto no sabe cómo responder mejor a los
rebasamientos de planificaciones, las pérdidas de personal o los nuevos requisitos que se presentan. La
priorización de los requisitos debe ser una actividad de colaboración que abarque múltiples perspectivas
de los interesados. El capítulo 16, “Primero, primero: Establecer las prioridades de los requisitos”, analiza ANEXOS
la priorización con más detalle.
• No ambiguo
El lenguaje natural es propenso a dos tipos de ambigüedad. Un tipo que puedo verme, cuando puedo
pensar en más de una manera de interpretar un requisito dado. El otro tipo de ambigüedad es más difícil
de detectar. Eso es cuando diferentes personas leen el requisito y llegar a diferentes interpretaciones
de la misma. El requisito tiene sentido para cada uno de ellos, pero significa algo diferente a cada uno
de ellos. Las inspecciones son una buena manera de detectar las ambigüedades (Wiegers 2002). Una
revisión formal por pares, como una inspección (en lugar de simplemente distribuir los requisitos a las
personas a examinar por su cuenta) ofrece una oportunidad para cada participante para comparar su
comprensión de cada requisito a alguien más. “Comprensible” se relaciona con “inequívoco”: los lectores
deben entender lo que cada requisito está diciendo. El Capítulo 17 describe el proceso de revisión por
pares de software.

Nunca eliminarás toda la ambigüedad de los requisitos: esa es la naturaleza del lenguaje humano.
La mayoría de las veces, personas razonables pueden sacar las conclusiones correctas de incluso un
ÍNDICE
requisito ligeramente difuso. Obtener un poco de ayuda de sus colegas a través de revisiones se limpiará
un montón de los peores problemas, sin embargo.
• Verificable
PRELIMINARES
¿Puede un probador diseñar pruebas u otros métodos de verificación para determinar si cada requisito
se implementa correctamente? Si un requisito no es verificable, decidir si se implementó correctamente
se convierte en una cuestión de opinión, no en un análisis objetivo. Los requisitos que son incompletos,
inconsistentes, infalsificables o ambiguos tampoco son verificables. Los probadores son buenos para
examinar los requisitos de variabilidad. Incluya en sus requisitos revisiones de pares para detectar
problemas temprano.
BIMESTRE
PRIMER
6.6.2. Características de las colecciones de requisitos
No es suficiente tener excelentes declaraciones de requisitos individuales. Los conjuntos de requisitos

que se agrupan en una línea de base para una liberación o iteración específica deben presentar las
características descritas en las siguientes secciones, ya sea que estén registradas en un documento ERS,
una herramienta de gestión de requisitos, un conjunto de historias de usuario y pruebas de aceptación
SEGUNDO
BIMESTRE
o cualquier otra forma.
• Completo
Ningún requisito o información necesaria debe estar ausente. En la práctica, nunca documentará todos
SOLUCIONARIO
los requisitos de un sistema. Siempre hay algunos requisitos implícitos o asumidos, aunque tienen
más riesgo que los requisitos explícitamente establecidos. Los requisitos que faltan son difíciles de
detectar porque no están allí. La sección “Evitar la incompletitud” más adelante en este capítulo sugiere
algunas maneras de identificar los requisitos que faltan. Cualquier especificación que contenga TBDs es
incompleta.
BIBLIOGRÁFICAS
REFERENCIAS
• Consistente
Los requisitos consistentes no entran en conflicto con otros requisitos del mismo tipo o con requisitos de
negocio, de usuario o de sistema de nivel superior. Si no resuelven las contradicciones entre los requisitos
antes de bucear en la construcción, los desarrolladores tendrán que lidiar con ellos. Grabar el originador
de cada requisito le permite saber con quién hablar si descubre conflictos. Puede ser difícil detectar
ANEXOS
inconsistencias cuando la información relacionada se almacena en diferentes ubicaciones, como en un
documento de visión y alcance y en una herramienta de administración de requisitos.
• Modificable
Siempre puede reescribir un requisito, pero debe mantener un historial de cambios realizados en cada
requisito, especialmente después de que se basan. También necesita saber acerca de las conexiones y
dependencias entre los requisitos para que pueda encontrar todos los que deben cambiarse juntos. La
habilidad Modi dicta que cada requisito debe ser etiquetado de manera única y expresado por separado
de otros, de modo que pueda referirse a él sin ambigüedad. Consulte el Capítulo 10, “Documentación de
los requisitos”, para ver las distintas formas de etiquetar los requisitos.

• Trazable
Un requisito rastreable puede vincularse tanto a su origen como hacia adelante a requisitos derivados,
ÍNDICE
elementos de diseño, código que lo implementa y pruebas que verifican su implementación. Tenga en
cuenta que en realidad no tiene que definir todos estos vínculos de rastreo para un requisito de tener
las propiedades que lo hacen rastreable. Los requisitos rastreables están etiquetados únicamente con
identificadores persistentes. Se escriben de una manera estructurada, no en párrafos largos de la narrativa.
PRELIMINARES
Evite combinar varios requisitos juntos en una sola sentencia, ya que los diferentes requerimientos
podrían rastrearse a diferentes componentes de desarrollo.
6.7. Directrices para la redacción de requisitos
No existe una fórmula para escribir excelentes requisitos. Los mejores profesores son la experiencia y la
BIMESTRE
PRIMER
retroalimentación de los destinatarios de los requisitos. Recibir retroalimentación constructiva de colegas
con ojos agudos es una gran ayuda porque puede aprender donde hizo la escritura y no golpeó la marca.
Esta es la razón por la cual los exámenes por pares de los documentos de requisitos son tan críticos.
Para comenzar con las revisiones, compórtese con un analista de negocios y empiece a intercambiar
los requisitos para su revisión. Aprenderá al ver cómo otro analista de negocio escribe requisitos y
SEGUNDO
BIMESTRE
mejorará el trabajo colectivo del equipo descubriendo errores y oportunidades de mejora tan pronto
como sea posible. Las siguientes secciones proporcionan numerosos consejos para escribir requisitos-
particularmente requisitos funcionales- que los lectores pueden entender claramente. Muchos autores
presentan muchas otras recomendaciones y ejemplos para escribir buenos requisitos.
SOLUCIONARIO
Cuando decimos “ escritura de requisitos”, la gente inmediatamente piensa en escribir requisitos textuales
en lenguaje natural. Es mejor traducir mentalmente la frase “requisitos de escritura” a “representar el
conocimiento de requisitos”. En muchos casos, las técnicas de representación alternativas pueden
presentar información de manera más efectiva que el texto en línea recta. (Wigers, 2006) El BA debe
elegir una combinación adecuada de métodos de comunicación que asegure un entendimiento claro y
compartido de las necesidades de las partes interesadas y la solución a construir.
BIBLIOGRÁFICAS
REFERENCIAS
Los requisitos presentados aquí siempre se pueden mejorar, y siempre hay formas equivalentes de
expresarlos. Los dos objetivos importantes en la redacción de los requisitos son los siguientes:
• Cualquiera que lea el requisito llega a la misma interpretación que cualquier otro lector.
• La interpretación de cada lector coincide con lo que el autor pretendía comunicar. Estos resultados
son más importantes que la pureza de estilo o se adaptan dogmáticamente a alguna regla o
convención arbitraria. ANEXOS
6.7.1. Perspectiva del sistema o del usuario
Puede escribir requisitos funcionales desde la perspectiva de lo que hace el sistema o lo que el usuario
puede hacer. Debido a que la comunicación efectiva es la meta general, es necesario mezclar estos estilos,
expresando cada requisito en cualquier estilo que sea más claro. El estado de los requisitos de manera
consistente, como “El sistema deberá” o “El usuario deberá”, seguido de un verbo de acción, seguido por
el resultado observable. Especifique la acción o condición de activación que hace que el sistema realice
el comportamiento especificado. Una plantilla genérica para un requisito escrito desde la perspectiva
del sistema es:
[Precondición opcional] [evento de disparo opcional] el sistema [deberá responder al sistema].

Esta plantilla es del enfoque “Easy Approach to Requirements Syntax” (EARS). EARS también incluye
construcciones de plantillas adicionales para comportamientos indeseados, impulsados por el estado,
ÍNDICE
opcionales y complejos. A continuación, se muestra un ejemplo de un requisito funcional simple que
describe una acción del sistema que utiliza esta plantilla:
Si el producto químico solicitado se encuentra en el almacén de productos químicos, el sistema deberá

mostrar una lista de todos los contenedores del producto químico que se encuentran actualmente en
PRELIMINARES
el almacén.
Este ejemplo incluye una precondición, pero no un disparador. Algunos redactores de requisitos omitirían
la frase “el sistema deberá” de este requisito. Ellos argumentan que, debido a que los requerimientos están
describiendo el comportamiento del sistema, no hay necesidad de decir repetidamente que “el sistema”
hará esto o aquello. En este ejemplo, eliminar “el sistema debe” no es confuso. A veces, sin embargo, es
más natural expresar el requisito en términos de la acción de un usuario, no desde la perspectiva del
BIMESTRE
PRIMER
sistema. Incluir “deberá” y escribir en la voz activa para dejar claro qué entidad está tomando la acción
descrita.
Al escribir requisitos funcionales desde la perspectiva del usuario, la siguiente estructura general
funciona bien:
SEGUNDO
BIMESTRE
La [clase de usuario o nombre del actor] será capaz de [hacer algo] [a algún objeto] [condiciones de
calificación, tiempo de respuesta o declaración de calidad].
Fraseos alternativos son:
SOLUCIONARIO
“El sistema dejará (o permitirá, permitirá o habilitará) [un nombre de clase de usuario particular] a
[hacer algo]”.
A continuación, se muestra un ejemplo de requisito funcional escrito desde la perspectiva del usuario:
El Químico podrá reorganizar cualquier producto químico que haya ordenado en el pasado recuperando
BIBLIOGRÁFICAS
REFERENCIAS
y editando los detalles del pedido.
Observe cómo este requisito utiliza el nombre de la clase de usuario -Químico- en lugar del genérico
“usuario”. Hacer el requisito tan explícito como sea posible reduce la posibilidad de una interpretación
errónea.
6.7.2. Estilo de escritura

ANEXOS
La escritura de los requisitos no es como escribir ficción u otros tipos de no ficción. El estilo de escritura
que usted pudo haber aprendido en la escuela en el cual usted presenta la idea principal, luego los
hechos de apoyo, la conclusión, no trabaja bien. Ajuste su estilo de escritura para poner primero la línea
de fuerza “la declaración de la necesidad o funcionalidad” seguida de detalles de apoyo (justificación,
origen, prioridad y otros atributos de requisito). Esta estructura ayuda a los lectores que sólo están
examinando un documento, mientras que para aquellos lectores que necesitan todos los detalles, siga
siendo útil. Incluir tablas, listas estructuradas, diagramas y otros elementos visuales ayuda a romper una
letanía monótona de requisitos funcionales y proporciona una comunicación más rica a aquellos que
aprenden mejor de diferentes maneras.
Evite intercalar voz pasiva y activa en un intento de hacer el material más interesante de leer. No use
términos múltiples para el mismo concepto sólo para lograr variedad (cliente, cuenta, patrón, usuario,
invitado). Ser fácil de leer y comprender es un elemento esencial de los requisitos bien redactados; Ser

interesante es, francamente, menos importante. Si usted no es un escritor experto, usted debe esperar
que sus lectores pueden no entender lo que usted pretende transmitir.
ÍNDICE
Considere las siguientes sugerencias al elaborar las declaraciones de requisitos para obtener la máxima
eficacia de la comunicación.
1. Claridad y conciso:
PRELIMINARES
Escribir los requisitos en frases completas usando gramática, ortografía y puntuación apropiadas.
Mantenga frases y párrafos cortos y directos. Escribir los requisitos en un lenguaje sencillo y directo
adecuado al dominio del usuario, evitando la jerga. Definir los términos especializados en un glosario.
Otra buena pauta es escribir de forma concisa. Frases como “necesita proporcionar al usuario la capacidad
de” se puede condensar en “debe”. Para cada información de los requisitos, pregúntese: “¿Qué haría el
BIMESTRE
PRIMER
lector con esta información?” Si no está seguro de que algunos interesados encontrarían esa información
valiosa, tal vez no la necesite. Sin embargo, la claridad es más importante que la concisión.
Los requisitos precisos aumentan la probabilidad de que las personas reciban lo que esperan; Los
requisitos menos específicos ofrecen al desarrollador más argumentos para la interpretación. A veces
esa falta de especificidad está bien, pero en otros casos puede conducir a demasiada variabilidad en
SEGUNDO
BIMESTRE
el resultado. Si un desarrollador que revisa el ERS no está claro sobre la intención del cliente, considere
incluir información adicional para reducir el riesgo de problemas más adelante.
2. La palabra clave “debe”
SOLUCIONARIO
Una convención tradicional es usar la palabra clave “debe” para describir alguna capacidad del sistema.
La gente a veces se opone a la palabra “debe”. “No es así como la gente habla”, protestan. ¿Y qué? Las
declaraciones “Deberán” indicar claramente la funcionalidad deseada, de acuerdo con su objetivo general
de comunicación clara y efectiva. Es posible que prefiera decir “debe”, “necesita” o algo similar, pero sea
coherente. A veces leo especificaciones que contienen una mezcla aleatoria y confusa de verbos de
requisitos: puede, debe, puede, puede, va a, debería, podría, necesita, tiene que, debería proporcionar,
BIBLIOGRÁFICAS
REFERENCIAS
y otros. Nunca sé si hay diferencias entre los significados de estos o no. Los matices entre los diferentes
verbos también hacen que el documento sea mucho más difícil para los equipos interculturales de
interpretar de manera consistente. Es mejor que se pegue con una palabra clave como “debe”.
Algunos autores de requisitos deliberadamente utilizan diferentes verbos para implicar distinciones
sutiles. Ellos usan ciertas palabras clave para significar prioridad: “debe” significa requerido, “debería”
ANEXOS
significa deseado, y “puede” significa opcional. Consideramos que tales convenciones son peligrosas.
Es más claro siempre decir “debe” y asignar explícitamente prioridad alta, media o baja a cada requisito.
Además, las prioridades cambiarán a medida que progresen las iteraciones, por lo que no las vinculan
al enunciado de los requisitos. El “deber” de hoy podría convertirse en “debe” de mañana. Otros autores
usan “debe” para indicar un requisito y “voluntad” para designar una expectativa de diseño. Tales
convenciones corren el riesgo de que algunos lectores no entiendan las distinciones entre las palabras
que las personas usan indistintamente en la conversación cotidiana; Es mejor evitarlos.
3. Voz activa
Escriba en la voz activa para dejar claro qué entidad está tomando la acción descrita. Muchas escrituras
de negocios y científicas están en la voz pasiva, pero nunca es tan clara y directa como usar la voz activa.
El siguiente requisito está escrito en voz pasiva:

Tras el envío de la actualización del producto, el número de serie se actualizará en la línea del
contrato.
ÍNDICE
El fraseo “se actualizará” es indicativo de voz pasiva. Denota el destinatario de la acción (número de
serie) pero no el ejecutante de la acción. Es decir, este fraseo no ofrece ninguna pista sobre quién o qué
actualiza el número de serie. ¿El sistema lo hará automáticamente, o se espera que el usuario actualice el
número de serie? Reescribir este requisito en voz activa hace que el actor sea explícito y también aclara
PRELIMINARES
el evento desencadenante:
Cuando Fulfillment confirme que envió una actualización del producto, el sistema actualizará el
contrato del cliente con el nuevo número de serie del producto.
4. Requisitos individuales
BIMESTRE
PRIMER
Evite escribir párrafos narrativos largos que contengan múltiples requisitos. Los lectores no deben recoger
los requisitos individuales incrustados en una masa de lenguaje descriptivo libre. Distinguir claramente
los requisitos individuales de la información contextual o de fondo. Esa información es valiosa para los
lectores, pero necesitan reconocer inequívocamente las declaraciones de requisitos reales. Una vez
revisé una amplia especificación de requisitos escrita en forma de párrafos largos. Pude leer una página
completa y entenderlo, pero tuve que trabajar duro para seleccionar los requisitos discretos. Otros
SEGUNDO
BIMESTRE
lectores podrían llegar a conclusiones diferentes de exactamente qué requisitos estaban acechando en
esa masa de texto.
Palabras como “y”, “o”, “adicionalmente” o “también” en un requisito sugieren que varios requerimientos
podrían haber sido combinados. Esto no significa que usted no puede usar “y” en un requisito; Sólo
SOLUCIONARIO
asegúrese de que la conjunción está uniendo dos partes de un solo requisito en lugar de dos requisitos
separados. Si usas diferentes pruebas para verificar las dos partes, divide la oración en requisitos
separados.
Evite usar “y / o” en un requisito; Deja la interpretación al lector, como en este caso:
BIBLIOGRÁFICAS
REFERENCIAS
El sistema debe permitir la búsqueda por número de pedido, número de factura y / o número de
orden de compra del cliente.
Este requisito permitiría al usuario ingresar uno, dos o tres números a la vez al realizar una sola búsqueda.
Puede que no sea lo que se pretende.
Las palabras “a menos que”, “excepto” y “pero” también indican la presencia de requisitos múltiples:
ANEXOS
La tarjeta de crédito del comprador se cobrará por el pago, a menos que la tarjeta de crédito haya
expirado.
Si no se especifica qué sucede cuando la cláusula “a menos que” sea verdadera es una fuente común
de requisitos que faltan. Divida esto en dos requisitos para abordar el comportamiento de las dos
condiciones de la tarjeta de crédito que está activo y expiró:
Si la tarjeta de crédito del Comprador en el archivo está activa, el sistema cargará el pago a esa
tarjeta.
Si la tarjeta de crédito del Comprador ha caducado, el sistema permitirá al Comprador actualizar

la información de la tarjeta de crédito actual o introducir una nueva tarjeta de crédito para el pago.

6.7.3. Nivel de detalle
Los requisitos deben especificarse con un nivel de precisión que proporcione a los desarrolladores y
ÍNDICE
probadores la suficiente información para implementarlos correctamente.
1. Detalles apropiados
PRELIMINARES
Una parte importante del análisis de los requisitos es descomponer un requisito de alto nivel en
suficiente detalle para aclararlo y darle cuerpo. No hay una sola respuesta correcta a la pregunta común:
“¿Cuán detallados deben ser los requisitos?” Proporcione suficientes detalles para minimizar el riesgo
de malentendidos, basándose en el conocimiento y la experiencia del equipo de desarrollo. Si un
desarrollador puede pensar en varias formas posibles de satisfacer un requisito y todos son aceptables,
la especificidad y los detalles son correctos. De acuerdo Wiegers (2006) debe incluir más detalles cuando:
BIMESTRE
PRIMER
a. El trabajo se está haciendo para un cliente externo.
b. El desarrollo o las pruebas serán externalizados.
c. Los miembros del equipo del proyecto están geográficamente dispersos.
d. Las pruebas del sistema se basarán en los requisitos.
e. Se necesitan estimaciones exactas.
SEGUNDO
BIMESTRE
f. La trazabilidad de los requisitos es necesaria.
Es seguro incluir menos detalles cuando:
g. El trabajo se está haciendo internamente para su empresa.
SOLUCIONARIO
h. Los clientes están muy involucrados.
i. Los desarrolladores tienen experiencia considerable en el dominio.
j. Los precedentes están disponibles, como cuando se está reemplazando una aplicación
anterior.
k. Se utilizará una solución de paquete.
BIBLIOGRÁFICAS
REFERENCIAS
2. Granularidad consistente
Los autores de requisitos a menudo se esfuerzan por encontrar el nivel adecuado de granularidad para
escribir requisitos funcionales. No es necesario especificar todos sus requisitos al mismo nivel de detalle.
Por ejemplo, puede profundizar en un área que presenta mayor riesgo que otros. Sin embargo, dentro
de un conjunto de requisitos relacionados, es una buena idea tratar de escribir requisitos funcionales en
un nivel consistente de granularidad. ANEXOS
Una guía útil es escribir requisitos individualmente verificables. Incluso se ha propuesto el recuento de
requisitos de prueba como una métrica para el tamaño del producto de software. Si puede pensar en
un pequeño número de casos de prueba relacionados para verificar que un requisito se implementó
correctamente, es probable que en una granularidad adecuada. Si usted prevé numerosas y diversas
pruebas, tal vez varios requisitos se combinan y deben ser separados.
He visto declaraciones de requisitos en el mismo ERS que varían ampliamente en su alcance. Por ejemplo,
las dos funciones siguientes se dividieron como requisitos separados:
• El sistema interpretará la combinación de teclas Ctrl + S como Archivo Guardar.

• El sistema interpretará la combinación de teclas Ctrl + P como Archivo Imprimir.

Estos requisitos son muy finos. Necesitarán pocas pruebas para verificar el comportamiento correcto.
Se puede imaginar una lista tediosamente larga de requisitos similares, que sería mejor expresarse en
ÍNDICE
forma de una tabla que enumera todos los atajos de teclas y cómo el sistema los interpreta.
Sin embargo, ese mismo ERS también contenía un requisito funcional que parecía bastante amplio en
su alcance:
PRELIMINARES
El producto responderá a las instrucciones de edición introducidas por voz.
Este requisito único-aparentemente no más grande o más pequeño que todos los demás en el ERS-
estipuló la inclusión de un complejo subsistema de reconocimiento de voz-prácticamente un producto
completo. La verificación de este requisito en el sistema de trabajo podría requerir cientos de pruebas. El
requisito tal como se indica aquí podría ser apropiado en el alto nivel de abstracción que se encuentra en
un enunciado de visión o un documento de requisitos del mercado, pero el requisito de reconocimiento
BIMESTRE
PRIMER
de voz claramente exige mucho más detalle de funcionalidad.
SEGUNDO
BIMESTRE
Hemos finalizado el estudio de la unidad 6 y vamos a utilizar diferentes formas de documentar
los requisitos para ello se recomienda el desarrollo de las siguientes actividades:
•• Obtenga la plantilla para especificar requisitos de software, que utiliza RUP
SOLUCIONARIO
•• Desarrolle la documentación de los requisitos de acuerdo a la plantilla previamente obtenida.
•• Revise la plantilla que propone Volere para documentar los requisitos.
•• Busque en la web o en algún material impreso, la plantilla que utiliza RUP para documentar
los requisitos.
•• Ingrese al sitio de volere (http://www.volere.co.uk) y descargue la plantilla para especificar
BIBLIOGRÁFICAS
requisitos de software
REFERENCIAS
ANEXOS

Autoevaluación 6
ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
1. El documento que sirve como base para el diseño e implementación del sistema se lo conoce
como:
a. Carta de compromiso
b. Visionamiento
SEGUNDO
BIMESTRE
c. Especificación de Requerimientos de Software
2. El responsable directo de la elaboración del documento “Especificación de Requerimientos de

Software” es el:
SOLUCIONARIO
a. Analista
b. Cliente
c. Usuario
3. Una de las fuentes para elaborar el documento de requisitos de usuario es:
BIBLIOGRÁFICAS
REFERENCIAS
a. Plantilla de requerimientos
b. Base de datos
c. Visión del producto
4. Al documento que actúa entre puente entre la definición del negocio y los requerimientos de
software, se lo conoce como:
ANEXOS
a. Plantilla de requerimientos
b. Requerimientos de usuario
c. Visión del producto
5. Uno de los lectores del documento de requerimientos de usuario es el:
a. Patrocinador del proyecto

b. Programador
c. Diseñador de la base de datos

6. Cuando en el ERS todos los requisitos reflejan alguna necesidad real, entonces cumple con el
atributo de:
ÍNDICE
a. Clasificado
b. Correcto
c. No ambiguo
PRELIMINARES
7. Las convenciones de interfaz de usuario a seguir cuando se mejora un producto existente, se
describen en la ERS en la sección de:
a. Suposiciones y dependencias
b. Características del sistema
c. Restricciones de diseño e implementación
BIMESTRE
PRIMER
8. Las normas para las fuentes, iconos, etiquetas, imágenes, esquemas de color, secuencias de campo
de tabulación, entre otros; se describen en la sección de Requerimientos de interfaz externa, en la
parte de Interfaz de:
a. Hardware
SEGUNDO
BIMESTRE
b. Software
c. Usuario
9. Por lo general utilizar lenguaje natural en la especificación de requisitos conlleva a la ambigüedad.

Una forma de solventar sería:
SOLUCIONARIO
a. Gráficos o notaciones formales
b. Descripción de casos de uso
c. Visionamiento adecuado del problema
BIBLIOGRÁFICAS
10. “Cuando el profesor no registre la nota dentro del plazo establecido el sistema registrará la nota
REFERENCIAS
mínima establecida”, es un ejemplo de requerimiento:
a. Con restricción
b. Sin restricción
c. Con resultado observable
Estimado estudiante ANEXOS
Recuerde que el solucionario se encuentra al final del presente texto guía
Ir a solucionario

UNIDAD 7. VALIDANDO LOS REQUISITOS
ÍNDICE
Estimado estudiante
En esta unidad analizamos aquellas actividades que nos van a permitir validar los requisitos especificados
mediante el uso de técnica y estrategias que ayuden a determinar posibles errores en la definición de los
PRELIMINARES
requisitos. Es una actividad que muchas de las personas no le dan la importancia del caso, sim embargo
para garantizar la especificación es fundamental que se puedan hacer las validaciones necesarias. Como
se ha manifestado anteriormente, es mejor corregir los errores en los requisitos en las fases tempranas que
luego cuando ya están siendo implementados, pero aún, cuando está en funcionamiento la aplicación.
7.1. Necesidad de validación
BIMESTRE
PRIMER
La mayoría de los desarrolladores de software han experimentado la frustración de tener requisitos que
eran ambiguos o incompletos. Si no pueden obtener la información que necesitan, los desarrolladores
tienen que hacer sus propias interpretaciones, que no siempre son correctas. Como vimos en el Capítulo
1, cuesta mucho más corregir un error de requisito después de la implementación que corregir uno
SEGUNDO
BIMESTRE
encontrado durante el desarrollo de requisitos. Evidentemente, cualquier medida que pueda tomar para
detectar errores en las especificaciones de los requisitos ahorrará tiempo y dinero.
En muchos proyectos, la prueba es una actividad de última etapa. Los problemas relacionados con los
requisitos persisten en el producto hasta que finalmente se revelan a través de las pruebas del sistema que
SOLUCIONARIO
consumen mucho tiempo o, peor, por el usuario final. Si inicia su planificación de pruebas y desarrollo de
casos de prueba en paralelo con el desarrollo de requisitos, detectará muchos errores poco después de
su introducción. Esto les impide hacer más daño y minimiza sus costos de desarrollo y mantenimiento.
La Figura 36 ilustra el modelo V de desarrollo de software. Muestra las actividades de prueba que
comienzan en paralelo con las actividades de desarrollo correspondientes. Este modelo indica que las
BIBLIOGRÁFICAS
REFERENCIAS
pruebas de aceptación se derivan de los requisitos del usuario, las pruebas del sistema se basan en los
requisitos funcionales y las pruebas de integración se basan en la arquitectura del sistema. Este modelo
es aplicable si las actividades de desarrollo de software que se están probando son para el producto
como un todo, una liberación en particular o un solo incremento de desarrollo.
Como discutiremos más adelante en el capítulo, puede utilizar las pruebas para validar cada uno de
estos tipos de requisito durante el desarrollo de requisitos. En realidad, no puede ejecutar ninguna
prueba durante el desarrollo de requisitos porque todavía no tiene ningún software en ejecución. Sin ANEXOS
embargo, las pruebas conceptuales (es decir, independientes de la implementación) basadas en los
requisitos revelarán errores, ambigüedades y omisiones en sus requisitos y modelos antes de que el
equipo escriba cualquier código.

ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
Figura 36. El modelo V de desarrollo de software
Los participantes del proyecto a veces son reacios a pasar tiempo revisando y probando los requisitos.
Su intuición les dice que la inserción de tiempo en el calendario para mejorar la calidad de los requisitos
SOLUCIONARIO
retrasaría la fecha prevista de envío por esa misma duración. Sin embargo, esta expectativa supone un
retorno cero de su inversión en la validación de requisitos. En realidad, esa inversión puede acortar el
calendario de entrega reduciendo los retoques requeridos y acelerando la integración y las pruebas del
sistema. Mejores requisitos conducen a una mayor calidad del producto y satisfacción del cliente, lo que
reduce los costos de mantenimiento del producto, el mejoramiento y el soporte al cliente. Invertir en la
calidad de los requisitos generalmente le ahorra mucho más de lo que gasta.
BIBLIOGRÁFICAS
REFERENCIAS
Varias técnicas pueden ayudarle a evaluar la exactitud y calidad de las necesidades. Un enfoque
consiste en cuantificar cada requisito para que se pueda pensar en una forma de medir cuán bien la
solución propuesta lo satisface. Algunos autores usan el término criterios de ajuste para describir tales
cuantificaciones. Este capítulo aborda las técnicas de validación de las revisiones de requisitos formales
e informales, el desarrollo de pruebas a partir de los requisitos y el hecho de que los clientes definan sus
criterios de aceptación para el producto.
ANEXOS
7.2. Verificación y validación
La validación de requisitos es el cuarto componente del desarrollo de requisitos, junto con la obtención,
análisis y especificación. Algunos autores usan el término “verificación” para este paso. Sin embargo,
vamos a adoptar la terminología del Cuerpo de Conocimientos de Ingeniería de Software y referimos
este aspecto del desarrollo de requisitos como “validación”. (Alain, Moore, Bourque y Dupuis, 2004)
La verificación de los requisitos para asegurar que tengan todas las propiedades deseadas de requisitos
de alta calidad es también una actividad esencial. Precisamente, la validación y la verificación son
dos actividades diferentes en el desarrollo de software. La verificación determina si el producto con
las actividades de desarrollo cumple con sus requisitos (hacer lo correcto). La validación evalúa si un
producto satisface las necesidades del cliente (haciendo lo correcto).

ÍNDICE
PRELIMINARES
Al extender estas definiciones a los requisitos, la verificación determina si ha escrito correctamente los
requisitos: sus requisitos tienen las propiedades deseables. La validación de los requisitos evalúa si se
BIMESTRE
han escrito los requisitos adecuados: se remontan a los objetivos de negocio.
PRIMER
Estos dos conceptos están estrechamente entrelazados. Para simplificar en este capítulo, hablamos de
validar los requisitos, pero las técnicas que describimos contribuyen tanto a tener los requisitos correctos
como a tener requisitos de alta calidad.
SEGUNDO
BIMESTRE
La validación de los requisitos permite a los equipos construir una solución correcta que cumpla con los
objetivos de negocio establecidos. Las actividades de validación de requisitos intentan asegurar que:
• Los requisitos de software describen con precisión las capacidades y propiedades del sistema
pretendido que satisfarán las necesidades de las diversas partes interesadas.
SOLUCIONARIO
• Los requisitos de software se derivan correctamente de los requisitos empresariales, los requisitos
del sistema, las reglas empresariales y otras fuentes.
• Los requisitos son completos, factibles y verificables.
• Todos los requisitos son necesarios, y todo el conjunto es suficiente para cumplir con los objetivos
de negocio.
BIBLIOGRÁFICAS
• Todas las representaciones de los requisitos son consistentes entre sí.
REFERENCIAS
• Los requisitos proporcionan una base adecuada para proceder con el diseño y la construcción.
La validación no es una sola fase discreta que se realiza después de obtener y documentar todos los
requisitos. Algunas actividades de validación, tales como revisiones incrementales de los requisitos, están
adheridas a lo largo de los procesos iterativos de obtención, análisis y especificación. Otras actividades,
como las inspecciones formales, proporcionan una puerta de calidad antes de basar un conjunto de
requisitos. Incluya las actividades de validación de requisitos como tareas en su plan de proyecto. Por ANEXOS
supuesto, sólo se pueden validar los requisitos que se han documentado, no los requisitos implícitos que
sólo existen en la mente de alguien.
7.3. Revisión de los requisitos
En cualquier momento alguien que no sea el autor de un producto de trabajo examina el producto
para determinar problemas, se está llevando a cabo una revisión por pares. Revisar los requisitos es una
técnica poderosa para identificar requisitos ambiguos o no verificables, requisitos que no se definen
claramente para que comience el diseño y otros problemas.
Diferentes tipos de revisión por pares van por una variedad de nombres. Las revisiones informales son
útiles para educar a otras personas sobre el producto y recolectar retroalimentación no estructurada. Sin

embargo, no son sistemáticos, minuciosos o realizados de manera consistente. Los enfoques de revisión
informal incluyen:
ÍNDICE
• Un “peer deskcheck”, en el que se pide a un colega mirar por encima el producto de trabajo.
• Un “pasoound”, en el que se invita a varios colegas a examinar simultáneamente una entrega.
• Un “walkthrough”, durante el cual el autor describe una entrega y solicita comentarios sobre ella.
PRELIMINARES
Las revisiones informales son buenas para detectar errores, inconsistencias y lagunas. Pueden ayudarle
a localizar declaraciones que no cumplen con las características de los requisitos de alta calidad. Pero es
difícil para un revisor captar todos los requisitos ambiguos por su cuenta. Él podría leer un requisito y
pensar que lo entiende, pasando a la siguiente sin un segundo pensamiento. Otro revisor puede leer el
mismo requisito, llegar a una interpretación diferente, y tampoco pensar que hay un problema. Si estos
dos revisores nunca discuten el requisito, la ambigüedad pasará desapercibida hasta más adelante en
BIMESTRE
PRIMER
el proyecto.
Las evaluaciones formales por pares siguen un proceso bien definido. Una revisión de requisitos formales
produce un informe que identifica el material examinado, los revisores y el juicio del equipo de revisión
sobre si los requisitos son aceptables. El producto principal es un resumen de los defectos encontrados y
los problemas planteados durante la revisión. Los miembros de un equipo de revisión formal comparten
SEGUNDO
BIMESTRE
la responsabilidad por la calidad de la revisión, aunque en última instancia los autores son responsables
de la calidad de los resultados que crean.
El tipo mejor establecido de revisión formal de pares se llama inspección. La inspección de documentos
de requisitos es una de las técnicas de calidad de software de mayor apalancamiento disponibles. Varias
SOLUCIONARIO
compañías han evitado hasta 10 horas de trabajo por cada hora que invirtieron en la inspección de
documentos de requisitos y otros productos de software.
La inspección detallada de grandes conjuntos de requisitos es tediosa y consume mucho tiempo. Sin
embargo, los equipos que han adoptado inspecciones de requisitos están de acuerdo en que cada
minuto que pasan vale la pena. Si no tiene tiempo para inspeccionar todo, utilice el análisis de riesgos
BIBLIOGRÁFICAS
REFERENCIAS
para diferenciar los requisitos que exigen inspección de los menos críticos, menos complejos o menos
nuevos para los que será suficiente una revisión informal. Las inspecciones no son baratas. Ni siquiera
son tan divertidas. Pero son más baratos -y más divertidos- que la alternativa de gastar mucho esfuerzo
y los problemas de buena voluntad del cliente que se encuentran mucho después.
7.3.1. El proceso de Inspección
La inspección ha sido reconocida como una mejor práctica de la industria del software. Cualquier ANEXOS
producto de trabajo de software puede ser inspeccionado, incluyendo requisitos, documentos de
diseño, código fuente, documentación de prueba y planes de proyecto.
La inspección es un proceso bien definido y de múltiples etapas. Se trata de un pequeño equipo de

participantes que examinan cuidadosamente un producto de trabajo por defectos y oportunidades de
mejora. Las inspecciones sirven como una puerta de calidad a través de la cual las entregas del proyecto
deben realizarse antes de que se defina la línea base. Hay varias formas de inspección, pero cualquiera
de ellas es una técnica de gran calidad. La siguiente descripción se basa en la técnica de inspección de
Fagan.

1. Participantes
Asegúrese de tener todas las personas necesarias en una reunión de inspección antes de continuar. Los
ÍNDICE
participantes en una inspección deben representar cuatro perspectivas:
• El autor del producto de trabajo y quizás los compañeros del autor. El analista de negocios que
escribió el documento de requisitos proporciona esta perspectiva. Incluya otro analista de negocio
PRELIMINARES
experimentado si puede, porque sabrá del tipo de errores en los requisitos.
• Las personas que son las fuentes de información que alimentaron el elemento que se está
inspeccionando. Estos participantes podrían ser representantes de usuarios reales o el autor de
una especificación predecesora. En ausencia de una especificación de nivel superior, la inspección
debe incluir representantes de los clientes, tales como product-champions, para asegurar que los
requerimientos describen sus necesidades correctamente y completamente.
BIMESTRE
PRIMER
• Personas que harán el trabajo basado en el ítem que se está inspeccionando. Para un ERS,
puede incluir un desarrollador, un probador, un administrador de proyectos y un escritor de
documentación del usuario porque detectarán diferentes tipos de problemas. Un probador es más
probable para escoger un requisito no verificable; Un desarrollador puede detectar los requisitos
que son técnicamente imposibles.
SEGUNDO
BIMESTRE
• Las personas responsables de los sistemas de interfaz que se verán afectados por el elemento que
se está inspeccionando. Estos inspectores buscarán problemas con los requisitos de la interfaz
externa. También pueden detectar efectos de ondulación, en los que el cambio de un requisito en
el ERS que se está inspeccionando afecta a otros sistemas.
SOLUCIONARIO
Trate de limitar el equipo a siete o menos inspectores. Esto podría significar que algunas perspectivas no
estarán representadas en cada inspección. Los grandes equipos se enredan fácilmente en discusiones
paralelas, resolución de problemas y debates sobre si algo es realmente un error. Esto reduce la velocidad
a la que cubren el material durante la inspección y aumenta el costo de detectar cada defecto.
BIBLIOGRÁFICAS
REFERENCIAS
El director del autor normalmente no debe asistir a una reunión de inspección, a menos que este
contribuyendo activamente al proyecto y su presencia es aceptable para el autor. Una inspección eficaz
que revela muchos defectos podría crear una mala impresión del autor a un gerente hipercrítico. Además,
la presencia del gerente podría estimular la discusión de otros participantes.
Roles de la inspección
Todos los participantes en una inspección, incluyendo el autor, buscan defectos y oportunidades de ANEXOS
mejora. Algunos de los miembros del equipo de inspección desempeñan las siguientes funciones
específicas durante la inspección.
Autor
El autor crea o mantiene el producto de trabajo que está siendo inspeccionado. El autor de un documento
de requisitos suele ser el analista de negocios que obtuvo las necesidades del cliente y escribió los
requisitos. Durante las revisiones informales, tales como tutoriales, el autor a menudo lidera la discusión.
Sin embargo, el autor asume un papel más pasivo durante una inspección. El autor no debe asumir
ninguna de las otras funciones asignadas: moderador, lector o grabador. Al no tener un papel activo,
el autor puede escuchar los comentarios de otros inspectores. De esta manera el autor puede detectar
errores que otros inspectores no ven.

Moderador
El moderador planifica la inspección con el autor, coordina las actividades y facilita la reunión de inspección.
ÍNDICE
El moderador distribuye los materiales a inspeccionar, junto con cualquier documento predecesor
relevante, a los participantes unos días antes de la reunión de inspección. Las responsabilidades del
moderador incluyen iniciar la reunión a tiempo, alentar las contribuciones de todos los participantes
y mantener la reunión enfocada en detectar los principales defectos en lugar de resolver problemas o
PRELIMINARES
distraerse por problemas estilísticos menores y errores tipográficos. El moderador hace un seguimiento
de los cambios propuestos con el autor para asegurarse de que las cuestiones que salieron de la
inspección se abordaron adecuadamente.
Lector
Durante la reunión de inspección, el lector parafrasea los requisitos y los elementos del modelo que se
BIMESTRE
PRIMER
examinan uno a la vez. Los otros participantes señalan entonces los posibles defectos y problemas que
ven. Al establecer un requisito en sus propias palabras, el lector proporciona una interpretación que
puede diferir de la que poseen otros inspectores. Esta es una buena manera de revelar una ambigüedad,
un posible defecto, o una suposición. También subraya el valor de tener a alguien que no sea el autor
como lector. En los tipos menos formales de revisiones por pares, el papel del lector se omite, con el
SEGUNDO
BIMESTRE
moderador.
Grabador
El grabador usa formularios estándar para documentar los problemas planteados y los defectos
encontrados durante la reunión. El grabador debe revisar en voz alta o visualmente compartir lo que
SOLUCIONARIO
escribió para confirmar su exactitud. Los otros inspectores deben ayudar al grabador a captar la esencia
de cada asunto de una manera que comunique claramente al autor la ubicación y la naturaleza de la
cuestión para que pueda abordarla de manera eficiente y correcta.
2. Criterio de entrada
BIBLIOGRÁFICAS
REFERENCIAS
Está listo para inspeccionar un documento de requisitos cuando satisface requisitos previos específicos.
Estos criterios de entrada establecen algunas expectativas claras para los autores a seguir mientras se
prepara para una inspección. También mantienen al equipo de inspección de pasar tiempo en asuntos
que deben ser resueltos antes de la inspección. El moderador utiliza los criterios de entrada como una
lista de verificación antes de decidir continuar con la inspección. A continuación, se presentan algunos
criterios de entrada de inspección sugeridos para los documentos de requisitos:
ANEXOS
• El documento se ajusta a la plantilla estándar y no tiene problemas ortográficos, gramaticales o
de formato obvios.
• Los números de línea u otros identificadores únicos se imprimen en el documento para facilitar la
referencia a ubicaciones específicas.
• Todos los problemas abiertos están marcados como TBD (a determinar) o accesibles en una
herramienta de seguimiento de problemas.
• El moderador no presentó más de tres defectos mayores en un examen de diez minutos de una
muestra representativa del documento.

3. Etapas de la inspección
Una inspección es un proceso de varios pasos, como se ilustra en la Figura 37. Puede inspeccionar
ÍNDICE
pequeños conjuntos de requisitos a la vez, tal vez los asignados a una iteración de desarrollo específica,
cubriendo con ello la totalidad de la recolección de requisitos.
PRELIMINARES
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
Figura 37. Pasos del proceso de inspección
SOLUCIONARIO
Planificación
El autor y el moderador planifican la inspección juntos. Ellos determinan quién debe participar, qué
materiales los inspectores deben recibir antes de la reunión de inspección, el tiempo total de reunión
necesario para cubrir el material, y cuándo la inspección debe ser programada. El número de páginas
BIBLIOGRÁFICAS
revisadas por hora tiene un gran impacto en cuántos defectos se encuentran. Debido a que ningún
REFERENCIAS
equipo tiene tiempo disponible para inspecciones de requisitos, Una tasa de inspección adecuada
basada en el riesgo de pasar por alto los defectos mayores. Dos a cuatro páginas por hora es una guía
práctica, aunque la tasa óptima para la máxima eficacia de detección de defectos es aproximadamente
la mitad de esa tasa. Ajuste esta tasa basándose en los siguientes factores:
• Los datos de inspección anteriores del equipo, que muestran la efectividad de la inspección en
función de la tasa ANEXOS
• La cantidad de texto en cada página
• La complejidad de los requisitos
• La probabilidad y el impacto de tener errores sin ser detectados
• Qué tan crítico es el material que se está inspeccionando para el éxito del proyecto
• El nivel de experiencia de la persona que escribió los requisitos
Preparación
Antes de la reunión de inspección, el autor debe compartir información de antecedentes con los
inspectores para que entiendan el contexto de los elementos que se están inspeccionando y conocer
los objetivos del autor para la inspección. Cada inspector examina el producto para identificar posibles
defectos y problemas, utilizando la lista de verificación de los defectos de requisitos típicos u otras
técnicas de análisis. Hasta el 75 por ciento de los defectos encontrados por una inspección se descubren

durante la preparación, así que no omita este paso. Planee dedicar al menos la mitad de tiempo a la
preparación individual para las reuniones de inspección del equipo.
ÍNDICE
Reunión de inspección
Durante una reunión de inspección, el lector lleva a los otros inspectores a través del documento,
describiendo un requisito a la vez con sus propias palabras. A medida que los inspectores plantean
PRELIMINARES
posibles defectos y otros problemas, el grabador los captura en la lista de elementos de acción para
el autor de los requisitos. El propósito de la reunión es identificar tantos defectos importantes como
sea posible. La reunión de inspección no debe durar más de dos horas; Las personas cansadas no son
inspectores eficaces. Si necesita más tiempo para cubrir todo el material, programe reuniones adicionales.
Después de examinar todo el material, el equipo decide si acepta el documento de requisitos tal como
está, lo acepta con revisiones menores o indica que se necesita una revisión mayor. Un resultado de
BIMESTRE
PRIMER
la “revisión mayor necesaria” podría sugerir que el proceso de desarrollo de requisitos tiene algunas
deficiencias o que el analista de negocio que redactó los requisitos necesita capacitación adicional.
Considere la posibilidad de realizar una retrospectiva para explorar cómo se puede mejorar el proceso
antes de la siguiente actividad de especificación. Si se requieren revisiones importantes, el equipo puede
optar por reexaminar partes del producto que requieran una reelaboración extensa.
SEGUNDO
BIMESTRE
A veces, los inspectores sólo reportan problemas superficiales. Además, los inspectores se desvían
fácilmente a discutir si un problema es realmente un defecto, debatiendo cuestiones de alcance del
proyecto, y soluciones de lluvia de ideas a los problemas. Estas actividades pueden ser útiles, pero distraen
la atención del objetivo principal de encontrar defectos significativos y oportunidades de mejora.
SOLUCIONARIO
Rehacer
Casi todas las actividades de control de calidad revelan algunos defectos. El autor debe planear pasar
algún tiempo reelaborando los requisitos después de la reunión de inspección. Los defectos de requisito
no corregidos serán costosos, por lo que este es el momento de resolver las ambigüedades, eliminar la
BIBLIOGRÁFICAS
borrosidad y sentar las bases para un proyecto de desarrollo exitoso.
REFERENCIAS
Seguir
En este paso de inspección final, el moderador o un individuo designado trabaja con el autor para
asegurarse de que todos los problemas abiertos se resolvieron y que los errores se corrigieron
correctamente. El seguimiento lleva al cierre del proceso de inspección y permite al moderador
ANEXOS
determinar si los criterios de salida de la inspección han sido satisfactorios. El paso de seguimiento podría
revelar que algunas de las modificaciones hechas fueron incompletas o no se realizaron correctamente,
lo que condujo a una reelaboración adicional.
4. Criterio de salida
El proceso de inspección debe definir los criterios de salida que deben ser satisfechos antes de que el
moderador declare completo el proceso de inspección (no sólo la reunión). Estos son algunos posibles
criterios de salida para las inspecciones de requisitos:
• Todas las cuestiones planteadas durante la inspección se han abordado.

• Cualquier cambio realizado en los requisitos y productos de trabajo relacionados se realizó
correctamente.
• Se han resuelto todos los problemas abiertos o se ha documentado el proceso de resolución de
cada problema abierto, la fecha de destino y el propietario.

7.3.2. Lista de verificación de defectos
Para ayudar a los revisores a buscar errores típicos en los productos que revisan, es necesario elaborar
ÍNDICE
una lista de verificación de defectos para cada tipo de documento de requisitos que sus proyectos
crean. Dichas listas de verificación llaman la atención de los revisores con los problemas frecuentes de
los requisitos históricos. Las listas de verificación sirven como recordatorios. Con el tiempo, las personas
internalizar los elementos y buscan los temas adecuados en cada revisión.
PRELIMINARES
La figura 38 ilustra una lista de verificación de revisión de requisitos. Si crea representaciones o modelos
de requisitos particulares, puede ampliar los elementos de la lista de comprobación para que sean
más exhaustivos. Los requisitos de negocio, como un documento de visión y alcance, podrían justificar
su propia lista de verificación. En el artículo de Hoffman y Burgess (2009) proporcionan varias listas
detalladas de revisión, incluyendo una para validar los requisitos de software en función de los requisitos
del negocio.
BIMESTRE
PRIMER
Nadie puede recordar todos los elementos de una larga lista. Si hay más de seis u ocho elementos en la
lista, un revisor probablemente tendrá que hacer varias pasadas a través del material para buscar todo
en la lista; La mayoría de los críticos no se molestan. Pare las listas para satisfacer las necesidades de su
organización y modifique los elementos para que reflejen los problemas que la gente encuentra con
SEGUNDO
BIMESTRE
más frecuencia con sus propios requisitos. Algunos estudios han demostrado que dar a los revisores
responsabilidades específicas de detección de defectos -proveer procesos de pensamiento estructurados
o escenarios para ayudarlos a buscar tipos particulares de errores- es más efectivo que simplemente
entregar a todos los revisores la misma lista de verificación y esperar lo mejor.
SOLUCIONARIO
En el anexo 4 existe una lista de verificación que permite validar la especificación de requisitos de
software propuesto por Gottesdiener (2005).
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS
Figura 38. Lista de verificación de defectos para revisar los documentos de requisitos

7.4. Prototipos
ÍNDICE
Es difícil visualizar cómo un sistema funcionará bajo circunstancias específicas simplemente leyendo
los requisitos. Los prototipos son herramientas de validación que hacen que los requisitos sean reales.
Permiten al usuario experimentar algunos aspectos de lo que sería un sistema basado en los requisitos.
Los prototipos pueden ayudar a los interesados a juzgar si un producto construido está de acuerdo
con los requisitos y si satisfacen sus necesidades, además si los requisitos son completos, factibles y
PRELIMINARES
claramente comunicados.
Todo tipo de prototipos le permiten encontrar los requisitos que faltan antes de realizar actividades
más costosas como el desarrollo y las pruebas. Algo tan simple como una maqueta de papel se puede
utilizar para caminar a través de casos de uso, procesos o funciones para detectar cualquier requisito
omitido o erróneo. Los prototipos también ayudan a que las partes interesadas tengan una comprensión
BIMESTRE
PRIMER
compartida de los requisitos. Alguien podría implementar un prototipo basado en su comprensión de
los requisitos, sólo para saber que un requisito no estaba claro cuando los evaluadores de prototipo no
están de acuerdo con su interpretación.
Los prototipos de prueba de concepto pueden demostrar que los requisitos son factibles. Prototipos
evolutivos permiten a los usuarios ver cómo funcionan los requisitos cuando se implementan, para
SEGUNDO
BIMESTRE
validar que el resultado es lo que esperan. Niveles adicionales de sofisticación en prototipos, como
simulaciones, permiten una validación más precisa de los requisitos; Sin embargo, la construcción de
prototipos más sofisticados también tomará más tiempo. De acuerdo a Gottesdiener (2005), existen tres
tipos de prototipos:
SOLUCIONARIO
• Prototipo de la interfaz del usuario:
Es un modelo evolutivo de cómo va quedando la interfaz del usuario en base a los requisitos o necesidades
planteadas. Puede ser desarrollado en papel, ejecutable del sistema o proyecto en desarrollo o software
específico que se las encuentra libremente en el mercado.
BIBLIOGRÁFICAS
REFERENCIAS
• Prototipos de rendimiento:
Estos no incluyen la interfaz del usuario. Va orientado a los desarrolladores, con el fin de comprobar la
funcionalidad de los componentes de la solución que se está desarrollando. No se aplica a la Ingeniería
de Requisitos.
• Prototipo funcional:
ANEXOS
Es una versión limitada de la solución desarrollada. No se aplica a la Ingeniería de Requisitos.
El proceso para desarrollar las pruebas mediante prototipos, consiste en:
1. Determine qué requisitos validar utilizando prototipos.
üü Elija los requisitos que representan mayor riesgo (como es: requisitos que no pueden
ser factibles, reglas de negocio complejas, o algoritmos) o necesidades que representan
requisitos de usabilidad crítica. Escoja casos de uso o escenarios de prioridad alta que
permitan validar la usabilidad de los requisitos.
üü Asegúrese que los requisitos elegidos son bien entendidos

2. Desarrolle el prototipo
• Decida entre desarrollar un prototipo desechable o evolutivo (Un prototipo desechable
ÍNDICE
es fácil y rápido de construir, pero al final se desecha. Un prototipo evolutivo requiere
habilidades de desarrollo y más esfuerzo, pero podría involucrar un entregable del producto).
• Usar datos reales y escenarios definidos por el usuario
PRELIMINARES
• Construir el prototipo de forma iterativa (por ejemplo, desarrollar un pequeño prototipo
para empezar a evaluarlo con el usuario, revisarlo como sea necesario antes de seguir
adicionando funcionalidades).
3. Evalúe el prototipo
BIMESTRE
PRIMER
• Identificar los usuarios para la prueba del prototipo. Asegurar con claridad el propósito del
prototipo con el usuario antes de empezar.
• Dirigir una demostración. Para prototipos de interfaz de usuario que los usuarios intenten
usar el prototipo. Pídale que usen escenarios o tareas para guiar sus pruebas.
SEGUNDO
BIMESTRE
• Haga preguntas preparadas tales como: “¿Tiene sentido este siguiente paso?”, “¿El tiempo
de respuesta es suficiente?”, “¿Qué te detiene?”, “¿Los mensajes tienen sentido?”, etc.
• Ejecute una prueba de la parte de construcción del sistema para prototipos que impliquen
un intercambio de señales o datos entre componentes de software o hardware, para probar
SOLUCIONARIO
el rendimiento o un algoritmo complejo.
• Registre los problemas que surjan durante la evaluación. Revise la documentación de

requisitos y prototipos para realizar los cambios necesarios.
7.5. Probando los requisitos
BIBLIOGRÁFICAS
REFERENCIAS
Las pruebas basadas en los requisitos funcionales o derivados de los requisitos del usuario ayudan a
que los comportamientos esperados del sistema sean tangibles para los participantes del proyecto. El
simple hecho de diseñar pruebas revelará muchos problemas con los requisitos mucho antes de que
pueda ejecutar esas pruebas en el software en ejecución. La escritura de pruebas funcionales cristaliza
su visión de cómo el sistema debe comportarse bajo ciertas condiciones. Los requisitos imprecisos y
ambiguos saltarán porque no podrás describir la respuesta esperada del sistema. Cuando los analistas ANEXOS
de negocio, los desarrolladores y los clientes pasen por las pruebas, lograrán una visión compartida de
cómo funcionará el producto y aumentarán su confianza en que los requisitos son correctos. Las pruebas
son una herramienta poderosa para validar y verificar los requisitos.
Puede comenzar a obtener pruebas conceptuales de los requisitos del usuario a principios del proceso
de desarrollo. Utilice las pruebas para evaluar requisitos funcionales, modelos de análisis y prototipos.
Las pruebas deben cubrir el flujo normal de cada caso de uso, flujos alternativos y las excepciones que
identificó durante la obtención y el análisis. Del mismo modo, si identificó flujos de procesos de negocio,
las pruebas deberían cubrir los pasos del proceso de negocio y todas las rutas de decisión posibles.
Estas pruebas conceptuales son independientes de la implementación. Por ejemplo, considere un caso
de uso llamado “Visualizar una orden almacenada” para el Sistema de Seguimiento Químico. Algunas
pruebas conceptuales son:

• El usuario introduce el número de pedido para ver, el pedido existe, el usuario ha realizado el
pedido. Resultado esperado: mostrar los detalles de la orden.
ÍNDICE
• El usuario introduce el número de pedido para ver, el pedido no existe. Resultado esperado:
Mostrar mensaje “Lo siento, no puedo encontrar esa orden.”
• El usuario introduce el número de pedido para ver, el pedido existe, el usuario no ha realizado el
PRELIMINARES
pedido. Resultado esperado: Mostrar mensaje “Lo siento, no es tu pedido.
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
Figura 39. Desarrollo y pruebas de los productos de trabajo se derivan de una fuente común
Idealmente, un analista de negocio escribirá los requisitos funcionales y un probador escribirá las
pruebas desde un punto de partida común: los requisitos del usuario, como se muestra en la figura
BIBLIOGRÁFICAS
REFERENCIAS
39. Las ambigüedades en los requisitos de los usuarios y las diferencias de interpretación darán lugar
a inconsistencias entre las opiniones representadas por los requisitos funcionales, los modelos y las
pruebas. A medida que los desarrolladores traducen los requisitos en interfaz de usuario y diseños
técnicos, los probadores pueden elaborar las pruebas conceptuales en procedimientos de prueba
detallados.
7.6. Validación de requisitos con criterios de aceptación ANEXOS
Los desarrolladores de software pueden creer que han construido el producto perfecto, pero el
cliente es el árbitro final. Los clientes deben evaluar si un sistema satisface sus criterios de aceptación
preestablecidos. Los criterios de aceptación -y, por lo tanto, las pruebas de aceptación- deben evaluar si
el producto satisface sus requisitos documentados y si se debe utilizar en el entorno operativo previsto.
Tener usuarios que diseñen pruebas de aceptación es una valiosa contribución para el desarrollo de
requisitos eficaces. Cuanto antes se escriban las pruebas de aceptación, más pronto podrán ayudar al
equipo a detectar defectos en los requisitos y, en última instancia, en el software implementado.
7.6.1. Criterios de aceptación
Trabajar con clientes para desarrollar criterios de aceptación proporciona una manera de validar tanto
los requisitos como la propia solución. Si un cliente no puede expresar cómo evaluaría la satisfacción del

sistema de un requisito particular, ese requisito no es suficientemente claro. Los criterios de aceptación
definen las condiciones mínimas para que una solicitud sea considerada lista para la empresa.
ÍNDICE
Pensar en los criterios de aceptación ofrece un cambio de perspectiva desde la pregunta “¿Qué necesita
hacer con el sistema?” a “¿Cómo juzgaría si la solución satisface sus necesidades?” Anime a los usuarios
a usar el SMART mnemónico -Específico, Mensurables, Alcanzables, Relevantes y Sensibles al tiempo- al
definir criterios de aceptación. Los criterios deben especificarse de tal manera que múltiples observadores
PRELIMINARES
objetivos lleguen a la misma conclusión acerca de si están satisfechos.
Los criterios de aceptación mantienen el enfoque en los objetivos empresariales de los interesados y las
condiciones que permitirían al patrocinador del proyecto declarar la victoria. Esto es más importante
que simplemente cumplir con una especificación de requisitos que podría no resolver realmente los
problemas de los negocios de los interesados.
BIMESTRE
PRIMER
Definir criterios de aceptación es algo más que decir que todos los requisitos se implementan o que
todas las pruebas pasan. Las pruebas de aceptación constituyen sólo un subconjunto de criterios de
aceptación. Los criterios de aceptación también podrían abarcar dimensiones como las siguientes:
• Funcionalidad específica de alta prioridad que debe estar presente y operar correctamente antes
de que el producto pueda ser aceptado y utilizado. (Otra funcionalidad planificada podría ser
SEGUNDO
BIMESTRE
entregada más tarde, o las capacidades que no están funcionando bien podrían ser arregladas sin
retrasar una versión inicial).
• Criterios esenciales no funcionales o métricas de calidad que deben cumplirse. (Algunos atributos
de calidad deben ser por lo menos mínimamente satisfechos, aunque se podrían diferir las mejoras
SOLUCIONARIO
de la usabilidad y el ajuste de rendimiento. El producto podría tener que cumplir con métricas de
calidad tales como una duración mínima de uso operativo sin experimentar un fallo.
• Problemas abiertos restantes y defectos. (Podría estipular que ningún defecto que exceda un
determinado nivel de severidad permanezca abierto en contra de los requisitos de alta prioridad,
BIBLIOGRÁFICAS
aunque todavía podrían estar presentes errores menores).
REFERENCIAS
• Condiciones legales, reglamentarias o contractuales específicas. (Estos deben estar completamente
satisfechos antes de que el producto se considere aceptable.)
• Apoyo a la transición, la infraestructura u otros requisitos del proyecto (no del producto). (Tal
vez los materiales de capacitación deben estar disponibles y las conversiones de datos deben
ANEXOS
completarse antes de que se pueda liberar la solución).
También puede ser valioso pensar en “criterios de rechazo”, condiciones o resultados de evaluación
que llevaría a un interesado a considerar que el sistema aún no está listo para ser entregado. Tenga
cuidado con los criterios de aceptación de acuerdo, de tal manera que encontrar uno podría bloquear
la satisfacción de otro, de hecho, la búsqueda temprana de criterios de aceptación es una forma de
descubrir requisitos contradictorios.
Los proyectos ágiles crean criterios de aceptación basados en historias de usuarios. Los criterios de
aceptación no son funcionales o pruebas unitarias; Más bien, son las condiciones de satisfacción que se
colocan en el sistema. Las pruebas funcionales y de unidad van mucho más profundamente al probar
todos los flujos funcionales, flujos de excepción, condiciones de contorno y funcionalidad relacionada
asociada con la historia.

En principio, si se cumplen todos los criterios de aceptación de una historia de usuario, el propietario
del producto aceptará la historia de usuario como completada. Por lo tanto, los clientes deben ser muy
ÍNDICE
específicos en la escritura de los criterios de aceptación que son importantes para ellos.
En Gottesdiener (2005), se indica los pasos a seguir para hacer las pruebas, las mismas que constan de:
• Defina los criterios de aceptación para el sistema
PRELIMINARES
a. Identifique la funcionalidad, atributos de calidad y datos correctos necesarios para que los
clientes acepten el sistema.
b. Pregunte a los usuarios “¿Cómo juzgará si el sistema satisface sus necesidades?”
• Defina los casos de prueba de aceptación
BIMESTRE
PRIMER
§§ Los casos de prueba son los datos de entrada y los resultados esperados. Cada criterio
de aceptación podría tener uno o más casos de prueba. Los escenarios creaos durante el
modelado de análisis son buenas fuentes para los casos de prueba.
• Determine los métodos de prueba de aceptación
SEGUNDO
BIMESTRE
§§ Considere utilizar métodos de pruebas comunes, como los que se indica en la siguiente
tabla.
Tabla 14.
Métodos de prueba de aceptación
SOLUCIONARIO
Método Explicación
Casos de prueba escritos en papel y recorrer manualmente a través de los
Pruebas manuales
pasos utilizando los modelos de análisis
Herramientas de pruebas con Herramientas que ejecutan el sistema mientras graban las acciones del usuario
Interfaz Gráfica de Usuario y el sistema responde
BIBLIOGRÁFICAS
REFERENCIAS
El código escrito por los desarrolladores para ejecutar una prueba, a menudo
Código y prueba ayudado con un marco de pruebas que ayudan a manejar la ejecución de una
o más pruebas
Forma simplificada de código escrito pro desarrolladores o usuarios, que
Secuencia de comandos
utilizan una notación específica
Hoja de cálculo creada con el valor de datos en columnas, con una columna
Hoja de cálculo
ANEXOS
adicional para resultados esperados
Plantilla Una combinación de secuencia comandos y hoja de cálculo
• Valide los modelos de análisis utilizando las pruebas de aceptación de usuario.
§§ Los fallos en las pruebas de aceptación pueden tener diferentes niveles de severidad, tal
como se indica en el ejemplo que se indica a continuación.
Tabla 15.
Criterios de severidad
Nivel de
Definición
severidad
1 •• Crítico: Es imposible continuar con las pruebas o aceptar el sistema a causa de este error.

Nivel de
Definición
severidad
ÍNDICE
2 •• Alto: Las pruebas pueden continuar, pero el sistema no se puede implementar con este problema.
•• Mediano: Las pruebas pueden continuar y el sistema es probable que se siga desarrollado con
3
algunas salidas de funcionalidad del negocio acordados.
•• Mínimo: Las pruebas y el despliegue pueden progresar. El problema debería ser corregido, pero
4
PRELIMINARES
no afectará la funcionalidad de negocio.
•• Visual: Los errores como colores, fuentes, y las demostraciones de interfaz que son menos que
5
deseables pueden ser corregidos en algún futuro tiempo.
7.6.2. Prueba de aceptación
Las pruebas de aceptación constituyen la mayor parte de los criterios de aceptación. Los creadores
BIMESTRE
PRIMER
de pruebas de aceptación deben considerar los escenarios de uso más comúnmente realizados y los
más importantes al decidir cómo evaluar la aceptabilidad del software. Centrarse en probar los flujos
normales de los casos de uso y sus correspondientes excepciones, dedicando menos atención a los
flujos alternativos menos utilizados.
SEGUNDO
Los enfoques de desarrollo ágil suelen crear pruebas de aceptación en lugar de escribir requisitos
BIMESTRE
funcionales precisos. Cada prueba describe cómo debe funcionar una historia de usuario en el software
ejecutable. Debido a que están reemplazando en gran medida los requisitos detallados, las pruebas de
aceptación en un proyecto ágil deben cubrir todos los escenarios de éxito y fracaso. (Leffingwell, 2011)
SOLUCIONARIO
El valor en las pruebas de aceptación escritas es que guía a los usuarios a pensar en cómo se comportará
el sistema después de su implementación. El problema de escribir sólo pruebas de aceptación es que los
requisitos sólo existen en la mente de la gente.
Al no documentar y comparar vistas alternativas de requisitos -requisitos de usuario, requisitos

funcionales, modelos de análisis y pruebas-, puede perder la oportunidad de identificar errores,
BIBLIOGRÁFICAS
inconsistencias y lagunas.
REFERENCIAS
Estimado estudiante. ANEXOS

Hemos finalizado el estudio de la unidad 7 y es necesario que profundice loas conocimientos en
las actividades de validación de requisitos, para ello se recomienda el desarrollo de las siguientes
actividades:
•• Realice un mapa conceptual que indique los pasos para realizar el proceso de validación de
requisitos.
•• Diseñe un plan para realizar inspección mediante prototipos.
•• Revise detenidamente el tema 7.3.1 y extraiga las actividades que son fundamentales en el
proceso, luego utilizando una herramienta grafique el proceso (puede utilizar herramientas
de modelado)
•• En base al ERS y caso de uso desarrollado en las actividades de las unidades anteriores
proponga un prototipo de usuario que permita validar los requisitos.

Autoevaluación 7
ÍNDICE
PRELIMINARES
Lea detenidamente cada una de las preguntas y seleccione la alternativa correcta según corresponda
BIMESTRE
PRIMER
1. Al proceso de comprobar que los requisitos fueron especificados de acuerdo a las necesidades de
los clientes, se conoce como:
a. Especificación
b. Análisis
SEGUNDO
BIMESTRE
c. Validación
2. Las etapas de validación de requisitos consisten en:
a. Planificar la validación y Validar los requerimientos
SOLUCIONARIO
b. Seleccionar e integrar la técnica, Asegurar la participación del usuario, Validar los
requerimientos y Revisar la documentación de requerimientos.
c. Documentar los casos de prueba y Elaborar el plan de pruebas
3. La participación adecuada del usuario en la etapa de validación de requerimientos requiere que:
BIBLIOGRÁFICAS
REFERENCIAS
a. Se definan los interesados
b. Se clasifique a los interesados
c. Los interesados deben revisar la documentación para asegurarse que los requisitos están
completos, completos y sean de calidad
4. El costo de corregir un error en las etapas finales es de:

ANEXOS
a. 1 a 5 veces.
b. 10 a 100 veces.
c. 95 a 100 veces.
5. Cuando se requiere revisar y documentar los requerimientos se debe realizar:
a. Revisión de pares
b. Crear pruebas de validación
c. Mostrar partes del sistema

6. Cuando se requiere validar los modelos, se debe:
a. Realizar pruebas sobre modelos de requerimientos.
ÍNDICE
b. Revisión de pares.
c. Mostrar partes del sistema.
7. La revisión de requisitos lo realiza:
PRELIMINARES
a. Un grupo de personas que lee, analiza y discute el documento de especificación de
requisitos.
b. Un proceso automatizado con la ayuda del analista.
c. El equipo de desarrolladores (programadores).
BIMESTRE
PRIMER
8. Cuando se requiere realizar prototipos operacionales, se debe:
a. Realizar pruebas sobre modelos de requerimientos.

b. Revisión de pares.
c. Mostrar partes del sistema.
SEGUNDO
BIMESTRE
9. Cuando existen errores en cuanto a colores, fuentes y las demostraciones de interfaz que son
menos que deseables pueden ser corregidos en algún tiempo futuro, se refiere a un nivel de
severidad:
a. Visual.
SOLUCIONARIO
b. Análisis.
c. Herramienta.
10. Se utilizan simulaciones de pruebas en lugar de casos de prueba real para pasar por múltiples
modelos de análisis. Esto se denomina:
BIBLIOGRÁFICAS
REFERENCIAS
a. Modelos de validación.
b. Prototipos operacionales.
c. Prototipos visuales.
Recuerde que el solucionario se encuentra al final del presente texto guía ANEXOS
Ir a solucionario

UNIDAD 8. GESTIÓN DE REQUISITOS
ÍNDICE
Estimado estudiante
En la presente unidad analizaremos las actividades relacionadas con la gestión de requisitos, ya que
cuando se desarrollan proyectos de software es frustrante ver como las personas pierden el tiempo
PRELIMINARES
trabajando a partir de especificaciones de requisitos obsoletas o inconsistentes. Los diferentes artefactos
que se obtienen a partir de las distintas actividades de desarrollo de requisitos tienen que estar bien
administrados y comunicarse efectivamente entre los participantes del proyecto. El control de versiones
de requisitos individuales y conjuntos de requisitos es una de las actividades básicas de la gestión de
requisitos.
BIMESTRE
PRIMER
8.1. El proceso de gestión de requisitos
La gestión de requisitos es el proceso de monitorear el estado de los requisitos y controlar los cambios
a la línea base de los requisitos, incluye todas las actividades que permiten mantener la integridad,
exactitud y coherencia de los acuerdos de requisitos a lo largo del proyecto.
SEGUNDO
BIMESTRE
Gestión de
requisitos
SOLUCIONARIO
Seguimiento al estatus Seguimiento a los
BIBLIOGRÁFICAS
Control de versión Control de cambio
REFERENCIAS
de los requisitos requisitos
• Definición de un • Proponer cambios • Definir posibles • Definir las relaciones

esquema de • Análisis de impacto estados de los a otros requisitos
identificación de • Tomar decisiones requisitos • Definir las relaciones
versión • Actualizar requisitos • Guardar el estatus de a otros elementos del
• Seguimiento individuales cada requisito sistema
individual de la • Actualizar el conjunto • Seguimiento de la
ANEXOS
versión de requisitos de requisitos distribución del
• Versión de • Actualizar el plan estatus de todos los
seguimiento del • Asegurar requisitos requisitos
conjunto de volátiles
requisitos
Figura 40. Principales actividades de la gestión de requisitos

En la figura 40 se muestra las actividades principales de la gestión de requisitos en cuatro categorías

principales: control de versiones, control de cambios, seguimiento de estado de requerimientos y rastreo
de requerimientos.
La organización debe definir las actividades que los equipos de proyecto deben realizar para administrar
sus necesidades. Documentar estas actividades y capacitar a los profesionales en su desempeño permite

a los miembros de la organización llevarlos a cabo de manera consistente y efectiva. Considere la

posibilidad de abordar los siguientes temas:
ÍNDICE
• Herramientas, técnicas y convenciones para distinguir versiones de requisitos individuales y
conjuntos de requisitos
• La forma en que los conjuntos de requisitos se aprueban y se define su línea base
• Las formas en que se proponen, se evalúan, negocian y se comunican nuevos requisitos y cambios
PRELIMINARES
a los ya existentes
• Cómo evaluar el impacto de un cambio propuesto
• Atributos de requisitos y procedimientos de seguimiento de estado de los requisitos, incluidos los
estados de requisito que va a utilizar y quién puede cambiarlos
• ¿Quién es responsable de actualizar la información de seguimiento de los requisitos y cuándo?
BIMESTRE
PRIMER
• Cómo rastrear y resolver problemas de requisitos
• Cómo los planes y compromisos del proyecto reflejarán cambios en los requisitos
• Cómo utilizar eficazmente la herramienta de gestión de requisitos
Puede incluir toda esta información en una única descripción del proceso de gestión de requisitos.
Como alternativa, es posible que prefiera escribir controles de versiones, controles de cambios, análisis
SEGUNDO
BIMESTRE
de impacto y procedimientos de seguimiento del estado. Estos procedimientos deben aplicarse en toda
la organización porque representan funciones comunes que cada equipo del proyecto debe realizar. Las
descripciones de proceso deben identificar el rol del equipo que posee cada una de las actividades de
gestión de requisitos.
SOLUCIONARIO
El analista de negocios del proyecto normalmente tiene la responsabilidad principal de la gestión de
requisitos. El analista de negocio establecerá los mecanismos de almacenamiento de requisitos, definirá
los atributos de requisito, coordinará el estado de los requisitos y rastreará las actualizaciones de datos
y monitoreará la actividad de cambio según sea necesario. La descripción del proceso también debe
indicar quién tiene autoridad para modificar el proceso de administración de requisitos, cómo se deben
BIBLIOGRÁFICAS
manejar las excepciones y la ruta de escalamiento para los impedimentos encontrados. (Wiegers y
REFERENCIAS
Beatty, 2013)
8.2. La línea base de los requisitos
El desarrollo de requisitos incluye actividades para obtener, analizar, especificar y validar los requisitos
de un proyecto de software. Los entregables del desarrollo de requisitos incluyen requisitos de negocio, ANEXOS
requisitos de usuario, requisitos funcionales y no funcionales, un diccionario de datos y varios modelos
de análisis. Una vez revisados y aprobados, cualquier subconjunto definido de estos ítems constituye
una línea de base de los requisitos.
Una base de referencia de los requisitos es un conjunto de requisitos que los interesados han acordado,
a menudo definiendo el contenido de una liberación planificada específica o una iteración de desarrollo.
El proyecto podría tener acuerdos adicionales en cuanto a entregas, restricciones, calendarios,
presupuestos, requisitos de transición y contratos.
En el momento en que se establece un conjunto de requisitos, generalmente después de la revisión y

aprobación, los requisitos se colocan bajo la administración de la configuración (o cambio). Los cambios
subsiguientes sólo pueden realizarse a través del procedimiento de control de cambios definido en el

proyecto. Antes de la línea de base, los requisitos siguen evolucionando, por lo que no tiene sentido
imponer costes indirectos innecesarios sobre esas modificaciones.
ÍNDICE
Una línea base podría consistir en algunos o todos los requisitos de un ERS en particular (ya sea para un
producto completo o una sola versión), o un conjunto de requisitos designados almacenados en una
herramienta de gestión de requisitos o un conjunto acordado de historias de usuarios para una única
iteración en un proyecto ágil.
PRELIMINARES
Si el alcance de una versión cambia, actualice la línea de base de los requisitos como corresponde.
Distinguir los requisitos de una base de referencia particular de otros que fueron propuestos, pero no
aceptados, se asignan a una línea de base diferente o permanecen sin asignar en la cartera de productos.
Si los requisitos se especifican en forma de un documento como un ERS, identifíquelo claramente como
una versión de referencia para distinguirlo de los borradores anteriores.
BIMESTRE
PRIMER
El almacenamiento de requisitos en una herramienta de gestión de requisitos facilita la identificación de
aquellos que pertenecen a una línea de base específica y el manejo de los cambios a esa línea de base.
Un equipo de desarrollo que acepta cambios o adiciones de requisitos propuestos podría no ser capaz de
cumplir con su calendario y compromisos de calidad existentes. El gerente del proyecto debe negociar
los cambios con los gerentes, clientes y otros interesados afectados. El proyecto puede acomodar
SEGUNDO
BIMESTRE
requisitos nuevos o modificados de varias maneras:
• Difiriendo los requisitos de menor prioridad en iteraciones posteriores o cortarlos completamente

• Obteniendo personal adicional o subcontratando parte del trabajo
SOLUCIONARIO
• Ampliando el calendario de entrega o añadiendo iteraciones a un proyecto ágil
• Sacrificando la calidad para enviar en la fecha original
Ningún enfoque individual es universalmente correcto, porque los proyectos difieren en su flexibilidad
de características, personal, presupuesto, programación y calidad. (Wigers, 2006)
BIBLIOGRÁFICAS
REFERENCIAS
La elección debe basarse en los objetivos de negocio del proyecto y en las prioridades establecidas por los
principales interesados durante la iniciación del proyecto. No importa cómo responda a las necesidades
cambiantes, acepte la realidad de ajustar las expectativas y compromisos cuando sea necesario. Esto es
mejor que imaginar que de alguna manera todas las nuevas características serán incorporadas por la
fecha de entrega original sin excesos presupuestarios miembros del equipo apagados o compromisos
de calidad.
ANEXOS
8.3. Control de versiones de requisitos
El control de versiones, que identifica de forma única las diferentes versiones de un ítem, se aplica
tanto a los requisitos individuales como a los conjuntos de requisitos, representados más comúnmente
en forma de documentos. Comience el control de versión tan pronto como redacte un requisito o un
documento para poder conservar un historial de cambios realizados.
Cada versión de los requisitos debe ser identificada de manera única. Cada miembro del equipo debe
poder acceder a la versión actual de los requisitos. Los cambios deben ser claramente documentados
y comunicados a todos los afectados. Para minimizar la confusión y la falta de comunicación, permita
que sólo personas designadas actualicen los requisitos y asegúrese de que el identificador de versión
cambia cada vez que se realiza una actualización. Cada versión puesta en circulación de un documento

de requisitos o cada requisito de una herramienta debe incluir un historial de revisiones que identifique
los cambios realizados, la fecha de cada cambio, la persona que hizo el cambio y la razón de cada cambio.
ÍNDICE
El enfoque más sólido para el control de versiones es almacenar los requisitos en una herramienta de
administración de requisitos. Las herramientas de gestión de requisitos rastrean el historial de cambios
realizados en cada requisito, lo cual es valioso cuando se necesita volver a una versión anterior. Tal
herramienta permite comentarios que describen la razón detrás de una decisión de agregar, modificar
PRELIMINARES
o eliminar un requisito. Estos comentarios son útiles si el requisito se convierte en un tema de discusión
nuevamente en el futuro.
Si almacena los requisitos en los documentos, puede realizar un seguimiento de los cambios utilizando
la función de marcas de revisión del procesador de textos. Esta característica resalta visualmente los
cambios realizados en el texto con anotaciones como el tachado de resaltado para las supresiones y
subrayados para las adiciones. Al basar un documento, primero archive una versión marcada, luego
BIMESTRE
PRIMER
acepte todas las revisiones y guarde la versión ahora limpia como la nueva línea de base, lista para la
siguiente ronda de cambios. Guarde los documentos de requisitos en una herramienta de control de
versiones, como la que utiliza su organización para controlar el código fuente a través de procedimientos
de check-out y check-in. Esto le permitirá volver a versiones anteriores si es necesario y saber quién
cambió cada documento, cuándo y por qué.
SEGUNDO
BIMESTRE
El mecanismo de control de versiones más sencillo consiste en etiquetar manualmente cada revisión
de un documento de acuerdo con una convención estándar. Los esquemas que tratan de diferenciar
versiones de documentos basadas en fechas son propensos a la confusión. Utilizo una convención que
etiqueta la primera versión de cualquier nuevo documento con su título y “versión 1.0 del borrador 1”.
SOLUCIONARIO
El siguiente borrador conserva el mismo título, pero se identifica como “Versión 1.0 borrador 2.” El autor
incrementa el número del borrador con cada iteración hasta que el documento sea aprobado y alineado.
En ese momento, el identificador de versión se cambia a “Versión 1.0 aprobada”, manteniendo de nuevo
el mismo título del documento. La siguiente versión es “Versión 1.1 borrador 1” para una revisión menor
o “Versión 2.0 borrador 1” para un cambio importante. (Por supuesto, “mayor” y “menor” son subjetivos
y dependen del contexto). Este esquema claramente distingue entre borrador y versiones de línea base
BIBLIOGRÁFICAS
REFERENCIAS
del documento, pero requiere disciplina manual por parte de los que modifican los documentos.
8.4. Atributos de requisito
Piense en cada requisito como un objeto con propiedades que lo distinguen de otros requisitos. Además
de su descripción textual, cada requisito debe tener piezas de apoyo de información o atributos asociados
con ella. Estos atributos establecen un contexto y antecedentes para cada requisito. Puede almacenar ANEXOS
valores de atributo en un documento, una hoja de cálculo, una base de datos o, lo más efectivamente
posible, una herramienta de gestión de requisitos. Es engorroso usar más de un par de atributos de
requisitos con documentos.
Las herramientas de gestión de requisitos normalmente proporcionan varios atributos generados por el
sistema además de permitirle definir otros, algunos de los cuales se pueden rellenar automáticamente.
Las herramientas permiten consultar en la base de datos para ver subconjuntos de requisitos
seleccionados en función de sus valores de atributo. Por ejemplo, podría enumerar todos los requisitos
de alta prioridad asignados a Peter (Programador) para su implementación en la versión 2.3 y tener
un estado de Aprobado. A continuación, se presenta una lista de atributos de requisitos potenciales a
considerar:

• Fecha en que se creó el requisito

• Número de versión actual del requisito
ÍNDICE
• Autor que escribió el requisito
• Prioridad
• Estado
• Origen o fuente del requisito
PRELIMINARES
• Fundamento del requisito
• Número de versión o iteración a la que se asigna el requisito
• Interesados que pueden ponerse en contacto con las preguntas o tomar decisiones sobre los
cambios propuestos
• Método de validación a utilizar o criterios de aceptación
BIMESTRE
PRIMER
Los requisitos planificados para una liberación cambiarán a medida que se agreguen nuevos requisitos
y se eliminen o aplacen los ya existentes. El equipo puede estar manipulando documentos de requisitos
separados para varias versiones o iteraciones. Dejar los requisitos obsoletos en el ERS puede confundir a
los lectores en cuanto a si esos requisitos, si están incluidos en esa línea base. Una solución es almacenar
los requisitos en una herramienta de gestión de requisitos y definir un atributo “Número de publicación”.
SEGUNDO
BIMESTRE
Deferir un requisito significa cambiar su lanzamiento planificado, de modo que simplemente actualizar
el número de liberación cambia el requisito en una línea base diferente. Maneje los requisitos eliminados
y rechazados usando un atributo de estado. Definir y actualizar estos valores de atributos es parte del
costo de la gestión de requisitos, pero esa inversión que puede producir un retorno significativo.
SOLUCIONARIO
8.5. Seguimiento al estado de los requisitos
El seguimiento de estado significa comparar donde realmente se encuentra en un momento dado contra
la expectativa de lo que significa “completo” para este ciclo de desarrollo. Es posible que haya planeado
implementar sólo ciertos flujos de un caso de uso en la versión actual, dejando la implementación
BIBLIOGRÁFICAS
REFERENCIAS
completa para una versión futura. Supervisar el estado de sólo los requisitos funcionales que se
comprometieron para la versión actual, porque ese es el conjunto que se supone que es 100 por ciento
hecho antes de declarar el éxito y enviar el lanzamiento.
La tabla 16 enumera varios estados de requisitos posibles. Algunos profesionales añaden otros, como
Diseñado y Entregados. Es valioso mantener un registro de los requisitos rechazados y las razones por
las que fueron rechazados. Los requisitos rechazados tienen una forma de resurgir más tarde durante
el desarrollo o en un proyecto futuro. El estado Rechazado le permite mantener un requisito propuesto ANEXOS
disponible para posible referencia futura sin desordenar el conjunto de requisitos específicos de una
versión específica.

Tabla 16.
Estado de los requisitos sugeridos
ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
La clasificación de los requisitos en varias categorías de estado es más significativa que tratar de
supervisar el porcentaje de finalización de cada requisito o de la línea base de liberación completa.
Actualizar el estado de un requisito sólo cuando se cumplen las condiciones de transición especificadas.
Ciertos cambios de estado también requieren actualizaciones de los datos de rastreo de requisitos para
indicar qué diseño, código y elementos de prueba trataron el requisito.
BIBLIOGRÁFICAS
REFERENCIAS
La Figura 41 ilustra cómo puede monitorear visualmente el estado de un conjunto de requisitos a lo
largo de un proyecto hipotético de 10 meses. Muestra el porcentaje de todos los requisitos del sistema
que tienen cada valor de estado al final de cada mes. El seguimiento de la distribución por porcentajes
no muestra si el número de requisitos en la línea base está cambiando con el tiempo. El número de
requisitos aumenta a medida que se agrega el ámbito y disminuye cuando se elimina la funcionalidad
de la línea base. Las curvas ilustran cómo el proyecto se está acercando a su objetivo de verificación
completa de todos los requisitos aprobados. Un cuerpo de trabajo se realiza cuando todos los requisitos ANEXOS
que se le asignan tienen un estado Verificado, eliminado o Diferido.

ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
Figura 41. Seguimiento de la distribución del estado de los requisitos a lo largo del ciclo de desarrollo de
un proyecto
SEGUNDO
BIMESTRE
SOLUCIONARIO
Hemos finalizado el estudio de la unidad 8, la última del presente componente, y para finalizar
recomiendo el desarrollo de las siguientes actividades:
•• Utilice una herramienta para gestión de requisitos y registre los requisitos funcionales y no
funcionales, además de los casos de uso.
BIBLIOGRÁFICAS
REFERENCIAS
•• Indique ¿Qué actividades de gestión se puede realizar con la herramienta?
•• En el internet busque herramientas para gestión de requisitos. Puede ser herramientas
en la nube, para que no realice instalaciones locales. Pero si quiere utilizar de mejor
forma las prestaciones puede optar por hacer una instalación local.
•• Considere la documentación del caso de uso y tanto los requisitos funcionales como
los no funcionales desarrollados en las unidades anteriores para registrarlos en la
ANEXOS
herramienta.
•• Consulte en manuales y foros sobre el uso de la herramienta escogida.

Autoevaluación 8
ÍNDICE
PRELIMINARES
Lea detenidamente cada una de las preguntas y seleccione la alternativa correcta según corresponda
BIMESTRE
PRIMER
1. Al proceso de seguimiento de la situación y control de cambios de los requerimientos basados en
una línea base, se conoce como:
a. Gestión de requerimientos
b. Desarrollo de requisitos
SEGUNDO
BIMESTRE
c. Mantenimiento de sistema
2. La correcta administración de los requisitos, permite:
a. Planificar el cronograma
SOLUCIONARIO
b. Gestionar los costos
c. Minimizar los errores en las etapas posteriores a la especificación de requisitos
3. Una de las herramientas que permiten realizar la gestión de requerimiento de software tenemos:
a. Microsoft Visio
BIBLIOGRÁFICAS
REFERENCIAS
b. Open Project
c. Rational Requisite Pro
4. Elegir una técnica de gestión de requerimientos depende de:
a. Tipo de proyecto
b. Software a utilizar ANEXOS
c. Interesados
5. A la tarea de realizar un seguimiento de los requisitos, conociendo el ciclo de vida de los mismo,
se conoce como:
a. Control de cambios.
b. Definir requisitos.
c. Trazabilidad.

6. Al aplicar el control de cambios se:
a. Adapta el negocio al sistema
ÍNDICE
b. Establecen restricciones
c. Alinea el proyecto de software con el cambio a las necesidades del negocio
7. Los atributos de los requerimientos a los nuevos miembros les permite:
PRELIMINARES
a. Conocer la organización
b. Educarse acerca de los requerimientos
c. Desarrollar el proyecto
8. Para crear las matrices de seguimiento de requerimientos se debe:
BIMESTRE
PRIMER
a. Especificar los requerimientos
b. Establecer los atributos de calidad
c. Determinar qué resultados de desarrollo de software se debe dar seguimiento
9. Para mostrar los requisitos relacionados con el linaje hacia delante y hacia atrás con los entregables
SEGUNDO
BIMESTRE
del proyecto, se debe crear:
a. Atributos de requerimientos.
b. Políticas y procedimientos de control de cambios.
SOLUCIONARIO
c. Matrices de trazabilidad de requerimientos.
10. En cuanto a visibilidad la matriz de seguimiento, ayuda a:
a. Priorizar requerimientos
b. Identificar funcionalidades y restricciones que tendrá un proyecto o sistema
BIBLIOGRÁFICAS
REFERENCIAS
c. Cancelar requisitos duplicados
Recuerde que el solucionario se encuentra al final del presente texto guía
ANEXOS
Ir a solucionario

Texto-Guía: Ingeniería de Requisitos SOLUCIONARIO
7. Solucionario
ÍNDICE
PRIMER BIMESTRE
PRELIMINARES
Autoevaluación 1
Pregunta Respuesta
1. c
2. c
BIMESTRE
PRIMER
3. c
4. c
5. b
SEGUNDO
BIMESTRE
6. a
7. c
8. b
SOLUCIONARIO
9. a
10. c
BIBLIOGRÁFICAS
REFERENCIAS
Ir a autoevaluación
ANEXOS

Autoevaluación 2
ÍNDICE
Pregunta Respuesta
1. b
2. a
PRELIMINARES
3. c
4. b
5. a
BIMESTRE
PRIMER
6. a
7. b
8. c
SEGUNDO
BIMESTRE
9. b
10. c
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS

Autoevaluación 3
ÍNDICE
Pregunta Respuesta
1. b
2. c
PRELIMINARES
3. a
4. a
5. a
BIMESTRE
PRIMER
6. v
7. v
8. v
SEGUNDO
BIMESTRE
9. f
10. f
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS

Autoevaluación 4
ÍNDICE
Pregunta Respuesta
1. a
2. c
PRELIMINARES
3. c
4. b
5. b
BIMESTRE
PRIMER
6. b
7. f
8. f
SEGUNDO
BIMESTRE
9. v
10. v
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS

SEGUNDO BIMESTRE
ÍNDICE
Autoevaluación 5
Pregunta Respuesta
a
PRELIMINARES
1.
2. b
3. a
4. b
BIMESTRE
PRIMER
5. a
6. c
7. b
SEGUNDO
BIMESTRE
8. c
9. b
10. c
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS

Autoevaluación 6
ÍNDICE
Pregunta Respuesta
1. c
2. a
PRELIMINARES
3. c
4. b
5. a
BIMESTRE
PRIMER
6. b
7. c
8. c
SEGUNDO
BIMESTRE
9. a
10. a
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS

Autoevaluación 7
ÍNDICE
Pregunta Respuesta
1. c
2. b
PRELIMINARES
3. c
4. b
5. a
BIMESTRE
PRIMER
6. a
7. a
8. c
SEGUNDO
BIMESTRE
9. a
10. a
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS

Autoevaluación 8
ÍNDICE
Pregunta Respuesta
1. a
2. c
PRELIMINARES
3. c
4. a
5. c
BIMESTRE
PRIMER
6. c
7. b
8. c
SEGUNDO
BIMESTRE
9. c
10. b
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS

Texto-Guía: Ingeniería de Requisitos REFERENCIAS BIBLIOGRÁFICAS
8. Referencias bibliográficas
ÍNDICE
Alain, A., Moore, J., Bourque, P., & Dupuis, R. (2004). Guide to the Software Engineering Body of Knowledge.
Los Alamitos, United States: IEEE Computer Society Press.
PRELIMINARES
Beatty, J., & Chen, A. (2012). Visual Models for Software Requirements. United States: Microsoft Press.
Bern, B., & Allen, D. (2012). Object-Oriented Software Engineering Using UML, Patterns, and Java. Munich:
Prentice Hall.
Boehm, B., Abts, C., Winsor, B., Sunita, C., & Bradford, C. (2000). Software Cost Estimation with Cocomo II.
Prentice Hall.
BIMESTRE
PRIMER
Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The Unified Modeling Language User Guide. Addison-Wesley.
Bourque, P., & Fairley, R. (2014). Guide to the Software Engineering Body of Knowledge, Version 3.0 SWEBOK.
IEEE Computer Society.
SEGUNDO
BIMESTRE
Boyer, J., & Mili, H. (2011). Agile Business Rule Development. Process, Architecture, and JRules Examples.
Heidelberg, Germany: Springer.
Gottesdiener, E. (2005). The Software Requirements - Memory Jogger. New york, United States: GOAL/QPC.
Hatley, D., Hruschka, P., & Pirbhai, I. (2000). Process for System Architecture and Requirements Engineering.
SOLUCIONARIO
New York: Dorset House Publishing.
Hoffman, C., & Burgess, R. (2009). Use and Profit from Peer Reviews on Business Requirements Documents.“.
Business Analyst Times.
IEEE. (2002). Standard Glossary of Software Engineering Terminology.
BIBLIOGRÁFICAS
REFERENCIAS
ISO/IEC/IEEE. (2011). ISO/IEC/IEEE 29148:2011 Systems and software engineering -- Life cycle processes --
Requirements engineering.Geneva: Switzerland: International Organization for Standardization.
Johnson. (1995). Chaos: The Dollar Drain of IT Project Failures. Application Development Trends, 2, 41-47.
Lamsweerde, A. (2009). Requirements Engineering: from system goals to UML models to software
ANEXOS
specifications. Chichester, England: Wiley.
Leffingwell, D. (2011). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and
the Enterprise. Upper Saddle River: Addison-Wesley.
Robertson, S., & Robertson, J. (2012). Mastering the Requirements Process:Getting Requirements Right.
Massachusetts, United States:Addison-Wesley.
Sommervile, I. (2011). Ingeniería de Software. México: Pearson.
Sommerville, I., & Sawyer, P. (1997). Ingeniería de Software. México: Pearson
Wiegers, K., & Beatty, J. (2013). Software Requirements. Washington, United States: Microsoft Press.
Wigers, K. (2006). Software Requirements. Washington, United States: Microsoft Press.
Young, R. (2004). Effective Requirements Practices. Boston, United States: Addison-Wesley.

Texto-Guía: Ingeniería de Requisitos ANEXOS
9. Anexos
DI CTI ONARY
TH ESA UR US
ÍNDICE
El presente material ha sido reproducido con fines netamente didácticos,
cuyo objetivo es brindar al estudiante mayores elementos de juicio para la
PRELIMINARES
comprensión de la materia, por lo tanto no tiene fin comercial.
Anexo 1.
Anexo 1.a. Actividades de desarrollo y gestión de requisitos propuesto por el SWEBOK
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS

Anexo 1.b. Actividades de desarrollo y gestión de requisitos propuesto por Ellen Gottesdiener
ÍNDICE
P reparar el es c enario
Identifique los
Defina la visión Defina los
riesgos de los
del producto términos
requerimientos
PRELIMINARES
Des arrollo de requerimientos
Elicitación Especificación Especificación Validación
BIMESTRE
PRIMER
Documentar y
Identifique las
El modelado del verificar los Revisión de
fuentes de los
negocio requerimientos requerimientos
requerimientos
de usuario
SEGUNDO
BIMESTRE
Documentar y
Identificar los Entender el
verificar los Crear pruebas de
Stakeholders del alcance del
requerimientos validación
producto proyecto
de software
SOLUCIONARIO
Describir las
Agregar detalle a
necesidades y Probar los
los
criterios de modelos de
requerimientos
satisfacción de requerimientos
de usuario
los Stakeholders
BIBLIOGRÁFICAS
REFERENCIAS
Negociar las
Revisar técnicas
prestaciones Demostrar partes
de elicitación de
entre los del sistema
requerimientos
requerimientos
Plan de ANEXOS
elicitación
G es tionar los requerimientos
Establecer mecanismos
Identificar información Entender el linaje y
para gestionar los
de requerimientos relaciones de los
requerimientos de
suplementarios requerimientos
cambio

Anexo 1.c. Proceso de desarrollo de requisitos según Volere (Robertson & Robertson, 2012)
ÍNDICE
PRELIMINARES
BIMESTRE
PRIMER
SEGUNDO
BIMESTRE
SOLUCIONARIO
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS

Anexo 2. Sistema de gestión de trámites - UTPL

Visión
ÍNDICE
Versión 1.0
Historial de Revisiones
PRELIMINARES
Fecha Versión Descripción Autor
Propuesta inicial del documento Visión con
01/02/2016 0.9 las primeras definiciones de las necesidades José Alberto Suarez
por parte de los interesados.
15/02/2016 1.0 Versión 1.0 lista para su aprobación Miguel Angel Suarez
BIMESTRE
PRIMER
SEGUNDO
Tabla de Contenidos
BIMESTRE
1. Introducción............................................................................................................................................. 197
1.1. Propósito.............................................................................................................................................................. 197
1.2. Alcance.................................................................................................................................................................. 197
SOLUCIONARIO
1.3. Definiciones, acrónimos y abreviaturas:................................................................................................. 197
1.4. Referencias:......................................................................................................................................................... 197
2. Posicionamiento.................................................................................................................................... 197
2.1. Oportunidad de negocio:.............................................................................................................................. 197
BIBLIOGRÁFICAS
REFERENCIAS
2.2. Declaración del problema............................................................................................................................. 198
2.3. Posicionamiento del producto................................................................................................................... 199
3. Resumen de Usuarios......................................................................................................................... 199
4. Necesidades de los Afectados/Usuarios................................................................................. 200
4.1. Necesidades comunes de todos los afectados.................................................................................... 200
ANEXOS
4.2. Necesidades de <nombre del afectado>............................................................................................ 200
5. Resumen del Producto...................................................................................................................... 201
5.1. Perspectiva del Producto............................................................................................................................... 201
5.2. Resumen de Capacidades............................................................................................................................. 202
5.3. Supuestos y Dependencias.......................................................................................................................... 203
6. Características del Producto.......................................................................................................... 203
7. Restricciones............................................................................................................................................. 204
Apéndice............................................................................................................................................................... 204
Apéndice 1 – Requerimientos en Características..................................................................... 204
Apéndice 2 – Relación Necesidades – Características........................................................... 205

Visión
1. Introducción
ÍNDICE
1.1. Propósito
El propósito de éste documento es recoger, analizar y definir las necesidades de alto nivel y
PRELIMINARES
las características del sistema de gestión de tramites de la UTPL. El documento se centra en la
funcionalidad requerida por los participantes en el proyecto y los usuarios finales.
Este sistema cubre la gestión de cada uno de los trámites que los estudiantes de modalidad de
estudios a distancia que necesitan realizar por diferentes motivos, desde el lugar de residencia (en
todo el Ecuador y centro internacionales).
BIMESTRE
PRIMER
Los detalles de cómo el sistema cubre los requerimientos se pueden observar en la especificación
de los casos de uso y otros documentos adicionales.
1.2. Alcance
El documento Visión se ocupa, como ya se ha señalado, del sistema de gestión de trámites de la
SEGUNDO
BIMESTRE
UTPL. El sistema lo desarrollará el equipo de desarrollo de software de la institución educativa.
El sistema permitirá a los encargados de la empresa controlar todo lo relativo a la distribución de

los artículos (gestión de stock, gestión de pedidos, gestión de clientes, etc.). Además, también
permitirá a los clientes realizar pedidos online, realizar un seguimiento de sus pedidos, etc.
SOLUCIONARIO
El sistema permitirá a cada estudiante registrar los trámites con sus respectivos requisitos y a su
vez a los encargados de resolver disponer de todos los elementos necesarios para hacer el estudio
del caso y tomar la decisión que corresponde, todo esto en un ambiente distribuido donde cada
una de las personas que intervienen estén notificados lo que ocurre con sus trámites.
BIBLIOGRÁFICAS
1.3. Definiciones, acrónimos y abreviaturas:
REFERENCIAS
• Trámite: Solicitud de reclamo que el estudiante de modalidad a distancia realiza.
• Interesado: Persona o grupo de personas que tienen un interés en la realización del proyecto
• Digitalizar: Escanear todos los documentos para luego presentarlos en la secretaria del
centro.
1.4. Referencias: ANEXOS
• Glosario
• Acta de constitución del proyecto
2. Posicionamiento
2.1. Oportunidad de negocio:
En base a los procesos ya establecidos de cada uno de los trámites, con el desarrollo del presente
proyecto se pretende mejorar a niveles adecuados la atención al estudiante. De la misma manera
todos los demás involucrados en las actividades se verán beneficiados debido a que contarán con
los elementos necesarios para hacer el estudio al que corresponda, esto implica:

• Automatizar los procesos de obtención de datos relacionados con el tipo de trámite.

• Programar procesos de verificación de información rápida y oportuna a fin de cumplir con
ÍNDICE
las regulaciones impuestas por las entidades de control.
• Obtención de reportes de datos de manera rápida y confiable.
• Re-definir los procesos que amerite, debido a las funcionalidades que se desarrollen.
PRELIMINARES
2.2. Declaración del problema
La atención de trámites académicos y contables que generan los estudiantes no tienen

una adecuada atención, lo que genera excesiva demora en la resolución de los mismos
El problema de
debido a que no existe un flujo definido para el envío-recepción y a la falta de políticas
para su ejecución
•• Estudiantes
BIMESTRE
•• Directora MAD
PRIMER
•• Director Administrativo Financiero
•• Coordinación Académica MAD – Loja
•• Coordinación Académica MAD - CRQ
Afecta a
•• Directores de Escuela
•• Contabilidad MAD
•• Gestión de Procesos
SEGUNDO
BIMESTRE
•• Atención al Estudiante
•• Secretarías
•• El promedio de tiempo para resolver un trámite es alto
•• El estudiante requiere mucha gestión para obtener el resultado de su trámite,
causando malestar e insatisfacción.
SOLUCIONARIO
•• Se desperdicia tiempo, en tareas relacionadas a tratar de ubicar un trámite y
Cuyo impacto es
conseguir su estado.
•• Algunos trámites causan congestión en el proceso de matrícula, pues al no poderse
resolver ágilmente, los estudiantes deben regresar al centro universitario varias
veces entorpeciendo procesos de trabajo importantes (Matrículas).
•• Que la atención de los casos se realice mediante un sistema de fácil uso, de tal forma
BIBLIOGRÁFICAS
de que se dé solución a todos los trámites
REFERENCIAS
•• Que las solicitudes de trámites sean registradas directamente en un sistema
•• Que las solicitudes de trámites fluyan electrónicamente hacia a las diferentes
personas que deban revisarlo antes de su resolución
•• Que la documentación relacionada al trámite esté asociada a éste de forma digital
de manera que pueda ser visualizada directamente en el sistema
•• Que las personas implicadas en la resolución de un trámite sean notificadas por
e-mail del particular
Una solución exitosa •• Que las personas que intervienen en la resolución del trámite puedan realizar sus ANEXOS
tareas de aceptación, reprobación o notificación en el sistema y que éstas tareas
es provoquen inmediatamente la actualización del sistema académico, cuando
esto sea posible, eliminando así ciertas tareas manuales y agilitando los procesos
relacionados
•• Que una persona pueda conocer fácilmente los trámites que le han sido asignados
•• Que se pueda conocer inmediatamente que persona está atendiendo un trámite
•• Que se pueda conocer el estado en que se encuentra un trámite
•• Que se pueda disponer de estadísticas que permitan tomar decisiones para
optimizar los procesos relacionados
•• Que exista seguimiento adecuado de los trámites, estableciendo tiempos de
respuesta.

2.3. Posicionamiento del producto
••
ÍNDICE
Estudiantes
•• Directora MAD
•• Director Administrativo Financiero
•• Coordinación Académica MAD – Loja
•• Coordinación Académica MAD - CRQ
Para
•• Directores de Escuela
PRELIMINARES
•• Contabilidad MAD
•• Gestión de Procesos
•• Atención al Estudiante
•• Secretarías
•• Necesitan que los trámites tengan un tiempo de ejecución mínimo.
•• Necesitan tener registrados los trámites en una aplicación
Quién(es)
•• Necesitan conocer el status de un trámite en determinada instancia del flujo de trabajo
BIMESTRE
PRIMER
•• Necesitan tener un control estadístico sobre la ejecución de los trámites
El (nombre del
Sistema de Automación de Trámites - UTPL
producto)
Permitirá:
•• Exista un flujo de documentación desde los CUA’s a la sede central
SEGUNDO
Que •• Que las solicitudes de trámites sean registradas directamente en el sistema
BIMESTRE
•• Que las personas involucradas en el trámite sean notificadas entes de la ejecución del
mismo.
Del sistema actual que permite que:
•• Los trámites fluyan indistintamente entre los departamentos.
•• Exista demora en la resolución de un trámite, debido a que este puede ser enviado a
SOLUCIONARIO
varios departamentos.
A Diferencia
•• Desgaste de las personas en ubicar trámites
•• Entorpece la ejecución de otros procesos.
•• El estudiante tenga que concurrir un sin número de ocasiones a la universidad a CUA
para dar seguimiento a su trámite.
Permitirá
BIBLIOGRÁFICAS
REFERENCIAS
•• Que las solicitudes de trámites académico / contable se registren en el sistema
•• Que los requisitos asociados a un trámite se ingresen obligatoriamente
•• Que se notifique a los involucrados (personal UTPL-Estudiantes) del inicio de un trámite
•• Que se visualicen las solicitudes de trámite en formato digital.
•• Que las personas involucradas puedan gestionar un trámite
Esta Aplicación
•• Notificar al estudiante de la ejecución de un trámite.
•• Identificar a la persona que está atendiendo un trámite
•• Que se disponga de estadísticas que permitan la toma de decisiones
•• Que se pueda obtener información académica/contable ANEXOS
•• Que los trámites puedan ser configurados
•• Que se puedan ejecutar trámites automáticos de acuerdo al trámite solicitado.
3. Resumen de Usuarios
Nombre Descripción Afectado al que representa

Dra. María Andrade Director a de MAD Autoridades
Ing. Carlos Arellano Director financiero Autoridades
Dra. Margarita Rodríguez Coordinadora académica Autoridades
Ing. Verónica Galarza Coordinadora CRQ Autoridades
Lic. Katerine Galarza Contabilidad Operativo
Eco. Luís García Director de procesos Operativo

4. Necesidades de los Afectados/Usuarios
4.1. Necesidades comunes de todos los afectados
ÍNDICE
Soluciones
Necesidad Prioridad Solución Actual Preocupación
Propuestas
Las solicitudes de
PRELIMINARES
trámites no tienen
Que las solicitudes Disponer de un
un tiempo definido Inadecuada definición
de trámites puedan sistema automático
de ejecución y la de flujos de trabajo
ser resueltas en un de resolución de
Alta comunicación de y requisitos para
tiempo mínimo y trámites basado
resultados de una la ejecución de los
comunicar sus resultados en un motor de
solicitud en la mayoría trámites.
oportunamente. workflow.
de los casos no se la
BIMESTRE
realiza
PRIMER
4.2. Necesidades de <nombre del afectado>
Soluciones
Propuestas
SEGUNDO
BIMESTRE
Las solicitudes fluyen Disponer de un El número de
indistintamente entre módulo de ingreso trámites a presentar,
Que se registren las
Alta los departamentos, no de trámites, en donde puede afectar a la
solicitudes en el sistema
existe un registro de se puedas escoger el facilidad de uso de la
estos. trámite a realizar aplicación.
SOLUCIONARIO
Que los requisitos La aplicación
Los requisitos se
necesarios para permitirá que los
encuentran dispersos, Que no se definan
llevar a cabo un requisitos para cada
es decir se tiene correctamente los
trámite se presenten Alta trámite puedan ser
que recurrir a varias requisitos para cada
al inicio de cada configurados en una
fuentes para resolver trámite.
trámite y se ingresen funcionalidad de
un trámite
BIBLIOGRÁFICAS
obligatoriamente. ingreso.
REFERENCIAS
Disponer de un
Se notifique a las No existe notificación
módulo que notifique
personas involucradas del envió del trámite, Que los involucrados
a cada uno de los
(personal UTPL – Alta este llega por fax, no revisen las
involucrados vía
Estudiantes) del inicio de correo, e-mail, valija notificaciones
e-mail, o en su defecto
un trámite UTPL
utilizar Outlook
Disponer de una
Las solicitudes de funcionalidad de ANEXOS
Que las solicitudes de
trámites deben digitalización de Que los documentos
trámites puedan ser
Media llegar físicamente documentos, que no se visualicen
visualizadas en formato
al involucrado en el permita mantener adecuadamente.
digital.
trámite. el registro de los
trámites en el sistema.
Las solicitudes de El involucrado podrá
Que las personas
trámites se gestionan gestionar un trámite
involucradas puedan Alta
indistintamente en los directamente en la
gestionar un trámite.
departamentos funcionalidad.

Soluciones
Propuestas
ÍNDICE
Se comunica a los
CUA’s, del resultado
de la solicitud
Mediante los servicios
de trámite, en la Que no se pueda
Que se notifique al en línea el estudiante
mayoría de los casos actualizar esta
solicitante la ejecución Alta podrá verificar el
PRELIMINARES
el estudiante no es información en los
de un trámite status de su solicitud
notificado servicios en línea
de trámite
Las secretarias no
comunican los
resultados
La aplicación
No se puede manejará un flujo de
Que el motor
BIMESTRE
PRIMER
Que se pueda identificar identificar debido a trabajo (workflow)
de workflow
a las personas que está Alta que el trámite fluye que permitirá
no se configure
atendiendo un trámite indistintamente entre identificar a las
adecuadamente
los departamentos personas involucradas
en un trámite
La aplicación
SEGUNDO
BIMESTRE
permitirá visualizar
Que se disponga Que no se definan
información
de estadísticas que No se realiza este adecuadamente las
Alta estadística realizando
permitan la toma de proceso. combinaciones de
combinaciones
decisiones. criterios.
para los criterios
establecidos
SOLUCIONARIO
Integrar la
La información Que se genere
Qué se pueda acceder a aplicación al SGA
se obtiene de inconsistencia en
información académico/ Alta para la obtención
diferentes fuentes la información
contable. de información
indistintamente consultada
académico-contable
La aplicación
BIBLIOGRÁFICAS
REFERENCIAS
permitirá la
Que los trámites puedan Que no se defina
configuración de cada
ser configurados: No se realiza este adecuadamente el
Alta uno de los trámites
número de pasos, inicio proceso. flujo de trabajo para
mediante una
– fin los trámites
funcionalidad para su
ingreso
Que se puedan generar La aplicación
ANEXOS
procesos automáticos permitirá integrar Que se presente
con el SGA para la No se realiza este los trámites que se dificultades para la
Alta
ejecución de solicitudes proceso. ejecutan en el SGA, integración entre los
de trámite (ej. anulación para que su ejecución dos sistemas.
de matrículas.) sea automática.
5. Resumen del Producto
5.1. Perspectiva del Producto
El “Sistema de Automatización de Trámites” será integrado en el Sistema de Gestión Académica

y tendrá como objetivo la gestión automática de trámites a través de un motor de workflow que
proveerá la infraestructura para diseñar, construir, ejecutar, monitorear a cada uno de los trámites.

Debido a que el sistema se deberá integrar con el Sistema de Gestión Académica, interactuará con
sus módulos principales: Gestión Académica, Gestión Financiera, Configuración.
ÍNDICE
SISTEMA DE GESTIÓN ACADEMICA
Módulo de Descripción
Maneja información referente a los asuntos académicos como, por ejemplo:
PRELIMINARES
Gestión Académica planes de estudio, periodos académicos, notas, expedientes de los estudiantes,
etc.
Este módulo permite consultar información de los saldos a favor y en contra de
Gestión Financiera
los estudiantes que realicen solicitudes de trámite.
Este módulo permite la parametrización del sistema, por ejemplo, cierre de
Configuración matrículas, cierre de ingreso de notas, restricciones a funcionalidades, creación
de catálogos, etc.
BIMESTRE
PRIMER
Permite al consultar información académica/contable al estudiante. (Notas,
Servicios en Línea al Estudiante
saldos a favor, saldos en contra etc.)
MODULO DE AUTOMATIZACIÓN DE TRÁMITES
SEGUNDO
BIMESTRE
Permite invocar a cualquier trámite y además controlar las actividades que lo
Funcionalidades Generales
gestionan.
Permite llevar adelante en el sistema las actividades específicas definidas en cada
Funcionalidades Especificas
uno de los trámites.
SOLUCIONARIO
5.2. Resumen de Capacidades
• Las solicitudes de trámites serán registradas directamente en un sistema

• Las solicitudes de trámites fluirán electrónicamente hacia a las diferentes personas que
BIBLIOGRÁFICAS
deban revisarlo antes de su resolución
REFERENCIAS
• La documentación relacionada al trámite estará asociada a éste de forma digital de manera
que pueda ser visualizada directamente en el sistema
• Las personas implicadas en la resolución de un trámite serán notificadas por e-mail del
particular
• Las personas que intervienen en la resolución del trámite podrán realizar tareas de aceptación,
ANEXOS
reprobación o notificación en el sistema y estas tareas provocarán inmediatamente la
actualización del sistema académico, cuando esto sea posible, eliminando así ciertas tareas
manuales y agilitando los procesos relacionados
• Las personas involucradas en la resolución de trámites podrán conocer fácilmente los
trámites que le han sido asignados.
• Los estudiantes podrán acceder a información del status del trámite a través de los servicios
en línea al estudiante.
• Se conocerá inmediatamente que persona está atendiendo un trámite y en qué estado está
• Se dispondrá de estadísticas que permitan tomar decisiones para optimizar los procesos
relacionados

5.3. Supuestos y Dependencias
6. Características del Producto
ÍNDICE
Característica Descripción
Facilidad para ingresar solicitudes de Permitirá ingresar una solicitud (académico/contable). Se
trámites en el sistema controlará que no se dupliquen estas solicitudes.
PRELIMINARES
Facilidad para consultar notificaciones que La aplicación permitirá que tanto el personal UTPL como el
tiene un involucrado en la resolución de estudiante pueda consultar notificación de inicio de ejecución de
trámites un trámite.
Facilidad para comunicar electrónicamente La aplicación generará notificaciones automáticas a los
al personal involucrado del inicio de una involucrados (personal UTPL – Estudiantes) antes que empiece la
solicitud de trámite antes de su ejecución ejecución del trámite.
La aplicación permitirá digitalizar solicitudes de trámite con la
BIMESTRE
PRIMER
Facilitar la digitalización de las solicitudes
finalidad de que se almacenen en un banco de datos y puedan ser
de trámite.
consultadas a futuro.
Facilidad para visualizar las solicitudes de
Permite visualizar las solicitudes de trámite que fueron digitalizadas
trámites
Facilidad para realizar la aceptación de
La aplicación permitirá gestionar la solicitud de trámite
SEGUNDO
solicitud de trámite
BIMESTRE
Facilidad para realizar la reprobación o Permitirá que se pueda cerrar un trámite indicando en este el
notificación de trámite resultado de la ejecución del trámitesolicitud.
Facilidad para conocer el status de Permitirá tanto a personal UTPL como estudiantes consultar el
un trámite en determinada instancia, estado de la solicitud de trámite en cualquier instancia del proceso
SOLUCIONARIO
ingresando Actividad-Estado-Responsable- de resolución y podrá ser consultado gráficamente a través del
Tiempos de Actividad. motor de workflow del ORACLE 9i
Facilidad para que el estudiante pueda El estado de un trámite será subido a la funcionalidad de servicios
verificar el resultado del trámite desde los en línea para que el estudiante pueda consultar información
servicios en línea. relacionada a su solicitud.
Facilidad para que desde los CUA se pueda La aplicación permitirá el acceso al módulo de consultas desde los
BIBLIOGRÁFICAS
verificar el trámite. CUA´S,
REFERENCIAS
Facilidad para identificar al personal La aplicación permitirá identificar el estado y personal involucrado
involucrado en la resolución de un trámite en la ejecución de un trámite dentro del motor de workflow.
Facilidad para obtener información La aplicación permitirá obtener información estadística de los
estadística de trámites en ejecución. trámites en ejecución.
Facilidad para obtener información La aplicación permitirá obtener información estadística los
estadística de trámites ejecutados. trámites ejecutados.
Facilidad para obtener información La aplicación permitirá obtener información estadística de cada ANEXOS
estadística del tiempo promedio de uno de los estados que tomará un trámite dentro del motor del
culminación de un trámite. workflow.
Facilidad para visualizar la información La aplicación permitirá obtener información estadística de cada
estadística realizando combinaciones de los uno de los estados que tomará un trámite dentro del motor del
criterios establecidos. workflow.
Facilidad para verificar información contable La aplicación permitirá consultar información contable asociada
(Facturas, Saldos a favor, saldos en contra. a un estudiante sin necesidad de utilizar el módulo de Gestión
etc.). Financiera del SGA
Facilidad para verificar información La aplicación permitirá consultar información académica asociada
académica (Expediente, Matriculas, a un estudiante sin necesidad de utilizar el módulo de Gestión
Asignaturas, etc.) Académica del SGA
La aplicación permitirá configurar los datos de cada trámite
Facilidad para ingresar datos de un trámite.
académico/contable.

Característica Descripción
Facilidad para registrar tiempos de respuesta La aplicación permitirá configurar los tiempos de respuesta
ÍNDICE
por trámite. asociado a cada trámite académico/contable.
La aplicación permitirá categorizar cada trámite académico/
Facilidad para categorizar un trámite.
contable.
Facilidad para definir el flujo de trabajo de La aplicación permitirá definir el flujo de trabajo de cada trámite
un trámite. académico/contable.
PRELIMINARES
La aplicación permitirá integrar los trámites
La aplicación permitirá identificar los trámites que pueden ser
que se ejecutan en el SGA, para que su
ejecutados automáticamente por el SGA.
ejecución sea automática.
7. Restricciones
BIMESTRE
PRIMER
Apéndice
Apéndice 1 – Requerimientos en Características
Característica Requerimientos
•• Facilidad para ingresar solicitudes de •• La aplicación debe permitir ingresar solicitudes de trámites en el
SEGUNDO
BIMESTRE
trámites en el sistema sistema.
•• Facilidad para identificar todos los
requisitos asociados a un trámite. •• La aplicación debe permitir que uno o varios requisitos se puedan
•• Facilidad para que el ingreso de asociar a un trámite
requisitos asociado a un trámite sea •• La aplicación debe considerar el ingreso obligatorio de requisitos.
SOLUCIONARIO
obligatorio
•• Facilidad para comunicar
electrónicamente al personal •• La aplicación debe comunicar electrónicamente al personal
involucrado del inicio de una solicitud involucrado del inicio de una solicitud de trámite antes de su
de trámite antes de su ejecución ejecución.
•• Facilidad para consultar notificaciones •• La aplicación debe permitir consultar notificaciones que tiene un
BIBLIOGRÁFICAS
que tiene un involucrado en la involucrado en la resolución de trámites.
REFERENCIAS
resolución de trámites
•• Facilitar la digitalización de las
solicitudes de trámite. •• La aplicación debe realizar la digitalización de las solicitudes de
•• Facilidad para visualizar las solicitudes trámite.
de trámites
•• Facilidad para realizar la aceptación
•• La aplicación debe permitir la aceptación de una solicitud de
ANEXOS
de solicitud de trámite
trámite
•• Facilidad para realizar las reprobación
•• La aplicación permitir realizar las reprobación o notificación de
o notificación de trámite
trámite
•• Facilidad para conocer el status de
•• La aplicación debe permitir conocer el status de un trámite
un trámite en determinada instancia,
en determinada instancia, ingresando Actividad-Estado-
ingresando Actividad-Estado-
Responsable-Tiempos de Actividad.
Responsable-Tiempos de Actividad.
•• La aplicación debe permitir la visualización del status de un
•• Facilidad para visualizar status de un
trámite a través de un motor de workflow
trámite en el motor de workflow.
•• Facilidad para presentar información
ágil de los trámites. •• La aplicación debe permitir que el estudiante pueda verificar el
•• Facilidad para que el estudiante resultado del trámite desde los servicios en línea.
pueda verificar el resultado del •• La aplicación debe permitir que desde los CUA’s se pueda verificar
trámite desde los servicios en línea. el trámite
Facilidad para que desde los CUA’s se
pueda verificas status de un trámite.

Característica Requerimientos
•• Facilidad para identificar al personal
•• La aplicación debe permitir identificar al personal involucrado en
ÍNDICE
involucrado en la resolución de un
la resolución de un trámite
trámite
•• Facilidad para obtener información
estadística de trámites en ejecución.
•• Facilidad para obtener información •• La aplicación debe permitir obtener información estadística de
PRELIMINARES
estadística de trámites ejecutados. trámites ejecutados.
•• Facilidad para obtener información •• La aplicación debe permitir la obtención de información
estadística del tiempo promedio de estadística del tiempo promedio de culminación de un trámite.
culminación de un trámite. •• La aplicación debe visualizar la información estadística realizada
•• Facilidad para visualizar la información mediante combinaciones de los criterios establecidos.
estadística realizando combinaciones
de los criterios establecidos.
BIMESTRE
PRIMER
•• Facilidad para verificar información
contable (Facturas, Saldos a favor, •• La aplicación debe permitir la verificar de información contable
saldos en contra. etc.) (Facturas, Saldos a favor, saldos en contra
•• Facilidad para verificar información •• La aplicación debe permitir verificar información académica
académica (Expediente, Matriculas, (Expediente, Matriculas, Asignaturas, etc.)
Asignaturas, etc.)
SEGUNDO
BIMESTRE
•• Facilidad para registrar Trámites
•• Facilidad para registrar los requisitos
asociados a un trámite •• La aplicación debe permitir registrar cada uno de los trámites
•• Facilidad para registrar tiempos de •• La aplicación debe permitir registrar tiempos de respuesta por
respuesta por trámite. trámite.
•• Facilidad para categorizar un trámite. •• La aplicación debe permitir categorizar un trámite.
SOLUCIONARIO
•• Facilidad para definir el flujo de
trabajo de un trámite.
•• Facilidad para integrar los trámites
•• La aplicación debe permitir la resolución automática de trámites
que se realizan en el SGA, para que su
mediante la interacción con el SGA
ejecución sea automática.
BIBLIOGRÁFICAS
REFERENCIAS
Apéndice 2 – Relación Necesidades – Características
Necesidad Características
Que se registren las solicitudes en el
•• Facilidad para ingresar solicitudes de trámites en el sistema.
sistema
Que los requisitos necesarios para llevar a •• Facilidad para que se inicie un trámite adecuadamente.
cabo un trámite se presenten al inicio de •• Evitar pérdida de tiempo. ANEXOS
cada trámite •• Facilidad para disminuir la cadena de resolución de un trámite.
•• Facilidad para comunicar electrónicamente al personal
involucrado del inicio de una solicitud de trámite antes de su
Se notifique a las personas involucradas
ejecución
de la UTPL del inicio de un trámite
•• Facilidad para consultar notificaciones que tiene un involucrado
en la resolución de trámites
Que las solicitudes de trámites puedan •• Facilitar la digitalización de las solicitudes de trámite.
ser visualizadas en formato digital •• Facilidad para visualizar las solicitudes de trámites
•• Facilidad para realizar la aceptación de solicitud de trámite
•• Facilidad para realizar las reprobación o notificación de trámite
Que las personas involucradas puedan •• Facilidad para conocer el status de un trámite en determinada
gestionar un trámite. instancia, ingresando Actividad-Estado-Responsable-Tiempos de
Actividad.
•• Facilidad para visualizar status de un trámite.

Necesidad Características
•• Facilidad para presentar información ágil de los trámites.
ÍNDICE
Que se notifique al solicitante la ejecución •• Facilidad para que el estudiante pueda verificar el resultado del
de un trámite trámite desde los servicios en línea.
•• Facilidad para que desde los CUA se pueda verificar el trámite
Que se pueda identificar a las personas •• Facilidad para identificar al personal involucrado en la resolución
que están atendiendo un trámite de un trámite
PRELIMINARES
•• Facilidad para obtener información estadística de trámites en
ejecución.
•• Facilidad para obtener información estadística de trámites
Que se disponga de estadísticas que ejecutados.
permitan la toma de decisión •• Facilidad para obtener información estadística del tiempo
promedio de culminación de un trámite.
•• Facilidad para visualizar la información estadística realizando
BIMESTRE
PRIMER
combinaciones de los criterios establecidos.
•• Facilidad para verificar información contable (Facturas, Saldos a
Qué se pueda acceder a información favor, saldos en contra. etc.)
académico/contable. •• Facilidad para verificar información académica (Expediente,
Matriculas, Asignaturas, etc.)
•• Facilidad para registrar Trámites
SEGUNDO
BIMESTRE
Que lo trámites puedan ser configurados: •• Facilidad para registrar tiempos de respuesta por trámite.
número de pasos, inicio – fin •• Facilidad para categorizar un trámite.
•• Facilidad para definir el flujo de trabajo de un trámite.
Que se puedan generar procesos
automáticos con el SGA para la ejecución •• Facilidad para integrar los trámites que se realizan en el SGA, para
SOLUCIONARIO
de solicitudes de trámite (ej. anulación de que su ejecución sea automática.
matrículas.)
BIBLIOGRÁFICAS
REFERENCIAS
ANEXOS

Anexo 3. Sistema de gestión de trámites - UTPL

Especificación de requisitos de software
ÍNDICE
Versión 1.0
Historial de Revisiones
Fecha Versión Descripción Autor
PRELIMINARES
Propuesta inicial del documento Visión con las primeras
01/02/2016 0.9 definiciones de las necesidades por parte de los José Alberto Suarez
interesados.
15/02/2016 1.0 Versión 1.0 lista para su aprobación Miguel Angel Suarez
BIMESTRE
PRIMER
Tabla de Contenidos
SEGUNDO
BIMESTRE
1. Introducción............................................................................................................................................. 208
1.1. Propósito.............................................................................................................................................................. 208
1.2. Convenciones del documento.................................................................................................................... 208
SOLUCIONARIO
1.3. Público objetivo y sugerencias de lectura.............................................................................................. 208
1.4. Alcance.................................................................................................................................................................. 208
1.5. Referencias.......................................................................................................................................................... 208
2. Descripción general............................................................................................................................. 209
2.1. Perspectiva del producto............................................................................................................................... 209
BIBLIOGRÁFICAS
REFERENCIAS
2.2. Funciones del producto................................................................................................................................. 209
2.3. Clases y características de usuario............................................................................................................. 210
2.4. Ambiente de operación................................................................................................................................. 210
2.5. Restricciones de diseño e implementación.......................................................................................... 210
2.6. Asunciones y dependencias........................................................................................................................ 210
3. Características del sistema............................................................................................................. 210
ANEXOS
3.1. Registrar solicitud de trámite...................................................................................................................... 210
4. Requerimientos no funcionales.................................................................................................. 212

1. Introducción
1.1. Propósito
ÍNDICE
La gestión de trámites por parte de los estudiantes de MAD de la UTPL, requieren de una
atención adecuada por parte de cada uno de los estamentos universitarios que intervienen en la
resolución de los mismos. La aplicación “Gestión de tramites - UTPL” permite el aprovechamiento
de los recursos que la UTPL posee en cuanto a personas, coma a tecnología. En esta versión, la
PRELIMINARES
1.0 se establecen las necesidades de los usuarios, secretarias de centros, secretarias de carrera,
coordinación académica y profesores para gestionar y responder al flujo de eventos que se
realizan por cada trámite. La aplicación utilizará la información académica del sistema académico
“Syllabus” y del sistema financiero “Baan”.
1.2. Convenciones del documento
BIMESTRE
PRIMER
Al escribir este documento se basa en la plantilla del estándar IEEE-830.
1.3. Público objetivo y sugerencias de lectura
Este documento está dirigido para:
SEGUNDO
BIMESTRE
• Director de MAD
• Coordinador académico de la MAD
• Director del área de procesos de la MAD
• Coordinador del centro asociado de la MAD
SOLUCIONARIO
• Profesores
• Secretarias
• Estudiantes
1.4. Alcance
BIBLIOGRÁFICAS
REFERENCIAS
“SGT-UTPL” es una aplicación web que permitirá:
• Que las solicitudes de trámites académico / contable se registren en el sistema.

• Que los requisitos asociados a un trámite se ingresen obligatoriamente.
• Que se notifique a los involucrados (personal UTPL-Estudiantes) del inicio de un trámite.
ANEXOS
• Que se visualicen las solicitudes de trámite en formato digital.
• Que las personas involucradas puedan gestionar un trámite.
• Notificar al estudiante de la ejecución de un trámite.
• Identificar a la persona que está atendiendo un trámite.
• Que se disponga de estadísticas que permitan la toma de decisiones.
• Que se pueda obtener información académica/contable.
• Que los trámites puedan ser configurados.
• Que se puedan ejecutar trámites automáticos de acuerdo al trámite solicitado.
1.5. Referencias
• Acta de constitución del proyecto.

• Documento de visionamiento y problemática.
• Plan de especificación de requerimientos, entre otros.

2. Descripción general
2.1. Perspectiva del producto
ÍNDICE
El “SGT-UTPL” será integrado en el Sistema de Gestión Académica y tendrá como objetivo la gestión
automática de trámites a través de un motor de workflow que proveerá la infraestructura para
diseñar, construir, ejecutar, monitorear a cada uno de los trámites.
PRELIMINARES
Debido a que el sistema se deberá integrar con el Sistema de Gestión Académica, interactuará con
sus módulos principales: Gestión Académica, Gestión Financiera, Configuración.
SISTEMA DE GESTIÓN ACADÉMICA
BIMESTRE
PRIMER
Maneja información referente a los asuntos académicos
Gestión Académica como, por ejemplo: planes de estudio, periodos académicos,
notas, expedientes de los estudiantes, etc.
Este módulo permite consultar información de los saldos a
Gestión Financiera favor y en contra de los estudiantes que realicen solicitudes
de trámite.
SEGUNDO
BIMESTRE
Este módulo permite la parametrización del sistema, por
Configuración ejemplo, cierre de matrículas, cierre de ingreso de notas,
restricciones a funcionalidades, creación de catálogos, etc.
Permite al consultar información académica/contable al
Servicios en Línea al Estudiante
estudiante. (Notas, saldos a favor, saldos en contra etc.)
SOLUCIONARIO
MÓDULO DE AUTOMATIZACIÓN DE TRÁMITES
Permite invocar a cualquier trámite y además controlar las
Funcionalidades Generales
BIBLIOGRÁFICAS
actividades que lo gestionan.
REFERENCIAS
Permite llevar adelante en el sistema las actividades
Funcionalidades Especificas
específicas definidas en cada uno de los trámites.
2.2. Funciones del producto
El SGT-UTPL constará de las siguientes funcionalidades:

ANEXOS
Registro de trámites
Contempla servicios como:
• Búsqueda de estudiantes.
• Escoger tipo de trámite.
• Digitalizar documentos.
• Emitir notificaciones.
• Determina el flujo de eventos para cada trámite.
• Asigna cada trámite al rol de usuario.

Resolución de trámites
Contempla los siguientes servicios:
ÍNDICE
• Presenta una bandeja de trámites con los trámites por resolver.
• Presenta información dependiendo del trámite.
• Resuelve la actividad encomendada.
PRELIMINARES
• Notifica de la solución de la actividad.
Consulta de trámites
Dependiendo del trámite y rol del usuario se presenta información referente al trámite.
2.3. Clases y características de usuario
BIMESTRE
PRIMER
Los usuarios que intervienen son:
• Estudiante: Recibe notificación de las actividades respecto al trámite.

• Secretaria centro: Quien registra el trámite en el sistema.
SEGUNDO
BIMESTRE
• Profesor: Quien registra los datos cuando existe un trámite que tiene que ver con su materia.
• Coordinación académica: Resuelve ciertas actividades que tienen que ver con la coordinación.
2.4. Ambiente de operación
SOLUCIONARIO
El SGT-UTPL funcionará embebido en el sistema de gestión académica de la UTPL.
2.5. Restricciones de diseño e implementación
• El sistema deberá adaptarse al proceso que se realiza en el grupo de software de la UTPL.

• Se acoplará a la arquitectura del sistema académico de la UTPL
BIBLIOGRÁFICAS
REFERENCIAS
• Utilizará los servicios del sistema financiero.
2.6. Asunciones y dependencias
Asunciones
• El acceso a las características del sistema web se realizará previamente un registro de

usuarios. ANEXOS
• Las actividades que pueda realizar cada usuario dependerá del rol que se asigne en el
sistema.
Dependencias
• El sistema se basará en el uso de herramientas que esta licenciado la UTPL, y como motor
central el worflow de Oracle.
3. Características del sistema
3.1. Registrar solicitud de trámite

1. Descripción.
El estudiante inicia el proceso al entregar todos los documentos (dependiendo del trámite),
ÍNDICE
en el centro asociado, para que la secretaria con la ayuda del sistema registre en línea el
trámite y se notifique tanto al estudiante como a quienes deben resolver sobre la existencia
del trámite.
PRELIMINARES
2. Requerimientos funcionales
Los requerimientos que se identifican son:
FUN-AUT-01. Seleccionar estudiante
Entrada:
BIMESTRE
PRIMER
La selección del estudiante consiste en buscar y presentar si tiene registrado previamente
algún trámite. Se presenta un formulario con el tipo de búsqueda a realizar: (básica o
avanzada), y los campos son:
• Cédula del estudiante
SEGUNDO
BIMESTRE
• Nombres del estudiante
• Apellidos del estudiante
Proceso:
SOLUCIONARIO
Para realizar la búsqueda se puede realizar de dos formas:
• Búsqueda básica: Se la realiza ingresando el número de cédula del estudiante.

• Búsqueda avanzada: Se realiza ingresando: nombres y/o apellidos del estudiante.
Salida:
BIBLIOGRÁFICAS
REFERENCIAS
Si el estudiante fue encontrado presentar:
• Datos académicos adicionales del estudiante: carrera, período académico, centro

universitario.
• Datos de trámites ya registrados anteriormente: Tipo trámite, fecha inicio, fecha fin,
responsable, actividad, estado.
ANEXOS
FUN-AUT-02. Registrar documentos
…
FUN-AUT-03. Registrar tipo trámite

…
FUN-AUT-04. Consultar estado del trámite

…

4. Requerimientos no funcionales
1. La aplicación deberá ser tan familiar como sea posible a los usuarios que han usado otras
ÍNDICE
aplicaciones web (Syllabus) y aplicaciones de escritorio en Windows.
2. La aplicación debe ser fácil de entender y utilizar

3. Se deberá diseñar una aplicación amigable, que minimice la sobrecarga cognitiva y
PRELIMINARES
perceptiva del usuario de la aplicación, o sea, diseñar de forma óptima el conjunto de
operaciones, niveles, dispositivos y lenguajes resumidos en la etapa de análisis.
4. El flujo de trabajo de cada trámite deberá ser fácilmente interpretado en el motor de
workflow.
5. Cada una de las actividades de trámite, deberán ser especificadas de acuerdo al proceso
definido para la resolución de este, con la finalidad de que no existan actividades adicionales
BIMESTRE
PRIMER
a considerar en el flujo de trabajo
Apéndice A: Glosario
1. Términos Generales
SEGUNDO
BIMESTRE
• Actividad de un Trámite
Representa cada uno de los estados y diligencias que la solicitud de un estudiante tiene que
recorrer en el flujo de trabajo hasta su conclusión.
SOLUCIONARIO
• Digitalización
Proceso por el cual se capturan los datos de un formato físico y se lo expresa datos en forma digital.
• Estatus de trámite
Representa la situación relativa de una actividad de trámite dentro de un determinado flujo de
BIBLIOGRÁFICAS
REFERENCIAS
trabajo.
• Flujo de trabajo
Representa los aspectos operacionales de una actividad de trabajo: cómo se estructuran las tareas,
cómo se realizan, cuál es su orden correlativo, cómo se sincronizan, cómo fluye la información que
soporta las tareas y cómo se le hace seguimiento al cumplimiento de las tareas.
ANEXOS

Anexo 4. Lista de verificación para Inspección de la especificación de requisitos de

software
ÍNDICE
Identificador del documento
Autor
PRELIMINARES
Nombre del proyecto
Nombre de los revisores
Fecha de inspección
BIMESTRE
PRIMER
Exactitud
99 ¿Están los requisitos establecidos de una manera que sea independiente de la solución?
99 ¿Están los requisitos libres de errores de contenido y gramaticales?
99 ¿Todas las referencias cruzadas internas a otros requisitos son correctas?
SEGUNDO
BIMESTRE
99 ¿Los requisitos pueden ser utilizados como base para aceptar el sistema?
Claridad
99 ¿Puede interpretarse cada requisito de una sola manera?
SOLUCIONARIO
99 ¿Cada requisito está identificado de manera única?
99 ¿Están todos los requisitos escritos en un nivel de detalle consistente y apropiado?
99 ¿Los requisitos son lo suficientemente claros como para ser entregados a un grupo independiente
para el diseño y la implementación y todavía deben ser entendidos con una explicación mínima?
99 ¿Están los requisitos escritos de forma concisa (es decir, lo más corto posible sin perder el sentido)?
BIBLIOGRÁFICAS
REFERENCIAS
99 ¿Cada requisito es único y no está duplicado por ningún otro requisito?
Completo
99 ¿Todo el hardware e interfaces externas están definidas?

99 ¿Están especificadas todas las entradas y salidas del sistema, incluyendo su fuente, exactitud,
rango de valores y frecuencia? ANEXOS
99 ¿Están especificadas todas las tareas que el usuario necesita realizar?
99 ¿Cada tarea indica los datos utilizados en la tarea y los datos resultantes de la tarea?
99 ¿Están documentadas todas las reglas de negocio para las tareas del usuario?
99 ¿Falta alguna información necesaria de un requisito? Si es así, ¿se identifica como “por determinar
(TBD)”?
99 ¿Están especificados todos los atributos de calidad operacional necesarios (por ejemplo,
rendimiento, usabilidad, fiabilidad)? ¿Cada una de ellas precisa las escalas de medida?
99 ¿Se especifican todos los atributos necesarios de calidad de despliegue (por ejemplo, escalabilidad,
disponibilidad y flexibilidad)? ¿Cada una de ellas precisa las escalas de medida?
99 ¿Se han definido atributos importantes (por ejemplo, estado, propietario de la fuente, liberación,
etc.) para los requisitos?
99 ¿Los requisitos proporcionan una base adecuada para el diseño?

99 ¿Los requisitos han sido firmados por el aprobador y se ha creado formalmente la línea base?
99 Consistencia
ÍNDICE
99 ¿Están todos los requisitos de acuerdo (es decir, desprovistos de conflicto o de contradicción)?
99 ¿Se especifica el equilibrio aceptable entre los atributos especificados (es decir, entre el tiempo de
respuesta y el valor de los datos)?
99 ¿Se han escrito los requisitos en un formato estándar?
PRELIMINARES
Relevancia
99 ¿Es necesario cada requisito para lograr la visión del producto?

99 ¿Se han identificado los límites, alcance y contexto de cada característica o conjunto de requisitos?
99 ¿Se incluye la prioridad de implementación de cada requisito?
BIMESTRE
PRIMER
99 ¿Se relaciona cada requisito funcional con su origen en el entorno del problema o con una
justificación que explique su propósito?
99 ¿Están documentados los requisitos para establecer una relación entre cada requisito y su posterior
diseño, implementación y resultados de prueba?
99 ¿Pueden utilizarse los requisitos como base para aceptar el sistema?
SEGUNDO
BIMESTRE
Factibilidad
99 ¿Es posible desarrollar los requisitos con las tecnologías existentes?

99 ¿Se pueden satisfacer los requisitos prioritarios dentro de los recursos aprobados?
SOLUCIONARIO
99 ¿Hay al menos una solución de diseño e implementación que puede implementar correctamente
cada requisito?
99 ¿Pueden implementarse los requisitos dentro de las limitaciones de conocimiento?
Verificabilidad
BIBLIOGRÁFICAS
REFERENCIAS
99 ¿Se verifican los requisitos mediante pruebas, demostraciones, revisiones o análisis?
99 ¿Se establece cada requisito de una manera que permita que los criterios de prueba se desarrollen
y se realicen para determinar si los criterios se han cumplido?
99 ¿Pueden usarse los requisitos para crear planes de prueba, procedimientos y casos?
ANEXOS
MS/jclg/2017-03-09/214 pag.

Guía Didáctica Requisitos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guía Didáctica Requisitos

Cargado por

Copyright:

Formatos disponibles

ÍNDICE

La Universidad Católica de Loja

Facultad de Ingenieria y Arquitectura

Facultad de Ingenierias y Arquitectura

La Universidad Católica de Loja

Ediloja Cía. Ltda.

UNIDAD 3. REQUISITOS DE NEGOCIO................................................................................................. 51

UNIDAD 5. ANÁLISIS DE REQUISITOS................................................................................................ 92

6.7. Directrices para la redacción de requisitos............................................................................................ 150

UNIDAD 7. VALIDANDO LOS REQUISITOS......................................................................................... 158

7 MODALIDAD ABIERTA Y A DISTANCIA

¡Bienvenidos una vez más y éxitos en el ciclo académico!

8 MODALIDAD ABIERTA Y A DISTANCIA

Texto Guía elaborado para el estudio de la asignatura de Ingeniería de Requisitos en la titulación de

9 MODALIDAD ABIERTA Y A DISTANCIA

• Robertson, S. y Robertson J. (2013) Mastering the requierements Process. Massachusetts, United

La guía SWEBOK (cuerpo de conocimiento de la ingeniería de software), describe el conocimiento

OCW (Recurso Educativo Abierto)

Sitio donde se dan lineamientos sobre la Ingeniería de Requisitos de Software.

10 MODALIDAD ABIERTA Y A DISTANCIA

5. Orientaciones generales para el estudio

Le proponemos algunas orientaciones que le servirán en su proceso de aprendizaje:

11 MODALIDAD ABIERTA Y A DISTANCIA

Apoyo Tecnológico e Interactividad

12 MODALIDAD ABIERTA Y A DISTANCIA

6.1. Competencias genéricas de la UTPL

• Capacidad para organización y planificación del tiempo

• Habilidades para buscar, procesar y analizar información procedente de fuentes diversas

6.2. Planificación para el trabajo del alumno

• Desarrollar el cuestionario de proyectos de software

MODALIDAD ABIERTA Y A DISTANCIA

MODALIDAD ABIERTA Y A DISTANCIA

Unidades 1 a la 4 • Revisar los contenidos como Semana 7 y

MODALIDAD ABIERTA Y A DISTANCIA

6.3. Sistema de evaluación de la asignatura (primer y segundo bimestres)

Investigación (cita fuentes de

16 MODALIDAD ABIERTA Y A DISTANCIA

6.4. Orientaciones específicas para el aprendizaje por competencias.

Muchas décadas después de la invención de la programación de la computadora, profesionales de

17 MODALIDAD ABIERTA Y A DISTANCIA

Representan los objetivos de alto nivel de la organización o del cliente que

1 Instituto de Ingenieros Eléctricos y Electrónicos

18 MODALIDAD ABIERTA Y A DISTANCIA

Documento de Visión y Alcance

Figura 1. Relación entre los diferentes tipos de requisitos

1.2. Ingeniería de requisitos

19 MODALIDAD ABIERTA Y A DISTANCIA

Al construir un proyecto de desarrollo de software, el objetivo como ingeniería de requisitos es investigar

20 MODALIDAD ABIERTA Y A DISTANCIA

A continuación, se detalla cada una de las dimensiones que se indican en la figura 2.

1.3. Desarrollo y gestión de Requisitos

21 MODALIDAD ABIERTA Y A DISTANCIA

En concreto la Ingeniería de requisitos se divide en el desarrollo de requisitos y la gestión de requisitos

• Identificar las clases de usuarios y otros interesados del producto. ANEXOS

22 MODALIDAD ABIERTA Y A DISTANCIA

• Traducir el conjunto de necesidades de usuario escribiendo requisitos y diagramas apropiados

• Desarrollar pruebas y criterios de aceptación para confirmar que un producto basado en

1.3.2. Gestión de Requisitos

La gestión de requisitos es un conjunto de actividades que le permiten al equipo de desarrollo identificar,

23 MODALIDAD ABIERTA Y A DISTANCIA

24 MODALIDAD ABIERTA Y A DISTANCIA

• La expansión de los requisitos de usuario

25 MODALIDAD ABIERTA Y A DISTANCIA