| “Measure twice, cut once” |  | |
| “Look before you leap” |
What do these sayings have in common?
They're about thinking before acting.
Why? Because it saves time, money, effort and embarrassment.
It's plain common sense, yet, when it comes to software development, this common sense seems to disappear.
All too often, projects start before thought has been put into the project's purpose, its desired results, and how its success will ultimately be measured.
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 lifecycle. 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 incomplete.
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 minute saved at the start is just as effective as one saved at the end
Tell me and I'll forget,
show me and I may remember,
involve me and I'll understand
For more info about Software Development Lifecycle refer to SDLC.
The sooner you begin coding the later you finish
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:
Reasons are:
| “If you don’t know where you’re going, any road will take you there” - Lewis Carroll |
A user will tell you anything you ask about, but nothing more
Conceptually, requirements analysis includes three types of activity:
The task of communicating with customers and users to determine what their requirements are.
Determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues.
Requirements may be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications.
A user is somebody who tells you what they want the day you give them what they asked for
Have you experienced these situations in the project?
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 lifecycle. 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.
Steve McConnell, in his book Rapid Development, details a number of ways users can inhibit requirements gathering:
Possible problems caused by engineers and developers during requirements analysis are:
If we don’t beat these challenges, 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 lifecycle. 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. The business analyst should help users reviewing the documentation till getting them signed off.
Due to this project plan, estimations and other project management aspects gets affected and also our milestone deliverables changes.
The impact of change in requirement would be more and affect the entire project plan and consumes extra time to do impact analysis, estimation.
To deliver the project to the customer successfully in time, we should not get experienced in any one of the above points.
| “What if users developed their own applications?!” |
What is not on paper has not been said
There are two types of requirement volatility causes.
I’m trying to write a DOS bat file that runs an Access macro to import a CSV output file from my COBOL program. Any help would be appreciated
There are basically three types of requirements:
Conscious requirements are those that the stakeholders are particularly aware of.
Unconscious requirements are those that the stakeholder knows the requirement so well that he thinks that it's not worth mentioning.
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 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.
Requirements are the What
Design is the How
Studies have shown that as many as 4 out of 5 software development projects go over time, over budget or don't deliver expected results (The Chaos Report, 1994 Standish Group). With such long odds, it pays to put in the effort upfront to minimize the risk of failure. The question is, how do we achieve this?
There is no one perfect method for gathering and analyzing a project's requirements. If there was, we'd all be using it. Rather, there are many approaches to choose from
What is Apprenticing and when to use it?
Note: Effective for Unconscious Requirements
Brainstorming involves two phases. They are Idea Generation and Idea Reduction and Voting.
Method:
Rule:
a) Idea Generation
For example:
Each participant then reads his ideas and notes it down.
b) Idea Reduction and Voting
Benefits of Brainstorming technique:
What is Brainstorming and when to use it?
Note: Effective for Undreamed Requirements
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
b) Use Association
c) Be Clear
d) Layout
What is Mind Mapping and when to use it?
Note: Effective for Undreamed Requirements
Use case workshops technique is more popular now 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 and minute details should not be ignored. It is easy to document and written in natural language.
Advantages of Use Case Workshops Technique:
What are Use Case Workshops and when to use it?
Note: Effective for Conscious Requirements
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.
| Stakeholder 1 | Stakeholder 2 | Stakeholder n | ||
|---|---|---|---|---|
| Requirements #1 | Definition | |||
| Scope | ||||
| Date of Interview | ||||
| Deadlines & Boundaries | ||||
| Requirements #2 | Definition | |||
| Scope | ||||
| Date of Interview | ||||
| Deadlines & Boundaries |
What is Interviewing and when to use it?
Guidelines:
- Most useful when you have time and opportunity to talk to the Business User.
Note: Effective for Conscious Requirements
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.
| Stakeholder 1 | Stakeholder 2 | Stakeholder n | ||
|---|---|---|---|---|
| Requirements #1 | Intake/Idea | |||
| Meaning | ||||
| Significance | ||||
| Response/Consolidations | ||||
| Requirements #2 | Intake/Idea | |||
| Meaning | ||||
| Significance | ||||
| Response/Consolidations |
What is Family Therapy and when to use it?
Note: Effective for Conscious Requirements
This technique is used when multiple things are present for single common purpose. In some project, there could be possibility that, two and more modules have same functionality. In this case we can re-use the functionality and save the time.
How to Re-use the requirements?
Note: Effective for Un/Conscious Requirements
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?
Note: Effective for all types of Requirements
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. 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:
The following table explains the strength of each requirement technique.
Users don't know what they want until you show it to them
Focus is the most import aspect of any requirements document. A good requirements document clearly states the objective of the project and defines its scope, to clarify what the project does and does not cover.
Discussing the many ways in which requirements can be gathered can end up in a heated and impractical debate. The short answer is that you should gather requirements using whichever method works for you, the most important outcome is that the people who need to understand the requirements can do so. If the people that form the project team (client, stakeholders, designers, developers) are happy with the format, that's half the battle won.
This is not to say that all formats of requirements documentation are equal. If you happen to believe that use cases are effective, but your client doesn't understand UML, then it's going to be difficult for them to effectively review the document and identify any errors. This increases the risk of misinterpretation. If the document is too technical, the client is likely to assume it's correct because they don't really know otherwise. These sorts of assumptions don't surface until the work is done, at which point it becomes far more expense to fix. This scenario brings us back to the purpose of a requirements document: to avoid these mistakes in the first place.
So, if you have a format that you, your client and your project team are comfortable with, stick to it.
The art of writing requirements takes great skill and, like writing code, the end result is usually cleaner and more consistent if there's a single author. Great care should be taken in selecting the author. It's a matter of balancing the need for a thorough understanding of the project domain (i.e. the client's business) against understanding the process of software development. An author with a great understanding of the project domain but no experience with software development is a risky choice. So is an author with no understanding of the project domain but extensive experience in software development. Ideally, you want to aim for an author that has both.
If there's only one rule in the use of language then it's to use the same language as your client. It's that simple. If the language is consistent, it greatly lowers the risk of misinterpretation of the requirements. For example, a recent project contains a product catalogue for seeds. In the first draft we categorized the seeds into 'types', 'categories' and 'sub-categories'. While this made sense to us, the client and other stakeholders use the terms 'crop', 'type' and 'variety'. This was bound to cause problems if we didn't use the same terms as the client. A useful technique to avoid this problem is to include a glossary of terms and definitions in the requirements document.
There's little use writing requirements if they are not an accurate reflection of what the client wants. We've found the best way to deal with this is to walk the client through the requirements, as they'll rarely read them on their own. If it takes five reviews to get it right, then so be it. While it can become a drain to do multiple reviews, persistence pays off. Remember: it costs many times more to fix things in testing than in the requirements phase.
Having said that, don't expect to get the requirements 100% correct. You need to allow for human nature. A requirements document is a statement of 'what' the end result has to achieve. Even with the best intentions in the world, sometimes when we arrive at the end result, it just doesn't work the way we expected -- it's a fact of life. So, the requirements should capture what the client wants, but allow for change as long as the objectives are still being met.
Being clear and unambiguous is difficult. In law, there are rules for interpretation, but even then, those rules are applied by judges who have their own interpretations of how to apply the rules. What does that mean for requirements? It's important to ensure everyone has the same understanding. One of the best ways to minimize the risk of different interpretations is to include examples: diagrams, pictures, or sample data that illustrates what the requirements mean.
Don’t give me best practices, they are yesterday’s news.
Give me emerging practices, they are tomorrow’s news.
What “Requirements Gathering” is all about is info transferring and sharing. The “Requirements” document can be considered as the real project contract between the user and the developer, and it is also the first draft of the project plan.
In brief:
The Requirements Document is
the Business coded version of
the User’s Specifications written using
the Human Programming Language!
To approach this description, there are some advised best practices to make sure that the user’s business requirements will be smoothly translated into the “required” program. Among these best practices are some suggested tips to be taken into consideration while producing the requirements artifact be it a document, a prototype, a list of features… using the aid of whichever techniques of the previously mentioned ones.
The requirements should include the following:
The “Approvals” section is the first step determining stakeholders even if they don’t participate in the requirements gathering exercise. Approvals list includes the stakeholders names, their titles and their signatures.
The “Objectives” section also known as the “Problem Statement” section gives the reader of the document a brief idea about the purpose of the project and the needed system. It gives an overview about the system and may describe the background of the problem and the impact of implementing the requirements.
The “Scope” section clearly states what should be covered by the proposed solution and what will not covered. It determines the “In Scope” and “Out of Scope” requirements.
The “Business Goals” section helps developer and business stakeholders understanding the goal of the project and sharing the same view.
As requirements gathering and analysis is an intermediate step between the business requirements and the to-be developed system, it is very important to ensure that all stakeholders and developers have a common understanding. As humans, this is almost impossible to achieve, at which point the importance of the “Assumptions” section emerges, it helps all stakeholders viewing, as much as possible, the requirements from the same viewpoint. Assumptions may include business, technical and planning assumptions.
The “Constraints & Risks” section helps identifying problems facing the product implementation at early stages, thus facilitating decision making and project planning. Constraints and risks may be business and/or technical.
In the “Pre-requisites” section you can define any dependencies the project will be rely on and will not be launched unless they exist.
The “References” section refers to other helper systems or documentation.
In the “System Actors/Users” section, we define the users who will have access to the system with a brief description about their roles.
As an example, we can use a table to represent actors and their roles:
| User/Actor | Role | Comments |
|---|---|---|
| Student | Review schedule |
Then comes the “Functionality” section in which each of the roles/functions is described clearly. As a best practice, you can give a little description about the functionality, the expected fields to be manipulated and the actions to be performed to achieve the required function.
Example:
After logging in to the system, the student should be able to review the schedule by viewing the list of subjects, dates and time. Fields to be accessed by the student can be:
Actions to be performed by the student are:
The “GUI Requirements” section headlines the user needs for the GUI. It can describe the look and feel, include some screen shots or refer to the prototype.
The “Non-functional Requirements” section includes the user’s requirements regarding 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.
It is also healthy to use questionnaires. Questionnaires help getting quick and precise answers to vague requirements. A proposed template is:
Signoff is the final and most important step in the requirements gathering process. By signoff, the requirements should be freezed and later request for changes should be treated separately. Before signoff, it is a good practice to take a second opinion about the requirements, it is preferable to involve technical opinion in the requirements to ensure their feasibility before finalizing the agreement with the customer. To ensure the effectiveness of the requirements, it is better to review them with the customer before the signoff process.
I know that you believe that you understand what you think I said but I am not sure you realize that what you heard is not what I meant.
To be able to understand users, needs, system requirements and improve suggestions, a good Business Analyst should be involved. The Business Analyst must have the majority of the following skills:
Continuous effort to improve the quality of software development activities
There is no silver bullet, no one answer, no perfect approach method or technique to requirements gathering. Developing a good requirements document is about giving your project the best chance of success. To do so, you must reduce the risk of common mistakes that arise from a lack of communication or understanding. Keep this in mind as you gather your requirements, and the documentation - and project as a whole - will have the best chance of success.
