Stakeholder and System Requirements - Why Bother ?

As systems engineers working across different industry sectors, Jim Henderson and?I ( Martyn Cleland FSEng MSc MInstMC ) continue to discover two common themes:

(1) Companies not spending enough time defining and validating requirements at the beginning of a project;

(2) Failing to perform requirements verification as a project progresses.

Instead, We find a lot of companies diving into the detailed design as quick as possible, and, often verifying designs too late in the project. This often comes at cost of finding out during commissioning the system doesn’t do what stakeholders expected, or the requirement is not achievable.???

We find ourselves asking the same questions:?

"How do you know your designing a system your stakeholders need, if you don’t define and agree what it should do at the start"??And; ?

"Why didn’t you asses if the requirements can be met before commissioning the system"????

Which leads us to the point,?why bother with stakeholder and system requirements??

Stakeholder and System Requirements:

It’s often difficult to define stakeholder requirements up front, given that in most cases stakeholders don’t always know fully what they need. This is understandable given frequently it’s something new being considered. However, this doesn’t mean just give up and dive into the development!

Difficult as it is, and maybe if it is incomplete, setting down some requirements up front is vital to the success and management of the Project. In many cases the requirements evolve or indeed form up from the stakeholders as early demos and prototypes are built. In this case it is vital to have established some baseline requirements from which the changes can be made (with schedule, quality and cost implications). Otherwise, the Project goals are built on "shifting sand" and the outcomes / deliverables are far from certain.

Having requirements established early on, if not at the start of a Project reduces the Project uncertainty in terms of cost, schedule and even quality. After all, how do you know you have finished the Project if you cannot make reference to the original needs / requirements of the stake holders? Lack of requirements leads to potential "scope creep" and misunderstanding leading to Project cost and schedule overruns.

During the project risks can be assessed and captured in a risk register strongly linked to the requirements, which can be shared with the stakeholders. In the latter stages of the Project when Verification and Validation take place cross reference to the original (or developed) requirements can be made to both help satisfy the stakeholders that their requirement has been incorporated, and the need can be verified from a design perspective and validated in the product or service.

Most projects that start design and implementation without a good basis of requirement definition inevitably run late and over budget, with understandable stakeholder dissatisfaction.

It may not be perceived as the "coolest" of tasks for engineers to get the requirements established before embarking on a "cool development", but it pays several times over, both during the development and the verification and validation stages knowing that you have actually spent your valuable time wisely developing the right thing for the stakeholder and hopefully exceeding their expectations!