Document des exigences fonctionnelles

Le document des exigences fonctionnelles (FRD) est une déclaration formelle des exigences fonctionnelles d'une application. Il sert le même objectif qu'un contrat. Ici, les développeurs acceptent de fournir les capacités spécifiées. Le client s'engage à trouver le produit satisfaisant s'il fournit les capacités spécifiées dans le FRD.

Les exigences fonctionnelles capturent le comportement prévu du système. Ce comportement peut être exprimé en tant que services, tâches ou fonctions que le système doit exécuter. Le document doit être adapté aux besoins d'un projet particulier. Ils définissent des éléments tels que les calculs du système, la manipulation et le traitement des données, l'interface utilisateur et l'interaction avec l'application.

Le document des exigences fonctionnelles (FRD) présente les caractéristiques suivantes -

  • Cela démontre que l'application apporte de la valeur en termes d'objectifs commerciaux et de processus commerciaux dans les prochaines années.

  • Il contient un ensemble complet d'exigences pour l'application. Il ne laisse aucune place à quiconque pour supposer quoi que ce soit qui ne soit pas indiqué dans le FRD.

  • Il est indépendant de la solution. La DRE est une déclaration de ce que l'application doit faire - pas de la façon dont elle fonctionne. Le FRD n'engage pas les développeurs dans une conception. Pour cette raison, toute référence à l'utilisation d'une technologie spécifique est tout à fait inappropriée dans un FRD.

L'exigence fonctionnelle devrait inclure les éléments suivants:

  • Descriptions de data à entrer dans le système

  • Descriptions de operations effectué par chaque écran

  • Descriptions de work-flows effectué par le système

  • Descriptions de system reports ou autres sorties

  • Qui peut entrer dans le data dans le système?

  • Comment le système répond applicable regulatory requirements?

La spécification fonctionnelle est conçue pour être lue par un public général. Les lecteurs doivent comprendre le système, mais aucune connaissance technique ne doit être requise pour comprendre ce document.

Livrables des exigences fonctionnelles

Un Business Requirements Document (BRD) se compose de -

  • Functional Requirements- Un document contenant les exigences détaillées du système en cours de développement. Ces exigences définissent les caractéristiques fonctionnelles et les capacités qu'un système doit posséder. Assurez-vous que toutes les hypothèses et contraintes identifiées au cours de l'analyse de rentabilisation sont toujours exactes et à jour.

  • Business Process Model - Un modèle de l'état actuel du processus (modèle «tel quel») ou un concept de ce que le processus devrait devenir (modèle «à être»)

  • System Context Diagram - Un diagramme de contexte montre les limites du système, les entités externes et internes qui interagissent avec le système et les flux de données pertinents entre ces entités externes et internes.

  • Flow Diagrams (as-is or to-be)- Les diagrammes représentent graphiquement la séquence des opérations ou le mouvement des données pour un processus métier. Un ou plusieurs organigrammes sont inclus en fonction de la complexité du modèle.

  • Business Rules and Data Requirements - Les règles métier définissent ou contraignent certains aspects de l'entreprise et sont utilisées pour définir les contraintes de données, les valeurs par défaut, les plages de valeurs, la cardinalité, les types de données, les calculs, les exceptions, les éléments requis et l'intégrité relationnelle des données.

  • Data Models - Diagrammes de relations d'entité, descriptions d'entités, diagrammes de classes

  • Conceptual Model - Affichage de haut niveau des différentes entités pour une fonction métier et de leurs relations les unes avec les autres.

  • Logical Model - Illustre les entités, attributs et relations spécifiques impliqués dans une fonction métier et représente toutes les définitions, caractéristiques et relations des données dans un environnement commercial, technique ou conceptuel.

  • Data Dictionary and Glossary - Une collection d'informations détaillées sur les éléments de données, les champs, les tables et autres entités qui composent le modèle de données sous-jacent à une base de données ou à un système de gestion de données similaire.

  • Stakeholder Map- Identifie toutes les parties prenantes qui sont affectées par le changement proposé et leur niveau d'influence / autorité pour les exigences. Ce document est développé lors de la phase de création de la méthodologie de gestion de projet (PMM) et appartient au gestionnaire de projet, mais doit être mis à jour par l'équipe de projet à mesure que les parties prenantes nouvelles / modifiées sont identifiées tout au long du processus.

  • Requirements Traceability Matrix - Un tableau qui illustre les liens logiques entre les exigences fonctionnelles individuelles et d'autres types d'artefacts système, y compris d'autres exigences fonctionnelles, des cas d'utilisation / récits d'utilisateurs, des éléments d'architecture et de conception, des modules de code, des cas de test et des règles métier.