Í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
Opciones de Representación.....................................................................................................34
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
Opciones de Representación.....................................................................................................40
Lista de Verificación .......................................................................................................40
6.3.4. Construcción del Documento “ Especificaciones de requisitos”.........................................42
Impacto de no contar con este artefacto....................................................................................42
Opciones de Representación.....................................................................................................43
Lista de Verificación ............................................................................................................43
6.3.4. Construcción del Glosario...................................................................................................45
Propósito...................................................................................................................................45
Consideraciones claves.............................................................................................................45
Impacto de no tenerlo................................................................................................................45
Opciones de Representación.....................................................................................................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”
Artefactos
Nombre de la  Responsa­
Descripción  Relacionados Guías
Actividad bles
(Procductos)
1.   Definitr   o   Una necesidad es una demanda que expresa  Analista Solicitud de 
Ajustar   Nece­ una   persona(s),   dependencia(s)   o   instancia  Interesados Necesidad 
sidad(s) 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. 
2. Elaboración   Un   requerimiento   es   la   descripción   precisa   y  Analista  Lista Maestra  ­ Los requerimientos y los re­
o actualización   clara de una necesidad funcional en términos  de requeri­ quisiitos
de la lista ma­ de lo que debe hacer el sistema. Una necesi­ mientos ­ Detallando un requerimien­
estra de re­ dad puede descomponerse  en varios requeri­ to(s) o requisito(s)
querimiento(s)   mientos   dependiendo   de   la   manera   como   se  ­Tecnicas de Captura de re­
haya definido.  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   Con base en las necesidades de los interesa­ Analista Visión  ­ Construcción del 
y actualización   dos, los requerimientos y los requisitos de alto  documento visión
del documento  nivel definidos por el analista se plantea la si­
Visión tuación problematica y la posible solución infor­
matica para los interesados.
4. Elaboración   A medida que se definen y ajustan las necesi­ Analista Glosario  ­Construcción del Glosario
y actualización   dades y requerimientos de los interesados, se  Interesados
Documento   construye   y   unifican   cierta   terminología   entre 
Glosario los interesados y el equipo de trabajo con el fin 
de   que   exista   una   buena   comunicación   entre 
los mismos.    
5. Elaboración   Un   requerimiento   responde   a   una   necesidad  Analista Documento “  ­ La construcción del 
y actualización   funcional del sistema, mientras que un requisito  Especificación  documento “ 
del documento  representa una necesidad técnica en terminos  de requisitos” Especificaciones de 
“ Especifica­ de   usabilidad,   confiabilidad   ,   disponibilidad   y  Requisitos”
ción de Requi­ seguridad del sistema.
sitos”
6. Aprobación   Luego de una revisión de la visión por parte de  Interesados Acta ­ Construcción del documen­
de la Visión  los interesados, estos evaluan si aprueba o no  to visión
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. 
7. Aprobación   Al igual que con el documento visión, los inte­ Interesados Acta   Los requerimientos y los re­
de los Reque­ resados deben dar su aval cuando se define un  quisiitos
rimientos  requerimiento y en caso de que no se aprue­ ­ Detallando un requerimien­
ben deberán ser ajustados para su futura apro­ to(s) o requisito(s)
bación.  ­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   Con base en los requerimientos aprobados, se  Analista ­Modelo de  ­Construcción de los casos 
modelos, ca­ procede   a   detallarlo   mediante   diagramas,   ca­ Casos de Uso. de uso
sos y especifi­ sos y especificaciones de casos de uso.  ­Caso de Uso  ­ Construccion de los mode­
caciones de   de alto  los de casos de uso
uso ­Especificación 
de caso de uso
9. Diseño, de­ Este procedimiento (Gestión de requerimientos  Equipo de  ­ Revisar los capitulos si­
sarrollo y des­ y requisitos) es el insumo para llevar a cabo el  Desarrollo guientes
pliegue de los   diseño, desarrollo y despliegue del software 
requerimientos  
y requisitos.
10. Control de   A medida que surgen los cambios propios del  Analista ­ Visión ­ Revisar capitulo “ Gestión 
Cambios dise­ proceso   de   desarrollo   (Anáisis,   diseño,   desa­ ­ Lista  Maes­ de Cambios”
ño, desarrollo   rrollo , despliegue) , es necesario ajustar la do­ tra de Requeri­
y depliegue   cumentación   propia   de   la   gestión   de   requeri­ mientos
del software.  mientos y requisitos, como la visión, el glosario,  ­ Especifica­
los casos de uso de alto nivel, las especifica­ ción de requisi­
ción   de   requisitos   y   lista   maestra   de   requeri­ tos
mientos.  ­ Modelo, caso 
de uso de alto 
nivel y especifi­
caciones de 
casos de uso
 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 socio­económico. 
El Jefe de Admisiones debe ser capaz de actualizar la información del estrato socio­econó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. 

Opciones de Representació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 “si­entonces”. 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 sub­flujos. 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 pos­condiciones
Una precondición es el estado en que el sistema, y su contexto, debe estar para que el caso de uso 
pueda iniciarse. Las post­condiciones 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 post­condiciones

 
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 post­condiciones 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 re­elaboraciones 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.

Opciones de Representación
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 sub­flujos 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 
elementos de mayor costo, porque estos determinan las opciones arquitectónicas. 
Además, si usted no captura los requisitos globales del sistema en un lugar central, pero los repite a 
través de los Casos de Uso, el resultado será más mantenimiento y más opciones de cometer errores. 

Opciones de Representación
Este producto de trabajo no implica usar únicamente un documento para capturar todos los tipos de 
requerimientos. Para administrar la comunicación de la información, tiene más sentido organizar la 
información en documentos separados o usar la Lista de Elementos de Trabajo. 
Las siguientes son recomendaciones y opciones para representar los Requisitos de Soporte. 

Opción: Uso la Lista de Unidades de Trabajo 
Considere capturar los Requisitos de Soporte en las listas de unidades de trabajo, para priorizarlos y 
administrarlos. Si los Interesados (Stakeholders) están cómodos con este o con acceder un reporte 
automáticamente generado desde este, entonces usted no necesita un documento separado. 
Opción: Incluirlos como Parte del Documento Visión 
Considere   incluir   algunos   tipos   de   Requisitos   de   Soporte   en   la   Visión.  Para   conservar   la   visión 
estable, siga esta opción para los tipos de requisitos que necesitan menos refinamiento, tales como 
Calidad del Producto, Documentación o Conformidad. 
Recomendación: Use la Plantilla de Especificación de Requisitos de Soporte 
Aún en un proyecto pequeño, una herramienta de administración de requisitos, una base de datos o 
una hoja de cálculo,  son recomendadas  para priorizar  y  administrar  requisitos.  Si los  Interesados 
(Stakeholders) están cómodos con acceder directamente los requisitos desde esta herramienta o con 
acceder un reporte automático generado desde la herramienta, usted no necesitará un documento 
separado. 

Lista de Verificación
¿ Los requisitos de facilidad de uso que serán implementados en la próxima iteración han sido 
capturados y validados?

¿Los requisitos de confiabilidad que serán implementados en la próxima iteración han sido 
capturados y validados?
• ¿Los requisitos de confiabilidad han sido especificados como requisitos cuantificables o como 
 metas de diseño priorizadas? 
• ¿Se requiere chequeo y recuperación de errores? 
• ¿Los   eventos   no   deseados   han   sido   considerados?   ¿Los   respuestas   requeridas   a   tales 
eventos están especificadas?
• ¿Los estados iniciales o especiales están considerados?  

¿ Los requisitos de desempeño que serán implementados en la próxima iteración han sido 
capturados y validados?
• ¿ Los requisitos de márgenes de uso de recursos y desempeño están definidos?  (por ejemplo, 
velocidad, tiempos de respuesta, tiempos de recuperación) 

¿ Los requisitos de mantenimiento que serán implementados en la próxima iteración han sido 
capturados y validados?
• ¿Existen requisitos que deban cumplirse para mejorar el grado de mantenimiento al aire del 
sistema que se está construyendo?

¿ Las restricciones que deben ser consideradas en la próxima iteración han sido capturadas y 
validadas?
• ¿ Existen restricciones de estándares, lenguajes de implementación, políticas de integridad de 
las bases de datos, límites de recursos, ambientes operativos, etc ?
• ¿Se ha considerado el uso de diseños heredados, código o herramientas pre seleccionadas?

¿   Las   interfaces   externas   que   deben   ser   consideradas     en   la   próxima   iteración   han   sido 
capturadas y validadas?
• ¿Esta claro como el software interactuará con las  personas,  el hardware del sistema,  otro 
hardware u otro software?
• ¿Los datos críticos que sobrepasan las fronteras del sistema han sido identificados para los 
casos de uso y escenarios de la próxima iteración?

¿   Las   reglas   del   negocio   que   deben   ser   consideradas     en   la   próxima   iteración   han   sido 
capturadas y validadas?
• ¿ Las reglas relevantes que aplican a los  casos de uso han sido identificadas? (reglas  de 
validación de datos, formulas, flujos de decisiones)

¿ Los estándares aplicables y cumplimientos normativos que deben ser considerados   en la 
próxima iteración han sido capturados y validados?
• ¿Se han identificado los requisitos derivados de estándares y regulaciones existentes? 
6.3.4. Construcción del Glosario
Este artefacto define términos importantes usados en el proyecto. Estos términos son esenciales para 
lograr una colaboración efectiva entre los Interesados y otros integrantes del equipo. 

Propósito
El objetivo del Glosario es proporcionar un vocabulario común aceptado por todos los Interesados. 
Este puede ayudar a las personas desde diferentes grupos funcionales a alcanzar un entendimiento 
mutuo del sistema. La meta no es registrar todos los términos posibles, sino únicamente aquellos que 
son inciertos, ambiguos o requieren elaboración. 

El Glosario le ayuda a evitar errores conceptuales al proporcionar dos recursos esenciales: 
• Una ubicación central para consultar los términos y abreviaciones que son nuevas para los 
miembros del equipo de desarrollo.
• Las definiciones de términos que son usados en forma específica dentro del dominio.
Las definiciones para los términos del Glosario provienen de varias fuentes, tales como documentos 
de requisitos, especificaciones y discusiones con Interesados y expertos en dominio. 

Consideraciones claves
En algunos proyectos que no incluyen modelos del negocio o del dominio, el Glosario es el principal 
artefacto para capturar información sobre el dominio del negocio del proyecto. 
Aunque si bien son listados como una salida desde y una entrada a las tareas asociadas con la 
disciplina de requisitos, este artefacto puede ser actualizado en cualquier momento, por cualquier rol, 
cuando nuevos términos sean identificados.

Impacto de no tenerlo
Los   errores   conceptuales   acerca   del   significado   de   datos   de   elementos   conllevan   al   fracaso   de 
muchos proyectos. Algunos de estos empiezan a ser obvios únicamente en las fases posteriores a las 
prueba del sistema y puede ser extremadamente costoso corregirlos. 

Opciones de Representación
El Glosario es una lista simple de términos del dominio y sus definiciones. Se puede publicar esta lista 
sobre un sitio Wiki para simplificar el acceso y el mantenimiento.