gestionrequerimientosrequisitos

Índice de contenido
6.1. Ficha de caracterización del subproceso “Gestión de Requerimientos y Requisitos”..................3
6.2. Descripción de la Actividades del procedimiento “ Gestión de Requerimientos y Requisitos”. .5
6.3. Guias..............................................................................................................................................9
6.3.1. Los Requerimientos y Requisitos..........................................................................................9
6.3.1.1. Detallando un Requerimiento(s) o Requisito(s)...............................................................12
6.3.1.2. Definición de los Requisitos.............................................................................................14
6.3.1.3. Técnicas de Captura de Requerimientos y/o Requisitos...................................................19
6.3.1.4. Errores comunes en la definición de los Requerimientos y Requisitos............................23
6.3.1.5. Revisiones Efectivas de los Requerimientos y Requisitos...............................................27
6.3.2. Construcción del documento “Visión” ...............................................................................29
Impacto de no contar con el artefacto.......................................................................................29
Opciones de Representación.....................................................................................................30
Pasos .........................................................................................................................................30
Lista de Verificación .............................................................................................................32
6.3.3. Construcción de los Casos de Uso.......................................................................................33
Propósito...................................................................................................................................33
Propiedades de los Casos de Uso..............................................................................................35
Lista de verificación .................................................................................................................38
6.3.4. Construcción de los Modelos de Casos de Uso...................................................................39
Lista de Verificación .......................................................................................................40
6.3.4. Construcción del Documento “ Especificaciones de requisitos”.........................................42
Impacto de no contar con este artefacto....................................................................................42
Lista de Verificación ............................................................................................................43
6.3.4. Construcción del Glosario...................................................................................................45
Propósito...................................................................................................................................45
Consideraciones claves.............................................................................................................45
Impacto de no tenerlo................................................................................................................45

6.1. Ficha de caracterización del subproceso “Gestión de
Requerimientos y Requisitos”

6.2. Descripción de la Actividades del procedimiento “ Gestión de Requerimientos y
Requisitos”
Nombre de la
Actividad
Descripción
Responsa
bles
Artefactos
Relacionados
(Procductos)
Guías
1. Definitr o
Ajustar Nece
sidad(s)
Una necesidad es una demanda que expresa
una persona(s), dependencia(s) o instancia
con respecto a una situación problemática y
que puede ser solucionada a través de una
aplicación informática.
El interesado debe emitir o expresar cual es su
necesidad y el analista debe interpretarla y asi
iniciar el proceso de desarrollo.
Analista
Interesados
Solicitud de
Necesidad
2. Elaboración
o actualización
de la lista ma
estra de re
querimiento(s)
Un requerimiento es la descripción precisa y
clara de una necesidad funcional en términos
de lo que debe hacer el sistema. Una necesi
dad puede descomponerse en varios requeri
mientos dependiendo de la manera como se
haya definido.
Analista Lista Maestra
de requeri
mientos
Los requerimientos y los re
quisiitos
Detallando un requerimien
to(s) o requisito(s)
Tecnicas de Captura de re
querimientos y requisiitos
Errores comunes en la defi
nición de los requerimiento(s)
y requisitos(s)
Revisiones efectivas de los
requerimientos

3. Elaboración
y actualización
del documento
Visión
Con base en las necesidades de los interesa
dos, los requerimientos y los requisitos de alto
nivel definidos por el analista se plantea la si
tuación problematica y la posible solución infor
matica para los interesados.
Analista Visión Construcción del
documento visión
4. Elaboración
y actualización
Documento
Glosario
A medida que se definen y ajustan las necesi
dades y requerimientos de los interesados, se
construye y unifican cierta terminología entre
los interesados y el equipo de trabajo con el fin
de que exista una buena comunicación entre
los mismos.
Analista
Interesados
Glosario Construcción del Glosario
5. Elaboración
y actualización
del documento
“ Especifica
ción de Requi
sitos”
Un requerimiento responde a una necesidad
funcional del sistema, mientras que un requisito
representa una necesidad técnica en terminos
de usabilidad, confiabilidad , disponibilidad y
seguridad del sistema.
Analista Documento “
Especificación
de requisitos”
La construcción del
documento “
Especificaciones de
Requisitos”
6. Aprobación
de la Visión
Luego de una revisión de la visión por parte de
los interesados, estos evaluan si aprueba o no
la definición o solución al problema planteado,
en caso de que no se apruebe se debe ajustar
el documento y consecuentemente las necesi
dades planteadas.
Interesados Acta Construcción del documen
to visión

7. Aprobación
de los Reque
rimientos
Al igual que con el documento visión, los inte
resados deben dar su aval cuando se define un
requerimiento y en caso de que no se aprue
ben deberán ser ajustados para su futura apro
bación.
Interesados Acta Los requerimientos y los re
quisiitos
Detallando un requerimien
to(s) o requisito(s)
Tecnicas de Captura de re
querimientos y requisiitos
Errores comunes en la defi
nición de los requerimiento(s)
y requisitos(s)
Revisiones efectivas de los
requerimientos
8. Elaborar
modelos, ca
sos y especifi
caciones de
uso
Con base en los requerimientos aprobados, se
procede a detallarlo mediante diagramas, ca
sos y especificaciones de casos de uso.
Analista Modelo de
Casos de Uso.
Caso de Uso
de alto
Especificación
de caso de uso
Construcción de los casos
de uso
Construccion de los mode
los de casos de uso
9. Diseño, de
sarrollo y des
pliegue de los
requerimientos
y requisitos.
Este procedimiento (Gestión de requerimientos
y requisitos) es el insumo para llevar a cabo el
diseño, desarrollo y despliegue del software
Equipo de
Desarrollo
Revisar los capitulos si
guientes

10. Control de
Cambios dise
ño, desarrollo
y depliegue
del software.
A medida que surgen los cambios propios del
proceso de desarrollo (Anáisis, diseño, desa
rrollo , despliegue) , es necesario ajustar la do
cumentación propia de la gestión de requeri
mientos y requisitos, como la visión, el glosario,
los casos de uso de alto nivel, las especifica
ción de requisitos y lista maestra de requeri
mientos.
Analista Visión
Lista Maes
tra de Requeri
mientos
Especifica
ción de requisi
tos
Modelo, caso
de uso de alto
nivel y especifi
caciones de
casos de uso
Revisar capitulo “ Gestión
de Cambios”

6.3. Guias
6.3.1. Los Requerimientos y Requisitos

                 Los “Requerimientos” definen:
• Lo que los grupos de interés (usuarios) necesitan
• Lo que el sistema debe incluir para satisfacer las necesidades de los grupos de interés.
                   Los Requerimientos son las listas "por hacer" del equipo del proyecto.
Los Requerimientos definen lo que es necesario y enfoca al equipo del proyecto. Son el mecanismo
primario para comunicar los objetivos del proyecto a cualquiera que intervenga en el proyecto.
Son la base para capturar y validar las necesidades, administrar las expectativas, priorizar y asignar
el trabajo, verificar y validar el sistema y administrar el ámbito del proyecto.
Los requerimientos pueden tomar diferentes formas incluyendo los casos de uso y los escenarios,
texto no estructurado, texto estructurado o una combinación de todos ellos y pueden estar
estructurados en diferentes niveles de granularidad. En el más alto nivel de granularidad las
características definen los servicios que el sistema debe proveer para solucionar los problemas de los
clientes. Dichas características son capturadas en texto estructurado o no estructurado dentro del
Visión.  El siguiente nivel de granularidad son los casos de uso que definen la funcionalidad que el
sistema debe tener para poder proveer las características requeridas, estos describen la secuencia de
acciones desarrolladas por el sistema para poder brindar un resultado observable que sea de valor
para el actor o actores.
El sistema debe ser desarrollado de acuerdo al comportamiento que se especifica en los casos de
uso. Sin embargo, existen requerimientos del sistema que representan un comportamiento específico
a estos se les denomina “Requisitos” tales como:
• Requisitos legales o normativos, así como estándares.
• Atributos de calidad incluyendo características de uso e interacción con los usuarios,
confiabilidad, desempeño y requerimiento de soporte.
• Requisitos de interfaz que le dan capacidad al sistema para interaccionar con sistemas
externos.
• Restricciones de diseño tales como sistemas operativos, imagen institucional o de
compatibilidad con otro software.

Los requisitos se capturan de forma estructurada en el documento “Especificaciones de Requisitos de
soporte”
Los requisitos de soporte están clasificados de acuerdo al modelo FURPS+ (Funcional
(Requerimientos), características de uso e interacción con el usuario, confiabilidad, desempeño,
capacidad de soporte + restricciones). Las restricciones incluyen aquellas relacionadas al diseño,
implementación, interfaces y reglas del negocio.
Los requisitos de características de uso e interacción con los usuarios Incluye aquelos basados en
factores humanos e interfaces de usuario tales como la capacidad de acceso, estética de las
interfaces y consistencia.
Los requisitos de confiabilidad Incluye aspectos tales como la disponibilidad, exactitud, proyección,
frecuencia de fallo o recuperación del sistema en caso de fallo.
Los requisitos de desempeño incluye requisitos de carga de información del sistema, tiempos de
respuesta del sistema y uso de recursos.
Por otro lado encontramos los requisitos asociados a las restricciones de diseño, implementación,
interfaces, físicas y reglas de negocio:
• Restricciones de diseño: limitar el diseño y declarar los requisitos sobre el enfoque que debe
tenerse en cuenta en el desarrollo del sistema.
• Restricciones de implementación: poner límites al proceso de generación de código o de
construcción. (estándares requeridos, lenguajes, herramientas o plataforma)
• Restricciones de interfaz: son requerimientos para interaccionar con sistemas externos,
describiendo los protocolos o la naturaleza de la información que debe ser transferida a través
de la interfaz.
• Restricciones físicas: afectan el hardware o el empaquetado del sistema (forma, tamaño y
peso)
• Reglas del negocio: son la políticas, normas, estatutos, acuerdos , resoluciones o cualquier
tipo de decisión que gobierna la forma en que la institución opera. Ellas restringirán los pasos
descritos en el flujo del caso de uso.
Los requerimientos, requisitos y los casos de uso definen las necesidades de lo que se quiere del
sistema. Estos deben soportar las características dadas en la declaración de Visión. Cada
requerimiento y requisito debe soportar al menos una de las características y cada característica debe
estar soportada por al menos un caso de uso.
En general, los requerimientos describen el comportamiento y son capturados en los casos de uso y
los requisitos o requerimientos no funcionales son capturados en el artefacto ”Especificación
de Requisitos de Soporte”. Sin embargo, algunos requisitos están relacionados con algunos casos de
uso por lo que estos son capturados directamente dentro de ellos para simplificar la comunicación y el

mantenimiento. Por otro lado existen requerimientos globales, o de nivel de sistema, que son
capturados junto con los requerimientos de soporte.
A los requerimientos y requisitos se le puede asignar unos atributos para ayudar en la gestión del
proyecto.
Los atributos son propiedades que determinan información adicional e importante. Esta información
pude ser utilizada para responder preguntas acerca del estado de desarrollo de un proyecto
específico.
A continuación se muestra un conjunto típico de atributos. El valor de cada uno de ellos podrá ser un
número, un valor boleano, una fecha o simplemente una cadena de texto:
Prioridad: Declara la importancia relativa del requerimiento o requisito desde el punto de vista de
los interesados. Puede ser usada una escala de valoración (alta, media, baja). De acuerdo a la
complejidad del sistema dicha escala deberá poseer más valores que hagan más discernible el
modelo de requisitos.
Asignado a: En la institución quien es el encargado de asegurarse que el requerimiento o requisito
se esta cumpliendo. Corresponde a un nombre de persona y a un rol específico dentro de la
institución.
Iteración – La iteración en la cual se pretende implementar el requerimiento o requisito
Estimación del tamaño – Brindar una estimación de alto nivel que de cuenta del esfuerzo requerido
parta implementar y verificar el requerimiento o requisito y su solución. Usualmente se mide a partir
de valores sin unidades.
Esfuerzo faltante: Un estimativo del esfuerzo que falta para implementar y verificar el requerimiento
o requisito  y su implementación. Usualmente en horas
Estado: Marca el progreso en la implementación de un requerimiento o requisito. Puede utilizarse
una lista numerada (completo, parcialmente completado, no iniciado) o puede ser inferido desde el
atributo del esfuerzo faltante.
Cuando se asignan valores a todos los atributos de un requerimiento o requisito resulta relativamente
sencillo responder preguntas acerca del estado del proyecto:
¿Cuantos requerimientos o requisiitos fueron implementados en la iteración?
¿Que porcentaje de requerimientos  o requisitos de alta prioridad han sido implementados?
¿Cuantos requerimientos o requisitos asignados a la presente iteración continúan sin ser
implementados?
¿Cuales requerimientos o requisitos están asignados a una persona en especial?
otros atributos útiles podrían ser:

Fuente: Persona, documento u otro origen del requerimiento. Este es importante para poder
determinar a quien referirse cuando se tengan inquietudes o para agrupar requerimientos de acuerdo
a una fuente en particular.
Comentarios: Comentarios hechos a un requerimiento o requisito por parte de los revisores o
escritores.
Dificultad: Un indicador del nivel de esfuerzo requerido para implementar el requerimiento (Alto,
medio, bajo).
Riesgo: Medida confidencial acerca de la probabilidad real de cumplir o no un requerimiento o
requisito.
ID de prueba: Identificación de una prueba específica u otro método de verificación que pueda ser
aplicado al requerimiento o requisito.
6.3.1.1. Detallando un Requerimiento(s) o Requisito(s).
Un requerimiento(s) y/o requisito(s) deben ser escritos en una sola frase conformada por un sujeto y
un predicado. El sujeto es un actor, un interesado, el sistema en desarrollo o una entidad de diseño
que esté relacionada con el requerimiento. El predicado especifica la acción, o el resultado esperado,
que es realizada por, para o con el sujeto, usualmente incluye condiciones y criterios de desempeño.
Así es posible analizar un requerimiento o requisito desde un pinto de vista gramatical. Por ejemplo:
El modulo de matrículas debe ser capaz de completar 100 peticiones de los estudiantes en menos de
10 minutos.
Este requerimiento o requisito tiene un sujeto (el módulo de matrículas, que es parte del sistema en
desarrollo), un estado de finalización específico y medible (100 peticiones de estudiantes
completadas) y un criterio de desempeño (en menos de 10 minutos).
En los requerimientos o requisitos de los interesados el uso del “debería ser capaz de expresar
claramente que el interesado puede realizar algo pero no está obligado a hacerlo.
Para el caso de los requisitos del sistema la forma verbal “deberá” expresar que el sistema se obliga a
ejecutar esa acción cuando se cumplan determinadas condiciones.
Agrupar los requerimientos en listas numeradas pueden hacer que la lectura sea más clara pero debe
tenerse en cuenta que cada ítem de la lista debe ser en sí un requerimiento completo.
Deben evitarse palabras que conduzcan a ambigüedad tales como todos, todo, algunos.

Las siguientes guías ayudaran a escribir mejores requerimientos o requisitos. Para mantener la
consistencia del ejemplo todos los requerimientos se encuentran en el contexto de un proceso de
admisiones:
• Definir un requerimiento o requisito a la vez. Por ejemplo usar,
El Jefe de Admisiones debe ser capaz de actualizar el listado de inscritos de acuerdo a la información
del estrato socioeconómico.
El Jefe de Admisiones debe ser capaz de actualizar la información del estrato socioeconómico.
• Evitar las conjunciones (y, o) que generan múltiples requerimientos y fomentan la
ambigüedad. Por ejemplo es mejor usar:
El Aspirante debe ser capaz de observar si fue admitido desde la ventanilla de admisiones.
El Aspirante deber ser capaz de observar información relacionada con el proceso de admisión en la
ventanilla de admisiones.
En lugar de:
El Aspirante debe ser capaz de ver desde la ventanilla de admisiones si fue admitido y toda la
información relacionada con el proceso de admisiones.
La última forma es potencialmente peligrosa en el sentido de que no se especifica claramente si el
Aspirante debe ver la información al mismo tiempo a hacen parte de dos procesos separados.
• Evitar frases sueltas o palabras que impliquen opciones o excepciones (a menos que,
exceptuando, si es necesario, pero). Estas son peligrosas ya que dificultan la tarea de
determinar si el requerimiento aplica o no. Será mejor escribir requerimiento separados para
cada condición o estado del sistema. Por ejemplo, es mejor usar:
El sistema debe ser capaz de generar el recibo de pago 10 días antes del inicio de clases.
El sistema debe ser capaz de generar un recibo de pago en cualquier fecha cuando lo solicite al
Consejo de Facultad.
En lugar de:
El sistema debe ser capaz de generar los recibos de pago 10 días antes de iniciar las clases a menos
que haya una solicitud del Consejo de Facultad.
• Usar frases simples y directas

El Jefe de Planeación debe ser capaz de ver el indicador de ocupación del salón.
• En lo posible use palabras simples y conocidas de tal forma que se entiendan por un grupo no
especializado.
• Identificar el tipo de usuario que necesita cada requerimiento
El docente debe ser capaz de..
• Enfocarse en declarar cual es el resultado que el sistema dará a un tipo especial de usuarios:
...ver el plan de trabajo en una hoja de cálculo...
• Definir criterios identificables
6.3.1.2. Definición de los Requisitos
Esta guía explica como desarrollar y usar las especificación de requisitos del sistema.
Existe un conjunto finito de requisitos que se deben tener en cuenta cuando se considera todo el
ámbito del sistema, la características de calidad o las restricciones. Muchos de ellos no son familiares
para los interesados y por tanto ellos encontraran dificultades a la hora de responder preguntas
relacionadas con la disponibilidad desempeño, escalabilidad o localización. Se puede utilizar esta
guía al momento de hablar con los interesados.
a. Características de Uso e interacción con el usuario
Los requisitos que determinan las características de uso e interacción son críticas para el éxito de
cualquier sistema. No ayuda mucho si se tienen requisitos como: El sistema debe ser fácil de usar. Ya
que este no puede ser verificado.
Mientras se capturan los requerimientos funcionales es una buena idea identificar primero los
problemas y las inquietudes para poder refinarlas luego convirtiéndolas en requisitos verificables. De
acuerdo con la definición tradicional las características de uso e interacción tienen cinco factores:
• Facilidad de Aprendizaje: Un usuario con un nivel específico de experiencia debe ser capaz
de aprender como se utiliza el sistema en una cantidad determinada de tiempo.
• Eficiencia en las tareas: Un usuario debe ser capaz de completar una tarea específica en un
tiempo determinado (o en un número determinado de pulsaciones del ratón).
• Facilidad de recordar: Un usuario debe ser capaz de recordar como se utiliza el sistema aun
cuando haya dejado de utilizarlo por un determinado periodo de tiempo.
• Facilidad de ser comprendido: Un usuario debe ser capaz de entender los mensajes y las
alertas que el sistema genera.

• Satisfacción subjetiva: Un porcentaje considerable de la comunidad de usuarios debe
expresar satisfacción al utilizar el sistema.
Se pueden utilizar los siguientes métodos para identificar y especificar los requisitos de uso e
interacción con el usuario:
1. Identificar los problemas claves relacionados con las características de uso y de interacción
con el usuario. Es ideal revisar las tareas críticas, perfiles de usuario, metas del sistema y
problemas anteriores que se hayan presentado.
2. Seleccionar el estilo apropiado para expresar los requisitos:
• Estilo basado en el desempeño: Especificar que tan rápido los usuarios pueden
aprender varias tareas y que tan rápido ellos deben ejecutar tales tareas después de
ser entrenados.
• Estilo centrado en los defectos: Más que medir el tiempo empleado en ejecutar una
tarea se deben identificar los defectos encontrados con la características de uso e
interacción con el usuario, especificando con que frecuencia ocurren.
• Estilo centrado en guías de diseño: Especificar la apariencia general y los tiempos
de respuesta de la interfaz de usuario haciendo referencia a un estándar bien definido.
b. Confiabilidad
La confiabilidad incluye la habilidad que el sistema tiene para continuar funcionando ante situaciones
de tensión o condiciones adversas. En el caso de las aplicaciones la confiabilidad se relaciona con la
cantidad de tiempo que el sistema permanece funcionando. Especificar la confiabilidad a niveles
aceptables así como los mecanismos para que esta pueda ser medida y evaluada. Describir los
criterios de confiabilidad en términos cuantificables, usualmente como el tiempo permitido entre fallos
o la tasa de fallo total permitida. Otras consideraciones de confiabilidad incluye:
• Exactitud: Especificar los requisitos para la precisión (resolución) y la exactitud (de acuerdo a
un estándar conocido) que se necesita en cualquiera de los cálculos desarrollados o en la
salida del sistema.
• Disponibilidad: Especificar los requisitos para el porcentaje de tiempo que el sistema esta
disponible para uso, las horas de uso y las horas de mantenimiento. La disponibilidad es
típicamente especificada en términos del tiempo medio entre fallos. (TMEF).
• Recuperación: Especificar los requisitos para que el sistema se recupere de un fallo. Esto es
expresado típicamente en términos del tiempo medio de recuperación (TMDR).
• Frecuencia y severidad de los fallos: Especificar la tasa máxima de defectos (expresadas
en defectos/KSLOC o defectos/puntos de función) y la severidad de los fallos. La severidad
puede ser catalogada como menor, significativa y crítica. Los requerimientos deben definir

cada uno de estos términos sin ambigüedad, Por ejemplo, un defecto crítico puede ser
definido como aquel que resulta en una pérdida de datos o como uno que genere una pérdida
de la funcionalidad en una parte del sistema.
c. Desempeño
• Tiempo de respuesta: Especificar la cantidad de tiempo disponible para que el sistema
complete tareas específicas o transacciones (promedio, máximo). Utilizar unidades de medida.
Ejemplo:
• Cualquier interfaz entre el usuario y el sistema debe tener un tiempo máximo de
respuesta de 2 segundos.
• Rendimiento: Especificar la capacidad del sistema para soportar un determinado flujo de
información (Por Ejemplo, transacciones por segundo).
• Capacidad: Especificar la cantidad de datos que el sistema almacena y el volumen de datos
que el sistema maneja. Asegurar que la descripción de requerimientos esta cuantificada de tal
forma que pueda ser probada. Usar unidades de medida tales como: número de usuarios o
transacciones que el sistema puede administrar, el uso de recursos (memoria, discos,
conexiones de red, buffers, etc)
Ejemplos:
• El sistema debe atender hasta 10.000 estudiantes dentro del periodo de tiempo
comprendido entre las 9:00 AM a las 11 AM.
• La carga máxima en otros periodos será de 1500.
• Inicio del sistema: Tiempo máximo para que el sistema entre en producción después de ser
encendido.
• Apagado del Sistema: Tiempo máximo que el sistema tarda en apagarse.
d. Capacidad del sistema para ser mantenido
• Capacidad de adaptación: ¿Existen requerimientos especiales que contemplen la adaptación
del software (incluyendo actualizaciones)?. Listar los requerimientos que faciliten que el
sistema se adapte a nuevos ambientes.
• Compatibilidad: ¿Existen requerimientos que contemplen la compatibilidad del sistema con
otras versiones o con sistemas subsidiarios que proveen la misma capacidad?
• Configuración: ¿El producto debe ser configurado después de haberse instalado? ¿En que
forma debe ser configurado el sistema?
• Instalación: Declarar cualquier requerimiento especial que se relaciones con la instalación del
sistema.

• Nivel de soporte: ¿Que nivel de soporte se requiere para el producto? Usualmente se utilizan
una mesa de ayuda (Help desk). Si existe personas que provean soporte al producto ¿es ese
soporte parte de lo que se debe proveer a los clientes? ¿existen requerimientos para dicho
soporte?. Si se debe incluir soporte dentro del mismo sistema en esta sección deberían
colocarse tales requerimientos. Considere el nivel de soporte que el sistema, de forma
anticipada, provee y la forma en que será prestado.
• Mantenimiento: ¿Existen requerimientos especiales que contemplen el mantenimiento del
sistema? ¿Cuales son los requerimientos para el ciclo de liberaciones del sistema? ¿En que
forma se realizaran tales liberaciones?. Cuantificar el tiempo necesario para realizar cambios
específicos en el producto. Existen otros requerimientos especiales para el mantenimiento
tales como requerimientos para que los usuarios finales o interesados puedan realizar las
tareas de mantenimiento. Esto tiene efecto en la forma en que el sistema debe ser
desarrollado. Además, deben existir requerimientos adicionales para la documentación y el
entrenamiento o capacitación. Describir el tipo de mantenimiento y la cantidad de esfuerzo
requerido.
• Ejemplos:
Las mejoras de mantenimiento deben ser ofrecidas una vez cada año.
• Capacidad de crecimiento: ¿Que volumen de datos y usuarios debe soportar el sistema?
Estos requerimientos especifican el incremento esperado en tamaño que el sistema deberá
soportar a medida que el negocio crece ( o lo que se espera que crezca), los sistemas
software deben aumentar su capacidad para copar dichos volúmenes. Esto usualmente se
expresa como un perfil de tiempo.
• Capacidad de ser probado: ¿Existen requerimientos especiales que contemplen las pruebas
del sistema?. Usualmente los planes de auditoria pueden ser una fuente efectiva para rescatar
estos requerimientos a un alto nivel.
e. Restricciones (+)
• Restricciones de diseño: ¿Existen decisiones de diseño que deban ser aceptadas por el
producto? Estas incluyen políticas de imagen institucional, colores institucionales, etc.
• Componentes de terceros: Especificar cualquier componente de software tanto de software
libre como COTS o elementos legales que deban ser usados por el sistema.
• Lenguajes de implementación: Especificar los requerimientos para los lenguajes de
programación que deben ser utilizados.
• Plataforma de soporte: Especificar los requerimientos para la plataforma de soporte para el
sistema.

• Límite de recursos: Especificar los requerimientos que limitan el uso de recursos del sistema,
tales como el espacio en disco duro y la memoria.
• Restricciones físicas: Especificar los requisitos de forma, tamaño y peso del hardware
resultante que debe contener el sistema.
f. Requisitos de Interfaz(+)
Describe tanto la interfaz de usuario como las interfaces con sistemas externos.
Describe los requisitos relacionadas con la interfaz de usuario que debe ser implementada por el
software. La intención de esta sección es describir los requerimientos pero no describir la interfaz
como tal porque el diseño podría solaparse con el proceso de captura de requerimientos. Esto es
particularmente cierto cuando se esta utilizando la técnica de prototipos como parte del proceso de
captura de requerimientos. A medida que se desarrollan prototipos es importante capturar los
requerimientos que se relacionan con la forma en que luce y se ve la interfaz de usuario. En otras
palabras, debe asegurarse en todo momento que se entienden las intenciones de la institución en
cuando a la interfaz de usuario. Se recomienda registrar dichos requerimientos y no solo utilizar un
prototipo para su aprobación.
• Estilo y sensación: Una descripción de la apariencia estética y el diseño de la interfaz. La
institución puede tener ciertas restricciones en cuanto al estilo, los colores, el grado de
interacción y otras cosas. La idea es capturar las expectativas, restricciones y las demandas
de los clientes antes de diseñar la interfaz.
Ejemplos:
• El producto debe tener el mismo diseño que la página principal de la institución.
• El producto debe utilizar los colores de la institución.
• Requerimientos de disposición en pantalla y navegación: Especifica los requerimientos de
las áreas de la pantalla y como ellas deben ser agrupadas.
• Consistencia: La consistencia en la interfaz de usuario permite que se pueda predecir que
sucederá al interaccionar con el sistema. En esta sección se debe declarar los requerimientos
en cuanto al uso de mecanismos que se emplearán el la interfaz de usuario. Esto aplica tanto
para el sistema como para otros sistemas relacionados y puede ser aplicado a diferentes
niveles: controles de navegación, tamaños y forma de las áreas de la pantalla, lugares para
colocar o ingresar datos, terminología, etc.
• Personalización de usuario y requerimientos de personalización: requerimientos sobre el
contenido que debería se presentado automáticamente al usuario o ser disponible sobre la
base de los atributos del usuario. Algunas veces se permite al usuario personalizar el
contenido mostrado.

g.Interfaz a sistemas o dispositivos externos
• Interfaz de software: ¿Existen sistemas externos con los cuales tenga que interaccionar el
software? ¿Existen restricciones debido a la naturaleza de la interfaz, tales como el formato de
datos que se transfiere? ¿Dichas interfaces usan un protocolo específico? Describir la interfaz
o interfaces, que el sistema tenga con otros sistemas. Dichas interfaces pueden incluir
componentes comprados, componentes reusados desde otra aplicación, componentes que
deben ser desarrollados por subsistemas que se encuentran fuera del ámbito del proyecto
pero con los cuales se tiene que interaccionar. Para cada sistema se deben considerar tanto
las interfaces requeridas como las provistas.
• Interfaz de hardware: Defina cualquier interfaz de hardware que deba ser soportada por el
software incluyendo la estructura lógica, la dirección física, el comportamiento esperado, etc.
• Interfaz de comunicación: Describa cualquier interfaz de comunicación que se tenga con
otros sistemas o dispositivos tales como redes de área local (LAN), dispositivos seriales
remotos, etc.
h. Reglas de Negocio (+)
Más allá de los requerimientos técnicos también se debe considerar el dominio de negocios particular
en el cual encaja el sistema.
Las reglas del negocio o políticas que el sistema debe cumplir. Las reglas del negocio son
referenciadas desde los casos de uso del sistema y pueden ser definidas en forma de tablas de
decisión, reglas computacionales, árboles de decisión y algoritmos entre otros. Al describir las reglas
dentro de los flujos de los casos de uso usualmente los vuelve confusos. Por esta razón es que
dichas reglas son capturadas en artefactos separados o como anexos relacionados con las
especificaciones de los casos de uso. En muchos casos una regla del negocio aplica a más de un
caso de uso. Se recomienda recopilar las reglas en un repositorio único tal como el documento de
requerimientos de soporte.
6.3.1.3. Técnicas de Captura de Requerimientos y/o Requisitos
Esta guía describe varias técnicas que pueden ser útiles en la captura de los requerimientos y
requisitos.
Unos buenos requerimientos y requisitos inician cuando se detectan correctamente las fuentes.
Encontrar fuentes de alta calidad es una tarea importante que, afortunadamente, requiere pocos
recursos.

La fuente primaria de requerimientos son los interesados, luego es necesario identificar otros
candidatos:
• Clientes
• Usuarios
• Administradores
• Equipo de Mantenimiento
• Asociados
Preguntar a cada interesado para que ellos mismos propongan a otros interesados. De esta manera
se podrán identificar rápidamente a todos los interesados de tal forma que no se pierdan perspectivas
o requerimientos importantes. Esto puede servir para identificar y resolver los conflictos de
requerimientos de forma temprana.
Existen otras posibles fuentes de ideas para los requerimientos :
• Expertos en el dominio de interés. Como jefes de dependencias, empleados antiguos,
pensionados.
• Analistas en el tema de la educación y la administración educativa.
• Información acerca de Instituciones de Educación Superior o en general del área de interés.
Este último ítem también incluye la información asociada a los sistemas de información que utilizan
otras instituciones para solucionar los mismos problemas.
Después de que se identifiquen las fuentes de requerimientos se pueden aplicar diferentes técnicas
que sirven para capturarlos. Sin embargo, hay que tener en cuenta que la captura de requerimientos
es un proceso iterativo y que no existe una técnica única que sea universalmente aplicable.
Algunos de los métodos de captura de requerimientos son:
• Sesiones de tormentas de ideas.
• Entrevistas
• Trabajar en el ambiente objetivo
• Estudio de sistemas análogos
• Análisis de sugerencias y reportes de problemas y fallos.
• Charlas con los equipos de soporte
• Estudiar las mejoras realizadas por los usuarios
• Búsqueda de usuarios no considerados

• Conducir sesiones de trabajo en grupo y talleres.
• Mostrar los prototipos a los interesados
a. Conducir Sesiones de Tormenta de Ideas
Una tormenta de ideas es un sesión de trabajo en la que un pequeño grupo de personas proponen
ideas acerca de lo que consideren importante en el área o tópico de interés. Inicialmente Las ideas se
recogen pero no se discuten. Después de esto un facilitador guía al grupo para que los resultados de
la sesión sean organizados y priorizados. Las siguientes reglas básicas pueden asegurar unos
mejores resultados:
• Comenzar declarando claramente el objetivo de la sesión de tormenta de ideas.
• Generar el mayor número de ideas posible.
• Permitir que la imaginación vuele.
• Evitar y disuadir cualquier forma de crítica o de debate mientras se están capturando las ideas.
• Después de que se hayan capturado las ideas reformularlas y combinarlas.
b. Entrevistas a Usuarios
El contacto cara a cara con los usuarios a través de las entrevistas se puede considerar como la
fuente primaria de requerimientos y una de las vías más adecuadas para validarlos. Sin embargo se
debe recordar que esta nos es la única técnica y que las entrevistas también pueden tomar muchas
formas. Se recomienda desarrollar un repertorio de entrevistas para ser utilizado en situaciones
específicas. A menos que el grupo de desarrollo sea el único interesado en el producto es necesario
hacer un esfuerzo para entender de forma clara y correcta el problema que se desea resolver.
Empezar con entrevistas no estructuradas para ganar un entendimiento del marco de trabajo.
Preguntar a los interesados acerca de sus trabajos y de los problemas que enfrentan y pueden ser
solucionados con el sistema. Luego de ello se pueden estructurar entrevistas con base a un conjunto
de preguntas prediseñadas que tengan como objetivo complementar el conocimiento adquirido.
c.Trabajar en el ambiente objetivo
A veces es necesario tener la experiencia de los usuarios de forma directa. Esto ayuda a entender el
problema de primera mano y comprender el por qué las soluciones previas han fallado. Ha de tenerse
en cuenta que el integrante del grupo de desarrollo debe tratar por todos los medios de ponerse en el
lugar del usuario y así entender que es lo que podría hacer el sistema para disminuirle las cargas de
trabajo. En todo caso, es necesario evitar soluciones que incluyan herramientas para programadores

(editores, depuradores) a menos que se tenga seguridad de que los usuarios tienen el nivel de
habilidad requerido.
d.Estudiar Sistemas Análogos
El punto de partida para muchos proyectos es muchas veces similar a otros sistemas ya existentes.
Los sistemas que atacan el mismo problema pueden dar ideas acerca de como solucionarlo. Esto
permite ahorrar tiempo en el proceso de captura de requisitos y requerimientos mientras brinda
oportunidades para entender como otras personas han atacado el mismo problema. En ciertas
ocasiones estudiar sistemas que ataquen otro tipo de problemas puede contribuir a enriquecer las
propuestas de solución.
e. Examinar las sugerencias y los reportes de problemas
Algunos requerimientos pueden venir de sugerencias de cambios o de problemas explícitos
reportados por los usuarios. Un camino directo para encontrar los requerimientos es mirarlos cambios
y los problemas tal como fueron reportados inicialmente. Se recomienda utilizar formularios en línea
para que los usuarios puedan reportar problemas en el sistema o defectos en el software. Luego es
necesario agruparlos por áreas y preguntar a los usuarios para que clarifiquen los problemas
encontrados. Siempre se debe valorar la experiencia de los usuarios.
f. Conversar con los grupos de soporte
Se debe tener una mesa de ayuda que permita llevar registro de los errores y soluciones encontradas
en el sistema. Esta deberá contemplar procesos que soporten a los ingenieros que ayudan a
encontrar la solución así como a los usuarios que reportar fallos, errores y mejoras. Tener un equipo
de capacitación e instalación ayuda a interaccionar con el usuario y obtener requerimientos.
g. Analizar mejoras realizadas por los usuarios
Una buena fuente de requerimientos es analizar los cambios que el usuario ha realizado al sistema
base o la forma en que el usuario ha solucionado los problemas con aplicaciones genéricas (hojas de
cálculo, procesadores de texto, etc). La mayoría de las veces estás son fuentes invaluables que
cuentan la forma en que los usuarios desean ver solucionado un problema.
h.Verificar usos no considerados inicialmente.
Las personas a veces usan los sistemas para solucionar problemas para los cuales no fueron
elaboradas. Esto constituye una fuente para determinar ciertos requerimientos y obtener nuevas ideas
de desarrollo.
i. Conducir sesiones de trabajo en grupo y talleres
Los talleres pueden ayudar a capturar un conjunto de requerimientos rápidamente. En pocos días se
puede capturar y mejorar un conjunto adecuado de requerimientos que, debido a la naturaleza de
captura, tendrán un alto grado de calidad.

Aunque está técnica es más costosa en cuanto al uso de recursos también puede evitar gran cantidad
de entrevistas directas. Los talleres deben ser estructurados de tal forma que maximice el beneficio
de la inversión de tiempo de los participantes.
Seleccionar lugares que aíslen al grupo de trabajo de las tareas diarias y desestimule el uso de
dispositivos móviles . Tomar ventaja de la interacción informal seleccionando sitios – o ubicando los
elementos – que potencien el contacto cara a cara y que no presenten rigidez estructural (las sillas
ubicadas en círculos son una buena idea).
j. Mostrar los prototipos a los interesados
Los prototipos y los modelos son mecanismos excelentes para presentar ideas a los usuarios porque
ellos pueden ver inmediatamente algunos aspectos claves del sistema. Mostrar los prototipos puede
provocar que el usuario brinde un mayor número de requerimientos o cambie de idea acerca de los
requerimientos existentes depurándolos. Los prototipos también pueden ilustrar como la solución
podría funcionar o dar a los usuarios un vistazo de lo que podrían hacer con el sistema. Muchos más
requerimientos salen a la vista cuando el usuario puede comprobar los que están proponiendo.
Una presentación puede incluir un grupo de diapositivas, un concepto elaborado por un artista o un
diseñador, una representación o una animación que brinde a los usuarios una visión de las
posibilidades del sistema. Cuando se creen prototipos de software se puede hacer una maqueta
compuesta por pantallazos enfatizando que no existe código asociado y que el sistema aún no ha
sido especificado, diseñado o desarrollado,
Advertencia: Una maqueta puede crear un conjunto de expectativas difíciles de ser cubiertas.
Estos prototipos tienen como objetivo fomentar que los usuarios mencionen requerimientos que
faltan, no se supone que se está vendiendo una idea o un producto. Es decir, se debe centrar la
presentación en determinar lo que realmente se requiere del sistema. Ver un prototipo que,
invariablemente tiene problemas, en algún sentido puede ser un estímulo para que los usuarios
comiencen a decir lo que necesitan. Si ellos expresan demasiados problemas con el prototipo es
señal de que se esta logrando el cometido ya que cada problema puede conducir a un nuevo
requerimiento.
6.3.1.4. Errores comunes en la definición de los Requerimientos y
Requisitos
Esta guía describe las fallas típicas que se cometen al momento de capturar, definir y escribir los
requerimientos y requisitos.
Investigaciones muestran que los errores en los requerimientos y requisitos son frecuentes, llegando
a superar el 56% de todos los errores cometidos durante el desarrollo. Además, se encuentra el
hecho de que el costo de corrección de errores de requerimientos y requisitos incrementa
exponencialmente a través del ciclo de vida del desarrollo.

Frederick Brooks resume esta situación:
La parte más difícil de construir un sistema de software radica en decidir lo que se va a construir.
Ninguna otra parte del trabajo conceptual es tan difícil como el trabajo de establecer los
requerimientos y requisitos técnicos detallados. Ninguna otra parte del trabajo provoca que el sistema
resultante quede mal hecho. Ninguna otra parte es tan difícil de rectificar posteriormente.
Es crítico que los errores en los requerimientos se detecten lo más rápido posible antes de que se
propaguen a los artefactos de diseño, implementación y pruebas.
Aunque no hay una vía segura para eliminar los errores en los requerimientos si existen mecanismos
para evitar fallos comunes.
a. Ambigüedad
Evitar la ambigüedad es una de las reglas más difíciles de cumplir al momento de escribir los
requerimientos, Tratar de escribir lo más claro y explícito posible. Ser específico. Si se usan términos
ambiguos o vagos se debe estar seguro de que sean definidos en el glosario.
Propicie que muchos colegas e interesados revisen los requerimientos para asegurar un
entendimiento común y consistente. Aunque no hay una prueba definitiva para la ambigüedad, o al
menos diferente al consenso general, algunas de ellas ocurren cuando se utilizan palabras tales como
o, para y a menos que.
Ejemplo
"El mismo subsistema debe ser capaz de generar alertas visibles o audibles al Jefe de la Oficina."
En este requerimiento se cabría preguntar: ¿Cual subsistema?¿Las señales serán visibles, audibles o
ambas? ¿El Jefe de cual oficina?
b. Requerimientos Múltiples
Los requerimientos que contienen conjunciones (palabras que unen clausulas) deben ser evitados.
Los problemas con ellos surgen en el momento en que los lectores tratan de determinar cual de las
clausulas unidas aplican, específicamente si ellas están en conflicto o si cada una de las partes
aplica de forma diferente. Los requerimientos múltiples hacen que la verificación sea más compleja.
Conjunciones peligrosas incluyen: o, y, pero.
Ejemplo
"El indicador de deserción debe encenderse cuando el número de alumnos matriculados no supera el
40% en relación al semestre anterior y el número de alumnos o el porcentaje debe ser guardado en la
bodega de datos o el sistema transaccional."

c. Clausulas de escape
Los requerimientos que incluyen opciones o excepciones deben evitarse. Ellos tratan de definir algo
concreto pero al final resultan brindando otras alternativas. Los problemas se materializan cuando
dichos requerimientos deben ser probados y alguien tiene que decidir si estos están siendo cubiertos.
Palabras que implican excepciones incluyen: si, cuando, pero, excepto, a menos que, aunque.
Ejemplos
"El recibo de pago del estudiante debe ser generado una semana antes de iniciar las clases excepto
para los casos en que el estudiante haya terminado materias o cuando los Consejos de Facultad
aprueben otras expediciones."
Este es un requerimiento exageradamente peligroso.
d.Prolijidad
Sentencias extensas, especialmente cuando se combinan con lenguaje arcano o referencias a
documentos inalcanzables, conduce rápidamente a confusión y error.
Ejemplo
"Teniendo en consideración que las notas obtenidas por el estudiante correspondan a las escalas
mostradas en el Estatuto Estudiantil se puede comprobar su promedio considerando que el plan de
estudios pertenezca o no a la categoría de créditos”
e. Diseño Prematuro
Los requerimientos deben ser específicos pero sin restringirse a un diseño en particular. Si se genera
mucho detalle, se empieza a diseñar el sistema. Ir demasiado lejos es tentar a los diseñadores para
empezar a generar elementos que pueden estar pobremente sustentados.
Algunos signos de peligro incluye la utilización de nombres de componentes, materiales, objetos de
software o procedimientos, o campos de la base de datos.
Ejemplo
"La sabana de notas del estudiante debe ser cargada usando el formulario Carga de Notas que a su
vez debe guardar los datos en la tabla nota_estudiante”.
Al especificar un diseño en lugar que capturar las necesidades actuales incrementa el costo del
sistema al estipular restricciones sobre el desarrollo. Siempre preferir conocer el por qué que el como.

f. Mezclar diferentes tipos de requerimientos
Los requerimientos de usuario forman un modelo completo de lo que el usuario necesita. Estos
requieren ser organizados de forma coherente para mostrar vacíos y superposiciones. Lo mismo

aplica para los requisitos del sistema que forman un modelo funcional completo del sistema
propuesto. Un camino rápido hacia la confusión es mezclar los requerimientos de usuario con los
requisitos del sistema o con requerimientos de como el sistema debe ser diseñado, probado o
instalado.
Signos de peligro es encontrar referencia a sistema, diseño, prueba o instalación.
Ejemplo
"El usuario debe ser capaz de ver el formulario de inscripción el cual debe desplegarse en
navegadores compatibles con Mozilla 3.0 con soporte para HTML 4.01 transitional, ECMA 262 y CSS
2.1."
g. Especulación
Los requerimientos son parte del contrato entre la institución y el grupo de desarrollo. En este caso no
hay lugar para listas de deseos que contengan las cosas que probablemente alguien quiere pero que
no están completamente definidas.
Los signos de peligro incluyen vaguedad acerca del usuario que está interaccionando o
generalizaciones tales como usualmente, generalmente, la mayoría de las veces, normalmente,
típicamente.
Ejemplo
"Los Jefes requieren alertas tempranas acerca del no cumplimiento de indicadores”.
h. Vaguedad, términos indefinidos
Muchas de las palabras que se usan informalmente para indicar la calidad del sistema, son
demasiado vagas para ser usadas en los requerimientos. Los términos a evitar incluyen: versátil,
flexible, aproximadamente, en lo posible.
Los requerimientos que hacen uso de tales términos son difíciles, si no imposibles, de verificar,
porque no existen pruebas definitivas que muestren que el sistema tengan las propiedades indicadas.
Ejemplos
"El módulo de impresión debe ser versátil”.
i. Expresar solamente posibilidades
Sugerencias que no sean expresamente declaradas como requerimientos son ignoradas por los
realizadores del software.
"Opciones posibles" están indicadas con términos tales como puede, podrá, deberá, quizás,
probablemente.

j. Pensamiento ilusorio
El pensamiento ilusorio significa preguntar por lo imposible. La ingeniería es una actividad del mundo
real y ningún sistema o componente es perfecto.
Términos de pensamiento iluso incluye realizable, seguro, gestionar todos los fallos inesperados,
complacer a todos los usuarios, ejecutarse sobre todas las plataformas, nunca fallar, completamente
actualizable.
Ejemplo
"La captura de notas debe ser 100% segura en condiciones normales."
"El sistema debe gestionar todos los errores inesperados sin interrumpir el servicio”.
6.3.1.5. Revisiones Efectivas de los Requerimientos y Requisitos
El costo de corregir los errores crece de forma exponencial a medida que se avanza en el ciclo de
vida del desarrollo. Por tanto es importante descubrir los problemas de forma temprana y resolverlos
de la forma más rápida y económica.
La revisiones de los requerimientos y requisitos tienen como objetivo descubrir problemas
relacionados antes de que se gaste tiempo y trabajo significativo implementando los elementos
equivocados. Esto no quiere decir que se deba tener el conjunto completo de requerimientos antes de
empezar a desarrollar, es para garantizar que se ha revisado internamente y con los interesados,
aquellos requerimientos que se han seleccionado en las fases tempranas y que tienen un alto impacto
en el sistema. Se pueden hacer los siguientes tipo de revisiones:
a. Revisiones Informales
Las revisiones de los requerimientos pueden ser informales como mostrar un borrador de los
requerimientos a los colegas o demostrar el funcionamiento de un prototipo.
Estas revisiones informales son excelentes para obtener la correcta estructura de los requerimientos y
para remover los fallos obvios. Manteniendo pequeño el equipo de revisores es más fácil realizar
progresos rápidos. Sin embargo, las revisiones informales pueden generar pérdidas importantes
desde la perspectiva de los interesados claves.
b. Revisiones Formales
Los revisiones de requerimientos pueden ser reuniones formales. Deben ser preparadas de forma
cuidadosa de tal forma que se organicen los comentarios antes de la reunión. La reunión en si misma
debe producir resultados en todos los elementos revisados. Después de la reunión se deben llevar las
acciones de revisión hasta un estado de finalización. Si estas acciones involucran gran cantidad de
trabajo o requieren un cambio de un artefacto que esta bajo control de configuración se debe
considerar elevar un control de cambios para priorizar y hacer seguimiento al trabajo.

Las revisiones formales son de una mayor cobertura y son en general más costosas (consumen más
recursos). Proveen una revisión más equilibrada ya que concentra múltiples perspectivas. Sin
embargo, dichas revisiones involucran mayor cantidad de personas, lo que dificulta la coordinación
(debido a la necesidad de mantener la formalidad).
c. Revisiones de dos capas
Una técnica que toma lo mejor de los dos mundos es la de usar revisiones en dos etapas – o dos
capas – en donde primero se usan varias revisiones informales por un grupo pequeño y luego, la
segunda capa, se realizan algunas revisiones formales sobre elementos más concretos.
Revisiones de primera capa: Los autores de los requerimientos y el grupo de desarrollo revisan los
requerimientos para asegurar que no son ambiguos, son consistentes y completos. Es importante
incluir a los desarrolladores y los encargados de las pruebas para asegurarse que los requerimientos
son verificables y creíbles. Estas revisiones determinan si un conjunto dado de requerimientos está
listo para una revisión por parte de un conjunto más amplio de interesados. Las revisiones de primera
capa pueden ser informales, formales o una combinación de ambas.
Revisiones de segunda capa: Involucra un grupo más extenso para asegurarse que se tienen más
mentes trabajando en la solución del problema y para lograr un entendimiento compartido de tal forma
que dichos requerimientos puedan convertirse en requisitos que sean implementados y validados.
Las revisiones por capas ofrecen muchos beneficios:
1. Eliminar el ruido producido por ediciones menores ocurridas dentro de las primeras revisiones
de primera capa, permitiendo que las revisiones siguientes se centren en la funcionalidad.
2. Provee una visión profesional de los requerimientos presentándolos a ellos mismos y a sus
autores en la mejor de las formas.
3. Protege la inversión de tiempo de los interesados de tal forma que evite el “aburrimiento
escalonado” o la perdida de efectividad de las revisiones debido a la sobrecarga o la tensión.
4. Provee la mejor oportunidad para efectuar revisiones efectivas.
Se recomienda seguir estas reglas de oro en las revisiones:
1. Fomente la crítica: Recordar siempre que las personas están mejorando los requerimientos no
criticando al equipo de trabajo. Aún las críticas más punzantes contienen un grado de verdad. Adoptar
la aptitud de que toda sugerencia es un regalo. El equipo de desarrollo ha de prepararse
psicológicamente para aceptar la crítica.
2. Seleccione sus mejores revisores: A medida que transcurre el ciclo de vida del proyecto se
empieza a decantar las personas que tienen voluntad de revisión. Estas ocupan su tiempo y esfuerzo
en estas tareas. El equipo de trabajo debe cultivar la interacción con tales interesados.

3. Brindar el tiempo adecuado: La idea es obtener unos requerimientos y requisitos claros, precisos y
adecuados. Ciertos grupos de trabajo requieren bastante tiempo para lograrlo. Se debe mantener un
equilibrio adecuado entre los tiempos del proyecto y los de los interesados.
6.3.2. Construcción del documento “Visión”
Se entiende como visión los objetivos estratégicos y funcionales que a largo plazo persigue el
sistema. En general la visión se centra en la descripción de un problema y su solución basado en los
requerimientos y requisitos de los interesados.
El objetivo de la Visión es proponer una solución de alto nivel a un problema identificado y aceptado
por los interesados. Es necesario que dichos interesados interaccionen con el equipo de desarrollo,
expresando y documentando sus problemas, necesidades y características potenciales y esperadas
del sistema; con esto se logra un mejor entendimiento de que es lo que se va a construir y que
problema real se va a solucionar.
Este artefacto contiene la definición de la visión que los Interesados (stakeholder) tienen del producto
a ser desarrollado, especificado en términos de las necesidades y características claves de los
Interesados. Contiene los lineamientos de los requerimientos nucleares visionados del sistema.
Este artefacto provee un alto nivel, algunas veces contractual, la base para los requisitos técnicos
más detallados que son visibles para los Interesados (stakehoders). Captura la esencia del sistema
describiendo los requisitos de alto nivel y las restricciones de diseño que dan al lector una apreciación
global del sistema desde una perspectiva de requisitos funcionales. Sirve como entrada para el
proceso de aprobación del proyecto, comunica los "Qué y Por qué" fundamentales del proyecto y
proporciona un plan frente al cual todas las decisiones futuras deberán ser confrontadas.
Este artefacto proporciona una visión completa del sistema de software en desarrollo y los soporte del
contrato entre los clientes y la organización de desarrollo. Cada proyecto necesita una fuente para
capturar todas las expectativas de los Interesados.
Este artefacto es escrito desde la perspectiva de los clientes, enfocado en las características
esenciales del sistema y niveles aceptables de calidad. El artefacto debería incluir una descripción de
qué caracteristicas serán incluidas, como también cuales de estas se han considerado pero no se han
incluido.
Impacto de no contar con el artefacto
Si no se usa este artefacto, hay un alto riesgo de que los interesados y el equipo de desarrollo tenga
diferentes expectativas. Esto podría llevar a la cancelación del proyecto.

Opciones de Representación
Enmarcar este artefacto como requisito para necesidades en el proyecto. Generalmente es buena
práctica conservar este artefacto tan breve como se pueda y tan pronto como sea posible entregar
este a los Interesados y hacerlo fácil de leer y comprenderlo por los Interesados. Se puede lograr
esto, incluyendo únicamente las solicitudes y características más importantes de los Interesados y
evitando los detalles de los requerimientos. Se pueden describir los detalles en los otros artefactos de
requisitos.
Pasos
a. Identificar los interesados
Identificar los gestores (personas claves que se encargan de gestionar las cuestiones claves dentro del
proyecto), usuarios potenciales, expertos del dominio, analistas del dominio, aliados y otras partes
interesadas en el desarrollo de la solución.
Desarrollar perfiles de usuarios potenciales (o actuales) del sistema que encajen dentro de los roles de
actores humanos del sistema en desarrollo. Se debe documentar la información general de usuarios
claves en el artefacto visión.
b. Obtener un acuerdo del problema a ser solucionado
El objetivo de este paso es evitar ambigüedades al momento de definir una solución. Aplicando la
premisa de que una definición exacta del problema ya contiene una definición aproximada de la
solución, el equipo y los interesados deben llegar a un acuerdo concreto acerca del problema a ser
resuelto. La búsqueda de las causas del problema usualmente conduce a encontrar el “problema
detrás del problema”.
Se recomienda el uso de técnicas tales como las descritas en la guia “ Tecnicas de captura de
requisitos”. Formular una declaración del problema y documentarlo en la sección correspondiente del
artefacto Visión. La idea general es distinguir entre soluciones (respuestas) y problemas (preguntas).
c. Capturar un vocabulario común
Todos los proyectos tienen sus propios términos especializados que todo el equipo debe conocer, de
tal forma que se pueda comunicar fácilmente las ideas y avances a los interesados. Entre las
técnicas recomendadas se tiene:
Trabajar con los interesados en la definición de un glosario que contenga los acrónimos,
abreviaciones y términos relevantes del dominio o técnicos.
Trabajar con los interesados para que continuamente se expanda dicho glosario a medida que se

transcurre por el ciclo de vida del proyecto.
d. Capturar los requerimientos de los interesados
Utilizar los métodos más apropiados para capturar información del conjunto descrito en la guia “
Captura de requerimientos” Cada uno de ellos es aplicable es situaciones particulares o de acuerdo
al tipo de interesados:
En el caso de que se pueda tener encuentros personales con el interesado se puede conducir una
sesión de tormenta de ideas o una entrevista. Este tipo de contactos es de gran valor ya que reduce
el riesgo de confusión en la interpretación de las necesidades de los interesados..
Los requisitos pueden ser documentados utilizando listas de unidades de trabajo. Estas pueden ser
usadas como punto de partida desde el cual el conjunto total de requisitos puede ser creado.
e. Definir las fronteras del sistema
Encontrar y definir la línea que divide la solución y el mundo real que engloba dicha solución.
Identificar las interfaces así como las entradas y salidas de información intercambiadas entre
usuarios, máquinas y sistemas.
El modelo de Casos de Uso es una técnica reconocida para definir las fronteras del sistema.
f. Identificar restricciones del sistema
Considerar varios aspectos que pueden restringir los alcances del sistema y que por tanto pueden
tener un impacto significativo en el diseño y desarrollo de la solución y el proyecto. Entre otros se
incluyen aspectos como:
• Políticos
• Económicos (presupuesto, licencias)
• Ambientales
• Técnicos (plataformas, tecnología)
• Factibilidad (cronograma, provisión de recursos)
• Sistema (compatibilidad, soporte de sistemas operativos y ambiente de desarrollo).
g. Definir las características del Sistema
Trabajar con los interesados para capturar una lista de caracteristicas que los interesados necesitan
en el sistema, describirlas superficialmente y asignar atributos que ayuden a definir su estado y
prioridad dentro del proyecto.

Actualizar el artefacto visión para documentar las características identificadas y sus atributos.
h. Asegurar apoyo e involucrar a los interesados
Conducir una revisión de la visión del proyecto con los interesados principales y el equipo de
desarrollo para asegurar acuerdos, identificar parámetros de calidad y cambios requeridos.
Lista de Verificación
¿Se ha explorado completamente cual es el problema que esta detrás del problema?
Asegurar que se ha encontrado la raíz (causa) del problema o la necesidad especificada por los
interesados. La mayoría de la veces los interesados definen soluciones y no declaran explícitamente
el problema (o queja) que están experimentando. Como consecuencia no se identifica el problema
adecuadamente y por tanto no se define una solución correcta.
Tratar de colocar los problemas como preguntas a resolver es una buena técnica. Por ejemplo,
"Teniendo en cuenta los altos tiempos asociados a la atención de estudiantes y las cargas
administrativas, ¿Cual es la mejor alternativa para realizar el proceso de pago de matrícula?" es mejor
que "Necesitamos un módulo de pago de matrícula en línea".
¿La declaración del problema esta definida correctamente?
Asegurar que se tiene un acuerdo del problema a ser resuelto por el sistema.
¿La lista de interesados (stakeholders) es completa y correcta?
Asegurarse que no se ha “olvidado” un interesado clave. Es de vital importancia identificar a todos los
interesados para considerar la mayoría de perspectivas del problema – y la solución apropiada .
¿Todos los interesados están de acuerdo con la definición de las fronteras del sistema?
Definir claramente que esta dentro y que está fuera de los límites del sistema. Esto es un paso crítico
para definir el ámbito del trabajo.
¿Se han explorado suficientemente las restricciones que tiene el sistema?
No olvidar las restricciones y los requisitos no funcionales. Estos son usualmente los que generan
mayores costos al desarrollo.
¿Se han incluido todos los tipos de restricciones incluyendo políticas, económicas y
ecológicas?

Estas restricciones no técnicas pueden acarrear problemas en fases posteriores del proyecto.
¿Todas las características claves del sistema han sido definidas e identificadas?
Realizar una verificación completa, comparando las características del sistema con la declaración del
problema para asegurarse que no se pasa por alto una característica clave.
¿Las características podrán solucionar los problemas que han sido identificados?
Todas las características son realmente necesarias?
Quizás se pueda reducir el ámbito.
¿Las características del producto son consistentes con las restricciones identificadas?
Verificar que no existan requisitos en conflicto. Si se detectan se deben resolver en este momento.
¿Podrá alguien que no esté familiarizado con el proyecto entender que se pretende alcanzar
con él, tan solo con leer el documento de Visión?
El propósito del documento Visión es describir los objetivos del proyecto en términos de personas de
perfil no técnico. Cualquiera que no esté involucrado con el proyecto deberá poder entenderlo.
6.3.3. Construcción de los Casos de Uso
Un caso de uso describe la interacción entre uno o más actores y el sistema, de tal forma que se
provea un resultado observable que sea de valor para el actor participante.
La funcionalidad del sistema esta definida por diferentes casos de uso cada uno representando metas
específicas (obtener un resultado observable y de valor) para un actor en particular.
Este artefacto captura la secuencia de acciones que un sistema realiza y que genera un resultado
observable que es de valor para aquellos que interactuan con el sistema.
Propósito
El propósito principal de los Casos de Uso es capturar el comportamiento requerido del sistema
desde la perspectiva del usuario final, alcanzar una o más metas. Diferentes usuarios se benefician
en diferente forma, por ejemplo:
• Los Clientes los usan para describir, o al menos para aprobar, la descripción del
comportamiento del sistema.
• Los Usuarios Potenciales los usan para entender el comportamiento del sistema
• Los Arquitectos los usan para identificar la funcionalidad arquitectónicamente significativa.
• Los Realizadores de Software los usan para entender los comportamientos requeridos del
sistema de tal manera que ellos puedan identificar clases desde el flujo de eventos de los

Casos de Uso.
• Los Probadores los usan como una base para identificar un subconjunto de los Casos de
Prueba requeridos.
• Los Administradores los usan para planear y evaluar el trabajo para cada iteración.
• Los Escritores Técnicos los usan para entender la secuencia del comportamiento del
sistema que ellos necesitan describir en la documentación.
Decida la extensión de los Casos de Uso que usted elaborara:
• ¿Describir únicamente flujos principales?
• ¿Describir únicamente los Casos de Uso más importantes?
• ¿Describir completamente las precondiciones y postcondiciones?
• ¿Describir escenarios primero, y luego elevar el nivel de abstracción describiendo los flujos de
los Casos de Uso?
Algunos proyectos aplican Casos de Uso informalmente para ayudar a descubrir los requisitos,
documentar y gestionar estos requisitos en otra forma tal como unas historias de usuario. La forma
como usted presente los Casos de Uso podría depender del tamaño del proyecto, la experiencia del
equipo, su conjunto de herramientas, las relaciones con el cliente, y así sucesivamente.
Un caso de uso describe las interacciones entre los actores y el sistema en términos de un diálogo
estructurado como sigue:
1. El actor <<hace algo>>
2. El sistema <<hace algo en respuesta>>
3. El actor <<hace algo más>>
4. El sistema…
Cada dialogo, mostrado de esta forma es llamado un “Flujo de eventos”.
Debido a que existen muchos flujos de eventos posibles para lograr los objetivos (por ejemplo,el flujo
puede ser diferente de acuerdo a entradas específicas del Actor) y hay situaciones en las cuales las
metas no puedan se alcanzadas (por ejemplo, una conexión de red puede no estar disponible), cada
flujo de eventos debe contener muchos flujos, incluyendo un “Flujo Básico” y muchos “Flujos
Alternativos”.
El Flujo Básico especifica la interacción entre los actores y el sistema para un caso de uso ideal,
cuando todo va según lo planeado y las metas son alcanzadas por el Actor. El flujo básico

representan la funcionalidad principal proveída por este caso de uso.
Como el nombre lo dice, los Flujos Alternativos especifican interacciones alternativas asociadas con la
misma meta.
Relacionado con los casos de uso esta el concepto de Escenario. Un escenario es un flujo de eventos
específico para un conjunto específico de entradas y estados del sistema y del contexto del sistema.
Los escenarios están íntimamente relacionados con los casos de prueba.
Propiedades de los Casos de Uso
a. Nombre
Cada caso de uso debe tener un nombre que describa claramente el objetivo principal del caso de
uso. El nombre debe tener el número de palabras adecuado para ser claro y no tan extenso.
Usualmente el nombre identifica una acción por ejemplo: Retirar Dinero.
Nota: Dos casos de uso no pueden tener el mismo nombre.
b. Descripción breve
Refleja de forma clara y concisa el propósito del casos de uso.
c. Flujo de Eventos Contenido
El flujo de eventos deberá describir claramente la interacción entre el actor, o actores, y el sistema. El
flujo de eventos deberá representar lo que hace el sistema y no como el sistema está diseñado para
realizar la labor requerida.
Se deben seguir las siguientes guías para crear el contenido del flujo de eventos:
• Describir como empieza y termina el caso de uso.
• Describir que datos son intercambiados entre el actor y el caso de uso.
• No describir detalles de la interfaz de usuario a menos que sea necesario para entender el
comportamiento del sistema. Especificar los detalles de la interfaz de forma temprano podría
limitar las opciones de diseño.
• Describir el flujo de eventos, no solo la funcionalidad. Para forzar esto empezar cada acción
como "Cuando el actor ... ".
• Evitar términos vagos o ambiguos.
• Detallar el flujo de eventos. Especificar que sucede cuando..., en cada acción. Recuerde que
este texto podrá ser utilizado para identificar casos de prueba.
Si se han utilizado ciertos términos en otros casos de uso debe garantizarse que también son
utilizados de la misma forma (semántica y sintáctica) en el caso de uso actual. Para administrar los

términos se deben colocar en el Glosario.
d. Flujo de Eventos Estructura
Las dos partes principales del flujo de eventos son el flujo básico y los flujos alternativos, El flujo
básico de eventos debe cubrir los que “normalmente” pasa cuando se desarrolla el caso de uso. Los
flujos alternativos de eventos cubre comportamiento de carácter excepcional u opcional en relación
con el comportamiento normal; también pueden hacer referencia a variaciones del comportamiento
normal. Se puede pensar en los flujos alternativos como desviaciones en la ruta del flujo básico de
eventos algunos de los cuales retornarían al flujo básico mientras que otros se llevarían hasta finalizar
el caso de uso.
La flecha recta de la figura No 2 representa el flujo básico de eventos y las líneas curvas representan
rutas alternativas en relación a la normal. Algunas rutas alternativas retornarán al flujo básico de
eventos mientras que otras terminarán el caso de uso.
Estructura típica del flujo de eventos en un caso de uso

Para aclarar el sitio donde un flujo alternativo encaja en la estructura del caso de uso es necesario
describir los siguientes aspectos para cada uno de los “desvíos” del flujo básico de eventos:
• Dónde puede ser insertado el flujo alternativo de eventos
• Cuál es la condición que debe cumplirse para que el comportamiento alternativo comience.
• Cómo y dónde se regresa al flujo básico de eventos o como termina el caso de uso.
Si un flujo de eventos es muy simple se tiende a insertarlo directamente dentro del flujo básico por
medio de sentencias del tipo “sientonces”. Lo anterior en todo caso debe evitarse ya que degenera

en casos de uso complejos de comprender. En todo caso se debe emplear lenguaje natural y no
emplear construcciones que parezcan pseudo código. Recordar que los casos de uso deben ser
validados por los interesados.
Tanto los flujos básicos como los alternativos pueden ser estructurados en subflujos. Al hacer esto se
debe perseguir que el texto sea más comprensible y fácil de leer. Una guía es que el subflujo debe
contener un segmento de comportamiento con un objetivo claro dentro del caso de uso y que puede
ser atómico en el sentido de que las acciones que contiene deben ser ejecutadas completamente.
e. Requerimientos Especiales
En la sección de requerimientos especiales del caso de uso se describen todos los requerimientos
que no fueron cubiertos por los flujos de eventos. Usualmente se trata de requerimientos no
funcionales que pueden influir en le modelo de diseño.
f. Precondiciones y poscondiciones
Una precondición es el estado en que el sistema, y su contexto, debe estar para que el caso de uso
pueda iniciarse. Las postcondiciones son estados en los cuales el sistema puede estar después de
que el caso de uso ha terminado. Es de gran ayuda utilizar tanto las precondiciones como las
postcondiciones para aclarar como los casos de uso empiezan y terminan. Sin embargo, se deben
utilizar solo si los interesados y el grupo de desarrollo necesitan realmente esta información. La figura
No 3 muestra un ejemplo.
Ilustración de precondiciones y postcondiciones

g. Nivel de detalle en los casos de uso
Usualmente el modelo contiene casos de uso que son tan simples que no requieren una descripción
detallada y estructurada. En estos casos una descripción en formato paso a paso sería suficiente para
describirlos, sin embargo este enfoque solo debe tomarse si tanto los interesados como el grupo de
desarrollo acuerdan que no se necesita mayor refinamiento para lograr entender el objetivo del caso
de uso. Ejemplos clásicos incluyen a los casos de uso que describen la entrada de datos al sistema o
la búsqueda de información dentro del mismo.
Lista de verificación
Esta lista de verificación provee una serie de preguntas que sirven para determinar si los casos de
uso han sido descritos de una manera consistente o con un grado óptimo de exactitud

¿El nombre del caso de uso es único, claro, descriptivo y no ambiguo?
• ¿El caso de uso tiene un nombre único?
• ¿El nombre tiene la estructura verbo + sujeto (por ejemplo: Registrar Espacio Académico)?
• ¿El nombre resume el propósito principal del caso de uso?
• ¿El nombre es independiente del Actor?
¿ La descripción efectivamente presenta el objetivo principal del caso de uso?
• ¿Queda claro, después de leer la descripción, cual es propósito principal del caso de uso?
• ¿Los resultados de valor que arroja el caso de uso son obvios?
¿Los actores e información intercambiada están claramente definidos?
• ¿El caso de uso está asociado a uno o más actores?
• ¿El actor principal o actor inicial está definido?
• ¿Es claro quien realiza las acciones en el caso de uso?
• ¿La información intercambiada ente el sistema y los actores está claramente definida?
• Si un actor "tiempo" es utilizado, ¿Está seguro que no se esta desconociendo la importancia
de un actor o de otros casos de uso asociados? (quizás personal administrativo o de
mantenimiento que se encargan quienes definen los cronogramas)
¿Las precondiciones están definidas?
¿ Cada precoindición representa un estado concreto del sistema?
¿El flujo principal y los flujos alternativos son completos, correctos y consistentes?

• ¿Esta definido donde comienza el caso de uso?
• ¿El evento que desencadena el caso de uso está claramente descrito?
• ¿El flujo tiene un final definitivo?
• ¿Cada paso del escenario tiene el mismo nivel de abstracción – o de especificidad?
• ¿Cada paso del escenario describe algo que puede suceder actualmente y que el sistema
puede detectar razonablemente?
• ¿Cada paso representa un progreso para alcanzar la meta?
• ¿Faltan pasos? ¿Está claro como se va desde un paso a otro? ¿La secuencia de
comunicación entre actores y el caso de uso está conforme a las expectativas del usuario?
• ¿Cada paso describe como éste ayuda al actor a alcanzar sus metas?
• ¿Cada paso es independiente de la tecnología? ¿Cada paso esta libre de detalles técnicos o
de restricciones de diseño?
• ¿Los pasos están numerados de forma correcta?
• Para cada flujo alternativo, ¿las condiciones de inicio están claramente definidas?
• Para cada flujo alternativo, ¿Esta claro como termina el caso de uso o en que punto el flujo
básico continua?
¿Las postcondiciones están especificadas?
• Si las Garantías Mínimas están presentes, ¿Estas siempre pasan cuando se completa el caso
de uso independientemente de su éxito? (Una Garantía Mínima representa una condición que
debe ser verdadera cuando el caso de uso termina sin importar la forma en que este termine.)
• Si las Garantías de Éxito están presentes. ¿Estas siempre pasan cuando el caso de uso
termina de forma exitosa? (Una Garantía de Éxito representa una condición que será
verdadera cuando el caso de uso termina de forma exitosa.)
¿Los requisitos no funcionales han sido capturados?
• ¿Los requisitos no funcionales que aplican al caso de uso han sido capturados?
• ¿Dichos requisitos son aplicables a muchos casos de uso? Si esto es cierto, considere
capturarlos en el documento de Especificación de Requisitos.
6.3.4. Construcción de los Modelos de Casos de Uso
Esta guía describe como desarrollar y evolucionar el modelo de caso de uso para poder capturar los
requerimientos funcionales para el sistema en desarrollo.
La clave de éxito en un desarrollo iterativo es asegurar que el equipo de desarrollo maximiza el valor
entregado a los interesados y minimiza el riesgo en las etapas tempranas del proyecto. Esto impone
algunas restricciones en la forma en que se desarrolla el modelo de casos de uso.
En un extremo está el enfoque clásico en cascada, el cual propone detallar todos los requerimientos

antes del diseño y la implementación. Esto demora innecesariamente las entregas que se puedan
hacer a los interesados y no se tiene un control sobre el riesgo.
En el otro extremo está comenzar el diseño y desarrollo antes de conocer lo que el sistema debe de
hacer lo que genera costosas reelaboraciones en etapas tardías del ciclo de vida.
Un enfoque que ha demostrado ser adecuado propone detallar los requerimientos que serán
desarrollados en la siguiente (o máximo dos siguientes) iteraciones. La selección de los
requerimientos a desarrollar está fundamentado en el valor que entrega a los interesados y en la
reducción de los riesgos. Aunque no se espera un conocimiento completo del dominio se es
necesario tener una vista general del mismo.
Las siguientes discusiones bosquejaran el enfoque usado para llevar el modelo de casos de uso a un
sistema que alcance las metas propuestas.
El enfoque recomendado es “ancho antes que profundo”. Se deben identificar los actores y los casos
de uso para realizar bosquejos de ellos rápidamente. Basado en este conocimiento se puede realizar
una valoración inicial del riesgo y así concentrar el esfuerzo en detallar los casos de uso de las áreas
correctas.
Este artefacto captura un modelo de las funciones esperadas del sistemas así como el ámbito del
mismo. Sirve de contrato entre la institución y los desarrolladores.
Este artefacto presenta una visión del comportamiento esperado del sistema. Es la base para los
acuerdos de desarrollo entre los interesados y el grupo de proyecto. También ayuda a guiar las
diferentes tareas dentro del ciclo de vida del desarrollo de software.
Aunque existen diferentes opciones de representación se recomiendan los reportes y diagramas
generados en herramientas de modelado UML. La mayoría de la información en el modelo de casos
de uso es capturado en las especificaciones de casos de uso.
Lista de Verificación

¿Es fácil determinar lo que hace el sistema al revisar el modelo?
• ¿La encuesta de casos de uso proveé una descripción clara y concisa de la funcionalidad del
sistema?
• ¿No existen cadenas demasiado largas de relaciones include? Tales cadenas pueden volver
complejo la interpretación y comprensión.
• ¿Los casos de uso incluidos son independientes de los casos de uso que los incluyen?

• Si muchos casos de uso contienen subflujos similares. ¿Ha investigado como integrar este
comportamiento común en un caso de uso incluido de tal forma que simplifique el modelo?
¿Todos los casos de uso han sido identificados?
• ¿Los casos de uso identificados efectivamente dan cuenta de la funcionalidad requerida para
el sistema?
• ¿Todas las características identificadas en el documento Visión y que son aplicables a la
iteración han sido contempladas por al menos un caso de uso?
• ¿Los requisitos no funcionales que deben ser satisfechos por un caso de uso específico han
sido capturados en dicho caso de uso?
• ¿A verificado que el modelo de casos de uso no contiene comportamiento superfluo?
• ¿Cada caso de uso concreto está asociado con al menos un actor?
• ¿Todos los actores están asociados con al menos un caso de uso?
¿El modelo es consistente?
• ¿El comportamiento del sistema es consistente de tal forma que ofrezca los mismas salidas a
las mismas entradas?
¿Todas las relaciones entre los casos de uso son realmente requeridas?
• ¿Cada caso de uso incluido hace que el modelo sea más fácil de entender, implementar y
mantener?
• ¿Cada caso concreto es independiente de otros casos de uso?
¿Los paquetes de casos de uso están siendo utilizados de manera apropiada?
• Las dependencias entre paquetes han sido reducidas o eliminadas para prevenir conflictos de
ámbito y pertenencia dentro del modelo?
• ¿El empaquetado es intuitivo? ¿El empaquetado hace que el modelo sea más fácil de
entender e implementar?
¿Todos los elementos del modelo tienen un nombre apropiado?
• ¿Se ha verificado que los nombres de los casos de uso sean únicos?
• ¿Cada actor tiene un nombre que efectivamente describa su rol?
¿Los casos de uso individuales están especificados?
• ¿Se ha revisado la calidad de la especificación de cada caso de uso utilizando la lista de
Verificación?

6.3.4. Construcción del Documento “ Especificaciones de requisitos”
Este artefacto captura los equisitos en el ámbito del sistema que no hayan sido capturados en
escenarios o casos de uso, incluye requisitos sobre atributos de calidad y de desempeño global.
Los Casos de Uso describen los requerimientos de comportamiento para el sistema y los Requisitos
de Soporte describen requisitos globales del sistema que no son capturados en las Especificaciones
de los Casos de Uso. Hacer esta distinción simplifica el mantenimiento.
Los Requisitos de Soporte pueden ser categorizados de acuerdo al modelo FURPS+ (Funcionalidad,
facilidad de Uso, Confiabilidad, Desempeño, Facilidad de mantenimiento + Restricciones).
La figura a continuación ilustra la relación entre los Requisitos de Soporte, las Especificaciones de
Casos de Uso y los Actores.

Impacto de no contar con este artefacto
La meta de este producto de trabajo es asegurarse que todos los tipos de requisitos están cubiertos,
lo cual reduce el riesgo de no considerar alguna faceta importante del sistema. Los requisitos
FURPS+ son globales al sistema e influencian los Mecanismos de Arquitectura que se crearán,
también, guían el desarrollo de los fundamentos del sistema. Estos requisitos son frecuentemente los

gestionrequerimientosrequisitos

gestionrequerimientosrequisitos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

Destacado

Destacado (7)

Similar a gestionrequerimientosrequisitos

Similar a gestionrequerimientosrequisitos (20)

Último

Último (20)

gestionrequerimientosrequisitos