HIGH-LEVEL REQUIREMENTS CAN BE INTERPRETED DIFFERENTLY
As the BA and client stakeholders begin to discuss initial project objectives and goals, both parties start to build a picture in their minds of what a possible solution might look like. It is very likely that these mental pictures are vastly different, and these differences are not likely to be exposed until detailed requirements are discussed, written down, and jointly reviewed.

TEXTUAL REQUIREMENTS ARE NOT ENOUGH
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 only. Building the wrong product can mean a lot of costly rework and an unhappy client. Discussing and documenting requirements using diagrams usually prevents wasted time and confusion about true needs. With visual requirements mapped out, 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 IDENTIFIED
Many business rules and business guidelines are not mentioned during broad requirements elicitation because they seem inconsequential or because the business SMEs take for granted that everyone knows them. These business rules often drive exception processing and can cause major problems if omitted. Every business rule that will be automated by software must be explicitly stated in the requirements. 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 FOR DIFFERENT TEAM MEMBERS
Requirements are usually expressed very differently by business stakeholders than the way that they are understood by the technical team. Ideally, the BA will be able to express the requirements in a format and style that can be understood by both parties. This is a good example of why expressing requirements in text alone is discouraged. Using textual language requires both audiences to share an understanding of terminology that must be precise. The expectation that business people learn IT language or IT people to learn the business language is unrealistic. Developers need requirements to be split into logical, technically related pieces of data. Data needs will be met differently than process needs and should therefore, be presented separately to IT. While some components of the requirements will seem very obvious to business people (for example, screen layouts, reports, etc.), other components will be built into the software and not easily "seen" (i.e., business rules). The business analysis professional has the skills necessary to present requirements in visual formats that can be clearly understood by all groups.

Building Detailed Project Requirements Not Optional

Related Stories

Recommended For You