Nel mio cervello mi sto dibattendo su quale sia la risposta giusta qui e dove il divario nel processo di raccolta dei requisiti è in questa squadra.
-
BA non tecnico - il loro ruolo è quello di scrivere i requisiti aziendali e degli utenti sotto forma di User Story. Quando c'è un convincente motivo aziendale per definire un comportamento generale del sistema, anche se scriveranno storie utente con un attore di sistema. Definiscono i criteri di accettazione per queste storie.
-
Analisti dei sistemi aziendali e SE : il nostro ruolo è di soddisfare i requisiti aziendali e degli utenti e ricavarne i requisiti funzionali. Definiremo generalmente gli attori del sistema e definiremo il comportamento del sistema con la tracciabilità dei requisiti aziendali e delle storie degli utenti.
Il divario su cui sono confuso è che i requisiti aziendali e le storie degli utenti in genere non definiscono i dettagli necessari necessari per descrivere i componenti funzionali e non sono sicuro che dovrebbero anche. I BA non tecnici non comprenderebbero la complessità di come farlo anche se glielo chiedessimo, così sembra che appartengano ai Requisiti Funzionali, tuttavia in base alla definizione formale dei requisiti funzionali essi devono definire il comportamento dei sistemi:
A function is described as a set of inputs, the behavior, and outputs (see also software). Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish. Functional Requirements (Wikipedia)
Tutti nel team hanno a che fare con questo in modo diverso adesso. Il nostro documento approvato per la cattura di FR è limitato in un modo che ci costringe a definire le funzioni di un componente e non i dettagli del componente stesso. Alcuni BSA e SE stanno definendo funzioni con condizioni vuote e criteri di accettazione e utilizzando il campo Input per definire le proprietà del componente. Altri ancora non stanno nemmeno acquisendo le informazioni o le hanno sparpagliate nelle note che allegano alle funzioni.
Altri ancora discutono con i BA non tecnici sostenendo che i loro requisiti non sono abbastanza specifici e la risposta del maestro Scrum ci incoraggia a dividere le cose in oblio totale offuscato con la speranza che le cose diventino più stimabili.
La mia comprensione della definizione dei requisiti funzionali è limitata qui?
CHIARIMENTO: Ho sentito che dovrei chiarire che quando dico Business Requirements intendo affermazioni di visione MOLTO di alto livello da un livello dirigenziale. Sono quasi irrilevanti per il progetto in tutto tranne che per parlare di acqua fredda. I requisiti effettivamente utilizzati sono User Story.