Project

General

Profile

Knowledge Base ยป

Needs and Requirements Management

The course uses an Excel file to organize project needs & requirements. It is an enhanced version of the one used for IED.

Required version:
  • Needs and Requirements - export:template documents/Needs and Requirements workbook.xlsx - improved from the IED version
    An enhancement is that all needs are individually numbered, and all requirements are individually numbered. This allows complete traceability of needs and requirements in your documentation as long as you do not change any of the numbering! Instead, simply add new items after the existing ones. Do not insert needs or requirements into the middle of the list. Just add them at the end of the list to keep the numbering intact.
Reminder of the IED version

Gathering Needs

Customer interviews, benchmarking research, and product reviews will generally produce a large list of user comments and complaints. Often this does not uncover 'obvious' unspoken needs or other aspects that are not customer-focused.

The following list of Requirement Types may inspire team to generate additional needs for the design:

  • Functionality
  • Performance
  • Quality
  • Usability
  • Accessibility
  • Reliability
  • Durability
  • Availability
  • Manufacturability
  • Maintainability
  • Environmental impact
  • Interfaces

Some types are closely related. For examples:

  • Reliability is related to performance (quality).
  • Repairability is also related to environmental impact. If not repairable, it will be disposed of.
  • Material selection is related to environmental impact because of recyclability.

Defining Requirements

Remember that gathering Customer Needs and then converting those into Project Requirements was covered in IED!

The attached file atlee-chapter4.pdf is an excerpt from a book on software development. This chapter broadly covers requirements gathering and definitions for software projects.

Requirements for software packages can be managed using other techniques - Software Requirements Specifications

Requirements vs. Constraints

A constraint is a non-functional need that "must be". These are sometimes not measurable items. Examples of these are:
  • The Design Lab currently uses ESP32 microprocessors, so your project will unless there is a specific reason to use another
  • If you work for Company-A, you are probably constrained to use the company's products - and not to use Competitor-B's products
  • For Capstone, students are constrained to using the EDN for all technical material

User Stories

Another powerful tool for gathering requirements is the "user story". There are many resources on this to be found online. Although developed and widely used in the software development area, it can also be applied to other areas.

In the simplest form, it consists of documenting who the user is, what they need to be able to do, and what the benefit / reason is.

Templates:
  • As a [type of user], I want to [perform some tasks] so that I can [achieve some goals].
  • As a [type of user], I want a [feature] so that I can [satisfy a need].
Can be built as a table:
Title Type of User Tasks to Perform Desired Goal/Outcome
production worker adjust the motor speed to avoid damaging the part
production worker adjust the motor speed to set part size
where the Title column is used to create groupings of related items.
For example:
  • As a student, I must regularly post technical contributions to the Electronic Design Notebook so that I can collaborate effectively with my team.
  • The car's transmission must transfer the energy from the engine to the wheels so that the vehicle can move.
  • As a driver, I must be able to control the car's energy transfer so that I can go forward and backward.
  • As a driver, I must be able to control the car's energy transfer so that I drive slowly and fast both with a boat/trailer attached and without it.

It is often desirable to be able to sort these by the user type/role, so it is recommended that these be kept in a simple spreadsheet like this one - export:template documents/User Stories.xlsx

Acceptance Criteria

Use cases describe functional needs. We can also write acceptance criteria to add details to user stories to make them more specific and measurable (testable). A use case gets one or more acceptance criteria. This is simply different terminology for "requirements with metrics" or "specifications." They are all the same.

For example:
  • As a user, I want a reliable system so that I can use it to complete assigned tasks.
    • Acceptance Criterion: The downtime of the system is less than 15 minutes/day.
  • As a user, I want a secure system so that my data is protected.
    • Only authorized users can access the system.
    • When a user fails to be authenticated three times, the user account is locked. (And) The user must contact the system admin to unlock the account.

If the acceptance criteria are all met, the use cases have been satisfied.

Tips

Team SHOULD leverage many sources when developing Needs, Requirements, and User Stories:
  • initial Project Description document
  • all team discussions
  • notes and discussion from Client Meeting # 1 Project Kickoff
  • any life experience team members have with similar equipment, processes, and products
  • industry standards

ATTACHMENTS BELOW