Requisiti del software - Tutorialspoint

Requirement Engineering

Il processo per raccogliere i requisiti software dal cliente, analizzarli e documentarli è noto come requirement engineering.

L’obiettivo del requirement engineering è quello di sviluppare e mantenere un sofisticato e descrittivo documento ‘System Requirements Specification’.

Processo di ingegneria dei requisiti

È un processo in quattro fasi, che include –

Studio di fattibilità
Raccolta dei requisiti
Specificazione dei requisiti software
Convalida dei requisiti software

Vediamo brevemente il processo –

Studio di fattibilità

Quando il cliente si avvicina all’organizzazione per ottenere lo sviluppo del prodotto desiderato, si presenta con un’idea approssimativa su quali funzioni il software deve eseguire e quali caratteristiche ci si aspetta dal software.

Facendo riferimento a queste informazioni, gli analisti fanno uno studio dettagliato per sapere se il sistema desiderato e le sue funzionalità sono fattibili da sviluppare.

Questo studio di fattibilità è focalizzato sull’obiettivo dell’organizzazione. Questo studio analizza se il prodotto software può essere praticamente materializzato in termini di implementazione, contributo del progetto all’organizzazione, vincoli di costo e secondo i valori e gli obiettivi dell’organizzazione. Esplora gli aspetti tecnici del progetto e del prodotto come l’usabilità, la manutenibilità, la produttività e la capacità di integrazione.

L’output di questa fase dovrebbe essere un rapporto di studio di fattibilità che dovrebbe contenere adeguati commenti e raccomandazioni per la gestione circa l’opportunità o meno di intraprendere il progetto.

Raccoglimento dei requisiti

Se il rapporto di fattibilità è positivo per intraprendere il progetto, la fase successiva inizia con la raccolta dei requisiti dall’utente. Gli analisti e gli ingegneri comunicano con il cliente e gli utenti finali per conoscere le loro idee su ciò che il software dovrebbe fornire e quali caratteristiche vogliono che il software includa.

Software Requirement Specification

SRS è un documento creato dall’analista di sistema dopo che i requisiti sono stati raccolti dai vari stakeholder.

SRS definisce come il software previsto interagirà con l’hardware, le interfacce esterne, la velocità di funzionamento, il tempo di risposta del sistema, la portabilità del software su varie piattaforme, la manutenibilità, la velocità di recupero dopo un crash, la sicurezza, la qualità, le limitazioni ecc.

I requisiti ricevuti dal cliente sono scritti in linguaggio naturale. È responsabilità dell’analista di sistema documentare i requisiti in linguaggio tecnico in modo che possano essere compresi e utili al team di sviluppo del software.

SRS dovrebbe avere le seguenti caratteristiche:

I requisiti dell’utente sono espressi in linguaggio naturale.
I requisiti tecnici sono espressi in un linguaggio strutturato, che è usato all’interno dell’organizzazione.
La descrizione del design dovrebbe essere scritta in pseudo codice.
Format of Forms and GUI screen prints.
Conditional and mathematical notations for DFDs etc.

Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud. Requirements can be checked against following conditions –

If they can be practically implemented
If they are valid and as per functionality and domain of software
If there are any ambiguities
If they are complete
If they can be demonstrated

Requirement Elicitation Process

Requirement elicitation process can be depicted using the folloiwng diagram:

Processo di elicitazione dei requisiti

Raccolta dei requisiti – Gli sviluppatori discutono con il cliente e gli utenti finali e conoscono le loro aspettative dal software.
Organizzazione dei requisiti – Gli sviluppatori danno priorità e organizzano i requisiti in ordine di importanza, urgenza e convenienza.
Negoziazione & discussione – Se i requisiti sono ambigui o ci sono alcuni conflitti nei requisiti delle varie parti interessate, se lo sono, viene poi negoziato e discusso con le parti interessate. I requisiti possono poi essere prioritarizzati e ragionevolmente compromessi.

I requisiti provengono da vari stakeholder. Per rimuovere l’ambiguità e i conflitti, vengono discussi per chiarezza e correttezza. I requisiti irrealistici sono compromessi ragionevolmente.
Documentazione – Tutti i requisiti formali & informali, funzionali e non funzionali sono documentati e resi disponibili per la successiva fase di elaborazione.

Tecniche di Elicitazione dei Requisiti

L’Elicitazione dei Requisiti è il processo per scoprire i requisiti di un sistema software previsto comunicando con il cliente, gli utenti finali, gli utenti del sistema e altri che hanno un interesse nello sviluppo del sistema software.

Ci sono vari modi per scoprire i requisiti

Interviste

Le interviste sono un forte mezzo per raccogliere i requisiti. L’organizzazione può condurre diversi tipi di interviste come:

Interviste strutturate (chiuse), dove ogni singola informazione da raccogliere è decisa in anticipo, seguono modelli e argomenti di discussione con fermezza.
Interviste non strutturate (aperte), dove le informazioni da raccogliere non sono decise in anticipo, più flessibili e meno parziali.
Interviste orali
Interviste scritte
Interviste one-to-one che si tengono tra due persone dall’altra parte del tavolo.
Interviste di gruppo che si tengono tra gruppi di partecipanti. Aiutano a scoprire qualsiasi requisito mancante in quanto sono coinvolte numerose persone.

Sondaggi

L’organizzazione può condurre sondaggi tra i vari stakeholder interrogando le loro aspettative e i loro requisiti dal sistema futuro.

Questionari

Un documento con una serie predefinita di domande oggettive e le rispettive opzioni viene consegnato a tutti gli stakeholder per rispondere, che vengono raccolte e compilate.

Un difetto di questa tecnica è che se un’opzione per qualche problema non è menzionata nel questionario, il problema potrebbe essere lasciato in sospeso.

Analisi dei compiti

Un team di ingegneri e sviluppatori può analizzare l’operazione per cui è richiesto il nuovo sistema. Se il cliente ha già un software per eseguire una certa operazione, questo viene studiato e vengono raccolti i requisiti del sistema proposto.

Analisi del dominio

Ogni software rientra in qualche categoria di dominio. Le persone esperte nel dominio possono essere di grande aiuto per analizzare i requisiti generali e specifici.

Brainstorming

Un dibattito informale è tenuto tra le varie parti interessate e tutti i loro input sono registrati per un’ulteriore analisi dei requisiti.

Prototipazione

La prototipazione è la costruzione di un’interfaccia utente senza aggiungere funzionalità di dettaglio per l’utente per interpretare le caratteristiche del prodotto software previsto. Aiuta a dare un’idea migliore dei requisiti. Se non c’è un software installato presso il cliente per il riferimento dello sviluppatore e il cliente non è consapevole dei propri requisiti, lo sviluppatore crea un prototipo basato sui requisiti inizialmente menzionati. Il prototipo viene mostrato al cliente e il feedback viene annotato. Il feedback del cliente serve come input per la raccolta dei requisiti.

Osservazione

Un team di esperti visita l’organizzazione o il posto di lavoro del cliente. Osservano il funzionamento effettivo dei sistemi installati esistenti. Osservano il flusso di lavoro presso il cliente e come vengono affrontati i problemi di esecuzione. The team itself draws some conclusions which aid to form requirements expected from the software.

Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software development project. Hence they must be clear, correct and well-defined.

A complete Software Requirement Specifications must be:

Clear
Correct
Consistent
Coherent
Comprehensible
Modifiable
Verifiable
Prioritized
Unambiguous
Traceable
Credible source

Software Requirements

We should try to understand what sort of requirements may arise in the requirement elicitation phase and what kinds of requirements are expected from the software system.

In generale i requisiti del software dovrebbero essere categorizzati in due categorie:

Requisiti funzionali

I requisiti che sono relativi all’aspetto funzionale del software rientrano in questa categoria.

Definiscono funzioni e funzionalità all’interno e dal sistema software.

Esempi –

Opzione di ricerca data all’utente per cercare tra varie fatture.
L’utente dovrebbe essere in grado di spedire qualsiasi rapporto al management.
Gli utenti possono essere divisi in gruppi e ai gruppi possono essere dati diritti separati.
Dovrebbe essere conforme alle regole di business e alle funzioni amministrative.
Il software è sviluppato mantenendo intatta la compatibilità verso il basso.

Requisiti non funzionali

I requisiti, che non sono collegati all’aspetto funzionale del software, rientrano in questa categoria. Sono caratteristiche implicite o attese del software, che gli utenti assumono.

I requisiti non funzionali includono –

Security
Logging
Storage
Configuration
Performance
Cost
Interoperability
Flexibility
Disaster recovery
Accessibility

Requirements are categorized logically as

Must Have : Software cannot be said operational without them.
Should have : Enhancing the functionality of software.
Could have : Software can still properly function with these requirements.
Wish list : These requirements do not map to any objectives of software.

While developing software, ‘Must have’ must be implemented, ‘Should have’ is a matter of debate with stakeholders and negation, whereas ‘could have’ and ‘wish list’ can be kept for software updates.

User Interface requirements

UI is an important part of any software or hardware or hybrid system. A software is widely accepted if it is –

easy to operate
quick in response
effectively handling operational errors
providing simple yet consistent user interface

User acceptance majorly depends upon how user can use the software. UI is the only way for users to perceive the system. A well performing software system must also be equipped with attractive, clear, consistent and responsive user interface. Otherwise the functionalities of software system can not be used in convenient way. A system is said be good if it provides means to use it efficiently. User interface requirements are briefly mentioned below –

Content presentation
Easy Navigation
Simple interface
Responsive
Consistent UI elements
Feedback mechanism
Default settings
Purposeful layout
Strategical use of color and texture.
Fornire informazioni di aiuto
Approccio centrato sull’utente
Impostazioni di visualizzazione basate sul gruppo.

Software System Analyst

L’analista di sistema in un’organizzazione IT è una persona che analizza i requisiti del sistema proposto e assicura che i requisiti siano concepiti e documentati correttamente &. Il ruolo di un analista inizia durante la fase di analisi del software di SDLC. È responsabilità dell’analista assicurarsi che il software sviluppato soddisfi i requisiti del cliente.

Gli analisti di sistema hanno le seguenti responsabilità:

Analizzare e comprendere i requisiti del software previsto
Comprendere come il progetto contribuirà agli obiettivi dell’organizzazione
Identificare le fonti dei requisiti
Validazione dei requisiti
Sviluppare e implementare il piano di gestione dei requisiti
Documentazione dei requisiti di business, tecnici, di processo e di prodotto
Coordinamento con i clienti per dare priorità ai requisiti e rimuovere le ambiguità
Finire i criteri di accettazione con il cliente e le altre parti interessate

Metriche e misure del software

Le misure del software possono essere intese come un processo di quantificazione e simbolizzazione di vari attributi e aspetti del software.

Le metriche del software forniscono misure per vari aspetti del processo del software e del prodotto software.

Le misure del software sono requisiti fondamentali dell’ingegneria del software. Non solo aiutano a controllare il processo di sviluppo del software ma anche a mantenere la qualità del prodotto finale eccellente.

Secondo Tom DeMarco, un (Software Engineer), “Non puoi controllare ciò che non puoi misurare”. Con il suo detto, è molto chiaro quanto siano importanti le misure del software.

Vediamo alcune metriche del software:

Metriche della dimensione – LOC (Linee di codice), per lo più calcolate in migliaia di linee di codice sorgente consegnate, indicate come KLOC.

Il conteggio dei punti funzione è la misura della funzionalità fornita dal software. Il conteggio dei punti funzione definisce la dimensione dell’aspetto funzionale del software.
Metriche di complessità – La complessità ciclomatica di McCabe quantifica il limite superiore del numero di percorsi indipendenti in un programma, che è percepito come complessità del programma o dei suoi moduli. È rappresentata in termini di concetti di teoria dei grafi usando il grafico del flusso di controllo.
Metriche di qualità – I difetti, i loro tipi e cause, le conseguenze, l’intensità della gravità e le loro implicazioni definiscono la qualità del prodotto.

The number of defects found in development process and number of defects reported by the client after the product is installed or delivered at client-end, define quality of product.
Process Metrics – In various phases of SDLC, the methods and tools used, the company standards and the performance of development are software process metrics.
Resource Metrics – Effort, time and various resources used, represents metrics for resource measurement.