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.