Tema N° 5 Ingeniería de Requisitos y los Requisitos del Software

Profa. Sara Alcántara
DEL SOFTWARE Y
LA INGENIERÍA DE
Tema Nº 5
✓ Definiciones, Dificultades
✓ Clasificación, Niveles
✓ Proceso, Importancia
LOS REQUISITOS
REQUISITOS

Requisito
01
02
03
04
05
06
07
08
Tipos de Requisitos
Requisitos del Software
Características de los Requisito del Software
Clasificación de los Requisito del Software
Requisitos Funcionales
Requisitos No Funcionales
Niveles de los Requisitos - Representación
3
4
8
9
10
13
14
16
09
10
Niveles de los Requisitos - Definición
Niveles de los Requisitos - Ejemplos
18
19
CONTENIDO
11
Niveles, Tipos y ERS - Representación
20
12
13
Stakeholders
Tipos de Stakeholders
21
22
14
15
Ingeniería de Requisitos (IR)
Subprocesos y Actividades de la IR
23
24
16
Proceso de la Ingeniería de Requisitos
25
17
18
Dificultades para definir los Requisitos
Importancia/Beneficios de la IR
32
33
19
Referencias 35
Requisitos vs Restricción 6
20

Definición:
Los Requisitos del Software y la Ingeniería de Requisitos (IR)
Requisitos De acuerdo a diferentes autores un requisito puede definirse
como:
Condición o capacidad que necesita el usuario para resolver un
problema o conseguir un objetivo determinado (Piattini et al.,
1996).
Una propiedad que debe exhibirse para solucionar algún
problema del mundo real (Sawyer y Kontoya, 2001).

Dificultades:
Requisitos Dificultades para definir los Requisitos:
- Los requisitos no son obvios y vienen de muchas fuentes.
- Son difíciles de expresar en palabras (el lenguaje es ambiguo).
- La cantidad de requisitos en un proyecto puede ser difícil de
manejar.
- Nunca son iguales, algunos son más difíciles, más riesgosos,
más importantes o más estables que otros.
- Los requisitos están relacionados unos con otros y a su vez se
relacionan con otras partes del proceso.
- Cada requisito tiene propiedades únicas y abarcan áreas
funcionales específicas.
- Un requisito puede cambiar a lo largo del ciclo de desarrollo.
- El usuario no puede explicar lo que hace, ocasionando:
- Problemas de comunicación: Incomprensiones entre los
clientes, los que desarrollan los requisitos y los ingenieros de
software que desarrollan o mantienen el sistema.

Problemas o dificultades:
Requisitos

Requisitos vs Restricción:
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. Por ejemplo tenemos el siguiente requerimiento:
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.
Rq1: Imprimir transparencias de color en una impresora de
blanco y negro.
Rq2: Establecer la correspondencia al blanco y negro de forma
automática.

Requisitos vs Restricción:
Restricción La Restricción sería: Utilizar el formato postscrip.
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.

Tipos de Requisitos:
Requisitos Según la metodología que se utilice, existen varias clasificaciones
de los tipos de requerimientos, entre los más usuales están los
requisitos de software y los requisitos de hardware:
Requisitos de software: Se refiere a lo que debe hacer y lo que
no debe hacer el sistema, se pueden subdividir en
requerimientos funcionales y requerimientos no funcionales.
Requisitos de hardware: Dependen del volumen de
operaciones, cantidad de usuarios y de las aplicaciones que
deben de estar en uso cuando se implemente el sistema. Se
pueden distinguir tipos de requerimientos de hardware,
requerimientos de rendimiento, de interfaz, de ambiente.

Definiciones:
Requisitos del S... Los requisitos software son la descripción de las características y las
funcionalidades del sistema 'target'. Los requisitos nos comunican las
expectativas de los consumidores de productos software. Los requisitos
pueden ser obvios o estar ocultos, conocidos o desconocidos, esperados o
inesperados, des del punto de vista del cliente. Otras definiciones son:
Una característica del sistema que es una condición para su aceptación
(DoD, 1994).
Condición o capacidad que debe exhibir o poseer un sistema para
satisfacer un contrato, estándar, especificación, u otra documentación
formalmente impuesta (IEEE, 1999a).
Una condición o capacidad que debe ser conformada por el sistema
(RUP).
Algo que el sistema debe hacer o una cualidad que el sistema debe
poseer (Robertson - Robertson).

Características:
Debe redactarse en un lenguaje
comprensible por los inversores
en lugar de uno de tipo técnico y
especializado, aunque aun así
debe referenciar los aspectos
importantes.
Conciso
Ningún requisito debe entrar en
conflicto con otro requisito
diferente, ni con parte de otro.
Asimismo, el lenguaje
empleado entre los distintos
requisitos debe ser consistente
también.
Consistente
Los requisitos deben
contener en sí mismos toda
la información necesaria, y no
remitir a otras fuentes
externas que los expliquen
con más detalle.
Completo
Las características de un requerimiento son sus propiedades principales. Los requisitos bien formulados deben satisfacer
varias características tanto individualmente como en grupo. Si no lo hacen, deben ser reformulados hasta hacerlo.
El texto debe ser claro, preciso y
tener una única interpretación
posible.
No Ambiguo

Características:
Un requisito debe ser un objetivo
realista, posible de ser
alcanzado con el dinero, el
tiempo y los recursos
disponibles.
Alcansable
Se debe poder verificar con
absoluta certeza, si el requisito
fue satisfecho o no. Esta
verificación puede lograrse
mediante inspección, análisis,
demostración o testeo.
Verificable
Un requerimiento es necesario si
su omisión provoca una deficiencia
en el sistema a construir, y además
su capacidad, características
físicas o factor de calidad no
pueden ser reemplazados por otras
capacidades del producto o del
proceso.
Necesario
Normalmente, no todos los
requisitos son igual de
importantes. Los requisitos
pueden clasificarse por
importancia (esenciales,
condicionales u opcionales) o por
estabilidad (cambios que se
espera que afecten al requisito).
Clasificable

Características:
Un requisito es modificable si
los cambios en los mismos
pueden realizarse de forma fácil,
completa y consistente.
Modificable
Un requisito debe de ser
rastreable desde que se define y
durante todo el desarrollo del
software, lo cual garantiza una
adecuada administración del
cambio con el fin de evaluar el
impacto en el resto del sistema.
Trazable o Rastreable
Nota: Estas características suelen ser subjetivas, es decir, no pueden
ser calculadas de forma automática por ningún sistema. Por ello, se
tiende a utilizar métricas o indicadores que sí que pueden ser
calculados de forma automática y que, de algún modo, pueden
contribuir a ponderar las anteriores características.

Clasificación de los Requisitos del Software:
Requisitos
No Funcionales
Requisitos
Funcionales

Requisitos Funcionales:
Requisitos del S… Son declaraciones de los servicios que proveerá el sistema, de la
manera en que éste reaccionará a entradas particulares y de
cómo se comportará en situaciones particulares. Pueden declarar
lo que el sistema no debe hacer. Una falla de un requerimiento
funcional degrada un sistema. Estos requerimientos dependen
del tipo de software:
Por ejemplo, para un sistema que imprime cheques
semanales de pago, los requerimientos funcionales deben
responder a preguntas como:
- ¿Qué entrada es necesaria para que un cheque se
imprima?
- ¿Bajo que condiciones puede cambiar el monto del
pago?
- ¿Qué provoca la remoción de un empleado de la
nómina de pago?

Requisitos Funcionales:
Requisitos del S… Otro ejemplo seria un sistema de biblioteca, algunos tipos
de requerimientos funcionales serian los siguientes:
- El usuario deberá tener la posibilidad de buscar en el
conjunto inicial de la base de Datos o seleccionar un
subconjunto de ella.
- El sistema deberá proveer visores adecuados para
que el usuario lea documentos en el almacén de
documentos.
- A cada pedido se le deberá asignar un identificador
único que el usuario podrá copiar al área de
almacenamiento permanente de la cuenta.

Requisitos No Funcionales (RNF):
Requisitos del S…
Son aquellos requerimientos que no se refieren directamente a las
funciones específicas que entregará el sistema, sino a las
propiedades emergentes de éste tales como la fiabilidad,
portabilidad, la capacidad de almacenamiento, entre otros.
Definen las restricciones del sistema como la capacidad de
dispositivos de E/S y la representación de datos que se utiliza en las
interfaces del sistema. Incluyen restricciones cuantitativas, como el
tiempo de respuesta o precisión, tipo de plataforma (lenguajes de
programación y/o sistemas operativos, entre otros).
En general se refieren al sistema como un todo y no a rasgos
particulares, por lo tanto, una falla de un requerimiento no
funcional, podría inutilizar un sistema.
Ejemplos de este tipo de requerimiento son:
- El sistema debe ser desarrollado sobre un computador X
- Los estándares de desarrollo deben ser los que la
organización tiene establecidos.

Requisitos No Funcionales:
Se detallarán los requisitos
relacionados con la carga que se
espera tenga que soportar el
sistema. Por ejemplo, el número de
terminales, el número esperado de
usuarios simultáneamente
conectados, número de
transacciones por segundo que
deberá soportar el sistema.
Requisitos de Rendimiento
Se describirán los requisitos
que afecten a la interfaz de
usuario, interfaz con otros
sistemas (hardware y software)
e interfaces de
comunicaciones.
Requisitos de Interfaz Externa
Se detallarán los atributos de
calidad del sistema: Fiabilidad,
mantenibilidad, portabilidad, y, muy
importante, la seguridad. Deberá
especificarse qué tipos de usuario
están autorizados, o no, a realizar
ciertas tareas, y cómo se
implementarán los mecanismos de
seguridad.
Atributos de Calidad
Algunos Subtipos de Requisitos No Funcionales de acuerdo a la IEEE 830-1998 son:
Todo aquello que restrinja las
decisiones relativas al diseño de
la aplicación: Restricciones de
otros estándares, limitaciones
del hardware, entre otros.
Restricciones de Diseño

Niveles/Representación:
Niveles de Requisitos
Los requisitos se pueden definir a distintos niveles de
abstracción o detalle:
- Usuario (needs).
- Sistema (features).
- Software (SW requirements).

Definición:
Niveles de Requisitos Usuario (needs): Declaraciones definidas mediante lenguaje natural,
tablas y diagramas, de los servicios que el sistema provee y sus
restricciones operacionales. Pueden responder a varios orígenes:
- Dominio del problema (Requisitos de Dominio).
- Intereses de la organización (Requisitos de Negocio u
Organizacionales).
- Necesidades de los usuarios finales del software.
Sistema (features): Estos requisitos engloban a los requisitos de
diferentes interesados: usuarios, clientes, autoridades; así como
elementos de tipo hardware, software, firmware, personas,
información, técnicas, facilidades y servicios. Se obtiene un documento
estructurado con las descripciones detalladas de las funciones, servicios
y restricciones operacionales del sistema. Define lo que deberá ser
implementado. Puede ser parte de un contrato con el cliente.
Software (SW requirements): Son declaraciones detalladas de diseño e
implementación del software.

Ejemplos:
Niveles de Requisitos Usuario (needs):
- El software debe proveer un medio de representar y
acceder a los ficheros externos creados por otras
herramientas.
Sistema (features):
- El usuario debe poder elegir el tipo de fichero
externo.
- Cada tipo de fichero externo debe poder tener
asociada una herramienta externa para editarlo y
mostrarlo.
- Cada tipo de fichero externo tiene un icono asociado.
Software (SW requirements):
- Los iconos de los tipos de fichero se guardan en
archivos JPG.

Representación:
Niveles, Tipos y ERS

Definición y Tipos:
Stakeholders Si los requisitos expresan necesidades y restricciones, ¿quiénes
tienen estas necesidades? ¿Quién decide las restricciones que
debe cumplir el software?
Los stakeholders de un proyecto son aquellas personas y
entidades que tienen algún impacto o interés en éste.
En este sentido, el término se utiliza para referirse a cualquier
persona que tiene influencia directa o indirecta sobre los
requisitos del sistema.
Entre los stakeholders se encuentran:
- Los usuarios finales: los que utilizan o interactúan con el
sistema y todos aquellos en la organización se que verán
afectados por dicho sistema.

Tipos:
Stakeholders Entre los stakeholders se encuentran:
- Los clientes: quienes serán los propietarios del software
o que representan el mercado de destino.
- Analistas de mercado: Identifican lo que el mercado
demanda.
- Reguladores: Aseguran el cumplimiento con las normas
y leyes establecidas.
- Los ingenieros: que desarrollan o dan mantenimiento a
otros sistemas relacionados, los administradores del
negocio, los expertos en el dominio del sistema, los
representantes de los trabajadores, entre otros.

Definición:
IR El proceso de recopilar, analizar y verificar las necesidades del
cliente para un sistema de software es llamado Ingeniería de
Requisitos.
En este sentido, la Ingeniería de Requisitos, es el proceso de
desarrollar una especificación de Software. Las
especificaciones pretenden comunicar las necesidades del
sistema del cliente a 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.
La meta de la ingeniería de requisitos es entregar una
especificación de requisitos de software correcta y completa.
Esta apunta a mejorar la forma en que comprendemos y
definimos sistemas de software complejos.

Subprocesos y
Actividades de la IR:
Ingeniería de Requisitos
2
1
Elicitación
Documentación/Especificación
Análisis
Verificación
Validación
Negociación
Desarrollo de Requisitos Gestión de Requisitos

Desarrollo de Requisitos:
Elicitación
Subproceso de la IR La Elicitación es la primera acción a realizar.
Para llevar este subproceso a cabo el ingeniero debe aprender:
- De donde vienen los requisitos, y
- Cómo puede recopilarlos.
Es un subproceso fundamentalmente humano, en el que se
identifican los interesados (stakeholders) y se establecen relaciones
entre el equipo de desarrollo y los clientes.
En este sentido, este subproceso, probablemente es 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.
Las técnicas más comunes que se utilizan en la elicitación son: las
entrevistas, reuniones en grupo, estudio in situ...

Documentación
Subproceso de la IR En esta fase se documentan los requisitos acordados con el cliente,
en un nivel apropiado de detalle. En la práctica, esta etapa se va
realizando conjuntamente con el análisis, pero se podría decir que
la Especificación es el “pasar en limpio” el análisis realizado
previamente aplicando técnicas y/o estándares de documentación,
como la notación UML.

Verificación
Actividad de la IR 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), matriz de interacción, entre otras.
La Veriﬁcación puede considerarse como la actividad cuyo objetivo
es alcanzar la calidad interna exigible a la especiﬁcación de
requisitos conforme a las normas establecidas por la organización
previamente.

Validación
Actividad de la IR La Validación tiene como objetivo es asegurar que los requisitos
elicitados, documentados, analizados y veriﬁcados representan
realmente las necesidades de clientes y usuarios. Es decir, esta
tercera actividad de calidad intenta asegurar que los requisitos
verificados reflejan realmente las necesidades de clientes y
usuarios.
Las técnicas empleadas suelen ser reuniones en las que se revisan
los requisitos mediante el apoyo de prototipos de interfaz de
usuario.
Por lo tanto, los requisitos deben ser validados para:
- Asegurar que el ingeniero software los ha comprendido.
- El documento de ERS es conforme a los estándares
establecidos, comprensible, consistente y completo.
Se trata de asegurar que el documento ERS define el
software adecuado, es decir, el que espera el usuario.

Negociación
Subproceso de la IR La Negociación de requisitos es el proceso de discutir los
conflictos encontrados y llegar a algún compromiso que satisfaga
a todos los stakeholders.
Ejemplo: En el desarrollo de cierta aplicación para una
empresa el departamento de ventas quiere tener acceso total
a los recursos almacenados y a la lista de clientes, mientras
que el de seguridad quiere controlar dichos recursos y permitir
sólo un acceso restringido.
Tareas de la negociación:
- Discutir los requisitos conflictivos.
- Establecer prioridades en los requisitos.
- Compromiso final sobre el conjunto de requisitos.
En este sentido, el objetivo de este subproceso es buscar
soluciones a los conflictos detectados que satisfagan a los
distintos stakeholders.

Gestión de Requisitos:
Subproceso de la IR La Gestión de Requisitos consiste en gestionar:
- Los cambios en los requisitos acordados.
- Las relaciones entre requisitos.
- Las dependencias entre el documento ERS y otros documentos,
Dado que los requisitos cambian ya sean por: cambio en la
estrategia o prioridades del negocio, cambios tecnológicos o
cambios en leyes o regulaciones.
En este sentido, 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.

Proceso:
Proceso de la IR

Importancia/Beneficios:
IR Los principales beneficios que se obtienen de la Ingeniería de
Requisitos son:
- Permite gestionar las necesidades del proyecto en forma
estructurada: Cada actividad de la Ingeniería de Requisitos
consiste de una serie de pasos organizados y bien definidos.
- Mejora la capacidad de predecir cronogramas de proyectos, así
como sus resultados: La Ingeniería de Requisitos proporciona un
punto de partida para controles subsecuentes y actividades de
mantenimiento, tales como estimación de costos, tiempo y
recursos necesarios.
- Disminuye los costos y retrasos del proyecto: Muchos estudios
han demostrado que reparar errores por un mal desarrollo no
descubierto a tiempo, es sumamente caro; especialmente
aquellas decisiones tomadas durante la Especificación de
Requisitos.

Importancia/Beneficios:
IR Los principales beneficios que se obtienen de la Ingeniería de
Requisitos son:
- Mejora la calidad del software: La calidad en el software tiene
que ver con cumplir un conjunto de requisitos (Funcionalidad,
Facilidad de Uso, Confiabilidad Desempeño, entre otros).
- Mejora la comunicación entre equipos: La especificación de
requisitos representa una forma de consenso entre clientes y
desarrolladores. Si este consenso no ocurre, el proyecto no será
exitoso.
- Evita rechazos de usuarios finales: La Ingeniería de Requisitos
obliga al cliente a considerar sus requisitos cuidadosamente y
revisarlos dentro del marco del problema, por lo que se le
involucra durante todo el desarrollo del proyecto.

Referencias Electrónicas
Referencias Bibliográficas
Bibliográficas y Electrónicas:
Referencias

Pressman R. (2010). Ingeniería de Software. Un Enfoque Práctico. 7ma. Edición. México, D. F: McGraHill Companies,
Inc.
Sommerville, I. (2005). Ingeniería del Software. 7ma. Edición. Madrid, España: Pearson Addison Wesley.
Bibliográficas:
Referencias

Bernárdez, B., Durán A. & Toro, M. (2003). Una Revisión Empírica de Heurísticas de Verificación de Casos de Uso basadas en
Métricas. [Archivo PDF]. https://www.researchgate.net/publication/220268712_Una_Revision_Empirica_de_
Heuristicas_de_Verificacion_de_Casos_de_Uso_basadas_en_Metricas
García, A. & García, F. (2018, Febrero). Ingeniería de Software I - Tema 4: Ingeniería de Requisitos. [Archivo PDF].
https://repositorio.grial.eu/bitstream/grial/1143/1/IS_I%20Tema%204%20-%20Ingenieria%20de%20Requisitos.pdf
González, J. (2009, Marzo). Tema 1: Ingeniería de Requisitos. [Diapositiva de PowerPoint]. SlideShare
https://es.slideshare.net/jcgmoreno/tema-1-ingeniera-de-requisitos
IEEE (2008, Octubre). Especificación de Requisitos según el estándar de IEEE 830 [Archivo PDF].
https://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf
Ingeniería de requisitos. (2011, septiembre 21). EcuRed, de https://www.ecured.cu/Ingenier%C3%ADa_de_requisitos
Electrónicas:
Referencias

Prado, C. (2017, Julio). Ingeniería de Requisitos e Ingeniería de Requerimientos. [Archivo PDF].
https://www.slideshare.net/CesarEPradoN/ingeniera-de-requisitos-e-ingeniera-de-requerimientos-77622450
Ruiz, F. (s.f.). Ingeniería de Software I - Tema 3: Requisitos. [Archivo PDF]. https://www.istr.unican.es/asignaturas/is1/is1-t03-
trans.pdf
Sandoval, M. & García M. (s.f.). La Trazabilidad en el Proceso de Requerimientos de Software. [Archivo PDF].
http://www.iiis.org/CDs2008/CD2008CSC/CISCI2008/PapersPdf/C601UZ.pdf
Electrónicas:
Referencias

Docente:
PNF en Informática
MSC.
salcantara3@gmail.com
Ingeniería del Software II - Trimestre I
SARA ALCÁNTARA
Recurso:
El recurso puede ser utilizado bajo condiciones Creative Commons.
Atribuciones:
Algunas de las imágenes utilizadas son de libre uso,
descargadas desde:

Tema N° 5 Ingeniería de Requisitos y los Requisitos del Software

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Tema N° 5 Ingeniería de Requisitos y los Requisitos del Software

Similar a Tema N° 5 Ingeniería de Requisitos y los Requisitos del Software (20)

Más de SaraEAlcntaraR

Más de SaraEAlcntaraR (8)

Último

Último (20)

Tema N° 5 Ingeniería de Requisitos y los Requisitos del Software