5 reviews that a systems engineer must know

Word has long since gotten around about how effective reviews are for finding bugs. Nevertheless, I often see reviews being put on the back burner. But there are many different types of reviews. Knowing these helps us to use the right one, maximize the added value of the reviews and keep the effort as low as possible.

Agility needs reviews

To get straight to the point: Agile projects benefit enormously from reviews. This is why they are also an integral part of many agile methods. Scrum, for example, requires regular sprint reviews. Code reviews and Pair Programming are popular techniques in agile development.

In agile projects in particular, it is important that the reviews are lightweight and have a clear benefit. The right tools can also speed up reviews enormously and make them "less painful".

Tools make reviews much more efficient

Reviews are unpopular for several reasons. However, many of the reasons can be solved with tools. The most important reasons include:

• Merge results - We've all been there: a specification is sent as a Word file. The sender then receives five customized documents and has to merge them. Have fun...
• Document results - What use is a review if the results are not properly documented? And in such a way that they can be found when needed? And preferably in a form that can withstand an audit.
• Work asynchronously - Or five people meet in the meeting room and go through the requirements together. For the third requirement on the second page, there is a long discussion in which only two experts take part. Finally, the review meeting is adjourned because the remaining ten pages have not yet been reviewed.

There is no longer any excuse for such problems:

• In software development, tools such as Gerrit or ALM systems such as gitHub with which teams can carry out their code reviews independently of time and in a cleanly documented manner.
• Cloud-based word processing systems such as Google Docs have built-in comment functions for distributed reviews. Even Microsoft Word can now do this.
• Modern RE tools such as Jama Connect or Intland Codebeamer have integrated review systems that enable formal reviews.

Reviews in the literature

In systems engineering in particular, it is almost impossible to do without reviews, as many projects are safety-critical and have to implement corresponding compliance requirements. Many standardsincluding ISO 15288 or IEEE 1028. IEEE 1028 in particular has five reviews that every systems engineer should know.

However, it is important to note that the literature approaches these reviews quite formally. In practice, we should question the purpose of the review and check whether we can implement it less formally with the same objective. With tools in particular, we can make the reviews feel much less formal, as the tools automatically take care of the audit trail.

Here are the five review types:;

Even if the term is more reminiscent of the head of department, it is actually all about project management. A management review can be informal and aims to identify problems and bottlenecks at an early stage.

The Daily Scrumwhich should last no longer than 15 minutes, is a very informal management review.

As the name suggests, this is a review for technical correctness. An informal code review is a good example of this class of review.

Technical reviews can be extremely informal. In software development, this is Pair programming a form of continuous, informal review. We can also visit colleagues briefly at their desks with a piece of paper (well, Corona...) to get some feedback.

It's amazing how incomprehensible the self-written specification sometimes seems after just one week...

We don't even need colleagues for a technical review: We can carry out a review of our own work results in the same way. In this case, it makes sense not to do this immediately after creation, but to get some distance from the work result. It also makes sense to use standard review techniques, such as checklists.

It becomes more formal

A walk-through is exactly what the name says: one person guides a group through a work product and explains in a meaningful sequence why the work product is the way it is. The author can take the lead, but this does not necessarily have to be the case.

IEEE 1028 defines a walk-through quite formally with certain predefined roles. However, the demo often provided in a sprint review is also a walk-through.

Walk-throughs can also quickly become interactive if participants cannot follow certain steps or question them. This is a good opportunity to discuss alternatives. We should be prepared for this during a walk-through. Because this is where the walk-through has great value: we can get skeptics on board and convince them. And maybe the skeptics are right and we can work out an even better solution together.

An inspection is more formal than a walk-through. In particular, the entire work product must be checked and formally recorded during an inspection.

An inspection usually works quite formally. For example, there are often inspection rules, checklists, specifications for the participants and much more.

Even if there are no legal requirements, inspections can drastically improve the quality of the result if used correctly. If you decide to do so, you should automate as much as possible. For example, a modern development system can be configured so that at least two different people perform a code review before code is merged into a branch. Many formal checks can also be automated. This has long been standard in software development (e.g. with static code analysis). And even Specifications in natural language can now be automatically checked for vocabulary, consistency and more.

The most formal of all reviews is the audit. An external expert is involved here. Audits are often carried out by legislators, but also by customers or independent organizations. Audits are often prescribed due to compliance requirements.

Organizations that have a review culture need not fear audits. But even in such cases, an audit can cause considerable effort, as it ties up time and resources. Tools can also help here. A properly set up repository with appropriate processes can save an enormous amount of time. It does not matter whether the repository contains requirements, models or code. Good processes ensure that an organization is continuously "audit-ready".

Conclusion

Reviews are enormously effective and ultimately also inexpensive. For it to work, an organization needs a review culture. The right attitude, pragmatic processes and good tools help to take the fear out of reviews.

Photo by Markus Winkler on Unsplash