Many BAs I coach make the mistake of mixing software capabilities with business rules, employee procedures, and operational guidelines when documenting requirements for an information system or software application.
Here are a few real-life examples of things that I’ve seen being incorrectly listed as part of the requirements in software specification documents:
“Vendor activities (Check Stock, Ship Product) need to be completed before their due date/time.”
This statement is clearly not a software requirement. We are not describing an automatable procedure, as the system can’t “force” employees to complete their activities before the deadline. This needs to be treated as a job responsibility, rather than a software requirement, and can be a valuable source for discussion of potential additional requirements to help support the business objective. For example,
“Employees responsible for vendor activities (Check Stock, Ship Product) will see their pending tasks in a Work Queue, with a visual indication of approaching and missed deadlines.”
(This type of capability can help reduce the risk of employees missing their due dates, although it’s still the responsibility of each person to make sure their activities are completed on time.)
“Any uploaded material must be legally distributable.”
You may very well wish that users upload to the system only legally distributable material, but most likely won’t have the means to prevent illegal material from being uploaded.
Instead, to help the business achieve this objective, you might end up with a requirement like this:
“When a user attempts to upload content, the system will prompt him to confirm that the material is legally distributable before completing the action.”
(While it’s still the responsibility of the user to ensure the policy is followed, the system can help reduce the risk of non-compliance by providing a reminder and requiring user confirmation.)
“Consultants in a client assignment are required to work 40 hours a week.”
Well, that may be your company’s expectation or policy, but again, in practice your software can’t enforce that rule. And what if a consultant gets sick, or has to travel to take care of personal business? Now, a requirement like this might make sense for a time tracking system:
“The system will require consultants in a client assignment to enter at least 40 hours in their weekly timesheet before being allowed to submit it, providing the appropriate codes for client work, sick leave, unpaid leave, vacation, and training.”
(Now you are creating a valid constraint in the system to ensure that consultants don’t submit less than 40 hours while reporting week hours, so HR can correctly compute billable and non-billable time and the payable amount for each consultant.)
* * *
Business policies, rules, procedures and protocols are criteria that guide business activity and support operational decision-making in organizations. As seen above, they are a great source of potential requirements for IT solutions to business problems, but typically can’t be treated software requirements themselves. Knowing how to derive and propose the right requirements based on policies and rules is a competence that every business analyst should develop to increase his/her contribution to software projects.