When developing requirements, we often need to remember that the software has a life beyond the end of the project we are working on. We need to remember that the piece of functionality that we are working on will have to be maintained and understood long after we are done creating/modifying it. This is determined by how maintainable the requirements that you are outlining are. This has nothing to do with "Support Requirements" or "Training Requirements." Maintainability means that once the feature is released:
A year from now, any developer or analyst who looks at the feature and needs the context in which it was originally developed should understand what it does and why it does it, with very little explanation.
A year from now, anyone can come and make a modification to the feature and be able to confidently say that the original functionality has not been negatively impacted.
Modifying the feature in the future (say that ten times fast) does not require an act of god because people are afraid to touch it since they don't know everything involved.
You can hand off this feature to any other person, and it does not require constant care and attention from the team that originally built it.
How do you make sure that this result is achieved:
Keep It Simple Stupid (KISS): It has become a cliche, but it is more accurate than ever in this scenario. Product Managers who are confronted with complicated business problems tend to create complex requirements. Part of it is an inability to break it down, but part is the rush it brings when you feel like you have taken down a gargantuan problem with an equally ginormous (technical term) and convoluted requirement. The reality is that you should be headed in the opposite direction and trying to simplify the requirement. The question you need to ask yourself is, will someone else who has not been in every meeting and discussion you have been involved in be able to understand the requirement and extend it? If you are having difficulty keeping track of the requirement yourself, imagine how complicated it will be for someone else down the line to work with it. If you want to test if your requirements fit this criterion quickly, walk through your requirements with someone not on your project and pay attention to the expressions on their face. If the business is pushing you to deliver a complicated requirement, tell them you will start with a simple version and then build on it if needed. That way, you have allowed your simple solution to succeed and placated your business stakeholders by letting them know that you will not leave them hanging if the need arises to build additional functionality.
The essence of maintainability is how often and easily somebody can build new features on top of your features.
Comments