Requisiti di scrittura quando l'attività è volta a migliorare un'implementazione esistente

Per iniziare, direi che non hai informazioni sufficienti per scrivere i requisiti. Il tuo compito sarebbe quello di raccogliere dettagli specifici. Quando hai il compito di migliorare le prestazioni, la prima cosa che dovresti fare è misurare quale sia il rendimento corrente e registrare questi numeri.

Quindi, dovresti decidere insieme al business quale sia l'obiettivo. Se hai questo, puoi scrivere i requisiti. Ecco alcuni esempi:

• Il componente X dovrebbe calcolare Y entro 2 secondi
• Il modulo dovrebbe avere un throughput di almeno 100 richieste al secondo

Fare ciò rende il soggettivo "migliorare le prestazioni" più oggettivo e misurabile. Evita anche discussioni successive in cui alcuni dicono che è peggiorato, alcuni dicono che è rimasto lo stesso e altri dicono che è migliorato. Con dati e benchmark reali puoi dimostrare l'impatto dei cambiamenti.

Vedo due casi: hai i requisiti per il software o non lo hai.

Nel tuo caso particolare, non hai requisiti di prestazione, ma hai requisiti funzionali. È necessario aggiornare le specifiche dei requisiti per aggiungere requisiti prestazionali e associarli a specifiche funzionalità. Quando stai scrivendo questi requisiti di rendimento, dovrebbero comunque aderire a le stesse linee guida generali sulla qualità dei requisiti funzionali , in particolare essere completo, coerente, non ambiguo, tracciabile e verificabile.

Invece di confrontare le prestazioni con il vecchio sistema, considerale semplicemente come nuovi requisiti. Specificare le cose come il tempo massimo per rispondere a un input, il throughput minimo dei dati, gli intervalli tra le uscite (limiti superiore e / o inferiore).

Esempi di requisiti di buona prestazione sono:

The {component} shall respond to {input} within 5 milliseconds.

The {component} shall {output} at 10Hz.

Quando si organizzano i miei requisiti, in genere raggruppo prestazioni e requisiti funzionali insieme. Generalmente, un requisito di prestazioni è associato a una particolare funzione del sistema, forse quando il sistema si trova in un determinato stato. I miei altri gruppi sono vincoli di progettazione (decisioni di progettazione attualmente esistenti e devono guidare i requisiti), requisiti di interfaccia (hardware, software, scambio dati, interfacce utente) e attributi di qualità (le funzionalità, sicurezza, ecc.)

Per completezza, nel caso in cui non avessi una specifica dei requisiti al livello appropriato, inizieresti semplicemente con i nuovi requisiti come descritto sopra in una specifica. Se si dispone di tempo sufficiente, è possibile tornare indietro e scrivere funzionalità, prestazioni e altri attributi di qualità per il sistema e altri componenti e seguire le procedure di test ai requisiti. Si finirebbe con scenari che non sono coperti dai requisiti, ma questa è la natura del trattare con i requisiti non documentati per cominciare.

Ho un po 'di esperienza nell'ingegnerizzazione dei requisiti, anche se per questo tipo di requisiti di contrasto è necessario, a mio parere, dare una visione diversa dei requisiti. Esistono vari metodi per l'evocazione, il raggruppamento, l'analisi, il perfezionamento dei requisiti ecc.

Esiste tuttavia un modello comune alla maggior parte dei metodi e delle pratiche: è necessario adottare punti di vista e prospettive diversi per gli stessi requisiti, in modo tale che i soggetti interessati (e se stessi) comprendano e concordino i requisiti. Non sei ancora in quello stato, quindi devi ottenere maggiori informazioni o fare ipotesi.

Nell'azienda di medie dimensioni su cui sto lavorando in questo momento, dove c'è poca conoscenza dell'ingegneria dei requisiti in generale, scelgo un semplice modello in 3 fasi per discutere le mie ipotesi e definire / concordare i requisiti con lo stakeholder:

Obiettivi aziendali

Gli obiettivi aziendali sono i requisiti più importanti. Guidano tutto e ti danno ragione (e il denaro della tua azienda o altro valore) per qualsiasi attività di sviluppo. Gli obiettivi aziendali devono rispondere alla domanda: perché lo fanno? = > In base a come e come descrivi la tua situazione, non ti è chiaro e forse anche per gli uomini d'affari della tua azienda.

È che alcuni clienti importanti si sono lamentati del fatto che il joystick è troppo lento e lo perderai se questo non è migliorato? Oppure i tuoi concorrenti hanno un sistema complessivamente più reattivo e hai bisogno di stare al passo con la competizione? Se, ad esempio, quest'ultimo è il caso, dovresti confrontare il tuo sistema con la concorrenza e ricavare i requisiti tecnici da questo confronto.

Metterei un punto di domanda all'obiettivo dichiarato "rendere il sistema più veloce". Qualcuno probabilmente aveva buone intenzioni che richiedevano di farlo, ma dovrebbe essere il tuo lavoro come "ingegnere dei requisiti" per fare supposizioni e ragionare dal punto di vista del business.

A seconda di dove lavori e di come appare la tua organizzazione, può o non può essere una buona idea chiedere direttamente un motivo o un obiettivo aziendale alla tua attività. Questo può fare un'impressione negativa. Piuttosto, fai una supposizione chiaramente formulata per l'obiettivo aziendale e chiarisci che la tua ipotesi sarà quella che guida l'analisi e la definizione dei tuoi requisiti tecnici. Spesso questo porterà indirettamente a dibattiti nel reparto business, perché è probabile che l'obiettivo aziendale non sia così chiaro. Qual è quindi un compito aziendale per affinare gli obiettivi.

Anche se non sei un ingegnere dei requisiti ufficialmente (quindi lo metto tra virgolette sopra), dovresti prendere questa posizione in una certa misura. Perché a) qualcuno può incolparti in un secondo momento per qualsiasi motivo, perché è facile affermare che non hai capito il compito senza ulteriori background o obiettivi di business forniti. Gli uomini d'affari lo sanno. Anche se si tratta di giocare brutti scherzi, ma conoscere queste cose ti rende anche parte della soluzione.

Requisiti del prodotto

I requisiti del prodotto dovrebbero dare una risposta alla domanda: che cosa è necessario fare. Dovrebbe anche adattarsi alla visione del prodotto.

Questa parte sembra definita (implementa o reimplementa alcuni moduli all'interno del tuo prodotto). Anche se senza background, non capisco la ragione. Probabilmente lo sai. In caso contrario, dovresti anche chiedere un'immagine più ampia e come le tue modifiche dovrebbero migliorare il prodotto.

Requisiti di sistema

Infine, all'ultimo momento e dal punto di vista aziendale meno importante (non per te ovviamente), i requisiti di sistema rispondono alla domanda: come dovrebbe essere fatto / implementato?

Credo che tu sappia come definirlo. E questo sarà il problema minore per te, dopo aver raccolto i requisiti aziendali e di prodotto.

Inoltre, non devi necessariamente dimostrare o smentire qualsiasi cosa - solo dare delle asserzioni chiare e ben formulate. Fornisci le tue ipotesi insieme ai requisiti definiti al tuo capo e ai tuoi stakeholder. Concordare con loro su entrambi, le ipotesi e i requisiti definiti.

È compito di chiunque "possegga" un requisito (o abbia un interesse in esso) a confutare la tua assunzione. Fornisci le tue ipotesi e i requisiti a tutto ciò che può interessare e le tue possibilità di successo saranno notevolmente aumentate.