Fairdeal S​oftware Consultants

Business Requirement Analysis Resource

Benefits of Good Business Requirement Analysis

• 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

Today, you have methods that capture the requirements in a  quick manner yet accurate and complete- techniques that are flexible but also structured to produce high-quality documented specifications. It is essential that companies perform a comprehensive business requirement gathering initiative to see that the project for application development can be a successful activity.

Methods / Techniques for Requirement Analysis

• One-on-one interviews
• Group interviews
• Facilitated sessions
• Joint application development (JAD)
• Questionnaires
• Prototyping, Flow charting, block diagrams, sequence diagrams etc.
• Use cases
• Following people’s work routine
• Brainstorming
• Domain Modelling, Process modeling

Business Requirement Analysis Process

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.

• Prototypes and other diagrams
• Flowcharts
• System Requirements Specification Document (SRS)
• Functional Specifications Document (FS)
• Use Cases

1. 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).

2. 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.

3. ​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. xt. Click to select the text box. Click again or double click to start editing the text.

4. Keeping requirements Feasible and Relevant Click to select the text box. 

• You need to ensure that the requirements being captured and documented are relevant to the solution under consideration. There may a lot of needs but are all those needs going to be met by the software which is going to be developed.
• 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.

5. Inadequate Review, Feedback, Closure

The requirements need to be reviewed by the client and all stakeholders need to come to an agreement that the requirements reflect the needs adequately. If the requirements are properly signed off it will help in meeting expectations and having satisfied customers.

Five Essential Guidelines for business requirement analysis

1. 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.
2. The Scope of the Project and Products should be clearly defined in the Vision /Scope document.
3. Prioritize the requirements by their relative importance gives the performing organization the focus for the project,
4. It is important that the identified requirements are detailed enough so that they can be quantified and also measurable.
5. 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.

Five Tips for Getting Requirement Analysis Right

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?

Apart from answering the above questions, a high level or top management view description of the solution needs to be developed and the business needs it is going to address needs to be documented.

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.

4. Define the features required.

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.