We use the term, 'Requirement Gathering' everyday. This usually implies a group of analysts collecting the requirements from the user. 'Gathering' forces us to think that requirements are already available, we just need to find them.
But in practice, it is not exactly true. Requirements are rarely seen on the surface. They are buried deep beneath the layers, hidden from the eyes of the analysts or even the user. Perhaps this is not the right one, but it's better to remember Steve Job saying:
"People don't know what they want until you show it to them"
Digging for Requirements
The hardest part is to recognize a true requirement while digging through the dirt. For that, we need to know what a requirement is. Let's start with a basic one:
"An employee record may be viewed only by a nominated group of people"
This is an example of a good requirement. Why? Because this implies something that the system requires in a general way. Let's dig in further. Consider the following:
"Only an employee's supervisors and the personnel department may view that employee's records"
Is this statement truly a requirement? Perhaps today. But what if the policy changes tomorrow and somebody else can also view an employee's record? Then we'll have to re-write the requirement. But first example applies even after the policy change. It is always important to know why the users are doing certain things rather than knowing how they are currently doing it.
What's the best way to get inside our user's requirements? The answer is simple: become a user. Sit with the user while she's doing her job. Think and understand from the perspective of the user. We'll see how the requirement collection changes from a mere boring task to something remarkable.
Work with a User to Think Like a User
- summary of Digging for Requirements, from The Pragmatic Programmer: from Journeyman to Master
But in practice, it is not exactly true. Requirements are rarely seen on the surface. They are buried deep beneath the layers, hidden from the eyes of the analysts or even the user. Perhaps this is not the right one, but it's better to remember Steve Job saying:
"People don't know what they want until you show it to them"
Digging for Requirements
The hardest part is to recognize a true requirement while digging through the dirt. For that, we need to know what a requirement is. Let's start with a basic one:
"An employee record may be viewed only by a nominated group of people"
This is an example of a good requirement. Why? Because this implies something that the system requires in a general way. Let's dig in further. Consider the following:
"Only an employee's supervisors and the personnel department may view that employee's records"
Is this statement truly a requirement? Perhaps today. But what if the policy changes tomorrow and somebody else can also view an employee's record? Then we'll have to re-write the requirement. But first example applies even after the policy change. It is always important to know why the users are doing certain things rather than knowing how they are currently doing it.
What's the best way to get inside our user's requirements? The answer is simple: become a user. Sit with the user while she's doing her job. Think and understand from the perspective of the user. We'll see how the requirement collection changes from a mere boring task to something remarkable.
Work with a User to Think Like a User
- summary of Digging for Requirements, from The Pragmatic Programmer: from Journeyman to Master
No comments:
Post a Comment