Quali elementi deve contenere un requisito che può essere considerato completo? O se questo funziona meglio - quali domande dovrei chiedere su un requisito per scoprire se è completo. Non sto parlando dell'implementazione del requisito ma del requisito stesso.
Lo sto chiedendo dal punto di vista di un analista che vuole assicurarsi che i suoi requisiti siano completi prima di trasmetterli al team di progettazione.
Per essere considerati completi, ciascun requisito deve essere (almeno):
Saresti sorpreso di quanto siano soddisfacenti le tue esigenze seguendo solo queste tre linee guida a tutti i costi.
Inoltre, assicurati di scrivere una logica per ciascun requisito. Questo è molto importante e utile lungo la strada quando qualcuno si chiede perché è stato creato un particolare requisito.
E ricorda, i requisiti dovrebbero descrivere COSA il software farà, non come lo farà. Il HOW dovrebbe essere lasciato per il team di progettazione.
Quando viene avviato alla produzione e verificato dal PM. So che non è quello che stai cercando perché vuoi che i requisiti siano corretti prima del design, ma non è così che funziona nel mondo reale. I requisiti sono saltati, fraintesi dagli ingegneri, erroneamente dichiarati dal prodotto, vagamente dichiarati dal prodotto, vagamente compresi dagli ingegneri, ecc. E a volte non è ovvio fino a quando il codice non inizia a essere scritto, o fino a quando un test di integrazione non inizia o fino al PM vede la funzione dimostrata e dice "Questa non è la funzione giusta".
I requisiti raramente vengono completati, di solito si evolvono e cambiano.
Come è stato detto nel famoso libro Programmatore pragmatico, da Journeyman a Master di Andrew Hunt, David Thomas;
The Requirements Pit
Many books and tutorials refer to requirements gathering as an early phase of the project. The word "gathering" seems to imply a tribe of happy analysts, foraging for nuggets of wisdom that are lying on the ground all around them while the Pastoral Symphony plays gently in the background. "Gathering" implies that the requirements are already there—you need merely find them, place them in your basket, and be merrily on your way.
It doesn't quite work that way. Requirements rarely lie on the surface. Normally, they're buried deep beneath layers of assumptions, misconceptions, and politics.
Non sono sicuro se ci sia un punto in cui puoi dire che il requisito è completo.
I am asking this from the perspective of an analyst who wants to make sure that his requirements are complete before passing them on to the design team.
Scelta puramente personale o aziendale, molti progetti iniziano con un'idea di alto livello di ciò che vogliono e si evolveranno da soli per raggiungere lo stadio finale. In alcuni casi potrebbe essere necessario firmare un contratto che indichi il set di requisiti di base. quindi, dipende sempre.
Quando si tratta di requisiti, l'unica cosa importante è che devi essere pronto ad agire in base al cambiamento.
ci sono diverse cose che dovrebbero essere veri per i requisiti da completare.
Se tutte queste sono vere, puoi essere abbastanza sicuro che un requisito è completo. Anche se non puoi essere sicuro al 100% finché i tuoi designer / programmatori non li guardano e li capiscono come te.
Dovresti avere una definizione di fatto .
C'è un post sul blog sul soggetto, ma Di solito uso la definizione di definizione di fatto (yeah) dalla guida di scrum a>.
Definition of “Done”
When the Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the “Definition of Done” for the Scrum Team and is used to assess when work is complete on the product Increment.
The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning Meeting. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current Definition of “Done.”
Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it. Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.
As Scrum Teams mature, it is expected that their Definition of “Done” will expand to include more stringent criteria for higher quality.
Secondo Karl Wiegers in Requisiti software , ci sono caratteristiche di ciascun requisito. Un requisito di alta qualità e ben scritto è:
Questo requisito è appropriato e amp; Catturare pienamente le esigenze aziendali?
Ma, personalmente, dovrei esaminare i requisiti prima di passare alla progettazione.
Considero completo un insieme di requisiti funzionali quando possono essere utilizzati per collegare ogni uscita del sistema a uno o più ingressi di sistema. Questa è tracciabilità orizzontale. Senza di esso ti mancherà circa il 30% dei tuoi requisiti totali. Per ulteriori informazioni, consulta link
Qualsiasi requisito che richieda requisiti figli è, e deve essere, ambiguo. Se fosse inequivocabile, non avrebbe bisogno dei requisiti del bambino. Con questo criterio, la maggior parte dei requisiti in un sistema di grandi dimensioni è ambigua.
Per i requisiti funzionali che non hanno figli, c'è un semplice test per l'ambiguità. Dettagli completi sul link
La descrizione semplificata del test è che i requisiti devono essere tracciabili orizzontalmente e la fase di elaborazione in ogni requisito funzionale deve essere un algoritmo.
Leggi altre domande sui tag requirements