What’s a Design Review?

A design review is a milestone within a system development process whereby a design is evaluated against its requirements, feedback on the technical adequacy of the design is provided, and members are recognized for their work. As a team, we don’t engineer in isolation. Cross-functional collaboration and diversity of opinions are key in enabling us to produce successful designs. The goal of a design review is not to criticize, but to improve the design and ensure that it meets its objectives. The cost of correcting a fault in a design increases as it progresses through the development process, which is why design reviews are an integral part of how Space Systems operates. Check out all our past design reviews here: Design Reviews

Design reviews close the loop of our Space Systems engineering framework. The feedback gained feeds directly back into improving the requirements model, and hence the design [src].

Contents

For system-level design reviews, teams are encouraged to abide by the following presentation structure to ensure consistency and to maximize the productivity of the review. The level of detail of the presentation should scale with the current phase of the mission (see ), and the time you have to present:

1. Team Introduction: Introduce the ’s responsibility and its contributing members. For a quick way to create a grid of member profile pictures, you can leverage the
2. Requirements Model: Present the model that drives the design of your team’s system(s) (see Requirements Engineering).
3. System Architecture: Present the diagram that depicts the architecture of your system, its components, and their internal and external interfaces. Explain how your addresses your requirements.
4. Completion Criteria: Detail your team’s completion criteria for the (singular) you are in. Here, you start to present where you are with respect to completing these criteria.
5. Engineering Artifacts: Present 2-3 engineering artifacts (, , , etc.) that went into the design of your system architecture. This is an opportunity for members to showcase project work.
6. Risk Management: Present some risks that your team has managed, is managing, or will manage - to be taken from the . Risk Management provides assurance to external stakeholders that you have anticipated and acted on potential pitfalls in your system.
7. Next Steps: Detail outstanding completion criteria, open questions, and your Roadmap.
8. Q&A: Be prepared to answer questions from other teammates or external advisors. Some questions may be challenging. It is completely okay to say that you don’t know the answer yet, but will look into it. Remember, design reviews are learning opportunities for all of us!

Logistics

Internal Design Reviews

An Internal Design Review is essentially a day-long Systems meeting (woop woop). They take place on a semesterly basis and are scheduled for the last UTAT Saturday of every semester unless stated otherwise. This frequency of design reviews promotes an agile workflow with a consistent feedback loop (see Systems Engineering), ensures that teams know what is going on at their relevant interfaces (and beyond), and allows us to regularly check in on our progress with respect to our long-term mission goals.

An Internal Design Review will generally be structured as follows:

External Design Reviews