In my last blog I talked about where the value lies in documenting requirements – and that value is that clearly documented requirements allows for better understanding across project team members and business stakeholders exactly what the focus of the project should be. In this Blog #2, let’s talk about the importance of detail in those requirements. We all can agree that requirements have to be discussed and agreed upon at a very detailed level. This is a very important step because the activity itself ensures that the business stakeholders have carefully thought about and have answered in detail questions about their business, their business processes and have clearly communicated their needs. Requirements also need to be detailed to give the development team clear direction about the expectations.
Now, analyzing and developing requirements at a very detailed level is time consuming, and for this reason, many project managers and business analysts don’t go deep enough. Business stakeholders and/or managers don’t understand why requirements take so long to develop, and most developers don’t like to get very detailed requirements because it suppresses their creativity. Despite the benefits detailed requirements can provide, the factors just mentioned all serve to explain why the industry is still so poor at defining requirements. They also explain why agile approaches to projects are initially appealing – no documenting of requirements. When working with their clients, PMs and BAs must clearly explain the importance of capturing detailed requirements. Organizations that do not understand the value behind detailed requirements will not invest the time.
High-Level Requirements Are Interpreted Differently
Until the BA and business stakeholders get into very detailed discussions about how the business process will be accomplished, analysis work is not complete. As the BA and stakeholder discuss initial project objectives and goals, the BA begins to build a picture in his or her mind of what a solution might look like. Meanwhile, each business stakeholder also has a picture in his or her mind. It is very likely that these vague sketches in the minds of individual team members are different. These differences will not really be exposed until detailed requirements are discussed, written down, and jointly reviewed.
Many Analysts Only Use Text to Document Requirements
Textual requirements are by their very nature ambiguous and incomplete. It is difficult to capture the complexity of a business area or technology specification with text. When requirements are not detailed enough, developers will build the product they see in their mind which most likely will not match the picture in the mind of the BA or of the business stakeholder. Building the wrong product means a lot of costly rework and an unhappy client. This is not to say that developers can’t provide great creative solutions, but they need to understand the constraints around which features (or components) can be designed creatively and what areas need to follow strict business guidelines.
Discussing and documenting requirements using diagrams usually prevents wasted time and confusion about true needs and wasted business user time adjusting to a change. Any change to a business area is disruptive. The BA can help discuss the ramifications of a change with the business stakeholders before the requirement is complete to make sure the change is appropriate and necessary.
Complex Business Rules Must Be Found
Many business rules are not exposed until very-low-level detailed requirements are discovered and documented. Many business rules and business guidelines are not mentioned during requirements elicitation because they seem inconsequential (too detailed) or because the business SMEs takes for granted that everyone knows them. These business rules often drive exception processing and cause major problems if omitted. Every business rule that will be automated by software must be explicitly stated in the requirements. With business rules, the requirements should include the desired exception processing, including the exact wording of any warning or error messages. Helping the business SME think about how they expect to see business rules enforced often exposes other business rules and more detailed requirements.
Requirements Must Be Translated
Requirements are usually expressed very differently by business stakeholders than the way that they are understood by developers. The BA acts as a liaison or translator, and the requirements are the tool for that translation. Ideally, the BA will be able to express the requirements in a format and style that can be understood by both the user and the technical team. This is the reason why expressing requirements in text is discouraged. Using language requires both audiences to share an understanding of terminology that must be very exact. For business people to learn IT language or IT people to learn the business language is a waste of time. The business analysis professional has the skills necessary to present requirements in visual formats that can be clearly understood by both groups. In addition, developers need requirements to be split into logical, technically related pieces. Data needs will be met in a very different technology than process needs, so these should be presented separately to IT. Some components of the requirements will be very obvious to business people (screen layouts, reports), while other components will be built into the software and not easily “seen” (i.e., business rules). These requirements should be documented and presented separately.