We all strive to write the perfect requirements. Many of us are familiar with the somewhat vague, ubiquitous and poorly conceived scribblings that are jotted down in the brief few minutes that we get to spend with the stakeholders and subject-matter experts (SME).The stakeholders and SMEs tell us about a new, brilliant, wonderful and life-changing system that will be implemented later this year… (hopefully), and we struggle to use our scribblings to write the requirements to bring this system to life.
OK, maybe it is not quite as bad as that, but we do spend our days trying to construct those requirements into a comprehensive document with Business, Functional and Non-Functional requirements. This is accompanied by a wide variety of supporting graphics, Use Cases and charts that we then take to our stakeholders for review and the infamous “Approval.” To be honest, we are ALL bad at reading through things that we should take a little more time to go over. I would bet most of you have installed a few software products in your time and quickly clicked through the Terms & Conditions, only to be upset and annoyed to see the dreaded Google Menu Bar installed at the top of Internet Explorer for the fifth time. Yes, based on the permission requirements that you approved, it was going to install this for you, and also, in case you didn’t notice, it will change your Homepage too. So we have all done it, we have read the requirements, provided the “Approval,” only to find out that what you ended up with was not exactly what you had hoped for. In our particular case, we can easily uninstall the additional things we got, but in the real world of building software, this could be a very costly mistake.
So I know I’m not telling you anything new. What’s the big deal? Projects have been developed this way for years. A quote you often hear is that there is a 40 percent rework rate because someone forgot to really read what was put in front of them. In most organizations, there are no major repercussions for not reading the functional requirements and still continuing to sign off on them; they are simply an “Illusion of Acceptance.” If somebody comes back later and tries to point the finger, I’m sure there is enough vagueness and ambiguity in the document that everyone would understand why you would sign off first and fix it “in version 1.1 or Phase II, or after some Change Requests” later.
The answer in my mind is to take an Agile approach to any project. Agile is really a state of mind as much as it is a methodology and can be applied in many ways in all walks of life. I’m all for throwing away the “Approval Process,” routing documents from person to person, group to group and waiting for the day when it is all approved. Instead, I prefer to take an interactive approach to the requirements process, involve the stakeholders at repeated points in the process and step them through smaller, more consumable assets over a period of time.
The agile approach favors early feedback and frequent person-to-person communication. Start delivering value right away by holding a kick-off session with the project’s stakeholders. In this session, brainstorm around two questions:
- Who needs to use the thing we’re about to build?
- Why do they need to use it?
Focus on the problems you are trying to solve, and “How” to fix the problems. Sometimes you have to spend some time on the how, especially when a new architecture is involved. This architecture needs to grow with the requirements, so in this case, it may well have to be a parallel effort.
While it is great to write down lengthy textual requirements with Scope, Stakeholders, As-is and To-be states, I encourage you to get to your Use Cases as soon as possible. Use the information you gathered in your first session to define a high-level use case diagram with the key actors involved. And don’t be afraid to go back to your stakeholders and get their buy-in before you move forward. It is very easy to skip an actor or a use case when you first define this high-level diagram.
Comments