Requirements Management using MagicDraw

For something like this, I would suggest that keeping the requirements in their own, separate model is the best option. That way, the main system models can use whatever version is appropriate. So when a new baseline is available, simply "point" the other models at the new version.
Note that TeamWork Cloud supports branching, merging, and other management techniques that would support this effort

Now I'm going to ask the challenging question: Why not update the requirements instantly? Let's leverage the power of our tools and see things now rather than later. Example: physical requirement for length changes. Model automatically detects that our length value exceeds the limit. I can start fixing that NOW instead of not knowing until the next approved baseline is released.

Tim Weilkeins discusses variant modeling using custom stereotypes at https://mbse4u.com/2012/05/07/variant-modeling-with-sysml/. In characterizing an existing system with variants we have taken a similar approach using disjoint generalizations.

In reply to Robin Felix:

Robin
I second Mike's point of keeping them in a separate model if possible. Especially if you have a large number of them.

Also, NAVAIR is working with NAVWAR to develop a Requirements Profile for managing requirements in Magic Draw. It's still in development but they've made a ton of process over the last few months. I'd recommend reaching out to Barbara Lawson at barbara.d.lawson@navy.mil for more info. Not only is she developing this profile she's also a requirements expert and former DOORS instructor.

It really depends upon the magnitude of the scope -- how big is the model? how many requirements? how many baselines are you attempting to manage utilizing MagicDraw?

Either way, there a various pros and cons to either option -- Managing Requirements Directly within the System Model vs. Managing Requirements in a Large Model Split into Modules. I think the requirements sync goes a bit smoother if you elect to manage requirements in a larger model that's split into various modules (conceptual, logical, physical, etc). Having the requirements in a separate project but linked to the architecture allows you to manage versioning/baselines better without disturbing the holistic model in the event you need to revert changes. Not to mention, it should not prevent you or your team from working while conducting simultaneous syncs.

In reply to Monique Harris:

Thank You, My project is extremely large. We have 4 levels of requirements, which change or are updated on different schedules, that's a mess in and of itself. Currently we are just working on how to tackle this. We are currently investigating creating each Requirement level in a separate model, and then using the share project option to import model into the main model, that's easy part. It get more complicated when we start linking requirements.In any event we have just begun investigating this topic. I've been working something similar however it is a much smaller scale and not as complicated. In this model we only have two baselines however we have requirement traced/relationships (in some fashion) to source (higher level requirements), test events, risk, functions, systems, Baselines. Through these relationships we were able to create a Test Evaluation Matrix which is very powerful. We've also been able to produce project documents using scripts and macros.

I've received some good information, please keep posting your thoughts, it will assist everyone.

In reply to David Fields:

While not germane to the original question of requirements variants, it may be of interest to some that we are using Jama as our requirements manager, bringing the set of Jama requirements into a separate Cameo model as Mike suggests. The requirements model is then a project usage for traceability of requirements within the operational, functional, and system Cameo models.

We have been using Syndeia now for a couple of years for that linkage, but Syndeia continues to lag behind its feature promises. Specifically, it is not enabling full exchange with Cameo of the relationships kept within Jama. As a result, we're investigating TaskTop as a more mature requirements integration tool between Jama and Cameo.

As an additional comment, I'd encourage you to work on REDUCING the number of text-based requirements or at least deferring their creation until they are supported by appropriate analysis. I believe at lot of the churn and baselines are related to version controlling text descriptions that shouldn't even exist at that point in time.
When I hear that there are four levels of requirements all changing at varying rates that is a leading indicator of this problem.

Seemingly absent from the discussion is the extent of rigor required of your Requirements Management Process. Are you familiar with the IREB's (International Requirements Engineering Board) Requirements Management Handbook? If not, then you might consider reading it, it is free. Perhaps your required rigor is not so demanding as IREB's can be.

I would argue that Magic Draw and its derivatives are not well suited to implement a comprehensive requirements management process where we manage requirement versions at the atomic level (i.e., requirement model element vs. model), implement a change request and management process, and can provide change history reports throughout the system's life cycle. To cite just a few of the essential sub-process / activity elements of a comprehensive requirements management process.

I'm not saying it can't be done, I'm just uncertain that the required resource investment will pay a dividend. Many activities of a rigorous requirements management process are outside of the intended scope of both the SysML language and modeling tooling. These systems / services were never intended to solve the problems / address the needs of a comprehensive requirements management process.

All that said, I concur with Micheal V's opinion regarding a model reserved for requirements. Requirement baselines will, typically, be managed independently from the related system architecture description baselines. I believe we should decouple the version identity of the different baselines (IMHO). I may very well be proven wrong! I'm open to the discussion.

Best of Luck