Documento de Requisitos Funcionais

O Documento de Requisitos Funcionais (FRD) é uma declaração formal dos requisitos funcionais de um aplicativo. Ele tem o mesmo propósito de um contrato. Aqui, os desenvolvedores concordam em fornecer os recursos especificados. O cliente concorda em considerar o produto satisfatório se ele fornecer os recursos especificados no FRD.

Os requisitos funcionais capturam o comportamento pretendido do sistema. Este comportamento pode ser expresso como serviços, tarefas ou funções que o sistema deve executar. O documento deve ser adaptado para atender às necessidades de um projeto específico. Eles definem coisas como cálculos do sistema, manipulação e processamento de dados, interface do usuário e interação com o aplicativo.

O Documento de Requisitos Funcionais (FRD) tem as seguintes características -

  • Isso demonstra que o aplicativo agrega valor em termos de objetivos de negócios e processos de negócios nos próximos anos.

  • Ele contém um conjunto completo de requisitos para o aplicativo. Não deixa espaço para ninguém presumir nada que não esteja declarado no FRD.

  • É independente de solução. O ERD é uma declaração do que o aplicativo deve fazer - não de como ele funciona. O FRD não compromete os desenvolvedores com um design. Por esse motivo, qualquer referência ao uso de uma tecnologia específica é totalmente inadequada em um FRD.

O requisito funcional deve incluir o seguinte -

  • Descrições de data para ser inserido no sistema

  • Descrições de operations realizado por cada tela

  • Descrições de work-flows realizado pelo sistema

  • Descrições de system reports ou outras saídas

  • Quem pode entrar no data no sistema?

  • Como o sistema atende aplicável regulatory requirements?

A especificação funcional é projetada para ser lida por um público geral. Os leitores devem compreender o sistema, mas nenhum conhecimento técnico deve ser exigido para compreender este documento.

Entregáveis ​​de requisitos funcionais

Um Documento de Requisitos de Negócios (BRD) consiste em -

  • Functional Requirements- Um documento contendo requisitos detalhados para o sistema que está sendo desenvolvido. Esses requisitos definem os recursos e capacidades funcionais que um sistema deve possuir. Certifique-se de que quaisquer suposições e restrições identificadas durante o Caso de Negócio ainda sejam precisas e atualizadas.

  • Business Process Model - Um modelo do estado atual do processo (modelo "como está") ou um conceito de como o processo deve se tornar (modelo "ser")

  • System Context Diagram - Um diagrama de contexto mostra os limites do sistema, entidades externas e internas que interagem com o sistema e os fluxos de dados relevantes entre essas entidades externas e internas.

  • Flow Diagrams (as-is or to-be)- Os diagramas representam graficamente a sequência de operações ou a movimentação de dados para um processo de negócios. Um ou mais diagramas de fluxo são incluídos dependendo da complexidade do modelo.

  • Business Rules and Data Requirements - As regras de negócios definem ou restringem alguns aspectos do negócio e são usadas para definir restrições de dados, valores padrão, faixas de valores, cardinalidade, tipos de dados, cálculos, exceções, elementos necessários e integridade relacional dos dados.

  • Data Models - Diagramas de relacionamento de entidade, descrições de entidade, diagramas de classe

  • Conceptual Model - Exibição de alto nível de diferentes entidades para uma função de negócios e como elas se relacionam entre si.

  • Logical Model - Ilustra as entidades, atributos e relacionamentos específicos envolvidos em uma função de negócios e representa todas as definições, características e relacionamentos de dados em um ambiente de negócios, técnico ou conceitual.

  • Data Dictionary and Glossary - Uma coleção de informações detalhadas sobre os elementos de dados, campos, tabelas e outras entidades que compõem o modelo de dados subjacente a um banco de dados ou sistema de gerenciamento de dados semelhante.

  • Stakeholder Map- Identifica todas as partes interessadas que são afetadas pela mudança proposta e seu nível de influência / autoridade para os requisitos. Este documento foi desenvolvido na fase de originação da Metodologia de Gerenciamento de Projetos (PMM) e pertence ao Gerente de Projeto, mas precisa ser atualizado pela equipe do projeto à medida que novos / alterados Stakeholders são identificados ao longo do processo.

  • Requirements Traceability Matrix - Uma tabela que ilustra os links lógicos entre os requisitos funcionais individuais e outros tipos de artefatos do sistema, incluindo outros requisitos funcionais, casos de uso / histórias do usuário, arquitetura e elementos de design, módulos de código, casos de teste e regras de negócios.