Follow our illustrated blog on Embedded Software Architecture

How to build a hybrid solar/wind energy harvester?

From stakeholder to system requirements

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)

System requirements and their organization

engineering process

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.

organization of system requirements

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
The quality attributes that we consider are performance (as requested by business) and system protection (as requested by project management). Here’s an example of the solar panels input:
input solar panels

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.

from stakeholder to system requirements

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.

In this example (see figure) we trace backward from REQ79 to REQ16 ‘Energy Harvester’ via part-of relations (decomposition tree). Also, REQ79 links to the stakeholder requirement ‘Connect solar panels’ (traceability to stakeholder requirements).

bidirectional traceability: bottom-up

Next example shows how the stakeholder requirements ‘Outperform in terms of configurability.’ is realized by the system. Note that there are still (lots of) open questions.
bidirectional traceability: top-down

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).

traceability between stakeholder and system requirements

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?

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
Share
About rtos.be

rtos.be is a joined initiative from Gert Boddaert and Pieter Beyens.
More info: about us, our mission, contact us.

Speak Your Mind

*


nine + 4 =