Subramanya S M, Technical Architect, Quadwave
Requirement Elicitation and Analysis
Introduction
Any project/release-cycle typically starts with a set of requirements being provided to a lead, to either come up with the ball-park estimate or a detailed one. For any project, be it a short-term or a long-term project, it is very important that the requirements are clear and complete. This could be ensured by requirement elicitation and analysis, rather than just requirement collection/gathering.
Requirement Analysis
Requirement analysis is taking account of all the possibly conflicting requirements of the various stakeholders, analyzing, validating, and documenting the requirements. It involves requirement elicitation, projecting out all the possible alternate and error flows in the (proposed) solution, and documenting all the dependencies. Typically, development of user scenarios, identifying use cases, and/or mock-ups/prototypes can be considered for the analysis.
Requirement Elicitation
Requirement elicitation is the process of bringing out all the details required for the successful implementation of a solution – catering to the demand of the end-users and other stakeholders – to the complete extent, without any major deviations, either in the planned efforts or in the schedule. Requirement analysis that includes requirement elicitation is the cornerstone of the project success and any let-off in the same would invariably result in effort and schedule overruns.
Requirement elicitation can be broadly classified as functional and non-functional.
Functional Requirements Elicitation
Functional requirements mainly comprise of the use-cases that need to be delivered by the solution. While eliciting the functional requirements, one needs to go much beyond the requirements provided, in the form of a simple definition of a problem or even in a detailed functional requirement document. The steps involved in the elicitation of functional requirements are detailed below.
- It is essential to identify diverse users of the solution being sought along, with their needs/pain points, which are to be addressed by the solution. In the case of complex solutions, it would be beneficial to talk to the typical end-users involved (through planned requirement workshops) and get a complete feel of their expectations from the solution. In case, if it is not feasible, a role-play can be used to understand all the possible usage scenarios.
- Come out with all the possible usage scenarios, even if some of them are only theoretical possibilities. Identify the practical scenarios and explicitly rule out the others.
- For each success-flow, identify all the alternate flows and the error flows.
- Identify all integrations involved with external systems.
- Check if multi-tenancy is required.
Non-Functional Requirements Elicitation
Non-functional requirements are as important as the functional requirements, if not more. Following are the list of important aspects to be noted. Of course, there can be more than just these for a given solution.
- Environments in which the solution needs to run – Development, Testing, Staging, and Production environments with all the details like OS version, service pack version, application/web servers and their versions, databases and their versions, target browsers and their versions, server hardware – RAM, processor speed, HDD space, etc. The more detailed the relevant aspects, the better is the output.
- Technical details of the integrations involved, like Socket details, Definitions of web-services, XML/file structures, Success/Error codes, etc.
- Performance parameters and the load conditions in which they are applicable.
- Short term and long term projected loads, in terms of total users, peak concurrent users, the size of important data like number of records, memory consumption, etc.
- The volume of data to be loaded at any point on to the memory or onto a web page in real time.
- Any other technological constraints imposed/dictated by the stakeholders.
Requirement Elicitation and Analysis in Agile Development
In an agile sprint based development approach, the elicitation and analysis of all the requirements may not happen in one go. However, the elicitation and analysis need to be done for the requirements being scoped for a particular sprint, during sprint planning or even earlier. It may also happen that, a couple of scenarios out of many possible ones may be picked for implementation during a sprint. Even in such cases, it is advisable to document the scenarios that are not being taken up in the sprint for the sake of clarity, for all the stakeholders.
Also, in the agile development, the non-functional requirements need to be elicited and analyzed beforehand so as to make proper technological choices at the very beginning, and to avoid major changes in the later stages.