ISTP VIGIL APSTI ANALISIS Y DISEÑO DE SISTEMAS

SESION 06 - MODELADO DE REQUERIMIENTOS - TEORIA

1. CONCEPTOS ASOCIADOS A LOS REQUERIMIENTOS

La importancia de la definición, especificación, análisis y administración de requerimientos en un proyecto de

desarrollo de software es ampliamente reconocida; pues permite establecer las funcionalidades que deberá tener
el producto software a desarrollar, que correspondan con las necesidades del cliente/usuario; asimismo, sirve de
base para la planificación del proyecto y para verificar si el producto software es de calidad.

Muchos proyectos fracasan por una mala definición, especificación, análisis y administración de requerimientos;
la experiencia ha demostrado que las actividades relacionadas con los requerimientos son complejas debido a la
poca participación de los usuarios, al uso de lenguajes distintos entre desarrolladores y usuarios, a los cambios de
requerimientos, entre otras razones.

Por ello, es importante para el profesional involucrado en proyectos de desarrollo de software poseer las
suficientes competencias para la definición, especificación, análisis y administración de los requerimientos a fin
de afrontar con éxito estas tareas.
En esta lección se define y caracteriza el concepto de requerimientos y se describen técnicas para la captura de
los mismos.

1.1 REQUERIMIENTOS:

“Un requerimiento es una condición o capacidad a la que debe ajustarse el sistema que se construye.” (Jacobson,
2000, p.94)

De acuerdo con la IEEE Std. 610.12-1990, “un requisito es:

(1) Una condición o capacidad necesaria para un usuario para resolver un problema o conseguir un objetivo.
(2) Una condición o capacidad que debe reunir o poseer un sistema o componente de un sistema para satisfacer
un contrato, estándar, especificación, u otro documento formalmente impuesto.
(3) Una representación documentada de una condición o capacidad como las definidas en (1) o (2)” (IEEE, 1990,
p.64).
“Un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar
el sistema o una restricción de éste” (Somerville, 2005, p.108).

1.2 TIPOS DE REQUERIMIENTOS

Los requerimientos se pueden dividir en dos tipos: Requerimientos Funcionales y Requerimientos No funcionales.

1.2.1 REQUIRIMIENTO FUNCIONAL

Un Requerimiento funcional es un requerimiento que especifica una acción que debe ser capaz de
realizar el sistema, sin considerar restricciones físicas; es un requisito que especifica comportamiento
de entrada / salida del sistema (Jacobson, 2000).
El requerimiento o requisito funcional describe que debe hacer el sistema respecto a su entorno. En
otras palabras, refleja las necesidades de los usuarios o la interacción con otros sistemas.

Por ejemplo, los usuarios de un Sistema de Gestión Académica para la Universidad pueden ser
profesores y alumnos, algunos requerimientos funcionales son:

Ing. Ricardo Nina mail: rnina@iesp.edu.pe Pág.1

IESP- VIGIL APSTI ANALISIS Y DISEÑO DE SISTEMAS
El sistema permitirá a los profesores:
 Consultar los horarios de sus asignaturas
 Consultar la programación de los exámenes
 Actualizar y ver su información personal
 Registrar y modificar las notas de los estudiantes a su cargo.

Ing. Edwin Valencia e-

El sistema permitirá a los estudiantes:
 Consultar los horarios de sus asignaturas
 Consultar la programación de los exámenes  Actualizar y ver su información personal 
Consultar notas de una asignatura.

1.2.2 REQUERIMIENTO NO FUNCIONAL

Un Requerimiento No funcional es un requerimiento que especifica propiedades del sistema, como

restricciones del entorno o de implementación, rendimiento, dependencia de la plataforma,
mantenibilidad, extensibilidad o fiabilidad; especifica restricciones físicas sobre un requisito funcional
(Jacobson, 2000).

Un requerimiento no funcional describe atributos del sistema o del ambiente en donde éste se
desarrolla.

Algunos ejemplos de requerimientos no funcionales son:

 El sistema debe brindar una interfaz de usuario intuitiva y sencilla, con un buen mecanismo de
ayuda on-line.
 El sistema debe disponer de una documentación adecuada que facilite las tareas de
mantenimiento.
 La tasa de disponibilidad del sistema debe ser de un 99%.

1.3 CLASIFICACION DE REQUERIMIENTOS: MODELO FURPS

Una manera de categorizar los requerimientos está descrita en el modelo FURPS (Larman, 2002), los
requerimientos se clasifican en requerimientos de: Functionality (Funcionalidad), Usability (Capacidad
de Uso), Reliability (Fiabilidad), Performance (Desempeño) y Supportability (Capacidad de Soporte).

Los Requerimientos de Funcionabilidad (Functionality) son aquellos requerimientos que reflejan las
características fundamentales (requerimiento funcional o funcionalidades del sistema), además de
capacidades y seguridad.

Los requerimientos de usabilidad o Capacidad de Uso (Usability), son aquellos requerimientos que
representan facilidad o nivel de uso del producto; es decir, el grado en el que el diseño de un elemento
facilita o dificulta su manejo. Se incluyen: Factores humanos, Estética, Consistencia de la interfaz de
usuario, Ayudas en línea, Agentes y wizards, Documentación de usuario y material de entrenamiento.
Por ejemplo, Visibilidad del texto a una cierta distancia y Combinación de colores del texto.

Los requerimientos de Fiabilidad (Reliability, son aquellos que muestran la capacidad de un sistema o
componente para ejecutar las funciones requeridas bajo condiciones normales en un periodo de
tiempo específico. Tiene las siguientes sub-categorías: Disponibilidad (el porcentaje de tiempo
disponible, horas de uso, acceso para mantenimiento, etc.); Tiempo medio entre fallas; Tiempo medio
para reparación, cuánto tiempo es posible que el sistema esté inoperante después que falla; Exactitud

Ing. Ricardo Nina e-mail: rnina@iesp.edu.pe Pág.2

IESP- VIGIL APSTI ANALISIS Y DISEÑO DE SISTEMAS
(precisión y exactitud, según algún estándar conocido) que se requiere para las salidas del sistema;
Cantidad máxima de errores o porcentaje de defectos, generalmente expresado en términos de
errores por miles de líneas de código o errores por punto funcional;

Errores o porcentaje de defecto, categorizados en términos de errores menores, significantes y críticos

(se debe definir qué significa error “crítico”, por ejemplo pérdida completa de dato o imposibilidad de
uso de ciertas funcionalidades del sistema.

Los requerimientos de Desempeño (Performance), se refieren a las características de rendimiento del

sistema. Incluye tiempos de respuesta específicos. Por ejemplo: Tiempo de respuesta para una
transacción (promedio, máximo); Transacciones por segundo; Capacidad, como por ejemplo el
número de clientes o transacciones que el sistema puede soportar; Modos de degradación, esto es,
cual es el modo aceptable de funcionamiento cuando el sistema ha sido degradado de alguna manera;
Utilización de recursos: memoria, disco, comunicaciones, etc.

Los requerimientos de Capacidad de Soporte (Supportability), son requerimientos que refuerzan el

soporte y mantenimiento del sistema que está siendo construido, incluyendo normas de codificación,
convenciones de nombres, librerías, acceso para mantenimiento, utilidades de mantenimiento si las
hay. Como requerimiento que ayuda al mantenimiento se debe hacer referencia al uso de
nomenclatura común para el desarrollo del sistema, y a la metodología de desarrollo.

ALGUNOS REQUERIMIENTOS FUNCIONALES DEL SISTEMA DE GESTION DE HORARIOS PARA LA FACULTAD DE

INGENIERIA DE SISTEMAS, CÓMPUTO Y TELECOMUNICACIONES
El sistema permitirá al secretario académico, introducir las asignaturas que se imparten en el semestre
académico, los datos del docente asignado a cada sección, de teoría y práctica, de la asignatura, los datos de las
aulas de teoría (ubicación y aforo) y de prácticas (ubicación, sistemas operativos, software,...).
La configuración del horario se lleva a cabo directamente sobre una plantilla horaria semanal, en la que cada
casilla representará una hora en un determinado día de la semana. Cuando el Secretario pulsa esa casilla se
mostrarán las asignaturas del curso que se esté configurando en ese momento. Una vez escogida las asignaturas
se mostrarán las secciones de teoría y práctica a los que todavía no se les ha asignado un horario. Al escoger una
sección se muestran las aulas disponibles (si es un grupo de teoría) o los laboratorios que cumplen las
restricciones de sistemas operativos establecidas para esa materia y que no están ocupados a esa hora. El
sistema podrá ser consultado por cualquier usuario, que podrá consultar el horario de una asignatura, un ciclo,
o de un aula o laboratorio concretos.

ALGUNOS REQUERIMIENTOS NO FUNCIONALES DEL SISTEMA DE GESTION DE HORARIOS PARA LA FACULTAD DE

INGENIERIA DE SISTEMAS, CÓMPUTO Y TELECOMUNICACIONES
La tasa de disponibilidad del sistema debe ser de un 99%. El sistema debe tener una interfaz de uso intuitiva y
sencilla, complementada con un buen sistema de ayuda. El sistema debe disponer de una documentación
fácilmente actualizable que permita realizar operaciones de mantenimiento con el menor esfuerzo posible.

1.4 CARACTERISTICAS DE LOS REQUERIMIENTOS

Un requerimiento debe ser:

 Especificado por escrito, como todo contrato o acuerdo entre dos partes.
 Posible de probar o verificar, si un requerimiento no se puede comprobar, entonces, ¿cómo se sabe
si se cumplió con él o no?
 Conciso, un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y
clara para aquellos que vayan a consultarlo en el futuro.
 Completo, un requerimiento está completo si no es necesario ampliar detalles en su redacción, es
decir si se proporciona la información suficiente para su comprensión.
 Consistente, un requerimiento es consistente si no es contradictorio con otro requerimiento.

Ing. Ricardo Nina e-mail: rnina@iesp.edu.pe Pág.3

IESP- VIGIL APSTI ANALISIS Y DISEÑO DE SISTEMAS
 No ambiguo, un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje
usado en su definición, no debe causar confusión en el lector.

1.5 DIFICULTADES PARA DEFINIR LOS REQUERIMIENTOS

 Los requerimientos no son obvios y vienen de muchas fuentes

 Son difíciles de expresar en palabras (el lenguaje es ambiguo)
 La cantidad de requerimientos en un proyecto puede ser difícil de manejar  Un requerimiento
puede cambiar a lo largo del ciclo de desarrollo.
 El usuario no puede explicar lo que hace.
 El usuario tiende a recordar lo excepcional y olvidar lo rutinario
 Hablan de lo que no funciona
 Los usuarios tienen distinto vocabulario que los desarrolladores  Usan el mismo término con
distinto significado.

1.6 TECNICAS PARA OBTENER EL REQUERIMIENTO

1.6.1 ENTREVISTAS

Esta técnica es adecuada para la primera toma de contacto. Es conveniente comenzar por preguntas
de contexto libre, para entender: el problema, a las personas interesadas en la solución, naturaleza de
ésta, y lograr efectividad de la reunión.

Ejemplos de preguntas centradas en el cliente, los objetivos globales y beneficios 

¿Quién solicita el trabajo?
 ¿Quién utilizará la solución?
 ¿Cuál será el beneficio económico de una buena solución?
 ¿Existen otras alternativas a esta solución?

Ejemplos de preguntas sobre el problema y la solución 

¿Qué entiende el cliente por una solución “correcta”?
 ¿Qué problemas afrontará esta solución?
 ¿En qué entorno se va a implantar la solución?
 ¿Existen restricciones o aspectos de rendimiento importantes?

Ejemplo de preguntas sobre la efectividad de la reunión

 ¿Es usted la persona adecuada para responder a estas preguntas? ¿Sus respuestas son
“oficiales”?
 ¿Son relevantes mis preguntas para su problema?
 ¿Hay alguien más que pueda proporcionar información adicional?
 ¿Hay algo más que debería preguntar?

Problemas de las entrevistas:

 Pueden surgir malentendidos
 Omisión de información
 Mala relación de trabajo (“nosotros-ellos”)

1.6.2 JAD

Ing. Ricardo Nina e-mail: rnina@iesp.edu.pe Pág.4

IESP- VIGIL APSTI ANALISIS Y DISEÑO DE SISTEMAS
El Diseño en Conjunto de Aplicaciones (JAD, “Joint Application Design”) fue desarrollado por IBM a
finales de los setenta. Es una sesión de trabajo con participación de todos los involucrados. El resultado
de la sesión es un documento de especificación que incluye definiciones de elementos de datos, flujos
de trabajo y pantallas de interfaz.
El resultado de una sesión JAD representa un acuerdo entre usuarios, clientes y desarrolladores y
minimiza los cambios posteriores de requerimientos.
Las actividades de la sesión JAD son: Definición del proyecto, Investigación, preparación, Sesión,
preparación del documento final.

Definición del proyecto: el coordinador se entrevista con gerentes y clientes para determinar
objetivos y alcance del proyecto. Se elabora la “guía de definición administrativa”.

Investigación: se entrevista a usuarios y se recopila información del dominio, descripción de flujos de

trabajo y asuntos a tratar en la reunión. Se elabora la “agenda de sesión” y la “especificación
preliminar”.

Preparación: el coordinador elabora un “documento de trabajo” o primer borrador del documento

final.

Sesión: el coordinador guía al equipo para crear la especificación del sistema en una reunión que
puede durar varios días. Se definen los flujos de trabajo, elementos de datos, pantallas, informes, etc.
Las decisiones se documentan en unos formularios.
Preparación de documento final: el coordinador prepara el “documento final” usando los
“formularios” y se distribuye a los asistentes para su revisión. Se realiza una reunión para discutir
revisiones y finalizar el documento.

1.7 CAPTURA DE REQUISITOS A PARTIR DEL DIAGRAMA DE ACTIVIDADES DEL NEGOCIO

Mediante la utilización del modelo del negocio como entrada, el analista emplea una técnica sistemática
para crear un modelo de casos de uso tentativo. Para ello, construirá un diagrama de casos de uso
tomando como punto de partida los diagramas de actividades de los casos de uso del negocio.

En primer lugar, se obtienen los requisitos funcionales a partir de las actividades candidatas a ser informatizadas.
Luego, con estos requisitos, se crean los casos de uso. Las actividades que no serán soportadas por el sistema no
les corresponderán un caso de uso. Los actores se identificarán a partir de los roles (trabajadores o actores del
negocio) que realizan las actividades del negocio a informatizar.

Es importante documentar el seguimiento de estos elementos: actividades a informatizar, requisitos

funcionales y casos de uso; más aún, si se trata de seguir requisitos funcionales de casos de uso, el cual
es un proceso complicado por el hecho de que existe una relación muchos a muchos entre ellos. Un caso
de uso puede tratar muchos requisitos funcionales y un requerimiento funcional puede estar presente
en varios casos de uso diferentes.

Afortunadamente, existen herramientas de ingeniería de requisitos, como el RequisitePro y DOORS. Pero

si no tiene ningún soporte de herramienta de modelado, tiene que hacer el trabajo manualmente. Un
buen enfoque es crear una matriz denominada Matriz de actividades Vs. requisitos. Estas matrices se
crean a menudo en hojas de cálculo (Excel). La plantilla se proporciona en la Tabla 3.2.

Ing. Ricardo Nina e-mail: rnina@iesp.edu.pe Pág.5

IESP- VIGIL APSTI ANALISIS Y DISEÑO DE SISTEMAS

Matriz de Actividades Vs. REquisitos del Sistema <Nombre del Sistema>

Proceso de Actividad del Responsable del

Negocio Negocio Requisito Caso de Uso Actores
Negocio

R01 CUS01

Proceso 1
R02 CUS02

R03 CUS03

R04 CUS04

Proceso 2
R05 CUS05

R06 CUS06

Tabla Plantilla de matriz de actividades y requisitos.

Una matriz de actividades Vs. requisitos es una herramienta manual utilizada para obtener requisitos
funcionales a partir de actividades del negocio que se van a informatizar. Una vez identificado los
requisitos funcionales, se crean los casos de uso. Por otro lado, los actores son creados a partir de los
responsables de las actividades del negocio que se tienen en la matriz.

Examinemos un ejemplo para capturar requisitos a partir de un diagrama de actividades del negocio para
un sistema de créditos XYZ. En la figura 3.5, se muestra el diagrama de actividades del caso de uso de
negocio “otorgamiento de Créditos”; las actividades sombreadas se identificaron para ser informatizadas.

Ing. Ricardo Nina e-mail: rnina@iesp.edu.pe Pág.6

IESP- VIGIL APSTI ANALISIS Y DISEÑO DE SISTEMAS

Ing. Ricardo Nina e-mail: rnina@iesp.edu.pe Pág.7

IESP VIGIL APSTI ANALISIS Y DISEÑO DE SISTEMAS
IESP VIGIL APSTI ANALISIS Y DISEÑO DE SISTEMAS
La matriz de actividades Vs. requisitos para el sistema de créditos XYZ es el siguiente:

Tabla Matriz de actividades y requisitos del sistema de créditos XYZ.

Observaciones:

• Note que, para el requerimiento R02 y R04, se crea el mismo caso de uso, esto es, debido a que ambos requisitos dan
lugar al criterio de búsqueda del CU Consultar Solicitudes por Estado.
• Por otro lado, fue necesario crear el actor Visualizador de Solicitudes para el Inspector y Jefe de Créditos, pues dos
actores no pueden iniciar el mismo caso de uso.
• Por último, los requisitos R05, R06, R07 y R08 dieron lugar al caso de uso Evaluar Crédito porque serán definidos como
subflujos en la Especificación del CU Evaluar Crédito.

Ing. Ricardo Nina e-mail : rnina@iesp.edu.pe pág. 9