Categorias de requisitos no funcionales

Mientras que los requisitos funcionales describen lo que debe hacer un producto, los requisitos no funcionales son propiedades o cualidades que el producto debe tener. Estos últimos pueden marcar la diferencia entre un producto bien aceptado y uno con poca aceptación.

El modelo CMMI no considera expresamente una diferencia entre requisitos funcionales y no funcionales. Éstos se identifican básicamente en las prácticas de RD mezclados o derivados entre los requisitos del cliente, productos y componentes y asociados con los atributos de calidad del producto. En el proceso de definición de los requisitos se tienen prácticas que ayudan a identificar no solamente lo que se espera del producto sino también las expectativas de comportamiento o cualidades que se esperan.

Requisitos no funcionales
Los requisitos funcionales son normalmente identificados como parte de las necesidades del producto y la expectativa de respuesta que se tiene en cuanto a lo que debe hacer. La forma de comportamiento o las propiedades del producto muchas veces se omiten o pasan por alto, siendo las que determinan en muchas ocasiones su aceptación. Es importante trabajar en su identificación y documentación para garantizar su cumplimiento. 

Típicamente los requisitos no funcionales se agrupan en las siguientes categorías y aunque no necesariamente se requieren todas, es importante considerar la mayoría de las que aquí se mencionan. 

• Apariencia o interfaz externa. Describe la apariencia del producto, cómo se pretende que sea la interfaz externa del producto o la necesidad de cumplir con normas, estándares, las interfaces de sistemas o los estándares de la empresa.
• Usabilidad. Describen los niveles apropiados de uso. Derivan de una combinación de lo que el cliente está tratando de lograr con el producto y lo que los usuarios finales esperan del mismo.
• Rendimiento. Imponen condiciones a los requisitos funcionales tales como: velocidad de procesamiento o cálculo, eficiencia, disponibilidad, precisión, tiempo de respuesta o de recuperación
• Soporte. Abarcan todas las acciones a tomar una vez que se ha terminado el desarrollo del software para asistir a los clientes, así como lograr su mejoramiento y evolución en el tiempo.
• Portabilidad. Especifican que el producto de software podrá ser usado en diferentes plataformas.
• Seguridad. Considera elementos relacionados con la confidencialidad, integridad y disponibilidad
• Políticos y Culturales. Son factores especiales que pudieran hacer el producto no utilizable debido a costumbres humanas, preferencias o prejuicios. También deben ser considerados los requisitos políticos a nivel de empresa, sucursal o departamento.

• Legales. Estipulan las formas en que el software cumple con las leyes vigentes.
• Confiabilidad. Caracterizan la respuesta del sistema ante los fallos o indican cuán robusto de éste, se establecen en términos de frecuencia y severidad de los fallos, protección contra fallos, recuperación, predicción de fallos y tiempo medio entre fallos.
• Interfaz interna. Enuncian las diferentes vías de interactuar con el sistema, con componentes comprados o reusados de otras aplicaciones, u otros componentes usados que quedan fuera del alcance de la especificación.
• Ayudas y documentación en línea. Se incluye en caso de existir requisitos vinculados al sistema de ayuda, documentación en línea, soporte técnico, instrucciones de instalación, derechos de autor, logos corporativos, iconos y otros elementos de la interfaz de usuario que deban mantenerse consistente con el resto de la documentación.
• Software. Debe mencionar el software del que se debe disponer.
• Hardware. Elementos de hardware de que se disponen.
• 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 .