Certain terms within requirements signal details are missing, thus ensuring additional discussions. Discovery sessions are the norm but when a requirement document has the follow statements, requirements are not completed.
1.) The number one offending term:;TBD – “To be discussed” or “To be Determined.” A requirement with the letters “TBD” is not a requirement and stops the progress of the technical team to interpret what to delivery. It is clearly evident the requirement was not thoroughly thought out and clearly stated to communicate the desired purpose.
2.) General Statements. A general statement, such as “the system should display information.” What are the elements of information to display? Is there an order information should follow? General statements go back to the earlier discussion on “The What of Requirements.” A requirement should detail presentation of information.
3.) Missed References: A missed reference is a when a requirement refers to a specification but the section is absent or miss-numbered making the statement a guessing game.
4.) “But Not Limited To.” The statement is designed to grant the author some wiggle room so the requirement is not written in stone. The statement itself “but not limited to” delivers an uncertainty to future change that may occur. If the requirement should address possible configuration changes, the statement should reflect future changes or list table expansions. Preparations for future modification can be built into a requirement, however “but not limited to” is a statement that causes confusion.
5.) The fifth and most lethal and debilitating offender in system requirements is the dreaded “Scope Change.” Avoid the addition of requirements out of the original project scope unless it is deemed necessary to add the new functions. It is fine to desire something else to enhance services not within in scope. Instead of changing the project scope, a greater benefit is found in making the addition/modification as a following phase or next iteration. A “Scope Change” will bring into question every requirement and cause a full review of the project. Basically it sends the project back into discovery sessions and is pure upheaval of requirements. The avoidance of the five requirement pitfalls can lead to a better project.
There are other pitfalls, such as flows with missing steps or charts that leave out systems/processes but the above five are the most common offenders in most requirements.
