Requisitos no funcionales

Requisitos no funcionales

Requisitos No Funcionales, son requisitos que imponen restricciones en el diseño o la implementación como restricciones en el diseño o Estándares de Calidad. Son propiedades o cualidades que el producto debe tener.

Generalidades

• Debe pensarse en estas propiedades como las características que hacen al producto atractivo, usable, rápido o confiable.

• Se conocen como un conjunto de características de calidad, que es necesario tener en cuenta al diseñar e implementar el Software.

• No son parte de la razón fundamental del producto pero si son necesarios para hacer funcionar el producto de la manera deseada.

• No modifican la funcionalidad del producto y si añaden funcionalidad al producto.

• Describen la experiencia del usuario cuando trabaja con el producto y fundamentalmente son las características que se representan por casos de usos.

Algunos de los atributos propios de un sistema eficaz no se pueden describir en términos de funcionalidad. En la práctica, los Requisitos No Funcionales son primordiales para el éxito de estos sistemas. Si bien los Requisitos No Funcionales suelen ser difíciles de definir y cuantificar con objetividad, es importante identificarlos, al menos en términos generales, para que puedan estudiarse. Es muy difícil establecer una separación entre requisitos funcionales y no funcionales, ya que la decisión de si es uno u otro puede venir por el nivel de detalle del documento de requisitos. Además, los Requisitos No Funcionales son difíciles de expresar, y mucho más de ser recogidos en un documento de requisitos utilizando las mismas técnicas que para los requisitos funcionales. Hay que tener en cuenta, que normalmente, los errores debidos a Requisitos No Funcionales son los más difíciles y caros de resolver. Los RNF deben establecer restricciones en el producto que está siendo desarrollado, en el proceso de desarrollo y en restricciones específicas que el producto pueda tener. Los Requisitos No Funcionales son difíciles de verificar/testear, y por ello son evaluados subjetivamente.

Categorías

Existen diferentes categorías de los Requisitos No Funcionales entre ellas:

• Requisitos de Apariencia.
• De Usabilidad.
• De Rendimiento.
• De Mantenibilidad y Portabilidad.
• De Seguridad.
• Culturales y Políticos
• Legales.

Además existen otros menos usados pero igual de importantes:

• De Interfaz.
• De Desempeño.
• Operacionales y Económicos.
• Funcionalidad.
• Eficiencia y Simplicidad.

Orientados al Usuario

Existen clasificaciones de requisitos que se solapan con otras, o contienen algunas en su interior. Tal es el caso los requisitos Orientados al usuario que contiene aquellos que están dirigidos al trabajo específico del cliente con el sistema.

Fiabilidad, Seguridad (safety), Usabilidad, Robustez, Disponibilidad, Rendimiento (Tiempo de respuesta, Capacidad, Throughput).

Requisitos de Seguridad

La seguridad de un sistema no solo tiene en cuenta la seguridad del sistema sino, además, el ambiente en el que se usará el sistema. Por lo que se tiene que contemplar la seguridad física del lugar donde se usa la aplicación, los controles administrativos que se establecen de acceso al sistema y las regulaciones legales que afecta o determina el uso del sistema y que serán tenidas en cuenta si se incumple. La seguridad puede ser tratada en tres aspectos diferentes:

Confidencialidad: La información manejada por el sistema está protegida de acceso no autorizado y divulgación.

Integridad: La información manejada por el sistema será objeto de cuidadosa protección contra la corrupción y estados inconsistentes, de la misma forma será considerada igual a la fuente o autoridad de los datos. Pueden incluir también mecanismos de chequeo de integridad y realización de auditorias.

Disponibilidad: Significa que los usuarios autorizados se les garantizará el acceso a la información y que los dispositivos o mecanismos utilizados para lograr la seguridad no ocultarán o retrasarán a los usuarios para obtener los datos deseados en un momento dado.

Requisitos de Rendimiento y Escalabilidad

Se debe de tener en cuenta el requisito de Rendimiento y Escalabilidad porque convendría que los usuarios examinaran con detenimiento hasta qué punto el proyecto se ajusta a sus expectativas en cuanto a los tiempos de respuesta y es capaz de prestar servicio adecuadamente de acuerdo al tipo y tamaño para el que ha sido concebido.

Requisito de Disponibilidad

Hoy las instituciones o centros de trabajos utilizan los sistemas informáticos, conectados a la red. Un cambio fundamental lo constituirá el aumento espectacular de la dependencia de los usuarios con respecto a la red, de modo que si el software dejara de estar disponible, a los usuarios les será imposible continuar su trabajo. Por consiguiente, convendría que los usuarios que se disponen a contratar un sistema identifiquen las necesidades de sus usuarios en cuanto a disponibilidad y las detallen en el momento de la contratación.

Requisito de Fiabilidad

Uno de los más importantes por parte del usuario es la Fiabilidad debido a que debe de tener en cuenta la recuperación frente a fallos de conexión: asegurar que no se pierdan los datos del perfil definido por el usuario. Esto incluye no perderlos en el envío al servidor o en el envío a otras máquinas, como no perderlos si hay un fallo de conexión entre el receptor del usuario y el servidor.

La recuperación frente a fallos del sistema: posibilidad de reiniciar el sistema. Verificar la Fiabilidad en la autenticación de los usuarios y la posibilidad de dar marcha atrás en la definición del perfil de cada usuario.

Orientados al desarrollador

Es semejante a la clasificación Orientado al usuario, surge por las mismas razones, para unificar aquellas clasificaciones con las que trabaja directamente el desarrollador como: Disponibilidad, Portabilidad, Adaptabilidad, Testabilidad, Comprensibilidad.

Requisito de Facilidad de Uso

La definición de este requisito es una cuestión de especial importancia, pues un proyecto puede fracasar porque sus usuarios no encuentren sencillo su uso, porque no exista una interfaz sencilla y atractiva, o un manual que describa el funcionamiento y el uso del sistema al usuario final.

Requisito de Soporte

Le brinda al usuario la facilidad de instalación, facilidad de mantenimiento, lo que requiere código y diseño documentado y facilidad de actualización hacia versiones más moderna.

Requisitos de Software

Debe mencionarse el software del que se debe disponer, después de implementado el sistema.

Requisitos de Hardware

Se deben enunciar los elementos de hardware que se necesitan para que el software cumpla sus funcionalidades.

Restricciones en el diseño y la implementación

Especifica o restringe la codificación o construcción de un sistema, son restricciones que han sido ordenadas y deben ser cumplidas estrictamente.

Requisitos de apariencia o interfaz externa

Este tipo de requisito describe la apariencia del producto. Es importante destacar que no se trata del diseño de la interfaz en detalle sino que especifican cómo se pretende que sea la interfaz externa del producto. También pueden ser necesidades de cumplir con normas estándares, o con los estándares de la empresa para la cual se esté desarrollando el software.

Requisitos de Usabilidad

Describen los niveles apropiados de usabilidad, dados los usuarios finales del producto, para ello deben revisarse las especificaciones de los perfiles de usuarios y las clasificaciones de sus niveles de experiencia.

Fuentes

• RUMBAUGH, I.J.G.B.J.. El Proceso Unificado de Desarrollo de Software. 2000: Addison Wesley. Capítulos 7, 8 páginas 125-163, 187-202.

• Giraldo, O.P. (2007). Ingeniería de Requisitos. Volumen, 13.
• Hurtado, G.P.G. (2006). "Solo requisitos 2006". Volumen, 37.
• Thayer, M.D.a.R. (1990). "Standards, Guidelines and Examples on System and Software Requirements Engineering".