Ingeniería de requisitos funcionales y no

funcionales de un so ware

Requisitos funcionales y no funcionales

Actividad 1

Proceso de obtención de requisitos

Actividad 2

Conclusiones

Bibliografía

PDF Descargable
17

Requisitos funcionales y no funcionales

Requisitos funcionales
 Los requisitos funcionales especifican las condiciones que el so ware debe ser
capaz de desarrollar sin tener en cuenta restricciones sicas.

Asimismo, precisan los comportamientos de entradas y salidas del so ware.

Estas condiciones se iden fican desde el punto de vista del cliente.

Requisitos no funcionales (FURSP+)

Para conocer acerca de los requisitos no funcionales, haga clic en los botones.


 

Func onality (funcionalidad): Seguridad de acceso.

 

Usability (usabilidad): Facilidad de uso.

 

Reliability (fiabilidad): Frecuencia de fallos, capacidad de recuperación.

 

Supportability (portabilidad): Facilidad de mantenimiento.

 

Performance (rendimiento): Tiempo de respuesta.

 

+ Restricciones: Restricciones de diseño, implementación, interfaz y sicas.

Por ejemplo:

P RO C ES O S F U N C I O N A L ES P RO C ES O S N O F U N C I O N A L ES

El aula virtual, ¿qué requisitos funcionales debe cumplir?

Actualizar la información de los profesores que dictan los cursos de postgrado.

Registrar las reglas de evaluación definidas por el asistente académico.

Permi r consultar la programación de las evaluaciones de un curso.

 Crear un foro.

P RO C ES O S F U N C I O N A L ES P RO C ES O S N O F U N C I O N A L ES

Para el caso de la plataforma Blackboard, ¿qué requisitos no funcionales puede

iden ficar?

Tiene que soportar la conexión concurrente de tantos alumnos como

matriculados hay en una misma aula.

Que la mayoría de los usuarios califique como “fácil” la búsqueda de un

contenido.

Que la carga de un archivo no demore más de 3 minutos.

Que en caso de error mientras se rinde una evaluación el usuario pueda

reconectarse desde el punto donde se quedó.

Que el empo de acceso sea 24/7.

3
Proceso de obtención (to elicit) de
requisitos
 1

La obtención de requisitos es la capacidad de trabajar en colaboración con las

partes interesadas para descubrir las necesidades actuales del producto y llegar a
un acuerdo sobre la visión y los obje vos del proyecto propuesto. Se considera
una de las etapas más importantes del desarrollo de so ware (Borland, 2005).
 2

Varios inves gadores coinciden en que los requisitos incorrectos, incompletos y

confusos enen un gran impacto nega vo en la calidad, el coste y el plazo de
entrega de los proyectos de so ware (Polh, 2011).
 3

Para superar estas dificultades y descubrir las necesidades adecuadas de los

interesados, en la literatura, se han propuesto varios procesos para la obtención
de requisitos (Polh, 2010).

Modelos de obtención de requisitos

En la tabla que se muestra a con nuación, se puede observar las ac vidades del
proceso de obtención de requisitos según la fuente de referencia. En ella, es posible
visualizar diferencias así como coincidencias, ambas manteniendo el mismo
obje vo.

Ejercicio:
Tomando en cuenta la aplicación que más use en su vida laboral y bajo su
experiencia con la misma, defina al menos 5 requisitos no funcionales y su sustento.

Ir a la s igu ien te lecció n

27

Actividad 1

Lea y resuelva la siguiente ac vidad.

01/01

Marque la respuesta incorrecta con respecto a los requisitos funcionales:

Se iden fican desde el punto de vista del cliente.

Se especifican las condiciones que el so ware debe ser capaz de

desarrollar sin tener en cuenta restricciones sicas.

Son fáciles de mantener.

Se especifican los comportamientos de entradas y salidas del so ware.

37

Proceso de obtención de requisitos

Las ac vidades que se realizan para la obtención de los requisitos son secuenciales
e itera vas.
Revise los siguientes ejemplos:
1
 2

A continuación, se detallará cada actividad:

Adquisición del conocimiento

El ingeniero de requisitos necesita adquirir conocimientos (acquiring
knowledge) del dominio sobre el po de aplicación que va a
desarrollar.
 Esta ac vidad le permi rá inferir el conocimiento tácito que los
stakeholders no ar culan, evaluar las ventajas y desventajas que serán
necesarias entre los requisitos en conflicto y, a veces, para actuar
como un “user champion” (SWEBOK, 2014).

Determinación de fuentes

Para conocer lo que opina el autor Loucopoulos (1995), haga clic en las imágenes:
 Determinar las fuentes de
requisitos se refiere a
determinar todos los tipos de
fuentes potenciales.

1 of 3

Esto se debe a que los

requisitos pueden provenir
de diferentes fuentes, tales
como:

Usuarios

Sistemas

D t

2 of 3

Una vez que las fuentes de

requisitos han sido
identificadas, el ingeniero
de requisitos puede
 comenzar a obtener
necesidades de los usuarios.

3 of 3

Definición de técnicas

L oucopoul os (1995)
–
Según Loucopoulos, esta ac vidad se centra en elegir la técnica, herramienta o
enfoque de ER adecuada para conseguir expresar las necesidades de los usuarios.
Entre esas técnicas, se consideran: las entrevistas, las encuestas, los proto pos,
etc.
Carri zo et al . (2 014 )
–
Por su parte, Carrizo expone que en la mayoría de los proyectos de so ware se
u lizan varias técnicas, métodos y herramientas, en muchos casos
complementarias a lo largo del proceso de requisitos.
T i pos de técn i cas
–
Entre los pos de técnicas más empleadas, están:

Encuestas

Entrevistas

Observación

Tormenta de ideas

Focus group

Diagrama de casos de usos

Proto pos

Design thinking
 4

Identificación de lista de deseos

 1

Según Pohl (2010), esta ac vidad se refiere a iden ficar las necesidades del
stakeholders, es decir, capturar los requisitos de los usuarios de las fuentes
iden ficadas (sistemas, personas, documentos, etc.) y con la técnica de obtención
adecuada.
 2

Ejemplo:

Integración de la identificación de la lista de

deseos
Esta ac vidad es de vital importancia ya que definirá el orden con el que se podrá
trabajar los requisitos obtenidos.

S EG Ú N P O H L ( 20 1 0 ) PROPÓS IT O

Esta ac vidad se refiere a integrar todas las necesidades del stakeholder.

S EG Ú N P O H L ( 20 1 0 ) PROPÓS IT O

El propósito de esta ac vidad es consolidar, agrupar, ordenar y priorizar los

diferentes requisitos capturados por el analista o el ingeniero de requisitos. De esta
manera, se eliminan las redundancias de los requisitos repe dos para poder
reu lizarlos.

Por ejemplo, en este caso, se define como una lista de casos de uso.

Documentación

Haga clic en los botones para ampliar la información.

  

 
 

Según Mulla et al. (2012), la documentación se refiere a definir la manera de documentar

la información obtenida en la ER.
 

En la ingeniería de so ware, la documentación también se conoce como la especificación,

que se refiere a la producción de un documento o su equivalente electrónico. Este
documento puede ser revisado sistemá camente, evaluado y aprobado (SWEBOK, 2014).
 

La documentación también se refiere a la descripción de las técnicas de las caracterís cas

del so ware.
 

So ware Requirements Specifica ons (SRS). (IEEE Std. 830-1998).

 

Historia de usuario (metodología ágil).

Estructura de un SRS (especificación de

requisitos de so ware)

La especificación de los requisitos de so ware suele tener un orden y una

estructura concreta.
 Por ejemplo, en la siguiente imagen se muestra la estructura en el escenario de
los casos de uso dentro de un marco tradicional de so ware.

Historias de usuario

De igual manera, en métodos ágiles, la documentación de los requisitos está

representada mediante las historias de usuario.
 1

Estructura

La historia ene la siguiente estructura: Como (actor / rol), Quiero (lo que debe
hacer) y Para (obje vo concreto).
 2

Prioridad

El número suele estar relacionado a la prioridad de este.

Refinamiento

Revise la definición proporcionada por dos autores:

 M U L L A ET A L . ( 20 1 2) D A V I S ( 1 9 9 3)

Esta ac vidad se refiere a definir el proceso de validación y corrección de los

requisitos obtenidos.

M U L L A ET A L . ( 20 1 2) D A V I S ( 1 9 9 3)

Los documentos de requisitos pueden estar sujetos a procedimientos de validación

y verificación. Asimismo, pueden ser validados para asegurar que el ingeniero de
so ware ha entendido las necesidades de los usuarios. Además, es importante
verificar que un documento de requisitos cumpla con las cualidades de los
requisitos.
Validación de requerimientos

La validación de requerimientos se concentra en verificar la versión final de la

documentación para que no existan conflictos, omisiones o desviaciones de los
estándares. Si la documentación es clara y completa, se puede con nuar con el
análisis y el diseño del sistema.

Validación de requisitos- Checklist

En la siguiente tabla, se muestra un ejemplo de validación aplicando el checklist de

los requisitos.
Ejercicio:
En el área donde trabaja, es muy probable que exista la necesidad de automa zar
tareas e incluir tecnología emergente como realidad virtual, realidad mixta, IA,
machine learning, etc. Tomando como premisa lo anterior, elabore la lista de deseos
para dicha aplicación.

Ir a la s igu ien te lecció n

47

Actividad 2

Lea y resuelva la siguiente ac vidad.

01/01

¿Qué técnicas son las más u lizadas para recoger las necesidades de los usuarios? Marque
la respuesta correcta.

Encuestas, exposiciones y proto pos

Entrevistas, encuestas y proto pos

Documentos, encuestas y proto pos

Documentos, exposiciones y proto pos

57

Conclusiones

El proceso de obtención de requisitos permite facilitar el desarrollo de la

solución de so ware.

Las historias de los usuarios permiten definir los requisitos, los cuales son
usados, sobretodo, en métodos ágiles.
El refinamiento de requisitos permi rá asegurar su calidad y su uso para
las siguientes etapas del desarrollo de la solución de so ware.

Ir a la s igu ien te lecció n

67

Bibliogra ía

Abran, A., Moore, J. W., Bourque, P., & Dupuis, R. (2004). Guide to the
so ware engineering body o nowledge (2004 version). IEEE Computer
Society.

IEEE 830-1998 - IEEE Recommended Prac ce for So ware Requirements

Specifica ons. Disponible en: h ps://standards.ieee.org/standard/830-
1998.html
Pressman, R. S. (2010). Ingeniería del so ware: un enfoque prác co (3a
ed.). McGraw-Hil

Sommerville, I. (2011). Ingeniería de So ware (9a ed.). Pearson

Educación.

Wong L. and Mauricio D. (2019). Quali es that the ac vi es of the

elicita on process must meet to obtain agood requirement. Journal of
Engineering Science and Technology. 14(5), 2883–2912.
77

PDF Descargable

In gen i erí a de requi si tos f un ci on al es y n o f un ci on al es de

un so ware.pdf
21.1 MB

Mat erial producido por la Univ ersidad P eruana de Ciencias Aplicadas

Autor: Daniel Subauste

IR A LA LECCIÓN 1

UP C, 2022