Model Based Requirements Engineering

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

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

3. Model Based Requirements EngineeringA More Formal Approach to Structure Requirements • Regulation • Multiple Business Channels • Complex Business Interaction • Distributed Development • Cost Pressure • Business Rules going viral • Scattered information • Many models and documents • Disconnected artifacts • Complex application interaction • Increasing number of Test Cases ExternalForces Endemic Symptoms 1 2 Model Based Solution Applyprinciples • Repository based modeling tool • Shared Repository • Graphical Specification • Traceability • Standardized modeling method based on UML profiles • Reuse Models • Minimize communication efforts • Bring roles and activities together • ALM with Product Focus • Support Distributed Delivery Teams • Foster Standardization • Generate Documents 3 4

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)

5. Application Lifecycle ModelPart of Application Lifecycle Management (ALM) Testting JIRA Model Based Requirements Engineering (Enterprise Architect) Request in IT-AM Request Pool Project Requirement (Copy) Project Requirement (Copy) 1 4 Trace 4 Unidirectional Synchronization EPIC/Feature on JIRA Project Instance Trace Trace Unidirectional Synchronization Product Requirement Test Case 2 Trace 5 7 Product Requirement Trace Trace 3 Trace Test Defect Trace Bidirectional Synchronization 8 Test Defect Product Requirement (Copy) Caption: Step in ALM Process Synchronization Traceability 7 8 6 June 2013

6. ALM with Product FocusProjects Are Great – Products last longer June 2013

7. Requirements Management in JIRAPrioritize and Keep Track of Requirements • 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 June 2013

8. Synchronization of Requirements and ModelsComplicated Interactions Require Formal Rules June 2013

9. Separation of Product and Project ViewImplementation of the Product View • 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

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

11. Model Based Requirements EngineeringUML Profile Facilitate Implementation • UML Profile supporting all standardized artifacts • Reporting based on the UML Profile • UML Profile easily available in the Toolbox June 2013

12. Atomic Requirements and Simple ReportsDefine Once, Maintain Regularly, Reuse and Generate Often • Manage Product Requirements – choose the appropriate Atomic Requirement and document • Generate report with integrated templates Work out horizontal traceability in your various diagrams Define file name and select the corresponding template and generate Add relationships with the context menu Select artifact – press F8 to open RTF report generation dialog box June 2013

13. Model Based Requirements EngineeringMultitude of Different Traces Requirement Engineering (conceptual view) dBOM (Domain Base Types) Project Requirement Depending aBOM (Application Base Types) Product Req: UseCase (arch. relevant) Product Req: NFR (arch. relevant) Product Req: INT, Screen, Report… (non-arch. relevant) Realize Realize Realize Solution Architecture Realize Check-In Logical Datamodel Solution Arch: UseCase Realization Solution Arch: Deployment Architecture Solution Arch: Other Comp. e.g. Logical Interfaces/Jobs Realize Realize Realize Realize Software Engineering Physical Datamodel Comp Spec: Tech. UseCase Realization Comp Spec: Physical Comp. e.g. Physical Interfaces/.NET Classes etc. Source Code Uses Naming June 2013

14. Model based Requirements EngineeringTraceability in Enterprise Architect • Project Requirements synchronized with JIRA (Requests and Reqs) • Product Requirements are modeled in Enterprise Architect • Vertical Traceability (link Project Requirements to Product Requirements) Project Requirements automatically created (JIRA to EA synchronization) Establish vertical traceability with a trace arrow connecting the Project Requirement with the Product Requirement June 2013

15. Models in Model Based Requirements EngineeringBusiness Object Model • 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

16. Models in Model Based Requirements EngineeringInterface 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

17. Models in Model Based REInterface Model (Mappings) • 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

18. Models in Model Based Requirements EngineeringREGRASP (RE Graphical Specification) • 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 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)!! Check the generated report. Drag and drop the elements to be represented in the REGRASP report from the Project Browser Create new diagram – usually in the Projects area June 2013

19. Models in Model Based Requirements EngineeringTraceability Report • Centrally provided script to show traceability to your CMMI assessor • Just select the Package and run the script • Excel report will be generated June 2013

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

21. Model Based Requirements EngineeringBenefits • 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

22. 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 June 2013

25. Relationships of Project RequirementsOverview JIRA: AMITREQPOOL Request JIRA: Project Pool EA Repository (Application Id) QC Repository (Application Id) Package EPIC Folder “ProjectRequirement” Area:= UseCase Task/Subtask “ProjectRequirement” Area:= ___ Project Requirement Project Requirement: USC, NFR, BRU, INT, SCR, REP, BOM June 2013

26. Model Based Requirements EngineeringWell Proven Practices (derived from Scott Ambler agile modeling) • 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

27. 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

28. Glossary • 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