Formalizzare una specifica dei requisiti scritta in inglese narrativo

Question

Formalizzare una specifica dei requisiti scritta in inglese narrativo

#1 da (5 voti)
#2 da (0 voti)
#3 da (0 voti)

2

Ho una specifica di requisiti di funzionalità piuttosto tecnica, espressa in prosa inglese, prodotta dal mio project manager. È strutturato come una raccolta di schede dell'interfaccia utente, in cui i requisiti per ciascuna scheda sono espressi sotto forma di campi illuminati dell'interfaccia utente e un elenco di regole aziendali per la scheda.

La maggior parte delle regole aziendali sono per i campi dell'interfaccia utente in una scheda, ad esempio:

Deve essere alfanumerico, lunghezza massima 20.
Deve essere un menu a discesa, con valori dalla tabella x.
È obbligatorio.
È obbligatorio in determinate condizioni, ad es. un altro campo è solo popolato o ha un valore specifico.

Quindi le altre regole aziendali diventano un po 'più complesse. La specifica è per un'applicazione di lavoro, quindi l'oggetto business centrale (tabella) è il richiedente e abbiamo diverse altre tabelle con relazioni uno-a-molti con il richiedente, come Laurea, Alta scuola, Impiegato precedente, Diploma, ecc.

Una regola così complessa dice che un campo di stato può essere assegnato a un determinato valore solo se esiste un record su più lati in almeno una delle tabelle a più lati. Per esempio. il candidato ha almeno una High School o almeno un record di diploma.

Sto cercando consigli su come codificare questi requisiti in una specifica più strutturata definita in termini di tabelle, campi e relazioni, in particolare per le regole condizionali per i campi e per la presenza di record correlati. Qualsiasi suggerimento e consiglio saranno i benvenuti, ma sarei felice se potessi trovare un sistema o una struttura già definiti per esprimere cose come questa.

requirements specifications documentation

posta ProfK 14.12.2012 - 09:53

fonte

3 risposte

Leggi altre domande sui tag requirements specifications documentation

Analisi statiche automatiche vs test della scatola bianca Usando quale tecnica facebook e pininterest mostrano le immagini?

score 5 · Answer 1

Potresti formalizzare questi requisiti utilizzando sintassi Gherkin , ad esempio:

Scenario: Entering nothing into the name field
    Given I am on the main data entry tab
    And I have not entered a value into the name field
    When I click OK
    Then I should be prompted to input a value into the name field

Screnario: Name field input too small
    Given I am on the main data entry tab
    And I have entered a value into the name field that is less than 10 characters in length
    When I click OK
    Then I should be warned the name field must be at least 10 characters long

L'idea alla base del cetriolino è che i requisiti (detti " Given, When, Then ") sono suddivisi in feature e ciascuna funzionalità è suddivisa in uno o più scenari. Ogni scenario è codificato con precondizioni ( Dato un contesto che imposta lo scenario in uno stato conosciuto), azioni ( Quando I [l'utente] intraprende qualche azione) e asserzioni ( Quindi alcuni effetti collaterali o obiettivi osservabili dovrebbero essere raggiunti).

Sulla rete ci sono molte informazioni sulle specifiche di Gherkin e su come aiutano a formalizzare e codificare i requisiti, migliorando la comunicazione e la comprensione * tra sviluppatori ed esperti di dominio.

* sì questa è una parola composta:)

score 0 · Answer 2

Prova a modellarlo con oggetti MVC (modello, vista, controllo). Separare i dati dalla presentazione. Ad esempio, hai un oggetto educativo con campi / proprietà per la scuola superiore e il diploma. Il validatore per questo oggetto ha la logica per garantire che l'istruzione non sia valida a meno che uno di questi non sia specificato.

score 0 · Answer 3

La cosa importante che vorrai garantire, indipendentemente dalla sintassi scelta, è che le persone parlino della stessa cosa e utilizzino sempre la parola giusta per quella cosa. Il termine design basato sul dominio per questo è "Ubiquitous Language".

Il tuo esempio di requisiti dell'interfaccia utente per un menu a discesa è scritto in modo generico - qualcuno senza conoscenza di dominio può capire cosa si intende per "valori dalla tabella x". La tua difficoltà sarà nel convertire la lingua da persone che dicono "un elenco a discesa con tutte le città in cui abbiamo account" in una lingua che afferma cose come "un menu a discesa i cui valori sono compilati dalla tabella Città, uniti alla tabella Account, visualizzando solo le città che hanno almeno un account ". Ma ecco la cosa: non è necessario per specificare da quale tavolo proviene. Farlo nella documentazione perpetua la necessità di tradurre avanti e indietro.

Incoraggia invece tutti i membri del team a utilizzare la stessa lingua. In questo caso potrebbe essere qualcosa come "un elenco a discesa che elenca tutte le città account". Gli sviluppatori del progetto sanno a cosa si riferisce una città degli account, ma anche amministratori, utenti, tester ... non tutti hanno motivo di sapere (o preoccuparsi) della struttura del database.

Ora - questo richiederà un impegno da parte di tutti i membri del tuo team. Avrai bisogno di generare una cultura in cui qualcuno dice "aspetta, quando hai detto 'città', intendi Città del Conto o tutte le città del mondo?" è visto come un chiarimento utile piuttosto che un nitpick. Richiederà una dedica al discorso rigoroso che la maggior parte delle persone non ha intrinsecamente. Ma può ripagare enormi dividendi a lungo termine quando tutti nella stanza parlano effettivamente la stessa lingua, piuttosto che avere mille piccole incongruenze, il che significa che le persone non sono sulla stessa pagina.

Se puoi adottare un linguaggio così onnipresente, la traduzione in sintassi Gherkin (o qualsiasi altra) diventa davvero semplice. Se non lo fai, allora una tale traduzione fallirà tipicamente, perché le persone non hanno già sviluppato le abitudini mentali che consentono il linguaggio preciso richiesto da tale strumento.