Are requirements the elephant in the room? Karolina Mileros, Requirements Management Specialist at System Verification, gives you her best advices to get started and make requirements less frightening.
Requirements. Savour the word. According to the Oxford English Dictionary, a requirement is:
• A thing that is needed or wanted
• A thing that is compulsory; a necessary condition
Requirements are not seldom connected to extensive and wearisome documents, preferably in the context of business contracts, that once fulfilled grant a reward in the shape of a bag of money. Requirements are therefore often seen as a necessary evil to get hold of that anticipated bag of money. And in most cases, this is where the requirements stay.
requirements are about creativity
For me, requirements are about innovation and creativity. To get a vision on paper so that different stakeholders can be involved in discussions about the vision and possible solutions. Requirements embody the process of creating and implementing new systems that can aid, improve and even revolutionize technology as we know it. But bad requirements and requirements engineering can just as easily overturn a project, leading to harm, monetary loss, stagnation and overwhelming migraine. A crushing 56%* of all failed projects do fail due to inadequate requirements engineering.
Requirements are not sexy. The field is vast, hard to grasp, mined with question marks and sprinkled with red tape. Requirements can be hard, but do not necessarily need to be (and should not be!) the elephant in the room that nobody acknowledges or mentions. So how do you eat an elephant? One piece at a time! Here are three nibbles to start with:
• Review the requirements
• Draw a context diagram
• Create mock-ups
How to get everyone on board
Reviewing requirements to improve their quality is not a mind-blowing idea, but for different reasons, i.e. economical, time pressure and ignorance, this step is skipped. Involve your customers, developers, testers and end users early to ensure everybody is aboard the same train. And that your requirements are on track.
A context diagram is a powerful tool to identify the environment in which a system will operate. It also defines the scope of the system to develop. It soon becomes clear how easy integration points or system users are missed and how differing views stakeholders can have regarding what should be implemented and included in the project.
A picture is worth a thousand words and this should not be underestimated when it comes to requirements. A graphical user interface becomes radically more digestible, easy to grasp and discuss if the requirements are accompanied with simple illustrations describing interface outlines and flows. And mock-ups do not need to be user interfaces only, a diagram can describe a required high level system architecture and a simple piece of demo code can simulate a component not yet developed. To have something tangible around which to discuss requirements makes it easier for both customer and contractor to identify gaps and misunderstandings.
That concludes the appetizers. If you are hungry for more there is more to learn from various courses or a friendly requirements consultant near you.
Author: Karolina Mileros, Requirements Management Specialist, System Verification
* Source: J. Martin