Introduction
The purpose of this document is to highlight the different types of requirement gathering techniques which will be helpful for the requirement gathering team while gathering requirements from the customer. The requirement gathering team can use effective and efficient techniques while collecting requirements from the customer. These techniques are not specific to any project. The person who is involved in the requirement gathering phase can use this document as a reference in order to complete this phase successfully.
Requirement gathering is a process of collecting the user needs to solve a problem or issues and achieve an objective. It is basically a software capability needed by the user to solve a problem or achieve an objective. This is really an important phase/ milestone in a the project life cycle. If the requirement gathering is not done properly/ completely, all the hierarchy phases given below stay incomplete, no matter how best the design, until and unless requirements are complete. So we should carefully plan and carry out the requirements gathering with a systematic approach.
It is not quite accurate to say that requirements are in the minds of clients; it would be more accurate to say that they are in the social system of client organization. They have to be invented, not captured or elicited and that invention has to be a cooperative venture involving the clients, the users and developers. The difficulties are mainly social, political and cultural and not technical.
A Standish group research report says that, 31% of all projects are cancelled before they ever get completed and nearly 53% of projects cost almost twice their original estimates. The reasons are:
- Users have trouble in explaining what they want.
- Developers have trouble in translating user requirements into working programs and databases.
- Both the business world and technology world are constantly changing.
Have you experienced these situations in the project?
- Scope and Vision not clearly defined
- All requirements are critical, no priority is defined
- Signed-off requirements keep changing
- New requirements get added in the middle of the project
- Users/customers are busy and not available to specify requirements
- Functionality built, rarely or never used
If we are experienced in the above points, it is an indication that, we would not be delivering the final product to the customer successfully in time. The impact of the above points are huge in the project/product life cycle. Assume if the scope of the project is not clearly defined, it means that we are not sure about the objectives. We need to clearly define and state what is in the scope of the particular project and what is out of scope. Once we have it on paper, we need to get a review from the customer and agree to this definition of scope to ensure everyone is clear about what will be delivered at the completion of project. If the signed-off document is changing frequently, it means that we have not collected the requirement properly or that the customer had not gone through the document properly before sign off. No project team member will have control over the requirements if requirements change frequently. Due to this project plan, estimations and other project management aspects gets affected and also our milestone deliverables changes. It is not a best practice even though we are handling the requirement changes using change management process. We always make sure that the customer has gone though each and every point specified in the document and has got a clear understanding of the application needs before sign-off. The impact of change in requirement would be more and affect the entire project plan and consumes extra time to do impact analysis, estimation, creating traceability matrix and resource, etc. To deliver the project to the customer successfully on time, we should not experience any one of the above points.
There are two types of requirement volatility causes. They are internal and external factors.
- Internal Factors
- Not capturing requirements from all relevant stake holders
- Not using right requirement capturing technique depending on the context
- Not capturing all relevant details
- Not having measures such as check-list to ensure completeness of requirements captured
- Not having measures to ensure clarity
- External Factors
- Market driven
- Need to be handled and managed
There are basically three types of requirements. They are conscious, unconscious and undreamed requirements.
- Conscious Requirements
Conscious requirements are those that the stakeholders are particularly aware of.
- Unconscious Requirements
Unconscious requirements are those that the stakeholder knows the requirement so well that he thinks that it's not worth mentioning.
- Undreamed Requirements
Undreamed requirements are those that the stakeholders do not ask for, either because they think they are not possible or because they are new ideas that have occurred to them.
Non Functional Requirements
Non functional requirements basically talk about hardware and software requirement of an application. They also talks about application performance, number of normal and concurrent users, page response time. They address business risk.
Non-functional requirements are properties the product/ project must have, such as the desired look and feel, usability, performance, cultural aspects, availability, reliability, maintainability, extensibility, security and so on. This section discusses the types of non-functional requirements, and shows you how to use the template, and other methods, to find the all-important qualitative requirements for your product/ project.
Requirement Gathering Techniques
Please download the Word document which explains types of Requirement Gathering Techniques.
History
- 17th April, 2007: Initial post
