<p>Requirements? What exactly do you mean?</p><p>Recently I got involved in discussions, arguments, debates (usually due to my own highly opinionated opinions ) about requirements management. It used to be a favourite topic of mine years ago when I was with another employer, but at Microsoft it doesn’t get a lot of airtime – so I am glad this is changing!</p><p>What I find most irritating about this topic is the term “Requirement”. If you consult one of the world’s authorities on this matter, the Oxford English Dictionary you’ll find the following definition:</p><p> The act of requiring; a requisition, request.</p><p> The fact of being requisite; necessity.</p><p> That which is required or needed; a want, need.</p><p> That which is called for or demanded; a condition which must be complied with</p><p>So according to the world’s authority a requirement is a request, a necessity, a want, a need or a condition.</p><p>I quite like this description because it states the obvious – “Requirement” it is a fairly broad definition to begin with. It surprises me how this wishy-washy term survived all these years in our industry to describe one of the most fundamental concepts of software engineering. It’s time to fix it….</p><p>Requirement Types</p><p>I assume every competitive business has a vision and goals of what it wants to achieve. The more sophisticated ones may even have metrics describing goals in measurable terms.</p><p>To realise the vision and goals, businesses structure activities around processes providing the capabilities required to achieve the goals. </p><p>The manifestation of these processes is typically a collaboration of one or more employees performing specific tasks.</p><p>Some of these tasks are executed manually others are automated. The automated tasks are performed by systems which in turn are often constraint by the technology used to implement them.</p><p>I hope none of this astounds you – it isn’t rocket science! This simple example highlights that using the term “requirement” is too simplistic to identify all the “requirements” as defined by the world’s authority – we need to be able to distinguish different types! This isn’t very difficult and without trying to hard I can come up with the following types:</p><p>With a little more extra effort, I can also work out how these requirement types relate by creating a requirement type hierarchy (Figure 3). Again it’s not rocket science nor does it take very long to do it. </p><p>What we have at this stage is:</p><p>1) A more robust vocabulary to better communicate with all stakeholders what we mean by “requirement”.</p><p>2) Defined our traceability requirements (Note: a requirement type!), very handy if you plan to use a tool to capture this information.</p><p>I am not done with this topic (watch my blog), but it’s a start and enough for today.</p><p>Next time someone asks you about “Requirements” – ask “What exactly do you mean?”</p>