© GooBiz.com Agile System Modeling on the basis of Marketing Requirements and the Project Vision How to assure MRD - PSD traceability and deal with changes using a Goal-Driven Modeling ? An ‘MP3 Player’ Case Study… To visualize presentation slides, please use the full screen mode and click to progress © 2010 – 2011 Birol Berkem - GooBiz.com (*) MRD : Marketing Requirement Document PSD : Product Specification Document

Agile Requirements Writing using UP or Scrum Methods User Story Example : « As a Listener of an MP3 Audio-Player System, I would like to Listen and Record Audio with satisfaction » The underlying system requirements for the MP3 Player are : How to smartly structure such requirements in order to deal with changes ? 2

 Step 1. Compose hierarchically business requirements (1) and system requirements (2) that refine them  Step 2. Derive system functions (3) that satisfy these requirements and use cases that invoke system functions  Step 3. Model how system functions are triggered in the Product Life Cycle ?  Step 4. Establish Test Cases on the basis of Use Case Scenarios that realize System Functions (1) Business Requirement : A needed achievement and the quality measures expressed in terms of broad outcomes the business requires. (2) System Requirement : A condition or capacity required by a user from the system in order to fulfill the business requirements (the goal). (3) System Function : Action requested from a product or realized by itself to partially satisfy a requirement 3 Main Steps to « Smartly Gather Requirements » Let’s look at each step on the same case study… Requirements and System Analysis 3

Step 1 - Compose hierarchically business and system requirements to better manage impact analysis when requirements evolve Business Requirement : A need and the quality measures expressed in terms of broad outcomes the business requires System Requirement : A condition or capacity required from the system in order to fulfill the business requirements Functional Boundary of the System under Discussion 4 How to assign requirements to system functions ? (cf. next slide)

Step 2 – Formalize the System Boundary by assigning requirements to system functions System Functions : Actions requested from a product or realized by itself to satisfy partially a user requirement 5 How to capture the rules to be verified by the ‘ Player Controler’ before triggering these system functions ?

6 Step 3 – Model states and transitions of the Player Controler where system functions are triggered by clicking on the « Surrounding » state we will specify how the « Surrounding function » is used (slide 9) In each state a system function is triggered by the Player Controler How to specify the usage of these functions by the Actors of the system ?

Step 4.1 – Determine first how Use Cases invoke System Functions The Audio Player Functions are based on the previous system requirements A base Use Case that processes the actor’s interactions with the system functions 7 How are these functions invoked within Use Case Scenarios ? (see next slide)

8 Step 4.2 – …then elaborate UC Scenarios that invoke System Functions Actor / System Interactions formalize invocation scenarios of system functions in the UC « Listen Audio » This Surround scenario will be available just by a simple click on it (see next slide) Actor / System interactions for the ‘ Surrounding’ Scenario (cf.next)

Steps 4.3/4.4 – Describe each Scenario and the related System Function (Test Case) Actor / system interactions describe the black box test case for the « Surround » function. These Messages become operations to test this function (click to visualize) 9 Object Functional State Operation Contracts for testing this System Function More precisely (see next slide)…

10 Step 4.4 – Specify a Test Component for each System Function to deploy into the System Architecture  Transform each system function into an object in the desired functional state ( a Goal-Oriented Object) (1)  Map actor/system interactions that realize each function as contextual operations of this object A Goal-Oriented Object whose goal is to support The « Surrounding Function » within the Player System 10 How to design the Architecture Backbone using system functions ? (see next slide)…  (1) Goal-Oriented Object : An object in a state whose goal is to test and realize one or more system function scenario Example : All of the actions that realize the Surrounding function (see previous slide) can be tested and realized in the [Surrounding] state of the Player object Object State

The controler of the Player orchestrates execution of these functions External components participate to the realization of functions via required and provided interfaces Step 4.5 – Design a draft of the ‘Architectural Backbone’ before building system functions The Surrounding function is expressed by the [Surrounding] state of the Player object. The actor / system interactions (scenario) that realize this function become its operations Recording function of the Player … 11

 Step 5. Elaborate a High-Level Block Diagram of the System using Parts, Ports and Interfaces  Step 6. Refine and Optimize the initial architecture design to better deal with changes  Step 7.1 Model white box interactions by use case scenario (user story)  Step 7.2 Map corresponding Operations on the Components (Parts) of Blocks 12 Steps for « System Design » Click to visualise these steps on our Case Study… 12 System Design

13 Step 5 – Elaborate the Internal Blocks and Ports of the System : The « User Interface » and « Processing » Subsytems of the Player are shown below An Application Controler block may be designed inside the CPU block to Orchestrate execution of the above functions (see next slide) Functional Blocks will be deployed there to better deal with evolutions of these functions (see next slide) Click to visualize detailed parts and interfaces on the next slide…

14 Etape 6 –An optimized architecture to better deal with changes An Application Controler designed for the cpu block to Orchestrate execution of the above functions (MVC pattern) Surround, Record and Play « Components » designed for the memory (mem) block to better deal with evolutions of these functions (OCP pattern) Provided and required interfaces between the CPU and Mem components How to accurately determine operations of these components ? (see next slide)

15 Step Describe each white box scenario to prepare the Integration Test for the corresponding software component These interactions describe WHITE BOX test case realization for the « Surround » function. They will become operations to test this function (see next slide) Operations of system components will be updated on the basis of these interactions (see next slide)

16 Etape 7.2 – Update components with operations on the basis of white box interactions The White box interactions (previous slide) that realize the Surrounding function become operations of the corresponding block Remember that these system components were already succesfully specified as ‘black box components’ of the Architecture Backbone (see slide 10 and 11)

17 How to deal with changes ?  Model hierachically changed business and system requirements grouping them by goals  Impact changes on system functions (services) to satisfy these requirements  Transform system functions to map them into the system architecture Let’s look at each step on our case study… System Analysis and Design Requirements and System Analysis 17

Model changed business and system requirements Changing Business Requirements that cause extension to previous functions Additional Requirements that must be supported by the system functions to satisfy Business Requirements 18

Impact changes on the system functions to satisy new requirements New Complex Functions are added to the functional architecture to satisfy changes on requirements Requirements and System Analysis 19

Map these functions with corresponding requirements to the existing system architecture for tests New complex functions are mapped into the existing architecture using association or specialization relationships System Analysis and Design 20 Notice how «Goal-Driven Modeling » brings agility in developping systems particularly to better deal with the changes

More complete Agile Modeling and SOA Trainings with BMM, BPMN, UML, SysML and SoaML… © 2011 – GooBiz.com Increasing Business Agility with the Goal-Driven SOA using EA (1 day on your site) Goal-Driven SOA Specification et Realization using BPMN, UML and SoaML (3 days on your site) Goal-Driven SOA Specification et Realization using BPMN, UML and SoaML (3 days on your site) Goal-Driven Agile Business Modeling with BMM, BPMN and SOAML using EA (3 days on your site) Efficient Requirement Analysis with UML 2 using EA (3 days on your site) Component Based System Design with UML 2 using EA (2 days on your site) Agile Embedded System Design with UML 2 and SysML using EA (3 days on your site) to : 21