BusinessRequirement of type Decision not shown properly in Element Properties

[mmontminy]

Hi,

I want to document Business Decisions. Those that have been approved as well as other in the process (Proposed, Validated, etc).

I created element of Stereotype=BusisnessRequirement with Element Type = Decision. In the Project Browser, List View or Specification Manager they are shown with the "diamond" icon and the type in the List View is "Decision". But in the Element Properties window, Type=BusinessRequiement??? If I click on the 3-dots (...) to Select  Element Type, Decision is already selected.

Is this a known problem? Am I doing something wrong?

Thanks for you help,

Martin

[KP]

I think a stereotyped Decision is a poor choice of element for documenting business decisions. A Decision node directs flow on an activity diagram (i.e. splits a control flow into two or more control flows based on a condition). Try a stereotyped Requirement instead.

[mmontminy]

In addition to the Stereotype "BusinessRequirement", I was using Element Type = Decision as a sub-type of BusinessRequirement. But I understand that is was a bad choice.

I guess one way to do what I want  would be to the other way around. Create a stereotype "BusinessDecision" of type requirement. I would like to differentiate Business Decision (and other types of decisions) from requirements. The difference can be subtle but can be important. Examples can be in the form "we will no longer offer so and so, from no on ...". It is not a requirement per say. Requirement would be derived from the decision.

Thanks for the heads up

[Shegit Brahm]

As I have only UML background, I disagree the idea that requirements would be derived from decisions.

In "my world" a decision is like what KP said: e.g. splitting up control flows based on conditions.

And a requirement tells what a system should / must do. Not how. This is done by e.g. Activity Diagrams.

So regarding your "business decisions" that is for me you document a process of what should be done.
Which results in requirements - the thing is: do model the process or the result?

Because for the process, I would have an (UML) activity that contains some actions.
One action element would have a control flow to the decision element which is named after your "business decision" (like: what would we do now?).
Follow up would be e.g. 2 actions: one says "keep it as it is", the other would say "change x" associated with an artifact "new requirement".

Just this "new requirement" would not be a requirement of the system the activity describes. For me it would be a requirement for a different system.

So I would have to find something else than the UML requirement & decision element for your case, I guess.

[Update:] Could you share a screenshot, please?

HTH, Shegit

[mmontminy]

Shegit,

First, I totally agree that using the Element Type "Decision" was a bad idea.

What I am talking about here are high level business decision often "executive" decision that you want to capture as such and then assess the impact on existing architecture and propose target architecture.

I work for a bank a here's a concrete example. Branches will be cashless (Executive business decision). This decision will impact existing requirements (use cases, functional, etc.),  processes(some will be changed, other removed and new one created), systems, infrastructure and more. We want to be able to trace back the changes to the decision that is at the root. It could also be use to give feedback to management of the impact of the decision before proceeding.

If you look at TOGAF content Metamodel , they are architecture requirement that can affect all architecture domain.

We are using Sparx E.A which is UML based but we use the Archimate profile as we are in Enterprise Architecture. Archimate has Motivation elements which include Requirement but it is not as rich as the extended requirements capability that E.A. provides.

I thought about creating a new stereotype extending the "BusinessRequirement" Stereotype but I'm trying to get by with what's out-of-the-box.

Martin

[Shegit Brahm]

Hi Martin,

cross reading your link points me back (& supports me) to my initial question:

Do you want to model the process of decisions made (might call it the decision finding system) or do you want to model the result (might call it the bank system)?

In both cases you need UseCases and requirements to describe the system.

Where is the difference? For what the system is used.

In first case:
You describe a requirements management tool (RMT). This tool is able to track down how a decision made regarding the "bank system" (BS).

In second case:
You describe the bank system (BS). This tool will be used by John Does, e.g. to do account transfers.

That means, that the requirements for the RMT reflect the business process, how decisions are made to create the BS.
While the requirements for the BS are these ones you describe as

This decision will impact existing requirements (use cases, functional, etc.),  processes(some will be changed, other removed and new one created), systems, infrastructure and more. We want to be able to trace back the changes to the decision that is at the root. It could also be use to give feedback to management of the impact of the decision before proceeding.

So as far as I understood/ assume: you have two systems: one is for tracking requirements that are the base for a system.

That means:

The usecase-requirements-description for the RMT contains the made decisions only as "artifacts to be stored properly". And it results in code, that is the RMT.

While the usecase-requirements-description for the BS contains e.g. account details as "artifacts to be stored properly". And it results in code, that is the BS.

And with a good requirements management tool you can do impact analysis, you can track down a system requirement to a stakeholder wish and also to a toplevel goal of the entire BS.
And you can use this RMT again to design the BS2 - independent from the further development of BS, just the process how to develop both BS is the same.

Coming back to your initial question: well, you want to model a RMT, which artifacts & database objects are used to create a BS - and to tell the developer of the BS how much impact a change in stakeholder requirements has.

Just don't mix requirements (for RMT) with requirements (for BS).

So a requirements manager would use the RMT to tell the bosses how the BS looks like.

Cheers, Shegit

Cheers, Shegit

[Glassboy]

I work for a bank a here's a concrete example. Branches will be cashless (Executive business decision). This decision will impact existing requirements (use cases, functional, etc.),  processes(some will be changed, other removed and new one created), systems, infrastructure and more. We want to be able to trace back the changes to the decision that is at the root. It could also be use to give feedback to management of the impact of the decision before proceeding.

Strictly speaking that is a business rule, the decision was deciding on the business rule.

If you look at TOGAF content Metamodel , they are architecture requirement that can affect all architecture domain.

We are using Sparx E.A which is UML based but we use the Archimate profile as we are in Enterprise Architecture. Archimate has Motivation elements which include Requirement but it is not as rich as the extended requirements capability that E.A. provides.

I thought about creating a new stereotype extending the "BusinessRequirement" Stereotype but I'm trying to get by with what's out-of-the-box.

You really need to decide whether you are implementing TOGAF with its ArchiMate notation or not.  If you don't actually want to use ArchiMate and you understand the meta-model behind what you need to model you are better to role your own UML profile (or MDG).

or if you don't have a look at the EBMM as different approach http://motivationmodel.com/ebmm/