Functional Design: Why making requirements matters

Within our daily life, changes come along, as do the decisions on how we deal with them. These changes appear in your personal life and also in your professional life. And this is no different at LeaseWeb. Technology is changing and so are the wishes of our customers (and customers can come from within LeaseWeb and from the outside). And sometimes the changes that are requested are big and sometimes the changes are smaller.

But at the start of every change there’s always the same question: “Why do you want this change?” This can be to sell more products, to increase customer satisfaction, to keep ahead with the competition, to lower the manual actions so less hours are spend and more money can be earned and so on.

When the reason of the change is clear, it must be made clear what needs to be changed and what the change should look like. Say, for example, that you are a woodwork shop and a customer tells us he wants a new bed. As a woodworker, how do I know how this bed must look like? As I start building the bed with only this information, there is a big chance I will build something like this:

bed

Image source: IKEA, FJELLSE Bedframe

How do I know, before I start to build it, the customer is thinking about this:

cloud4

Image source: Rocking Bed – Private Cloud 

Obviously, LeaseWeb does not make beds, but we do run into this kind of problem, when we try to build software.

So all this comes down to the problem of making requirements. By asking the customer what he wants in detail, the chance is bigger that the development of the product will possess the correct critical properties and not possess the properties that were not requested. Expectations will be met more precisely and any rebuilding of the product will be less. So the costs will be lower (at the end) and time will be saved (by not rebuilding and remodeling the product). And most importantly, the customer will be more satisfied with the result. So, the most important activity in starting to build a (new or changed) product is to properly gather the requirements for the product.

There are four core activities within the requirements engineering process:

  • Elicitation: defining and refining the needs and wishes from different stakeholders in a most detailed way
  • Documentation: the elicited requirements are described adequately
  • Validation and negotiation: requirements are checked if they meet the predefined quality criteria; requirements that are inconsistent, are negotiated between stakeholders
  • Management: measures that are necessary to structure requirements, to prepare them so they can be used by different roles, to maintain consistency after changes, and to ensure their implementation

These are also well described on the requirementskenniscentrum website (in Dutch) and in the post called “requirements engineering explained” by Mike Polga.

So, the next time, when someone from functional design is at your desk and you’re thinking: “Why all these questions? I only want a bed”. Then realize that these questions are asked to understand the requirements: what kind of bed you want, what you’re going to use it for, how long you want to use it, for what purpose and for which costs? By telling him (or her) everything you’re thinking about (and more), you increase the chance that you get a product that meets your expectations, within time and within your budget.

Share

One thought on “Functional Design: Why making requirements matters”

  1. This post assumes that customer requirements are static and that the customer is fully aware of his requirements upfront. This is almost never the case. Customer requirements are usually very vague at the beginning of the project and are never enough. Understanding the client’s business is key to properly collecting requirements.

    PS: We have published a substantial number of articles on requirements management, you can find them here: http://www.pmhut.com/category/requirements-management

Leave a Reply

Your email address will not be published. Required fields are marked *