model based requirements engineering agile modeling in the software lifecycle june 20131
TRANSCRIPT
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 23
Synchronization Meta Data Model – “Structure”Formal Rules Need to be simple and transparent to everyone
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