Skip to main content

Last few months I have been working with USoft Studio a lot to get to understand and at the same time capture the business rules for one of our customers. Within USoft Studio, we use the Semantics for Business Vocabulary and Rules (SBVR) and standard techniques to create diagrams for object-fact modelling (SBVR diagrams), process flows (BPMN 2.0) and/or database modelling (ER diagrams). There are a lot of manuals available on these topics, but when working with USoft Studio I got some real hands-on experience, which might help you all as well. This short article aims to give you tips to work with USoft Studio as efficiently as possible, based on my personal experience.

Tip 1. Do not try to define the entire galaxy

When defining a set of rules, a pitfall is that you try to define everything. Definitions will result in a nice green term noun concept to indicate you have defined what you mean with it. This “reward” makes you want to get more and more green terms, which is a good thing, but somewhere you need to stop defining nouns because otherwise readers will get lost in a green forest of definitions that are not necessarily informative.

For example, you define something like: “A passenger is a person buying a ticket”. Now “passenger” will turn green because you defined what it is in your project. Some items become red, which means they are probably not that important. And some items remain black. This means they are undefined. In this case, “ticket” will be undefined. Now the decision comes. You only need to define the noun “ticket” if there can be some misunderstanding about what you mean with it, or if it is something totally different than one may expect. “A ticket is a proof for accessing our means of transport” might not be that useful because this is a quite general definition. Next step would then be defining means of transport, so you end up defining a plane, a train, a rocket and before you know it you are defining planets and therefore the galaxy. The definition “A ticket is a digital means to prove the right to access planes, which is sent to a customer by email“, is a lot more useful. It defines a lot more: it is digital, it is meant for accessing planes and, it is sent by email. And probably there is no need to define email, but defining customer probably is very useful. Email is generic, but when is a person a customer for your organization?

Tip 2. Get some blue terms in there

When you start defining nouns you will end up with a lot of green, black, and red words in your set of rules (the vocabulary). This is very good of course, but when you start defining relations between terms, the use of your vocabulary for creating software will improve. A relation is indicated as a blue term. An example is “customers own tickets”. When customers and tickets are defined noun concepts, the word “own” will become blue to indicate the relation between the two objects. Based on this you can also draw the SBVR, BPMN and/or E/R diagrams describing the relations between the different objects. This will help a technical consultant understand the object modelling and based on that create a database model quite easily. To learn more about this, study the “fact model” help and you will be able to get things done.

Tip 3. Study the sentence patterns help document

If you are a bit like me, you probably skip reading help and just start right away. USoft Studio will classify all sentences based on used patterns. Definitions, necessities, possibilities, locations, categories, … all kinds of useful classifications. For example, a … is a … will result in a definition. When you just start, you will end up with a lot of “other” classifications. This is not all bad but probably, by using the right way of writing things down, you will end up with a better-defined vocabulary of rules.

Tip 4. Don’t bother organizing rules at the start

Often, I find myself busy organizing information. And in USoft Studio you can do the same. You can organize by the following ways:

  • by business area,
  • by business object,
  • by rule set,
  • by rule number,
  • or organize by fact model.

This is super neat and will help you define the areas where certain rules are available for, but when you begin, just start entering information. By clicking on green and blue terms, Studio will show you the rules you have defined for certain areas, objects or sets right away, without any other organization added. They are linked by the terms used. This is the nicest way to learn about the information you need to know, and it saves time not having to organize anything yourself. As said, you can group and organize in a lot of ways, and sometimes this is useful. But consider these other ways as secondary, unless and until you experience a real need for them.

Tip 5. Some smaller tricks

If you have used the proper way of defining rules, you will have all kinds of differently classified rules. The dashboard pie-chart shows exactly how many rules of what type you have defined. And although this does not give you all information, it will show you immediately how you are doing and what (probably) needs to be done. Also, nice to know up front is that you can easily link rules to each other. Just add a # in front of the ID of the rule and Studio will create a hyperlink after submitting it. Finally, add notes. If you click on the arrow icon next to the “Add” button, you will get the “Add Detail” option which allows you to add notes or hints for implementation. This text will not be analyzed by the language engine but is very useful for later understanding and/or implementation.

 

I hope you find this useful and thanks for reading. I am confident that after some time, you will find it a useful addition to Jira stories and functional documents in Word. Good luck!

Be the first to reply!

Reply