Requirements Documenting – The Foundation of a Project’s Success
Receive free IIBA updates and exclusive content!
The next step after finalizing the business case for the initialization of a project which contains business analysis effort and eliciting business needs and respective information from engaged stakeholders is formulating and translating these thoughts, needs, claims and aspiration into requirements.
Documenting requirements is a task of high importance as it’s the foundation phase that can lead to success in the other business analysis phases. A requirement document will be used in design, in developing, in creating a user’s manual, in maintenance of the system developed and in future reuse for another project. Requirements of any kind influence the analysis, design, implementation, and test phases directly and indirectly. Requirements documents may also support the change management activities. When requirements change, the requirements document can serve as the basis to analyze the extent to which other parts of the system are influenced. The change effort can thus be estimated.
We have to highlight that existing documentation usually servers as the basis for maintaining and reusing requirements. Additionally, requirements documents like BRDs or FRDs can be the basis for legal contracts and other type of agreements with vendors and other stakeholders. Documenting the requirements can help to quickly overcome legal conflicts between two or more parties.
Requirement documents can take many forms. There are many well-known structures and templates for such types of documents and many approaches in each requirement description from natural language to specific models. From my point every case is different and tailoring every approach to the specific project’s conditions is the only way to have a suitable result. If different structures are not tailored, it is unlikely that the Business analysis effort and approach are appropriate for the needs of the project. This can lead to ’robotic’ project management at one extreme (the method is followed without question).
However the following characteristics of a Requirements Document are necessary:
- Clear Structure: Α clear structure is necessary. Every involved part with access to the document must find what he is looking for easily. He can skip parts that does not need and to focus on the valuable elements.
- Traceability in document and in requirements: The traceability of relationships between requirements documents and other documents (e.g., business process model, test plans, or design plans) is one of critical success. Moreover each requirement itself must be traceable. A unique identifies and some structured information fields per requirement may serve this goal. Furthermore, in Requirements Life Cycle Management Knowledge Area of BABOK® Guide a traceability Repository is suggested. Requirements management tools can provide significant benefits when there is a need to trace a large number of requirements that may be deemed unmanageable with manual approaches.
- Consistency: Εvery requirement included in a BRD or FRD must be understandable, clearly stated without any chances of misinterpretation. Requirements documents can be consistent and unambiguous only when the individual requirements are consistent and unambiguous.
- Holistic View: Νever forget that a requirement document except detailed requirements must present the larger picture. Getting and documenting a wider view of the business problem, integrating different views of the problem and the conditions cause the problem and grasping the connections between requirements, design, and testing in the solution domain must be mirrored in a requirements document.
Documenting findings and results is a part of a business analyst’s roles. It is the proof that the job is done and it’s one of the outputs that will evaluate the business analysis competency of an individual. We document the requirements to show we have arrived at a stable solution to the business problem. Documentation is a means for recording completed communication.
About the Author:
Giorgos Sioutzos works in the business consulting industry as a business analyst. He has experience in projects from different sectors and holds a BSc in Management Science and Technology from Athens University of Economics and Business and MSc in International Business & Management. He has published numerous articles about business and technology issues in Greek and foreign media.