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?
Accurate:
- 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?
Complete:
- 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?
Clear:
- 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?
- Brainstorming
- Document Analysis
- Focus Group
- Interface Analysis
- Interview
- Observation
- Prototyping
- Requirements Workshop
- Reverse Engineering
- Survey
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.
1. Establish Clear Communication Channels:
- Ensure there are open and effective lines of communication between all parties involved, including clients, stakeholders, and the development team.
- Designate points of contact for clarity and accountability.
2. Gather Comprehensive Requirements:
- Conduct thorough requirement gathering sessions with all stakeholders.
- Use interviews, surveys, workshops, and observation techniques to collect detailed information.
3. Define and Prioritize:
- Clearly define each requirement, including scope, purpose, and acceptance criteria.
- Prioritize requirements based on the project’s objectives and stakeholder value.
4. Use Specific Language:
- Avoid ambiguous terms and jargon. Be specific and use clear, understandable language.
- Include examples, scenarios, or use cases to clarify complex points.
5. Create Detailed Documentation:
- Document the requirements in a structured format, using templates or tools that ensure comprehensiveness and clarity.
- Include diagrams, flowcharts, or models where necessary to visualize complex processes or relationships.
6. Review and Validate:
- Regularly review the requirements with stakeholders and the development team to ensure alignment and understanding.
- Validate requirements by ensuring they are testable and align with business needs and user expectations.
7. Implement Version Control:
- Keep track of changes to the requirements over time. Use a version control system to manage modifications and ensure that everyone is working with the latest version.
8. Seek Feedback and Approval:
- Obtain feedback from all relevant parties to ensure the requirements meet their needs and expectations.
- Seek formal approval from key stakeholders to confirm that the requirements are correctly understood and agreed upon.
9. Train and Educate:
- Train your team on the importance of clear requirements and how to write and manage them.
- Educate stakeholders on the impact of vague requirements and the value of precise, detailed input.
10. Continuous Monitoring and Adjustment:
- Monitor the implementation of requirements throughout the project lifecycle to ensure they are being met as expected.
- Be prepared to adjust requirements as project needs evolve, while maintaining clarity and specificity.
11. Use Requirement Management Tools:
- Utilize requirement management software to organize, track, and maintain requirements throughout the project lifecycle.
12. Encourage Collaboration and Participation:
- Foster an environment where team members and stakeholders feel comfortable asking questions, suggesting improvements, and providing clarifications.
By implementing these strategies, you can minimize misunderstandings, reduce the risk of project delays, and ensure that the final product meets the intended goals and satisfies all stakeholders. Clear and concise requirements are the foundation of any successful project, leading to better planning, execution, and outcomes.
References
Requirements analysis
Project management triangle
Summary
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.
