Run requirements analyses with your own medium

With objectiF RPM, you can individually expand the model-based requirements analysis that is offered. The key is defining your own stereotypes. Then you can give model elements new or changed meaning. If you are well-versed in UML, then you know this expansion technique. In objectiF RPM you can use many artifacts, not just UML. You can see how that works in the example of the system context diagram.

How can the medium for requirements analysis be expanded?

The first stumbling block lies right at the start of the path through requirements engineering: if you don’t understand the context of the planned system, then important features and interfaces will probably be missing at the end.

Right when no one had spoken of requirements engineering or business analysis and was still doing system analyses, the context diagram was known in the framework of the structured analysis according to DeMarco. The diagram shows the external interfaces of the planned system and the flow of information between them.

Anforderungsanalyse mit klassischem Informationsflussdiagramm für den Systemkontext, erstellt mit case/4/0

Requirements analyssis with classic information flow diagram for the system context, created with case/4/0

In objectiF RPM you have three possibilities of modelling the system context.

  • For technical systems, the block diagram of SysML is often the recommended instrument.
  • If you automate processes, then UML use case diagrams are the most used means for context modelling.
  • And then there is another all-rounder that comes pretty close to the classic context diagram: the system context diagram.

And we’re going to look at it in more detail…

System context diagrams with objectiF RPM

With objectiF RPM you can map the following in a system context diagram:

  • the planned system (As a box of the stereotype «PlannedSystem»),
  • People who interact with the system (as «Actor»),
  • System context elements, that means systems, processes or events in the environment of the planned system and exchange information with it, i.e., influence it.  (presented as red-framed boxes of the stereotype «SystemContextElement»),
  • Rules, that means laws, standards or documents that have an influence on the system (yellow framed boxes of the stereotype «SystemContextRule»),
  • System context elements or rules that are recognized as irrelevant for the system (grey framed boxes)

That corresponds to this classification of the “world”:

Systemkontext mit Abgrenzung

System context with demarcation

How such a diagram looks and what can be done if you don’t get along with the stereotype «SystemContextElement» can be seen in this short film:

Do you also want to use your own mediums for requirements analysis? Please get in touch with us, we would be glad to support you!

What makes a successful Project Management process? How do I find the right business process? Which methods are useful? A graduate mathematician and co-founder of microTOOL, Ursula Meseberg is Managing Director of the company alongside Bernd Nawrot. She is fascinated with current trends and has made a name for herself as an author of professional articles.

0 replies

This discussion is missing your voice.

Leave a Reply

Your email address will not be published. Required fields are marked *