Requirements Gathering (WIP)


Requirements gathering is the process of determining what we should build.

TODO: add diagram showing a spectrum from right to left:

You can err in both directions—there’s often not much point in thinking about the business strategy, or questioning the clinical need. That’s not our role (most of the time). Even user needs are sometimes outside our purview, although often we will be involved in formalizing and prioritizing abstract user needs that our clients have never written down.

It’s also difficult to separate requirements gathering from design (and even construction), since some requirements become obvious as you begin working.

Learning Material

Read through this tweet sequence.

Read the Introduction, Section C on Design inputs, and Section D on Design outputs of the FDA’s Design Control Guidance For Medical Device Manufacturers.

TODO: address these


To learn as much as possible from these exercises, write your responses before revealing the provided answers. If any exercises seem irrelevant, you can skip them and instead write a justification as to why they are unimportant. These justifications will help us improve the lesson for future students.

Exercise 1

What is the difference between user needs and design inputs?

Exercise 2

What is the difference between a design input and a requirement?

Exercise 3

What is the difference between a design input and a design output?

Exercise 4

How does the FDA use the the term specification?

Exercise 5

Do you think engineers should be involved with requirements gathering? If so, why?

Exercise 6

You are developing a web application that consists of multiple modules. These modules are largely independent, but they currently utilize the same JavaScript bundle. An issue to split the bundle for better performance was created several months ago. This issue has not been prioritized. The client suddenly prioritizes the issue. How do you respond?


This situation occurred during a real project. The client was actually concerned with an external dependency that had caused a short downtime when the dependency’s server was not available. Splitting the bundle would not have prevented this problem, but it is easy to understand the client’s confusion since the issue described limiting the loading of dependencies.

Fortunately, the engineer had noticed the downtime, and he suspected the sudden shift in the issue’s priority might be related. He confirmed with the client that this dependency issue should be addressed and included a fix.

Unfortunately, the engineer also chose to continue implementing the bundle-splitting logic as specified in the issue without reconfirming the client’s desire to pursue the issue’s stated change. After spending nearly two days updating configuration, the engineer demonstrated the reduced bundle sizes to the client only to realize that the client had already been satisfied with the application’s original loading speed!

The engineer could have avoided days of unnecessary work at a cost of perhaps half an hour of requirements gathering. Clarifying the requirements and reducing the issue scope accordingly would also have illustrated Innolitics’ role as a venture partner rather than a service provider attempting to maximize billable hours.

Continuous Lesson Improvement

Open the lesson page in the GitHub editor.

Remove any exercises or learning material that are not useful to the intended audience. Find ways to shorten and clarify the writing. Add generally useful exercises, responses, or learning material. Your improvements will make our training program great!

Create a new branch and pull request and assign it to your lesson mentor. The available lesson mentors are included in the YAML front matter of the lesson. They will set up a time to review your suggested changes and to talk through your exercises for the lesson.

After the review add your self to the "completed" property in the lesson's YAML front matter and merge in your changes!