From stakeholder to system requirements

System requirements and their organization

Given our stakeholder requirements and some basic domain knowledge, we can now initiate the system requirements. Instead of extending the rather informal and unstructured stakeholder requirements, we prefer to start with a brand new set of requirements which is organized in a hierarchical structure (divide and conquer!) in which:

• the root node (level 0) is the system,
• the level 1 nodes are the functional blocks (or functions) of the system,
• the level 2 nodes are the functionality and the quality attributes (performance and system protection).

The benefit is that all requirements (functional and non-functional) of one functional block are bundled in a subtree.

The main functions (level1 nodes) of our energy harvester (the root node) are the inputs and outputs  (in a broad sense i.e. all functionality attached to an input or an output):

• input wind turbine
• input solar panels
• output to charge batteries
• output which supplies energy from the batteries
• output to use (or burn) excess generated power
• housing

Requirements traceability

There’s still a missing link between stakeholder and system requirements. This can be solved by requirements traceability which is one of the key points in requirements engineering.

Traceability is implemented by linking requirements and it allows you:

• to find the reason why a requirement exists by tracing backward to its originator (which is a stakeholder requirement), as well as
• to determine the impact of change of a requirement (stakeholders tend to change their minds…) by tracing forward to its children.

Probably the most important traceability tool is the traceability matrix. A traceability matrix can ensure us – apart from other features – that all stakeholder requirements are linked to system requirements. This is a quite valuable because then we can guarantee that no stakeholder need is forgotten. Next figure shows a part of our traceability matrix (click to enlarge).

System requirements of energy harvester

For a comprehensive list of requirements click here. The current set of requirements is still high-level but that’s fine. Iteration after iteration our knowledge and experience about the domain and the product will improve, and our high-level requirements will decompose into lower-level requirements (sometimes up to the point that the requirements can almost be translated into code).

The initial effort is significant but the reward will come later. We go for the long term. How many times did you forget the features or functionality of a certain product, especially after it is a few years in production?