Monzamarine make business yours
Related Articles
When a Software product has to be developed, one of the first tasks in the Project Manager’s schedule book is Requirements Analysis.
What is Requirements Analysis?
Simply put, Requirements Analysis process aims to identify and document the customer’s requirements for a proposed system.
A trained software practitioner called the Requirements Analyst(RA) communicates with knowledgeable user(s) to understand what the requirements are. Most times, the client will have a brief idea of what they need in the proposed system.
The Analyst’s job is to flesh it out, add implied requirements and mandatory or regulatory requirements the client may not be aware of and create a document called the Software Requirements Specification or SRS.
At the end of the process, the SRS turns out to be the blue print of the product. A reference point for the client, the project manager, the tester and the designer. The SRS should ideally restrict itself to specifying “what” the product should do rather than “how” to do it. Never include implementation details such as database structure, architecture and so on.
What should the Software Requirement Specification include?
Ideally, an SRS should include at the least the following information.
Functional requirements
Functional requirements are the “features” a software has. Example Requirements for a shopping cart are Browse Shop, Detailed product view, checkout, View cart, My Account.
The analyst should also identify requirements that the customer has missed or those that are required to support the main features. These requirements are called Implied Requirements. For example, if the client has asked for a Shopping site, the analyst includes requirements for the Shopping cart such as the View cart, Checkout and Delete from Cart.
Non functional requirements
How efficient is the Software product? Is it high performance, is it reliable, how fast is it, does it consume a lot of system resources. These are aspects dealt with in the non functional requirements. Novice programmers generally fail to address these requirements. These requirements directly affect the quality of the product.
Regulatory requirements
In many industries, there may be regulations within which the software product should comply. For example, the tax laws of the country in which an accounting product has to be deployed. Language preferences, password encryption laws, URL standards, email standards. These are some of the regulatory requirements which the client may not be aware of. The analyst has to include these requirements if applicable to the industry or country in which the software product is to be deployed.
External Interface Requirements
Will this product interact with other software or hardwares? The analyst need to list the minimum requirements of these interfaces.
Acceptance criteria
Finally, the acceptance criteria has to be stated. What criteria will confirm that the software is working as per the client specification. Usually, the tested specifications will be the functional and non-functional requirements stated in the SRS.
It is important that all requirements should include the Feature Number. This improves traceability of each feature throughout the project lifecycle. At the design, construction and at the testing phases, the project members know that they are designing, coding or testing Feature No. FE-2 or FE-45.
Prioritizing Requirements
The SRS should include priorities for each feature. Clients may ask for some features to be completed early on. A carefully Prioritized requirements document leads to quicker development of the more important features.
Isn’t the Software Requirements Specification (SRS) a waste of time. Who benefits?
Thats a fallacy. The SRS is useful to everyone who has anything to do with the project. The project manager knows what to plan for. The designers know what to design. The testers know how the product is expected to work. All with the SRS.
Finally, the SRS helps the customer the most. The customer knows what he will get in the end. Generally, development starts only after the client reads and approves the SRS. For example, if the customer wants the Shopping site system to include a Wishlist, he can quickly scan the SRS and ask for the Wishlist to be added if it is already not there. Increased customer input so early on in the project, helps everyone know what is to be developed and what needs to be developed first.
Review Software Requirements
Getting the requirements right in the first place costs 50 to 200 times less than correcting code. It is important to review the SRS before it goes into the next stage.
Typically, a review session will include at least 3-4 experts and will be held for a maximum of 2 hours per session. The attendees will read the doc prior to attending the meeting. A good review will unearth about 60-90% of the defects in the product.
Some software development companies ignore this crucial meeting leading to disastrous consequences. A simple requirements review will result in a Net Schedule savings of 10-30% . And yes, these inspections are about 20 times as effective as testing the product. It comes as no surprise that each hour spent on review avoids an average of 33 hours of maintenance.
Managing requirements change
No project is static. Requirements may change and a good Project Leader should learn to anticipate that. However, each change in requirements costs time and money, especially if crucial changes come up during Coding or testing and worse if it comes in after development.
The Analyst “has” to try to minimise late changes as far as possible. The best way to do that is to show the customer what he is going to get using small prototypes and the SRS. Customers can easily see what they are going to get and ask for changes much before any development has begun. This way the analyst manages to reduce cost for the customer.
In case changes do occur, during or after coding, the Project leader has to ensure that these changes are controlled. All changes in the specification should be approved by the customer and should be reviewed by team members. All team members should get copies of the latest specification.
Most projects generally experience a 25% change in requirements. Good requirements methodlogies will reduce the No. of changes and cost per change. For example, if the RA could reduce number of changes to 10% and the cost of change by a factor of 5 or 10, the combined effect would be really huge.
Can’t you code without requirements analysis.
You can code without any analysis, design or even testing. This is what most programmers do.
Customers, project leaders and coders generally under-estimate the value of good requirements analysis and give it the go by because a software product “can” be developed without proper requirements, design or testing.
But problems start surfacing in several unrelated incidents.
For instance, tester claim they have completed testing and submit the project to the customer. The customer says “Hey this is not what I wanted. I wanted the shopping cart to be stored in case the shopper decides to complete the ordering process after 2 days?” The tester may not even have known of this requirement, the coder wouldn’t have known, the project leader wouldn’t have known. Finally everyone works overtime to develop this new feature. The coder will claim that it is impossible to develop this feature with the existing design. Then the designer has to twist the design to somehow include the new feature. Will it be optimum design? Well who knows? No one has the time to find that out. Eventually after all that confusion, the customer is given the new feature which is poorly designed and executed.
Is requirements analysis important in smaller projects.
In smaller projects, the same person could analyse, design and code. As the project size increases, all that happens is that the roles are taken over by different people. What is small project? Any project over 2 weeks duration should necessarily include the requirements analysis process.
