Preface

Requirements Tree Diagram is my brain child. For some reasons I couldn't publish this work in formal manner, so ultimately decided to make this information public through here. Please fee free to share your comments.

---

Let's Begin !!!

For a project to be successful, from any field that project might be, its requirements should be clearly understood by the people implementing it. Lots of efforts have been put by people all over the world to systematically transform the requirements into the final goal. However surprisingly very less effort are invested in systematically capturing the requirements itself.

Requirements are very important for a project to be successful. Ambiguity in requirements is perhaps one of the greatest causes of failure of the projects. Ambiguity causes scope creep, missed deadlines, run-away costs, under/over utilization of resources, and others.

In software applications, significant efforts are put to systematically transform the requirements into design and then to the code. Every application has certain goal. This goal can be categorized into number of sub-goals, called as requirements. Requirement is a behavior expected by application at given conditions. To deliver the application as per the expectations, the utmost important thing is to understand all the requirements correctly, and to understand the requirement it is very important to thoroughly gather all the information related to the requirement.

Tools like UML provide various systematic approaches like Class Diagram, Sequence Diagram, Communication Diagram etc. to implement the functional specifications. However on Requirements gathering front, very few tools are available. Diagrams like Use Case Diagram and up to some extent Activity and State Machine Diagrams are available in this region. However these diagrams are not sufficient enough to capture all the requirements. Rather we can say that it's not the purpose of these diagrams to capture all the requirements. Since requirements are always changing, up to some extent it is correct not to waste our time in capturing all the Use Cases (in case of Use Case Diagram) or Activities (in case of Activity diagrams). However at the same time, it is very risky to assume any requirements. So in real world scenario, although system Analyst doesn't capture all the Use Cases and Activities in respective diagrams, he/she always tries to capture all the requirements in some or the other format.

Most common formats used for gathering requirements are either text format or spreadsheet format. System Analyst comes up with a format which he/she thinks is best suitable one and easy to understand. Many organizations have their standardized formats in terms of templates. However till now there is no format common across the world. Moreover, many times, requirements captured in text format are full of bulky paragraphs, which make it difficult to understand them (particularly if writer is lingo-savvy and/or the reader is weak in the language). Again System Analyst chooses the sequence in capturing the requirements based on past experience. Some times it is also customer-driven. So there is always a possibility of missing any requirement as there is no check if all the requirements are thoroughly captured.

It is always a tedious job to track all the requirements captured in big text documents. If any requirement is to be modified, analyzing the impact of these changes on other requirements and on entire system is always a challenge.

Requirement Tree Diagram tries to provide better solution to above said problems. Requirements Tree Diagram is a systematic approach in gathering the requirements. It tries to capture requirements diagrammatically rather than putting them into bulky paragraphs. It also provides the relationship between the requirements, based on these relationships; it is simple to identify the impact of changing one requirement on the entire system.

Requirements Tree Diagram itself cannot capture all the requirements entirely. However in conjunction with other tools like flow charts (for business logic processing), Screen Transition Diagrams, Data Flow Diagrams etc. Requirements Tree Diagram can play a vital role in systematically capturing the requirements. Like all UML diagrams, almost everything in Requirements Tree Diagram is optional. This diagram gives user a liberty to capture the information he/she wants. However at the same time, it helps the user in checking the completeness of captured requirements. Requirements Tree Diagram has ability to question the user at various levels during gathering requirements. User gets a clearer picture of requirements as the diagram expands. However the extremity at which requirements to be captured is still a user’s choice.

---