El documento aborda los requisitos no funcionales en el desarrollo de software, destacando su importancia como restricciones relacionadas con la calidad, eficiencia y seguridad del sistema. Se clasifican en diferentes categorías, incluyendo usabilidad, dependibilidad y requisitos organizacionales y externos, con ejemplos específicos para cada uno. Concluye subrayando la necesidad de una comunicación efectiva y la correcta definición de requerimientos para garantizar el desarrollo de software de calidad y confiable.

1. 1

2. Requisitos no Funcionales
Docente: René Guamán-Quinche
Facultadde la Energía, las Industrias y los RecursosNaturalesNo Renovables
Carrera de Ingeniería en Sistemas/Computación
Junio, 2020
Loja, Ecuador
Estudiantes:
• Alexis David Quizhpe Mendoza.
• Danny Vinicio Vasquez Calderón.
• Angel Favian Minga Medina.
• Danny Michael Jaramillo Jumbo.
• Franklin Stalin Mora Mendoza

3. 3
1. Requisitos no Funcionales.
2. Tabla comparativa Requisitos Funcionales vs Requisitos no
Funcionales.
3. Clasificación de Requisitos No Funcionales.
4. Videos para complementar el tema.
5. Recomendaciones y Conclusiones.
Agenda.

4. Requisitos No Funcionales
• Son aquellos que no se asimilan a las funciones del sistema como tal.
• Especifican restricciones sobre cómo que limiten las elecciones para
construir una solución.
• Son menos números que los RF.
• Conciernen a aspectos como:
➢ Calidad: usabilidad, confiabilidad, eficiencia.
➢ Implementación: plataforma de software, lenguaje de
programación, hardware.
➢ Ambiente: seguridad, privacidad, confidencialidad.

5. Requisitos No Funcionales
Requisitos Funcionales Requisitos No Funcionales
Trata de las diferentes funciones que va a realizar el
producto de software.
Se los conoce como restricciones o requisitos de calidad.
Se divide en requisitos de usuario y de sistema. Se los divide en requisitos de producto, requisitos de
organización y requisitos externos.
Describen el funcionamiento del sistema. Define como debe ser el sistema.
Los RF del usuario se suelen expresar como objetivos del
sistema.
Son atributos relacionados con el tiempo, presupuesto,
calidad.

6. Ejemplos
• Requisito Funcional
El sistema debe enviar un correo electrónico cada vez que se cumpla
una determinada condición.
• Requisito No Funcional
Los correos electrónicos deben enviarse con una latencia de no más de
12 horas desde dicha actividad.

7. Ejemplo
• Mal ejemplo de un RNF
El sistema debe ser seguro.
• Buen ejemplo de un RNF
Las comunicaciones entre los servidores de datos deben estar cifradas
utilizando el algoritmo RSA.

8. Requisitos
no funcionales Organizacionales
Producto
Externos
Seguridad
Dependibilidad
Eficiencia
Usabilidad
Implementación
Estandares
Entrega
Interoperabilidad
Éticos
Legislativos

9. Requisitos no
Funcionales De
Producto
Suele referirse a limites o restricciones
sobre el comportamiento del sistema, por
lo cual establece límites y restricciones
sobre lo que los diseñadores (arquitectos
de software) e ingenieros de software
pueden hacer.

10. Clasificación
• Requerimientos de usabilidad:
La usabilidad se define como el esfuerzo que necesita
hacer un usuario para aprender, usar, ingresar datos e
interpretar los resultados obtenidos de un software de
aplicación
Requerimientos de eficiencia:
Se relaciona en el desempeño en cuanto al tiempo
• Requerimientos de dependibilidad:
Engloba varios atributos:
Disponibilidad, Confiabilidad,
Seguridad industrial, Integridad, Mantenibilidad.
Requerimientos de seguridad:
Capacidades funcionales o no funcionales que debe
tener un sistema para cumplir atributos en el área de
seguridad de tecnología de información entre otros.

11. Ejemplos
Usabilidad
• El tiempo de aprendizaje del sistema por un usuario deberá ser menor a 4 horas.
• El sistema debe contar con manuales de usuario estructurados adecuadamente.
Eficiencia
• El sistema debe ser capaz de procesar N transacciones por segundo
• Toda funcionalidad del sistema y transacción de negocio debe responder al usuario en menos de 5
segundos.
Seguridad
• Los permisos de acceso al sistema podrán ser cambiados solamente por el administrador de acceso a
datos
• Todos los sistemas deben respaldarse cada 24 horas.
Dependibilidad
• El sistema debe tener una disponibilidad del 99,99% de las veces en que un usuario intente accederlo
• El tiempo para iniciar o reiniciar el sistema no podrá ser mayor a 5 minutos.

12. 12
Requisitos no Funcionales
Organizacionales.
Se basa en el proceso de desarrollo del sistema y los
documentos a entregar, éstos deben apegarse al proceso y a los
productos.

13. 13
Clasificación.

14. 14
Ejemplos:
•El procedimiento de desarrollo de software a usar debe estar
definido en manuales de procedimientos y debe cumplir con
los estándares ISO 9000.
•Cada dos semanas deberán producirse reportes gerenciales
en los cuales se muestre el esfuerzo invertido en cada uno
de los componentes del nuevo sistema.
•La metodología de desarrollo de software que se
aplicara será Scrum.

15. 15
Requisitos no funcionales
Externos
Se derivan del entorno
organizacional en el cual
se desarrolla el sistema
y pueden hacerse tanto
sobre el producto (el
software desarrollado) o
también sobre el
proceso de desarrollo de
software. Se clasifican
en:

16. 16
Ejemplos de requerimientos Externos:
•El Escáner de Red del BOSS debe escanear al menos veinte páginas por
minuto a 2400 puntos por pulgada.
•El sistema no seguirá operando si la temperatura externa es menor de 4
grados Celsius.
•La Administración de Registros del BOSS del FBI deberá proteger la
privacidad de los individuos identificados en un registro de acuerdo con la Ley
Federal Políticas de privacidad del gobierno.
•El Sistema de Gestión de Archivos del FBI BOSS deberá mantener la
integridad de los datos guardando copias de seguridad de todas las
actualizaciones de la base de datos para cada transacción de registro.

17. Conclusiones
❑ El resultado satisfactorio de la obtención de requerimientos funcionales como no funcionales
depende de una intensa comunicación entre los involucrados con el sistema (clientes, analistas de
requerimientos, entre otros).
❑ Los requerimientos no funcionales surgen de la necesidad del usuario, restricciones en el
presupuesto, políticas de la organización, necesidad de interoperabilidad con otros sistemas de
software o hardware, factores externos como reglamentos de seguridad y políticas de privacidad.
❑ Los requerimientos tienen que estar bien definidos desde el inicio del proyecto y la probabilidad
de que cambien debe ser mínima. Es necesario cuidar que la modificación de requerimientos no
produzca un sistema que no cumple con las necesidades reales de los usuarios.
❑ Entregar software de calidad, a tiempo y dentro del presupuesto hará que nuestros clientes
confíen, asegurará el crecimiento y madurez de la relación de negocio.

18. Recomendaciones
❑ Para la obtención de requerimientos, se recomienda que la persona que
llevara a cabo la recolección de requerimientos funcionales como no
funcionales, se prepare, se documente, utilice las diferentes técnicas de
recolección de datos.
❑ Desarrollar cuestionarios y preguntas según el usuario que interactuara con el
sistema ya que no todo usuario podrá realizar las mismas actividades que
otros en el sistema, obteniendo así diferentes puntos de vistas.
❑ Es recomendable utilizar más tiempo en el análisis de requerimientos y la
verificación del mismo, ya que si los requerimientos están mal analizados será
una pérdida de tiempo y dinero en volver a analizarlos.

19. 19
Créditos
• Pierdin, M., & Bulder, G. (2012). Dimensions and Types of Non-
Functional Requirements NFR Dimensiones y tipos de
Requisitos No-Funcionales RNF.
• Sommerville, I. (2005). Ingeniería del software. Pearson
educación.
• Koelsch, G. (2016). Requirements writing for system
engineering (p. 428). Berkeley: Apress.

20. Networking académico:
Correo electrónico: rguaman@unl.edu.ec
Twitter: @rene5254
SlideShare: https://es.slideshare.net/rene5254
20
Gracias