We have good news and bad news. Let’s swallow the bitter pill first. Approximately one in three projects fail because of unclear requirements. All wasted efforts, time, and money are a result of vague direction.
The better news: we can show you how to improve your requirements gathering process. The key to an effective project kick-start is building a formal process of eliciting and documenting all the software requirements during interviews and workshops. Let’s zoom in on the details.
What is Requirements Gathering?
Requirements gathering (also requirements elicitation) refers to determining and documenting what functions new software must have and how it should perform under specific conditions. Requirements elicitation mainly consists of generating brief written statements that represent project needs.
Research, analysis, and collaboration are essential components of requirements gathering. Elicitation involves talking to stakeholders directly, researching the market, and testing different assumptions.
The requirements gathering process ensures that everyone on the team:
- Are aligned on the product vision
- Understand the software purpose and core functions
- Know the ultimate project goals and the overall business context
Despite the apparent simplicity, the requirements gathering process is not as straightforward as it seems. Initially, vague ideas tend to be hard to break down into a list of precise descriptions. It’s not enough to simply decide that you want to build a mobile payment app. You will need to document user actions, system responses, and technical requirements for every feature. The devil is in the details.
Secondly, some requirements may continue to evolve throughout the development process. In this case, requirements elicitation helps to keep development aligned to business needs even when things change.
Defining Characteristics of Great Requirements for Software
- Aligned with identified needs
- Ranked and grouped
How Poor Requirements Influence Project Outcomes
Requirements have a profound impact on a project’s success because projects fail due to inaccurate elicitation processes. Just think about it: even given a great idea, 35% of projects will not meet users’ or clients’ expectations just because the specifications are vague, do not match the real needs, or fail to provide enough details.
Other negative effects of poor requirements elicitation include:
Inadequate Expectation Management
If requirements are not defined at the outset, you don’t have a reference point for your expectations for the final product. Subsequently, it’s hard to justify the investment. Furthermore, you will run the risk of not receiving the software product you expected.
Lack of Team Agreement
Generally, when requirements are unclear, people interpret them based on their prior knowledge, which might not necessarily mirror the real needs of the business and customers.
Unclear requirements often lead to reworks and a slow project pace. To the point that in 75% of organizations, every one in three dollars spent on software development is wasted due to poor project requirements.
Unmet Business Needs
If requirements fail to articulate the needs of the business, even the most technologically adequate app will not deliver on the set needs.
These factors are pressing enough for in-house projects. When it comes to IT outsourcing, the stakes become even higher. After all, your vendor may not fully comprehend your business’ context or be able to gauge your goals and strategy. From this perspective, outsourcing only emphasizes how important it is to get everyone on the same page and to establish clarity.
Due to the knowledge gap, it is necessary that you approach your vendor with all relevant materials and a predefined list of requirements. By doing so, you can expect your outsourcing vendor to only expand upon your specifications and validate them. Yet, if you do not yet have requirements in place, then a discovery workshop will be helpful in gathering them and establishing a collaboration with your outsourcing partner.
Main Types of Project Requirements in IT
Requirements are a list of characteristics a software product needs to have. These “characteristics” can be grouped into:
As per Guide to the Business Analysis Body of Knowledge (BABOK) version 3.0, a business requirement is a representation of goals, objectives, and outcomes that describe why a company initiates a project and how the success of this project will be assessed.
A business requirement summarizes the features and functions your product requires to satisfy end-user needs or run a business process in a new way.
For example: “We need a new payment method integration to process QR payments at POS.”
Technical requirements describe software engineering aspects of the product that must be fulfilled such as performance, reliability, and availability.
For example: “We need a PCI-DSS compliant payment processor with an open API, with 99.99% availability”.
The BABOK 3.0 defines a functional requirement denote characteristics that a solution must have in terms of behavior and information management.
Functional requirements specify what a system should and should not do in defined circumstances. They are determined by the type of software and user needs it attempts to address.
Example: “Users need to be divided into separate user roles (customer, reseller, administrator) with different levels of access”
Non-functional requirements (also called quality of service requirements) do not relate directly to the product’s functionality and behavior. Instead, they define what makes the product effective and what qualities it should have (e.g. how secure/usable/scalable the solution is).
Example: “The app should be able to handle 50 million users without changes in performance”
Examples of Requirement Elicitation Techniques
Requirements gathering is a collaborative process of exchanging knowledge, ideas, and preferences between project stakeholders, business analysts, and tech people. But to keep such discussions productive and result-oriented, you need to keep the conversations structured.
Below are several popular requirement elicitation techniques that help with that.
Interviewing stakeholders is an important step in gathering requirements. Stakeholders set the baseline expectations, clarify the project vision, and voice out the needs and preferences for the final product.
Based on a type of need, a business analyst defines the goals and objectives for the interview.
For example, if you need to collect user requirements, you will need to conduct interviews with the real users or people who represent your buyer personas and know what your target audience wants (e.g. product owner)
The choice of questions also depends on the interview’s goal. The following are examples of basic questions to include in the elicitation interview:
- “What functionality do you need from the system?”
- “What problems should this app solve?”
- “Who will be using the app?”
- “Do you have performance problems that need to change?”
- “Why is this requirement important to your business/customers/users?”
What makes an interview efficient?
- Thorough preparation of questions beforehand
- In-depth knowledge of a domain by both the interviewer and interviewee
- Experience with conducting interviews
- Accurate documentation of answers
- Motivation and time commitment to providing relevant information
- Clearly defined interview goals
During requirements workshops, stakeholders work together to collect requirements, review them for feasibility, and reach a consensus on whether or not they are feasible. Usually, you’ll have a mix of business and technical people present.
At Edvantis, we offer to host requirement gathering workshops during the discovery phase. A workshop provides both a good opportunity to generate ideas and to establish effective collaboration practices.
What makes a workshop efficient?
- Stakeholders respect the opinions of one another
- Everyone contributes
- Participants restrict off-topic discussion to a certain time
- Discussions focus on ideas rather than people
- There is an agreement on how decisions are made
Documentation analysis involves examining available written materials and existing organizational assets. These materials may include current product specifications, technical documentation, compliance documents, problem reports, and procedure manuals.
Documentation analysis is mostly used for the following purposes:
- Obtain background information
- Understand the context of a business need
- Verify the interview and workshop information
- Identify and address systemic gaps
- Determine opportunities for a change
Documentation analysis is mostly performed by business analysts.
Surveys and Questionnaires
Surveys and questionnaires can assist in gathering information from stakeholders about customers, products, and work practices. After collecting the answers, business analysts can compile or validate the requirements.
The process objective determines which participants to engage in the survey. For example, if you need to elicit information about the app’s architecture, get in touch with software architects. General tip: questions should be neutral and straightforward, especially if they are written. As a result, the respondent will not be conditioned to provide desirable, but not objective, answers.
How Project Requirements are Documented
Despite the fact that requirements elicitation techniques provide a breadth of information, they should be structured in a digestible manner. The most common end-form of requirements is a user story. Basically, a user story is a one-sentence summary of the intel, obtained during interviews, workshops, surveys, etc.
How to Create User Stories
A user story is a brief, concise statement summarizing the software quality from the end-user perspective.
In software development, we apply user stories in planning, prioritizing, and estimating software development tasks. User stories also help capture stakeholders’ needs, generate user acceptance tests, and trace related requirements.
A use story includes:
- Who — a user role
- What — a necessary action, behavior, or feature
- Why — the benefit or value the user receives if the story is implemented).
Examples of user stories:
- “As a subscriber, I want the ability to cancel my subscription at the beginning of the month so that I can stop accruing charges”
- “As a customer, I want to add products to my wishlist in order to purchase them later”
A user story is the end form of requirements. Because it is precise, brief, and clear, it is convenient to use it throughout the development.
Barriers to Effective Requirements Elicitation
Gathering software requirements comes with a lot of dependencies. The elicitation process requires engagement from all parties and time commitments.
Here are some common challenges to account for:
- Unengaged stakeholders. Participation may be hindered due to the absence of trust, the lack of time, and the assumption that all will be understood with no clarifications. Yet, the success of software development depends on the input of all stakeholders.
- Short discovery timelines. When this phase is shortened, you risk taking product development in the wrong direction from the very beginning.
- Lack of end-user participation. Ask them: what problem they want your product to solve and why this is important to them.
Developing an app without requirements is like assembling IKEA furniture without instructions: you know how it should generally look at the end, but have no idea how to get there. To avoid such a scenario, put some time and effort into the elicitation process. And if you go for outsourcing, remember: requirements gathering paves the way for an efficient engagement process with your vendor, leading to smoother project kick-off.
Interested in starting a new project or learn more about our approach to software development, contact us!