Requirements Elicitation

January 8, 2016 - Rebecca Haag, Systems Engineer II; and Gary Seim, Principal Systems Engineer, Retired

Requirements represent a translation of customer needs into a contract that designers can utilize to drive the development of the product and that can impact a project’s schedule, budget, and quality output. A complete set of requirements should capture the scope of a project and the vision associated with the product under development. The creation of this set of requirements is a non-trivial effort referred to as requirements elicitation. This paper will explore the process of eliciting requirements, including: determining who should participate, creating opportunities to extract/obtain requirements, and generating meaningful user discussions.

Key Participants

The elicitation process is commonly driven by a systems engineer; however in order to effectively capture correct requirements, the systems engineer needs to elicit input from various system users. It is extraordinarily important that all user classes (installer, end user, maintainer, etc.) and other stakeholders (regulatory bodies, marketing, etc.) are included or represented in the elicitation process. In circumstances where certain users or stakeholders cannot be included directly in the process, product champions may be identified to serve as the voice of those users. It is important that as many perspectives as possible are represented to ensure that a well-rounded understanding of the product need is captured.

Elicitation Activities

Although a number of activities can be undertaken during the requirements elicitation process, perhaps the most obvious are interviews and discussions with end users, including physicians and clinicians. These can be useful to understand how they expect to interact with the product, and how it could impact their workflow. It is important to keep in mind that this can be of somewhat limited use for very novel products. As Henry Ford observed, if he had asked his customers what they wanted, they would have told him they needed a faster horse.

In addition to interviews and discussions, other activities such as surveys, customer site visits, work flow and task analysis, and analysis of existing products (both competitive and previous generations) can be pursued.

User Discussions

When participating in user discussions for requirements elicitation, it is important to remain neutral and to prepare a questionnaire that includes specific/targeted questions.

Maintaining Neutrality

Development team members should remain as unbiased as possible during user discussions to avoid accidentally presenting discussion points framed as leading questions. These leading questions may prompt the user towards a desired implementation or solution already identified by the development team. This shortchanges the requirements elicitation process by preventing a well-rounded set of user inputs from being gathered. Though the user may not always be right, they bring a valid outlook to the discussion and should not be dismissed out of hand. Understanding what drives their perspective can provide valuable insight into appropriate requirements.


A key component to user discussions is the development of a questionnaire that is designed with the appropriate mix of specific/targeted questions and open-ended questions.

Specific/Targeted Questions

When participating in discussions with users or other stakeholders, the first impulse may simply be to ask them what they want or even what their requirements are. While these are the questions that the product development team ultimately needs answered, presenting them in this manner can spawn a large number of random, disjointed thoughts regarding the system. In order to prevent the development team from becoming overwhelmed by this user input, more targeted questions may be more effective.

More specific questions can be used when interviewing users to guide the discussion. It can also help to provide organization to the information being gathered.  Some examples of potential questions are listed below:

  • What would drive you to use the new product over what is already available on the market?
  • What problems will this product solve / minimize for you?
  • What aspects of the product will be most valuable to you? Least valuable?
  • What criteria will be used to evaluate product success?
  • In what types of environment will the product be used?

One of the most powerful tools in the requirements elicitation process is the question ‘why?’.

By digging further, more information can be gathered that might have otherwise been left unsaid, but implied. Many useful insights may be gained by asking why:

  • It may help identify assumptions that the person being interviewed holds. These assumptions can be evaluated to determine if they are incorrect, obsolete or at odds with the assumptions that others hold.
  • It may reveal implicit requirements that have not yet been mentioned or captured.
  • It may help the development team understand the rationale behind requirements.
  • It may clarify that certain requirements are higher priority than others. Prioritizing during the elicitation process can help drive trade-off decisions during the development process.
Open-Ended Questions

After utilizing these more targeted questions, introducing open-ended questions can encourage critical thought from the user. Questions like “What other scenarios could the product encounter?” or “Would there ever be a need to ‘do something’ ?” can prompt the user to provide additional insight not already discussed.

When developing open-ended questions, it is important to not fall into the common trap during requirements elicitation discussions of focusing on the normal behavior of the system. This normal behavior only provides part of the picture. It is also important to explore the users perspective on what types of things could go wrong with the system, what errors will need to be detected and how the system should respond to these error scenarios.

Minnetronix’ Philosophy on Requirements Elicitation

At Minnetronix, our systems engineers and development team members have extensive experience with requirements and are available to drive or support the requirements elicitation process as needed.  We work closely with our customers to understand their initial needs, identify areas that need additional clarification, and create a comprehensive set of system requirements to drive the project.


Creating requirements is an essential step in the medical device development process.  Good requirements have the potential to greatly improve the chances for a positive project outcome with respect to schedule, budget and quality output. The experienced Systems Engineering team at Minnetronix can help manage the requirements elicitation process to ensure a comprehensive set of needs is documented.

It is important to remember that even the best requirements documents cannot replace human dialogue. After the elicitation process has wrapped up, maintaining the dialogues between developers and users throughout the development process can help ensure that the end product meets the customer and user needs and expectations. In addition, it is essential that once established, requirements are appropriately documented, traced and changes are controlled as outlined in our Requirements Management paper.

  1. Systems Engineering Handbook: a guide for system life cycle process and activities, prepared by International Council on Systems Engineering (INCOSE), 4th Edition, Wiley, 2015
  2. Software Requirements – 2nd Edition: Practical techniques for gathering and managing requirements throughout the product development cycle, Karl E. Wiegers, Microsoft Press, 2003
  3. More About Software Requirements: Thorny Issues and Practical Advice, Karl E. Wiegers, Microsoft Press, 2006