The perfect review of features

Stakeholders pursue goals. Often, these goals derive from business goals and have strategic characters. For teams that develop software or systems, most of these goals are too vague to lead to concrete actions and solutions. The task of requirements engineering is to refine these goals into concrete, implementable refinements, to be able to derive features from them. The key to deriving features is the question for the stakeholders: What does the system under development have to be able to do in order to achieve the specified goals? It is not always easy for the stakeholders to give a direct answer. All the more important, then, is the review of features.

Criteria for assessing features

Even if we are dealing with feature requirements of a high professional level, they should already fulfil a range of quality criteria. Here is a checklist that you can use for the assessment of features:

1. Does every feature have at least one source? Are all interested stakeholders identified?
2. Are the features complete, do they cover the stakeholders’ goals and can they be traced back to goals or use cases?
3. Are the features understandably and clearly formed? Does the formulation allow interpretations? If you have followed the rules for the traditional description of features that should hardly be the case. Then you have made a large step in the direction of clarity.
4. Are the features correct? Do they reflect what the stakeholders want?
5. Are the features free of contradiction, consistent?
6. Are the features current and do they reflect the desires of the stakeholders as before?

These questions can all be clarified most quickly in one or multiple meetings with the stakeholders. But to get all stakeholders to one table for one or even more review meetings is not always possible in large and distributed organizations. Or it requires a lot of effort that will not get the okay from management nor from the potential participants. An alternative is available here: mechanical reviews. The advantages for the stakeholders is obvious: they can carry out the reviews – ideally with a browser-based software – whenever they find time for it, wherever they have internet access.

Advantages of mechanical reviews

You have no chance of getting all the stakeholders at one table for a review in your project? Then you can formalize reviews of the defined features with a tool like objectiF RPM, for example. Mechanical (more precisely: machine-supported) reviews are, at their core, workflows that work according to fixed rules. The similar procedure of mechanical reviews is, however, not their only advantage. Others are:

• They don’t cost administrative overhead: no reservation of rooms, no appointment coordination and – especially in distributed organizations – no travel time,
• The stakeholders can carry out a review in the framework of the defined expiry whenever they find time,
• The reviews are more binding through written comments from the stakeholders than through the oral transmission of review meetings,
• The comments and therefore the reviews are traceable,
• Reviews are artifacts from a tool point of view that can be evaluated. That way you can, for example, list the reviews in which you personally will take part or have taken part. Or you can create a list of all requirements with the associated reviews and their current states.

The following technique can not only be used for features. Mechanical reviews can also be created and carried out for the following elements:

• Requirements – regardless of their stereotype
• Use cases
• Documents
• Element groups

We recommend differentiating between three roles for mechanical reviews:

• The organizer of a review,
• The reviewer who carries out the assessment of the submitted element,
• The author who created the test article and has to improve it if necessary.

The organization of mechanical reviews

As an organizer, you are responsible for creating reviews:

• Create (at least) one review for each element to be examined.
• Describe its goal.
• Determine an expiry date.
• Confirm the involved reviewer and transfer the review to the state “ready”.

A quick tip: we assume that the elements to be examined are completely described and are therefore in the state “defined”. But one can also take the stance that the feature is only completely defined when the description is closed and reviews to assess the description are completely defined. If you share this opinion, then keep a feature in the state “in definition” until all necessary reviews have been created. Then trigger the event “definition complete,” the feature will then transfer into “defined” and all the planned reviews change states automatically from “planned” to “ready”.

The execution of mechanical reviews

From the perspective of a reviewer, the following questions are posed:

• What does it mean to execute a mechanical review?
• How can the review results be kept traceable?
• What does the workflow of a review fundamentally look like?
• How can I start with the assessment?

We will approach the answer successively as follows:

What does it mean to execute a mechanical review? A mechanical review means that every project employee who is allocated to the review as a reviewer has to critically acknowledge the description of the test article. The goal-setting provides the orientation that the organizer has formulated at the creation of the review.

How can one keep review results completely traceable? Knowledge, questions, positive or critical remarks, so the results of the examination are collected together in a review comment by the reviewer.

How does the workflow of a review foundationally look? As soon as a review finds itself in the state “ready”, the reviewer has to enter review comments. When they start doing so, the review will be in the state “in realization”. After the reviewer has completely entered the comments, they have to get to the heart of the knowledge. That means that the submitted test case has to be accepted or rejected. A review is only successfully closed and transferred to the state “approved” when all reviewers have accepted the test object. So a single rejected comment is enough to set the entire review into the state “rejected”.

As soon as a review lands in the state “rejected,” to the author of the test item, it means: improve. Because with the state transfer of the review into “rejected”, the test item of the state “defined” goes back into the state “in definition”. As soon as the author has improved the test item and the test item is “defined” again, the review can begin anew. Possibilities for improving the test item or skipping reviews, so the neutral behavior of the reviewer, can be achieved through the review being generally set to “approved”, as soon as all the other review comments turn out positively.

This can all be presented in a state diagram. Even if state diagrams are relatively easy to understand, the amount of states, events, conditions and notifications can overwhelm the reader. All the more important, then, is the support of mechanical reviews with a software with which you can on the one hand define your desired reviews and on the other carry them out concretely.

How would the next step with features look? Now if the quality of the features is secured through reviews, then the next step is to decide what meaning the stakeholders have for you. But that is a theme for another blog post.

Conclusion

Of course, review meetings and mechanical reviews don’t shut each other out. It is recommended to carry out agreements and examinations on the decision-level “face to face” in review meetings. For the far more often detailed expert examinations, mechanical reviews are recommended because they are less effort to set up. The temporal flexibility, the lack of appointment coordination and travel time and the easy traceability of results support mechanical reviews. But: changes cost time. This applies to both mechanical reviews and review meetings. So plan in time to be able to make improvements in each review. And plan a bit of additional time if you have to document review meeting states and state transfers manually. With mechanical reviews, this state will be automatically achieved when all reviewers agree to the feature description.

Note
We have summarized all the important information about objectiF RPM for you in the objectiF RPM whitepaper.