2. HowCanYouImproveYourAs-isModels?
RequirementsAnalysis Methods
Meet GQM
2
Topic: Detecting problems in As-is
and deriving To-be by solving them
We use an integrated model on:
Goal-oriented analysis +
Problem frame approach +
Use case modeling
Finding problems in
integrated models
using metrics
derived via GQM
Abstract
3. Background
l Information systems (ISs) should enhance their
business value
l To develop ISs providing high business value:
– Clarify the current situation (As-is) of business process
– Identify the problems hidden in the current situations
– Develop a new version of ISs (To-be)
We need techniques to support the identification of
the problems, which can be seamlessly connected to
the modeling techniques.
3
4. ModelingTechniques
Goal-Oriented Requirements Analysis
l Often used in As-is analysis
– Refines/decomposes abstract
goals to concrete
– Defines alternatives as
OR-decomposed goals
l Pros
– Clarifies the rationale of
requirements (bottom-to-up)
l Cons
– Hard to express
systems’ behavior
4
Refines/decomposes goals
Clarifies the rationales of requirements
Efficient road network
Traffics managed
using lights
GORA: Goal model
5. Our Solution:
GORA: Goal model
Refines/decomposes goals
Clarifies the rationales of requirements
Efficient road network
Traffics managed
using lights
Problem Frame: Context diag.
For understanding systems’ behavior
Clarifies the boundary between
machines and environments
Lights
Controller
(LC)
Light
Units
(LU)
Light
Cycle
5
Integrated Model
Use case modeling: Use case description
Provides sequence of steps of each functionality
which can be a glue to connect two modeling techniques
Identify problems in an integrated model w/ metrics via GQM
7. Home delivery
pizza
Receive orders
Can order with an
equipment anyone has
Easy to order
for customers
Receive orders
by telephone
Deliver pizzas
Get payment
Stock control
Example Goal Model:
Home Delivery Pizza
7
AND
8. Step 1: Construct As-is
l As an integrated model
– A goal model (GM)
– Use case descriptions (UCDs)
– A context diagram (CD)
8
GM UCDs CD
Construct
a model
Construct
a model
Refine
goals
Identify
problems
found
Not
found
As-is
To-be
9. Integration Rule
9
Use case:
Receive orders
by telephone
Precondition:
Telephone ringing
Basic flow:
1. Pick up telephone
2. (Get) Name, telephone
number, address
3. (Get) Order
4. Ring off telephone
5.Write an invoice
Receive orders
by telephone
l Each leaf goal in GM ó a UC ó a UCD
l Each step in UCD ó an event in CD
Staff (S)
Customer (C)
C! Ring off
telephone
<<human>>
<<human>>
10. Integrated Model (As-is)
10
Staff (S)
Customer (C)
Invoice (I)
S! Write an invoice
C! Telephone ringing
C! Order
C! Ring off telephone
C! Name, telephone number, address
Use case: Receive orders by telephone
Precondition:Telephone ringing
Basic flow:
1. Pick up telephone
2. (Get) Name, telephone number, address
3. (Get) Order
4. Ring off telephone
5.Write an invoice
Scenario of Receptionist
(Use case description)
<<human>>
<<human>>
Context diagramome delivery
pizza
Receive orders
Receive orders
by telephone
Deliver pizzas
Get payment
Goal model
11. Step 2: Identify Problems
l In the integrated model, find problems:
l E.g.,
– High human workload
– Complex work
l Identify the source goal(s)
11
Construct
a model
Construct
a model
Refine
goals
Identify
problems
found
Not
found
As-is
To-be
12. Step 2. Identify Problems
12
Staff (S)
Customer (C)
Invoice (I)
S! Write an invoice
C! Telephone ringing
C! Order
C! Ring off telephone
C! Name, telephone number, address
Use case: Receive orders by telephone
Precondition:Telephone ringing
Basic flow:
1. Pick up telephone
2. (Get) Name, telephone number, address
3. (Get) Order
4. Ring off telephone
5.Write an invoice
Scenario of Receptionist
(Use case description)
<<human>>
<<human>>
Context diagramome delivery
pizza
Receive orders
Receive orders
by telephone
Deliver pizzas
Get payment
Goal model
Many shared events btw.
Staff and Customer
= High human workload
13. Step 3: Refine Goals
l For the problematic goals in As-is by
– Refining them
– Defining their alternatives
13
Construct
a model
Construct
a model
Refine
goals
Identify
problems
found
Not
found
As-is
To-be
As-is goal model To-be goal model
Refine
14. Store and
update customers’
information
Retrieve customers’
information
Reduce staffs’ efforts
in getting name, telephone number,
address from a customer
Record and utilize
customers’ information
ordered before
Receive orders
by fax
Home delivery
pizza
Receive orders
Can order with an
equipment anyone has
Easy to order
for customers
Receive orders
by telephone
Deliver pizzas
-
14
15. Step 4: ConstructTo-be
l Constructs an integrated model
– From new To-be goal model
l Iterative process
– Identifies problems again
– Stops if no problems found
15
Construct
a model
Construct
a model
Refine
goals
Identify
problems
found
Not
found
As-is
To-be
To-be goal model
16. Staff (S)
Customer (C)
Invoice (I)
S!Write an invoice
C!Telephone ringing
C! Order
C! Ring off telephone
C!Telephone number
Retrieve
Update
Store
Use case: Receive orders by
telephone
Precondition: Telephone ringing
Basic flow:
1. Pick up telephone
2. (Get) Telephone number
3. Retrieve
4. (Get) Order
5. Ring off telephone
6.Write an invoice
Customer Management
System (CM)
S! Retrieve
Reduce staffs’ efforts
in getting name, telephone number,
address from a customer
Record and utilize
customers’ information
ordered before
Store and
update customers’
information
Retrieve customers’
information
includes
<<human>>
<<human>>
To-be Integrated Model
16
17. Metric-Based Identification
17
Construct
a model
Construct
a model
Refine
goals
Identify
problems
found
Not
found
As-is
To-be
[1] Basili,V., Caldiera, C. and Rombach, D.: Goal, Question, Metric Paradigm,
Encyclopedia of Software Engineering,Vol.1, pp.528–532, 1994.
Use of GQM [1]
A framework to find useful metrics
by deriving
• Questions from Goals
• Metris from Questions
Approach: Quantifying it via metrics
Aim: (semi-)automated
identification of problems
18. Applying GQM
18
Identifying the locations to
automate/reduce human efforts
Goal
Which was frequently
performed by human?
Which was hard
for human?
Question
In which was
many kinds
of human work
performed?
In which was
human work
preformed at
many times?
Which work
was complex
for human?
Which work
was time
consuming for
human?
NE ANOSACCCE
Metric
19. CE (Count of Events)
# distinct events related to each human domain
19
Staff (S)
Customer (C)
Invoice (I)
S! Write an invoice
C! Telephone ringing
C! Order
C! Ring off telephone
C! Name, telephone number, address
Use case: Receive orders by telephone
Precondition:Telephone ringing
Basic flow:
1. Pick up telephone
2. (Get) Name, telephone number, address
3. (Get) Order
4. Ring off telephone
5.Write an invoice
Scenario of Receptionist
(Use case description)
<<human>>
<<human>>
Context diagram
CE(Staff) = 5
20. NE (Number of Events)
20
Staff (S)
Customer (C)
Invoice (I)
S! Write an invoice
C! Telephone ringing
C! Order
C! Ring off telephone
C! Name, telephone number, address
Use case: Receive orders by telephone
Precondition:Telephone ringing
Basic flow:
1. Pick up telephone
2. (Get) Name, telephone number, address
3. (Get) Order
4. Ring off telephone
5.Write an invoice
Scenario of Receptionist
(Use case description)
<<human>>
<<human>>
Context diagram
NE(Staff) = 5
# event occurrences on each human domain
21. ACC and ANOS
l ACC (Actor-related Cyclomatic Complexity)
– CC in UCD [5], limited to human-related steps
– # alternative flows + 1
l ANOS (Actor-related Number of Steps)
– # human-related steps in UCD
21
Use case 1: Receive orders by telephone
Precondition:Telephone ringing
Basic flow:
1. Pick up telephone
2. (Get) Name, telephone number, address
3. (Get) Order
4. Ring off telephone
5.Write an invoice
Scenario of Receptionist
(Use case description)
ACC(UC1) = 1
ANOS(UC1) = 5
23. Illustrative Example
Reporting operation of a brokerage office
26
Brokerage
analyst
Dedicated
terminal
History
server
Distribution
server
Personal
terminal
Upload report files
in PDF format
Download
past reports
Download/Upload
Write reports
Upload reports
24. Step 1: As-Is Model
UC1 Collect data
Basic flow
1. Call UC3
2. ......
3. ......
Post-condition: Brokerage information provided
Goal model
(12 goals)
Context diagram
(6 domains, 16 events)
Reporting operation
of a brokerage office
Create a report Manage reports
UC1: Collect data UC2: Write a report
UC7: Fix a report
in the distribution server
UC3: Fetch a report
UC5: Store a report
to the distribution server
UC4: Store a report
to the history server
UC6: Fix a report
in the history server
Fix a report Store a report
Use case descriptions
(7 use cases)
Info. Source
Analyst
Dedicated
Terminal
History Server
A! Survey (1.2)
A! Translate (4.1)
A! Upload (4.2)
T! SendPDF (4.3)
T! SendReport (5.1)
IS! ProvideInfo (1.3)
Personal
Terminal
Distribution
Server
A! OpenReport (2.1, 7.1, 6.1)
A! ModifyReport (7.2, 6.2)
A! RequestReport (3.1)
A! Upload (5.2)
PT! SendReport (5.3)
PT! RequestReport (3.2)
HS! SendReport (3.3)
PT! SendReport (3.4)
A! CreateReport (2.2)
A! SendReport (3.5)
<<human>>
27
25. Reporting operation
of a brokerage office
Create a report Manage reports
UC1: Collect data UC2:Write a report
UC7: Fix a report
in the distribution server
UC3: Fetch a report
UC5: Store a report
to the distribution server
UC4: Store a report
to the history server
UC6: Fix a report
in the history server
Fix a report Store a report
Goal Model (As-is)
28
29. Reporting operation
of a brokerage office
Create a report Manage reports
UC1: Collect data UC2:Write a report
UC7: Fix a report
in the distribution
server
UC3: Fetch a report
UC5: Store a report
to the distribution server
UC4: Store a report
to the history server
UC6: Fix a report
in the history server
Fix a report Store a report
Goal Model (As-is)
32
30. Step 3: Refine Goals
(Build Solution)
Goal Model (As-is)
Report management
system
Manage reports
(w/ USB)
Manage reports
alternative
Reporting operation
of a brokerage office
Create a report
Manage reports
UC1: Collect data UC2: Write a report
UC7: Fix a report
in the distribution server
UC3: Fetch a report
UC5: Store a report
to the distribution server
UC4: Store a report
to the history server
UC6: Fix a report
in the history server
Fix a report Store a report
Reporting operation
of a brokerage office
Create a report Report
management
systemUC1: Collect data UC2: Write a report
UC3': Fetch a reportUC6-7: Fix a report
UC4-5:
Store a report
33
Goal Model (To-be)
31. Reporting operation
of a brokerage office
Create a report
Report management
system
UC1: Collect data UC2:Write a report
UC7: Fix a report
in the distribution server
UC3': Fetch a report
UC5: Store a report
to the distribution server
UC4: Store a report
to the history server
UC6: Fix a report
in the history server
UC6-7: Fix a report
UC4-5:
Store a report
Goal Model (To-be)
34
32. Step 4: To-be Model
Goal model
(8 goals)
Context diagram
(6 domains, 15 events)
Use case descriptions
(5 use cases)
Info.
Source
Analyst
History Server
A! Survey (1.3)
MS! Translate (4-5.4)
A! Upload (4-5.1)
MS! SendPDF (4-5.5)
MS! SendReport (4-5.3)
IS! ProvideInfo (1.4)
Personal
Terminal
Distribution
Server
A! OpenReport (2.1, 6-7.1)
A! ModifyReport (6-7.2)
HS! SendReport (3'.4)
A! CreateReport (2.2)
Management
System
A! RequestReport (3'.1)
T! RequestReport (3'.2)
MS! RequestReport (3'.3)
MS! SendReport (3'.5)
T! SendReport (4-5.2)
<<human>>
Reporting operation
of a brokerage office
Create a report
Report
management
system
UC1: Collect data UC2: Write a report
UC3': Fetch a reportUC6-7: Fix a report
UC4-5:
Store a report
35
UC1 Collect data
Basic flow
1. Call UC3
2. ......
3. ......
Post-condition: Brokerage information provided
35. Summary of Application
l It could show that …
– Our technique could find problems in As-is model
– The effectiveness of model updates from As-is to To-be
38
Step 1: As-Is Model
UC1 Collect data
Basic flow
1. Call UC3
2. ......
3. ......
Post-condition: Brokerage information provided
Goal model
(12 goals)
Context diagram
(6 domains, 16 events)
Reporting operation
of a brokerage office
Create a report Manage reports
UC1: Collect data UC2: Write a report
UC7: Fix a report
in the distribution server
UC3: Fetch a report
UC5: Store a report
to the distribution server
UC4: Store a report
to the history server
UC6: Fix a report
in the history server
Fix a report Store a report
Use case descriptions
(7 use cases)
Info. Source
Analyst
Dedicated
Terminal
History Server
A! Survey (1.2)
A! Translate (4.1)
A! Upload (4.2)
T! SendPDF (4.3)
T! SendReport (5.1)
IS! ProvideInfo (1.3)
Personal
Terminal
Distribution
Server
A! OpenReport (2.1, 7.1, 6.1)
A! ModifyReport (7.2, 6.2)
A! RequestReport (3.1)
A! Upload (5.2)
PT! SendReport (5.3)
PT! RequestReport (3.2)
HS! SendReport (3.3)
PT! SendReport (3.4)
A! CreateReport (2.2)
A! SendReport (3.5)
<<human>>
24
Step 4: To-be Model
Goal model
(8 goals)
Context diagram
(6 domains, 15 events)
Use case descriptions
(5 use cases)
Info.
Source
Analyst
History Server
A! Survey (1.3)
MS! Translate (4-5.4)
A! Upload (4-5.1)
MS! SendPDF (4-5.5)
MS! SendReport (4-5.3)
IS! ProvideInfo (1.4)
Personal
Terminal
Distribution
Server
A! OpenReport (2.1, 6-7.1)
A! ModifyReport (6-7.2)
HS! SendReport (3'.4)
A! CreateReport (2.2)
Management
System
A! RequestReport (3'.1)
T! RequestReport (3'.2)
MS! RequestReport (3'.3)
MS! SendReport (3'.5)
T! SendReport (4-5.2)
<<human>>
Reporting operation
of a brokerage office
Create a report
Report
management
system
UC1: Collect data UC2: Write a report
UC3': Fetch a reportUC6-7: Fix a report
UC4-5:
Store a report
32
UC1 Collect data
Basic flow
1. Call UC3
2. ......
3. ......
Post-condition: Brokerage information provided
36. Future Work
l Case study++
l Deriving more metrics to extract more
problems
– Different focus: skills or health conditions of human
– Make guidelines how to construct GQM trees
– Make reusable catalogs of metrics
l Automated transformation from As-is to
To-be models
– Define evolution patterns as model transformations
39
37. Conclusion
Our Solution:
GORA: Goal model
Refines/decomposes goals
Clarifies the rationales of requirements
Efficient road network
Traffics managed
using lights
Problem Frame: Context diag.
For understanding systems’ behavior
Clarifies the boundary between
machines and environments
Lights
Controller
(LC)
Light
Units
(LU)
Light
Cycle
2 .
2 .
5
Integrated Model
Use case modeling: Use case description
Provides sequence of steps of each functionality
which can be a glue to connect two modeling techniques
Identify problems in an integrated model w/ metrics via GQM
Construct
a model
Construct
a model
Refine
goals
Identify
problems
found
Not
found
As-is
To-be
Our Approach
l 4 steps incl. iteration
1. Construct an As-is model
2. Identify its problems
3. Refine goals
4. Construct a To-be model
6
NE ANOSACC
Identifying the locations to
automate/reduce human efforts
Which was frequently
performed by human?
Which was hard
for human?
In which was
many kinds
of human work
performed?
In which was
human work
preformed at
many times?
Which work
was complex
for human?
Which work
was time
consuming for
human?
CE
Applying GQM
Goal
Question
Metric
18
Step 3: Refine Goals
(Build Solution)
. 2
Goal Model (As-is)
Report management
system
Manage reports
(w/ USB)
Manage reports
alternative
Reporting operation
of a brokerage office
Create a report
Manage reports
UC1: Collect data UC2: Write a report
UC7: Fix a report
in the distribution server
UC3: Fetch a report
UC5: Store a report
to the distribution server
UC4: Store a report
to the history server
UC6: Fix a report
in the history server
Fix a report Store a report
Reporting operation
of a brokerage office
Create a report Report
management
systemUC1: Collect data UC2: Write a report
UC3': Fetch a reportUC6-7: Fix a report
UC4-5:
Store a report
33
Goal Model (To-be)