This lecture focusses on requirements elicitation.
It covers:
- Requirements discovery
- Requirements classification
- Requirements Prioritization
- Requirements Specifications
The output of this course consists in a list of artifacts and principles to be used when engineering Web applications is listed at https://trello.com/b/z49P8z3b
1ST DISIM WORKSHOP ON ENGINEERING CYBER-PHYSICAL SYSTEMS
Web Engineering L2: Requirements Elicitation for the Web (2/8)
1. Progettazione di Applicazioni Web
corso del Master in Web Technology
a.a. 2017-2018
https://app.schoology.com/course/1511186315/
Henry Muccini
Università degli Studi dell’Aquila
2. Collezione e descrizione dei requisiti del sistema web
2. MWT– Progettazione di Applicazioni Web Henry Muccini
2
Note
Orario di inizio: 9:30 MAT, 14:00 POM
Gruppo Skype
• #Principi
• #Difficolta’
SVN
Skip the Slides
3. MWT– Progettazione di Applicazioni Web Henry Muccini
3
NOTE:
Problema identificato: gestione dei tempi!
1. Il cliente cambia i requisiti!!
• Imp: meeting con «tutti» i clienti
• Imp: vincolare il cliente a quanto e’ stato scritto ed approvato
2. I tempi tecnici di sviluppo non corrispondono con i tempi
stimati
Principio: definire il «criterio» usato per guidare la design
decision
Principio: sviluppo incrementale, con identificazione dei
task prioritari
Principio: Dipendenze tra task
4. MWT– Progettazione di Applicazioni Web Henry Muccini
4
Copyright Notice
Il materiale riportato in queste slide puo’ essere
riutilizzato, parziale o totalmente, a patto che le fonti
e gli autori vengano citati
Henry Muccini
7. MWT– Progettazione di Applicazioni Web Henry Muccini
7
Salta le slides: Quiz!
Cosa sono i Requisiti funzionali del sistema?
Cosa sono i system boundaries?
Fatemi un esempio di vincoli di sistema (NFR)!
Valore contrattuale dei requisiti?
8. MWT– Progettazione di Applicazioni Web Henry Muccini
8
Requirements engineering
The process of establishing the services that
a customer requires from a system and the
constraints under which it operates and is
developed.
The system requirements are the descriptions of the
system services and constraints that are generated
during the requirements engineering process.
9. MWT– Progettazione di Applicazioni Web Henry Muccini
9
What is a requirement?
high-level abstract statement of a service or of
a system constraint
detailed mathematical functional specification.
define the system boundaries
Requirements may serve a dual function
– May be the basis for a bid for a contract - therefore must
be open to interpretation;
– May be the basis for the contract itself - therefore must be
defined in detail;
What is inside, what is outside the system?
10. MWT– Progettazione di Applicazioni Web Henry Muccini
10
Functional and non-functional
requirements
Functional requirements
– Statements of services the system should provide, how the system
should react to particular inputs and how the system should
behave in particular situations.
– May state what the system should not do.
Non-functional requirements
– Constraints on the services or functions offered by the system such as
timing constraints, constraints on the development process, standards,
etc.
– Often apply to the system as a whole rather than individual
features or services.
11. MWT– Progettazione di Applicazioni Web Henry Muccini
11
Functional requirements
Describe functionality or system services.
Depend on the type of software, expected users
and the type of system where the software is used.
Functional user requirements may be high-level
statements of what the system should do.
Functional system requirements should describe
the system services in detail.
13. MWT– Progettazione di Applicazioni Web Henry Muccini
13
Requirements Elicitation [estrazione]
Involves technical staff working with
customers to find out about the
application domain, the services that the
system should provide and the system’s
operational constraints.
14. MWT– Progettazione di Applicazioni Web Henry Muccini
14
The requirements elicitation and
analysis process
15. MWT– Progettazione di Applicazioni Web Henry Muccini
15
The requirements elicitation and
analysis process
16. MWT– Progettazione di Applicazioni Web Henry Muccini
16
Techniques to DISCOVER
Requirements
Bridging the gap between end user and developer:
– Questionnaires & Interviews
– Ethnography
– User Stories & Scenarios
– Use cases
– State-of-the art analysis
discussion
17. MWT– Progettazione di Applicazioni Web Henry Muccini
17
Techniques to DISCOVER
Requirements
Bridging the gap between end user and developer:
– Questionnaires & Interviews: Asking the end user a list of
pre-selected questions
– Ethnography: Observing end users in their operational
environment
– User Stories & Scenarios: Describe the use of the system
as a series of interactions between a concrete end user and
the system
– Use cases: Abstractions that describe a class of scenarios.
– State-of-the art analysis: Competitors analysis
discussion
18. MWT– Progettazione di Applicazioni Web Henry Muccini
18
Scenarios
– Scenarios and user stories are real-life examples of
how a system can be used
– A synthetic description of an event or series of
actions and events.
– A scenario can include text, video, pictures and story
boards. It usually also contains details about the work
place, social situations and resource constraints.
19. MWT– Progettazione di Applicazioni Web Henry Muccini
19
Scenarios: should include
– A description of the starting situation;
– A description of the normal flow of events;
– A description of what can go wrong;
– Information about other concurrent activities;
– A description of the state when the scenario finishes.
20. MWT– Progettazione di Applicazioni Web Henry Muccini
20
After the scenarios are formulated
Find all the use cases in the scenario that specify all
instances of how to report a fire
– Example: “Report Emergency“ in the first paragraph of the
scenario is a candidate for a use case
Describe each of these use cases in more detail
– Participating actors
– Describe the entry condition
– Describe the flow of events
– Describe the exit condition
– Describe exceptions
– Describe nonfunctional requirements
Functional Modeling (see next lecture)
21. MWT– Progettazione di Applicazioni Web Henry Muccini
21Questionario – Esempi concreti
elaborato corso di Software Architecture
22. MWT– Progettazione di Applicazioni Web Henry Muccini
22Scenario - Esempi concreti
Servizio Prenotazione Segreteria
Scenario 1
Andrea prenota un appuntamento per il giorno 25/11/2016 alle ore
11:00 della durata di 20 minuti per il servizio X.
Il giorno stabilito alle 11:20 Maria (l’operatore) si rende conto che è
necessario che Andrea torni nuovamente per fornire ulteriori
documenti, allora Maria concorda con Andrea una nuova data e gli
riserva un nuovo appuntamento.
Andrea riceve immediatamente la notifica della nuova prenotazione.
Scenario 2
Andrea, Giulio e Giorgio richiedono un appuntamento per il servizio Y,
Maria (l’operatore) sa che per il servizio Y è necessario compilare di
persona n documenti e crede di poter servire tutti e tre nello stesso
momento
quindi riserva loro 3 appuntamenti per lo stesso orario.
23. MWT– Progettazione di Applicazioni Web Henry Muccini
23Lista di Servizi – Esempio concreto
Servizio Prenotazione Segreteria
https://docs.google.com/document/d/1bo55UmqvITv
NiPDPS6uPTi4rXeJ2VCUIeCySR-
pljQk/edit?usp=sharing
24. MWT– Progettazione di Applicazioni Web Henry Muccini
24Lista di Servizi - Esempio
elaborato corso di Software Architecture
25. MWT– Progettazione di Applicazioni Web Henry Muccini
25
User Story - Esempio
As a < type of user >, I want < some goal > so that <
some reason >.
As a user, I can backup my entire hard drive.
Because an epic is generally too large for an agile team to complete in one iteration, it is split
into multiple smaller user stories before it is worked on. The epic above could be split into
dozens (or possibly hundreds), including these two:
As a power user, I can specify files or folders to backup based on file size, date created and
date modified.
As a user, I can indicate folders not to backup so that my backup drive isn't filled up with
things I don't need saved.
https://www.mountaingoatsoftware.com/agile/user-stories
30. MWT– Progettazione di Applicazioni Web Henry Muccini
30
The requirements elicitation and
analysis process
31. MWT– Progettazione di Applicazioni Web Henry Muccini
31
Prioritizing requirements
High priority
– Addressed during analysis, design, and implementation
– A high-priority feature must be demonstrated
Medium priority
– Addressed during analysis and design
– Usually demonstrated in the second iteration
Low priority
– Addressed only during analysis
– Illustrates how the system is going to be used in the future
with not yet available technology
32. MWT– Progettazione di Applicazioni Web Henry Muccini
32
The requirements elicitation and
analysis process
33. MWT– Progettazione di Applicazioni Web Henry Muccini
33
Ways of writing a system
requirements specification
Notation Description
Natural language The requirements are written using numbered sentences in natural language. Each
sentence should express one requirement.
Structured natural
language
The requirements are written in natural language on a standard form or template.
Each field provides information about an aspect of the requirement.
Design description
languages
This approach uses a language like a programming language, but with more
abstract features to specify the requirements by defining an operational model of
the system. This approach is now rarely used although it can be useful for interface
specifications.
Graphical notations Graphical models, supplemented by text annotations, are used to define the
functional requirements for the system; UML use case and sequence diagrams are
commonly used.
Mathematical
specifications
These notations are based on mathematical concepts such as finite-state machines
or sets. Although these unambiguous specifications can reduce the ambiguity in a
requirements document, most customers don’t understand a formal specification.
They cannot check that it represents what they want and are reluctant to accept it
as a system contract
35. MWT– Progettazione di Applicazioni Web Henry Muccini
35
Sommario
Use Case Diagram
– Attore
– Use Case
– Attore e Use Case
– Relazione tra attori (generalizzazione)
– Relazioni tra use case
36. MWT– Progettazione di Applicazioni Web Henry Muccini
36
Nota
Gli Use Case Diagrams sono solo uno dei tanti modi
possibili per documentare i requisiti
– L’importante non e’ il linguaggio che si usa
Gli UC Diagrams aiutano (ed “obbligano”) l’utente a
seguire certi ragionamenti e a documentarli
37. MWT– Progettazione di Applicazioni Web Henry Muccini
37
Use Case Diagram
Specifica le funzionalita’ del sistema
Use Case
Specifica gli attori umani o automatici che utilizzano il
sistema (e le sue funzionalita’)
Attori
Evidenzia come le funzionalità del sistema vengono
messe a disposizione degli utilizzatori del sistema
Use Case Diagram = Use Case, attori, e relazioni tra loro
Catturano il comportamento di un sistema che si sta
sviluppando, senza specificare come il sistema lo
implementerà
Costituiscono il contratto tra il committente e
l’implementatore del sistema
38. MWT– Progettazione di Applicazioni Web Henry Muccini
38
Vantaggi
Strumento facilmente comprensibile dagli utenti e
quindi utilizzati per comunicare ed ottenere la
validazione dei requisiti
Permettono di definire chiaramente i confini del
sistema ed evidenziarne i vari attori (umani e non)
Esprimono il comportamento del sistema,
evidenziando eventuali incoerenze e lacune nella fase
di analisi dei requisiti
Forniscono un’ottima documentazione
40. MWT– Progettazione di Applicazioni Web Henry Muccini
40
Processo indotto da use case
diagrams
Estrarre requisiti funzionali (use cases)
Identificare gli stakeholder (attori) che utilizzeranno tali
funzioni
Definire relazioni tra requisiti funzionali (specializzazione)
Definire relazioni tra use cases (specializzazione, include,
extend, …)
Documentare, in forma tabellare, i requisiti funzionali del
sistema
Tale diagramma viene poi usato per guidare la fase di
design
41. MWT– Progettazione di Applicazioni Web Henry Muccini
41
Sistema
Prima di iniziare a modellare le funzionalità del
sistema è necessario determinare i confini del
sistema stesso
E’ necessario stabile i confini in modo tale che non si
rischia di modellare entità che non fanno parte del
sistema
Graficamente è rappresentato come un rettangolo
che contiene tutti gli use case del sistema
E’ opzionale e viene fatto raramente
H1
43. MWT– Progettazione di Applicazioni Web Henry Muccini
42
Sistema Questo box non rappresenta
per forza un package.
Puo’ rappresentare un
qualsiasi modo di collezionare
Use Cases
44. MWT– Progettazione di Applicazioni Web Henry Muccini
43
Attore
Insieme coerente di ruoli che un utente di un caso
d’uso (funzionalità) recita quando interagisce con
esso
Non necessariamente persona fisica, può essere
anche un altro sistema
E’ un’entità esterna al sistema oggetto di
modellazione
Rappresentato mediante un omino stilizzato (stick
man)
45. MWT– Progettazione di Applicazioni Web Henry Muccini
44
Attore UML2.x:
Icone specifiche possono
essere introdotte per
non-human actors
Amministratore
Cliente
Studente
Universitario
Billing
System
Legacy
System
46. MWT– Progettazione di Applicazioni Web Henry Muccini
45
Attore
Attori comunicano con il sistema inviando o
ricevendo messaggi
Due tipi
– Primari: utilizzano le funzioni proprie del sistema; sono
detti attivi
– Secondari: fruiscono di informazioni o notifiche generate
da use case; sono detti passivi
Attore può essere attivo in uno use case e passivo in
un altro
47. MWT– Progettazione di Applicazioni Web Henry Muccini
46
Use Case
Descrizione di un insieme di sequenze di azioni che un
sistema esegue per ottenere un risultato osservabile di
valore per un attore
Sequenza di azioni che l’entità esegue interagendo con
il relativo attore che sono necessarie per erogare un
certo servizio
Rappresentano quindi i requisiti funzionali del sistema
48. MWT– Progettazione di Applicazioni Web Henry Muccini
47
Use Case
Graficamente è rappresentato mediante una ellisse
Ha un nome che identifica la funzionalità
– Può essere semplice o con path (se appartiene ad un
package)
– Generalmente i nomi sono frasi brevi prese dal vocabolario
del sistema che si sta modellando
Ha una breve descrizione che descrive il ruolo e lo
scopo dello use case
49. MWT– Progettazione di Applicazioni Web Henry Muccini
48
Use Case
Validate user
Place Order
Sensors::Calibrate
location
50. MWT– Progettazione di Applicazioni Web Henry Muccini
49
Use Case
Descrive cosa un sistema fa (le sue funzionalità) ma
non come, cioè la sequenza di azioni eseguita dal
sistema per realizzare una determinata funzionalità
E’ necessario descrivere un flusso di eventi che
modella il comportamento dello use case
Flusso di eventi può essere descritto
– Formato testuale: generalmente rappresentato tramite pseudo-codice
(cioè testo strutturato)
– Formalmente: mediante activity oppure tramite sequence
(generalmente vengono utilizzati successivamente alla descrizione
testuale)
51. MWT– Progettazione di Applicazioni Web Henry Muccini
50
Use Case
Flusso di eventi è composto
– Flusso principale (basic flow o happy path)
Descrive quello che accade il più delle volte quando viene
eseguito lo use case
– Flussi alternativi
Generalmente descrivono i flussi eccezionali (cioè che
gestiscono situazioni di errori) oppure flussi che si
verificano raramente.
Sono utilizzati anche per organizzare use case complessi
52. MWT– Progettazione di Applicazioni Web Henry Muccini
51
Use Case
Pre-condizioni
– Definiscono lo stato in cui si deve trovare il sistema prima
che inizi lo use case
– Possono essere descritte in forma testuale oppure formale
(es. O.C.L.)
Post-condizioni
– Definiscono una lista di possibili stati in cui si deve trovare
il sistema dopo che è terminato lo use case
– Possono essere descritte in forma testuale oppure formale
(es. O.C.L.)
53. MWT– Progettazione di Applicazioni Web Henry Muccini
52
Esempio
Registrazione CorsiStudente Catalogo Corsi
UML2.0:
Notazione alternativa
per Use Cases
54. MWT– Progettazione di Applicazioni Web Henry Muccini
53
Bacheca Virtuale: funzionalita’ analizzate dai
gruppi
– Il sistema deve permettere di:
• Anagrafica messaggi:
– Inserire, modiicare, cancellare e leggere messaggi
– Anonimato
• Identificare categorie di messaggi
• Autenticazione, Registrazione, modifica, controllo diritti di accesso
• Scadenza messaggi
• Ricerca (con certi criteri) di messaggi
• Moderazione sui messaggi
• Newsletter sulla categoria di interesse
• Profilo utente
• Contatto: email, sms, chat
• Amministrazione del sito
55. MWT– Progettazione di Applicazioni Web Henry Muccini
54
Considerazioni
Solo funzionalita’, non altro!
Cos’e’ una funzionalita’?
Non tutte le funzionalita’ sono allo stesso livello di
astrazione
Una funzionalita’ puo’ contenere altre sotto-
funzionalita’
Alcune funzionalita’ possono essere simili
Alcune funzionalita’ possono richiedere altre
funzionalita’ come pre-condizione
Non tutte le funzionalita’ hanno la stessa
importanza
Diversi attori richiedono diverse funzionalita’
Accorpare funzionalita’
56. MWT– Progettazione di Applicazioni Web Henry Muccini
55
Attore e Use Case
Attori sono entità esterne al sistema che interagiscono
con esso
Le interazioni consistono in uno scambio di messaggi
Attore è connesso con gli use case mediante una
relazione di associazione che permette di attivare
(attore attivo) lo use case o di ricevere (attore passivo) i
risultati
57. MWT– Progettazione di Applicazioni Web Henry Muccini
56
Attore e Use Case
Relazione di associazione è l’unica relazione possibile
tra attore e use case
Può avere la proprietà di navigazione (cioè può
esserci una freccia) la quale indica, per convenzione,
la direzione dell’inizio della comunicazione tra lo use
case e l’attore
Per una comunicazione che coinvolge una risposta
non è necessario inserire la freccia nella parte che ha
attivato la funzionalità
Se la comunicazione iniziale avviene da entrambe le
direzioni le frecce vengono omesse
58. MWT– Progettazione di Applicazioni Web Henry Muccini
57
Attore e Use Case
Cliente
Effettua Ordine
Verifica Ordine
Ve nditore
59. MWT– Progettazione di Applicazioni Web Henry Muccini
58
Generalizzazione tra attori
Può succedere che attori presentino diverse e
significative similitudini
E’ possibile raccogliere a fattor comune tale
similitudini creando un attore padre ed esprimere gli
altri attori in termini di estensione del primo
Rappresentato come la relazione di generalizzazione
tra classi
60. MWT– Progettazione di Applicazioni Web Henry Muccini
59
Generalizzazione tra attori
Ve nditore
Supervisore
Studente
Studente full-time Studente part-time
61. MWT– Progettazione di Applicazioni Web Henry Muccini
60
Generalizzazione tra attori
Venditore
Inserimento Ordine
Verifica Stato Ordine
Annullamento Ordine
Supervisore Generazione Report
62. MWT– Progettazione di Applicazioni Web Henry Muccini
61
Generalizzazione tra attori
Venditore
Inserimento Ordine
Verifica Stato Ordine
Annullame nto Ordine
Supervisore Ge nerazione Re port
63. MWT– Progettazione di Applicazioni Web Henry Muccini
62
Relazioni tra Use Case
Generalizzazione
Inclusione
Estensione
Realizzazione
– Collaboration
64. MWT– Progettazione di Applicazioni Web Henry Muccini
63
Generalizzazione
Può capitare che diversi use case presentino
somiglianze e condividano comportamento
E’ possibile utilizzare la generalizzazione per creare
uno use case genitore (che contiene le somiglianze)
ed estenderlo (modificando il comportamento o
aggiungendo dei passi allo use case) mediante casi
d’uso figli
Rappresentata come la generalizzazione tra classi
L’esecuzione degli use case “fratelli” è esclusiva
65. MWT– Progettazione di Applicazioni Web Henry Muccini
64
Generalizzazione
Cliente Validazione Utente
Check Password Scansione Retina
66. MWT– Progettazione di Applicazioni Web Henry Muccini
65
Inclusione
Relazione tra due use case, dove uno use case include
il comportamento dell’altro
E’ simile al concetto di chiamata di funzione (metodo)
Rappresentata con una linea tratteggiata
(dipendenza) e con lo stereotipo <<include>>
Nella versione 1.3 di UML era rappresentata come
uno stereotipo (<<uses>>) della relazione di
generalizzazione. Poteva generare confusione
67. MWT– Progettazione di Applicazioni Web Henry Muccini
66
Inclusione
Reperimento Dati Cliente
Repe rimento Articoli
Cliente Compila Ordine
<<include>> <<include>>
La funzionalita’ di “compilare ordine” <<include>> anche delle sottofunzionalita’
quali “reperimento dati cliente” e “reperimento articoli”.
A volte <<include>> si puo’ considerare anche come una pre-condizione
68. MWT– Progettazione di Applicazioni Web Henry Muccini
67
Estensione
Vengono utilizzate per modellare condizioni facoltative rispetto
al flusso principale
Relazione tra uno use case estendente e uno base che specifica come
il comportamento definito dal primo (l’estendente) debba essere
inserito nel comportamento di quello base
Nello use case base ci saranno dei punti che verranno estesi (punti
di estensione) dagli use case estendenti
Tali punti prevedono delle condizioni di guardia (cioè condizioni che
si devono verificare per eseguire la parte estesa)
71. MWT– Progettazione di Applicazioni Web Henry Muccini
70
Inclusione vs. Estensione
Se la sequenza di azioni di uno use case deve
avvenire solo al verificarsi di determinate condizioni
allora utilizzare estensione
Se use case (o parte di) può essere riutilizzato da altri
use case allora conviene utilizzare inclusione
72. MWT– Progettazione di Applicazioni Web Henry Muccini
71
Come Realizzare gli Use Case Diagram:
Use Case Centric
Actor Centric
73. MWT– Progettazione di Applicazioni Web Henry Muccini
72
Use Case Centric vs Actor Centric
Use Case centric:
– Per ciascuno Use Case, si identificano tutti gli attori
• Puo’ diventare complesso
Actor centric
– Per ciascun attore, si identificano tutti i suoi use case
• Se ho “n” use case, esistono “n” use case diagram
• Ripetizione di Use Case
75. MWT– Progettazione di Applicazioni Web Henry Muccini
74
Actor centric
Ospite
1.1 Visualizza
Offerta Formativa
1.2 Visualizza
Modulistica
1.3 Visualizza
Area Didattica
1.4 Visualizza
News e Avvisi
1.5 Informazioni
Generali
«uses»
«uses»
«uses»
«uses»
«uses»
Use Case 1 – Funzionalità Ospite
76. MWT– Progettazione di Applicazioni Web Henry Muccini
75
Template per Use Case, basic
1.3 •Visualizza Area Didattica
Descrizion
e
Visualizza il calendario delle lezioni, l’elenco dei docenti che
impartiranno le lezioni in un dato anno accademico, l’elenco dei corsi
proposti in uno specifico anno accademico, nonché l’elenco delle
aziende che sponsorizzano il master e i seminari da loro tenuti.
Importanza Media.
Evento
scatenante
Click dell’ospite nel menù della parte pubblica.
Uses Include la visualizzazione di altre parti.
77. MWT– Progettazione di Applicazioni Web Henry Muccini
76
Use Case Template, advanced
Use Case ID:
Use Case Name:
Created By:
Date Created
Actors:
Description:
Trigger:
Preconditions:
Postconditions:
Normal Flow:
Alternative Flows:
Exceptions:
Includes:
Priority:
Frequency of Use:
Business Rules:
Special
Requirements:
Assumptions:
Notes and Issues:
78. MWT– Progettazione di Applicazioni Web Henry Muccini
77
Alistair Cockburn Use Case Template
79. MWT– Progettazione di Applicazioni Web Henry Muccini
78
Use Case table in Magic Draw
80. MWT– Progettazione di Applicazioni Web Henry Muccini
79
Lessons Learned
You shall create a hierarchy of use case diagrams
Do not try to put the all information on a unique diagram
High-level with all functionalities, then detailed use case diagrams
Only functional requirements
Do not try to transform non functional requirements of data into use
cases
Use Case diagram is complex
It seems so simple, but it is the most complicated diagram
Use Case indexing:
Associate an ID to use cases
Usage of the <<Include>> <<extends>>
stereotypes
Importance of the “generalization” concept among
actors