Web Engineering L2: Requirements Elicitation for the Web (2/8)

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

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
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
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

5

Raccolta ed Analisi di
Informazioni

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
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
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
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
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
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
The requirements elicitation and
analysis process

15
analysis process

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
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
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
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
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)

21Questionario – Esempi concreti
elaborato corso di Software Architecture

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.

23Lista di Servizi – Esempio concreto
Servizio Prenotazione Segreteria
https://docs.google.com/document/d/1bo55UmqvITv
NiPDPS6uPTi4rXeJ2VCUIeCySR-
pljQk/edit?usp=sharing

24Lista di Servizi - Esempio
elaborato corso di Software Architecture

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

26

27
analysis process

28
Classificazione dei requisiti
 Funzionali
 Non funzionali

29

30
analysis process

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
analysis process

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
Sommario
Use Case Diagram
– Attore
– Use Case
– Attore e Use Case
– Relazione tra attori (generalizzazione)
– Relazioni tra use case

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
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
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

39

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
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

H1 esempio di "confini" nell'esempio Trip4You
Henry; 06/01/2014

42
Sistema Questo box non rappresenta
per forza un package.
Puo’ rappresentare un
qualsiasi modo di collezionare
Use Cases

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)

44
Attore UML2.x:
Icone specifiche possono
essere introdotte per
non-human actors
Amministratore
Cliente
Studente
Universitario
Billing
System
Legacy
System

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

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

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

48
Use Case
Validate user
Place Order
Sensors::Calibrate
location

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)

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

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.)

52
Esempio
Registrazione CorsiStudente Catalogo Corsi
UML2.0:
Notazione alternativa
per Use Cases

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

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’

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

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

57
Attore e Use Case
Cliente
Effettua Ordine
Verifica Ordine
Ve nditore

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

59
Ve nditore
Supervisore
Studente
Studente full-time Studente part-time

60
Venditore
Inserimento Ordine
Verifica Stato Ordine
Annullamento Ordine
Supervisore Generazione Report

61
Venditore
Inserimento Ordine
Verifica Stato Ordine
Annullame nto Ordine
Supervisore Ge nerazione Re port

62
Relazioni tra Use Case
Generalizzazione
Inclusione
Estensione
Realizzazione
– Collaboration

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

64
Generalizzazione
Cliente Validazione Utente
Check Password Scansione Retina

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

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

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)

68
Esempio

69
Estensione
Seleziona Esame
Verifica Idoneità studente
Studente
Prenota Appello
<<extend>>
<<extend>>
Validazione utente
<<include>> Extensions points:
Transazione abilitata
Verifica idoneità
(Transazione abilitata)
[Studente abilitato]
(Verifica idoneità)
[Appello selezionato]

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

71
Come Realizzare gli Use Case Diagram:
Use Case Centric
Actor Centric

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

73
Use Case
centric

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

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.

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:

77
Alistair Cockburn Use Case Template

78
Use Case table in Magic Draw

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

Web Engineering L2: Requirements Elicitation for the Web (2/8)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Web Engineering L2: Requirements Elicitation for the Web (2/8)

Ähnlich wie Web Engineering L2: Requirements Elicitation for the Web (2/8) (20)

Mehr von Henry Muccini

Mehr von Henry Muccini (20)

Web Engineering L2: Requirements Elicitation for the Web (2/8)