Understanding what people need and require from a product is important. So requirements are important. But what is a requirements and what are “good” or “bad” ones? I set forth to find the ultimate answer and found 42. So lets add a bit more structure and talk about the problem, solution and the conversation side and conclude with a question: where should the development team invest their energy: into creating the specification or into discussing the best possible solution given the constraints?
If really requirements are that important when developing a new product, and my experience strongly suggests that this is so, then one would think it is important to understand – and agree – what actually is meant with the term requirements and what makes a requirement to be “good” or “bad”.
The starting point different opinions
Have you asked around in your company? I tried that lately and received completely different opinions. My observation: if two people talk about requirements, both use a different definition of the term.
So lets look at what a couple of “official” sources have to say:
The wikipedia article makes it obvious: The term requirement is not as unambiguous as one would wish. Here are keywords I picked to contemplate the matter a bit more:
- A capability to offer
- A condition to satisfy
- A factor judged necessary
- By the circumstances
- By the nature of things
- Needed by a stakeholder
- Needed to fulfill a contract, standard
- explicitly requested or implicitly required
- what a product should achieve
- how to interact with a product
- detailed statements of the system’s behavior, content, qualities, and operational constraints
The difficulty seems to me, that these statements cover completely different aspects:
- There is knowledge about the context of a system, e.g. about users and customers, how they do and experience their work and life.
- There are also limitations rooted in the nature of the things, in circumstances of specific situation, about relevant regulations and laws, and more.
- There are explicit statements from stakeholders about what they want the system to be, do and how the system should do it. And also statements about what stakeholders want the development team to do and how.
- There is also the notion of externally visible behavior, content and qualities versus an internal view, i.e. the code, architectural drawings etc.
- And hidden away the idea that somebody decides whether something is actually a requirement or not, i.e. in scope or our of scope.
Adding structure to the answer
To put a bit more structure to it, lets put all of these things into one picture:
First, the problem side: On the one hand, we have stakeholders requests. They can be explicitly stated, implicitly presumed, contradictory, missed, undetected or even not yet existing. They can also be suggestions, wishes or even orders and they can cover any topic from team setup to function and on any level of detail. On the other hand the technology, the domain, and the organisation impose constraints onto the solution. A document covering this problem side is sometimes called business, user, or market requirements.
Second, the solution side: Given the current understanding of the problem side and while sorting out the conflicting inputs, the team works on the solution.
- WHAT FOR or the context view: Who will do what when and where using the product and what do these people experience as just great. Sometimes this is referred to as user needs specification or even again, user requirements.
- WHAT or the external view: What services and data does the product offer, how can users and other systems interact with it and to what level of quality? This is what software teams generally define as requirements.
- HOW or the devops & internal view: The internal structure of the product, the code and how it is developed, operated and maintained.
Third, the conversation side. In the process of developing a product, the team discusses In or Out. What requests should the solution address, what constraints are relevant, what audience to target, what services to offer, what components and functions to build, etc. In this process the team decides whether something looking like a requirement is actually considered a requirement.
These three fundamental things are part of any development, independent on how an organisation and the teams work. However, there are different approaches on how to do it.
Approach one: creating a specification
In the first approach the requirements engineers create a requirements specification.
In this specification, the external view of the software is what is basically relevant as requirements. These requirements are usually linked to both the context view and the problem side. Depending on the exact usage, a more detailed or more higher level specification is appropriate.
In some cases, creating the best possible external view at just the right level of details can be crucial. Especially if there is no way around one of those contracts where resources (time and money), scope and quality are tightly regulated.
Such a specification is always just the best compromise given the current state of knowledge about the problem and the solution side. Use Cases are a great tool for exactly this purpose and have been successfully used by many development teams.
Approach two: leading a conversation
The second approach is to lead a conversation about the best possible product. Given the current understanding of problem and solution and what the team achieved so far, what is the best possible product?
In this approach, the development team puts much more attention on constraints, stakeholder requests, and the context view rather than on a description of the external view.
That’s why those teams lead a conversation rather than specifying requirements.
This changes how teams do thing. Instead of creating a detailed requirements specification and drafting use cases to talk about how the system should work, teams focus on how the users will work given the cool new functionality the system will offer. They create mock-ups, do story-telling, sketch experiences and let the new product spring to live.
To communicate within and around the team, UI sketches, excel sheets containing business logic (yes, they make great executable acceptance tests), and data from external system form a much richer communication than the abstract body of requirements.
The preferred tools for this working style are user stories, user story mapping and backlogs. Each user story represents a bit of the future reality a team agreed with the stakeholders to create for customers and users. Each story is a promise to lead the conversation in the near future and thus backlogs and user story maps are plans in what order the team will lead these conversations to strategically build just the right product.
The difference: where we invest our energy
The following image illustrates the different guiding principle between the two approaches:
When we lead the conversation as a team, we invest our energy into testing with customers, users and other stakeholders about what brings enough value so we should build it and what not.
When we compile a requirements specification, we invest our energy into reviewing with stakeholders, whether we have captured all requirements.
Put down as provocative as this, the difference between the two approaches couldn’t be bigger.
So my conclusion: As a person responsible to get the user stories or the requirements right, I prefer to make people work together to develop the best possible product rather than specifying requirements. Hence I provide my share to the team effort so we as a team work with stakeholder requests, constraints, context and solution approaches so that really valuable user stories will turn into reality.
What is your conclusion?