Extending the Requirement Type

By J D Baker Sparx Systems Ambassador

An MDG Technology for adding attributes to manage requirements for systems and software engineering projects.
Because UML does not define a requirement element type, Enterprise Architect includes one in the Core Extensions set of elements. SysML includes a requirement element type that expands the EA type with two attributes. In the Guide for Writing Requirements, the INCOSE Requirements Working Group has defined a further expansion of the numbers and types of attributes that need to be considered in requirements engineering. In the software arena, Karl Wiegers has written extensively about software requirements and what you need to know about them. This presentation describes an MDG Technology that addresses the INCOSE recommendations and maps them to Wiegers' recommendations for attributes to capture about your requirements. We will explore both the creation and the use of the extended requirement elements.

Session Recording

Downloads

Summit Req MDG (PDF)
Summit Req MDG Notes (PDF)

Questions and Answers

My suggestion is to do two things. First flag them somehow, either using a status such as Suresh has suggested or a Deleted tag with Yes/No values. Second, moving them into a separate package made sense for our project.
For the most part I don't see a need for lists and styles in my requirement statements. In what the INCOSE Requirements guide calls requirement expressions (statements plus attributes, etc.) the formatting becomes a function of document generation.
I had to make an Add-in for this purpose. Works pretty well, but maybe, there is some more clever approach. Personally, I am interested in maintaining correct prefixes and uniqueness within that namespace like "F-nnn", "B-nnn"
Versioning is two problems. If it is a block of requirements, then cloning the block works ok in conjunction with setting a package Baseline. For individual elements, the Time Aware modeling offers some help https://www.sparxsystems.com/enterprise_architect_user_guide/15.1/model_domains/time_aware_models.html.
Also, TAM is a promising concept, however please evaluate what your plans are when it comes to reconciliation, or compare / merge with existing requirements. Baselines, are good ways to keep track of requirement versions, however if you intend to have a branch / copy of requirements as they are been developed and plan to merge and reconcile, i would suggest Baselines (Especially with 15..1 where you have ability to connect Baselines to a shared repository) or RAS.
A short video (not fancy) that I did to showcase RAS and baselines for one of our clients
https://youtu.be/XnLFBoloKAc

Speaker Bio

eaglobalsummit-ian-mitchell

J D Baker

Sparx Systems Ambassador