The success of a business solution is directly related to the clarity with which the problem has been defined. The business solution project has a great impact on the performance of both the Customer team and the solution provider.
This white paper clarifies the role of documentation as a foundation for building a successful business solution project.
Why should the requirements be documented?
The first reason of documenting requirements is to clearly identify the issues in the business scenario relevant to the project. The second is to get agreement (of both, customer team and the team of the solution provider) on what you are about to build, before you actually start building it. Thirdly, documenting requirements from beginning, helps trace the changes made to the requirements and thereby help people understand how it will affect the time and financial investments of the project.
Studies have shown that spending time doing requirements management can pay big dividends in terms of on-time, on-budget project delivery. If a project doesn’t get the requirements right, it is difficult to implement correctly or test correctly. Without good requirements management, all aspects of the project will suffer.
Who should document the requirements?
The documents can be prepared by either party. The person documenting requirements must be very familiar with, and sensitive to, the actual customer organization needs that the requirements are intended to solve.
Typically, this job is given to a person having good analytical power, communication skills and writing ability. That individual must have a direct access to the stakeholders who have expressed the needs that drove the requirements. This individual also must be intimate with the customer organization needs and act as a customer advocate to the project team (The team may consist of people from both sides, customer and solution provider).
Who benefits from requirements management?
Ultimately, the project benefits the most. The customer organization benefits because there are increased chances of getting the project delivered on-time and within budgets. The software team benefits because they can clearly identify the resources required, estimate time and investment needs more accurately and test the milestones vis-à-vis the requirements.
The requirements serve as an expression of the solution that the whole team is working to deliver. As a result, it’s important to communicate requirements by making them accessible to all team members (please refer to the definition of team above). This ensures that your project starts on track, and stays on track.
While many teams are practicing some method of requirements management, most teams vary in their requirements management maturity. Those with ad-hoc or less formal methods for managing requirements generally do not experience negative consequences until later in the software development lifecycle and they may not even recognize these consequences as requirements management issues.
Some of the symptoms teams may experience from ineffective requirements management can include a lack of development resources, numerous software mis-matches and significant amounts of rework involving more time and money.
Should the requirements be prioritized?
Yes. Simply documenting requirements is not enough. You need a way to select which requirements to implement first.
If the requirements are simply documented as textual statements, the prioritization process often lacks objectivity and priority is based on who is most vocal about a requirement or who carries the most weight in your organization.
Projects are most often broken-up into milestones. At every milestone achievement, the picture becomes clearer. It starts becoming apparent as to how the software will help resolve the problems and speed up the business processes.
To make this possible, the team must qualify requirements with information such as customer priority, level of effort, and stability. By assigning specific attributes when documenting requirements, you can objectively determine which requirements make the most business sense to address first.
Can the requirements be documented in one go?
Although a noble goal, it is unrealistic to expect requirements to be complete the first time you document them.
You need to leave room in your schedule for reviews that highlight inconsistency, conflicts, or incompleteness in your requirements documents. Requirements reviews are critical because they improve the quality of requirements upon which the development team bases its work. Incorrect requirements can result in rework and throw your project off course and cost extra money.
……………………………………………………………………………