Your unique responsibility as a business analyst is to write and communicate excellent requirements. This job is important because requirements consumers depend on the requirements in order to effectively design and construct solution components.
Excellent requirements leave no room for interpretation, create no cause for confusion, and omit no critical detail. They ensure that any consumer of the requirements information (such as developers, software or process engineers, database administrators, interface designers, architects, product managers, and sponsors) can understand what’s been requested. Excellent requirements possess seven different characteristics.
Requirements that generate more questions than they provide answers aren’t excellent requirements; lacking that clarity, the team may find delivering the appropriate solution much more difficult and frustrating.
Excellent business analysis report requirements are complete
A complete requirement thoroughly describes the user task and all the information required to support that task. To create complete requirements, push stakeholders to focus on describing the goal to be accomplished and the requirements for achieving that goal, as opposed to talking about the system functionality.
Focusing on system requirements often creates gaps because stakeholders frequently think of only the specific tasks that pertain to them. They miss critical interactions with or dependencies on others around the goal or outcome, and those elements are typically important for the overall solution. Here are two contrasting examples of completeness:
Non-excellent/incomplete: “Accounting needs to be able to process employee expense accounts.”
Excellent/complete: “Accounting supervisors need to be able to approve expense accounts submitted from employees.”
Excellent business analysis report requirements are correct
A correct requirement appropriately meets the goals of the project and accurately describes the user’s expectations of the functionality being specified.
You must challenge and eliminate assumptions that occur when stakeholders who are very familiar with their business areas internalize different business rules or scenarios and then omit those critical details from their requirements. Here are two examples of varying correctness:
Non-excellent/incorrect: “An employee may change his or her last name after a change in marital status.”
Excellent/correct: “An employee may change his or her last name after submitting appropriate legal proof of name change.”
Excellent business analysis report requirements are unambiguous
An unambiguous requirement is crystal clear. Based on the requirement you wrote, all readers should arrive at a single, consistent interpretation. Misinterpreted ambiguous requirements can result in the wrong system being developed, a situation that may not be found during testing if the tester is working under an incorrect interpretation of the requirements. Here are two examples of clear/unclear requirements:
Non-excellent/ambiguous: “Overtime is not permitted.”
Excellent/unambiguous: “Any consultant’s time sheet that’s submitted with an excess of 40 hours worked will be denied for payment and returned to the consultant for revision.”
Excellent business analysis report requirements are verifiable
Excellent requirements need to be testable in order to verify that what you get when the solution is completed is what you wanted in the first place.
Requirements that aren’t verifiable may be descriptive enough to be subjectively assessed, but they aren’t provable, which can complicate ensuring someone really got what was needed. Here are two contrasting examples of verifiability:
Non-excellent/unverifiable: “Order fulfillment should be able to pack most orders within 5 minutes.”
Excellent/verifiable: “Order fulfillment must be able to pack 90 percent of orders within 5 minutes after receipt of the packing slip.”
Excellent business analysis report requirements are necessary
Requirements need to clearly support a project goal or objective; they should not be on someone’s personal wish list, and they shouldn’t be requirements that anyone would review and declare to be scope creep. Every project operates under time and budget constraints; if a requirement isn’t necessary, it can be deprioritized. Here are two examples of levels of necessity:
Non-excellent/unnecessary: “Accounting systems must have current, up-to-the-minute exchange rates available.”
Excellent/necessary: “Accounting systems must have their exchange rates updated once daily.”
Excellent business analysis report requirements are feasible
Make sure that all requirements are technologically and realistically possible for a reasonable cost. To do so, bring in the technical team and discuss the requirements and potential solution options. Here are two examples highlighting feasibility:
Non-excellent/not feasible: “The web system’s intrusion detection functionality must capture the reason for any intrusion attempt.”
Excellent/feasible: “The web system’s intrusion detection functionality must capture the date, time, and IP address of any potential intrusion connection, as defined by intrusion-suspect criteria factors.”
Excellent business analysis report requirements are prioritized
After you decide that everything on the list is necessary, requirements must then be prioritized — just in case completing all of them right now still isn’t possible. Rank requirements from the business perspective, the technical perspective, or both. Facilitating these two perspectives involves some give and take:
From a business perspective, prioritize requirements according to their value, level of risk, or expected frequency of use in the business. Stakeholders can characterize what they need by using declarative statements — they must have X, X should be present, or X would be nice to have. Also identify requirements that may be considered a delighter, or something stakeholders may find unexpected but exciting and value-adding.
From the technical perspective, the technical team may need to implement requirements in order of technical importance or simplicity rather than by business importance. Requirements for compliance with governmental regulations, operating system upgrades, and other drivers may not have been initiated by the business but are still important to the business. Make sure the business understands why you’re prioritizing these items.
Excellent requirements are not just textual statements. Requirements can be communicated in many forms: textual statements, diagrams, pictures, and so on. The characteristics of an excellent requirement apply to any form of communicating requirements.