Stakeholder requirements

Introduction

End-users, developers, testers, production, project managers, business, sales… they all have their interest in the system and are called stakeholders.
At first, it is the task of the system architect to collect those interests (or concerns as recent literature suggests [ref]) and to resolve (potential) conflicts. Communication is key since stakeholders do not necessarily express those interests by themselves.

Secondly, the system architect has to analyze those high-level ‘requirements’ e.g. by classifying them by quality attribute (performance, configurability…).
Finally, given both inputs (high-level requirements and analysis), the architect can start to design the system.
Next figure summarizes things:

Stakeholder requirements

User requirements

The user shall be able to

• connect solar panels to the charge controller (REQ1)
• connect a wind turbine to the charge controller (REQ2)
• charge batteries (REQ3)
• connect a device to the output (REQ4)
• use the excess generated power (of the diversion load) if he wishes (REQ5)
• monitor the generated power (REQ6)
• monitor the battery health (REQ7)
• monitor the battery state of charge (REQ8)

Business goals

The system shall outperform the competition in terms of:

• configurability (REQ9)
• power harvesting (REQ10)
• power supply (REQ11)

Sales dreams

• The box shall have an elegant, green housing with rounded corners. (REQ12)

Project manager worries

The system shall be able to

• keep the wind turbine in a safe working regime (REQ13)
• protect the batteries (REQ14)
• protect itself (REQ15)

Analysis: classification by quality attribute

System safety

REQ13, REQ14, REQ15

Performance

REQ10, REQ11

Configurability

REQ9

Tool

We use Enterprise Architect (EA) as a tool for requirements engineering. The figure, which was captured from EA, gives a nice overview of our requirements. The complete model of the energy harverster can be found here.