Requirements – Why bother? »

thinkahead_brassWe regularly exchange ideas and opinions about Model Based Design and modeling using MATLAB and Simulink with our clients. Requirements are a recurring topic in these discussions. It is intriguing to observe that there seems to be no consensus about the virtue of requirements specification. In essence, writing requirements means specifying exactly what functions and qualities should be embedded in a product. Sounds like a logical first step in a design or development process. Does it?

Some companies rather skip requirements definition. They don’t see the immediate benefit. They feel it is complicated and slows them down. They find the administrative burden overwhelming; the requirements system appears rigid and cripples them. Indeed, drafting requirements requires patience and skills. It may be a challenging activity. It requires that the people involved agree on things early in the process, long before the actual product exists.

At MonkeyProof Solutions we are convinced that a structured requirements process has added value. Defining requirements forces you to think ahead. It helps to make implicit ideas explicit, and it is much easier to share, discuss, review, test, implement and improve explicit ideas. In fact, requirements definition directly relates to front loading: it facilitates teams to specify and test ideas early in the development process. A few quick-and-cheap requirements definition iterations early in the process may save many expensive design, implementation and test cycles later on. Clearly defined functional requirements speed up effective implementations. Thinking about non-functional aspects directly sets a target for performance and usability.

We acknowledge that requirements definition requires skills, tools and discipline. Skills you can train. It is our experience that peer reviews boost an engineer’s requirements skills. Tools for requirements management should fit your organization. Requirements tools that suit the workflow are helpful here. Discipline is a hurdle when skills and tools are not in place. We think that enforcing discipline is not necessary. Organizations better facilitate their workers by investing in effective training, automation of tedious tasks, and tools that fit the workflow. As soon as the benefits of requirements definition become clear, discipline is no longer an issue.

In short: requirements specification is a valuable activity, and quality requirements make up a solid frame of reference for design-, implementation- and test cycles. The trick is to keep requirements management practical and dynamic. Let us know if you want to discuss how.