The interface should be user friendly.
The system should be stable.
The application should work on all mobile phones.
A weekly sales report should be produced
Have you come across such requirements? Would you be able to design and develop a business solution or write use cases on the basis of requirements that are written in this manner? They are neither specific nor complete. Even if a solution is built using these vague requirements, it will be difficult to validate the IT solution against such requirements.
Writing effective IT requirements is critical to business. If requirements are not well-defined, product/ application development will not be as per client needs. The real business issues and problems will also not be solved. Poorly written requirements can also lead to delayed releases, rework and negative impact on cost and revenue. The client will not be satisfied with the end product. This will result in no repeat business from the client for the IT solution provider. The morale of the team will also go down if there is too much rework, too many bugs raised by clients and the end product is unsatisfactory to the client.
A requirements document can be considered as good or complete when it gives a detailed description of business requirements. A well-written requirements document will ensure a common understanding of the application scope and there will be lesser disagreements and conflicts over scope and change management. Therefore it is the responsibility of the business analyst to write a good quality requirements document.
9 things you should keep in mind while writing Requirements Document
Let us see how a business analyst can write a requirements document that will serve as a perfect blueprint to deliver a successful system:
1) A requirements document will have many requirement statements. Each requirement statement should cater to one business need such that at least one separate test case can be created for the same.
2) The requirement statements in the document should be complete sentences devoid of buzz words and uncommon acronyms. It should have any technical implementation details.
3) Each requirement statement should have a user role, intended state and measure to test the implementation.
4) The requirement statements should be concise, clear and consistent. It means it should be easily understood by technical and non-technical people and such that multiple interpretations are not possible. They should be as objective as possible.
5) The requirement statements should be verifiable and viable. This means the requirements should be testable and feasible from a technical, economic and business perspective.
6) Requirements can change. Some of them require more discussion or research. In case a requirement changes or new requirements have to added, the business analyst should review the change and the project team should validate it from a technical and business perspective. The team should assess its impact on the project cost, efforts and schedule. A formal change control process should be used to update the change and the traceability should be captured. The version of the requirements document should be updated and project team and stakeholders should be intimated of the change.
7) The requirements document should have the functional and non-functional requirements elicited separately.
8) Most IT organizations will have more than one Requirements Document template as per project type and client needs. As a business analyst it is better to use one of these templates to create the project requirements document as the template must be made by many experts together and also tested and improved upon as many project teams would have used it.
9) The requirements document written the first time should be treated as a draft. It should be reviewed by stakeholders and a final document should be made. Stakeholders also get more clarity about requirements as they read what is written down. This will take more time and effort but decrease number of bugs in testing phase and wrong development due to unambiguous requirements which are very costly to rectify.
Examples
Here are examples of requirements statements and the reasons as to whether they are well defined requirements or not
How Writing Better Requirements help?
Well defined requirements help the client, solution design team, development team and quality assurance Good requirements will optimise cost and effort. It will help in managing change as well. Well-written requirements will minimize conflicts between different teams as well as between solution provider and client.
Let us know your comments on what constitutes a good requirements document and its benefits for your project.
Comments