Características de requisitos funcionales y requisitos no funcionales

features functional requirements

Este tutorial explica los tipos, características, comparación de requisitos funcionales y no funcionales y requisitos empresariales y funcionales con ejemplos:

Los requisitos funcionales definen lo que debe hacer un sistema de software. Define una función de un sistema de software o su módulo. La funcionalidad se mide como un conjunto de entradas al sistema bajo prueba a la salida del sistema.

La implementación de los requisitos funcionales en un sistema se planifica en la fase de Diseño del sistema, mientras que, en el caso de los requisitos no funcionales, se planifica en el documento Arquitectura del sistema. El requisito funcional apoya la generación de requisitos no funcionales.

Lo que vas a aprender:

• Requisitos funcionales y requisitos no funcionales
  • Requerimientos funcionales
    • Tipos de requisitos funcionales
  • Requisitos comerciales frente a requisitos funcionales
  • Requisito no funcional
    • Tipos de requisitos no funcionales
  • Derivación de requisitos no funcionales a partir de requisitos funcionales
• Requisitos funcionales frente a requisitos no funcionales
• Conclusión
  • Lectura recomendada

Requisitos funcionales y requisitos no funcionales

Requerimientos funcionales

Entendamos qué son los requisitos funcionales con la ayuda de ejemplos:

Ejemplo: En un proyecto ADAS automotriz, un requisito funcional del sistema de vista envolvente podría ser 'La cámara trasera debe detectar una amenaza u objeto'. Los requisitos no funcionales aquí podrían ser 'la rapidez con la que se debe mostrar la alerta a un usuario cuando los sensores de la cámara detectan una amenaza'.

Toma otro ejemplo del proyecto de sistemas de infoentretenimiento. El usuario habilita Bluetooth aquí desde HMI y verifica si Bluetooth está habilitado o no. Nota , otros servicios Bluetooth se habilitan (de gris a negrita) cuando el usuario habilita Bluetooth.

limpiador de sistema gratuito para windows 7

Por lo tanto, los requisitos funcionales se refieren a un resultado particular del sistema cuando el usuario realiza una tarea en ellos. Por otro lado, el requisito no funcional da el comportamiento general del sistema o su componente y no en función.

Tipos de requisitos funcionales

Los requisitos funcionales podrían incluir los siguientes componentes que pueden medirse como parte de las pruebas funcionales:

# 1) Interoperabilidad: El requisito describe si un sistema de software es interoperable entre diferentes sistemas.

Ejemplo: Para el requisito funcional de Bluetooth en el sistema de infoentretenimiento del automóvil, cuando el usuario empareja un teléfono inteligente basado en Android con Bluetooth con un sistema de infoentretenimiento basado en QNX, deberíamos poder transferir la agenda telefónica al sistema de infoentretenimiento o transmitir música desde nuestro dispositivo de teléfono al sistema de infoentretenimiento.

Por tanto, la interoperabilidad comprueba si la comunicación entre dos dispositivos diferentes es posible o no.

Otro ejemplo es de los sistemas de servicios de correo electrónico como Gmail. Gmail permite importar correos electrónicos desde otro servidor de intercambio de correo como Yahoo.com o Rediffmail.com. Esto es posible debido a la interoperabilidad entre servidores de correo electrónico.

# 2) Seguridad: El funcional requisito describe el aspecto de seguridad de los requisitos de software.

Ejemplo: Servicios basados ​​en ciberseguridad en el sistema basado en cámara de vista envolvente ADAS que utiliza la red de área del controlador (CAN) que protege el sistema de amenazas a la seguridad.

Otro ejemplo es del sitio de redes sociales Facebook . Los datos de un usuario deben estar seguros y no se deben filtrar a un extraño. Esperamos que este ejemplo de Facebook brinde un alcance más amplio de seguridad a los lectores debido a la reciente incidencia de violación de datos en Facebook y las consecuencias que enfrenta Facebook.

# 3) Precisión: La precisión define que los datos ingresados ​​en el sistema son calculados y utilizados correctamente por el sistema y que la salida es correcta.

Ejemplo: En la red de área del controlador, cuando un valor de señal CAN se transmite a través del bus CAN mediante una ECU (es decir, unidad ABS, unidad HVAC, unidad de grupo de instrumentos, etc.), otra ECU podrá identificar si los datos enviados son correctos o no. mediante verificación CRC.

Otro ejemplo puede ser de una solución de banca en línea. Cuando el usuario recibe un fondo, la cantidad recibida debe acreditarse exactamente en la cuenta y no se acepta variación en la precisión.

# 4) Cumplimiento: Los requisitos funcionales de cumplimiento validan que el sistema desarrollado cumple con los estándares industriales.

Ejemplo: Si las funcionalidades de los perfiles de Bluetooth (es decir, transmisión de audio a través de A2DP, llamada telefónica a través de HFP) cumplen con las versiones de perfil de liberación de Bluetooth SIG.

Otro ejemplo puede ser el de Apple Car play en el sistema de infoentretenimiento del automóvil. La aplicación del infoentretenimiento obtiene un certificado de manzana si todas las condiciones previas mencionadas en el sitio web de Apple las cumplen los dispositivos Car Play de terceros (infoentretenimiento en este caso).

Otro ejemplo puede ser desde una aplicación basada en web para el sistema de emisión de billetes de tren. El sitio web debe seguir las pautas de ciberseguridad y cumplir con la World Wide Web en términos de accesibilidad.

Ejemplo de formulario de requisitos:

Ya hemos visto qué es el requisito funcional con algunos ejemplos. Veamos ahora cómo se vería un requisito funcional cuando se integra en herramientas de gestión de requisitos como IBM DOORS. Hay varios atributos que deben tenerse en cuenta al documentar un requisito funcional en la herramienta de gestión de requisitos.

A continuación, se muestran algunos atributos que deben tenerse en cuenta:

1. Tipo de objeto: Este atributo explica qué sección del documento de requisitos forma parte de este atributo. Pueden ser Encabezado, Explicación, Requisito, etc. En su mayoría, la sección 'Requisito' se considera para la implementación y las pruebas, mientras que las secciones de encabezado y explicación se utilizan como descripciones de apoyo para los requisitos para una mejor comprensión.
2. Persona responsable: Un autor que ha documentado el requisito en la herramienta de gestión de requisitos.
3. Nombre del proyecto / sistema: El Proyecto para el que se aplica el requisito, por ejemplo, “Sistemas de infoentretenimiento para XYZ OEM (fabricante de equipos originales) una empresa de automoción o aplicación web para la sociedad anónima bancaria ABC”.
4. Número de versión del requisito: Este campo / atributo notifica el número de versión del requisito si el requisito ha sufrido múltiples modificaciones debido a actualizaciones del cliente o cambios en el diseño del sistema.
5. ID de requisito: Este atributo menciona el ID de requisito único. El Id. De requisito se utiliza para rastrear los requisitos en la base de datos fácilmente y también para mapear los requisitos en el código de manera eficiente. También se puede utilizar para proporcionar una referencia a los requisitos al registrar defectos en las herramientas de seguimiento de errores.
6. Descripción del requisito: Este atributo es uno de los atributos más importantes que explican el requisito. Al leer este atributo, un ingeniero podría comprender el requisito.
7. Estado del requisito: El atributo de estado del requisito indica el estado de un requisito en la herramienta de gestión de requisitos, es decir, si se acepta, se pone en espera, se rechaza o se elimina el proyecto.
8. Comentarios: Este atributo proporciona a la persona responsable o al administrador de requisitos una opción para documentar cualquier comentario sobre el requisito. Ejemplo: un posible comentario para un requisito funcional podría ser “dependencia de un paquete de software de terceros para implementar el requisito”.

Una instantánea de DOORS

Derivación de requisitos funcionales a partir de requisitos comerciales

Esto ya está cubierto como parte de la sección ' Derivación de requisitos funcionales de requisitos comerciales ' bajo la Análisis de requisitos artículo.

Requisitos comerciales frente a requisitos funcionales

Esta diferencia está vagamente cubierta en el Análisis de requisitos artículo. Sin embargo, intentaremos resalte algunos puntos más aquí en la siguiente tabla:

Requisito no funcional

El requisito no funcional dice sobre 'qué debería ser un sistema' en lugar de 'qué debería hacer un sistema' (requisito funcional). En su mayoría, se derivan de requisitos funcionales basados ​​en las aportaciones del cliente y otras partes interesadas. Los detalles de implementación de requisitos no funcionales se documentan en el documento Arquitectura del sistema.

Los requisitos no funcionales explican los aspectos de calidad del sistema que se va a construir, a saber. rendimiento, portabilidad, usabilidad, etc. Los requisitos no funcionales, a diferencia de los requisitos funcionales, se implementan de forma incremental en cualquier sistema.

URPS (Usabilidad, confiabilidad, rendimiento y compatibilidad) de FURPS Los atributos de calidad (funcionalidad, usabilidad, confiabilidad, rendimiento y compatibilidad) que se utilizan ampliamente en la industria de TI para medir la calidad de un desarrollador de software, están todos cubiertos en requisitos no funcionales. Además, también hay otros atributos de calidad (detalles en la siguiente sección).

Wikipedia llama al requisito no funcional como 'ilidades' a veces, debido a la presencia de varios atributos de calidad como la portabilidad y la estabilidad.

Tipos de requisitos no funcionales

Los requisitos no funcionales consisten en los siguientes subtipos (no exhaustivos):

# 1) Rendimiento:

Un tipo de atributo de rendimiento de requisito no funcional mide el rendimiento del sistema. Ejemplo: En el sistema de vista envolvente ADAS, “la vista de la cámara trasera debe mostrarse dentro de los 2 segundos posteriores al encendido del automóvil”.

Otro ejemplo del rendimiento podría ser de un sistema de información y entretenimiento Sistema de navegación. “Cuando un usuario va a la pantalla de navegación e ingresa el destino, la ruta debe calcularse en“ X ”segundos”. Uno mas ejemplo desde la página de inicio de sesión de la aplicación web. 'Tiempo que tarda en cargarse la página de perfil de usuario después de iniciar sesión'.

Recuerde que la medición del rendimiento del sistema es diferente a la medición de la carga. Durante la prueba de carga, cargamos la CPU y la RAM del sistema y verificamos el rendimiento del sistema. En el caso del rendimiento, probamos el rendimiento del sistema en condiciones normales de carga / estrés.

# 2) usabilidad :

La usabilidad mide la usabilidad del sistema de software que se está desarrollando.

Por ejemplo , se desarrolla una aplicación web móvil que le brinda información sobre la disponibilidad de fontaneros y electricistas en su área.

La entrada a esta aplicación es el código postal y el radio (en kilómetros) desde su ubicación actual. Pero para ingresar estos datos, si el usuario tiene que navegar a través de múltiples pantallas y la opción de ingreso de datos se muestra en pequeños cuadros de texto que no son fácilmente visibles para un usuario, entonces esta aplicación no es fácil de usar y, por lo tanto, la usabilidad de la aplicación será muy bajo.

# 3) Mantenibilidad :

La capacidad de mantenimiento de un sistema de software es la facilidad con la que se puede mantener el sistema. Si el tiempo medio entre fallos (MTBF) es bajo o el tiempo medio de reparación (MTTR) es alto para el sistema que se está desarrollando, entonces la capacidad de mantenimiento del sistema se considera baja.

La capacidad de mantenimiento se mide a menudo a nivel de código utilizando la complejidad ciclomática. La complejidad ciclomática dice que cuanto menos complejo es el código, más fácil es mantener el software.

Ejemplo: Se desarrolla un sistema de software que tiene un alto número de códigos muertos (códigos no utilizados por otras funciones o módulos), altamente complejo debido al uso excesivo de la condición if / else, bucles anidados, etc. o si el sistema es enorme con códigos en ejecución. en muchos millones de líneas de códigos y sin comentarios adecuados. Tal sistema es de bajo mantenimiento.

Otro ejemplo podría ser de la página web de compras en línea. Si hay muchos enlaces externos en el sitio web para que el usuario pueda tener una visión general del producto (esto para ahorrar en la memoria), entonces la capacidad de mantenimiento de este sitio web es baja. Esto se debe a que, si cambia el enlace de la página web externa, también debe actualizarse en el sitio web de compras en línea y con demasiada frecuencia.

# 4) Fiabilidad :

La confiabilidad es otro aspecto de la disponibilidad. Este atributo de calidad enfatiza la disponibilidad de un sistema bajo ciertas condiciones. Se mide como MTBF al igual que la mantenibilidad.

Ejemplo: Las características mutuamente excluyentes como la cámara de vista trasera y el remolque en el sistema de cámara de vista envolvente ADAS deberían funcionar de manera confiable en el sistema sin interferencias entre sí. Cuando un usuario llama a la función Trailer, la vista trasera no debe interferir y viceversa, ya que ambas funciones acceden a la cámara trasera del automóvil.

Otro ejemplo desde el sistema de reclamaciones de seguros en línea. Cuando un usuario inicia el informe de reclamaciones y luego carga las facturas de gastos relevantes, el sistema debe dar tiempo suficiente para que se complete la carga y no debe cancelar el proceso de carga rápidamente.

# 5) Portabilidad:

Portabilidad significa la capacidad de un sistema de software para funcionar en un entorno diferente si el marco dependiente subyacente permanece igual.

Ejemplo: El sistema / componente de software en un sistema de información y entretenimiento desarrollado (es decir, servicio Bluetooth o servicio multimedia) para un fabricante de automóviles debe permitir su uso en otro sistema de información y entretenimiento con poco o ningún cambio en el código, aunque los dos sistemas de información y entretenimiento son completamente diferentes. .

Tomemos otro ejemplo de WhatsApp. Es posible instalar y usar el servicio de mensajería en IOS, Android, Windows, tableta, computadora portátil y teléfono.

# 6) Compatibilidad:

La capacidad de servicio de un sistema de software es la capacidad de un experto técnico / de servicio para instalar el sistema de software en un entorno en tiempo real, monitorear el sistema mientras está en ejecución, identificar cualquier problema técnico en el sistema y brindar una solución para resolver el problema.

La capacidad de servicio es posible si el sistema se desarrolla para facilitar la capacidad de servicio.

Ejemplo: Proporciona una ventana emergente de recordatorio periódica al usuario para una actualización de software, proporciona un mecanismo de registro / rastreo para depurar problemas, recuperación automática de fallas a través del mecanismo de reversión (revertir el sistema de software al estado de condición de trabajo anterior).

Otro ejemplo de Rediffmail. Cuando hubo una actualización en la versión del servicio de correo basado en la web, el sistema permitió al usuario cambiar a una versión más nueva del sistema de correo manteniendo intacto el anterior durante algunos meses. Esto también mejora la experiencia del usuario.

# 7) Adaptabilidad:

el mejor software gratuito de recuperación de datos de windows 10

La adaptabilidad de un sistema se define como la capacidad de un sistema de software para adaptarse al cambio en un entorno sin ningún cambio en su comportamiento.

Ejemplo: El sistema de frenos antibloqueo en el automóvil debe funcionar de manera estándar en todas las condiciones climáticas (frío o calor). Otro ejemplo podría ser el de un sistema operativo Android. Se utiliza en diferentes tipos de dispositivos, a saber. Teléfonos inteligentes, tabletas y sistemas de infoentretenimiento y son altamente adaptables.

Además de los 7 requisitos no funcionales enumerados anteriormente, tenemos muchos otros como:

Accesibilidad, Copia de seguridad, Capacidad, Cumplimiento, Interoperabilidad de datos, Retención de datos, Dependencia, Implementación, Documentación, Durabilidad, Eficiencia, Explotabilidad, Extensibilidad, Gestión de fallas, Tolerancia a fallas, Interoperabilidad, Modificabilidad, Operabilidad, Privacidad, Legibilidad, Informes, Resiliencia, Reutilización, Robustez, escalabilidad, estabilidad, probabilidad, rendimiento, transparencia, integrabilidad.

Cubrir todos estos requisitos no funcionales está fuera del alcance de este artículo. Sin embargo, puede leer más sobre estos tipos de requisitos no funcionales en Wikipedia.

Derivación de requisitos no funcionales a partir de requisitos funcionales

Los requisitos no funcionales pueden derivarse de muchas formas, pero la mejor y la mayoría de las industrias probadas y probadas es a partir de requisitos funcionales.

Tomemos el ejemplo de nuestros sistemas de infoentretenimiento que ya hemos tomado en algunos lugares de este artículo. El usuario puede realizar muchas acciones en el sistema de infoentretenimiento, a saber. cambiar la canción, cambiar la fuente de la canción de USB a FM o audio Bluetooth, establecer el destino de navegación, actualizar el software de infoentretenimiento mediante una actualización de software, etc.

# 1) Recopilación de requisitos no funcionales:

Enumeraremos las tareas realizadas por un usuario, que es parte de los requisitos funcionales. Una vez que las acciones del usuario se anotan en el diagrama de casos de uso de UML (cada óvalo), comenzaremos preguntas relevantes (cada rectángulo) sobre las acciones de cada usuario. Las respuestas a estas preguntas darán nuestros requisitos no funcionales.

# 2) Categorización de requisitos no funcionales:

El siguiente paso es la categorización de los requisitos no funcionales que hemos identificado mediante preguntas. En esta etapa, podemos verificar la posible respuesta y categorizar las respuestas en posibles categorías no funcionales o diferentes cualidades.

En la siguiente imagen puede ver los posibles atributos de calidad identificados a partir de las respuestas.

Requisitos funcionales frente a requisitos no funcionales

Ya hemos visto qué son los requisitos funcionales y no funcionales y cómo se derivan. Echemos un vistazo a las principales diferencias entre los requisitos funcionales y no funcionales.

Conclusión

Los requisitos forman el bloque de construcción básico para desarrollar cualquier sistema de software. Es posible construir un sistema con requisitos funcionales pero sus habilidades no se pueden determinar ni medir. Dicho esto, es muy importante tener requisitos funcionales de buena calidad derivados de un requisito comercial para tener un sistema de software que funcione de alta calidad.

Por lo tanto, los requisitos funcionales dan la dirección de implementación de un sistema de software, pero los requisitos no funcionales determinan la calidad de implementación que experimentarán los usuarios finales.

Lectura recomendada

• ¿Cómo probar la especificación de requisitos de software (SRS)?
• Pruebas funcionales versus pruebas no funcionales
• ¿Cómo probar una aplicación sin requisitos?
• ¿Qué es el análisis y la recopilación de requisitos en SDLC?
• 5 errores mortales en la gestión de requisitos y cómo superarlos
• Características de requisitos funcionales y requisitos no funcionales
• Cómo crear una matriz de trazabilidad de requisitos (RTM): ejemplo y plantilla de muestra
• Las 20 mejores herramientas de gestión de requisitos (la lista completa)