I have been through enough consulting engagements that I know every team and every organization has their approach and their style of documentation. So asking the client for a sample that they like, saves me the trouble of creating something and then realizing that they wanted something else.
The team provided me with a sample document, which contained the following details for a single use case:- A use case diagram
- A flow of events (including a primary flow and an alternate flow) as a textual description
- Preconditions
- Post conditions
- Extension points
- Special Requirements

It is important to realize that the team I was working with is constrained by the project methodology required by the organization. The team must apply a traditional waterfall approach to project management and solution development. Thus, it was important that the analysis artefacts I created fit into that style.
To develop this document, I applied another combination of business analysis techniques. I am not fond of the traditional interview-document-confirm requirement cycle. When time is of the essence, I prefer holding a workshop (60-90mins) with key stakeholders and we discuss, brainstorm, and confirm details regarding the requirement, while key stakeholders are present. To prepare for this event, I created a PowerPoint presentation with the key headings:- Statement of the Requirement – as defined in the requirement document
- Intent of the Requirement – as ascertained through discussion with the original requirement author
- Business Goal/Objective – a paraphrasing based upon 1&2
- Terminology – It has been my experience that terminology can be the point of most confusion between the business and IT development teams, or even between different business teams, thus it is imperative that a common definition be identified.
- Scope Clarification – related to 4. This is an opportunity to clarify what is in scope and what is out of scope for the requirement or the solution.
I prefer to use tables and onion diagrams to help confirm scope, because words can be ambiguous.
- Current State Description – how things work today. What limitations and/or challenges exist?
- Future State Description – the vision for how things should work in the future (at the end of the project)
- Assumptions – factor that is considered to be true, real or certain without any proof or demonstration. If the factor is proven to be false, the outcome of the project could be affected.
- Constraints – factor that limits or confines the method or outcome of the project
- Hardware, Software, Financial, Schedule
- Policy, procedures
- Legislation, Laws
- Stakeholders – an individual, group, or organization, who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project
- Actors – the individuals that will interact with the system
- Use Case Diagram – representation of a user’s interaction with the system.
While some teams may employ real-time multi-edit tools, like Google Slides, in lieu of a meeting, I am not fond of this approach, because it does not facilitate conversation between the stakeholders. While there is a place and value for tools that enable collaboration between physically and chronologically dispersed stakeholders, there is still value in enabling real-time communication (via conference calls and WebEx), because communication enables understanding of a shared objective.
Following the meeting, I published the updated slides on a SharePoint site so that all the stakeholders could see the final version and provide their comments/feedback. If the requirement warranted, I hosted a second workshop to discuss the workflows, business rules, and data requirements related to the requirement. At this time, I turned the bullet points from the presentation, into prose in a requirements document and supplemented the information in the deck with the following details ascertained during the process.- Functional Decomposition Diagrams
- Workflows Diagrams – may be in BPMN or a simple swim lane depending upon the formality of the process and the organization. The workflow shows primary and alternate paths through relevant actors for the process.
- Business Rules
- Data Requirements – inputs, outputs, validation, format, retention, etc.
- Capability Matrices – just like the one described in post one
- Details Operational Requirements
- Non-Functional Requirements – criteria that can be used to judge the quality operation of a system, rather than specific behaviors
One requirement was dropped mid-process and three requirements were merged into one document because there were three parts of the same process.
Stay tuned to post three for insight into elicitation of non-functional requirements