Project requirements come from a great many sources:
the voice of the people [is] the voice of God.
and those people should not be listened to who keep saying,
'The voice of the people [is] the voice of God,'
since the riotousness of the crowd is always very close to madness.
If we are designing a product that will help people with some activity, we have to get input from, and validate our plans with the intended users. Even if they don't know what they want. There are many mature and popular methodologies for requirements development, elicitation and management. Examples include
When defining a product it is important to identify all of the different types of people who would have a role in, or benefit from the proposed product. This certainly includes people from within your own organization (engineering, manufacturing, sales, support, marketing, management) but it also includes potential partners and customers. Different people have different perspectives. The more perspectives you look at, the less likely you are to miss something important.
For some products, it may be obvious who the potential users and customers are. For other products those people may be hidden within other organizations. If we are going to get useful input from potential users, we must:
This may sound trivial, but it is vital that none of these steps be omitted.
In the process of developing the product concept and initial requirements we will identify sub-classes of potential users. If we have experience in the problem domain, we may understand exactly what types of people perform what operations. If we do not, we will need to talk to people with domain experience to shore up our notions of who our users might be. In some cases we may have domain experts we can ask (sales people often know a great deal about their customers). In other cases, we may have to conduct customer interviews just to figure out who our customers might be.
Once we know what kinds of people we need to talk to, we have to find them. Perhaps we already have friends who work in such groups. If not, sales people may be able to help us find people to talk to. We must recognize, however, that the people we know (or are referred to) may not actually be the people to whom we need to talk. In an initial phone call, we can introduce the type of product we are working on, and ask if they would be a good person to talk to, or if they can suggest people who would be more appropriate.
The final hurdle is convincing potential users to talk to you. Most people dislike meetings, and the prospect of sending a half dozen people to a meeting called by some stranger may be particularly unattractive. There are, however, many good reasons why people choose to give up valuable time to participate in requirements sessions:
The process of getting potential users to tell you what they need is called Requirements Elicitation, and it is a surprisingly fragile process. It is very easy to go to a group of potential users, describe to them what we propose to build, and ask them what they think of it. The problem is that the potential customers say it sounds great, the developers build the product accordingly, and nobody uses it. What went wrong? At least two things:
Experience has shown that getting high quality input from potential users involves:
It is common to send a great many people to a requirements gathering session ... but they are there not there to talk. They are there to listen.
A facilitator (ideally someone with some experience with this process) briefly lays out the goals and agenda for the meeting. In general, the goals will be to gain an understanding of (within the product domain)
The agenda should include brief introductions of all participants. This is not merely a social formality. When interpreting peoples' suggestions, it is often vital to understand their roles in the process.
The agenda should also include a brief introduction of the proposed product concept. This is not a detailed description or a sales pitch. It is only intended to be enough to establish the context for the discussion. We are not here to describe a product to potential customers. We are here to listen to potential users describe what features would be valuable to them.
The facilitator will then put a series of questions to the interviewees. We will start with very general questions, and then move into more application specific questions. Our questions should be open ended, because we want them to tell us long and detailed stories about what they do. We should start with very general questions because we want to give them opportunities to bring up subjects we didn't even know to ask about.
We want to start by asking what these people do (e.g. within their organization), and the environment in which they work. This may seem a meandering path to the goal, but it establishes the context for the remainder of the discussions.
If we went straight to the activities that our product will facilitate, without understanding when, where and why those activities are undertaken we might find ourselves optimizing details of their tasks while missing the fundamental point. When it comes to understanding your customers, there is no such thing as useless knowledge.
Once we understand the organizational and process context in which they operate, we then ask people to describe the typical operations they perform, how they perform them, and what parts of this process do and do not work well. We are also interested in how much of their time goes into which activities, and which activities seem to be the most troublesome.
This is also when we can ask them about experiences they have had with related software: what they liked about it, what they did not like about it, why they do or do not use it, etc.
After they have described what they do, we should ask them for their suggestions on products to help them. These too should be open-ended. We don't want to limit their suggestions to features for the product we have envisioned. It might turn out that a very different type of product would be much more valuable.
As they suggest features and characteristics they would like to see, we should (gently) try to ascertain
If we are conducting multiple requirements elicitations, we are apt to hear the same requirements over and over again. This is a good thing (since it reaffirms the value of those requirements). If, however, we have other requirements that they did not mention, there is value in asking how this audience feels about those requirements. We do not, however, want to raise these questions until we have finished gathering their requirements. To do so might contaminate the interviewees with our thoughts.
Once we have gotten most of the suggestions that they have to offer, we can:
Even in these, however, we are still here to listen. We are not here to sell or defend our product concept. We are here to collect the assembled reviewers' responses to it.
Setting up a requirements gathering session is a great deal of work. It would be a crime to go to all of this trouble and not diligently capture the input. One or more people should be tasked with taking notes of the meeting. It is not necessary to capture every word. It is vital to accurately capture all descriptions of roles, tasks and problems, and of suggested features.
If it is not distracting to do so, it may be a good idea to capture these, in real time, on posters or a white board as they come out. This has the advantage of letting everyone see that these things have been noted, and giving them the opportunity to correct, amend, or annotate these key points.
It is also a good idea to summarize key points received at the end of the meeting. After the meeting, a formal report should be written, organizing the input and distilling out the key points learned. The original notes should be kept however ... as it is common for questions to arise about "exactly what he said" or "in what context that remark was made".
After we get back home, we look at the reports from our requirements elicitation sessions, and our lists of requirements and, we find (to our horror) that Alcuin was right: the people are insane!
At this point, it is important to recognize that requirements elicitation is a brain-storming activity. The first phase is a non-critical gathering of all available input. After this phase is complete, we move into the process of clarification, sorting, sifting and synthesis.
If requirements seem unreasonable (e.g. vague, trivial, ridiculous) we need to go back to their sources, and understand the context in which they were suggested. Often this alone is enough to enable us to rephrase the requirement in a more reasonable way. If this is not possible, we may be able to contact the person from whom we got the requirement, and seek a better understanding of its motivation. For all of these reasons, it is important to be able to trace every requirement back to its source.
Conflicting requirements should come as no surprise. We are always forced to find balance between conflicting goals. If we understand what motivated each of the requirements, and their respective priorities, it us usually possible to find a reasonable trade-off. This is why we try to ensure we know what problem every requirement is intended to address, and to obtain priorities for all requirements. Sometimes, however, there are directly contradictory requirements. If you really believe them all to be equally valid, you have to try to find a way to reconcile them:
It is usually possible to work a list of requirements down to a high quality subset. When we are done, our requirements should have the following properties:
After being manipulated by this process, it may be necessary to go back to the various stake-holders (including potential users) and get their approval before continuing.
It is also a very good idea to have a change control procedure for requirements:
Prior to the final evaluations and reconciliations, all of our requirements were "draft". The output of this process is a set of requirements that exhibit all of the above virtues. If all stake-holders can agree on them, we can declare these to be our "final" requirements. This term must be taken with a grain of salt ... because there will almost surely be future changes. In practice, the real meaning of "final requirements" is "a list that is, to the best of our knowledge, complete, and error free" ... and that isn't bad.
In what form should these final requirements be represented?
It is tempting to want to express all requirements as simple, declarative statements. This is certainly the most explicit form, the clearest to developers, and the easiest to verify.
Requirements can also be expressed through use-cases that describe scenarios the system must be able to support. This form, while less precise, may be much more understandable to end users, and may in fact better capture the actual requirements
Processes may be best captured by flow-charts. Information presentation may be most easily charcterized by simulated or sketched screen snapshots. The navigational structure of information may be best represented with class or object diagrams.
There are many possible forms in which requirements information can be captured. There is no "best" form ... but there are forms that are better and worse suited to particular applications, or particular audiences. A good representation is anything that communicates clearly to the indended audience.
We have said that there will almost surely be future changes to the (in our dreams) final requirements. Why?
These and other forces are always acting on any set of requirements. This is why requirements, like schedules, are almost always considered to be living documents.
At the product level, the distinction between requirements and specifications can be a very subtle one:
The waterfall model suggests that we go through a process of requirements elicitation, refinement, and reconciliation, to develop final requirements, that are the basis for product specifications. In actual practice, the relationship between these activities is iterative.
It is actually quite common for requirements and specifications to evolve in tandem, hopefully with the requirements converging and the specifications becoming more complete and detailed with each iterative cycle.
Users! You can't live with them, and you can't live without them!
They are the people you have to satisfy, but they may not understand (or be able to articulate) what they want. It is probably not possible to develop perfect requirements. If, however, we are careful in our identification of stakeholders, the process we use to gather information from them, and the process we use to refine that raw input into product requirements, we can develop much better requirements.