Lately I have really been struggling on what seems, on the surface, to be a relatively trivial problem. The problem is one of accurately capturing a customer’s requirements and translating those conversations into a well-crafted, stable application. This goal seems to have become more elusive to me the closer I try to get to it, leading me down many frustrated paths.
It seems the process is a good place to start. Who is involved in requirements gathering? Usually we will use a technical resource and a project manager or a business analyst, and most importantly, the client. The client can be internal or external, we all have customers. The techie provides insight into potential solutions, while the business analyst role is used to write up a lot of the requirements as well as try to probe the client for additional information and to deliver value by suggesting other alternatives while going through this process. The client is their to ensure that their vision is implemented correctly, as well as to serve as a conduit to the subject matter experts who can help us detail the intricate twists and turns of an organisation's processes and practices.
Usually, other parties that get involved are the person controlling the project purse strings, other IT staff ensuring standards, documenting third party systems, or maintaining IT order on the project. Each one of these parties may have their own vested interests in the outcome of the project, and provide input as well. It’s that input that I’m having a hard time with.
Where do we even start? Do we break up requirements by functional area, by web site navigation, by chronological order of conversation? The real disconnect that I am struggling with is how we ensure that the technical requirements, specifications and designs adequately serve the requirements and ensure compliance. My team gets slowed down when we have to stop and add fields to the database because they are captured in a single paragraph on page 158 of the specification, and, without our developer being an astute reader, would have slipped our minds until testing. Which brings up a point those XP folks will hammer on is that we need to ensure the tests are associated with the sections as well. So what can we do better, and what information do we need to capture?
This seems like it starts to break out into individual nodes of a tree like document following a very defined schema. What I’d like to see is something like
Narrative:
UI Notes: (must have drop down calendar, etc)
Database Tables :
Objects:
Security:
Tests:
Integration Points:
Performance Requirements:
Estimate:(could have a tasks breakdown as well, and maybe reflect dependencies to drive a project plan?)
Am I missing something, if we were to link these all in a format like this, would that improve our process? Would that document a majority of our situations effectively, or would it be too brittle and still allow things to be "missed"? Are there tools to deal with this, or do people have a home-grown kind of toolkit to system-atize this process? Any thoughts would be appreciated.
Seeking Therapy By Listening to: Green Day - Burnout