1. Lo que el software debe de hacer. Se encuentran muy ligados al modelo conceptual propuesto. Se concretarán las operaciones de tratamiento de información que realiza el sistema, tales como almacenamiento de información, generación de informes, cálculos, estadísticas, operaciones, etc.
1.1. ¿Qué hará el sistema? ¿Cuándo lo hará? ¿Existen varios modos de operación? ¿Cómo y cuándo puede cambiarse o mejorarse el sistema? ¿Existen restricciones de la velocidad de ejecución, tiempo de respuesta o rendimiento?
2. REQUERIMIENTOS FUNCIONALES
2.1. Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que éste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos casos, los requerimientos funcionales de los sistemas también pueden declarar explícita mente lo que el sistema no debe hacer.
3. REQUERIIENTOS NO FUNCIONALES
3.1. Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares. Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad. Normalmente apenas se aplican a características o servicios individuales del sistema.
4. Condición o capacidad que debe poseer un sistema par satisfacer un contrato, un estándar, una especificación u otro documento formalmente impuesto.
4.1. Por ejemplo, si un sistema de vuelo no cumple sus requerimientos de fiabilidad, no se certificará como seguro para el funcionamiento; si un sistema de control de tiempo real no cumple sus requerimientos de rendimiento, las funciones de control no funcionarán correctamente. Los requerimientos no funcionales no sólo se refieren al sistema software a desarrollar. Algunos de estos requerimientos pueden restringir el proceso que se debe utilizar para desarrollar el sistema.
5. REQUERIMIENTOS DEL DOMINIO
5.1. Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características y restricciones de ese dominio. Pueden ser funcionales o no funcionales.
6. Los requerimientos del dominio son importantes debido a que a menudo reflejan los fundamentos del dominio de aplicación. Si estos requerimientos no se satisfacen, es imposible hacer que el sistema trabaje de forma satisfactoria. Ejemplo en un Sistema de Biblioteca, este deberá proveer visores para que el usuario lea documentos en el almacén de documentos
6.1. La mayoría de los armazones de desarrollo de aplicaciones (por ejemplo, las MFC y .NET) te ofrecen "casi todo", menos las clases de dominio, cuyos requerimientos debes tú especificar (como Dios te dé a entender) para desarrollar una aplicación de utilidad.
7. CARACTERISTICAS DE LOS REQUERIMIENTOS
7.1. Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir.
7.2. Conciso: Un requerimiento es conciso si es fácil de leer y entender.
7.3. Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción
7.4. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.
7.5. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación.
7.6. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.
