In product management, there are always questions to be answered about goals and the requirements derived from them for a new product or a new release. There are use cases to discover, to understand and to detail. But what if you don’t want to limit yourself to the documentation of the technical model, but also want to answer these essential questions:
- Which program features are there and how are they organized into domains?
- Which features will be used in which of the business’s products, which ones have optional characters?
Do you want to get to know a good tool for your product management? Then check out objectiF RM!
objectiF RM as a tool for your product management
ObjectiF RM is a tool for managing requirements. It offers you diverse ways to collect and structure information for your product management. If you like, you can differentiate between four abstraction levels in objectiF RM that correspond to organizational roles at the same time: Professional modelling: At this level, the requirements engineering takes place. The results, consisting mainly of requirements cases, requirements, activity diagrams, and so on, will be organized into individual features in objectiF RM. Product management: Here, domains are modelled with their allocated features. Domains can be organized into any sub-domains. Through this, regardless of the actual products, it becomes transparent which feature areas of the business have been covered so far. As the second essential task, the product management manages the features of each individual product of the business. (Business) management: For the management of the business, it should be clear a) which products with which features are available and b) which use areas have already been covered by the business. For that, goal diagrams are created to map current and future goals as well as potential goal conflicts. Technical modelling: Designers and developers use all the information of previous levels and refinements, i.e., detailling the models. The expert requirements are refined into technical requirements. Class diagrams are modelled for the identified business entities and refined activity diagrams are created. Of course, developers also need information about how features in domains and products should be organized. How does the structure of the levels look? The technical model is presented on a right angle to the other levels, because it uses information from the other levels and details them further.
How can we implement them concretely in objectiF RM?
To model products, domains and features, blocks of the SysML diagrams are offered. For the first step we will expand the stereotype «Block» with the following sub-types.
That’s how the domains will be modelled with their structure. We will make it clear now with a concrete example. Here I will use the demonstration template of a mobile patient information system (moPATIS) In this context you can see a domain for the patient management like this:
The organization of features in products can be exemplarily displayed so that potential optional specifications in products can be described through the multiplicity.
The technique to refine stereotypes can also be used to differentiate between concrete goals for a release/product and future/planned goals. All relevant roles for a business’s product development work in a unique area and profit from the transparency. That way management has an overview of how the product management plans and organizes products. Developers can see directly what the current and planned goals of the business are. Every role has its own perspective.
How can the views be organized in objectiF RM?
And above all: how can, for example, individual requirements be left out of the management view, because they have no relevance from management’s perspective? That’s why we defined the user profiles according to the above mentioned levels:
Individual profiles can then be adapted. For example, to define that management shouldn’t see individual requirements and use cases, the following stereotype will be filtered:
The available commands in the product browser can be limited. The management doesn’t have to, for example, create new block diagrams. So management also doesn’t need the corresponding menu command.
Do you have questions or remarks about the implementation of objectiF RM for product management? Then I look forward to your message!