Principios de Ingeniería de

Software
UNIDAD 3 – ANALISÍS
«Requisitos»
Algo de historia

● Cuando se creó el termino

«Ingeniería de Software», en 1969, no
se mencionaban los requisitos.

• El término Ingeniería de requisitos, empezó a utilizarse en 1993

• En 2007 se funda el «International

Requirements Engineering Board». Definen un
currículo y una certificación.
Reflexión

Una definición de CALIDAD es:

«El grado que un producto, proceso o sistema cumple con sus
requisitos»
(IEEE 610,12)

Si los requisitos no están bien definidos no se obtendrá un

producto de calidad.
Para pensar…
El porcentaje de defectos que se originan durante la ingeniería de requisitos se
estima en un 50% .
Karl Wiegers

Los analistas reportan que cerca del 71% de los proyectos de software que fracasan,
lo hacen por un pobre manejo de los requisitos.
CIO Magazine

Como muchos requisitos se escriben en lenguaje natural, los directivos a menudo

piensan que cualquier persona puede hacer ingeniería de requisitos.
Donald Firesmith
Pero en realidad:
“ … Obtener un buen conjunto de requisitos es un proceso muy difícil.”
Ed Meagher, Government Computer News

Debemos entender qué vamos a desarrollar antes de desarrollarlo.

Las estadísticas muestran que esto todavía no se cumple.

Deb Jacobs, CrossTalk
Por lo tanto:

¡Invertir en los procesos de requisitos vale la

pena!
Glosario…

Elicitatción: Se usa esta palabra en lugar de

capturar, obtener o adquirir requisitos para
resaltar que no se trata simplemente de
recolectar información.

Stakeholder: Hace referencia a la

persona o entidad que afecta o se ve
afectada directa o indirectamente por
el sistema. Incluye los usuarios, los
clientes, los desarrolladores, los entes
reguladores, entre otros.
Glosario…

Requerimiento: Acción y efecto de requerir.

Requisito: Circunstancia o condición necesaria para

algo.
¿Qué es un requisito de software?

Glosario de IEEE (1997):

● Una condición o capacidad que necesita un usuario para resolver un
problema o lograr un objetivo.
● Una condición o capacidad que debe tener un sistema o un componente
para satisfacer un contrato, especificación u otro documento
formalmente impuesto.

SWEBOK
Una propiedad que debe presentar el software, para resolver un problema
del mundo real.
Requisito

● Los requisitos están en la cabeza de las personas.

● Se debe llegar a un entendimiento compartido por todos los

interesados.
Problemas…

● Los usuarios no saben lo que quieren.

● Un sistema tiene muchos usuarios y ninguno tiene una visión de

conjunto.

● No saben cómo hacer más eficiente la operación en su conjunto.

● No saben qué partes de su trabajo pueden transformarse en software.

● No saben detallar lo que saben de forma precisa.

¿Qué se busca?

● Requisitos
Los detalles sobre lo que se debe de hacer.

● Viabilidad
Saber si se va a poder hacer o no.

● Alcance
Cuánto de lo que se podría hacer se va a dar a tiempo y con la
gente que se tiene.
Niveles de requisitos

Del negocio
Objetivos generales de la organización o los clientes
Del usuario
Objetivos del usuario
Del software Funcionales

Funciones detalladas
No Funcionales
1. Fase de inicio
2. Obtención
3. Elaboración
4. Negociación
5. Especificación
6. Validación
Errores
Complejidad
Requerimientos
de Software
Requerimientos funcionales – no funcionales
Requerimientos funcionales

● Lo que el sistema debe hacer

● Las funciones que debe tener
● Son implementados por los desarrolladores
● Pueden contener algunos aspectos técnicos

Estructura gramatical
● Sujeto – Verbo – Objeto directo
Ejemplo:
El sistema- permitirá adicionar – los datos del cliente
Ejemplos de RF
• El sistema deberá asignar un número único a cada
orden de pedido.

• El sistema permitirá a un usuario registrado en el

sistema, colocar una orden para una comida.

• El sistema permitirá adicionar, modificar, eliminar

y consultar los datos del cliente, el proveedor y la
sucursal.
Requerimientos no funcionales

● Características o propiedades que debe tener el sistema

● Son adicionales o complementarios a la funcionalidad
● Pueden aplicar a todo el sistema o solo algunas funciones

Categorías
Atributos de calidad
● Afectan el comportamiento del sistema
● Interfaces eternas con otros sistemas
● Restricciones de diseño o implementación
● Restricciones culturales, legales y ambientales
Ejemplos de RNF

Requisito funcional:
El sistema debe permitir la consulta de las multas que
tiene una persona en tránsito y transporte.

Requisito no funcional: (atributo de calidad)

El sistema debe poder dar respuesta a la consulta, sin
dejar de funcionar, hasta a 1000 personas al tiempo
Evaluación de docentes
● La primera vez que un estudiante o docente ingrese
al sistema, se mostrará la opción de realizar un
tutorial para que conozca la forma de usar el sistema.

● El sistema debe poder soportar al tiempo entre 150 y

300 usuarios simultáneos ingresando evaluaciones
docentes.
Incorrecto
Que la página cargue rápidamente.

Correcto
La página no debe tardar más de 5 segundos en cargarse La
salida del programa debe producirse dentro de 15 segundos el
60% de las veces, y dentro de 25 segundos, el 100% de las veces
Incorrecto
El sistema se recuperará automáticamente tras producirse un
fallo.

Correcto
Ante un fallo en el software del sistema, no se tardará más de 5
minutos en restaurar los datos del sistema (en un estado válido)
y volver a poner en marcha el sistema.
Categorías RNF
Ejemplos RNF
Ejemplo general