Model Based Requirements Engineering

Agile Modeling in the Software Lifecycle

June 2013 1

June 2013 2

Model Based Requirements EngineeringContent• A More Formal Approach to Structure Requirements• Guiding Principles• Part of Application Lifecycle Management (ALM)• Projects Are Great – Products last longer• Prioritize and Keep Track of Requirements• Complicated Interactions Require Formal Rules• Implementation of the Product View and theGenerated Artifacts• UML Profile Facilitate Implementation• Define Once, Maintain Regularly, Reuse and Generate Often• Multitude of Different Traces - Traceability in Enterprise Architect• Business Object Model• Interface Model (incl. Mapping to BOM)• REGRASP (RE Graphical Specification)• Traceability Report• Leverage your Reuse Potential• Benefits• Appendix

Repository based modeling tool

Shared Repository Graphical Specification Traceability Standardized modeling

method based on UML profiles

Regulation Multiple Business Channels Complex Business Interaction Distributed Development Cost Pressure

Reuse Models Minimize

communication efforts

Bring roles and activities together

ALM with Product Focus

Support Distributed Delivery Teams

Foster Standardization

Generate Documents

Business Rules going viral

Scattered information

Many models and documents

Disconnected artifacts

Complex application interaction

Increasing number of Test Cases

June 2013 3

1 2

34

Model Based Requirements EngineeringA More Formal Approach to Structure Requirements

June 2013 4

Model Based Requirements EngineeringGuiding Principles

Assume Simplicity

Embrace Change

Working Software is your Primary Goal

Produce well crafted Software – Enabling the Next Effort is Your Secondary Goal

Incremental Change

Maximize Stakeholder ROI

Model with a Purpose

One model with multiple Views (Diagrams) – minimize Legacy

Quality Work

Rapid Feedback

Secure your results

Standardize your model elements e.g. Story, Use Case, BOM, Interface, Screen, Reports, Qualities (NFR)

Testting Model Based Requirements Engineering

(Enterprise Architect)

JIRA

Project Requirement (Copy)

Test Case

Request in IT-AM Request Pool

EPIC/Feature on JIRA Project Instance

Product Requirement

Test Defect

Product Requirement

Test Defect

Product Requirement (Copy)

Project Requirement (Copy)

1

2

3

8

4

5

4

7

8

6

Trace

Trace

Trace

Trace

Trace

Trace

TraceUnidirectional Synchronization

Bidirectional Synchronization

Unidirectional Synchronization

Caption:Step in ALM Process

SynchronizationTraceability

7

Trace

Application Lifecycle ModelPart of Application Lifecycle Management (ALM)

June 2013 5

Caption: RequestEpic/Feature

Multi Projects and Applications support

Epic 2Project N2

Epic 4Project N1

Iteration 1Iteration 2

Iter..

Epic nProject Nn

SubTask n

SubTask 22

SubTask 44

SubTask n

Request 2 Epic 4 SubTask 2 Task

SubTask 21

SubTask 12

SubTask 11

Request 2

Request 1

Request 3

SubTask 31

link

link

link

BPL

ProgramLead

BPLBPL

ProductOwner

ITBankIT/

Architecture

SSponsor

SME

Subject MatterExpert

PLPL/Program

Lead

ITProvider

IT-AM Requests in AMITREQPOOL

Request coordination and prioritization

SubTask 32

link

PRQ 1 Project Requirement (USC-UserStory, BRU, NFR...)

Bug 1 Bug

Epic 6Project N3

Epic 5Project N1

Iteration 1Iteration 2

SubTask 53

SubTask n

SubTask 64

Project Team 2 (JIRA)

SubTask 51

SubTask 42

SubTask 41

Request 5

Request 4

Request 6

SubTask 61

SubTask 62

SubTask 63

link

link

Epic 1Project N1

Project Team 1 (JIRA)

SubTask 1

Application 1 Repository QC

Application 1 Repository EA

tracetests

tests

trace

trace

Application 2 Repository QC

Application 2 Repository EA

tracetests

tests trace

Application 3 Repository QC

Application 3 Repository EA

Product Req 1 Product Requirement (USC-UserStory, BRU, NFR...)

LinkSyncro-nisation

Epic 7Project N3

link

Epic 3Project N1

link

Bug 51

Bug 51

Bug 11

PRQ 41

PRQ 21

Story 21

Bug 11

Story 51

PRQ 61

Story 62

Bug n

PRQ 41

Story 51 Story 51

PRQ 41

Story 21

PRQ 21

PRQ 11PRQ 11

PRQ 21

Story 21

Testcase PRQ 1

Testcase PRQ 22tests

Testcase Story 21

Testcase PRQ 41

Testcase Story 51 Product USC 51

Product Req 41

Epic 5

Epic 4Epic 4

Epic 5

Epic 2

Product USC 21

Product REQ 21

Product REQ 11

Product REQ 11

tests

Product REQ 21

tests

Epic 1PRQ 11

Epic 1

Epic 2

Product USC 21

tests

Product Req 41

tests

Product USC 51tests

ALM with Product FocusProjects Are Great – Products last longer

June 2013 6

Requirements (e.g. Epics, Stories, USC’s, Interfaces, Business Rules) are tracked in JIRA

Requirements in JIRA represent the change order derived from a Request

Product Requirements (e.g. USC, BRU, INT) modeled in EA represent the full specification

Requirements Management in JIRAPrioritize and Keep Track of Requirements

June 2013 7

Synchronisation EAI BPMN Engine

Tool ChainOperator

PL/ProgramLead

LLCH States

activate synchronization

stallstalledactive

deactivated

new

Meta JIRA Instance (Meta Data Container for Syncro) BPMN Server

Quality Center Product Repository

Enterprise Architect Product Repository

JIRA Team instances

Export Product Requirements from EA to QC

June 2013 8

Synchronization of Requirements and ModelsComplicated Interactions Require Formal Rules

SPARX Enterprise Architect (EA) acts as master of all product specific items

Traceability from Request to Code with help of EA and JIRA

Each Product/Platform has its own EA repository

With a shared product repository – common types, conceptual interfaces and domain glossaries are provided for all repositories

All specifications are generated with EA (REGRASP: Requirements Engineering GRAphical SPecification)

Base-Lining in EA

Reuse of RE artifacts in the Software Architecture Documentation – standardized report for applications

June 2013 9

Separation of Product and Project ViewImplementation of the Product View

Enterprise Architect

Project Requirement (Copy)

Design Element

Product Requirement

Code

Requirements Engineering Documentation), Release Specific Documents

Architecture DocumentationAnalysis/Design Documents

Build and Deployment artifacts

Requirements EngineeringWork ProductSolution EngineeringWork Product

Legend

Visual Studio Database SVN, GIT TeamCity

IDE or CBI

Generated

Generated

Component Naming

June 2013 10

Enterprise Architect – Product ViewOverview of Generated Artifacts

UML Profile supporting all standardized artifacts

Reporting based on the UML Profile

UML Profile easily available in the Toolbox

June 2013 11

Model Based Requirements EngineeringUML Profile Facilitate Implementation

Manage Product Requirements – choose the appropriate Atomic Requirement and document Generate report with integrated templates

Add relationships with the context menu

Work out horizontal traceability in your various diagrams

Select artifact – press F8 to open RTF report generation dialog box

Define file name and select the corresponding template and generate

UC0005.rtf

June 2013 12

Atomic Requirements and Simple ReportsDefine Once, Maintain Regularly, Reuse and Generate Often

Requirement Engineering (conceptual view)dBOM (Domain Base Types)

Solution Architecture

Software Engineering

Logical Datamodel

Solution Arch: UseCase Realization

Solution Arch: Deployment Architecture

Solution Arch: Other Comp. e.g. Logical Interfaces/Jobs

Project Requirement

Source Code

aBOM (Application Base Types)

Product Req: UseCase (arch. relevant)

Product Req: NFR (arch. relevant)

Product Req: INT, Screen, Report… (non-arch. relevant)

Physical Datamodel

Comp Spec: Tech. UseCase Realization

Comp Spec: Physical Comp. e.g. Physical Interfaces/.NET Classes etc.

Realize

Realize

Realize

Realize

Realize

Realize

Realize

Realize

Depending

Check-In

NamingUses

June 2013 13

Model Based Requirements EngineeringMultitude of Different Traces

Project Requirements automatically created (JIRA to EA synchronization)Establish vertical traceabilitywith a trace arrow connecting the Project Requirement with the Product Requirement

Project Requirements synchronized with JIRA (Requests and Reqs)

Product Requirements are modeled in Enterprise Architect

Vertical Traceability (link Project Requirements to Product Requirements)

June 2013 14

Model based Requirements EngineeringTraceability in Enterprise Architect

With the BOM you are modeling on a conceptual level!

Try to use conceptual/business data types e.g. Currency, Country, GICS, TransactionTypes and reuse them (shared repository)

External Interfaces shall not be presented as “conceptual” methods in the BOM. Model in– and outbound Interfaces explicitly and map them to your BOM.

June 2013 15

Models in Model Based Requirements EngineeringBusiness Object Model

Interfaces are tied to Use Cases from a conceptual point of view

Use conceptual data types (business data types) and components provided by Shared Product Repo

Map your Interface “DataTransferType” attributes the BOM attributes via Feature Link

Add Mapping rules as constraints in the properties of the “InformationFlow” connector

June 2013 16

Models in Model Based Requirements EngineeringInterface Model

From Element :: Attribute Mapping rule (constraint) To Element :: Attribute

ProjectRequirementsFromJIRAToEA :: Action 

Mapping (Constraint) name: MappingActionTypeMapping type: OCLMapping rule: Action>0

Project Requirement :: Action  

ProjectRequirementsFromJIRAToEA :: Priority 

Mapping (Constraint) name: ProcessPriorityMapping type: ProcessMapping rule: If 1lowIf 2mediumIf 3highIf 4blocker

Project Requirement :: Priority  

ProjectRequirementsFromJIRAToEA :: Status 

Mapping (Constraint) name: StatusStrintToProjectRequirementStateMapping type: ProcessMapping rule: If ip'in progress'If start'started'If finished 'closed'if planned'scheduled'

Project Requirement :: Status  

ProjectRequirementsFromJIRAToEA :: Type 

Mapping (Constraint) name: MapTypeToRequirementTypeMapping type: ProcessMapping rule: if 1 ->USCif 2INTif 3BRUif 4NFRif 5SCRif 6REP

Project Requirement :: Type  

ProjectRequirementsFromJIRAToEA :: AuthorPID

Project Requirement :: AuthorPID

ProjectRequirementsFromJIRAToEA :: Description

  Project Requirement :: Description

ProjectRequirementsFromJIRAToEA :: Name

  Project Requirement :: Name

ProjectRequirementsFromJIRAToEA :: ProjectReqID

Project Requirement :: ProjectReqID

Mapping rules have to be added as constraints (OCL or Process) in the properties of the “InformationFlow”

Don’t use Business Rules for simple Mapping tasks!

Report automatically generates the mapping tables

Mapping table generated with standard report (REGRASP)

June 2013 17

Models in Model Based REInterface Model (Mappings)

You can bundle Requests, Iterations, Epics and Product Specifications WYSIWYG like in one diagram and generate a Business Specification that covers all Elements in the Diagram

You can also use Linked Documents to include additional text based information

With the Umbrella Paper Stereotype you add the diagram context

2. Drag and drop the elements to be represented in the REGRASP report from the Project Browser

4. Check the generated report.

3. Open Scripting View: View – Scripting and start the REGRASP script. Make shure that the diagram you want to generate the report of is active (otherwise you will get a missing object error)!!

1. Create new diagram – usually in the Projects area

REGRASP

June 2013 18

Models in Model Based Requirements EngineeringREGRASP (RE Graphical Specification)

Centrally provided script to show traceability to your CMMI assessor

Just select the Package and run the script

Excel report will be generated

Trace from Object Stereotype from Trace to ObjectStereotype to

Trace Status (ok/nok)

DAPTC-136 : Hug Day Epic (PackageID=2568) EPICJIRA_Epic ::DAPTC-1 : INT0002 Import Project Requirements (ProjectRequirement ID=10169) ProjectRequirement

INT0002 - Export Project Requirements from JIRA to EA(INT ID=10831) INT ok

::DAPTC-12 : USC0002 Manage Request (ProjectRequirement ID=10168) ProjectRequirement USC0002 Manage Request(USC ID=10723) USC ok ::DAPTC-124 : USC0090 Synchronize Defects between QC an JRA (ProjectRequirement ID=10172) ProjectRequirement

USC0090 Synchronize Defects between JIRA and QC(USC ID=10744) USC ok

::DAPTC-20 : USC0080 Define Iteration (ProjectRequirement ID=10170) ProjectRequirement USC0080 Define Iteration(USC ID=10669) USC ok ::DAPTC-21 : USC0081 Setup Tasks for Iteration (ProjectRequirement ID=10173) ProjectRequirement --- No trace available for respective Object!!! Please verify! not ok ::DAPTC-23 : USC0005 Synchronize Project Requirements (ProjectRequirement ID=10171) ProjectRequirement USC0005 Synchronize Project Requirements(USC ID=10792) USC ok ::DAPTC-23 : USC0005 Synchronize Project Requirements (ProjectRequirement ID=10171) ProjectRequirement

USC0001 Synchronize Project Epics and Requirements between JIRA and EA(USC ID=10691) USC ok

::DAPTC-24 : USC0004 Manage Project Requirement (ProjectRequirement ID=10164) ProjectRequirement USC0004 Manage Project Requirement(USC ID=10737) USC ok ::DAPTC-12 : USC0002 Manage Request (ProjectRequirement ID=10165) ProjectRequirement USC0002 Manage Request(USC ID=10723) USC ok ::DAPTC-20 : USC0080 Define Iteration (ProjectRequirement ID=10163) ProjectRequirement --- No trace available for respective Object!!! Please verify! not ok

June 2013 19

Models in Model Based Requirements EngineeringTraceability Report

SPR hosts artifacts that expose reuse potential like: Conceptual Interfaces, Base Types, Shared Processes spawning multiple applications and Shared Glossary

You can auto link the SPR into your product repository

June 2013 20

Shared Product Repository (SPR)Leverage your Reuse Potential

Well structured formalized content

Reuse of artifacts in various models and diagrams

Software Architects, Developers and Requirements Engineers work in the same environment

Transparency due to same structures in all areas

User friendly Base-Lining

All Stakeholder share the same project tree

Low effort synchronization due to simple meta model

Efficiency gain due to recognition – all repositories have the same base structure

June 2013 21

Model Based Requirements EngineeringBenefits

June 2013 21

Appendix

June 2013 23

Synchronization Meta Data Model – “Structure”Formal Rules Need to be simple and transparent to everyone

June 2013 24

Business Object ModelThe most important entities

QC Repository (Application Id)

JIRA: Project Pool

JIRA: AMITREQPOOL

EA Repository (Application Id)

Request

EPIC

Task/Subtask

Project Requirement: USC, NFR,

BRU, INT, SCR, REP,

BOM

Package

“ProjectRequirement”

Area:= UseCase

“ProjectRequirement”

Area:= ___

Folder

Project Requiremen

t

June 2013 25

Relationships of Project RequirementsOverview

Active Stakeholder Participation. Stakeholders should provide information in a timely manner, make decisions in a timely manner, and be as actively involved in the development process through the use of inclusive tools and techniques.

Architecture Envisioning. At the beginning of an agile project you will need to do some initial, high-level architectural modeling to identify a viable technical strategy for your solution.

Document Continuously. Write deliverable documentation throughout the lifecycle in parallel to the creation of the rest of the solution.

Document Late. Write deliverable documentation as late as possible, avoiding speculative ideas that are likely to change in favor of stable information.

Executable Specifications. Specify requirements in the form of executable “customer tests”, and your design as executable developer tests, instead of non-executable “static” documentation.

Iteration Modeling. At the beginning of each iteration you will do a bit of modeling as part of your iteration planning activities.

Just Barely Good Enough (JBGE) artifacts. A model or document needs to be sufficient for the situation at hand and no more.

June 2013 26

Model Based Requirements EngineeringWell Proven Practices (derived from Scott Ambler agile modeling)

Look Ahead Modeling. Sometimes requirements that are nearing the top of your priority stack are fairly complex, motivating you to invest some effort to explore them before they're popped off the top of the work item stack so as to reduce overall risk.

Model Storming. Throughout an iteration you will model storm on a just-in-time (JIT) basis for a few minutes to explore the details behind a requirement or to think through a design issue.

Multiple Views and Diagram. Each type of model representation has it's strengths and weaknesses. An effective developer/requirements engineer will need a range of models in their intellectual toolkit enabling them to apply the right model in the most appropriate manner for the situation at hand.

Prioritized Requirements. Agile teams implement requirements in priority order, as defined by their stakeholders, so as to provide the greatest return on investment (ROI) possible.

Requirements Envisioning. At the beginning of an agile project you will need to invest some time to identify the scope of the project and to create the initial prioritized stack of requirements.

Single Source Information. Strive to capture information in one place and one place only.

Test-Driven Design (TDD). Write a single test, either at the requirements or design level, and then just enough code to fulfill that test. TDD is a JIT approach to detailed requirements specification and a confirmatory approach to testing.

June 2013 27

Model Based Requirements EngineeringWell Proven Practices (derived from Scott Ambler agile modeling)

Embedded Agile Modeling: Modeling embedded as a discipline in an agile Application Lifecycle Management. Agile Modeling is as well a method stating principles to model in an agile way.

UML Unified Modeling Language

UML Profile – Extension mechanism for UML Elements. Key concepts are “Stereotyping” (stereotype defines an extended Element) and Tagged Values (custom attributes in your elements e.g. class, use case)

Software craftsmanship is an approach to software development that emphasizes the coding skills of the software developers themselves. It is a response by software developers to the perceived ills of the mainstream software industry, including the prioritization of financial concerns over developer accountability.

June 2013 28

Glossary