Amy Corbett, Business Consultant North America, FINEOS
We assume that requirements are the easy part of an implementation. Here is a definition from a Computing dictionary: “The first stage of software development which defines what the potential users want the system to do. In modern methods these requirements should be testable, and will usually be traceable in later development stages. A common feature of nearly all software is that the requirements change during its lifetime.”
We have all been there. You are happily on your way to implementing your product. You have had requirement sessions and documented what you thought were all of the requirements and they have been signed off after multiple reviews and iterations. Then, all of a sudden, the client identifies something that they think is a requirement and you having no idea where that came from. Sure, you remember some vague discussions about the subject. But it was with someone in a side bar conversation; from someone who has not actually been involved in the project; and it seemed like there was no actual importance in the subject.
You thought that phase of the project was complete. Well, guess what? Requirements come up throughout a project life cycle. It may not get implemented in your current phase, but requirements are identified by customers all the time as the customer becomes more familiar with the product functionality. So, requirements need to be identified, documented and tracked even if it is outside of the initial requirements phase.
Management and users change as a project evolves. Decision makers change. They leave, they change jobs, and they get replaced. And no two users are the same. Requirements can be interpreted in different ways by everyone involved. It’s sort of like the whisper game – whisper a requirement in someone’s ear, and let them whisper it to the next person and by the time you get around to the end of the table, the requirement has changed. So, learning how to clearly and concisely document a requirement so that everyone is on the same page is not easy, but it is worth it in the end. Requirements are never done. They are living, breathing documents that need reviewed and revisited on a regular basis.
Just because a user requests a requirement does not mean that it is always a good idea or needs to be accepted. If a requirement is challenged for a legitimate reason, in a constructive manner, there is nothing wrong with the challenge. If the requirement is too vague or cannot be tested in the future, then it does not need to be a requirement. The old adage ‘anything can be done’ is not a good way of doing business. A requirement needs to make sense for the present but should also make sense for the future. Forward thinking should be taken into consideration with all requirements because you want the business to move forward and grow into the future. A business consultant has the duty to advise a client and counsel them regarding legitimacy of a requirement. Also, a client knows their business but a business consultant knows their product. The two contingencies need to meld their knowledge to make for optimum requirements.
Requirements need to be traceable in the implementation going forward. While documenting the requirements, the team should be envisioning how this requirement is going to be traced. There should be a valid business reason for the requirement and it should make sense in the totality of the project. The only way that this can be accomplished is to be able to trace the requirement into the future. This will help with any change control. When this information is documented then all parties can understand the need for change control and misunderstandings will be held to a minimum. This trace document also needs to be reviewed on a regular basis because it is ever evolving.
The requirements stage is an exciting time of a project. It is new for the client and a new project for the team. Getting the right information and documenting it will make the rest of the project so much better in the long run. So remember that requirements are living documents that continually need to be reviewed, they need to be accurately understood and documented. The requirements need to evolve into a testable format that can be traced into the system in the future. In other words, have fun with it, learn from it and don’t assume that requirements will just take care of themselves.
