Ivan Marsic Rutgers University

1. LECTURE 12: Problem FramesPart I: Decomposition Ivan Marsic Rutgers University

2. Topics • Typical System Requirements and Problems • Five Problem Frames: • Transformation • Simple Workpieces • Required Behavior • Information Display • Commanded Behavior

3. Why Problem Frames? • Because the best way to start solving your problem is by understanding it first. • Problem frames help us analyze and understand the problem that we are to solve. • Problem frames are the building blocks of SE problems • They are the most basic user stories or use cases

4. Typical System Requirements • REQ-1: Map input data to output data as said by given rules • REQ-2: Allow repository (or document) editing, where “repository” is a collection of data • REQ-3: Automatically control a physical object/device • REQ-4: Interactively control a physical object/device • REQ-5: Monitor and display information about an object

5. Typical Software Eng. Problems 1.a) System transforms input document to output document 1. User works with computer system (environment irrelevant/ignored) REQ-1: Map input data to output data as said by given rules IN doc System OUT doc 1.b) User edits information stored in a repository User System System REQ-2: Allow repository editing, where “repository” is a collection of data Repository User 2. Computer system controls the environment (user not involved) REQ-3: Automatically control a physical object/device System Environment 3.a) System observes the environment and displays information 3. Computer system intermediates between the user and the environment REQ-5: Monitor and display information about an object User System Environment 3.b) System controls the environment as commanded by the user User System Environment REQ-4: Interactively control a physical object/device Environment User System

6. Problem Architecture REQ-1: Map input data to output data as said by given rules Feeding subsystem Transformation subsystem Receiving subsystem 1.a) Transformation: REQ-2: Allow repository editing, where “repository” is a collection of data Data editor 1.b) Simple workpieces: User Data repository REQ-3: Automatically control a physical object/device Controlling subsystem Controlled subsystem 2. Required behavior: REQ-5: Monitor and display information about an object Monitoring subsystem Monitored subsystem 3.a) Information display: Display REQ-4: Interactively control a physical object/device Controlling subsystem Controlled subsystem 3.b) Commanded behavior: Operator

7. Aspect-Oriented Requirements Object-Oriented Analysis & Design Requirements gathering Requirements analysis Requirements specification Structured Analysis & Design Agile Development User Stories Requirements Process [ Recall Section 2.2: Requirements Engineering ]

8. Requirements and Specification Problem domain Software domain Describes Specification Requirements Program Customer Specifies Analyzes Develops Software Engineer

9. Software-to-be (“Machine”) Problem Domain Requirement a b Machine and Problem Domain (a) Software-to-be (“Machine”) Problem Domain Requirement a b Domain properties seen by the requirement (b) Requirement Specification Domain properties seen by the software-to-be a: specification interface phenomena b: requirement interface phenomena

10. Problem Framing • Problem framing means dividing the problem at its “seams” into smaller sub-problems • The difficulty is in recognizing the “seams” • Problem frames are derived from commonly occurring software requirements • They afford ready-made checklists for requirements analysis and system specification • We look for such basic problems to help us discover the “seams” of our problem

11. Example: Problem Decomposition REQ1: Keep door locked and auto-lock REQ2: Lock when “LOCK” pressed REQ3: Unlock when valid key provided REQ4: Allow mistakes but prevent dictionary attacks REQ5: Maintain a history log REQ6: Adding/removing users at runtime REQ7: Configuring device activation preferences REQ8: Inspecting the access history REQ9: Filing inquiries PROBLEM DOMAIN (5) Device preferences (6) Photosensor (7) Light (3) Key (1) Tenant (4) List of valid keys (3) Lock (8) Alarm bell (11) Log of accesses Software-to-be (2) Landlord (10) Tenant accounts (9) Desktop computer Difficult to consider the whole system at once…

12. Example: Problem Decomposition REQ1: Keep door locked and auto-lock REQ2: Lock when “LOCK” pressed REQ3: Unlock when valid key provided REQ4: Allow mistakes but prevent dictionary attacks REQ5: Maintain a history log REQ6: Adding/removing users at runtime REQ7: Configuring device activation preferences REQ8: Inspecting the access history REQ9: Filing inquiries REQ1, REQ2, REQ3, REQ4 REQ3 PROBLEM DOMAIN (5) Device preferences (6) Photosensor (7) Light Subsystem-2 (3) Key (1) Tenant (4) List of valid keys Subsystem-1 (3) Lock REQ4 Subsystem-3 (8) Alarm bell (11) Log of accesses Software-to-be (2) Landlord (10) Tenant accounts REQ5, REQ7, REQ8, REQ9 (9) Desktop computer Subsystem-4  Decompose the system based on its requirements

13. Example: Problem Decomposition [ Case Study 1: Safe Home Access ] Required Behavior • REQ1: keep door locked and auto-lock • REQ2: lock when “LOCK” pressed • REQ3: unlock when valid key provided • REQ4: allow mistakes but prevent dictionary attacks • REQ5: maintain a history log • REQ6: adding/removing users at runtime • REQ7: configuring device activation preferences • REQ8: inspecting the access history • REQ9: filing inquiries Commanded Behavior Information Display (database is the “display”) Simple Workpieces Simple Workpieces Information Display Simple Workpieces

14. Example: Problem Decomposition [ Case Study 2: Investment Fantasy League ] Information Display • REQ1: view market prices and volumes • Domains: exchange, display • REQ2: place a trade • Domains: investor, tradable-securities, pending-trades • REQ3: execute trades when conditions matched • Domains: exchange, pending-trades • REQ4: generate periodic report • Domains: portfolio, report • REQ5: generate leaderboard • Domains: all-portfolios, leaderboard • REQ6: view leaderboard • Domains: leaderboard, display • REQ7: start a trading group/clique • Domains: investor, group • REQ8: invite to a trading group/clique • Domains: investor, friends, group Simple Workpieces Required Behavior Transformation Transformation Information Display Simple Workpieces Commanded Behavior

15. Control software Broker software Key: C Causal domain X Lexical domain [C] Causal phenomena [E] Events [Y] Symbolic requirement phenomena Basic Frame 1: Required Behavior CS!C1 C3 Controlled domain Required behavior CD!C2 C Example: Execute a Trading order Control Software Controlled Domain Required Behavior a b Stock exchange Order handling rules C a: BS! {Execute[i]} [C1] b: SE! {Place[i], Cancel[i], Executed[i], Expired[i]} [C3] SE! {PriceQuotes, Ack[i], Failed[i]} [C2]

16. Required Behavior- Checklist of Concerns Required Behavior Frame Checklist • Existing behavior of the controlled domain: • Behavioral rules of the domain without system-to-be • Required behavior of the controlled domain: • Behavioral rules to be effected by our system • Capabilities of available “sensors”: • Sensed parameters: type, sampling rate, precision, … [ Case Study 1: Safe Home Access — REQ1: keep door locked and auto-lock ] Existing behavior for REQ1: Currently, the lock armed mechanically and remains so until mechanically disarmed If the user unlocks, but forgets to lock, the lock remains disarmed Required behavior for REQ1: The lock will be armed electronically and periodically checked that it remains so until explicitly disarmed If the user unlocks, but forgets to lock, the lock will be automatically disarmed after an interval “autoLockInterval” Capabilities of available “sensors”: The lock device will report current status when queried via USB protocol, using command

17. Commanded Behavior- Checklist of Concerns Document what the user can (cannot) do and how the system can help them do it (or prevent them from doing other things) Commanded Behavior Frame Checklist • Requested user commands: • List of all possible user commands and their parameters • Command applicability under different scenarios: • Description of scenarios for which each commandis applicable • Consequences of unacceptable commands: • What should happen if the user tries to execute a commandthat is not supported/allowed under the current scenario [ Case Study 1: Safe Home Access — REQ2: lock when “LOCK” pressed REQ3: unlock when valid key provided REQ4: allow mistakes but prevent dictionary attacks] Requested user commands (REQ2, REQ3): Lock, Unlock(key, door-ID) Command applicability under different scenarios (REQ2 - REQ4): Lock has no restrictions (always applicable) Unlock applicable only if numOfAttemps  maxNumOfAttempts Consequences of unacceptable commands (REQ4): When entered key does not correspond to the door-ID, increment numOfAttemps (block if > maxNumOfAttempts) When not applicable, Unlock will be ignored

18. Information Display- Checklist of Concerns Information Display Frame Checklist • Required information to observe: • Capabilities of available “sensors” • Required information to visualize: • Visualization description • Rules for visualization of the observed information: • The transformations needed to process the raw observedinformation to obtain displayable information [ Case Study 1: Safe Home Access — REQ5: maintain a history log (database is the “display”) ] [ Case Study 1: Safe Home Access — REQ8: inspecting the access history ] Information to observe for REQ8: Database records of past accesses Required information to visualize for REQ8: Access information will be displayed as stored, without post-processing Rules for visualization for REQ8: Render the result of the query as an HTML table

19. Simple Workpieces- Checklist of Concerns Simple Workpieces Frame Checklist • Data structures: • Data types of elements (“workpieces”) of the document • Requested commands: • List of all possible user commands and their parameters • Command applicability under different scenarios: • For each command, exactly describe the preconditions for execution • Consequences of unacceptable commands: • What should system do if the user tries to executea command that is not supported/allowed under the current scenario [ Case Study 1: Safe Home Access — REQ9: filing inquiries ] [ Case Study 1: Safe Home Access — REQ6: adding/removing users at runtime ] Data structures for REQ6: Database tables for each user, containing name, demographics, apartment number, keycode, … Requested commands for REQ6: Add new tenant Modify information of existing tenant Move tenant to a past-tenants table (no permanent deletion allowed) Command applicability under different scenarios: Applicable for a user type Landlord

20. Transformation- Checklist of Concerns Transformation Frame Checklist • Input & output data structures: • Data types of elements of the input document & of output doc • Traversal rules for data structures: • E.g., breadth-first or depth-first • Mapping rules for elements of data structures: • How an input element is mapped/transformed to an output element

21. Operator Controlled domain B A B B C C C Control software Basic Frame 2: Commanded Behavior CS!C1 CD!C2 C3 Command behavior E4 OP!E4 Example: Place a Trading order Controlled domain Command behavior a b Control software D c c Operator a: TS! {Create[i]} [E1] c: TR! {Place[i], Cancel[i], Executed[i], Expired[i]} [Y3] b: TR! {PriceQuotes, Place[i]} [Y2]

22. Real world B A Display Information software C C C C C Basic Frame 3: Information Display RW!C1 C3 Display ~ Real world Y4 IS!E2 Example: Place a Trading order Real world Information software Display ~ Real world a c D b d Display a: TS! {Create[i]} [E1] c: TR! {Place[i], Cancel[i], Executed[i], Expired[i]} [Y3] b: TR! {PriceQuotes, Place[i]} [Y2]

23. Work pieces Trading order X X Trader User B B Editing tool Trading software Basic Frame 4: Simple Workpieces ET!E1 WP!Y2 Y3 Command effects E3 US!E3 Example: Place a Trading order Workpieces Command effects a c Editing tool Order placing rules b d User a: TS! {Create[i]} [E1] c: TR! {Place[i], Cancel[i], Executed[i], Expired[i]} [Y3] b: TR! {PriceQuotes, Place[i]} [Y2]

24. Inputs B A Outputs Transform software X X X X C Basic Frame 5: Transformation IN!Y1 Y3 IO relation Y4 TS!Y2 Example: Place a Trading order Inputs a c Transform software IO relation D b d Outputs a: TS! {Create[i]} [E1] c: TR! {Place[i], Cancel[i], Executed[i], Expired[i]} [Y3] b: TR! {PriceQuotes, Place[i]} [Y2]

25. Software-to-be (The Machine) Machine 4 Machine 2 Machine 1 Domain 5 Domain 2 Domain 1 Requirement 1 Requirement 2 Requirement 4 Machine 3 Domain 3 Requirement 3 Domain 4 Domain 1 Complex Problem Decomposition The Requirements Domain 5 Domain 2 (a) Domain 3 Domain 4 (b)