Tema 2: Requisitos de Software

INGENIERÍA DEL SOFTWARE

Departamento de Ciencias de la Computación, Arquitectura de Computadores, Lenguajes y Sistemas
Informáticos y Estadística e Investigación Operativa
Contenidos
 Requisitos de Software
 Importancia de los requisitos
 Concepto de requisito
 Tipos de requisitos
 ¿Cómo escribir los requisitos?
 Documento de especificación de requisitos

2
Importancia de los requisitos
 Coste de proyectos reales
 Importancia de la gestión de requisitos
 Respuesta
 Tratar de obtener los requisitos correctos Entradas de usuario
 Proceso que acepte el cambio incorrectas 13%

Requisitos
incompletos 12%
Otros 50%

Cambios en los
Un 37% de los costes tienen
requisitos 12%
que ver de alguna manera
con los requisitos (13+12+12) Habilidades
técnicas
Mala dirección 6% pobres 7%
3
Importancia de los requisitos
 Causas del fracaso [Standish]:
 Requisitos incompletos
 No implicación del usuario (stakeholders en general)

 Es la base del resto del desarrollo, por tanto, es

CRÍTICO:
 Capturar y definir bien los requisitos
 Establecer los límites del sistema

 Ingeniería de requisitos.
 Actividades implicadas en la obtención, documentación y
mantenimiento de un conjunto de requisitos para un
sistema software.
4
Contenidos
 Requisitos de Software
 Importancia de los requisitos
 Concepto de requisito
 Tipos de requisitos
 ¿Cómo escribir los requisitos?
 Documento de especificación de requisitos

5
Concepto de requisito

 Qué hacer, no cómo IMPORTANTE

 Descripción de los servicios que tendrá que proporcionar

el sistema y de sus restricciones operativas
 Reflejan las necesidades de los clientes/usuarios de un sistema
que ayude a resolver algún problema concreto
 Ingeniería de Requisitos (Requirements Engineering):
 Proceso de descubrir, analizar, documentar y verificar los
servicios y restricciones (requisitos)

6
Concepto de requisito

 El concepto de “requisito” puede introducir cierta

ambigüedad

 “Lo que debe hacer el sistema” depende del destinatario

de la descripción

 Equipo directivo que contrata TODOS ¿Qué debe hacer?

 Equipo de desarrollo
Distintos niveles de detalle
 Usuarios dependiendo del ROL
 Administradores

7
Concepto de requisito

8
Concepto de requisito
Ejemplo: tienda de música on-line

 Quiero vender música a través de Internet

 Los usuarios comprarán créditos para adquirir canciones.
 Los usuarios buscarán las canciones que deseen y las
pagarán con créditos.
 Los usuarios tendrán algunos días para descargar en su
ordenador las canciones que hayan adquirido.
 Quiero hacer ofertas generales (afectan a todos los
usuarios) y particulares (afectan a usuarios concretos).

9
Contenidos
 Requisitos de Software
 Importancia de los requisitos
 Concepto de requisito
 Tipos de requisitos
 ¿Cómo escribir los requisitos?
 Documento de especificación de requisitos

10
Tipos de requisitos

Clasificación:

 Funcionales/No Funcionales

 De Dominio

 De Usuario/De Sistema (en función del grado de detalle)

11
Tipos de requisitos
 Funcionales:
 “Lo que debe hacer el sistema”. Declaraciones de los servicios que
debe proporcionar el sistema, de la manera en que éste debe
reaccionar a entradas y situaciones particulares. En algunos casos, los
requisitos funcionales también pueden declarar explícitamente lo que
el sistema no debe hacer.
 Ej: El teléfono móvil permitirá crear nuevos contactos y almacenarlos en la
agenda
 No funcionales:
 Restricciones de los servicios o funciones ofrecidas por el sistema.
Incluyen restricciones de tiempo, sobre el proceso de desarrollo y
estándares. Los requisitos no funcionales a menudo se aplican al
sistema en su totalidad. Normalmente apenas se aplican a
características o servicios individuales del sistema.
 Ej: La pantalla del teléfono móvil será táctil

12
Tipos de requisitos
 Requisitos funcionales
 Describen lo que el sistema debe hacer.
 Dependen:
 Del tipo de software
 De los posibles usuarios
 Del enfoque general
 Los de sistema deben ser:
 Completos
 Todos los servicios solicitados por el usuario deben estar definidos
 Consistentes
 No deben tener definiciones contradictorias y sin ambigüedades

13
Tipos de requisitos
 Requisitos no funcionales
 Requisitos que no se refieren a las funciones que proporciona
el sistema, sino a propiedades como fiabilidad, tiempo de
respuesta, disponibilidad…
 No suelen referirse a características particulares, sino
propiedades generales del sistema
 Pueden ser más críticos que los funcionales y hacer que el
sistema entero sea inutilizable
 Pueden referirse no al sistema sino al proceso (estándares,
herramientas,…)
 De necesidades de usuario (presupuestos, políticas,
interoperabilidad) o externos (seguridad, legislación)

14
Tipos de requisitos
 Requisitos no funcionales
 Diferenciados en el documento de especificación de
requisitos
 En la práctica, es difícil
 Por separado, difícil ver su relación
 Juntos, difícil separar la parte funcional de la no funcional e identificar los
que se refieren al sistema como un todo
 Balance apropiado
 Resaltar los referidos a propiedades emergentes (fiabilidad,
tiempo de respuesta, capacidad de almacenamiento, etc.)

 Se pueden producir conflictos con funcionales u otros no

funcionales

15
Tipos de requisitos
 Requisitos no funcionales
 Difíciles de verificar
 Redactados considerando las metas generales del usuario (facilidad de
uso, recuperación ante fallos, tiempo de respuesta)
 Problemas a los desarrolladores
 Interpretaciones abiertas
 Idealmente:
 Expresarlos cuantitativamente
 En la práctica
 Métricas difíciles para los clientes (mantenimiento…)
 Alto coste de comprobación
 Pueden deberse a
 Características requeridas por el software (producto),
 La organización que desarrolla el software (organizacionales)
 Otras fuentes externas

16
 Tipos de requisitos

REQUISITOS
NO FUNCIONALES
Requisitos de Requisitos
producto externos
Requisitos
organizacionales
Requisitos Requisitos Requisitos
Requisitos interoperabilidad éticos legislativos
de fiabilidad

Requisitos Requisitos
Requisitos de Requisitos Requisitos Requisitos de privacidad De seguridad
usabilidad de entrega implementación estándares

Requisitos de
portabilidad

Requisitos de
eficiencia

Requisitos de Requisitos
rendimiento de espacio

17
Tipos de requisitos
REQUISITOS
 RNF De producto: NO FUNCIONALES
especifican el
comportamiento del Requisitos de
producto
producto:
 Tiempo de carga de página Requisitos de
web, o uso máximo de fiabilidad
memoria.
Requisitos de Requisitos
 Tasa de fallo. usabilidad de eficiencia
 Multinavegador.
Requisitos de
portabilidad

Requisitos de Requisitos
rendimiento de espacio
18
Tipos de requisitos
 RNF Organizacionales: de REQUISITOS
las políticas y NO FUNCIONALES
procedimientos existentes
en la organización (cliente
o desarrollador): Requisitos
 Lenguajes de programación, organizacionales
procesos a utilizar,
documentación basada en
determinados estándares, Requisitos Requisitos
etc. de entrega estándares

Requisitos
implementación

19
Tipos de requisitos
 RNF Externos: se derivan REQUISITOS
NO FUNCIONALES
de factores externos al
sistema y de su proceso Requisitos
de desarrollo: externos

 Interoperabilidad:
protocolos para interactuar
con otros sistemas Requisitos
éticos
 Legislación competente:
LOPD… Requisitos Requisitos
interoperabilidad legislativos

Requisitos Requisitos
de privacidad de seguridad
20
Tipos de requisitos
Propiedad Medidas Requisitos no funcionales
Rendimient Transacciones procesadas por segundo
o Tiempo de respuesta a un evento
Tiempo de refresco de pantalla
Un
Tamaño Kbytes
Nº de chips de RAM
problema de
los
Fácil de uso Tiempo de aprendizaje
requisitos no
Nº de marcos de ayuda
funcionales
Fiabilidad Tiempo medio entre fallos es que
Probabilidad de no estar disponible
muchas
Tasa de ocurrencia de fallos
Disponibilidad
veces no son
verificables
Robustez Tiempo de recuperación ante fallos
Porcentaje de eventos causantes de fallo
Probabilidad de corrupción de datos en un fallo

Portabilidad Nº de sistemas objetivo

21
Tipos de requisitos
 Requisitos de dominio:
 Requisitos que provienen del dominio de especificación del sistema y
que reflejan las características y restricciones de ese dominio (no
tienen por qué derivarse de las especificaciones del usuario)
 Pueden ser funcionales o no funcionales.
 Ej: El teléfono móvil deberá operar en un rango de frecuencias
comprendidas entre los 800 y 1.800 MHz
 Es importante comprenderlo para comprender a los usuarios y
clientes (ej: el dominio tiene su propio vocabulario/lenguaje)
 Antes de entrar de lleno a especificar, con los usuarios y clientes, hay
que trabajar para conocer el dominio del sistema.
 Problema especial para los ingenieros del software porque han
de comprender un dominio que les puede ser ajeno
 Problema de los requisitos implícitos
 El grado de dificultad lo marca el dominio

22
Tipos de requisitos
 En función del grado de detalle
 Requisitos de usuario: declaraciones, en lenguaje natural y
en diagramas, de los servicios que se espera que el sistema
proporcione y de las restricciones bajo las cuales debe
funcionar
 Requisitos de sistema: establecen con detalle las funciones,
servicios y restricciones operativas del sistema. El documento
de requisitos del sistema debe ser preciso. Debe definir
exactamente qué es lo que se va a implementar. Puede ser
parte del contrato entre el comprador del sistema y los
desarrolladores

23
Tipos de requisitos
 Ejemplo

Requisito • 1. El teléfono móvil permitirá al usuario introducir contactos en la agenda

de usuario del teléfono

• 1.1. El usuario tendrá que tener encendido el teléfono y haber accedido

mediante su pin.
Requisitos • 1.2. Accederá al menú principal y seleccionará Contactos.
del sistema • 1.3. Pulsará Opciones y seleccionará Crear Contacto
• 1.4. Introducirá todos los datos del contacto a crear y pulsará Aceptar
• 1.5. El sistema almacenará los datos del nuevo contacto en Contactos.

24
Tipos de requisitos
 Lectores de las especificaciones
 Requisitos de usuario
 Administradores del cliente
 Usuarios finales del sistema
 Ingenieros del cliente
 Administradores de los contratistas
 Arquitectos del sistema
 Requisitos del sistema
 Usuarios finales del sistema
 Ingenieros del cliente
 Arquitectos del sistema
 Desarrolladores del software

25
Tipos de requisitos
 Requisitos de usuario
 Requisitos funcionales y no funcionales comprensibles para los
usuarios. No usar jerga técnica
 Se centran en especificar el comportamiento externo del sistema,
alejándose todo lo posible de las consideraciones de diseño del
sistema (el cómo)
 Ej: Especificación de un coche para un ingeniero mecánico o para un
comprador. Ambos “visualizan” el mismo vehículo desde dos
perspectivas diferentes
 Problemas habituales:
 Falta de claridad: difícil usar lenguaje sencillo no ambiguo
 Confusión de requisitos: entre funcionales y no funcionales, metas del
sistema e información de diseño….
 Conjunción de requisitos: varios requisitos juntos

26
Requisitos de usuario
 Recomendaciones para evitar problemas:
 Formato estándar para todos los requisitos. Es recomendable
indicar la persona que solicitó el requisito.
 Utilizar el lenguaje de forma consistente para distinguir entre
los requisitos obligatorios de los deseables.
 Resaltar el texto para distinguir las cuestiones claves del
requisito (negrita, cursiva, colores).
 Evitar en lo posible jerga informática. “Traducción entre los
idiomas”.

27
Requisitos de sistema
 “Versiones extendidas” de los requisitos de usuario para
los ingenieros de software.
 Agregan detalle y especifican cómo el sistema debe
proporcionar los requisitos para satisfacer los requisitos de
usuario.
 Debe ser una especificación completa y consistente del
sistema en su conjunto.
 Establece la relación contractual entre cliente y proveedor
 Debe definir claramente el sistema a desarrollar
 Evitar el uso exclusivo del lenguaje natural

28
Contenidos
 Requisitos de Software
 Importancia de los requisitos
 Concepto de requisito
 Tipos de requisitos
 ¿Cómo escribir los requisitos?
 Documento de especificación de requisitos

29
¿Cómo escribir los requisitos?

 Definir los requisitos es una tarea difícil:

 Distintas interpretaciones.
 Distintos niveles de detalle según los participantes.
 Los requisitos cambian constantemente.

 ¿Qué notación utilizar?

30
¿Cómo escribir los requisitos?
 Los requisitos de usuario podrían expresarse en lenguaje
natural
 Los requisitos de sistema necesitan de un mayor nivel de
detalle y han de evitar malas interpretaciones
 Se pueden utilizar diferentes notaciones
 Algunas facilitan la comprensión de lectores “no técnicos”

31
¿Cómo escribir los requisitos?
 La “mejor forma” de escribir requisitos no existe
 Lo más utilizado es el lenguaje natural:

<id> El <sistema> debería <función>

 Lenguaje natural complementado con diagramas y

notaciones formales
 La notación utilizada depende de quien lee o escribe los
requisitos
 Se puede usar un lenguaje formal

32
¿Cómo escribir los requisitos?
 Recomendaciones
 No usar conectores del tipo: ciertamente, claramente,
obviamente,...
 No usar términos imprecisos: algunos, a veces, normalmente,
en la mayoría de los....
 Usar términos de certidumbre: siempre, todos, nunca, ...
 Rangos: (10..100) ¿enteros, reales?
 Ejemplos para los cálculos
 Nº de página, pie, etc.
 Identificar cada requisito de forma unívoca

33
¿Cómo escribir los requisitos?
 Notaciones

Lenguaje natural • Definición de formularios y plantillas estándares para

expresar la especificación de requisitos (la siguiente
estructurado trasparencia muestra un ejemplo de plantilla).

• Uso de lenguaje gráfico complementado con anotaciones

de texto.
Notaciones gráficas • Casos de uso, diagramas de secuencia, diagramas de
estados,… (UML)

• Notaciones que se basan en conceptos matemáticos como

el de las máquinas de estados finito o los conjuntos.
Especificaciones
• La mayoría de los clientes no comprenden estas
matemáticas especificaciones y son reacios a aceptarlas como un
contrato del desarrollo del sistema.

34
¿Cómo escribir los requisitos?
 Lenguaje Natural Estructurado: plantilla
Agregar contacto en el móvil/SRS/3.5.1.
Función Agregar un contacto nuevo.
Descripción Agregará un contacto nuevo a la lista de contactos del móvil.
Se deberá verificar que no se duplique ni el nombre ni el
número de teléfono……
Entradas Datos del contacto de forma manual. Número de teléfono,
desde llamada o sms.
Salidas Contacto nuevo almacenado.
Precondición El móvil debe estar encendido y desbloqueado y se debe
haber accedido mediante el menú a dicha opción.
Postcondición Ninguna.
Efectos Ninguno.
colaterales

35
¿Cómo escribir los requisitos?
 Notación gráfica: Diagrama de Estados en UML
 X-Y: color del visor del automóvil y del peatón
 Automóvil: R (rojo), A (ámbar),V (verde)
 Peatón: R (rojo),Vi (verde intermitente),V (verde)

R-V R-Vi R-R

t1 cumplido t2 cumplido
Do/ Contar (t1) Do/ Contar (t2) Do/ Contar (t3)

t3 cumplido
t6 cumplido

R-R A-R V-R

t5 cumplido t4 cumplido
Do/ Contar (t6) Do/ Contar (t5) Do/ Contar (t4)

36
¿Cómo escribir los requisitos?
 Especificación de la Interfaz
 El documento de requisitos debería incluir una definición
clara de las interfaces de comunicación entre sistemas
preexistentes o en desarrollo:
 Interfaces de procedimiento: para acceder a los subsistemas
(APIs)
 Estructuras de datos: que pasan de un sistema a otro. Ej: Bases
de Datos comunes

37
¿Cómo escribir los requisitos?
 Requisitos en negativo

 Es importante decir lo que el sistema NO debe hacer (donde

no utilizar recursos)
 Fundamental para sistemas críticos
 Mantener la distinción liveness/safety:

 Liveness: lo que el sistema debe hacer

 Safety: lo que el sistema no debe hacer

38
¿Cómo escribir los requisitos?
 Ejercicio
Se desea desarrollar un sistema para los cajeros del banco
que permita hacer las operaciones habituales. Hay que
tener en cuenta que para llevar a cabo cualquier operación,
el cliente deberá validarse previamente. Además, existe un
límite de reintegro diario.

Se pide:
 Elaborar lista de requisitos candidatos

39
Contenidos
 Requisitos de Software
 Importancia de los requisitos
 Concepto de requisito
 Tipos de requisitos
 ¿Cómo escribir los requisitos?
 Documento de especificación de requisitos

40
Documento de especificación de requisitos
 También llamado ERS (Especificación de Requisitos
Software)
 Es la declaración oficial de qué deben implementar los
desarrolladores del sistema
 Debería incluir tanto los requisitos de usuario para el sistema
como una especificación detallada de los requisitos de sistema
 En una descripción única
 Los de usuario como introducción
 Intentar incluir información sobre cambios previstos
 Muchos participantes diferentes
 Comunicación entre clientes, usuarios y desarrolladores

41
Documento de especificación de requisitos
 Objetivos de la ERS según el tipo de participante
 Clientes: especifican los requisitos y los leen para verificar que
se cumplen sus necesidades. Especificarán cambios si es
necesario.
 Administradores: planifican una oferta por el sistema y el
proceso de desarrollo.
 Ingenieros de sistemas/software: para saber qué sistema debe
diseñarse y desarrollarse.
 Ingenieros de pruebas: para desarrollar las pruebas de
validación para el sistema/software.
 Ingenieros de mantenimiento: para comprender el sistema
nuevo y las relaciones entre sus partes (subsistemas).
Controlar la evolución del sistema.

42
Documento de especificación de requisitos
 Un documento de requisitos contiene
 Información acerca del problema
 Interfaz externa del sistema con su entorno (software,
hardware, usuarios, puertos de comunicación)
 Propiedades y comportamiento del sistema
 Restricciones de diseño y fabricación del producto
 Descripciones acerca de cómo el sistema ayudará a sus
usuarios a realizar mejor sus tareas
 Restricciones acerca de la tecnología que será utilizada en la
construcción del sistema (protocolos, SSOO, COTS, etc.)
 Restricciones acerca de las propiedades emergentes del
sistema (requisitos no funcionales)

43
Documento de especificación de requisitos
 Un documento de requisitos NO debe incluir

 Requisitos del proyecto: planificación, costes, fases, hitos,…

 Diseño
 Planes de garantía del producto

44
Documento de especificación de requisitos
 Muchos tipos de usuarios:
 Equilibrio entre
 Comunicación a los clientes
 Detalle necesario por los desarrolladores
 Nivel de detalle:
 En función del tipo de sistema y del proceso
 Ej: contratista externo: especificaciones muy claras y detalladas
 Ej: proceso iterativo interno: documento menos detallado, resolver
ambigüedades durante el desarrollo

45
Documento de especificación de requisitos
 “Documento” es cualquier medio:
 Documento con procesador de textos
 BBDD
 Herramienta de gestión de requisitos: almacena los requisitos
en una BBDD y genera un documento automáticamente
siguiendo una estructura

 Diversos estándares:
 IEEE/ANSI 830-1998

46
Documento de especificación de requisitos
ERS IEEE 830
1. Introducción
1. Propósito
2. Alcance del producto
3. Definición, acrónimos y abreviaturas
4. Referencias
5. Descripción del resto del documento.
2. Descripción general
1. Perspectiva del producto
2. Funciones del producto
3. Características del usuario
4. Restricciones generales
5. Suposiciones y dependencias
3. Requisitos específicos
o Es la parte más sustancial del documento. Incluye los requisitos funcionales, no funcionales y
de interfaz. Se puede definir usando la técnica de casos de uso (que veremos)
4. Apéndices
5. Índice
47
Documento de especificación de requisitos
 Cada requisitos tiene un identificador
 Para cada requisito se especifica con cuáles se relaciona
por medio de dichos números.
 Matriz de trazabilidad.
 ¿Se conoce el origen del requisito?
 ¿Cuál es el impacto de cambiar un requisito?.
 Debemos mantener información acerca:
 dependencia entre requisitos
 por qué existe el requisito
 relaciones con elementos del diseño y la implementación

48
Documento de especificación de requisitos
 Matriz de trazabilidad.

R1 R2 R3 R4 R5 R6
R1 * * R1 depende de R3 y de R4
R2 * *
R3 * *
R4 *
R5 *
R6

si modifico R4 resultarán afectados R1 y R3

49