Requirements Are Approved – So What?
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.
The core of a use case is its main success scenario — six to ten steps that describe how an actor gets something done. When written well, it gives a concise description of how the system needs to behave. When written poorly, it’s a tedious mess that makes the readers’ eyes glaze over. Learning to write succinct, informative steps is the most important skill a use case author can have. It’s also the hardest skill to acquire, since use case steps are so different from the traditional way of phrasing requirements.
Each step should describe an action taken either by the system or by the actor. The actions commonly fall into one of the following categories (if it doesn’t, that’s a clue you might not be getting the step right).
Kind of Step |
Example |
| System provides information to the actor | System displays the search results. |
| System prompts the actor | System asks member to accept invitation. |
| System does work on the actor’s behalf | System sends request to payment processor. |
| Actor makes a choice | Member accepts invitation. |
| Actor provides information to the system | Customer enters payment information. |
Keep the writing lively by describing the information being passed and the work being done. To keep the scenario readable and maintainable, omit details about:
- the user interface
- the format of the data being passed
- business rules and formulas
- performance (and other non-functional) requirements
Such details can be defined in text requirement formats and traced to[G1] . Don’t clutter up your use case.
Now that you have a concise use case that is easy to understand, get your stakeholders’ buy-in again. Step them through the flow and make sure they agree with the wording, the branches and includes that you have defined. While doing this, you can also expand upon your use case even more. Think of it as a Christmas tree and you can now hang all kinds of ornaments off your use case once it’s defined:
- Traces to other requirement elements
- Screen mockups
- Related data and business rules
- External references
Finally, DO NOT generate a large document and ask a group of people you don’t know to validate and sign off on your requirements. Bring them together in a working session; simulate the requirements where possible. Step them through the requirements in manageable chunks and document their feedback. Iterate through this process to hone and remove ambiguity from your requirements. If the meeting is quiet with very little feedback, it means one of two things:
- You’re the best BA in the world
- You are doomed for that 40 percent rework tax
Happy Requirements Development!
Don’t forget to leave your comments below.
Karl O’Brien is the Senior Solutions Engineer in the Northeast for Blueprint Software Systems, the leader in requirements definition and visualization software. In this capacity, Karl regularly consults with development organizations regarding their efforts to improve requirements elicitation, documentation, validation, and communication processes via automation. Prior to Blueprint, Karl worked with several major software companies as well as running his own consulting company for many years. Karl has over 30 years IT experience starting with Rolls Royce in Coventry, England. He moved to the USA in 1981. Karl has performed in several IT roles during his career, from developer to project manager. He now focuses his efforts on requirements definition and management.