---

Contents

• Prerequisites
• Background
• Create your requirements
  • Filter out requirements
  • Write as requirements
  • Fill in requirements
  • Renumber the requirements
  • Plan to verify your requirements
• Recap

Prerequisites

To understand the content on this page, you should have read or viewed the 2022 SE Seminar and the Video Series Summary. The reason is that he states this seminar is to fill in the gaps from his previous content.

Background

I would name this seminar "How to get the perfect start to your project," but I left the name that he gave it. Seminar video.

Customers (in our case NASA) always give point solutions. They never

• tell you what they really need
• provide all of the specifications the system must follow
• give proper requirements
• realize the system boundary

With these facts established, we know that we will have to do some work to convert the customer-provided documentation into proper requirements. We know that the system will not be fully constrained, so we will have to work with NASA or make some assumptions.

Note: We are designing a system, not just a robot. The robot is a key entity of the system, perhaps even a central entity, but we design the whole system. For example, this means factoring in transport options to the competition before we do any Design (traditional engineering design).

Create your requirements

First, outline the entire SEP rubric. To do this, give every sentence a unique number. Rather than numbering them 1, 2, 3, etc. he recommends numbering them 1.2.3 for the 1st section of the guidebook's 2nd paragraph's 3rd sentence, or however you feel is best to break it down.

Anytime there is a compound sentence ("and" or "or"), it needs to be broken up into multiple numbered requirements. Example: "The system shall do A, B, and C." becomes "1.2.3.1 The system shall do A. 1.2.3.2 The system shall do B. 1.2.3.3 The system shall do C."

Filter out requirements

Now, decide whether each statement is definitely a requirement, definitely not a requirement, or unclear. If unclear, ask NASA. If you can't get a clear answer in a timely manner, make the call. He recommends marking these differently, such as "probable requirement."

Note: Last year, we made such a judgment call on an incoherency that we couldn't get a response from NASA on all year: the penalty for using the arena cameras was stated as both 200 and 4 points. Other teams explained that it had been 4 points in the past and the 200 number was a typo that had existed in prior years representing 200 kbps (which, at 1 point per 50 kbps, that makes 4 points and makes sense). So, we decided to move forward assuming 4 points. While at the competition, NASA confirmed that they meant 4 points and that was how it would be scored at KSC. At UCF though, they decided to score as 200 points. How could we have avoided this? Mark recommends considering the consequences: "What if it was 200 points? Well, then we would be in big trouble. I guess we better focus on getting onboard cameras working."

Write as requirements

For all of the sentences that were identified as requirements, rewrite them in proper "shall" language.

Create a requirements traceability matrix. This lists the requirements and where they came from.

Fill in requirements

This is an incomplete list of requirements. For example, on the SEP rubric, it says to format the paper professionally. We need to convert that into a requirement for a table of contents, page numbers, font choices, table headers, etc.

Once the whole team agrees that all requirements exist, the team declares the requirements to be complete. Next, the team considers the requirements for validity, consistency, and coherency.

Renumber the requirements

With the final initial requirements, renumber them to be easy to reference universally.

Plan to verify your requirements

List how each requirement will be verified. This is useful when doing SE, writing your SEP, and for reviewers of both.

Now, you are ready for your SRR.

Recap

You may have noticed how much writing he recommends. He acknowledges that engineers don't like to write, but it is absolutely critical to remember justifications. Think: if you have just 10 requirements, will you remember all 10 in 1 week? Honestly, maybe my memory is just bad, but I know that I couldn't unless I studied like my life depended on it.

Besides, you're not in everyone else's head, so when someone else makes something a requirement, wouldn't you like to know why they're telling you that the system shall do X, Y, and Z? Maybe it's for a dumb reason and that requirement shouldn't exist. Maybe it's a good reason. We'll never know unless everyone writes their reasoning.