Presentation is loading. Please wait.

Presentation is loading. Please wait.

Model Based Requirements Engineering Agile Modeling in the Software Lifecycle June 20131.

Similar presentations

Presentation on theme: "Model Based Requirements Engineering Agile Modeling in the Software Lifecycle June 20131."— Presentation transcript:

1 Model Based Requirements Engineering Agile Modeling in the Software Lifecycle June 20131

2 2 Model Based Requirements Engineering Content 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

3 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 3 4 Model Based Requirements Engineering A More Formal Approach to Structure Requirements

4 June 20134 Model Based Requirements Engineering Guiding 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)

5 TesttingModel 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 Unidirectional Synchronizati on Bidirectional Synchronizati on Unidirectional Synchronizati on Caption: Step in ALM Process Synchronization Traceability 7 Trace Application Lifecycle Model Part of Application Lifecycle Management (ALM) June 20135

6 ALM with Product Focus Projects Are Great – Products last longer June 20136

7 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 JIRA Prioritize and Keep Track of Requirements June 20137

8 8 Synchronization of Requirements and Models Complicated Interactions Require Formal Rules

9 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 20139 Separation of Product and Project View Implementation of the Product View

10 Enterprise Architect Project Requirement (Copy) Design Element Product Requirement Code Requirements Engineering Documentation), Release Specific Documents Architecture Documentation Analysis/Design Documents Build and Deployment artifacts Requirements Engineering Work Product Solution Engineering Work Product Legend Visual Studio Database SVN, GIT TeamCity IDE or CBI Generated Component Naming June 201310 Enterprise Architect – Product View Overview of Generated Artifacts

11 UML Profile supporting all standardized artifacts Reporting based on the UML Profile UML Profile easily available in the Toolbox June 201311 Model Based Requirements Engineering UML Profile Facilitate Implementation

12 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 June 201312 Atomic Requirements and Simple Reports Define Once, Maintain Regularly, Reuse and Generate Often

13 Requirement Engineering (conceptual view) dBOM (Domain Base Types) Solution Architecture Software Engineering Logical DatamodelSolution 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 DatamodelComp Spec: Tech. UseCase Realization Comp Spec: Physical Comp. e.g. Physical Interfaces/.NET Classes etc. Realiz e Depending Check-In NamingUses June 201313 Model Based Requirements Engineering Multitude of Different Traces

14 Project Requirements automatically created (JIRA to EA synchronization) Establish vertical traceability with 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 201314 Model based Requirements Engineering Traceability in Enterprise Architect

15 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 201315 Models in Model Based Requirements Engineering Business Object Model

16 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 201316 Models in Model Based Requirements Engineering Interface Model

17 From Element :: AttributeMapping rule (constraint)To Element :: Attribute ProjectRequirementsFromJIRAToE A :: Action Mapping (Constraint) name: MappingActionType Mapping type: OCL Mapping rule: Action>0 Project Requirement :: Action ProjectRequirementsFromJIRAToE A :: Priority Mapping (Constraint) name: ProcessPriority Mapping type: Process Mapping rule: If 1low If 2medium If 3high If 4blocker Project Requirement :: Priority ProjectRequirementsFromJIRAToE A :: Status Mapping (Constraint) name: StatusStrintToProjectRequirementS tate Mapping type: Process Mapping rule: If ip'in progress' If start'started' If finished 'closed' if planned'scheduled' Project Requirement :: Status ProjectRequirementsFromJIRAToE A :: Type Mapping (Constraint) name: MapTypeToRequirementType Mapping type: Process Mapping rule: if 1 ->USC if 2INT if 3BRU if 4NFR if 5SCR if 6REP Project Requirement :: Type ProjectRequirementsFromJIRAToE A :: AuthorPID Project Requirement :: AuthorPID ProjectRequirementsFromJIRAToE A :: Description Project Requirement :: Description ProjectRequirementsFromJIRAToE A :: Name Project Requirement :: Name ProjectRequirementsFromJIRAToE A :: 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 201317 Models in Model Based RE Interface Model (Mappings)

18 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 June 201318 Models in Model Based Requirements Engineering REGRASP (RE Graphical Specification)

19 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 ObjectStereotype fromTrace to Object Stereoty pe 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)INTok ::DAPTC-12 : USC0002 Manage Request (ProjectRequirement ID=10168)ProjectRequirementUSC0002 Manage Request(USC ID=10723)USCok ::DAPTC-124 : USC0090 Synchronize Defects between QC an JRA (ProjectRequirement ID=10172)ProjectRequirement USC0090 Synchronize Defects between JIRA and QC(USC ID=10744)USCok ::DAPTC-20 : USC0080 Define Iteration (ProjectRequirement ID=10170)ProjectRequirementUSC0080 Define Iteration(USC ID=10669)USCok ::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)ProjectRequirementUSC0005 Synchronize Project Requirements(USC ID=10792)USCok ::DAPTC-23 : USC0005 Synchronize Project Requirements (ProjectRequirement ID=10171)ProjectRequirement USC0001 Synchronize Project Epics and Requirements between JIRA and EA(USC ID=10691)USCok ::DAPTC-24 : USC0004 Manage Project Requirement (ProjectRequirement ID=10164)ProjectRequirementUSC0004 Manage Project Requirement(USC ID=10737)USCok ::DAPTC-12 : USC0002 Manage Request (ProjectRequirement ID=10165)ProjectRequirementUSC0002 Manage Request(USC ID=10723)USCok ::DAPTC-20 : USC0080 Define Iteration (ProjectRequirement ID=10163)ProjectRequirement--- No trace available for respective Object!!! Please verify!not ok June 201319 Models in Model Based Requirements Engineering Traceability Report

20 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 201320 Shared Product Repository (SPR) Leverage your Reuse Potential

21 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 201321 Model Based Requirements Engineering Benefits

22 June 201321 Appendix

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

24 June 201324 Business Object Model The most important entities

25 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 Requirement June 201325 Relationships of Project Requirements Overview

26 Active Stakeholder ParticipationActive 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.inclusive tools and techniques Architecture EnvisioningArchitecture 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 ContinuouslyDocument Continuously. Write deliverable documentation throughout the lifecycle in parallel to the creation of the rest of the solution. Document LateDocument Late. Write deliverable documentation as late as possible, avoiding speculative ideas that are likely to change in favor of stable information. Executable SpecificationsExecutable Specifications. Specify requirements in the form of executable “customer tests”, and your design as executable developer tests, instead of non-executable “static” documentation.customer tests Iteration ModelingIteration 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) artifactsJust Barely Good Enough (JBGE) artifacts. A model or document needs to be sufficient for the situation at hand and no more. June 201326 Model Based Requirements Engineering Well Proven Practices (derived from Scott Ambler agile modeling)

27 Look Ahead ModelingLook 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.priority stack Model StormingModel 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 RequirementsPrioritized 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 EnvisioningRequirements 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.prioritized stack of requirements Single Source InformationSingle Source Information. Strive to capture information in one place and one place only. Test-Driven Design (TDD)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 201327 Model Based Requirements Engineering Well Proven Practices (derived from Scott Ambler agile modeling)

28 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 201328 Glossary

Download ppt "Model Based Requirements Engineering Agile Modeling in the Software Lifecycle June 20131."

Similar presentations

Ads by Google