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
- Requisitos funcionales frente a requisitos no funcionales
- Conclusión
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:
- 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.
- Persona responsable: Un autor que ha documentado el requisito en la herramienta de gestión de requisitos.
- 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”.
- 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.
- 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.
- 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.
- 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.
- 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:
Sl. No. | Requisitos comerciales | Requerimientos funcionales |
---|---|---|
7 | Por ejemplo, en el sistema bancario en línea, un requisito comercial podría ser 'Como usuario, debería poder obtener un extracto de transacciones en efectivo'. | El requisito funcional en este sistema de banca en línea podría ser, 'Cuando el usuario proporciona el rango de fechas en la consulta de transacción, esta entrada es utilizada por el servidor y la página web recibe los datos necesarios de la transacción en efectivo'. |
1 | Los requisitos comerciales dicen 'qué' aspecto del requisito del Cliente. Ejemplo, Qué debería ser visible para el usuario después de que el usuario inicie sesión. | Los requisitos funcionales dicen el aspecto 'cómo' de los requisitos comerciales. Ejemplo, Cómo debe mostrar la página web la página de inicio de sesión del usuario cuando el usuario se autentica. |
2 | Los analistas comerciales identifican los requisitos comerciales. | Los desarrolladores / arquitecto de software crean / derivan los requisitos funcionales |
3 | Hacen hincapié en el beneficio para la organización y están relacionados con los objetivos comerciales. | Su objetivo es el cumplimiento de los requisitos del cliente. |
4 | Los requisitos comerciales son del Cliente. | Los requisitos funcionales se derivan de los requisitos del software, que, a su vez, se derivan de los requisitos comerciales. |
5 | Los ingenieros de pruebas de software no prueban los requisitos comerciales directamente. Son probados principalmente por el cliente. | Los ingenieros de pruebas de software prueban los requisitos funcionales y, por lo general, los clientes no los prueban. |
6 | El requisito comercial es un documento de requisitos de alto nivel. | Un requisito funcional es un documento detallado de requisitos técnicos. |
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.
Sl. No | Requisitos funcionales (FR) | Requisitos no funcionales (NFR) |
---|---|---|
7 | Los requisitos funcionales forman el esqueleto de la implementación del sistema de software | Los requisitos no funcionales completan el sistema de software al ayudar a que los requisitos funcionales se mantengan unidos, como un músculo. |
1 | Dicen, lo que debería hacer un sistema. | Dicen, lo que debería ser un sistema. |
2 | Se detallan en el documento Diseño del sistema. | Se detallan en el documento Arquitectura del sistema. |
3 | Hablan del comportamiento de una función o característica. | Hablan del comportamiento de trabajo de un sistema completo o de un componente del sistema y no de una función en particular. |
4 | El usuario pasará la entrada y comprobará si la salida se muestra correctamente. | Cuando el usuario pasa una entrada, los NFR pueden responder las siguientes preguntas: i) ¿Cuánto tiempo se tarda en mostrar la salida? ii) ¿La producción es consistente con el tiempo? iii) ¿Existen otras formas de pasar el parámetro de entrada? iv) ¿Qué tan fácil es pasar el parámetro de entrada? |
5 | En una aplicación web, el usuario debe poder iniciar sesión a través de la autenticación es FR | En una aplicación web, cuánto tiempo se tarda en iniciar sesión en el sitio web, el aspecto de la página de inicio de sesión, la facilidad de uso de una página web, etc. son parte de NFR |
6 | Los requisitos funcionales se derivan primero de los requisitos del software. | Los requisitos no funcionales se derivan de requisitos funcionales. |
8 | Los requisitos funcionales pueden existir sin un requisito no funcional. | Los requisitos no funcionales no pueden existir sin requisitos funcionales. |
9 | Un requisito funcional proporciona información concreta sobre una característica, Ejemplo , La foto de perfil en Facebook debe estar visible al iniciar sesión. | Un requisito funcional puede tener muchos atributos de requisitos no funcionales. Ejemplo, tiempo para iniciar sesión (rendimiento), apariencia de la página de perfil (usabilidad), número de usuarios que pueden iniciar sesión a la vez (capacidad, rendimiento) |
10 | Es posible derivar requisitos funcionales a partir de requisitos de software para casi todos los requisitos comerciales | Los NFR a menudo se pasan por alto para documentarlos, ya que no se hacen preguntas relevantes sobre los FR. |
11 | La implementación de un requisito funcional normalmente se realiza en una compilación de software. | Los NFR se implementan durante todo el ciclo de vida del proyecto hasta que se logra el comportamiento deseado. |
12 | En su mayoría, son visibles para el cliente. | En su mayoría, estos no son visibles para el cliente, pero podrían experimentarse a largo plazo. Ejemplo, La usabilidad, el rendimiento, etc. solo se pueden experimentar a largo plazo, pero no pueden ser visibles en absoluto. |
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)