Building System Models for RE

Slides:



Advertisements
Similar presentations
[ §4 : 1 ] 4. Requirements Processes I Overview 4.1Fundamentals 4.2Elicitation 4.3Specification 4.4Verification 4.5Validation Requirements Definition Document.
Advertisements

lamsweerde Chap.12: Modeling System Operations © 2009 John Wiley and Sons Building System Models for RE Chapter 12 Modeling.
Building System Models for RE Chapter 12 Modeling System Operations.
Building System Models for RE Chapter 11 Modeling System Agents and Responsibilities.
Software Testing and Quality Assurance
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
Report on Intrusion Detection and Data Fusion By Ganesh Godavari.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Copyright W. Howden1 Lecture 2: Elaboration Tasks and Domain Modeling.
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
Chapter 10: Architectural Design
[ §6 : 1 ] 6. Basic Methods II Overview 6.1 Models 6.2 Taxonomy 6.3 Finite State Model 6.4 State Transition Model 6.5 Dataflow Model 6.6 User Manual.
Architectural Design.
Chapter 7 Requirement Modeling : Flow, Behaviour, Patterns And WebApps.
Chapter 10 Architectural Design
S/W Project Management
UML - Development Process 1 Software Development Process Using UML (2)
CLEANROOM SOFTWARE ENGINEERING.
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
UML Diagrams: Class Diagrams The Static Analysis Model Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Report on Intrusion Detection and Data Fusion By Ganesh Godavari.
Chapter 7 System models.
System models l Abstract descriptions of systems whose requirements are being analysed.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Review of Software Process Models Review Class 1 Software Process Models CEN 4021 Class 2 – 01/12.
The Static Analysis Model Class Diagrams Prof. Hany H. Ammar, CSEE, WVU, and Dept. of Computer Science, Faculty of Computers and Information, Cairo University.
1 15 quality goals for requirements  Justified  Correct  Complete  Consistent  Unambiguous  Feasible  Abstract  Traceable  Delimited  Interfaced.
Object-Oriented Software Engineering using Java, Patterns &UML. Presented by: E.S. Mbokane Department of System Development Faculty of ICT Tshwane University.
Deriving Operational Software Specification from System Goals Xin Bai EEL 5881 Course Fall, 2003.
Enabling Self-management of Component-based High-performance Scientific Applications Hua (Maria) Liu and Manish Parashar The Applied Software Systems Laboratory.
Inferring Declarative Requirements Specification from Operational Scenarios IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 24, NO. 12, DECEMBER, 1998.
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
 CMMI  REQUIREMENT DEVELOPMENT  SPECIFIC AND GENERIC GOALS  SG1: Develop CUSTOMER Requirement  SG2: Develop Product Requirement  SG3: Analyze.
UML - Development Process 1 Software Development Process Using UML.
Software Engineering Lecture 10: System Engineering.
Chapter 7 Part II Structuring System Process Requirements MIS 215 System Analysis and Design.
Testing Overview Software Reliability Techniques Testing Concepts CEN 4010 Class 24 – 11/17.
Chapter 9 Architectural Design. Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a software.
Engineering, 7th edition. Chapter 8 Slide 1 System models.
Chapter 4 – Requirements Engineering
The Enhanced Entity- Relationship (EER) Model
Analysis Classes Unit 5.
Lecture 4: Elaboration Tasks and Domain Modeling
An Overview of Requirements Engineering Tools and Methodologies*
UML Diagrams: Class Diagrams The Static Analysis Model
Software Requirements and the Requirements Engineering Process
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Chapter 11: Software Configuration Management
Unified Modeling Language
IEEE Std 1074: Standard for Software Lifecycle
Abstract descriptions of systems whose requirements are being analysed
CHAPTER 2 CREATING AN ARCHITECTURAL DESIGN.
Defining the Activities
Lecture Software Process Definition and Management Chapter 3: Descriptive Process Models Dr. Jürgen Münch Fall
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
Design Model Like a Pyramid Component Level Design i n t e r f a c d s
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
Chapter 11: Software Configuration Management
Chapter 9 Architectural Design.
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
Design Yaodong Bi.
Chapter 7 Goal Orientation in RE
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
Software Development Process Using UML Recap
Presentation transcript:

Building System Models for RE Chapter 15 A Goal-Oriented Model Building Method in Action

Building multi-view system models systematically and incrementally Heuristic rules & patterns for building goal models (Chap.8-9) Heuristics, derivation rules for building object models (Chap.10) Heuristics, derivation rules for building agent models (Chap.11) Heuristics, derivation rules for building operation models (Chap.12) Heuristics, derivation rules for building behavior models (Chap.13) Rules for inter-model consistency (Chap.14) How are these integrated => constructive method for building entire system model ?

A goal-oriented method for building multi-view models

Goal-oriented model building in action 1. Domain analysis: refine/abstract goals SafeTransportation NoTrainSameBlock

Goal-oriented model building in action 1. Domain analysis: refine/abstract goals SafeTransportation NoTrainSameBlock 2. Domain analysis: derive/structure objects On Train Block 0:1

Goal-oriented model building in action 1. Domain analysis: refine/abstract goals 3. S2B analysis: enriched goals (alternatives) SafeTransportation NoTrainSameBlock SafeComd 2. Domain analysis: derive/structure objects On Train Block 0:1

Goal-oriented model building in action 1. Domain analysis: refine/abstract goals 3. S2B analysis: enriched goals (alternatives) SafeTransportation NoTrainSameBlock SafeComd 2. Domain analysis: derive/structure objects On 4. S2B analysis: enriched objects from new goals Train Block 0:1 Driving Command

Goal-oriented model building in action 1. Domain analysis: refine/abstract goals 3. S2B analysis: enriched goals (alternatives) SafeTransportation NoTrainSameBlock SafeComd 2. Domain analysis: derive/structure objects On 4. S2B analysis: enriched objects from new goals SafeAcceler Train Block 0:1 Driving Command 5. Responsibility analysis: agent OR-assignment

Load analysis for goal elicitation

Goal-oriented model building in action 1. Domain analysis: refine/abstract goals 3. S2B analysis: enriched goals (alternatives) SafeTransportation NoTrainSameBlock SafeComd 2. Domain analysis: derive/structure objects 1-5. Obstacle & conflict analysis On 4. S2B analysis: enriched objects from new goals SafeAcceler Train Block 0:1 Driving Command 5. Responsibility analysis: agent OR-assignment

Goal-oriented model building in action 1. Domain analysis: refine/abstract goals 3. S2B analysis: enriched goals (alternatives) SafeTransportation NoTrainSameBlock SafeComd 2. Domain analysis: derive/structure objects 1-5. Obstacle & conflict analysis On 4. S2B analysis: enriched objects from new goals SafeAcceler Train Block 0:1 Driving Command 5. Responsibility analysis: agent OR-assignment Send Command :OBC 6. Operationalization & behavior analysis OnBoardController

Goal-oriented model building in action SafeTransportation NoTrainSameBlock SafeComd On SafeAcceler Train Block 0:1 Driving Command At any time: abstraction (e.g. from scenarios) Send Command :OBC OnBoardController

Goal-oriented model building in action: a mine safety control system System as-is Miners are exposed to multiple hazards while working inside a mine. These include life-threatening levels of percolating water, carbon monoxide, methane, and airflow. Currently, dedicated supervisors have to alert miners inside the mine for prompt evacuation when any of those levels is estimated to be dangerous. Sumps are placed at selected places in the mine for water collection. Each sump is equipped with a pump. The water level in each sump must be regularly checked by dedicated operators to see if the water level is not too high. When this level is too high, the corresponding pump must be turned on to pump the water out of the mine. To avoid the risk of explosion, pumps may not be operated when the methane level exceeds some critical threshold. The current situation results in unacceptable exposure to risks, due to possible human unawareness or misjudgement of potentially dangerous situations; sudden flows of gas or water without operators at the right place to act upon; or pump functioning problems. On the other hand, lack of accurate assesment sometimes results in unnecessary evacuations. The cost of manpower for safety control is another concern.

Goal-oriented model building in action: a mine safety control system System to-be To address these problems, a distributed safety control system will be installed. Each sump will be equipped with water level sensors in order to detect when the water is above a high or below a low level, respectively. A software-based controller shall turn a pump on whenever the water in the corresponding sump has reached the high water level, and off whenever the water has reached the low water level. The mine will also be equipped with sensors at selected places to monitor the carbon monoxide, methane, and airflow levels. An alarm shall be raised, and the operator informed within one second, whenever any of these levels has reached a critical threshold, so that the mine can be evacuated promptly. Human operators can also control the operation of the pump, like previously, but within limits. An operator can turn the pump on or off if the water is between the low and high water levels. A special operator, the supervisor, can turn the pump on or off without this restriction. In all cases, the methane level must be below its critical level if the pump is to be operated. The safety control system shall also maintain sensor readings and pump operation records for history tracking and analysis of anomalies.

Modelling the system-as-is Objective: identify & structure goals and concepts common to any system version (business goals, domain concepts) Step 1: Build preliminary goal model illustrated by scenarios identify, define, classify (type, category), refine/abstract stable goals from available material (e.g. interview transcripts) until reaching questionable refinement options or assignments using heuristic rules & techniques from Section 8.8 Step 2: Derive preliminary object model identify, define, classify (entity, association, agent, event), specialize/generalize stable concepts from goal definitions & domain descriptions using heuristic rules & techniques from Section 10.7

Search for intentional or prescriptive keywords in available material (system-as-is) Miners are exposed to multiple hazards while working inside a mine. These include life-threatening levels of percolating water, carbon monoxide, methane, and airflow. Currently, dedicated supervisors have to alert miners inside the mine for prompt evacuation when any of those levels is estimated to be dangerous. Sumps are placed at selected places in the mine for water collection. Each sump is equipped with a pump. The water level in each sump must be regularly checked by dedicated operators in order to see if the water level is not too high. When this level is too high, the corresponding pump must be turned on to pump the water out of the mine. To avoid the risk of explosion, pumps may not be operated when the methane level exceeds some critical threshold. The current situation results in unacceptable exposure to risks, due to possible human unawareness or misjudgement of potentially dangerous situations; sudden flows of gas or water without operators at the right place to act upon; or pump functioning problems. On the other hand, lack of accurate assesment sometimes results in unnecessary evacuations. The cost of manpower for safety control is another concern.

Search for intentional or prescriptive keywords in available material (system-as-is)

Search for intentional or prescriptive keywords in available material (system-as-is)

Use scenarios for understanding, illustration, goal elicitation (system-as-is) WHY? => Maintain [PumpOn If HighWater] WHY? => Maintain [PumpOff If HighMethane], Avoid [Explosion]

Refine & abstract stable goals: WHY, HOW questions (system-as-is) Avoid [MinersInFloodedMine] 3. WHY ? 4. HOW ? Maintain [SumpPumpedOut If HighWater] Sumps WellDistributed 1. WHY ? 2. HOW ? WaterPumped Out If PumpOn Sufficient PumpCapacity PumpOn If HighWater Common sequence of questions: WHY? directly followed by HOW? on elicited parent goal F to elicit missing subgoals, dom props, hypotheses

milestone-driven refinement Refine & abstract stable goals: using refinement patterns (system-as-is) PumpOn If HighWater HOW ? milestone-driven refinement HighWaterDetected PumpOn If HighWaterDetected Operator Operator refinement stops when questionable options are reached (cf. problems reported about system-as-is) => alternative refinements/assignments in system-to-be

Resulting model fragment (system-as-is) Avoid [MinersInFloodedMine] HOW ? Maintain [SumpPumpedOut If HighWater] Sumps WellDistributed WaterPumped Out If PumpOn Sufficient PumpCapacity WHY ? PumpOn If HighWater milestone-driven refinement HighWaterDetected PumpOn If HighWaterDetected Operator Operator

Using refinement patterns for model restructuring (system-as-is)

Step 1: Build preliminary goal model illustrated by scenarios Step 2: Derive preliminary object model (stable concepts in system-as-is) Def The pump must be on when the water level in the sump is above the high water level PumpOn If HighWater Each sump is equipped with a pump Sump WaterLevel: Depth 1 1 Pump Motor: {on, off} Regulation Def Electrical device regulating the level in a sump by water evacuation out of the mine Def Container located at selected bottom places of the mine for water collection

Step 2: derive preliminary object model (stable concepts in system-as-is) PumpOn If HighWater Each sump is equipped with a pump Sump WaterLevel: Depth 1 1 Pump Motor: {on, off} Regulation Location WaterEvacuation Inside Miner ... Mine MethaneLevel Def Miners inside the mine must be alerted whenever the level of methane is estimated too high Achieve [MinersAlerted If HMDetected]

Infer behavior model from scenarios for understanding “interesting” conceptual objects For Pump entity, Motor attribute with range {on, off, down} StartUp NotOperating EndRepair pumpProblem Operating NotPumping Pumping pumpOn pumpOff Failure Stop

A goal-oriented method for building multi-view models

Modelling the system-to-be Objective: expand preliminary structure of common goals & concepts, assign new responsibilities, derive operationalizations from reported problems on system-as-is, opportunities + any other elicited material about system-to-be => alternative goal refinements & agent assignments Step 3: replay Step 1 for system-to-be identify, define, classify, refine/abstract new goals until reaching goals assignable to individual agents (incl. software) using heuristic rules & techniques from Section 8.8 Step 4: replay Step 2 for system-to-be identify, define, classify, specialize/generalize new concepts from goal definitions & domain descriptions using heuristic rules & techniques from Section 10.7

From problems with system-as-is to soft goals on system-to-be The current situation results in unacceptable exposure to risks, due to possible human unawareness or misjudgement of potentially dangerous situations; sudden flows of gas or water without operators at the right place to act upon; or pump functioning problems. On the other hand, lack of accurate assesment sometimes results in unnecessary evacuations. The cost of manpower for safety control is another concern. Opportunity: distributed multi-sensor technology Reduce [SafetyRiskExposure] ... Improve [HumanAwarenessOf DangerousSituations] Reduce [UnnecessaryEvacuations] Improve [AccurateAssessmentOf DangerousSituations] Reduce [SafetyControlCost] ...

Search for intentional/prescriptive keywords in available material (system-to-be) To address these problems, a distributed safety control system will be installed. Each sump will be equipped with water level sensors in order to detect when the water is above a high or below a low level, respectively. A software-based controller shall turn a pump on whenever the water in the corresponding sump has reached the high water level, and off whenever the water has reached the low water level. The mine will also be equipped with sensors at selected places to monitor the carbon monoxide, methane, and airflow levels. An alarm shall be raised, and the operator informed within one second, whenever any of these levels has reached a critical threshold, so that the mine can be evacuated promptly. Human operators can also control the operation of the pump, like previously, but within limits. An operator can turn the pump on or off if the water is between the low and high water levels. A special operator, the supervisor, can turn the pump on or off without this restriction. In all cases, the methane level must be below its critical level if the pump is to be operated. The safety control system shall also maintain sensor readings and pump operation records for history tracking and analysis of anomalies.

milestone-driven refinement Step3 - Expand preliminary goal structure: using intentional keywords, HOW ELSE questions, refinement patterns PumpOn If HighWater HOW  ELSE ? milestone-driven refinement HighWaterDetected PumpOn If HighWaterDetected resolve lack of controllability highWater Sensor PumpSwitchOn If HighWaterDetected PumpOn If SwitchOn Pump Actuator Safety Controller

uncontrollability-driven Step3 - Expand preliminary goal structure: eliciting further goals through WHY, HOW questions Avoid [PumpFailure] ... Avoid [ PumpOn When NoWater] WHY ? PumpOff If LowWater HOW ? milestone-driven LowWaterDetected Pump0ff If LowWaterDetected uncontrollability-driven PumpSwitchOff If LowWaterDetected PumpOff If SwitchOff lowWater Sensor Pump Actuator Safety Controller

Step3 - Expand preliminary goal structure: use scenarios for illustration, understanding, further elicitation

Step4 - Expand object model: replay Step 2 from new goals + multiplicities for further elicitation

Step 5: Analyze obstacles for more complete goal model (cf. Chap. 9) ...

Step 5: Detect and resolve conflicts (cf. Chap. 3, 16, 18) boundary condition for conflict resolution by goal weakening

Step 5: Using scenarios to illustrate resolutions

A goal-oriented method for building multi-view models

Step 6: Analyze responsibilities and build the agent model Define agents, their capabilities monitored/controlled variables Check goal realizability by assignable agents capabilities must match monitored/controlled conditions in goal Build agent diagram, derive context diagram reponsibilities for leaf goals, agent interfaces Annotate capability, responsibility links: instance declarations Using heuristic rules & techniques from Chap. 11 agent refinement, software counterpart of human assignments, avoiding critical dependencies, ... check consistency rules among goal, object, agent models => Alternative responsibility assignments evaluated in Step 7

Step 6: agent diagram

Step 6: Deriving a context diagram PumpOn If HighWater HighWaterDetected PumpOn If HighWaterDetected PumpSwitchOn If HighWaterDetected PumpOn If SwitchOn highWater Sensor Pump Actuator Safety Controller highWaterSensor. highWaterSignal Safety Controller Pump.Switch highWater Sensor Pump Actuator ... ...

Step 7: Make choices among alternative options Options = alternative goal refinements, agent assignments, obstacle resolutions, conflict resolutions Evaluation needed to select "best" option Often in parallel with preceding steps Pros/cons of option = source for soft goal elicitation (cf. Chap. 8) By use of evaluation techniques ... informal heuristics: favor options ... best contributing to leaf soft goals introducing fewer / less severe risks introducing fewer / less severe conflicts resolving more / more severe risks or conflicts qualitative or quantitative techniques: cf. Chap. 16

Step 7: Selecting among options HighWaterDetected highWaterSensor LowWaterDetected lowWaterSensor better contributes to Reduce [SafetyRiskExposure] Reduce [SafetyControlCost] than HighWaterDetected WaterLevelSensor LowWaterDetected Same for CentralSafetyCtrler PumpSwitchOn If HighWater AndNot HighMethane DistibutedSafetyCtrler

A goal-oriented method for building multi-view models

Step 8: Operationalize leaf goals in the operation model Identify & specify the services to be provided by system-to-be to ensure leaf behavioral goals (satisfaction arguments) software operations, environments tasks Write precise specs (at least for sofware operations) Signature, DomPre/Post ReqPre, ReqTrig, ReqPost (if any), for every underlying goal Build operationalization diagram, derive use case diagrams Annotate agent-operation performance links: instance declars Use heuristic rules & techniques from Chap. 12 identify operations from scenario events, from goal fluents, ... check consistency rules among goal, object, agent, operation models

Operationalizing leaf goals: operationalization diagram fragment for SafetyController agent

Specify operations & operationalizations ReqTrig: hWs.highWaterSignal = ‘on’ and not hMs.highMethaneSignal = ‘on’ ReqPre: not hMs.highMethaneSignal = ‘on’ Input p: pump, hWs: highWaterSensor, hMs: highMethaneSensor, ... Output p: pump / Switch DomPre pump p's switch is off DomPost pump p's switch is on

Derived use case diagram Pre The pump switch is off and the high water signal becomes on and methane level is below critical Post The pump switch is on SwitchPumpOn highWater Sensor Pump Actuator SwitchPumpOff ResetMethaneAlarm lowWater Sensor RaiseMethaneAlarm methaneAlarm Actuator ... highMethane Sensor SafetyController See algorithm in Section 12.6

Step 9: Build & analyze the behavior model Model fragment for SafetyController agent, derived from annotated operationalization diagram (cf. Section 13.5.5) SafetyControllerState PumpSwitchState [ highWaterSignal = ‘on’ and not highMethaneSignal = ‘on’ ] PumpSw Off PumpSw On [ lowWaterSignal = ‘on’ or highMethaneSignal = ‘on’ ] MethaneAlarmSwitchState [ highMethaneSignal = ‘on’ ] MethAlarm SwOff MethAlarm SwOn methaneAlarmReset [ not highMethaneSignal = ‘on’ ] WaterAlarmSwitchState PumpFailure [ highWaterSignal = ‘on’ ] WaterAlarm SwOff WaterAlarm SwOn waterAlarmReset [ not highWaterSignal = ‘on’ ]

Step 9: Build & analyze the behavior model Similar model fragment for SafetyController agent, generalized from scenario examples (cf. Section 13.5.3) SafetyControllerState PumpSwitchState highWaterSignalOn [ not highMethaneSignal = ‘on’] PumpSw Off PumpSw On lowWaterSignalOn highMethaneSignalOn MethaneAlarmSwitchState highMethaneSignalOn MethAlarm SwOff MethAlarm SwOn methaneAlarmReset [ not highMethaneSignal = ‘on’ ] WaterAlarmSwitchState PumpFailure [ highWaterSignal = ‘on’ ] WaterAlarm SwOff WaterAlarm SwOn waterAlarmReset [ not highWaterSignal = ‘on’ ]

Generalizing from examples: some input scenarios

Building multi-view system models systematically and incrementally Heuristic rules & patterns for building goal models (Chap.8-9) Heuristics, derivation rules for building object models (Chap.10) Heuristics, derivation rules for building agent models (Chap.11) Heuristics, derivation rules for building operation models (Chap.12) Heuristics, derivation rules for building behavior models (Chap.13) Rules for inter-model consistency (Chap.14) How about model variants for product lines ?

Handling model variants for product lines To capture model commonalities and variations: keep multiple options in Step 7 Variation point = OR-refinement, OR -assignment, OR -resolution of obstacle or conflict Commonality: parent goal in refinement, assignable goal, obstacle/conflict to be resolved Variations: alternative refinements, assignments, resolutions Product configuration = selection of specific option at each variation point Process: define commonalities & variations; associate variations with specific PL members; form configurations by taking commonalities + specific variations

Elaborating commonalities & variations in PL goal model To associate variations with specific PL members: Attach SysRef attribute to nodes after variation point F identifies PL members to be developed with this option (cf. Sect. 8.7) At successor nodes of any variation point ... SysRef values must be disjoint SysRef list of variant references must be included in the SysRef list at alternative node preceding the variation point If needed, use generalization/specialization mechanism for structural commonality/variations in object model with SysRef attached to specialization link

Commonalities & variations in PL goal model for meeting scheduling

Commonalities & variations in PL object model for meeting scheduling

Forming model configurations To get goal model for specific PL member M: top-down, breadth-first traversal of PL goal model at each variation point, keep ... upward commonalities, successor option whose SysRef list includes M Customized agent, operation, behavior models for M are derived from this customized goal model

From multi-view models to project deliverables model editor requirements documents generator model browser (HTML generator)

Model-driven generation of Requirements Document From selected diagrams and textual annotations goal refinement trees => section/subsection trees Def annotations, ... According to templates fitting the IEEE-830 standard or company-specific standards Two-step process: 1. Create an internal composite document (by drag & drop from Concept Explorer) 2. Export the composite document ® RTF, PDF

Model-driven Requirements Document generated according to IEEE Computer Society Std 830 1. Introduction 1.1 Document purpose 1.2 System purpose 1.3 Definitions, acronyms & abbreviations 1.4 References 1.5 Overview 2. Overall Description 2.1 System perspective 2.2 User requirements 2.3 User characteristics 2.4 Constraints 2.5 Assumptions and Dependencies 2.6 Apportioning of requirements 3. System Requirements high-level goals generated from the object model derived from goal model traversed from top to bottom expectations & unresolved obstacles requirements priority derived from agent, object & operation models