Documento sui requisiti funzionali
Il documento sui requisiti funzionali (FRD) è una dichiarazione formale dei requisiti funzionali di un'applicazione. Ha lo stesso scopo di un contratto. Qui, gli sviluppatori accettano di fornire le funzionalità specificate. Il cliente accetta di trovare il prodotto soddisfacente se fornisce le capacità specificate nell'FRD.
I requisiti funzionali catturano il comportamento previsto del sistema. Questo comportamento può essere espresso come servizi, attività o funzioni che il sistema deve eseguire. Il documento dovrebbe essere adattato alle esigenze di un particolare progetto. Definiscono cose come calcoli di sistema, manipolazione ed elaborazione dei dati, interfaccia utente e interazione con l'applicazione.
Il documento sui requisiti funzionali (FRD) ha le seguenti caratteristiche:
Dimostra che l'applicazione fornisce valore in termini di obiettivi e processi aziendali nei prossimi anni.
Contiene una serie completa di requisiti per l'applicazione. Non lascia spazio a nessuno per assumere qualcosa che non sia dichiarato nella FRD.
È indipendente dalla soluzione. L'ERD è una dichiarazione di ciò che l'applicazione deve fare, non di come funziona. L'FRD non impegna gli sviluppatori a un design. Per questo motivo, qualsiasi riferimento all'uso di una tecnologia specifica è del tutto inappropriato in un FRD.
Il requisito funzionale dovrebbe includere quanto segue:
Descrizioni di data da inserire nel sistema
Descrizioni di operations eseguita da ogni schermata
Descrizioni di work-flows eseguito dal sistema
Descrizioni di system reports o altre uscite
Chi può entrare nel data nel sistema?
Come il sistema soddisfa applicabile regulatory requirements?
La specifica funzionale è progettata per essere letta da un pubblico generale. I lettori dovrebbero comprendere il sistema, ma non dovrebbe essere richiesta alcuna conoscenza tecnica per comprendere questo documento.
Requisiti funzionali Deliverables
Un documento sui requisiti aziendali (BRD) è costituito da:
Functional Requirements- Un documento contenente i requisiti dettagliati per il sistema in fase di sviluppo. Questi requisiti definiscono le caratteristiche funzionali e le capacità che un sistema deve possedere. Assicurati che tutti i presupposti e i vincoli identificati durante il Business Case siano ancora accurati e aggiornati.
Business Process Model - Un modello dello stato attuale del processo (modello "così com'è") o un concetto di ciò che il processo dovrebbe diventare (modello "essere")
System Context Diagram - Un diagramma di contesto mostra i confini del sistema, le entità esterne e interne che interagiscono con il sistema e i flussi di dati rilevanti tra queste entità esterne e interne.
Flow Diagrams (as-is or to-be)- I diagrammi rappresentano graficamente la sequenza delle operazioni o lo spostamento dei dati per un processo aziendale. Uno o più diagrammi di flusso sono inclusi a seconda della complessità del modello.
Business Rules and Data Requirements - Le regole aziendali definiscono o limitano alcuni aspetti dell'attività e vengono utilizzate per definire vincoli di dati, valori predefiniti, intervalli di valori, cardinalità, tipi di dati, calcoli, eccezioni, elementi obbligatori e integrità relazionale dei dati.
Data Models - Diagrammi di relazione tra entità, descrizioni di entità, diagrammi di classe
Conceptual Model - Visualizzazione ad alto livello di diverse entità per una funzione aziendale e come si relazionano tra loro.
Logical Model - Illustra le entità, gli attributi e le relazioni specifiche coinvolti in una funzione aziendale e rappresenta tutte le definizioni, le caratteristiche e le relazioni dei dati in un ambiente aziendale, tecnico o concettuale.
Data Dictionary and Glossary - Una raccolta di informazioni dettagliate su elementi di dati, campi, tabelle e altre entità che compongono il modello di dati alla base di un database o di un sistema di gestione dei dati simile.
Stakeholder Map- Identifica tutte le parti interessate che sono interessate dalla modifica proposta e il loro livello di influenza / autorità per i requisiti. Questo documento è sviluppato nella fase di creazione della Metodologia di Project Management (PMM) ed è di proprietà del Project Manager, ma deve essere aggiornato dal team di progetto man mano che vengono identificati nuovi / modificati Stakeholder durante il processo.
Requirements Traceability Matrix - Una tabella che illustra i collegamenti logici tra i requisiti funzionali individuali e altri tipi di artefatti di sistema, inclusi altri requisiti funzionali, casi d'uso / storie utente, architettura ed elementi di progettazione, moduli di codice, casi di test e regole di business.