Requisitos no funcionales

Objetivo General

Entender el concepto de requisito no funcional para posteriormente identificar y aplicar requisitos no funcionales en el desarrollo de un proyecto.

Objetivos Específicos

1. Comprender teóricamente que es un requisito no funcional.

2. Conocer diversos requisitos no funcionales.

3. Entender la aplicabilidad en el mundo real de los requisitos no funcionales.

Definición

Los requisitos no funcionales especifican los criterios que debe cumplir un sistema para que este sea adecuado a la hora de usar. Definen propiedades y restricciones del sistema.

Ejemplos de requisitos no funcionales

1. Operabilidad: Capacidad de un producto software para permitir al usuario manejarlo y controlarlo. [ISO 9126]

• Ejemplo: Desarrollar un software con un buen Frontend que permita el usuario una buena navegabilidad, usando menús y botones y evitando los comandos. Usando la biblioteca Vis.js que permite la visualización dinámica basada en navegador. La biblioteca está diseñada para ser fácil de usar, manejar grandes cantidades de datos dinámicos y permitir la manipulación de los datos. Además de embellecer la vista con Animate.less que proporciona divertidas y funcionales animaciones convertidas sobre LESS para proyectos Bootstrap o Animate.css el cual brinda simples efectos de desplazamiento para el texto u otros elementos. Simplemente anima lo que quieras con CSS.

2. Tolerancia a fallos: Capacidad del sistema o componente para operar según lo previsto en presencia de fallos hardware o software.

• Ejemplo: Utilizar en el desarrollo de una aplicación las excepciones o herramientas try catch o try except, que controlen errores de ingreso de datos en diversos campos, como solo aceptar letras o números y si el usuario comete dicho error, el sistema no caiga sino que le informe al usuario que no debe de ingresar dichos datos.

3. Modificabilidad: Capacidad del producto software de hacer posible la implementación de modificaciones especificadas. [ISO 9126].

• Ejemplo: Desarrollar un producto que permita realizar modificaciones (en el código) y que estas no afecten en mayor grado a todo el sistema, es decir, teniendo una aplicación que requiere sólo la modificación de un método, al efectuar dicho cambio todo el sistema debería trabajar como se desea (según la modificación realizada).

4. Extensibilidad: Grado en que la implementación del sistema toma en consideración y facilita su crecimiento en el futuro.

• Ejemplo: Realizar un sitio web de ventas que inicialmente solo va a vender vestidos de baño,sin embargo se espera que en seis meses la plataforma también cuente con ropa íntima y pijamas. Lo que obliga al diseñador a tener en cuenta que se requieren nuevas pestañas para las nuevas opciones. Es por esto que se deben usar patrones de diseño (alta cohesión, bajo acoplamiento) en el desarrollo de la aplicación, también hacer un sistema modular que permita crear una página extensible.

5. Despliegue: Las actividades que hace que un sistema de software esté disponible para su uso.

• Ejemplo: Se tiene un juego que ya se esta distribuyendo, por tanto se espera que todas las funcionalidades del juego (mapas, carros, personajes, etc) que se muestran puedan ser usadas por los jugadores y que ninguna de estas genere un error en la partida.

ISO25000. (s.f.). ISO 25010. Recuperado 12 diciembre, 2019, de https://iso25000.com/index.php/normas-iso-25000/iso-25010?limit=3

6. Seguridad o factor de seguridad: Busca hacer que el software desarrollado pueda ser lo más seguro posible, esto no implica que sea 100% invulnerable pero sí que se invierten los recursos justos. (Ejemplo del agua) http://www.dlsiis.fi.upm.es/docto_lsiis/Trabajos20052006/Diez.pdf

7. Gestión de fallas: Capacidad de identificar, seguir y solucionar fallas que se presenten en el sistema.

8. Open source: Permite acceso por parte de otros desarrolladores a el código en caso de que se requiera realizar modificaciones al software.

9. Capacidad de integración: Capacidad de unir los diferentes componentes de una aplicación que por la arquitectura definida en el diseño después de ser desarrollados.

10. Soportabilidad: Medida que nos indica que tan complejo resulta realizar soporte (Diagnóstico y solución de problemas) después de que se realiza la distribución del software. [GOR06] GORTON, Ian. Essential Software Architectu re. Germany, Springer Verlag Berlin Heidelberg, 2006. ISBN 3-540-28713-2.