Business Requirement Analysis
What is meant by "Business Requirement Analysis"?
Requirement Analysis for software development projects is the exploratory, developmental activity of helping users figure out what they want and recording the same for further use in the subsequent phases of development. Conceptually, Requirements Analysis includes three types of activities:
- Requirement Capture: the task of communicating with all stakeholders to determine what their requirements are.
- Requirement Analysis: the task of making the stated and unstated requirements clear, complete, unambiguous and detailed enough.
- Documenting Requirements: Requirements may be documented in various forms, such as
Process Specifications documents
Functional Specification documents (FS)
Software Requirement Specification documents (SRS)
- Interview the subject matter experts and identify the business needs or functional needs
- Organize the information which may be complex into simple subject areas
- Translate the language from business into technical and vice versa to make it easily understandable by all stakeholders
- Involve the stakeholders at all levels
- Draft written communication that is clear as well as concise for both users and technicians
- Work successfully with teams that are generally multidisciplinary
- "The damage was worst when non-IT business analysts were in charge of the requirements. Those projects came in at nearly double their budgets and took more than 245 percent of their allotted time.
- When IT workers managed the requirements analysis, the results were only slightly better, with budget overruns at 163 percent and time at 172 percent.
- The best results came when business and IT worked together on defining requirements."
Business Requirement Analysis Resource
An experienced analyst knowswhat questions to ask and should have good communication skills that are effective. Knowledge and experience in using modeling techniques that are easy to understand become handy in communicating the requirements to all stakeholders. One of the most common causes of changing requirements later in the project is when the right questions are not asked at the beginning of the project. An approach that can lead the analyst and the business users to discover all the requirements related to data flow, business rules, and functionality, and which will result in a complete and accurate representation is essentially a simple but systematic process that enhances the chances to get business specification right the first time.
By using a skilled resource to perform business requirement analysis for your next project could make a significant difference in terms of benefits that are accrued from the project.
- Cost Savings
- Shorten your development cycle
- Get a product that meets your needs on time
- Boost the team’s productivity
- Reduce rework and conflicts arising from unclear and ambiguous requirements
- One-on-one interviews
- Group interviews
- Facilitated sessions
- Joint application development (JAD)
- Prototyping, Flow charting, block diagrams, sequence diagrams etc.
- Use cases
- Following people’s work routine
- Domain Modelling, Process modeling
The cost of quality in software development is dependent on capturing the requirements early. The schedule of the projects gets often delayed due to poor requirements definition in the early phases of the project which are subsequently modified during the project life cycle. Overall the business requirement analysis becomes one of the most important processes for successful delivery of project and product benefits and the bottom line for the business owner and the performing organization.
Business Analysts (BA's) or Requirement Analyst can employ several techniques to elicit the business requirements of the product or service from the customers. This includes things as holding interviews, holding focus groups, creating requirements lists, prototyping, and use cases. Where necessary, the analyst will employ a combination of these methods to establish the exact business requirements from all stakeholders involved, so that software that meets the business needs is produced.
Business requirements for software development must be measurable, testable, and defined to a level of detail sufficient for system design.
We outline below some of the important aspects of business requirement analysis which are needed for successful gathering the requirements and recording them.
There are three levels of requirements that are commonly gathered.
- Business Requirements - The highest level objectives for a given project are generally recorded in the Vision or the Scope Document for the project.
- User Requirements - Task and facilities that are to be made available to the end user are recorded using Use Cases or some other technique.
- Functional Requirements - A document by this name or some other name is generally used to record the behavior that the software must exhibit. This needs to be recorded for all the features expected from the product. "Software Requirement Specification" called SRS in short or a document by another name is needed by developers from where they can understand the quality attributes and any other requirements including non-functional specifications for the product that is being built.
Option 1:If you are going in for a waterfall model kind of development in which you would be getting the software developed once the requirement analysis process is complete in that case we provide comprehensive documentation covering all requirements gathered in one or all of the following depending on the needs of the project
- Prototypes and other diagrams
- System Requirements Specification Document (SRS)
- Functional Specifications Document (FS)
- Use Cases
In case's of iterative and rapid software development, when we provide requirements gathering services, we think of an iterative process and provide simple sketches, screen drawings, some use cases, and even functional, running prototype software pieces that will help with that iterative process. All of these make up the requirements.
- Teams speak a different language
The IT teams want to talk about technology and want answers to their "How's".
The Project Managers want the scope so that they can fix the budget and schedule.
The CEO talks business.
So, where is the common ground ........
Hence it is important that the person doing the requirement analysis to cater to requirements from all stakeholders and create a common ground and tries to captures the 3 W's (What, When, Where).
- Pushing for Development to start
It is unfortunate that sometimes people do not realize the importance of doing the requirement analysis right; the emphasis is on getting to the coding /development at the earliest.
If the requirements are done right they can save a lot of time and effort down the road in fixing and re-fixing bugs and issues. Overall the development cycle will be smaller if enough time is spent on the requirement analysis phase. The statistics are there to prove this.
“From the studies made by various software development communities, it is evident that most failures in software products are due to errors in the requirements and design phases – as high as 64 percent of total defect costs according to Crosstalk, the Journal of Defense Software Engineering .”
So do not give into the pressure and emphasize on getting the requirement phase it's due.
- Delaying the documentation - We will document along the way
What if that person(s) knowing the requirements leaves or moves onto another project?
What if you have to stop the development and re-start it after some time?
On what will your testing be based on?
How will you know if what you wanted has actually been understood?
How will all concerned be in sync in terms of what is required?
Sometimes people want to cut corners and leave the documentation to be done later. If it is all in a person's head there are bound to be mistakes.
Even for small projects you need not go in for elaborate documentation but document enough to avoid issues mentioned above.
- Keeping requirements Feasible and Relevant
You also need to keep the requirements are in line with the rules and regulations of the company, regulatory authorities, government etc.
Examples – You might specify a date format of mm/dd/yyyy in your requirements; it will be valid in the USA. Is your software only for use in the USA? If yes, it is fine but if it is for global use this format may not be valid in the country of use. The same applies to currency.
- Inadequate Review, Feedback, Closure
Five Essential Guidelines for business requirement analysis
- Even though end-users or the customers may be challenged for giving time during the requirements capture phases of the project, it is important that they are involved as the project success is heavily dependent on this phase.
- The Scope of the Project and Products should be clearly defined in the Vision /Scope document.
- Prioritize the requirements by their relative importance gives the performing organization the focus for the project,
- It is important that the identified requirements are detailed enough so that they can be quantified and also measurable.
- Despite all precautions, some changes are inevitable which might have to be factored in and hence it is important to enforce a clear and realistic process for necessary change management during the project and product lifecycles.
The requirement analysis and capturing process should result in adequate documentation which will cover the following aspects
1. Define the Problem and High-level description of the solution.
The requirement Analyst needs to understand the problem and the need for the solution. The questions which need to answered are
- What problems is the proposed solution going to resolve?
- What benefits is the company going to derive from the solution?
- Are the requirements implementable?
2. Identify and document the needs of all the stakeholders including the users of the solution being developed.
You need to make sure that needs of all stakeholders are understood. You also need to understand the needs of the people who are ultimately going to use the solution/system. This is very important so that the solution delivers on all counts.This will also help in identifying conflicting requirements if any.
3. Define what the solution should and should not do.
You should not only define what the solution should do but also define what the solution will not do. State the requirements in a manner that nothing is left for imagination or which creates doubts.
Elaborate on the features required in the software solution. In Technical terms define both the functional as well as the non-functional requirements. Try to capture the "What's" and not "How's".
5. Capture all supporting information.
Include details about the Processes followed, Workflow, Information flow, hierarchies etc. Record any other information which might be relevant to the solution under consideration. Identify the source of all requirements and have them in documented in such a way that they are manageable.
Once you have applied all the above tips you will have Feasible, Non-conflicting, Unambiguous, Traceable and Testable Requirements.