License To Crack - Requirement Analysis phase

After the contract is signed off between the SDU and the clients, this phase is the main focus of the project managers and stakeholders. Meetings with managers, stakeholders and the users are held in order to determine the requirements.

User Requirement Specification (URS)

The SDU must now know what the client wants in the software project. To ease the process, many clients (alternate terms for clients are customers or users), prepare formal documents, which describe their need. This document will describe in detail about what is expected out of the software product, from the users perspective. This is called User Requirements Specification. This will use the same terms and nomenclature that the customer uses in the day to day business.

This is the base document for the functionality of the product. This will be prepared and reviewed by the user community, mainly by experienced users. As an example, the URS of Railways reservation system will talk about how the reservation, cancellation etc. are carried out in an actual reservation counter. The very idea is that, these are the activities that are going to the computerized and if these are properly documented, then it will be easy to proceed in the actual product development. In some countries, a few clients write this document in their native language and not necessarily in English.

Software Requirements Specification (SRS)

After the URS is defined, a team of business analysts, who are having a very good domain or functional expertise, will go to the clients place and get to know the activities that are to be automated. This includes thoroughly understanding the URS, item by item. The URS may not be in an understandable language and format, for the developers and testers. So SRS is derived based on URS, to provide clarity to the development team. If the SDU does not know what is to be computerized, it cannot develop software that satisfies the customers. So, understanding the requirements is very essential in software in software development process. Most of the times, the business analysts, together with expert users, will frame a single document, which will serve as both URS and SRS. This way, there will be only one document which will serve as a functional commitment document between the customers and the SDU.

Requirements Collection

The role of a business analyst is very vital to this process. Before we start talking to clients on project features we must know the domain well. The SME (subject matter expert) meets various people who are in charge of the day to day business activities in customer's core business. For example, if we develop a software for an insurance agent, we must know what he/she does with customer, we must know what detail he/she collects, how they fill up forms, how they arrive at premium amount, who approves it etc. if this can be clearly documented in plain English, the same can be used for development.

The SME must collect all fillable forms, receipts, reference numbers, approval papers, etc. Also the pain areas of customer must be documented so that the same can be computerized.

The SME must talk the same language, jargons, code words, acronyms with the customer, This will create trust with users and they will exchange more information to SME. The SME must make no assumptions. If there are any open or doubtful issues, that must also be documented along with the specs as annexure. Any sample forms must be scanned and attached to the specs. Specs can contain flowcharts as well. See the example flow for a car service centre.

Before going and meeting the client, the SME must do a lot of home work and prepare a clear list of questions. The time one spends with client is very precious and we must not waste client's time. Simple questions like a checklist will answer complex issues. Eg.

1. How many levels of approval is required for a purchase order?

2. Do you apply service tax for your services or are you exempted?

Once the SME drafts the requirements as described by the customer and end users, the specs must undergo an internal review. The project manager must review the specs. Then the same must be sent to the client for review. The review will clearly bring out the understanding level by the SME on what the customer wants. There are chances that the SME missing some of the points told by customer, or the SME understood it in a different way or the SME added something that the customer did not want/tell. Hence customer must review the specs very carefully. Once customer raises questions on the specs, SME must correct those areas and resend for review. This may take a few back and forth emails, a few telephonic calls etc. Finally when the customer says, "Yes, this what I want in the software", ask him to send an approval email or to sign off and printed version of specs.