How to answer on the question: "How much and when?". Requirements gathering is an essential part of any project and project management. Understanding fully what a project will deliver is critical to its success. This may sound like common sense, but surprisingly it's an area that is often given far too little attention. Why process is critical? Is effective communication is more important than hard work? Like any people-centered business activity, software requirements development is difficult. When software pros team up with their business counterparts to specify exactly what the planned application should and should not do, mistakes are hard to avoid. These terms mean essentially the same thing. But requirements elicitation is preferred because it more accurately describes the challenging, back-and-forth conversation that must take place among stakeholders to specify an application's needs effectively. By contrast, requirements gathering suggests that requirements are fully formed and ready to be discovered, which, of course, is not the case. The idea that software requirements development is a simple, linear process is part of an outdated mindset, where "you ask people what they want and then build an application with the requested features".
Like any human undertaking, projects need to be performed and delivered under certain constraints. Traditionally, these constraints have been listed as "scope," "time," and "cost". These are also referred to as the "Project Management Triangle," (also known as the "Iron Triangle") where each side represents a constraint. One side of the triangle cannot be changed without affecting the others. A further refinement of the constraints separates product "quality" or "performance" from scope, and turns quality into a fourth constraint.
If the feature doesn't correlate with a business goal, it's not worth developing. Even though there is recognition of the importance of requirements gathering for application development, not enough has been done to explain the underlying need for a requirements gathering process or to develop methods to improve the process. Understanding and applying the right requirements elicitation techniques won't do a lot of good without the right people in the room. Every feature defined during requirements development must be traced back to a business objective. "If the feature doesn't correlate with a business goal, it's not worth developing". Testers should participate in the project from the outset, in order to get enough information to define tests properly.
There is no one perfect method for gathering and analyzing a project’s requirements. If there was, we’d all be using it. Rather, there are many approaches to choose from. This article is not about how to gather requirements, or the "right" method. Instead, it preparess you to formulate your own, customized requirements gathering procedure by explaining the key issues you should consider.
What is the top priorities for customer focus?
- Operational distribution or deployment: Where will the system be used?
- Mission profile or scenario: How will the system accomplish its mission objective?
- Performance and related parameters: What are the critical system parameters to accomplish the mission?
- Utilization environments: How are the various system components to be used?
- Effectiveness requirements: How effective or efficient must the system be in performing its mission?
- Operational life cycle: How long will the system be in use by the user?
- Environment: What environments will the system be expected to operate in an effective manner?
- Are the requirements consistent – not contradicting other requirements?
- Are any requirements in conflict with given stated assumptions or constraints (business environment, technical environment, cost, schedule, and resources)?
- Do the requirements support the stated business, system and project objectives?
- Are all activities and operations necessary? Are any identified requirements not required or out of scope?
- Are all data requirements necessary; are any not required or out of scope?
- Are the goals and objectives of the system clearly and fully defined?
- Have all events and conditions been handled?
- Have all operations been specified? Are they sufficient to meet the stated system objectives?
- Have all objects and data in the Activity Specification been defined in the model(s)?
- Have all required definitions and rules for objects and data been defined?
- Does the specification satisfy the level of detail required by the design team?
- Have all undefined, unresolved, incomplete specifications been identified for resolution?
- Are all requirements free of implementation bias (not restricted to a specific design alternative)?
- Are all requirements precisely and concisely stated?
- Have all operations been stated in terms of their triggering events or conditions, information requirements, processing and outcomes?
- Is the terminology and prose understandable by the business client/users?
- Is there any ambiguity in any of the statements (operations, rules, definitions, etc.)?
- Have all assumptions been clearly stated?
The art of writing requirements takes great skill and, like writing code, the end result is usually cleaner and more consistent if there’s a single author. Great care should be taken in selecting the author. It’s a matter of balancing the need for a thorough understanding of the project domain (i.e. the client’s business) against understanding the process of software development. An author with a great understanding of the project domain but no experience with software development is a risky choice. So is an author with no understanding of the project domain but extensive experience in software development. Ideally, you want to aim for an author that has both. If that’s not possible — which is often the case — make sure that good review processes are in place so that the details can be identified.
Key collaborative factors are: feedback, communication and motivation. We can always use following techniques for feedback like: daily stand up and status report, for communication we try to use normal talks, instead of "techie" and know our audience and finally for motivation we can encourage trust, partnership and self-discipline.
What are the top 10 Rules for Successful Requirements Gathering?
- To be successful at requirements gathering and to give your project an increased likelihood of success follow these rules:
- Don't assume you know what the customer wants, ask. Involve the users from the start.
- Define and agree the scope of the project.
- Ensure requirements are specific, realistic and measurable.
- Gain clarity if there is any doubt.
- Create a clear, concise and thorough requirements document and share it with the customer.
- Confirm your understanding of the requirements with the customer (play them back).
- Avoid talking technology or solutions until the requirements are fully understood.
- Get the requirements agreed with the stakeholders before the project starts.
- Create a prototype if necessary to confirm or refine the customers' requirements.
Brainstorming is used in requirements elicitation to get as many ideas as possible from a group of people. Generally used to identify possible solutions to problems, and clarify details of opportunities. Brainstorming casts a wide net, identifying many different possibilities. Prioritization of those possibilities is important to finding the needles in the haystack. Reviewing the documentation of an existing system can help when creating AS-IS process documents, as well as driving gap analysis for scoping of migration projects. In an ideal world, we would even be reviewing the requirements that drove creation of the existing system – a starting point for documenting current requirements. Nuggets of information are often buried in existing documents that help us ask questions as part of validating requirement completeness. A focus group is a gathering of people who are representative of the users or customers of a product to get feedback. Interfaces for a software product can be human or machine. Integration with external systems and devices is just another interface. Interviews of stakeholders and users are critical to creating the great software. Without understanding the goals and expectations of the users and stakeholders, we are very unlikely to satisfy them. The study of users in their natural habitats is what observation is about.
What are the top 10 techniques to avoid vague requirements?
- Document Analysis
- Focus Group
- Interface Analysis
- Requirements Workshop
- Reverse Engineering
By observing users, an analyst can identify a process flow, awkward steps, pain points and opportunities for improvement. Observation can be passive or active (asking questions while observing). Passive observation is better for getting feedback on a prototype (to refine requirements), where active observation is more effective at getting an understanding of an existing business process. Either approach can be used to uncover implicit requirements that otherwise might go overlooked. Prototypes can be very effective at gathering feedback. Low fidelity prototypes can be used as an active listening tool. Often, when people can not articulate a particular need in the abstract, they can quickly assess if a design approach would address the need. Prototypes are most efficiently done with quick sketches of interfaces and storyboards. Prototypes are even being used as the “official requirements” in some situations.
When a migration project does not have access to sufficient documentation of the existing system, reverse engineering will identify what the system does. It will not identify what the system should do, and will not identify when the system does the wrong thing. When collecting information from many people – too many to interview with budget and time constraints – a survey or questionnaire can be used. The survey can force users to select from choices, rate something (“Agree Strongly, Agree…”), or have open ended questions allowing free-form responses. Survey design is hard – questions can bias the respondents. Don’t assume that you can create a survey on your own, and get meaningful insight from the results. I would expect that a well designed survey would provide qualitative guidance for characterizing the market. It should not be used for prioritization of features or requirements.
Project management triangle
Gather the right amount of information, because gathering requirements is hard work and it should be effective. We should break up requirements gathering process into multiple iterations to adapt to any project type. Managing a product backlog with priorities and estimates is critical for each release. Effective collaboration with all participants will foster trust and therefore enable honest feedback and increasing motivation for all. There is no silver bullet, no one answer, no perfect approach method or technique to requirements gathering. Developing a good requirements document is about giving your project the best chance of success. To do so, you must reduce the risk of common mistakes that arise from a lack of communication or understanding. Keep this in mind as you gather your requirements, and the documentation — and project as a whole — will have the best chance of success.