Requisiti funzionali / non funzionali VS design ideas

Affiderò il SWEBOK ( Book of knowledge di Ingegneria del software ) per guidare la mia risposta.

Nel Requisiti del software * capitolo, vengono fornite definizioni più formali dei termini necessari per la tua domanda.

Functional requirements describe the functions that the software is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities.

Nonfunctional requirements are the ones that act to constrain the solution. Nonfunctional requirements are sometimes known as constraints or quality requirements.

Li metto in evidenza perché sembra che ci sia qualche sovrapposizione nel modo in cui ti è stato richiesto di generare il tuo documento. Hai dichiarato: A SRS should only have functional, non functional and constraints e in base alla definizione di SWEBOK / IEEE puoi vedere che i requisiti e i vincoli non funzionali sono la stessa cosa.

E mentre alcuni potrebbero protestare contro l'eccesso, ci sono tre documenti principali relativi al lavoro sui requisiti.

System Definition Document This document (sometimes known as the user requirements document or concept of operations) records the system requirements. It defines the high-level system requirements from the domain perspective.

System Requirements Specification In this view, system requirements are specified, the software requirements are derived from the system requirements, and then the requirements for the software components are specified.

Software Requirements Specification establishes the basis for agreement between customers and contractors or suppliers (in market-driven projects, these roles may be played by the marketing and development divisions) on what the software product is to do as well as what it is not expected to do.

Quindi il problema con tutto questo è che appare chiaro quando viene spiegato, ma finisce per essere fangoso quando implementato. Per aiutare a mettere a fuoco la mia risposta, ignorerò il System Reqs Spec poiché è un argomento enorme e non del tutto necessario per la tua domanda.

La sfida principale che stai incontrando è che stai mescolando il tuo SDD e i tuoi documenti SoftRS (software). Dal momento che i due documenti sono ponti di comunicazione tra tre campi, è naturale e inevitabile che vedrete qualche sovrapposizione tra i due. L'SDD è un ponte tra il cliente e gli analisti, mentre lo SRS è un ponte tra gli analisti e gli sviluppatori.

Quindi, come traccia la linea tra SDD e SRS? Torniamo alla Ingegneria del sistema trinità:

• what
• why
• how

E dovrebbero davvero andare in questo ordine perché quando guardiamo il V-model , usiamo quelli tre per farci strada attraverso gli strati. Cominci con what & why a livello di sistema. Mentre li acquisisci, inizi a generare idee per how , che passa al livello successivo in V-Model. "Alla fine" finisci con un particolare livello e inizi a rivedere il livello sottostante nello stesso modo. La differenza sui livelli inferiori è che il how del livello superiore diventa questo % di what .

Blah, blah, muro di testo, affrontiamo le tue domande.

FR 1.1 : Have I incorporated a design idea here, would " the system shall have a registration form" be a better functional requirement?

Inizierò con "meh" per una risposta. "visualizza" vs "deve avere" su una forma che richiede l'interazione dell'utente è un po 'inutile. Se un argomento scoppiasse su un progetto reale sulla semantica tra quelle due forme, considererei che un'enorme bandiera rossa e tentare di salvare il progetto. Sul serio.

"Indicazione" implica "avere" mentre "deve avere" implica "visualizzare" in questo caso. Per essere completamente pedante, è necessario almeno "avere e display" per chiarire. Comunque una di queste tre varianti va bene.

F1.2 ,2.3 : Is this not singular? Would the conditions be better written for each its own separate requirement

Sono certamente correlati, e diventa complicato su come vuoi esprimere quelli. Mi affido alle norme del team in questo caso perché ho visto che va in entrambi i modi con risultati equivalenti. La parte importante è essere coerenti nel modo in cui gestisci i requisiti composti come questo.

FR 1.4: Is this a design idea? Is this a correct functional requirement or have I incorporated non functional(performance) in it? Would it be better if I written it like this: FR1 The system shall display an error message when check is unsuccessful. NFR: The system will respond to unsuccesful registration form checks within 1 seconds. Same question with FR 2.8 and 2.9.

Probabilmente li romperò, sì. Ecco perché: Il primo fornisce la funzione (visualizza un messaggio di errore) mentre il secondo fornisce i vincoli (quantità specifica di tempo) nel fornire quella funzione. I vincoli cambiano spesso, ma la funzionalità no. Spostando il vincolo in base alle proprie esigenze, possiamo ottenere un accordo iniziale sulla funzionalità e quindi gestire i vincoli (la velocità di consegna del messaggio) quando entriamo in implementazione.

FR2.3: The system shall check for "completeness", is completeness here used ambigiously? Should I rephrase it?

È vicino a spiegare la completezza con l'elenco degli articoli forniti. Tuttavia, potresti essere più chiaro nello specificare cosa determina la completezza o meno in ciascuno degli elementi che hai elencato.

FR1.2: I added that the system shall require a "Captcha code" is this a functional requirement or does it belong to the "security aspect" of a non functional requirement.

Dipende dal livello del tuo design di cui stai parlando. Ad un livello elevato, è un requisito non funzionale perché è un vincolo. A un livello basso, è un requisito funzionale perché specifica una funzione da fornire.

_{* SWEBOK è attualmente in uno stato di revisione per la prossima versione. Tranne che per il collegamento principale, alcuni dei collegamenti aggiuntivi potrebbero diventare obsoleti.}