REQUERIMIENTOS

CALIDAD DE SOFTWARE
2012-01
 OBJETIVOS

• Llegar a un acuerdo formal con los clientes y usuarios sobre lo

que el sistema debe hacer.

• Proporcionar a los miembros del proyecto una idea clara de los

requisitos del sistema.

• Delimitar las fronteras del sistema.

• Proporcionar las bases para la planificación del contenido técnico

de las iteraciones.

• Proporcionar las bases para estimar los costos y el tiempo de

desarrollo del sistema.

• Definir la interfaz gráfica del sistema.

¿QUÉ ES UN REQUERIMIENTO?

Descripciones que hace el usuario de los

deseos o necesidades que tiene de un
producto al equipo de desarrollo.
¿DÓNDE IDENTIFICAR REQUERIMIENTOS?

Actividades
del negocio
Clientes

Analistas

Socios
Usuarios

4
¿CÓMO CAPTURAR REQUERIMIENTOS?

• Entrevistas.
• Cuestionarios.
• Encuestas.
• Sondeos.
• Diagramas de procesos y workflows.
• Casos de uso del negocio.
• Diagramas de actividades de los procesos del negocio.
 REQUERIMIENTO VS. REQUISITO

• Los requerimientos originan REQUISITOS que se deben

cumplir para poder llegar a lograr los requerimientos.

Necesidad Requerimiento

Necesario para
cubrir la Requisito
necesidad
 REQUISITOS

•Una descripción de algo que el sistema es capaz de hacer

con el objeto de satisfacer las necesidades del cliente.

•Una característica del Sistema

•Propiedades o restricciones determinadas de forma

precisa que deben satisfacerse.
 ¿POR QUÉ SON IMPORTANTES LOS
REQUISITOS?
En 1994 el Standish Group hizo un estudio sobre 350 compañías
y cerca de 8000 proyectos de software para averiguar cómo
iban.
Los resultados fueron desalentadores:

•El 31% de los proyectos de software fueron cancelados antes

de completarse.
•En las grandes compañías, sólo el 9% de los proyectos fue
entregado en término y dentro del costo presupuestados;
•En las pequeñas empresas sólo el 16% cumplió con los tiempos
y costos definidos inicialmente.
 ¿POR QUÉ SON IMPORTANTES LOS
REQUISITOS?
Los principales factores fueron:

• Requisitos incompletos (13,1%).

• Falta de compromiso del usuario (12,4%).
• Falta de recursos (10,6%).
• Expectativas no realistas (9,9%).
• Falta de soporte ejecutivo (9,3%).
• Requerimientos y especificaciones cambiantes (8,7%).
• Falta de planeamiento (8,1%).
• Fin de la necesidad del sistema (7,5%).
 ¿POR QUÉ SON IMPORTANTES LOS
REQUISITOS?

• Si cuesta $1 identificar y subsanar un problema debido a

requerimientos, durante la etapa de definición de
requisitos;

• Puede costar $5 repararlo durante el diseño

• $10 durante la codificación

• $20 durante la prueba unitaria

• y hasta $200 después de la entrega del sistema.

 PROPÓSITO DE LOS REQUISITOS

• Permiten que los analistas expliquen cómo han

entendido lo que el cliente y usuarios esperan del
sistema.
• Indican a los diseñadores qué funcionalidad y
características va a tener el sistema resultante.
• Establecen para los desarrolladores la especificación
del comportamiento del sistema.
• Indican a los testeadores qué demostraciones llevar a
cabo para que el cliente se convenza de que el sistema
que se le entrega es lo que había solicitado.
 CLASIFICACIÓN

• FUNCIONALES

• NO FUNCIONALES
 REQUISITOS FUNCIONALES

• Especifica lo que debe hacer el sistema en relación a su

entorno (usuarios u otros sistemas) sin tener en cuenta
restricciones físicas.

• Cómo debe reaccionar ante los estímulos que recibe

• Cómo el sistema debe comportarse en situaciones

particulares.
 REQUISITOS FUNCIONALES

Ejemplo:

El sistema deberá:

•Actualizar la información de los profesores.

•Consultar los horarios de los cursos.
•Registrar reglas de evaluación.
•Consultar la programación de los exámenes.
•Cerrar un curso.
 REQUISITOS NO FUNCIONALES

• Definen las propiedades y restricciones del sistema a

construir o sobre el proceso que lo construirá

• Los requisitos no funcionales, suelen ser mas críticos

que los funcionales, dado que su incumplimiento puede
hacer inútil el sistema.
 REQUISITOS NO FUNCIONALES

A los requisitos no funcionales se les suele llamar

coloquialmente “cualidades” del sistema y pueden
dividirse en dos categorías:

•Cualidades de ejecución, como la seguridad o la

usabilidad, observables en tiempo de ejecución.

• Cualidades de evolución, como la testabilidad,

mantenibilidad, escalabilidad, determinadas por la
estructura estática del software.
 REQUISITOS NO FUNCIONALES

• Estos están clasificados según el tipo de restricción que

se quiera implementar

• Rendimiento del sistema:

Fiabilidad, tiempo de respuesta, disponibilidad…
• Interfaces:
Dispositivos de E/S, usabilidad, interoperabilidad…
• Proceso de desarrollo:
Estándares, herramientas, plazo de entrega…
Los Requisitos Funcionales definen
qué debe hacer un sistema

Los Requisitos No Funcionales

definen cómo debe ser el sistema.
 ESPECIFICACIÓN DE REQUISITOS

Los Requisitos ….

•Se especifican en lenguaje natural,

•Se expresan de forma individual

•A menudo, se codifican (para facilitar su gestión)

 ESPECIFICACIÓN DE REQUISITOS

Los requisitos han de ser …

•Claros y concretos: evitando ambigüedades e imprecisiones

•Completos: Todas las necesidades deben estar reflejadas.

•Consistentes: No debe existir contradicción entre requisitos.

•Comprobables: Se debe poder determinar si se cumple o no.

 ESPECIFICACIÓN DE REQUISITOS

Los requisitos han de indicar…

•Lo que se espera que haga el sistema (¿qué?),

•Su justificación (¿por qué ha de ser así? ¿quién lo propuso?)

•Los criterios de aceptación que sean aplicables (¿cómo se

verifica su cumplimiento?).
 ESPECIFICACIÓN DE REQUISITOS

Los requisitos Funcionales …..

•Deben estar redactados de tal forma que sean comprensibles

para usuarios sin conocimientos técnicos avanzados.

• Deben especificar el comportamiento externo del sistema y

evitar, en la medida de lo posible, establecer características
de su diseño,

• Deben priorizarse (al menos, se ha de distinguir entre

requisitos obligatorios y requisitos deseables).
 ESPECIFICACIÓN DE REQUISITOS

Los Requisitos No Funcionales …

•Han de especificarse cuantitativamente, siempre que sea

posible (para que se pueda verificar su cumplimiento).
 ESPECIFICACIÓN DE REQUISITOS

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

¿Por qué?
Mezcla de varios requisitos.
 ESPECIFICACIÓN DE REQUISITOS

BIEN
El editor permitirá el uso de una rejilla de líneas horizontales y
verticales que aparecerán dibujadas tras el diagrama.

Justificación: La rejilla facilita la creación de diagramas cuidados en

los que las figuras se puedan alinear con facilidad.

¿Por qué?

Preciso, conciso y justificado correctamente.

 ESPECIFICACIÓN DE REQUISITOS

MAL
•El sistema será lo más fácil de utilizar posible.
•El sistema proporcionará una respuesta rápida al usuario.
•El sistema se recuperará automáticamente tras
producirse un fallo.

¿Por qué?
Objetivos generales, vagos y abiertos a distintas
interpretaciones.
 ESPECIFICACIÓN DE REQUISITOS

BIEN

Un usuario experimentado debe ser capaz de utilizar todas las

funciones del sistema tras un entrenamiento de 2 horas, tras el cual
no cometerá más de 3 errores diarios en promedio.

Cuando haya hasta 100 usuarios accediendo simultáneamente al

sistema, su tiempo de respuesta no será en ningún momento superior
a 2 segundos.