How many times has a statement (requirement) like one of the following been given to you? (only to find out months later that there is an important exception that was not given to you):
- Field X will always be a positive integer! (except for the case where we decided long ago to populate it with “-9999” to represent something specific)
- Field Y always needs to be 10 characters long! (except for when we’re dealing with a specific customer, in which case it actually needs to be 11 characters long and the first character needs to be an ‘A’)
- The user will always need to fill out this field! (except for the case where the user can’t possibly get that information due to the fact that it physically doesn’t exist)
- The user will always need to fill out this new field that we are adding! (except for if they are editing something that existed prior to the field being added to the system)
- Noone will ever need to change that value! (except for if they get additional information a month later)
- The system should never accept an incomplete entry! (unless the user needs to be able to enter partial data and complete it at a later date)
As I mentioned in my last post (oh so long ago), any time in software development that you hear “always” or “never” while gathering requirements, that should be a trigger to delve a little deeper. These are the kinds of blanket statements that can lead to assumptions being made that may be costly to change later on. As a result, it is good to do as much as possible to break these absolutes (in valid ways) before they make it into a requirements document. Some methods I’ve found useful:
- First and foremost, if someone says “always” or “never”, make sure you’ve actually got the subject matter expert involved (this is always important for requirements, but doubly so when “always” and “never” start getting thrown around). Each step away from the expert you move, it becomes more likely that someone along the line hasn’t communicated (or simply is not aware of) an important exception case where “always” or “never” breaks down.
- Turn the statement around. Often times, when given the statement that “X will always be true”, simply asking “so X will never be false?” will get the person you are asking to give it enough thought that the response you get back falls along the lines of “well, there is this one condition…”
- Brainstorm. Start throwing out ideas for what may break the absolutes. Being able to do this effectively may depend a lot on domain knowledge. Come up with all the cases that could break the “always” or “never” and get them written down. Once you can’t come up with any more, work through and determine which cases are valid and which are not. If a field is “always” required to be filled in, ask whether what is entered into other fields has any impact on that. This is especially true if you are doing something like adding a new field to a screen that already exists and users may need to edit old data that has no value captured for your new field.
- Write them down. Capture absolutes that are brought up, and review them.
Now obviously (for a variety of reasons), you don’t want to take this to the extreme of asking “are you sure?” after every statement given to you. When in doubt, capture the absolute and take it back to your team (or a mentor) and ask for their input.
