Gathering software requirements can be as much fun as trying to count function points or code a webpage using a vi editor. The process usually involves the software team assuming that business customers will communicate everything that their hearts desire as succinctly as possible.
Business customers have a tendency to expect software teams to be mind-readers, and to deliver a solution based on unspoken, malformed or unknown requirements. All of these requirements need to be formally captured in a mammoth document that will be used for future sophomoric squabbles over a game of “he said, she said.”
Sound familiar?
Gathering requirements is complicated
The reality is that gathering requirements is a lot of work. Project teams can make bad assumptions, focus on the how instead of the what and incorrectly describe requirements. IT teams are often given a document template and told to “go gather requirements” with the expectation that the document will be implementation-ready in a week.
(I won’t even get on my soapbox about functional and nonfunctional requirements yet.)
If you ask your software teams about how they gather requirements, you’ll likely get varied responses: from doing some actual mind reading to participating in requirement management workshops using different templates and tools. The requirements-gathering process and all the associated tools, templates and techniques isn’t a one-size-fits-all model. PMOs and other project management professionals love to see teams use a common requirements tool. A better tactic is to use a toolbox approach.
Use the toolbox approach
With a toolbox approach, project teams can use a variety of tools and techniques to define business requirements. In any given organization, you’ll likely find multiple methodologies including Waterfall, Agile and some ERP variant for SAP and purchased package implementations. If our projects are different, methodologies are different and the people are different, why would we expect our requirement tools to be the same across projects?
Here are seven useful tools that I’ve built into my own requirements toolbox. I don’t use every tool on every project, but I’ve discovered that picking the right requirement tool for the job definitely helps. These tools are helpful in eliciting better requirements and provide clarity to translating business processes into software solutions.
1. Context diagram
A system context diagram defines the system’s boundary, its surrounding environment, and all the interacting entities. The system is plotted in the middle of the diagram and identifies customers, external or internal systems, the organization’s end users and any vendors or suppliers providing third-party services.
By building a visual model of the software solution, you have a better understanding of the major interactions and players in your system. It also helps to define the context where the system sits so the end user can agree to what is in scope and what is out of scope in the project.
2. Functional decomposition
A functional decomposition diagram provides a top-down view of the business process and/or the system’s major functions. When I think about what the system should do, I’ll use the functional decomposition diagram to break it down into major chunks. This view also helps validate all the functions the system should provide. It’s similar to an organization chart and your end user should be able to easily relate to this model.
3. Use case diagram
The use case diagram helps depict the interaction between the system and its users. Each user role is called an “actor” and different processes or functions are represented in the diagram. Each of these interactions can be further broken down into steps including the “happy path” and alternative paths.
Here’s how it breaks down:
Use case: Submit Application
Actor: Customer
Description: Describes the Credit Card application submission process
Successful completion:
- The user enters application information including social security number.
- System validates input for data entry errors.
- The system submits the application.
Alternative: System rejects the submission, citing form entry errors for social security number.
Pre-condition: User has been routed to credit application from email campaign or website.
Post-condition: User receive success message.
Assumptions: None
4. Sequence diagram
A sequence diagram shows the interactions between objects over time. It provides a top-to-bottom view with messages being sent back and forth between the different objects. The objects can be actors, systems or sub-packages within a system.
In the example above, the sequence diagram could be used to identify the different types of email notifications that need to be sent to the customer and the credit card company’s reviewer.
5. AS-IS and TO-BE process model
The swim lane diagram is a systems analysis model that is taught in every Systems Analysis and Design course. If you wanted a relevant book on business process management, take a look at Paul Harmon’s Business Process Change. It provides an in-depth approach to business process management that goes beyond the typical textbook. Here’s a look at the AS-IS and TO-BE process models:
AS-IS process model
The AS-IS process model describes the current business process flow. I’ve seen some teams struggle with developing an AS-IS model for the business process, as teams often want to jump to the future TO-BE process. However, it’s worth spending the time documenting the AS-IS for major processes or complex processes so the entire team can develop a common understanding of the business process.
(Plus it’s helpful to overlay the AS-IS with the TO-BE to understand the changes)
TO BE Process Model
The TO-BE process model usually adds the system as a swim lane and shows how the business process is adjusted with the system in place. Teams can now validate if the business process still makes sense with the addition of the IT system and supporting workflow.
6.User stories
I’ve covered user stories in previous articles and I include them here because they’re helpful tools to quickly identify the major functions of a system. Since they’re written on note cards (physical or virtual), the cards can be further split into smaller user stories as needed.
If a user story proves to be too complicated, it can be broken down into smaller stories and supported with one of the aforementioned diagrams. Agile doesn’t mean just using notes cards and sticky notes. Agile teams understand the importance of picking the right tool for the job.
7. Mind maps
Mind mapping is another awesome tool to capture ideas, requirements and help organize a conversation with many tangents. When you’re in a requirements gathering session, it is easy to run off-topic and leap to another business process needed. Mind mapping helps to organize the conversation by aligning comments, requirements and ideas with the major thought branches in a conversation.
Benefits
You’ll notice I didn’t include the boring old requirements document as a tool. Eventually, you’ll likely use a spreadsheet, a word processing document or a software system to further document these requirements. Even if you use a software system like HP’s Quality Center or IBM’s Rational Requisitepro, these tools will still provide an option to generate the mammoth requirements document.
The reality is: No one wants to read a boring and expansive document on systems requirements.
People are more likely to look at a picture than read a 200-page tree killer.
I’ve found by using visual communication to define and describe the requirement, teams are more engaged and they understand each other better. Even though the user story example was drawn on an index card, I still use Agile software tools to build my product backlog visually.
If I can draw it, I can understand it, and so can my business customers.
Requirements modeling tools
The above examples were developed in Microsoft Visio and MindGenius—a mind mapping program. If you’re looking for additional software tools for your requirements toolbox, then consider:
- Star UML – A popular UML modeling tool
- OpenText Provision – An extensive business process architecture tool
- Visual Paradigm – A design and management tool for business IT development
What’s in your toolbox?
The key takeaway is to try some of these tools, develop your own requirements toolbox and pick the right tool for your next project. The process of defining requirements isn’t a cut-and-dry path. Project teams take different approaches to develop requirements, and as IT leaders we should bring the right tool for the job.
Here’s another great tool for successful projects: accurate estimates. If you’re looking to expand or hone your method or would like to pick up some tips (we are devoted to ranged estimates), download our eBook, 6 Best Practices for Accurate Project Estimates.
