Table of Contents

1Introduction.................................................................................................................................2 What is Requirement?..................................................................................................................3 Requirement Gathering Challenges...........................................................................................4 Requirement Volatility - Causes..................................................................................................5 Types of Requirement .................................................................................................................6 Requirement Gathering Techniques...........................................................................................7 Relative Strengths in Requirement Gathering Techniques.....................................................15 About Author...............................................................................................................................16

Requirement Gathering Techniques

1 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 the requirement from the customer. Requirement gathering team can use the effective and efficient requirement gathering techniques while collecting the requirements from the customer. These requirement gathering techniques are not specific to any projects. Person who involve in the requirement gathering phase, can use this document as a reference in order to complete the requirement gathering phase successfully.

Page 2 of 16

Requirement Gathering Techniques

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 project life cycle. Because if the requirement gathering is not done properly/ completely, all below hierarchy phases get incomplete. No matter how best the design, until unless requirements are in complete. So we should carefully plan and carryout 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 worlds and technology worlds are constantly changing.

Page 3 of 16

Requirement Gathering Techniques

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. Because the impact of above points are huge in 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 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 signed-off document is changing frequently which means that we have not collected the requirement properly or customer had not gone through the document properly before sign off. No project team member will have control over the requirements if requirements changes 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 customer had gone though each and every point specified in the document and had got clear understanding of 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 delver the project to the customer successfully in time, we should not get experienced in any one of the above points.

Page 4 of 16

Requirement Gathering Techniques

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

Page 5 of 16

Requirement Gathering Techniques

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 its not worth mentioning. Undreamed Requirements: Undreamed requirements are those that the stakeholders do not ask for, either because he thinks they are not possible or because they are new ideas that have occurred to them. Non Functional Requirements Non functional requirement basically talks about hardware and software requirement of an application. It 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.

Page 6 of 16

Requirement Gathering Techniques

Requirement Gathering Techniques

Analysts report that poor requirements management accounts for as much as 71% of software project failures. A structured approach to requirements capture and management resolves these problems and is the only way all stakeholders can be confident that all requirements have been understood and incorporated into the project plan. Using a structured approach to gathering requirements allows us to develop S.M.A.R.T objectives (Specific, Measurable, Achievable, Realistic, and Time-based) which nearly guarantees the success of the project. The overall goal is to ensure a focused project direction, a solid schedule, and an accurate budget. Scientific approach requires a constant description of all activities, objectives and corrective measures to counter potential loopholes. One can do better requirement gathering using a scientific approach rather than random technique selection.

6.1 Apprenticing Technique

Observes the Business Users

Understands the Day to Day Activities

Capture/ Documents the Requirements

Gets Sign off from Customer

What is Apprenticing and when to use it? Analyst observes what the Business User does and understands Analyst becomes a part of what Business User does Useful when Business Users cannot spare enough time

Page 7 of 16

Requirement Gathering Techniques

Useful when the stake holder has trouble in communicating the requirements Note: Effective for Unconscious Requirements

6.2 Brainstorming Technique

Brainstorming involves two phases. They are Idea Generation and Idea Reduction and Voting. Method: Give each participant to sticky sheets with marker for jotting ideas. Rule: No criticism or debate Let Imaginations Soar Generate as many ideas as possible Mutate and combine ideas A) Idea Generation Facilitator explains the objective of process For example: a) What features would you like to see in your product? b) What services would you like to see product provide? c) What things would you like product to keep track of? Each participant then reads his ideas and notes it down. No criticism, and if natural silence occur, let it exist. B) Idea Reduction and Voting Prune ideas not worthy of further investigation. If any disagreement about some idea, let it remain. The index of healthy brainstorming session is the number of ideas discarded which proves people are thinking out of the box. Group ideas according to a) New features b) Performance Issues

Page 8 of 16

Requirement Gathering Techniques

c) Enhancements to current features d) UI and Ease of use Else group ideas based on capability like a) Marketing and Sales b) Customer Service c) Accounting Once ideas have been grouped, walk through each idea and get feature definition from contributor. Prioritize the idea and have cumulative voting to distribute amongst ideas. Benefits of Brainstorming technique: Encourages participation from all. Allows participant to piggyback on others ideas Results in broad set of solutions Encourages out of box thinking Most effective ideas originate from multiple seemingly unrelated ideas What is Brainstorming and when to use it? Helps in getting as much as ideas as possible in different perspectives. Consolidate the ideas and evaluate it to get the requirements. Useful when there is a group of stake holders addressing the same problem. Note: Effective for Undreamed Requirements

6.3 Mind Mapping

In mind mapping, we will discover the fragments of knowledge that we can capture by observing, listening, questioning and suggesting. Below is the summary of mind mapping laws. a) Use Emphasis Always use a central image Use images throughout your mind map. Use three or more colors per central image.

Page 9 of 16

Requirement Gathering Techniques

Use dimension in images and around words. Use variations of printing, line and image. Use organized spacing. b) Use Association Use arrows when you want to make connections within and across branch pattern. Use colors Use codes c) Be Clear Use only one Key Word per line. Print all words Make major branches connect to central image. Connect lines to other lines. Make your images as clear as possible. d) Layout Use Hierarchy Use Numerical Order What is Mind Mapping and when to use it? By observing, listening, questioning and suggesting you will discover fragments of knowledge that you can capture. Use Pictures, Colors, Symbols that your brain perceives the subject matter. Useful when you are summarizing your understanding. Mind map is a way to take more extensive and meaningful notes. Note: Effective for Undreamed Requirements

6.4 Use Case Workshops Technique

Use case workshops technique is more popular now a days. In this technique, we collect the requirement in step by step manner. Also it helps both requirement analyst team and customers to understand that even the obvious

Page 10 of 16

Requirement Gathering Techniques

and minute details should not be ignored. It is easy to document and written in natural language. Advantages of Use Case Workshops Technique: Use cases can be described very simply to prospective user of system. Written in natural language and easy to document. Provides simple structured format where development team and user can work together to define behavior of existing or new system. Early feedback can be obtained about user interfaces. What are Use Case Workshops and when to use it? Capture details of requirement in step-by-step manner. Normally, people converse in transaction mode. Use Case Workshops help to force a step-by-step narration mode. Helps both the requirements analyst team and customers to understand that even the obvious and minute details should not be ignored or omitted. Note: Effective for Conscious Requirements

6.5 Interviewing Technique

This Interviewing technique is useful when you have time and opportunity to talk to business user. In this technique we fix up the time with business user and attend the session and note down the information in notebook. Below table describes little clear idea about interviewing technique. Stake Holder 1 Requirements #1 Definition Scope Date of Interview Deadlines and Boundary Definition Scope Date of Interview Deadlines and Boundary .. Stake Holder 2

Requirements #2

Requirements #3

Page 11 of 16

Requirement Gathering Techniques

What is Interviewing and when to use it? Guidelines: Define a purpose and boundary. Have a fixed time limit. Talk to stake holders who have hands-on experience. Use Models and sketches LISTEN, LISTEN, LISTEN Most useful when you have time and opportunity to talk to the Business User.

Note: Effective for Conscious Requirements

6.6 Family Therapy Technique

This technique refers to all stake holders in the project. This technique works based on the model Intake Meaning Significance Response. Below table structure describes little clear idea about Family Therapy technique. Stake Holder 1 Requirements #1 Intake / Idea Meaning Significance Responses / Consolidations Intake / Idea Meaning Significance Responses / Consolidations .. Stake Holder 2

Requirements #2

Requirements #3

What is Family Therapy and when to use it? Family in this context refers to all stake holders in the project. This model is based on Intake Meaning Significance Response

Page 12 of 16

Requirement Gathering Techniques

The analyst tells a idea (Intake), stake holders attach a meaning to it (Meaning), decide how we feel (Significance) and the analyst consolidates it (Response). Useful with diverse group of people. Note: Effective for Conscious Requirements

6.7 Reusing Requirement Technique

This technique is used when multiple things are present for single common purpose. In some project, there could be possibility that, two are more modules have same functionality. In this case we can re-use the functionality and save the time. How to Re-use the requirements? There might be number of functionalities inter-connected by a common purpose. Try to re-use them. It is possible that the requirement might be useful in another part of the project. Try to re-use them. Note: Effective for Un/Conscious Requirements

6.8 Videos and Photographs

This technique applies to all type of requirements. When we are not able to understand the requirement properly in that case, we can re-visit the videos and photographs and get more clarity on the requirements. Videos and Photographs, when do they help us? When you cannot understand the requirements immediately, Videos help you to revisit and get more clarity. Prevents communication loss / gap between on-site and off-shore teams as off-shore teams gets access to direct version from the customer. Note: Effective for all types of Requirements

6.9 Prototyping
In this Prototyping technique, generally we create prototype of an application and will be presented to the customer to make sure we and customer are having same understanding of an application. In this technique, customer will check only the functionality aspect not how/what code is written in prototype.

Page 13 of 16

Requirement Gathering Techniques

Customer will traverse the prototype application and these prototypes will provide a data flow functionality overview from one end to another end of an application. Generally prototype application contains hard coded values, to display specific valid data on the page to the customer. Prototypes are basically mock ups of the screens of an application which allow customers to visualize the application that is not yet constructed. Prototypes help customers get an idea of what the system will look like, and make it easier for design team to make design decisions without waiting for the system to be built. Major improvements in communication between customers and developers were often seen with this prototypes technique. Early views of the screens led to fewer changes later and hence reduced overall costs considerably. This has been a very powerful tool to capture and gain customers confidence and almost all projects do it. Advantages of Prototyping Technique Gain customer confidence about our understanding Reduce the overall costs considerably as changes to prototype would be fewer. Improvements in communication between developers and customers. Design team can make design decision freely with the help of prototype. Receive early feedback from the customer

Page 14 of 16

Requirement Gathering Techniques

Relative Strengths in Requirement Gathering Techniques

Below table explains the strength of each requirement technique. TECHNIQUE Apprenticing Brainstorming Mind Mapping Use Case Workshops Interviewing Family Therapy Reusing Requirements Videos and Photographs CONSCIOUS 2 1 2 3 3 1 2 2 UNCONSCIOUS 3 1 2 2 2 3 2 2 UNDREAMED 1 3 3 2 1 1 1 2

(1 Limited Effectiveness, 2 Effective, 3 Very Effective)

Page 15 of 16

Requirement Gathering Techniques

About Author
Nagendra Gunaga is having 5.5 years of experience in IT industry. His experience is in .Net Framework, C#.Net, ADO.Net, ASP.Net, SQL Server and Microsoft Office SharePoint Server. Involved in requirement gathering aided him to compose this White Paper.

Page 16 of 16