Discusión:Requisito no funcional

La descripción o definición utilizada aquí para el concepto "requisitos (o requerimientos) no funcionales" es bastante exígua y limitada a la metodología orientada a objetos. Esta metodología no posee herramientas que permitan captar o relevar los requermientos no funcionales [1]. Un requerimiento no funcional comprende aspectos relacionados con las llamadas "propiedades emergentes del sistema", como describe Ian Sommerville en su obra "Ingeniería de Software" [2]. Estas propiedades emergentes no funcionales se refieren al comportamiento de los sistemas en su entorno operativo. Ejemplos de propiedades no funcionales son la fiabilidad, el rendimiento, la seguridad y la protección. Estos factores son críticos para sistemas informáticos, ya que un fallo mínimo en alguna de estas propiedades puede hacer inutilizable todo el sistema. Mientras que algunas de las propiedades funcionales pueden no ser necesarias para algunos usuarios siendo para estos el sistema aún aceptable sin ellas, un sistema inseguro, poco fiable o demasiado lento será seguramente rechazado por la mayoría de los usuarios.

Luego, los requerimientos no funcionales son descripciones o especificaciones de esas propiedades emergentes. Entre estas debemos mencionar:

1. restricciones de tipo físico, relacionadas (i) con la cantidad esperada de usuarios que tenga el sistema, (ii) con la arquitectura y/o estructura habitacional de la organización que utilizará el sistema, (iii) con los condicionamientos de tipo tecnológico (por ejemplo tipo de sistema operativo deseado por el cliente, tipo de sistema de bases de datos, modelo de red interna, conectividad con otros sitemas remotos, disponibilidad de servicio eléctrico ininterrumpido, etc.);
2. seguridad del sistema, entendiendo esta como (i) la tolerancia a fallas del sistema tanto a nivel lógico como físico, y la capacidad de recuperación ante estos tipos de fallas, (ii) la capacidad del sistema de resistir ataques informáticos externos, y (iii) la provisión de políticas de jerarquías y restricciones de usuarios del sistema y el rastreo de sus actividades;
3. la usabilidad del sistema, entendida como (i) la facilidad de uso por diferentes actores ("stakeholders") de la organización, (ii) velocidad de carga al inicio del sistema, (iii) velocidad de respuesta ante solicitudes al sistema por parte de los usuarios, (iv) la navegabilidad o facilidad de acceso a distintas funcionalidades ante situaciones no comunes;
4. la fiabilidad del sistema, es decir que el sistema debe comportarse siempre de manera previsible para cualquier usuario (actor);
5. restricciones presupuestarias, que comprenden la capacidad de la organización de absorver los costos del sistema propuesto, tanto a nivel del software como del hardware; y
6. restricciones reglamentarias o legales, que dirigen o limitan la aplicabilidad de todo o parte del sistema software. Entre estas se encuentran las relacionadas con la calidad de software;

Por lo antes expuesto, limitar la definición de los requisitos no funcionales a "atributos de calidad", o como se ha expuesto, "un requisito que especifica criterios que pueden usarse para juzgar la operación de un sistema", es desconocer la profundidad, la naturaleza y el impacto de esos requerimientos en cualquier proceso de desarrollo de software. De lo expuesto en el artículo, estos "... requisitos que ni describen información a guardar, ni funciones a realizar" claramente describen tanto funciones que todo sistema de información debe realizar cuanto información que el sistema debería guardar. Por ejemplo, la tolerancia a fallas, las políticas de usuario, el rastreo de usuarios o la fiabilidad son funcionalidades del sistema de información que, aúnque no integren las llamadas "actividades esenciales", permiten que estas se desarrollen con éxito.

Referencias:

[1] Arlow, Jim y Ila Neustadt: "Programación UML 2"; Anaya Multimedia; Madrid, 2006 - ISBN 978-84-415-2033-2

[2] Sommerville, Ian: "Ingeniería de Software, 7ma edición" (transcripción del cap. 2, §2.1); PEARSON EDUCACIÓN, S.A.; Madrid, 2005 - ISBN 978-84-7829-074-5

Enlaces externos modificados

Hola,

Acabo de modificar el enlace externo 1 en Requisito no funcional. Por favor tomaos un momento para revisar mi edición. Si tenéis alguna pregunta o necesitáis que el bot ignore los enlaces o toda la página en su conjunto, por favor visitad esta simple guía para ver información adicional. He realizado los siguientes cambios:

• Se añadió el archivo https://web.archive.org/web/20150209011617/http://www.stellman-greene.com/aspm/ a http://www.stellman-greene.com/aspm/

Por favor acudid a la guía anteriormente enlazada para más información sobre cómo corregir los errores que el bot pueda cometer.

Saludos.—InternetArchiveBot (Reportar un error) 21:26 1 dic 2017 (UTC)