how can you improve your as-is models? requirements analysis methods meet gqm
TRANSCRIPT
How Can You Improve Your As-is Models?Requirements Analysis Methods Meet GQM
Tokyo Institute of Technology, Japan
Shoichiro Ito, Shinpei Hayashi,and Motoshi Saeki
1
How Can You Improve Your As-is Models?Requirements Analysis Methods
Meet GQM
2
Topic: Detecting problems in As-isand 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 modelsusing metrics derived via GQM
Abstract
Backgroundl Information systems (ISs) should enhance their
business valuel 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
Modeling TechniquesGoal-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’ behavior4
Refines/decomposes goalsClarifies the rationales of requirements
Efficient road network
Traffics managedusing lights
GORA: Goal model
Our Solution:
GORA: Goal model
Refines/decomposes goalsClarifies the rationales of requirements
Efficient road network
Traffics managedusing lights
Problem Frame: Context diag.
For understanding systems’ behaviorClarifies the boundary between
machines and environments
LightsController
(LC)
LightUnits(LU)
LightCycle
5
Integrated Model
Use case modeling: Use case descriptionProvides sequence of steps of each functionalitywhich can be a glue to connect two modeling techniques
Identify problems in an integrated model w/ metrics via GQM
Constructa model
Constructa model
Refinegoals
Identifyproblemsfound
Notfound
As-is
To-be
Our Approach
l 4 steps incl. iteration1. Construct an As-is model2. Identify its problems3. Refine goals4. Construct a To-be model
6
Home deliverypizza
Receive orders
Can order with anequipment anyone has
Easy to orderfor customers
Receive ordersby telephone
Deliver pizzas
Get payment
Stock control
Example Goal Model:Home Delivery Pizza
7
AND
Step 1: Construct As-isl As an integrated model– A goal model (GM)– Use case descriptions (UCDs)– A context diagram (CD)
8
GM UCDs CD
Constructa model
Constructa model
Refinegoals
Identifyproblems
found
Notfound
As-is
To-be
Integration Rule
9
Use case:Receive ordersby telephone
Precondition:Telephone ringing
Basic flow:1. Pick up telephone2. (Get) Name, telephone
number, address3. (Get) Order4. Ring off telephone5. Write an invoice
Receive ordersby telephone
l Each leaf goal in GM ó a UC ó a UCDl Each step in UCD ó an event in CD
Staff (S)
Customer (C)
C! Ring offtelephone
<<human>>
<<human>>
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 telephonePrecondition: Telephone ringingBasic flow:
1. Pick up telephone2. (Get) Name, telephone number, address3. (Get) Order4. Ring off telephone5. Write an invoice
Scenario of Receptionist(Use case description)
<<human>>
<<human>>
Context diagramHome deliverypizza
Receive orders
Receive ordersby telephone
Deliver pizzas
Get payment
Goal model
Step 2: Identify Problemsl In the integrated model, find problems:l E.g.,– High human workload– Complex work
l Identify the source goal(s)
11
Constructa model
Constructa model
Refinegoals
Identifyproblems
found
Notfound
As-is
To-be
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 telephonePrecondition: Telephone ringingBasic flow:
1. Pick up telephone2. (Get) Name, telephone number, address3. (Get) Order4. Ring off telephone5. Write an invoice
Scenario of Receptionist(Use case description)
<<human>>
<<human>>
Context diagramHome deliverypizza
Receive orders
Receive ordersby telephone
Deliver pizzas
Get payment
Goal model
Many shared events btw. Staff and Customer
= High human workload
Step 3: Refine Goalsl For the problematic goals in As-is by– Refining them– Defining their alternatives
13
Constructa model
Constructa model
Refinegoals
Identifyproblems
found
Notfound
As-is
To-be
As-is goal model To-be goal model
Refine
Store andupdate customers’
information
Retrieve customers’ information
Reduce staffs’ effortsin getting name, telephone number,
address from a customer
Record and utilizecustomers’ information
ordered before
Receive ordersby fax
Home deliverypizza
Receive orders
Can order with anequipment anyone has
Easy to orderfor customers
Receive ordersby telephone
Deliver pizzas
-
14
Step 4: Construct To-bel Constructs an integrated model– From new To-be goal model
l Iterative process– Identifies problems again– Stops if no problems found
15
Constructa model
Constructa model
Refinegoals
Identifyproblems
found
Notfound
As-is
To-be
To-be goal model
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 telephonePrecondition: Telephone ringingBasic flow:
1. Pick up telephone2. (Get) Telephone number3. Retrieve4. (Get) Order5. Ring off telephone6. Write an invoice
Customer ManagementSystem (CM)
S! Retrieve
Reduce staffs’ effortsin getting name, telephone number,
address from a customer
Record and utilizecustomers’ information
ordered before
Store andupdate customers’
information
Retrieve customers’information
includes
<<human>>
<<human>>
To-be Integrated Model
16
Metric-Based Identification
17
Constructa model
Constructa model
Refinegoals
Identifyproblems
found
Notfound
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 metricsby deriving• Questions from Goals• Metris from Questions
Approach: Quantifying it via metrics
Aim: (semi-)automatedidentification of problems
Applying GQM
18
Identifying the locations toautomate/reduce human efforts
Goal
Which was frequently performed by human?
Which was hardfor human?
Question
In which was many kinds
of human work performed?
In which was human work preformed at many times?
Which workwas complex for human?
Which work was time
consuming for human?
NE ANOSACCCE
Metric
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 telephonePrecondition: Telephone ringingBasic flow:
1. Pick up telephone2. (Get) Name, telephone number, address3. (Get) Order4. Ring off telephone5. Write an invoice
Scenario of Receptionist(Use case description)
<<human>>
<<human>>
Context diagramCE(Staff) = 5
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 telephonePrecondition: Telephone ringingBasic flow:
1. Pick up telephone2. (Get) Name, telephone number, address3. (Get) Order4. Ring off telephone5. Write an invoice
Scenario of Receptionist(Use case description)
<<human>>
<<human>>
Context diagramNE(Staff) = 5
# event occurrences on each human domain
ACC and ANOSl 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 telephonePrecondition: Telephone ringingBasic flow:
1. Pick up telephone2. (Get) Name, telephone number, address3. (Get) Order4. Ring off telephone5. Write an invoice
Scenario of Receptionist(Use case description)
ACC(UC1) = 1ANOS(UC1) = 5
Supporting Tool
22
Integrated Model
Use case descriptioneditor Context diagram
editor
Goal model editor
Illustrative ExampleReporting operation of a brokerage office
26
Brokerageanalyst
Dedicatedterminal
Historyserver
Distributionserver
Personalterminal
Upload report filesin PDF format
Downloadpast reports
Download/Upload
Write reports
Upload reports
Step 1: As-Is Model
UC1 Collect data
Basic flow1. Call UC32. ......3. ......
Post-condition: Brokerage information provided
Goal model(12 goals)
Context diagram(6 domains, 16 events)
Reporting operationof a brokerage office
Create a report Manage reports
UC1: Collect data UC2: Write a report
UC7: Fix a reportin the distribution server
UC3: Fetch a report
UC5: Store a reportto the distribution server
UC4: Store a reportto the history server
UC6: Fix a reportin 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)
PersonalTerminal
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
Reporting operationof a brokerage office
Create a report Manage reports
UC1: Collect data UC2: Write a report
UC7: Fix a reportin the distribution server
UC3: Fetch a report
UC5: Store a reportto the distribution server
UC4: Store a reportto the history server
UC6: Fix a reportin the history server
Fix a report Store a report
Goal Model (As-is)
28
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)
PersonalTerminal
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>>
UC1 Collect data
Basic flow1. Call UC32. ......3. ......
Post-condition: Brokerage information provided
Step 2: Identify Problemsl Calculating metric values and detecting problems
29
Use cases ANOS ACCUC1 5 1UC2 2 1UC3 3 1UC4 2 1UC5 2 1UC6 7 2UC7 7 2
Events on Analyst #A! RequestReport 1A! Upload 2A! SendReport 2A! Translate 1A! OpenReport 3A! ModifyReport 2A! CreateReport 1A! Survey 1PT! SendReport 1IS! ProvideInfo 1
Total (NE) 15
CE= 12
Context Diagram (As-is)
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)
PersonalTerminal
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>>
30
Use Case Desc. (As-is)ACC(UC6) = 2ANOS(UC6) = 7
31
Reporting operationof a brokerage office
Create a report Manage reports
UC1: Collect data UC2: Write a report
UC7: Fix a reportin the distribution
server
UC3: Fetch a report
UC5: Store a reportto the distribution server
UC4: Store a reportto the history server
UC6: Fix a reportin the history server
Fix a report Store a report
Goal Model (As-is)
32
Step 3: Refine Goals(Build Solution)
Goal Model (As-is)
Report managementsystem
Manage reports(w/ USB)
Manage reports
alternative
Reporting operationof a brokerage office
Create a reportManage reports
UC1: Collect data UC2: Write a report
UC7: Fix a reportin the distribution server
UC3: Fetch a report
UC5: Store a reportto the distribution server
UC4: Store a reportto the history server
UC6: Fix a reportin the history server
Fix a report Store a report
Reporting operationof a brokerage office
Create a report Report management
systemUC1: Collect data UC2: Write a report
UC3': Fetch a reportUC6-7: Fix a reportUC4-5:
Store a report
33
Goal Model (To-be)
Reporting operationof a brokerage office
Create a reportReport management
system
UC1: Collect data UC2: Write a report
UC7: Fix a reportin the distribution server
UC3': Fetch a report
UC5: Store a reportto the distribution server
UC4: Store a reportto the history server
UC6: Fix a reportin the history server
UC6-7: Fix a reportUC4-5:
Store a report
Goal Model (To-be)
34
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)
PersonalTerminal
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 operationof a brokerage office
Create a reportReport
managementsystem
UC1: Collect data UC2: Write a report
UC3': Fetch a reportUC6-7: Fix a reportUC4-5:
Store a report
35
UC1 Collect data
Basic flow1. Call UC32. ......3. ......
Post-condition: Brokerage information provided
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)
PersonalTerminal
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>>
Context Diagram (To-be)l ΔCE = CETo-be – CEAs-is = 7 – 12 = –5 l ΔNE = NETo-be – NEAs-is = 8 – 15 = –7
Reduced!
36
Use Case Desc. (To-be)
ACC(UC3) = 1ANOS(UC3) = 3
ACC(UC3') = 1ANOS(UC3') = 1
l ΔACC = ACCTo-be – ACCAs-is = 1 – 1 = 0l ΔANOS = ANOSTo-be – ANOSAs-is = 1 – 3 = –2
Reduced!
37
Summary of Applicationl 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 flow1. Call UC32. ......3. ......
Post-condition: Brokerage information provided
Goal model(12 goals)
Context diagram(6 domains, 16 events)
Reporting operationof a brokerage office
Create a report Manage reports
UC1: Collect data UC2: Write a report
UC7: Fix a reportin the distribution server
UC3: Fetch a report
UC5: Store a reportto the distribution server
UC4: Store a reportto the history server
UC6: Fix a reportin 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)
PersonalTerminal
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)
PersonalTerminal
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 operationof a brokerage office
Create a reportReport
managementsystem
UC1: Collect data UC2: Write a report
UC3': Fetch a reportUC6-7: Fix a reportUC4-5:
Store a report
32
UC1 Collect data
Basic flow1. Call UC32. ......3. ......
Post-condition: Brokerage information provided
Future Workl 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
ConclusionOur Solution:
GORA: Goal model
Refines/decomposes goalsClarifies the rationales of requirements
Efficient road network
Traffics managedusing lights
Problem Frame: Context diag.
For understanding systems’ behaviorClarifies the boundary between
machines and environments
LightsController
(LC)
LightUnits(LU)
LightCycle
2 .2 .
5
Integrated Model
Use case modeling: Use case descriptionProvides sequence of steps of each functionalitywhich can be a glue to connect two modeling techniques
Identify problems in an integrated model w/ metrics via GQMConstructa model
Constructa model
Refinegoals
Identifyproblemsfound
Notfound
As-is
To-be
Our Approach
l 4 steps incl. iteration1. Construct an As-is model2. Identify its problems3. Refine goals4. Construct a To-be model
6
NE ANOSACC
Identifying the locations toautomate/reduce human efforts
Which was frequently performed by human?
Which was hardfor human?
In which was many kinds
of human work performed?
In which was human work preformed at many times?
Which workwas complex for human?
Which work was time
consuming for human?
CE
Applying GQMGoal
Question
Metric
18
Step 3: Refine Goals(Build Solution)
. 2
Goal Model (As-is)
Report managementsystem
Manage reports(w/ USB)
Manage reports
alternative
Reporting operationof a brokerage office
Create a reportManage reports
UC1: Collect data UC2: Write a report
UC7: Fix a reportin the distribution server
UC3: Fetch a report
UC5: Store a reportto the distribution server
UC4: Store a reportto the history server
UC6: Fix a reportin the history server
Fix a report Store a report
Reporting operationof a brokerage office
Create a report Report management
systemUC1: Collect data UC2: Write a report
UC3': Fetch a reportUC6-7: Fix a reportUC4-5:
Store a report
33
Goal Model (To-be)