Tag: concept review

Squeezing the Lemon

As a chess grandmaster once told me: “once you find a good move, search for a great move.” The same applies to systems engineering design, once you have found a good design, search for a better design.

A better design may not necessarily improve performance but may be easier to implement, or be future-proof, or circumvent some implementation difficulties.

The design should start with an individual exploration. This solo effort will have the highest chance of being original. Here, the most original ideas should be considered. The metaphorical lemon is squeezed to ensure that the best possible solution is proposed. Once an individual conceptualization of the solution is present in the mind of the systems engineer, cross-pollination with the ideas of other systems engineers and software or test engineers may rechannel or replace the original ideas obtained through the original solo investigation.

For cross-pollination and guidance in the design process, it helps to have a good systems team that is involved in the concept review and the drafting of the design, The best reviews are the ones where the attendees are attentive and where feedback is thorough at all levels from the high level concepts down to the details of the presentation of the design. I was lucky to work on a small and experienced systems engineering team of five. Design reviews were brutally frank and incisive. We all gave as good as we received and the outcome was excellent designs that were well organized and attentive to detail. By the time the design reached the software and test teams, we could concentrate on implementation issues and seldom had to change the high level concepts.

Beyond the systems team, good communication with the software and test teams at or before the concept review ensures that impossible approaches are discarded, practical points of view are considered, and previously identified pain points are remedied or avoided.

As part of the fleshing out of the design in the detailed design phase, the systems engineer should consider detailed use cases including adversarial scenarios. Problem use cases identified in the systems design phase will avoid costly problems in the field when bug fixes will be costly and slow to reach the already deployed product. The metaphorical lemon is squeezed again to identify all the possible impacts of the design. An error in the design at the systems level is at least ten times harder and ten times costlier to fix than an error in the software design, which is at least ten times costlier than an error in the coding of the software design. This multiplicative effect is the reason that enough time should be allocated to the systems design phase, and that the systems design should be given the attention it deserves.

The Systems Design Process

The design process is usually divided in three phases: the concept review, the detailed design phase, and the determination of the requirements.

The first phase is the concept review. In this phase which should take place at about one-third of the design duration, multiple design options are considered. This phase starts with an analysis of the product requirements to get a thorough understanding of the desired functionality. This is followed by the determination of multiple design options that are identified and submitted for review. Drafts for the concept review presentation should be reviewed intensely within the systems engineers team if possible. At the concept review proper, the systems engineer should describe the design at a high level, list the options that are possible for the different part of the design, and recommend a preferred option for each one of the options. The concept review goes over the main use cases with no regard to adversarial scenarios. The concept review should be attended by the product manager, the development lead, the development/software engineer responsible for implementing the function, the system test lead, and the systems test engineer who will test the function. By the end of the concept review, agreement is reached on the main aspects of the design.

The second phase is the detailed design phase which ends with the design review proper. In this phase, the systems engineer works out the details of the design. All the adversarial scenarios and use cases are considered. Details of the algorithms are nailed down to the level of exhaustive flow charts and call flows. Communication with the development and test engineers is encouraged to get early feedback on the design. Cross team communication may be needed to request changes to modules outside the responsibility of the systems engineer. It is possible that when working out the details of the design, some unexpected difficulties may be uncovered which could lead to modifications or even reversals of decisions taken during the concept review. The design review should be attended by the product manager, as many members of the development team as possible, and as many members of the test team as possible. This wide attendance will ensure that experts in all aspects of the system will be present and will bless or counter the design. By the end of the design review, agreement is reached on all aspects of the design.

The third phase is the writing of the requirements. This phase usually takes one to two weeks. The systems engineers writes and shares the requirement, then schedules the review about a week out to give the reviewers ample time to provide comments. Requirements are important because they will serve as milestones for the development and test teams for implementing and testing the function respectively. This phase is usually straightforward for the experienced systems engineers but may lead to multiple rounds of requirements reviews for the novice systems engineer which may struggle in the best way of describing the design through simple shall statements. Furthermore, in this phase, some reviewers who had first seen the design in the design review, may provide further comments on the detailed design. By the end of this phase, the design and requirements are set.

The length of the different phases may vary. However, a good time distribution is 1/3 to 1/2 of the time on the concept review, 1/2 the time on the detailed design phase, and about 2 weeks for the requirements review. A lengthier concept review may lead to a more detailed design and may shorten the detailed design phase.

The output of the concept review is always a presentation. The output of the design phase may be a presentation or a word document. Presentation are best used in dynamic environments with excellent communication between the systems, software and test teams. Word document are best used in more formal projects with either an emphasis on formal design, or a looser integration between the systems, software and test teams. In the latter case, a more detailed description will lead to clearer communication of the design.