BY Kristine Slaboszewski
One of the first steps in any project is to gather requirements from stakeholders, understand them and then verify them with the same stakeholders. Once verified, requirements can be given to developers and they can go on their merry way. But there are some who don’t see the value in documenting requirements.
FOR THOSE WHO MAY NOT SEE THE VALUE IN DOCUMENTING REQUIREMENTS, I OFFER THE FOLLOWING REASONS FOR ENGAGING IN THIS CRITICAL STEP:
PEOPLE ARE FORGETFUL
Without a dedicated team member like a Business Analyst (BA) whose role is to actively look for requirements, the project can quickly become an attempt to herd cats. When planning a large scale project, business stakeholders talk to a lot of people. The more people they talk to the more the idea evolves. As ideas evolve, requirements are often forgotten or misconstrued. This leads to a lot of wasted time and frustration while team members try to remember each iteration of the discussion.
VERBAL COMMUNICATION IS LOADED WITH ERRORS
Remember the game telephone we used to play as kids? The idea was that a message starts out as one thing but as it is passed from one person to another it changed, until the final message was completely different from the original. Requirements are very specific, detailed items that can easily be changed by using a different word or phrase. Verbal communication of requirements will rarely be accurate.
PEOPLE SOMETIMES ANSWER THE SAME QUESTION DIFFERENTLY IF ASKED TWICE
As I mentioned above, as the business stakeholder talks to multiple people the idea can easily change. Stakeholders may inadvertently give different messages to different people at different times. This, of course, leads to ambiguity and leaves everyone wondering “just what are we supposed to do here?” And sometimes stakeholders simply change their minds. BA’s are experts at asking the same question in different ways before documenting the requirement to be sure that the Subject Matter Expert (SME) has really answered definitively.
WRITING SOMETHING DOWN FORCES A PERSON TO BE MORE EXPLICIT
For example, a SME may indicate that he wants a report to show totals by month, but when he actually sees the report layout with 12 columns crammed together, he may realize that what he really wants are only the totals for the last three months.
WRITTEN REQUIREMENTS ALLOW SCRUTINY THAT CAN REVEAL AMBIGUITY AND POORLY DEFINED REQUIREMENTS
It also identifies missing requirements and undocumented assumptions.
NEW TEAM MEMBERS CAN GET UP TO SPEED QUICKLY
This is most effectively done by having requirements documented.
CLARITY IN EVALUATING AND MANAGING TEAM MEMBERS’ ASSIGNMENTS
Actually this holds true for all employees in any role, and is the reason why HR departments encourage managers to articulate assignments accurately. It is difficult to hold someone responsible for carrying out (or not carrying out) a task when the requirement for that task is not documented anywhere. Likewise, it is difficult to convince a client that an end product meets their stated needs if there are no documented requirements to refer back to.
Once we understand the importance of eliciting, documenting and verifying requirements we can understand the importance of detail in those requirements. Laying out detailed requirements at the outset of any project ensures that the business stakeholders have carefully thought about and have considered the needs for their business, the business processes involved, and have clearly communicated those needs. Detailed requirements also give the development team clear direction about what is expected.
Despite the many benefits provided by detailed requirements, many project managers and business analysts don’t go deep enough because they believe that the process is too time consuming. Additionally, business stakeholders don’t understand why requirements take so long to develop, and developers often believe that the requirements process suppresses their creativity. As a result, the industry is still doing a poor job overall when it comes to defining requirements. Many consultants are instead using agile approaches to projects, which may seem more appealing and less time consuming at the outset, but often result in greater difficulty at the end of the project when work has to be redone, satisfaction is not garnered and client needs are not met.
HERE ARE A FEW COMPELLING REASONS TO TAKE THE EXTRA TIME TO BUILD DETAILED REQUIREMENTS AT THE OUTSET OF A PROJECT:
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.
Kristine Slaboszewski is a Senior Business Analyst at Rightpoint, a digital agency and technology consulting company. The author can be reached at firstname.lastname@example.org.