Requirements (System Engineering)

Introduction

We come up with system requirements so that we can specify what we want our system to be.  Among other things, this allows us to communicate what we want the system to do and how it should operate so that when someone goes to the design and architecture phase, they have a place to start and they also act as constraints to help to ensure we end up with the system we want. 

When we’re specifying a system, we have two kinds of things we specify: functional and non-functional properties.

Kinds of Requirements

Functional

First we’re going to specify what the system should do; those specific behaviors or functions it must have. We call these  “System shall do <requirement>”s  and we refer to them as the functional requirements, and they specify the functional elements of a system.

The plan for implementing functional requirements is detailed in the system design.

Non-Functional

Next, we’re going to want to specify criteria that can be used to judge the operation of a system, rather than those specific behaviors described in the functional requirements. These are usually stated as “System shall be <requirement>”s, and are often called the qualities of a system, and they will specify the non-functional elements of a system.

The plan for implementing non-functional requirements is detailed in the system architecture.