23 DE MARZO DE 2023

MATERIAL DE APOYO PRO103

REQUERIMIENTOS

ALC
AIEP
 ÍNDICE
¿Qué es ingeniería de requerimientos?..................................................................................2
Proceso de ingeniería de requisitos..........................................................................................2
Concepto de requisito................................................................................................................3
Dimensiones de los requisitos...................................................................................................4
Especificación de requisitos del sistema..................................................................................5
Requisitos no funcionales...........................................................................................................6
Clasificación de los requisitos no funcionales [Sommerville, 2002]...........................................6
Requerimientos no funcionales, según Sommerville, 2002......................................................8
Propiedades deseables de los requisitos....................................................................................8
Tipos de conflictos entre requisitos [Davis, 1993]...............................................................9
Especificación de Requisitos (ERS).......................................................................................10
Casos de uso.............................................................................................................................13
Estimación de tiempo y esfuerzo en proyectos de software................................................13
Técnicas de estimación de software.......................................................................................13

1
¿Qué es ingeniería de requerimientos?

Es el proceso de desarrollar una especificación de Software. Las especificaciones

pretenden comunicar las necesidades del sistema del cliente con los desarrolladores del
sistema. Trata de los principios, métodos, técnicas y herramientas que permiten descubrir,
documentar y mantener los requisitos para sistemas basados en computadora, de forma
sistemática y repetible. Según Pressman, es un conjunto de procesos, tareas y técnicas
que permiten la definición y gestión de los requisitos de un producto de un modo
sistemático.
En definitiva, facilita los mecanismos adecuados para comprender las necesidades del
cliente, analizando sus necesidades, confirmando su viabilidad, negociando una solución
razonable, especificando la solución sin ambigüedad, validando la especificación y
gestionando los requisitos para que se transformen en un sistema operacional.

Proceso de ingeniería de requisitos

Obtención (elicitación) de requisitos: Este subproceso, probablemente el más crítico y el

más difícil de realizar, tiene como objetivos buscar, investigar y ayudar a los clientes y
usuarios a documentar sus necesidades.
La documentación de los requisitos deberá hacerse siempre usando el vocabulario de
clientes y usuarios, de forma que estos puedan entenderlos, siendo lo más habitual
emplear lenguaje natural Las técnicas más comunes son las entrevistas, reuniones en
grupo, estudio in situ...
Análisis de requisitos: Se denomina análisis a la distinción y separación de las partes de
un todo hasta llegar a conocer sus principios o elementos; Estudio, mediante técnicas
informáticas, de los límites, características y posibles soluciones de un problema al que se
aplica un tratamiento por ordenador [RAE, 2014].
Esta actividad es parte del subproceso de aseguramiento de la calidad. Tiene como
objetivo principal detectar conflictos en los requisitos obtenidos, normalmente mediante
técnicas de modelado conceptual y de prototipado de interfaz de usuario.
Los modelos generados son también una importante herramienta de comunicación con
diseñadores y programadores.
Verificación de requisitos: Esta actividad de calidad tiene como objetivo detectar defectos
en los
requisitos previamente analizados, normalmente mediante técnicas como revisiones
formales, listas de comprobación (checklists)…
Validación de requisitos: Esta tercera actividad de calidad intenta asegurar que los
requisitos verificados reflejan realmente las necesidades de clientes y usuarios. Las

2
técnicas empleadas suelen ser reuniones en las que se revisan los requisitos mediante el
apoyo de prototipos de interfaz de usuario
Negociación de requisitos: El objetivo de este subproceso es buscar soluciones a los
conflictos detectados que satisfagan a los distintos stakeholders
Gestión de requisitos: Este subproceso gestiona todo el proceso, en especial las
peticiones de cambios en los requisitos, el impacto de dichas peticiones, las distintas
versiones de los requisitos…
¿Qué describe un requisito?
Una utilidad para el usuario:
“El tratamiento de textos ha de incluir la comprobación y corrección gramatical”
Una propiedad general del sistema
“El sistema ha de garantizar que la información personal solamente será accesible
mediante autorización explícita”
Una restricción general del sistema
“El sensor ha de muestrearse 10 veces por segundo”
Cómo llevar a cabo cierto cálculo
“Calificación final = nota examen + 2*nota trabajo + 2/3 nota ejercicios”
Una restricción sobre el desarrollo del sistema
“El sistema ha de implementarse en C#”

Concepto de requisito
Condición o capacidad que necesita el usuario para resolver un problema o conseguir
un objetivo determinado [Piattini et al., 1996]
(a) Una condición o capacidad que un usuario necesita para resolver un problema o
lograr
un objetivo.
(b) Una condición o capacidad que debe tener un sistema o un componente de un
sistema
para satisfacer un contrato, una norma, una especificación u otro documento formal.
(c) Una representación en forma de documento de una condición o capacidad como las
expresadas en (a) o en (b) [IEEE, 1999a]
Una característica del sistema que es una condición para su aceptación [DoD, 1994]
Una propiedad que debe exhibirse para solucionar algún problema del mundo real
[Sawyer y Kontoya, 2001]

3
 simplicidad del concepto
 Es frecuente encontrar el término requisito calificado con adjetivos que pueden
resultar confusos en un primer momento de sistema.
 hardware
 Software
 de usuario
 de cliente
 funcional
 no funcional

Dimensiones de los requisitos

Ámbito
Indica en qué contexto se debe entender el requisito.
Sistema, Software, Hardware
Característica que define
Los requisitos se clasifican en función de la naturaleza de la característica del sistema que
se especifica
Requisitos funcionales, Requisitos no funcionales
Audiencia
Indica a quién está dirigido el requisito, es decir, las personas que deben ser capaces de
entenderlo. Implica un nivel de descripción determinado
Requisitos-C, Requisitos-D [Rombach, 1990; Brackett, 1990]
Requisitos de usuario o Requisitos de cliente, Requisitos software [Mazza et al., 1994]
Requisitos de usuario, Requisitos de sistema, Especificaciones de diseño [Sommerville,
2002]
Representación
Establece la forma cómo se definen los requisitos
Formal, Semiformal, No formal
Definición de requisitos de usuario
El software debe proporcionar un medio para la representación y acceso a ficheros
externos creados por otras herramientas.

4
Especificación de requisitos del sistema

Hay que proporcionar al usuario utilidades para definir el tipo de los ficheros externos

Cada tipo de fichero externo tendrá asociado una herramienta que podrá ser aplicada al
fichero
Cada tipo de fichero externo podrá estar representado mediante un icono específico en la
interfaz del usuario
Se proporcionarán utilidades para que el usuario pueda definirse el tipo de icono que
asociará a cada tipo de fichero
Cuando un usuario seleccione un icono que representa un tipo de fichero externo, el
efecto de la selección será la aplicación de la herramienta asociada con el tipo de fichero
externo al fichero representado por el icono seleccionado
K. Pohl (1997) establece una completa clasificación de requisitos, RSM (Requirements
Specification Model)
Las principales categorías son:
Requisitos funcionales: Describen la funcionalidad o los servicios que se espera
que este proveerá
De usuario: descripción general
De sistema: descripción detallada (función, entradas, salidas...)
Requisitos de datos
Requisitos no funcionales

Problemas con los requisitos

Los requisitos no reflejan las necesidades reales del cliente

Requisitos inconsistentes o incompletos
El cambio de requisitos, una vez acordados, es muy costoso
Problemas de comunicación

5
 Incomprensiones entre los clientes, los que desarrollan los requisitos y los
ingenieros de software que desarrollan o mantienen el sistema

Requisito vs. Restricción

Dada una lista de deseos y necesidades, ¿cuáles son los requisitos y cuáles son las restricciones?

Las restricciones limitan la forma en la que se puede resolver un problema.

Ejemplo:
Requerimiento1: Imprimir transparencias de color en una impresora de blanco y negro.
Requerimiento2: Establecer la correspondencia al blanco y negro de forma automática.
El programa tiene que imprimir transparencias de color en blanco y negro estableciendo
la correspondencia de forma automática e imprimir sobre una impresora postscript.
Restricción: Utilizar el formato postscript.
El programa tiene que imprimir transparencias de color en blanco y negro estableciendo
la correspondencia de forma automática e imprimir sobre una impresora postscript.
Indicación: Aquello que es tangible o visible para el usuario es normalmente un requisito
 Los dos primeros son visibles para el usuario el tercero no.
El programa tiene que imprimir transparencias de color en blanco y negro estableciendo
la correspondencia de forma automática e imprimir sobre una impresora postscript.

Requisitos no funcionales
 Requisitos no relacionados directamente con la funcionalidad del sistema.
 Pueden estar relacionados con propiedades emergentes del sistema.
 Pueden describir restricciones al producto a desarrollar
 Pueden describir restricciones externas del sistema
 Definen las cualidades globales que el sistema ha de exhibir
 Suelen hacer referencia al sistema considerado de forma global
 Suelen ser requisitos más críticos que los requisitos funcionales
 Suelen ser difíciles de verificar

Clasificación de los requisitos no funcionales [Sommerville, 2002]

 Requisitos de producto
 Especifican el comportamiento del producto
 Tiempo de respuesta, memoria requerida, fiabilidad, portabilidad, usabilidad…

6
 Requisitos de organización
 Se derivan de las políticas y procedimientos existentes en la organización del cliente
y en la del desarrollador
 Estándares de proceso, lenguajes de programación, métodos de diseño, estándares
de documentación...
 Requisitos externos: Factores externos al sistema y de su proceso de desarrollo
 Interoperabilidad, éticos, legislativos, privacidad, seguridad...

7
Requerimientos no funcionales, según Sommerville, 2002

Propiedades deseables de los requisitos

Comprensible por clientes y usuarios
Una especificación debe servir como canal de comunicación entre los participantes en el
proceso de ingeniería de requisitos
La mejor forma de lograr esta comunicación es pensar en la audiencia a la que van
dirigidos los requisitos
No ambigua
Cada requisito solo tiene una interpretación
Completa
Incluye todos los requisitos significativos
Define la respuesta a todo tipo de entradas
Es conforme con el estándar de especificación a cumplir
Están etiquetadas y referenciadas todas las figuras, tablas...

8
Consistente
No hay conflictos ni contradicciones
Es consistente externamente si y solo si todo requisito contenido en ella no está en
conflicto con otros documentos de nivel superior
Es consistente internamente si y solo si no existen conflictos entre los requisitos que
contiene

Tipos de conflictos entre requisitos [Davis, 1993]

Conflictos de conducta. Dos o más requisitos especifican conductas distintas del sistema
para las mismas condiciones y el mismo estímulo externo
Conflictos de términos:
Se utilizan términos distintos para referirse al mismo concepto
Conflictos de característica.
Dos o más requisitos especifican aspectos contradictorios para la misma característica del
sistema
Conflictos temporales.
Dos o más requisitos exigen características temporales contradictorias al sistema
Verificable
Todo requisito contenido en ella es verificable.
Existe un proceso finito y de coste razonable por el que una persona o una máquina
pueda comprobar que el sistema final cumple el requisito
Una condición absolutamente necesaria para que un requisito sea verificable es que no
sea ambiguo y que se defina de forma mensurable
Los procedimientos de observación para comprobar que el sistema cumple los requisitos
son la base para las pruebas de aceptación por parte del cliente [Wieringa, 1996]
Modificable
Su estructura y estilo de redacción permiten que los cambios se puedan realizar fácil,
completa y consistentemente
Debe tener una organización coherente
No debe ser redundante
Los requisitos deben expresarse individualmente y no de forma conjunta

9
Trazable
Para cada requisito contenido en ella se conoce su origen y puede referenciarse como
origen en posteriores documentos
Cada requisito puede seguirse hacia atrás y hacia delante
Anotada con importancia y estabilidad
Cada requisito contenido en ella está anotado con la importancia que tiene su
cumplimiento para clientes y usuarios y la estabilidad que se espera del requisito, es
decir, la probabilidad de que cambie durante el desarrollo
Independiente del diseño y de la implementación
No especifica una determinada descomposición del sistema (arquitectura) ningún aspecto
de su posible implementación
Solo deben admitirse requisitos que limiten la libertad de los diseñadores y
programadores en el caso de que el cliente lo solicite explícitamente.

Especificación de Requisitos (ERS)

Estructura de una ERS IEEE Std. 830-1998 [IEEE, 1999b]

1. Introducción
1.1. Objetivo
1.2. Ámbito
1.3. Definiciones, acrónimos y abreviaturas
1.4. Referencias
1.5. Descripción del resto del documento
2. Descripción general
2.1. Perspectiva del producto
2.2. Funciones del producto
2.3. Características del usuario
2.4. Limitaciones generales
2.5. Supuestos y dependencias
3. Requisitos específicos
3.1. Requisitos funcionales
3.2. Requisitos de interfaz externa

10
 3.3. Requisitos de ejecución
3.4. Restricciones de diseño
3.5. Atributos de calidad
3.6. Otros requisitos
Apéndices Índice
3.Requisitos específicos
3.1. Requisitos funcionales
3.1.1. Requisito funcional
3.1.1.1. Introducción
3.1.1.2. Entradas
3.1.1.3. Salidas
3.1.2. Requisito funcional 2 …………….
3.1.n. Requisito funcional n

3.2. Requisitos de interfaz externa

3.2.1. Interfaces de usuario
3.2.2. Interfaces hardware
3.2.3. Interfaces software
3.2.4. Interfaces de comunicaciones
3.3. Requisitos de ejecución
3.4. Restricciones de diseño
3.4.1. Acatamiento de estándares
3.4.2. Limitaciones hardware ……………
3.5. Requisitos no funcionales (atributos de calidad)
3.5.1. Seguridad
3.5.2. Mantenimiento ……………
3.6. Otros requisitos
3.6.1. Base de datos
3.6.2. Operaciones
3.6.3. Adaptación de situación

Portada
Lista de cambios
Índice
Lista de figuras
Lista de tablas
1. Introducción
2. Participantes en el proyecto

11
3. Descripción del sistema actual
4. Objetivos del sistema
5. Catálogo de requisitos del sistema
5.1 Requisitos de información
5.2 Requisitos funcionales
5.2.1 Diagramas de casos de uso
5.2.2 Definición de actores
5.2.3 Casos de uso del sistema
5.3 Requisitos no funcionales
6. Matriz de rastreabilidad objetivos/requisitos

7. Glosario de términos
8. Conflictos pendientes de resolución [opcional, pueden ir en un documento aparte]
Apéndices [opcionales]

[Durán y Bernárdez, 2002]

Portada
Lista de cambios
Índice
Lista de figuras
Lista de tablas
1. Introducción
2. Participantes en el proyecto
3. Descripción del sistema actual
4. Objetivos del sistema
5. Catálogo de requisitos del sistema
5.1 Requisitos de información
5.2 Requisitos funcionales
5.2.1 Diagramas de casos de uso

12
5.2.2 Definición de actores
5.2.3 Casos de uso del sistema
5.3 Requisitos no funcionales
6. Matriz de rastreabilidad objetivos/requisitos
7. Glosario de términos
8. Conflictos pendientes de resolución [opcional, pueden ir en un documento aparte]
Apéndices [opcionales]

Casos de uso

Revisar “Aprenda UML en 24 horas”, está en DRIVE del curso.

Estimación de tiempo y esfuerzo en proyectos de software.

Técnicas de estimación de software

Visitar estos link’s:

UNO:
http://www.pmoinformatica.com/2018/08/tecnicas-estimacion-software.html#:~:text=Una
%20estimaci%C3%B3n%20de%20software%20es,en%20la%20moneda%20de
%20preferencia.

DOS:
https://rzamurianos.wordpress.com/2011/06/26/descripcin-de-los-casos-de-uso-de-la-
aplicacin/#:~:text=Transacciones%3A%20Est%C3%A1%20representada%20por
%20uno,ayudan%20a%20clarificar%20las%20transacciones.

TRES: CON CASO DE USO

https://asprotech.blogspot.com/2012/03/estimacion-por-casos-de-uso.html

13