Smoothing the Way to Better Requirements
The fact that a large proportion of requirements are problematic, doesn't mean it's particularly difficult to produce good ones. Rather, a lot more working interaction is required between the delivery team and customer. That doesn't mean meetings with managers and administrators, it means interaction between the person who knows and the person who does.
Dialogue and Collaboration
Producing bad requirements can take weeks, even months, yet deadlines rarely shift to accommodate. Opening up a dialogue between customer and the delivery team as early as possible will greatly reduce delays, errors and inefficiency. Equally, the expectations of all the involved parties are clearer and more apparent.
Regardless of how requirements are produced, upfront with change controls or iteratively alongside development, the most important thing is that they communicate what's required and what's not required.
The matter of "how" will generally be a negotiation governed by such things as how much the new solution needs to integrate with existing infrastructure and systems, its visibility (I.e. is it internal or available on the internet), security, data volumes and types, and transaction frequency.
With this in mind, early access to documentation such as the organisations:
- Privacy policies.
- IT services, including:
- Policies and standards
- Availability and costs
- Lead times
- Dependencies on external suppliers and, in particular, contract end dates.
- Relevant regulatory requirements.
These all impact the suitability of the end product and must be considered prior to producing detailed requirements.
Simple Quality Control and Documentation Testing
Requirements are technical and producing good them requires business knowledge, skills and experience. Even where the fine detail is reached through iteration a good set of initial requirements should, at the very least:
- Describe the purpose.
- Define both what's in scope and what is not.
- Highlight any gaps that need to be addressed further.
- Indicate how the gaps can be filled.
- Highlight any assumptions.
- Identify any dependencies.
Essentially, the requirements provided at the start of development should either:
- Adequately define processes and structures such that no significant change is required during development. If changes are required then a low maintenance change control process is essential. I.e. Waterfall type projects.
- Provide a business case, overview, starting point (such as an existing process summary) and indications as to where and how further detail is to be pinned down. I.e. Iterative / Agile based projects.
If requirements are clearly inadequate don't simply pass them to the developers and hope for the best. Work them through with the appropriate people, if necessary placing that work-stream on hold until work can be started without risk of rework or error. Good developers are generally in limited supply so try not to waste their time.
A simple cost effective way to facility good quality requirements (for current processes), is to test existing process documentation. This should be done before anything else. Take a suitably qualified user who has not worked the process before and let them work from the documentation with supervision but no guidance or hand-holding.
Have the person supervising update the documentation whenever the test user gets into difficulty. Then, feed it back to the user iteratively until the process is complete. I.e. any new user can work the process from the documentation.
Smooth Flow, Communication and Change Controls
In order to maximise efficiency in any process, development or otherwise, progress must flow smoothly. If you have to wait a week for something that only takes five minutes then something is wrong.
Ideally development, of any particular aspect of a solution, should not start until the requirements for it are complete to the point that rework, de-scoping and structure changes are unlikely. For iterative approaches, such as Agile, specific requirements should only be passed to the developer when they are ready for coding. And... when they are unlikely to be adversely affected by other aspects of the solution.
Given that even a great set of requirements will at least need tweaking, the only adequate way to iterate is with immediate answers. Clearly, if the approach is iterative, questions tend to arise at a time when they are preventing progress. It goes without saying then, that sufficient resource must be allocated, and available, to answer questions as they arise. If this is not possible then every effort should be made to make the requirements as complete as possible.
When a developer, or analyst, is able to work uninterrupted for extended periods, then flow is optimal, I.e. we have a highly efficient process. It takes time to get up to speed, and that time is needlessly repeated each time a piece of work has to be put down and picked up again.
If the person tasked with answering questions needs to call a meeting then something has failed. Either it's the wrong person or the issue can't be resolved without a formal change request.
For more complex solutions, and prior to starting development, requirements can be passed to another analyst or a developer for proofing and wire-framing. Doing this prior to starting development will likely raise the most significant questions and issues before they require costly rework or compromise, or interrupt work-flow. Equally, users and output consumers should be given the opportunity to review those areas that they will be involved in once the solution is delivered.
The developer(s) should have the opportunity to add comments, questions and issues to the document itself prior to sign-off. Also within the document, to explain or question a) how problems will be resolved and b) how the functionality will be presented to the user as they understand it. This way the producers of the requirements and the developers can thrash out most of the detail prior to staring and, at the same time, be sure that the requirements are understood.
A formal change control process should be agreed but limited to actual changes. In other words, where the subject is either not included in, or contradicts, the original requirements, or adds significant extra work. Change requests should include the following:
- The subject being changed or added.
- The reason that the change is required, including why it wasn't in the original requirements.
- The date raised and the date the change request must be signed off and implemented.
- The full details of the change, including:
- Details of how the change will affect the process and user experience.
- Details of any additional resource requirements.
- Any new dependencies created and old ones deleted.
- Details of the impact of the change on other functional areas of the completed solution.
- Impact on any other aspects of development, i.e. anything that can't be progressed until the change is implemented and anything else that might need rework.
This process should not be used to cover such things as resolving unknowns but may be appropriate where assumptions have been entirely wrong.
Clearly identify the priority AND importance of each requirement. I.e.:
- Critical (must have) - anything critical, that the current delivery can't do without.
- Non-critical (should have) - anything that should be included but isn't currently critical. I.e. if necessary things that can be delivered later.
- Optional (could have) - anything not necessary that might improve the end solution in some minor way time permitting.
- Unnecessary (won't have) - anything that is completely outside the scope of the project, either because it's not currently required or completely obsolete.
- Importance in relation to:
- Productivity and flow - for example manual effort that could otherwise be automated. Essentially, anything that keeps running costs and turnaround times to a minimum.
- Security and privacy.
- Regulatory constraints.
- Dependencies - the things the requirement depends on as well as those depending on it. In particular:
- Isolated items - those that have little impact on the delivery of the rest of the solution. For example user and permissions management. These are important because a) they can be worked on at pretty much any time, and b) dependencies are few, easily identifiable and can be incorporated later.
- Core items - the ones with that must be completed before most others.
- Volatile items - the things that are most likely to change or be dropped.
- Fragile chains - strings of dependencies that can easily be blocked or broken.
- Obsoletes - anything no longer necessary but still performed in an existing process because nobody thought to stop it. A common area for this being internal reporting. Many "New" solutions attempt to improve existing processes without necessarily questioning the necessity of each step. Identifying obsoletes in an existing process is one of the most important aspects in process improvement and solution delivery.
Identifying the Gaps (I.e. Unknowns)
It's not uncommon, and perfectly reasonable, to have gaps in requirements. For example because of unavailable resource, timing issues or uncertainty regarding external factors such as regulatory change. Whatever the reason, all gaps should be highlighted, given a reference number, assigned, described and tracked.
While gaps remain it is not possible to accurately forecast and plan. Given this, filling gaps should be a priority.
To summarise, irrespective of how requirements are produced they should only be passed to a developer FOR CODING, when they are complete. With this in mind, where requirements are produced iteratively, or working on a change request, the less time between refining the requirements and handing them over to a developer the better.