How to know how much detailed requirements should be?

Question

This doubt has to do with the requirements gathering phase of each iteration in one project based on agile methodologies. It arose because of the following situation: suppose I meet with my customer to gather the requirements and he says something like: "I need to be able to add, edit, remove and see details of my employees".

That's fine, but how should we register this requirement? Should we simply write something like "the system must allow the user to manage employees", or should we be more specific writing for points

1. The system must allow the user to add employees;
2. The system must allow the user to see details of employees;
3. The system must allow the user to edit employees;
4. The system must allow the user to delete employees;

Of course, this is just an example of a situation I was in doubt. The main point here is: how to know how much detailed I must be, and how to know what I should register? Are there strategies for dealing with these things?

Thanks very much in advance!

Answer 1

The goal is to (1) deliver a system that satisfies the customer and (2) ensure the people using the requirements have everything they need. Provide the minimal detail level that performs both and you have answered your question.

More specifically, does your organization have any requirements standards? I assume not from your question but common templates or previous requirements documents may imply the level of detail required. Ask senior people in your organization, too.

Who will be using the requirements, such as developers, UX and QA? In your example, how much do they know about employees? Have they been working on similar systems for years and probably know it better than the customer or are they new to this type of system? For example, will they know what fields an employee has and their validation rules? If not, include these. See below for more examples.

What level of acceptance requirement detail does the customer require? Are they willing to experiment with several build/measure/learn cycles (less detail) or do they have detailed and strict compliance requirements (more detail)?

Capture when a requirement is not important (e.g. no system up time requirements) because the lack of a requirement can be just as important.

Requirements can be specified in different ways. Many prefer user stories or use cases. A UML sequence or activity diagram may be better for complex processes. Communicating requirements well is just as important as ensuring they are complete and consistent.

Not all requirements are suitable for all audiences. For example, customers confirming the system meets their requirements will likely want different information to developers doing the low level implementation. Consider splitting large lists into smaller ones for various audiences.

Beyond this and perhaps slightly off topic, requirements gathering is more than just specifying what the customer asks and to what level of detail. What requirements can you add? For example (hardly a definitive list):

1. Will employees be added in bulk? If so, does the UI need a bulk addition option (e.g. a table) instead of a form? Can they be imported form an HR system instead?
2. Who will enter the employee details? Who should not be allowed to see employee data? Who authorizes new users and removes old ones? If someone makes a change, does it need to be audited? How long should the audit logs be retained? Do changes need to be approved by others?
3. How many employee records will there be? Ten? Ten thousand? Ten million? How will they be searched, sorted and filtered? How many people will be accessing the system simultaneously?
4. Where will the employee details be entered from? A web browser on a desktop computer in the organization's office or a mobile device used by the site foreman at a construction site?
5. What is the impact of the system going down? Can I patch the systems during business hours?
6. Are there reasons why I could not consider an "off the shelf" system instead of writing it ourselves?
7. Does the customer require I follow any standards, e.g. Common Criteria, FIPS 140, ISO 27001? Is there contractual or legal requirements for retention or privacy?
8. Organizations often impose implicit requirements. For example, can the project's costs and timeline be estimated from the requirements? If not, what is missing? How does this fit into my organizations technology strategy?
9. Are there any constraints on development, such as fixed deadlines, budget limits or technology constrains?

This really adds value, particularly when requirements gathering becomes a two-way conversation with customers.