Requirements gathering is a critical, foundational step in all software development. It will either set the project on a course to great success if done well or doom it to failure if done poorly. As Janet Leon pointed out in her blog, The True Cost of a Software Bug, the earlier you catch a bug in the software development life cycle, the less costly the bug will be. So it should be our goal to get the requirements 100% correct in order to eliminate bugs. With the stakes high and the challenges many, here are a few items to consider during requirements gathering that will ensure your project charts a successful course.
The Challenge Defined
Why are requirements so difficult to elicit? First, the stakeholders are not always able to identify their specific business requirements to the development team. In the Agile development process, “big picture” requirements are gathered first, which become epics in the backlog. These are usually the major cost elements since details are not known or identified at that time. However, at some point the customer must perform a “deep dive” in which each of the major epics is examined and features are identified. For example, I know I need an online payment capability (epic), but do I want credit cards, debit cards, or checks (features)?
Another reason that requirements are difficult to elicit is confusion between features and user stories. User stories are developed to depict what a specific user of the software is trying to accomplish and why. For example, I want to purchase an item using my stored credit card information so that I don’t have to enter it again. Notice, there is no how at this stage.
User Types
Taking a logical approach to requirements gathering, who are the users? There are usually two types: external and internal.
External users may be using the software to purchase a commodity or license, or perhaps register a product. These users are often sending money to the customer, so this part of the system should get the highest priority and, usually, the lion’s share of the effort. External user requirements are often sketched out by the customer and clarified through specific events where they can interact with the customer, for example, at a trade show, via a survey or interacting an MVP release.
Internal users are usually not the priority because they are not providing revenue. However, this group should not be ignored because they not only have to understand how the external users are using the software but also how the software can make their lives better. User stories geared toward internal users should focus on specific business functions performed on a particular page to make their jobs more efficient. But even with this goal in mind, care must be exercised not to go overboard and eliminate mouse clicks just for the sake of efficiency.
Security
Another critical factor in crafting effective user stories is security. User groups gain access to features via pages, and each page needs to include page-based security to prevent external users from doing what internal users can do. Furthermore, certain internal users must not be able to do what other (more elite) users can do. This aspect of requirements gathering is where the agile process can be quite advantageous, since it allows the team to develop something for the customer to “test drive” before identifying specific privileges for one type of user over another. So, the questions that need to be asked are “what does the elite group need to do, and why not the other internal group?”
As soon as these questions are answered, the Business Analyst (BA) or Scrum Master needs to modify the user story to clearly identify the user groups who have access to the page and what are the differences in privileges. It should not be left up to the developer to contact the customer for clarification, nor to the QA/tester to identify when writing their test cases. Again, earlier is better.
Old vs. New
Another discriminating factor I have noticed is whether the new software is replacing legacy software or is completely new. If it is replacing legacy software, the BA is better served sitting alongside actual users of the legacy system to understand their business process and requirements. Often, I have seen cases where a manager identified the need for a particular feature or tried to map out a business process without gathering input from the end users and was way off track. Part of this BA effort is system mapping, where a flow diagram is developed to show flow from one task to another, or one process to another, such as the legacy system interacting with an outside system. Understanding the outside system’s performance characteristics can be very useful in debugging issues down the road, and it can often absolve the new system from undeserved criticism during system integration testing.
If we are dealing with a completely new business system or adding new functionality to a legacy system, the BA should make use of whatever documentation has been generated by the customer and dissect it, accordingly, into manageable epics and user stories, if this has not been done already. In waterfall development, for example, this would include Software Requirement Specification (SRS) and/or Use Case documents. In agile development, it would likely be a table extracted from a project management plan, or a spreadsheet.
There are several factors impacting effective requirements elicitation, but keeping in mind user types, security and legacy issues will set your project up for success. Great care must be taken by the development team to listen closely, ask questions, and review requirements with the customer to maximize understanding and minimize costly errors.