Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How Can You Improve Your As-is Models? Requirements Analysis Methods Meet GQM

9,742 views

Published on

Presented at REFSQ 2017
http://dx.doi.org/10.1007/978-3-319-54045-0_8

Published in: Software
  • Be the first to comment

  • Be the first to like this

How Can You Improve Your As-is Models? Requirements Analysis Methods Meet GQM

  1. 1. HowCanYouImproveYourAs-isModels? RequirementsAnalysis Methods Meet GQM Tokyo Institute of Technology, Japan Shoichiro Ito, Shinpei Hayashi, and Motoshi Saeki 1
  2. 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. 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. 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. 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
  6. 6. 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
  7. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  22. 22. SupportingTool 22 Integrated Model Use case description editor Context diagram editor Goal model editor
  23. 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. 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. 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
  26. 26. 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>> UC1 Collect data Basic flow 1. Call UC3 2. ...... 3. ...... Post-condition: Brokerage information provided Step 2: Identify Problems l Calculating metric values and detecting problems 29 Use cases ANOS ACC UC1 5 1 UC2 2 1 UC3 3 1 UC4 2 1 UC5 2 1 UC6 7 2 UC7 7 2 Events on Analyst # A! RequestReport 1 A! Upload 2 A! SendReport 2 A! Translate 1 A! OpenReport 3 A! ModifyReport 2 A! CreateReport 1 A! Survey 1 PT! SendReport 1 IS! ProvideInfo 1 Total (NE) 15 CE = 12
  27. 27. 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) 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>> 30
  28. 28. Use Case Desc. (As-is) ACC(UC6) = 2 ANOS(UC6) = 7 31
  29. 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. 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. 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. 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
  33. 33. 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>> Context Diagram (To-be) l ΔCE = CETo-be – CEAs-is = 7 – 12 = –5 l ΔNE = NETo-be – NEAs-is = 8 – 15 = –7 Reduced! 36
  34. 34. Use Case Desc. (To-be) ACC(UC3) = 1 ANOS(UC3) = 3 ACC(UC3') = 1 ANOS(UC3') = 1 l ΔACC = ACCTo-be – ACCAs-is = 1 – 1 = 0 l ΔANOS = ANOSTo-be – ANOSAs-is = 1 – 3 = –2 Reduced! 37
  35. 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. 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. 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)

×