Model Based Requirements Engineering


Case Study - Model Based Requirements Engineering based on JIRA Structure Plugin and Enterprise Architect

©Gregor Gisler Project Manager, Business Analyst

Content

- The Problem and the Solution Summary

- The Workflow

- A More Formal Approach to Structure Requirements

- Guiding Principles

- Part of Application Lifecycle Management (ALM)

- Projects Are Great but 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 as artifact of the Requirements Engineering Driven Modelling

- Interface Model (incl. Mapping to BOM)

- REGRASP (RE Graphical Specification)

- Traceability Report

- Leverage the method and improve the Reuse Potential

- Model Driven Requirements Engineering Benefits

- Appendix

The Problem

A More Formal Approach to Structuring Requirements offers more transparency over time - see also Agile Modeling by Scott Ambler. Most of the Requirements are although structured formally in a unmature state. Model Based Requirements Engineering offers a way to separate the Project view from the Product view and enabling teams to have the full functionality in a conceptual view. Interfaces for example are mapped to the BOM these conceptual mappings are available in a way that even a mature Meta Data Management system can consume them.

The development cycle is supported by several integrated solutions used for requirements management, software architecture and design, testing and quality management.

Problem and Solution - Summary

With the introduction of Agile lifecycle model, the company needed a tool to support it and chose Atlassian JIRA with GreenHopper to do the job. However, JIRA and GreenHopper did not allow to conveniently organize and view the full hierarchical range of the company's book of work, which was important for strategic backlog prioritizing, program management over multiple teams, project tracking and reporting.

Structure plugin was chosen to provide this missing functionality and now the company uses several structures for Business, IT-Management, Project Teams and Quality Management. The Requirements are then automatically synchronized with Enterprise Architect and the Test Management System.

Traditional Requirements Engineering and its problems

Picture 1. Why do we need a more Formal Approach to Structure Requirements?

The Workflow

The company's development process is quite typical for organizations with an internal development department serving the company's needs. Business Partners add their Requests to a JIRA-based central request management system and they are prioritized in a joint effort between Business and IT.

As soon as a Request is scheduled, it is in the hands of the development teams. Each Request can be implemented by several Epics from different projects and these Epics are linked to the Request via Feature link type.

Epics are assigned to different teams and each team may be working on Epics from different projects(there are about 30-40 different projects). Each Epic is broken down into Stories (and its Requirements), Tasks, and Sub-Tasks, and may have a number of related tests and bugs.

     

  • Issue types: Request, Epic, Story, Task, Sub-task, Requirement, Bug..

  • Issue links: Feature (Epics are linked to Requests).

  • Statuses: New, Analysed, Scheduled and other

 

Guiding Principles for agile modeling

Guiding Principles for agile modeling

Table 2. Guiding Principles

 

Part of Application Lifecycle Management (ALM)

Requirements Engineering, Design and Testing artifacts.

Artifacts per Environment

Picture 2. Artifacts per Environment.

 

Projects Are Great but Products last longer

Artifacts per Environment

Picture 3. Multi Projects and Support of various Applications from a single Request Repository.

 

Prioritize and Keep Track of Requirements

Artifacts per Environment

Table 2. Requirements overview.

 

Global Structure

Picture 4. Structure Plugin.

 

Complicated Interactions Require Formal Rules

Artifacts per Environment

Picture 5. Meta Data to capture process - complicated interactions require Formal Rules.

 

Implementation of the Product View and theGenerated Artifacts

Artifacts per Environment

Table 3. Separation of Project view and Product view.

 

Artifacts per Environment

Picture 6. Overview of generated Artifacts.

 

UML Profiles Facilitate Implementation

Artifacts per Environment

Picture 7. UML Profile Facilitate Implementation.

 

Define Once, Maintain Regularly, Reuse and Generate Often

Atomic Requirements and Simple Reports

Picture 8. Atomic Requirements and Simple Reports - Define Once, Maintain Regularly, Reuse and Generate Often.

 

Multitude of Different Traces - Traceability in Enterprise Architect

Artifacts per Environment

Picture 9. Multitude of Different Traces.

 

Artifacts per Environment

Picture 10. Traceability in Enterprise Architect.

 

Business Object Model as artifact of the Requirements Engineering Driven Modelling

Artifacts per Environment

Picture 11. UML BOM Modeling.

 

Interface Model (incl. Mapping to BOM)

Artifacts per Environment

Picture 12. Interface Model - Interaction with the BOM.

 

Interface Model with Mapping

Picture 13. Interface Model with Mapping to BOM - Transformation rules incoming and outgoing.

 

REGRASP (RE Graphical Specification)

Requirements Graphical Specification

Picture 14. REGRASP - Requirements Engineering Graphical Specification - Based on Diagrams

 

Traceability Report

Traceability Report

Picture 15. Traceability Report.

 

Leverage the method and improve the Reuse Potential

Artifacts per Environment

Picture 16. Shared Product Repository for reuse of shared artifacts.

 

Model Driven Requirements Engineering Benefits

Artifacts per Environment

Table 4. Benefits of Model Driven Requirements Engineering

 

The Solution in Detail

The global structure lists all Requests with status New, Analysed and Scheduled with their related Epics, Tasks, Requirements andBugs. This structure is mainly used for prioritization and progress overview.

The Project related Requirements are attached to the stories which is compliant with Scott Ambler's approach. In SPARX Enterprise Architect you see the Project (changing view) and the more stable Product View. The Project Requirements trace to the Product View and is transparent to all users.

Starting with the Requests, Business and IT-Management can now drill down to all related Epics, Stories and the related Requirements. Traceabiliy is at hand for everybody. Additionally REGRASP offers the Delta (Project Requirements) and the Full (Product Requirements) view in one report. Making it easier for Developers and Testers to identify the changes to an existing product.

     

  • With Structure Plugin build up your Project, Programs and Requirements Tree

  • The Requirements hierarchy is synchronized with a BPM Engine to Enterprise Architect or another modelling tool and to your test managment infrastructure.

  • The whole tree is transparent and versioned over the whole life-cycle. Due to Product view - specification takes place exactly at one place.

 

Global Structure

Picture 17 Request overview with derived EPICS and Stories to be implemented from various Project Teams - linking into the Structure by synchronizing their Team JIRA to various Requests. A team therefore is Multi Project and Multi Product capable in a transparen fashion. Note the aggregated progress and issues being combined from different projects.

This structure has a number of synchronizers, which ensure that the structure is up to date.

  • At the top level there is a filter synchronizer that adds to the structure all active Requests from the Request Pool.

  • After that, a Sub-Tasks synchronizer adds Sub-Tasks related to Requests.

  • The Epics are automatically added under the Requests by a Links synchronizer, when a link between the Request and the Epic is created.

  • The GreenHopper synchronizer takes care of the Stories belonging to the Epics, updating their Epic/Theme field.

  • The resulting structure provides the full picture of issues existing in the company JIRA and allows users to quickly see the relationships between all issues and progress for each Request.

    Using Different Structures

    Apart from the global structure, different departments have their own structures.

    Quality Assurance team has a structure, which provides a single view for tracking the progress of all quality-related tasks. The structure is periodically exported into Excel for further usage in the QA process.

    Project teams use structures to create risk views, WBS (work breakdown structures) and risk reports.

    With custom integrations, developed in-house, the company integrated JIRA/Structure with other applications in the Tool Chain - SPARX Enterprise Architect and HP Quality Center. So now their teams always look at the same structures of Epics and Requests, be it in JIRA, EA or QC.

    Do Requirements Elictation in JIRA and Requirments Engineering (Modelling) in SPARX Enterprise Architect.

    Apart from the global structure, different departments have their own structures.

    Requirements Engineering has all Project Requirements available in the corresponding Structure. The Analysis is done in Enterprise Architect. Traceability is maintained semi automatically as the machine can't guess every trace (especially when the naming conventions are breached). The traceability report shows every missing trace to an artifact.

    Quality Assurance team has a structure, which provides a single view for tracking the progress of all quality-related tasks. The structure is periodically exported into Excel for further usage in the QA process.

    Project teams use structures to create risk views, WBS (work breakdown structures) and risk reports.

    With custom integrations, developed in-house, the company integrated JIRA/Structure with other applications in the Tool Chain - SPARX Enterprise Architect and HP Quality Center. So now their teams always look at the same structures of Requests, Epics and Stories, be it in JIRA, Enterprise Architect, Eclipse, Visual Studio or QC. Furthermore this is all linked to the continuous build environment.

    In Conclusion

    The approach is fairly simple. Structure Plugin offers you a lot of possibilities. Important is to have a smart UML Profile in place that is stable. Meta Model changes in SPARX Enterprise Architect can be done but there is always Scripting on the database and on the EA repository involved. With a big number of Projects this can become elaborate. The advantage to have the same view (structure) in every tool makes it much easier to communicate over any specialist barriers. One final word to BPM. Use a good open source BPM engine. Be it Stardust, Camunda or anything else that is suitable (don't go for BPEL - the formal limitations are to big). With Eclipse Stardust you can use Apache Camel endpoints. There with Publish Subscribe in place you won't run into Performance Issues too early!

    ©Gregor Gisler-Merz

     

    View Gregor Gisler-Merz's LinkedIn profileView Gregor Gisler-Merz's profile