Statistics presented by Assay, 2008 states that 62% of the IT projects fail before completion. Hence, one of the biggest challenges in IT development projects is to successfully deliver projects - on time, within budget and with expected functionalities.
According to study presented by Meta Group, 60-80% of project failures can be attributed to poor requirement gathering practices and analysis of the requirements. Small and medium enterprises often struggle with budget allocation for IT projects. This leads to a compromise where business analyst(s) are not included in the team. Developers are given the task to visualize applications and develop it accordingly. However, due to lack of proper training in business analysis, developers fail to ask the right questions to ascertain the complete scope of the project. Also, developers tend to start programming as soon as possible. This leads to a situation where developers are working on application without completely understanding the scope and vision of the project.
The objective of this article is to discuss the best practices for requirement gathering and analysis that increases probability of success of IT projects.
There are a number of techniques that may be used to gather requirements. They are:
Brainstorming: it is used to get as many ideas as possible from a group of people to find solutions to problems. Information once gathered needs to be reshaped and combined. Also, prioritization of results is done.
Interviewing Users: Face to face interview can be conducted with customers, business users, domain experts and industry analysts to gather and validate requirements.
Sending Questionnaires: This technique is used where face to face interviews are not possible. The questionnaire should be designed such that it is able to capture the complete scope of the project.
Studying similar system: Analogous systems in the form of competitor's product, product in market that does not completely fulfil client's need or an old system that needs to be modified based on current business needs may be available. In these cases, studying such system as a starting point help in envisioning the new application.
Talking to support team: Talking to the support team helps in capturing requirements desired by the real users of the product.
Looking for unintended use: At times, users use things for purposes that they are not designed for. This may lead to creating a new and innovative product.
Joint Application Development Sessions (Workshops): These sessions are conducted so that participants can collaborate to document requirements. Session ends only when session objectives are complete.
Observation: Observation can be passive or active. It helps in identifying implicit requirements. Analysts are also able to prepare a process flow and identify pain areas, awkward steps and opportunities for improvement.
Interface analysis: Application needs to be analysed with the interface of product with other external applications to capture requirements that are not immediately visible to users.
Non-functional requirements that include application performance, number of normal and concurrent users, page response time, hardware and software requirement of the application, also need to be properly captured and documented. It is essential to note that while documenting non-functional requirements, it is advisable to write specific requirements rather than wishful statements like 100% reliable, handle all unexpected failures. Instead, precise statements like website page should appear in 1s in broadband internet connection of speed 1 Mbps or website should support 1,000 concurrent users and a load of 2,000,000 users should be used.