Click here to Skip to main content
Click here to Skip to main content

Requirement Gathering Techniques

, 16 Apr 2007
Rate this:
Please Sign up or sign in to vote.
The purpose of this document is to highlight the different types of requirement gathering techniques

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.

What is Requirement?

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.

Requirement Gathering Challenges

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.

Requirement Volatility - Causes

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

Types of Requirement

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

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

Share

About the Author

I have about 10 plus years of experience in professional software development with extensive involvement in Web based Object-Oriented, Multi-Tiered application design and development. I have experience in working with Content Management System and Portal Management System tools like SharePoint and also had experience in Integration of SharePoint with Commerce Server, Exchange Server.
 
Currently I am working in a Software firm Hewlett Packard Global Soft Private Limited as SharePoint Solution Architect located in Bangalore, India. My main responsibilities include designing SharePoint solution for a large enterprise product, automating SharePoint Deployment, Developing WebParts, Managing SharePoint Authentications. You can contact by emailing me at nagendragunaga@gmail.com

Comments and Discussions

 
QuestionPurposefully wrong requirements Pinmemberanandssunku13-Dec-14 6:48 
GeneralVery Good Article! Kudos. Pinmembershahzaib11-Oct-08 20:35 
GeneralBetter resource PinmvpMark Nischalke17-Apr-07 7:28 
GeneralRe: Better resource Pinmemberribawaja17-Apr-07 8:28 
GeneralRe: Better resource PinmvpMark Nischalke17-Apr-07 9:26 
GeneralRe: Better resource PinmemberSteveC-A918-Apr-07 5:17 
GeneralRe: Better resource PinmvpMark Nischalke18-Apr-07 6:30 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.141223.1 | Last Updated 17 Apr 2007
Article Copyright 2007 by NagendraGunaga
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid