Gathering Requirements Properly
Today I want to highlight a bit issue with the tech industry, and that is the gathering of requirements from customers. I've seen far too many product and project managers gather requirements from the client, then pass them to developers to implement without batting an eye as to their feasibility.
Let's use a specific example pulled from my work today:
users can post images but post needs to go through approval before going live
This is all that was given as a use case. For clarity, the system that this requirement is implicitly referencing is forum software. It is now up to the developer (me) to discern the meaning behind this sentence, whereas everyone else up the command chain assumes that the requirement will be completed without issue.
Let me point out how ambiguous this sentence is with a few questions of my own:
- What type of user is being represented here? There are many types of users in the system, with varying degrees of permissions. Does this requirement apply to all of them?
- What does "post images" mean? There are many ways one can post images: uploading an attachment, uploading an attachment and then referencing it in the post, adding an
[img]BBCode tag that tells the parser to display an inline image, and lastly, adding a link to the image that one must follow. - In terms of "approval", what kind of approval is it? To whom? Which system will be providing the approval?
- What does "going live" mean? Many times, if a piece of data has been submitted to the system, it is already deemed live. It is possible that "live", in this sense, means to be shown to other users. But again, there are many types of users, so which types are allowed to see this non-live data?
I fully admit I sound pedantic with these questions, but it serves to highlight how many ways a simple sentence can be interpreted by a developer. And yet, rarely does anyone attempt to build a sentence that acts as a specification to reduce ambiguity. Most of the time, developers are left to figure out the questions and gather the answers, which sort of defeats the purpose of the requirements gathering phase of a project.