Making ideas and concepts concrete and verifiable
To make the product idea communicable and understandable, it needs to be specified as concretely as possible. Only if this is done properly will engineers be able to design what is expected. This elaboration consists at least of the context, use cases and requirements.
The context describes the story of the product and the broader concept; why it is a good product and what value it offers to the users. In addition, an explanation of the business model is valuable to understand how money will be earned with the product. Finally, it is important to describe the broader environment in which the product must work.
Use cases are descriptions of scenarios how a user interacts with the product. Defining use cases is a good way to think about the different scenarios that are possible and how to deal with them. It forces the product owner to describe the interaction with the users in detail. Use cases provide a lot of context in which and how a product is used. This is indispensable when designing the system behavior, especially if there is human interaction (think human machine interface (HMI)) involved.
Subsequently, the functional and non-functional requirements need to be specified (requirements). Functional requirements say something about what the product must functionally do, and non-functional requirements specify what other aspects the product should meet. Properly recording requirements is absolutely necessary. And these requirements must be of good quality. It is a pitfall to want to specify 'everything': that is an unattainable goal. The quality of the requirements is more important. With good requirements, engineers will create a design that meets expectations. Based on good requirements, it is also possible to demonstrate that the design meets the requirements (verification).
Good requirements meet at least the following points:
- There is never a solution in a requirement. It says what the product should do or what it should comply with, never how it should do it.
- Requirements are not ambiguous. In other words, they are concrete and specific. Avoid possibilities for interpretation and assumptions in the requirement. Implicit assumptions are a major source of project failure!
- For each requirement, it should be recorded how this requirement will be tested (verified). An additional advantage of recording a test per requirement is that it prevents possible assumptions about the requirement. So the requirement becomes even more concrete.
- A requirement is one requirement. If there are two in one sentence, make it two requirements.
Capturing good requirements is not an easy task and it requires the attention of both product owners and engineers. There are a number of pitfalls and misconceptions when it comes to requirements, such as:
- Product owners sometimes think too much in terms of solutions, rather than requirements. This does not result in good requirements and limits the creativity of engineers.
- Requirements are sometimes approached as static and unalterable. This approach makes capturing requirements even more difficult, if not impossible. The same applies if requirements are the basis for commercial agreements. Requirements can change during the project, as long as this is done through a good change procedure.