Aggregating and Extracting Product Requirements
Aggregating and Extracting Product Requirements
Having success in software development isn't always just about making a good product, it's about making the right product at the right time.
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
Studies indicate that between 40% - 60% of all defects in software projects can be traced back to errors made in gathering requirements. Lack of clarity in the scope of business functions and ill-defined business requirements are identified as the top two challenges that business analysts face in managing requirements.
Arguably, the most important part of software product development or any technology project begins well before even a line of code is written, i.e. at the requirement gathering stage. The requirement document not only provides a blueprint to an intelligent, well-defined roadmap but also increases the probability of ensuring a projects’ timely success.
Software development professionals must follow a meticulous process. The goal is to get the software development team and users on the same page very early on. Moreover, identifying issues to minimize the gap between what users expect and what software product engineering team thinks is easier and less expensive to detect and fix in the earlier stages of development.
Importance of Requirement Gathering
Although requirement gathering may seem logical, it is given far too little attention. So how do we determine the needs and expectations of what consumers expect to receive? We do it through requirement gathering and user test cases.
Requirement gathering is either functional or non-functional and usually includes three types of activities, eliciting requirements, analyzing and recording requirements, aimed at creating a clear and concise outline of what the project aims to achieve.
While functional requirements refer to the desired functionality that a client wants, the processes, information, and interactions that a product must perform, scope of software product or boundaries, business rules and data models, the non-functional requirements address the visual properties of the system apart from the environment they’ll operate in, the technical requirements, cultural, political, legal or security requirements. Once the requirements have been established, it is time to implement MoSCoW (Must Have, Should Have, Could Have, Won’t Have) prioritization to help understand priorities.
Here Are the 7 Guidelines for an Effective Requirement Gathering:
There is no perfect way of gathering, aggregating, or extracting product requirements. However, these are just major guidelines:
- Involve the end-user from the start to define and agree on a well-defined scope of the project.
- Do not work on assumptions – always ask the user.
- Must be unambiguous and clearly describe the criteria with easy-to-follow written documentation of the requirements and share it with customers and confirm their understanding.
- Must be feasible so that it can be accomplished.
- Develop SMART (Smart, Measurable, Achievable, Realistic, and Timely) requirements, giving attention to the what and not the how.
- Understand the environment in which the software will run.
- Create a prototype to confirm or refine customer’s requirements.
Thus, a stronger foundation and understanding of the project through requirement gathering paves the way for a smoother and better software development process.
Define the Critical Objectives and Purpose
Before you get started with requirement gathering, you will need a clear and well-defined project scope to define critical objectives and purpose, thus fixing boundaries for requirements to be gathered. By defining the goals and setting milestones, not only does the Agile team increase the probability of success, but they are also able to better tackle the challenges and obstacles that they are likely to face. As a statement of purpose, each goal must have its purpose and is a powerful way to achieve flexibility in solving a problem.
- Requirement Gathering is what we are aiming to achieve.
- Objectives are what we actually deliver.
- Purpose is what the business gains from the output.
Talk to the Stakeholders and Apply Good Interpersonal Skills
A stakeholder is anyone with an interest in the project and it is important to gather accurate, complete requirement so they do not have any unrealistic expectations as to what is possible and what is not. Thus, there must be constant participation and communication with the stakeholders to address their expectations and concerns.
Quality and accuracy of requirements are critical. Therefore, it is advisable to properly gather requirements by selecting appropriate techniques and multiple tools for gathering requirements from stakeholders:
- Facilitated small group workshop sessions with a facilitator to gather data.
- Conference call interviews.
- One-on-one interviews in person.
- Group interviews.
- Requirement gathering tools like JIRA, Trello, HP ALM.
- On-line surveys.
Once the requirement is gathered, developing a prototype and reviewing it again with the stakeholders is a great way to get everyone on the same page, have all the necessary information, and ensure a successful project.
Apart from open-ended and close-ended questions, probing is a powerful tool in requirement gathering. An effective way of probing is not to ask questions from information that is readily available from other sources, but rather ask questions that help the responder think more deeply about the project. This, in turn, will help to elucidate the user/stakeholder’s requirements. Thus, you can obtain information to uncover requirements without the users or stakeholders feeling inhibited about what they need or expect from the project.
To develop a great product, it is imperative to be able to think from multiple viewpoints. Think broadly to inculcate a range of perspectives to allow the team in charge of product development to acquire a greater understanding of the actual market dynamics and maximize the probability of success. It involves considering the long-term vision, what users think about your product and what they are saying, what your competitors are doing, and the overall macro trends. Also, be on the lookout for new technologies to allow you to create disruptions well before others. Thus, you need to constantly view the bigger picture.
Choose the Best Methodology Based on the Requirements
Cost and time prove to be the most important factors when determining the best methodology. However, Agile, the iterative, team-based development process, continues to be the undisputed approach. With its time-boxed Sprints and continuous feedback loops, Agile can deliver better results by giving back control of the project.
However, you may follow these guidelines to choose the best methodology based on your requirements:
When to Choose theWaterfall Model: When the requirements are clear, well-known and fixed, product definition is fixed, technology is understood, and there are no ambiguous requirements.
When to Choose the Agile Model: When new changes are to be frequently implemented and can be done so at a very little cost. The developers take only a few hours or days to implement a new feature and when the changes can be discussed and features can be added or removed based on feedback.
Define the Capability Scope – Scope Document
Considered as one of the most challenging tasks of project management, the project scope document includes the goals and objectives of the project, the product description, and requirements for the project, the constraints and assumptions, and the risks associated with the project. This document should also include the acceptance criteria for the end product. The project requirement is essentially where product requirements are thoroughly understood and documented.
Most project value propositions include reduced cost, faster to market, increased operational efficiency, or even increase in market share. However, they must also address genuine user needs and go beyond the basics. Value proposition must be specific and a clear statement of tangible benefits a user stands to gain. It is equally important to mitigate scope creep because it is a slippery slope that can be difficult to recover from. You can manage it by well-defined customer requirements and ensure deviations are not encouraged and they are as per the agreed contract.
Remove/Discard Any Unrealistic Scope
The measure of the success of a project is its ability to remove and discard any unrealistic scope. Scope and objectives are the foundations on which the success of a project is built, therefore you must ensure that you discard any unrealistic scope so it does not hamper development at a later stage. An effective way to do this is to consult with each stakeholder to identify their needs and expectations, which allows you to:
- Avoid setting unrealistic outcomes.
- Provide a more realistic timeline.
- Avoid Scope Creep.
- Set unrealistic targets or deadlines.
Successful project scope statements should be realistic, clear, and concise. Setting unrealistic outcomes, and schedules prevent your project from succeeding.
Often a lack of understanding of the limitations of the IT infrastructure can lead to a situation where the client wants something that the software development team can simply not deliver. Managing requirement gathering is even more challenging in a globally dispersed team given the technology challenges and constraints. Thus, it is necessary that all stakeholders understand the technical limitations and be open to accepting alternative solutions. The best way to tackle technology challenges is to identify the actual requirements and put a framework in place which enables stakeholders to know what technology options are available and what the development team can do.
Consider the Risks Included
Analysis and requirement management are instrumental to a project’s success, therefore, it is advisable to run risk management processes throughout the product lifecycle stage. If stakeholders are not engaged properly or early enough, this can lead to unrealistic project outcomes. As certain risks are directly associated with specific requirements, this may open risks of regulatory non-compliance, legal issues, PR issues, unexpected costs, and process bottlenecks.
Critical Assumptions Based on Analysis
Apart from an emphasis on requirement gathering, articulating assumptions and constraints plays an equally important part. Assumptions are factors believed to be true but not confirmed, while constraints, like project budgets or deadlines, are limitations on possible solutions. Although clear and concise objectives leave less room for assumptions or varied interpretations, you must make intelligent and informed assumptions based on your analysis.
Feasibility Study and the Prediction of Success Ratio
A feasibility study is critical to gain the commitment of your senior management and obtain resources and project funding. Apart from helping predict the success ratio, feasibility studies also enable you to identify the risks associated with the project, thus providing valuable input to the requirement gathering efforts. It is used to evaluate a project’s potential for success and whether the solution is viable, practical, and workable as well as economically justifiable within the budget and schedule. The two key criteria to judge feasibility are cost required and value to be delivered. Key areas that feasibility studies emphasize to predict success ratios include:
- Technical Feasibility
- Economic Feasibility
- Legal Feasibility
- Operational Feasibility
- Scheduling Feasibility
Piecing together a requirement gathering plan for your project doesn’t have to be a monumental task. All it requires is an organized plan to steer your project to success.
Published at DZone with permission of Manmay Mehta . See the original article here.
Opinions expressed by DZone contributors are their own.