There is no universally agreed, ‘standard’ definition of the term requirement; many groups and individuals will have their own definitions. In general, it is reasonable to assume that a requirement represents something of value to the person or group that expressed it.
IEEE (Institute of Electrical and Electronic Engineers) offers the following definition:
- A condition or capability –
- needed by a user to solve a problem or achieve an objective –
- that must be met by a system or system component to satisfy a contract, standard, specification or other formerly imposed document.
This definition is also used by the IIBA which in turn is referred to in the current syllabus for the BCS Requirements Engineering training course.
There are plenty of other definitions. What we like about the IEEE one is the emphasis on solving a problem and realising an objective. A feature of Capiro’s mission is to help clients to identify the problems, objectives or opportunities before attempting to acquire a solution.
So, in looking for requirements, we could start by identifying the problems that are blocking the achievement of objectives or the realisation of opportunities. An immediate question is, whose problem, whose opportunities and whose objectives? Success with requirements demands that these people, all of them, be identified and engaged with; they must be listened to.
To achieve this aim, it is essential to work with the people most concerned with solving the problem or realising the opportunity; these are the stakeholders. The concept of a stakeholders may also covered by terms such as product manager, product owner, user or actor. Related concepts, terms and roles include change manager, benefits owner, subject matter expert, product champion or evangelist. I have also heard them described as the performers.
A challenge for anyone seeking to understand people’s requirements is that these stakeholders are not a homogeneous group. They are individuals and groups of individuals with individual (or group) perspectives, cultures, ambitions, needs and agendas. They do not all share the same idea of value. Putting all of this together frequently results, to a greater or lesser extent, in conflict. The ‘requirements seeker’, e.g. the business analyst or product owner, needs to be a great facilitator and negotiator.
The potential for confusion is increased with the proliferation of terms such as business requirement, user requirement, software requirement, feature, and so on. These terms are often used interchangeably, even within the same organisation. It is usually a safe bet that the organisation does not have an agreed set of definitions for these terms. Creating a restricted set of preferred terms and definitions would be a great start to improving your requirements process.
Another challenge for the requirements seeker is that requirements are not always expressed concisely, clearly or completely. There is a concept sometimes referred to as ‘customer expectations’. Customer expectations can extend well beyond the expressed requirements. They can be tacit or explicit, realistic or fanciful, creative or mundane. In order to really delight your customers you need to coax these expectations into the light. You then need to really understand them. With the help of other team members, you need to understand if it is feasible to realise them, financially, technically and culturally. And if they are are feasible, are they desirable?
A complete requirements process is likely to include at least the following activities:
- Requirements elicitation
- Requirements analysis, perhaps with requirements modelling
- Requirements recording (documentation)
- Requirements management
There are of course various approaches, techniques and tools that can be used to realise the process. We shall cover these in future posts.
