REQUERIMIENTOS DE SOFTWARE

FACULTAD DE INGENIERÍAS
PLAN DE ESTUDIOS DE INGENIERÍA DE SISTEMAS
Análisis y Diseño de Sistemas

Mg. Magreth Rossio Sanguino Reyes

 SITUACIÓN DE LA INDUSTRIA DE SOFTWARE

Tomado de: https://www.techbizdesign.com/biz/fracaso-proyectos-software/

 COSTO DE AJUSTAR LOS ERRORES DEL SOFTWARE

Errores de Código 1% Otros errores 10%

Errores de Diseño
13%

Costo de Requerimientos
82%
EL ESPACIO DEL PROBLEMA Y EL ESPACIO DE LA SOLUCIÓN

Formulación del
problema
Espacio del Problema
Análisis del
problema

Búsqueda de
soluciones

Selección de la
mejor solución
Espacio de la Solución
Diseño de la
solución

Implementación
de la solución
 EL ESPACIO DEL PROBLEMA Y EL ESPACIO DE LA SOLUCIÓN

Espacio del Problema

Modelado del Negocio
El
Problema

Necesidades

Características
La Solución
Ingeniería de Requisitos (software)
Requisitos de Software

Espacio de la Solución
Procedimientos de Pruebas Diseño Documentación
del Usuario
 DEFINICIONES DE REQUERIMIENTO
En ingeniería del software y el desarrollo de sistemas, un requerimiento es una
necesidad documentada sobre el contenido, forma o funcionalidad de un
producto o servicio.
[Diccionario de Informática y Tecnología]

Es una característica que se debe exhibir para solucionar un cierto problema en

el mundo real.
[Guía SWEBOOK]

Es una condición o capacidad a la que el sistema (siendo construido) debe

conformar.
[Rational]
 NECESIDAD - CARACTERÍSTICA - REQUERIMIENTO

STAKEHOLDER NECESIDAD CARACTERÍSTICA

Desea realizar un seguimiento a los El sistema debe permitir consultar el listado de los
Gerente de Ventas pedidos que han sido despachados. pedidos de productos que han sido registrados y
enviados.
Desea conocer el total que debe El sistema debe permitir registrar el valor de cada
Cliente pagar por la compra de sus producto y generar la factura de venta.
productos.
Necesita almacenar la información El sistema debe permitir registrar la información
Recepcionista de los huéspedes del hotel. de los huéspedes que ingresan al hotel
(documento, nombre, apellido, teléfono, …)
 CARACTERÍSTICAS DE LOS REQUERIMIENTOS

 Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema

a construir, y no puede ser reemplazado por otras capacidades del producto o del proceso.

 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 un futuro.

 Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción,

es decir, si se proporciona la información suficiente.

 Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.

 No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación.

 DIFICULTADES PARA DEFINIR REQUERIMIENTOS

 Los requerimientos no son obvios y vienen de muchas fuentes.

 Son difíciles de expresar en palabras (el lenguaje es ambiguo).
 Existen muchos tipos de requerimientos y diferentes niveles de detalle.
 La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
 Nunca son iguales.
 Los requerimientos están relacionados unos con otros, y a su vez se relacionan
con otras partes del proceso.
 Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
 CLASES DE REQUERIMIENTOS
Una manera de categorizar los requerimientos está descrito en el modelo
FURPS+:
 Functionality (Funcionalidad)
 Usability (Usabilidad)
 Reliability (Fiabilidad)
 Performance (Desempeño)
 Supportability (Soporte)
 El signo “+”, indica requerimientos adicionales que regularmente son
restricciones.
 MODELO FURPS+
SIGLA TIPO DE REQUERIMIENTO DESCRIPCIÓN
F Funcionality Funcionalidad Características, capacidades, aspectos de seguridad.

U Usability Facilidad de Uso Factores humanos (interacción), ayuda, documentación.

R Reliability Fiabilidad Frecuencia de fallos, capacidad de recuperación de un

fallo y grado de previsión.
P Performance Rendimiento Tiempos de respuesta, productividad, precisión,
disponibilidad.
S Supportability Capacidad de Soporte Facilidad de mantenimiento y de configuración.
Implementación Limitación de recursos, lenguajes, hardware.
Interfaz Interacción con sistemas externos.
+ Plus Operaciones Gestión del sistema, puesta en marcha.
Empaquetamiento Forma de distribución.
Legales Licencia, derechos de autor.
 REQUERIMIENTO FUNCIONAL
Es un requerimiento que describe qué debe
hacer el sistema respecto a su entorno
(usuarios y otros sistemas).

Estos requerimientos especifican los

comportamientos de entradas y salidas del
sistema.

Es la declaración de los servicios que debe

proporcionar el sistema, de la manera en que
éste debe reaccionar a entradas particulares y
de cómo se debe comportar en situaciones
particulares.
 EJEMPLO DE REQUERIMIENTOS FUNCIONALES

Para el estudiante de la UFPSO, el sistema de información académica SIA debe permitir:

 Consultar el horario correspondiente al semestre actual.
 Realizar cancelación e inclusión de asignaturas para el semestre actual.
 Visualizar su información personal.

Para el Gerente de Ventas, el sistema debe permitir:

 Generar reporte trimestral del volumen de ventas.
 Consultar información de Clientes morosos.

Para el Cliente de un servicio de televisión por cable, el sistema debe permitir:

 Registrar el pago correspondiente al mes consumido a través de tarjeta de crédito.
 Realizar la suscripción a un nuevo plan de TV.
 EJEMPLO DE REQUERIMIENTOS FUNCIONALES

Para el estudiante de la UFPSO, el sistema de información académica SIA debe permitir:

 Consultar el horario correspondiente al semestre actual.
 Realizar cancelación e inclusión de asignaturas para el semestre actual.
 Visualizar su información personal.

Para el Gerente de Ventas, el sistema debe permitir:

 Generar reporte trimestral del volumen de ventas.
 Consultar información de Clientes morosos.

Para el Cliente de un servicio de televisión por cable, el sistema debe permitir:

 Registrar el pago correspondiente al mes consumido a través de tarjeta de crédito.
 Realizar la suscripción a un nuevo plan de TV.
REQUERIMIENTO NO FUNCIONAL

Describe atributos del sistema o del ambiente

en donde éste se desarrolla.
Incluye: Usabilidad, Fiabilidad, Rendimiento y
Capacidad de Soporte.

Describe una restricción sobre el sistema que

limita las posibilidades en la construcción de
una solución al problema. Restringe los
servicios o funciones ofrecidas por el sistema.
Incluye restricciones de tiempo, el tipo de
proceso de desarrollo a utilizar, el tiempo de
respuesta, la capacidad de almacenamiento,
entre otros.
 EJEMPLO DE REQUERIMIENTOS NO FUNCIONALES

‗ El sistema debe tener una interfaz de uso intuitivo, complementada con un módulo de
ayuda.
‗ El sistema debe disponer de una documentación fácilmente actualizable que permita
realizar operaciones de mantenimiento.
‗ El sistema debe definir grupos de usuarios asociados a un conjunto de carpetas y
documentos.
‗ Todas las comunicaciones externas entre los servidores de datos, la aplicación y el
cliente del sistema deben estar cifradas utilizando el algoritmo RSA.
‗ El sistema debe contar con procedimientos automáticos para copias de seguridad y
restauración encaminados a realizar copias periódicas de seguridad de todos
elementos dentro del sistema (carpetas, documentos, metadatos, usuarios, roles,
permisos, configuraciones específicas)
 BUENAS PRÁCTICAS EN LA DEFINICIÓN
DE REQUERIMIENTOS

INCORRECTO
 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é?
Los objetivos son muy generales, vagos y abiertos a distintas
interpretaciones.
 BUENAS PRÁCTICAS EN LA DEFINICIÓN
DE REQUERIMIENTOS

CORRECTO
 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.
 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.

¿Por qué?
Los requisitos son verificables.
SITUACIÓN DE LA INDUSTRIA DE SOFTWARE
 PLANIFICACIÓN Y ESTIMACIÓN

FIN DE LA PRESENTACIÓN