A colleague posed an interesting question today; if I was starting a new project for a client from scratch (ground zero, day 1) what documentation would I want to put together to capture the business requirements?
Of course the real world answer would vary from client to client. More times than not the business requirements would mostly be defined and documented by someone else before I was brought onto the team. Likewise teams often already have a preferred process in place with document templates, etc.
But just for fun; if I was tasked with starting the documentation stack for a brand new project today, this is what I would do…
1.) Brainstorm
My brainstorming tool of choice is FreeMind.
I would sit down with the primary project stakeholder(s) and capture any and every idea we can conjure about the system we want to build. No idea is too big or too far out for the mind map; this should be a fun exercise to generate some excitement and momentum for the project.
2.) Capture Requirements and Use Cases
The next step would be to sit down with *all* the project and product stakeholders and refine the wild ideas from the previous exercise into something real. The important concept here is the brainstorming that happened above are the ideas of myself and one or two people while at this stage we want to capture the ideas of everybody else including the users.
The form will be a document that summarizes the business case (goals, scope, objectives) as well as requirement considerations and important use cases. I say requirement considerations because these are not the final requirements, but rather a stepping stone on the path towards the final requirements. If you believe that requirements are revealed as opposed to created then this document is your bridge to somewhere.
I use the following categories when interviewing the project stakeholders and users:
I am not sure where I came across this list and I almost never wind up with a ton of stuff in every single category but this list really gets me thinking about other important facets of the system on top of core functionality.
The use cases in this document will include the standard sections: goal, actors, pre-conditions, paths, etc. When this document is complete everybody on the project should be able to read it and understand it and be on the same page and it will be important to keep this document up to date throughout the project.
3.) Formulate User Stories
I prefer to work with user stories as opposed to formal requirements from this point out. A large batch of the user stories can be gleaned from the document above and entered into something like TargetProcess. The sooner I can get to this phase of the project the better; but not at the expense of the previous two steps. The most important consideration moving forward is that I am not allowed to create user stories when I feel like it. I must get some small version of the system in the hands of the stakeholders and users so they can refine and add to the backlog of stories while I continue fleshing out the documentation stack with design documentation, architecture diagrams, a test plan, etc.
