Documento de requisitos funcionales
El documento de requisitos funcionales (FRD) es una declaración formal de los requisitos funcionales de una aplicación. Tiene el mismo propósito que un contrato. Aquí, los desarrolladores acuerdan proporcionar las capacidades especificadas. El cliente se compromete a considerar satisfactorio el producto si proporciona las capacidades especificadas en el FRD.
Los requisitos funcionales capturan el comportamiento previsto del sistema. Este comportamiento puede expresarse como servicios, tareas o funciones que el sistema debe realizar. El documento debe adaptarse a las necesidades de un proyecto en particular. Definen cosas como cálculos del sistema, manipulación y procesamiento de datos, interfaz de usuario e interacción con la aplicación.
El Documento de Requisitos Funcionales (FRD) tiene las siguientes características:
Demuestra que la aplicación proporciona valor en términos de los objetivos comerciales y los procesos comerciales en los próximos años.
Contiene un conjunto completo de requisitos para la aplicación. No deja lugar para que nadie asuma nada que no esté establecido en el FRD.
Es independiente de la solución. El ERD es una declaración de lo que debe hacer la aplicación, no de cómo funciona. El FRD no compromete a los desarrolladores con un diseño. Por esa razón, cualquier referencia al uso de una tecnología específica es totalmente inapropiada en un FRD.
El requisito funcional debe incluir lo siguiente:
Descripciones de data para ser ingresado en el sistema
Descripciones de operations realizado por cada pantalla
Descripciones de work-flows realizado por el sistema
Descripciones de system reports u otras salidas
¿Quién puede entrar al data en el sistema?
Cómo cumple el sistema aplicable regulatory requirements?
La especificación funcional está diseñada para ser leída por una audiencia general. Los lectores deben comprender el sistema, pero no se requieren conocimientos técnicos para comprender este documento.
Requisitos funcionales Entregables
Un documento de requisitos comerciales (BRD) consta de:
Functional Requirements- Un documento que contiene los requisitos detallados para el sistema que se está desarrollando. Estos requisitos definen las características y capacidades funcionales que debe poseer un sistema. Asegúrese de que las suposiciones y limitaciones identificadas durante el Business Case sean precisas y estén actualizadas.
Business Process Model - Un modelo del estado actual del proceso (modelo "tal cual") o un concepto de lo que debería convertirse en el proceso (modelo "ser")
System Context Diagram - Un diagrama de contexto muestra los límites del sistema, las entidades externas e internas que interactúan con el sistema y los flujos de datos relevantes entre estas entidades externas e internas.
Flow Diagrams (as-is or to-be)- Los diagramas representan gráficamente la secuencia de operaciones o el movimiento de datos para un proceso empresarial. Se incluyen uno o más diagramas de flujo según la complejidad del modelo.
Business Rules and Data Requirements - Las reglas comerciales definen o restringen algunos aspectos del negocio y se utilizan para definir restricciones de datos, valores predeterminados, rangos de valores, cardinalidad, tipos de datos, cálculos, excepciones, elementos requeridos y la integridad relacional de los datos.
Data Models - Diagramas de relación entre entidades, descripciones de entidades, diagramas de clases
Conceptual Model - Visualización de alto nivel de diferentes entidades para una función empresarial y cómo se relacionan entre sí.
Logical Model - Ilustra las entidades, atributos y relaciones específicas involucradas en una función comercial y representa todas las definiciones, características y relaciones de los datos en un entorno comercial, técnico o conceptual.
Data Dictionary and Glossary - Una colección de información detallada sobre los elementos de datos, campos, tablas y otras entidades que componen el modelo de datos subyacente a una base de datos o sistema de gestión de datos similar.
Stakeholder Map- Identifica a todas las partes interesadas que se ven afectadas por el cambio propuesto y su nivel de influencia / autoridad para los requisitos. Este documento se desarrolló en la fase de origen de la Metodología de gestión de proyectos (PMM) y es propiedad del Gerente de proyecto, pero el equipo del proyecto debe actualizarlo a medida que se identifiquen Partes interesadas nuevas o modificadas a lo largo del proceso.
Requirements Traceability Matrix - Una tabla que ilustra los vínculos lógicos entre los requisitos funcionales individuales y otros tipos de artefactos del sistema, incluidos otros requisitos funcionales, casos de uso / historias de usuario, elementos de arquitectura y diseño, módulos de código, casos de prueba y reglas comerciales.