Effective Requirements Gathering: The Key to Success with IT Outsourcing

The bitter pill first. Approximately one in three projects fail because of unclear requirements. All wasted efforts, time, and money result from vague directions.

The better news: you can apply specific steps and techniques to build a formal process of documenting all the software requirements for a successful project kick-start. Read this blog post to receive a cherry-picked information about requirements gathering relevant to software development projects. Let’s zoom in on the details.

What is Requirements Gathering? 

Requirements gathering (or requirement elicitation) is a business analysis process of determining and documenting new software’s functions, characteristics, and expected behavior.

The requirements gathering process mainly generates brief written statements representing project needs.

Research, analysis, and collaboration are essential components of requirements gathering. So, you’ll need to talk to key stakeholders directly, research the market, and test different assumptions.

The requirements gathering process ensures that everyone on the team:

• Aligns with the product vision
• Understands the software’s purpose and core functions
• Knows the ultimate project goals and the overall business context

Despite the apparent simplicity, the requirements gathering process is more complex than it seems. Initially, vague ideas are hard to break down into a list of precise descriptions.

Example: It’s not enough to decide to build a mobile payment app. You’ll need to document user actions, system responses, and technical requirements for every feature. The devil is in the details.

Also, some requirements may continue to evolve throughout the development process. In this case, requirements gathering helps to keep development aligned with business needs even when things change.

How Poor Requirements Influence Project Outcomes

Projects fail due to inaccurate gathering processes. Just think about it: even given a great idea, 35% of projects will not meet users’ or clients’ expectations because the specifications are vague, do not match the actual needs, or fail to provide enough details.

Other adverse effects of poor requirements gathering include:

1. Inadequate Stakeholder Expectation Management

If requirements are unclear 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 risk not receiving the software product you expected.

2. Lack of Team Agreement

Generally, when requirements are unclear, people interpret them based on their prior knowledge, which might not necessarily mirror the business’s and customers’ real needs.

3. Financial Inefficiency

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 goes to waste due to poor project requirements.

4. Unrealistic project timeline

Unrealistic time estimates can stem from requirements that don’t match the project scope and needs. When you constantly expand or change requirements mid-project, your team may need to extend the deadline (resulting in extra costs).

5. 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.

Requirements Gathering is Vital for Outsourcing Projects

The above factors are pressing enough for in-house development teams. 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 project objectives 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, a discovery workshop will help gather them and establish 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:

Business Requirements 

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 it assesses the success of this project.

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.

An example of a business requirement: “We need a new payment method integration to process QR payments at POS.”

Technical Requirements

Technical requirements describe software engineering aspects of the product that must be fulfilled, such as performance, reliability, and availability.

An example of a technical requirement: “We need a PCI-DSS compliant payment processor with an open API, with 99.99% availability”.

Functional Requirements

The BABOK 3.0 defines a functional requirement as a characteristic a solution must have regarding 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.

An example of a functional requirement: “We need to divide users into separate user roles (customer, reseller, administrator) with different levels of access”

Non-Functional Requirements 

Non-functional requirements (or 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).

An example of a non-functional requirement: “The app should be able to handle 50 million users without changes in performance”

How to Gather Product Requirements for IT Projects: Best Practices and Techniques

Requirements gathering is a collaborative process of exchanging knowledge, ideas, and preferences between project stakeholders, business analysts, and tech people. But to maintain such discussions productive and result-oriented, you must keep the conversations well-scoped and structured.

To do so, follow these requirement gathering best practices: 

• Define roles: Determine the participants of the requirement gathering process. Typically, you’ll need to engage business leaders, department heads, end-users, and delivery teams (developers, BA, project managers, testers, designers, and customer support). Depending on your project, you may also need to elicit requirements from contractors, investors, suppliers, or partner organizations.

• Regularly communicate: Hold discussion sessions with stakeholders to determine their product development goals, changes they’d like to see, and challenges they’d like to solve. Ensure requirements remain relevant by collecting stakeholders’ feedback throughout the product development process.

• Maintain clear records: Condense your requirements into short, unambiguous sentences (like user stories) and approve them with all stakeholders.

• Provide shared understanding: Communicate requirements clearly with the team so everyone understands each requirement. As you go through each iteration, refine requirements with the team based on the new feedback or changes in market conditions.

• Apply business analysis techniques for requirements gathering: Align and cooperate with stakeholders, users, and tech specialists more efficiently by holding well-structured interviews, workshops, surveys, and more.

6 Examples of Requirement Gathering Techniques

Techniques for gathering requirements can significantly enhance and accelerate the elicitation process. Amongst the most popular requirements-gathering techniques are:

• Interviews with relevant stakeholders
• Requirements workshops
• Documentation analysis
• Surveys and questionnaires
• Market analysis
• Brainstorming

1. Interviews with Stakeholders

Stakeholders set the baseline expectations, clarify the project vision, and voice out the needs and preferences for the final product. Retrieve this information in a series of interviews.

How this process works in practice: based on a type of need, a business analyst (or a project manager) 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 actual users or people who represent your buyer personas and know what your target audience wants (e.g., product owner)

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 Stakeholder Interview Efficient?

1. Thorough preparation of questions beforehand
2. In-depth knowledge of a domain by both the interviewer and interviewee
3. Experience with conducting interviews
4. Thorough meeting notes
5. Motivation and time commitment to providing relevant information
6. Clearly defined interview goals

2. Requirements Workshops

Requirements workshops are meetings where 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 an excellent opportunity to generate ideas and establish effective collaboration practices.

What Makes a Workshop Efficient?

1. Stakeholders respect the opinions of one another
2. Everyone contributes
3. Participants restrict off-topic discussion to a specific time
4. Discussions focus on ideas rather than people
5. There is an agreement on the decision-making process

3. Documentation Analysis

Documentation analysis involves examining available written materials and existing organizational assets. These materials may include current product specifications, technical documentation, compliance documents, problem reports, lessons learned from previous projects, and procedure manuals.

Documentation analysis helps:

• Obtain background information
• Capture the context of a business need
• Verify the interview and workshop information
• Identify and address systemic gaps
• Determine opportunities for a change

Usually, documentation analysis is the responsibility of business analysts.

4. Surveys and Questionnaires

Surveys and questionnaires are another tool for gathering information from stakeholders. After collecting the answers, business analysts can compile information about customers, products, and work practices or validate the requirements.

Consider your current project goal to decide what participants to engage in the survey. For example, if you need to elicit information about the app’s architecture, contact software architects.

General tip: questions should be neutral and straightforward, especially if they are in written form. As a result, the respondent will less likely provide desirable, but not objective, answers.

5. Market Analysis

Chances are you want your product to end up both technically sound and commercially successful. To ensure that, ask your business analysis specialists to conduct a market analysis.

Market analysis helps identify services and products users need or want, pain points that trigger their purchase, and offers they receive from your competitors. Market analysis information helps you:

• Fine-tune the user experience of your future product
• Decide when it’s the best time to roll out a product
• Anticipate market trends and timely respond to them
• Expose weaknesses in your initial assumptions

6. Brainstorming

Brainstorming is a business analysis technique applied to quickly produce many ideas, assumptions, and options.

Brainstorming works best in a group that has different levels of experience with the selected topic of the problem. People without technical or industry expertise (like end users) might generate unobvious but valuable insights.

What Makes Brainstorming Efficient?

1. Focus on one topic per session
2. Creative freedom and no criticism or limit for ideas
3. Time restriction for the session
4. Criteria for rating and evaluating ideas

Requirements Gathering: Agile vs Waterfall Projects

Traditional software development methodologies like Waterfall assume pre-project requirements gathering. Due to the rigid SDLC structure, delivery teams often base requirements on assumptions and cannot change them mid-development. Eventually, such project requirements become less relevant as user needs and market conditions change.

Waterfall SDLC:

Agile methodologies, in turn, enable teams to gather, evaluate, and refine requirements during each iteration. This way, requirements remain up-to-date and aligned with dynamic business needs, user preferences, and market conditions. For instance, half of the “2022 State of Agile” respondents indicate that such a project lifecycle helps them better align with business needs.

Agile SDLC:

How to Gather Requirements in Agile 

For agile projects, requirements are gathered during the discovery phase and then constantly refined at the beginning of every software development iteration. Agile’s most common end-form of requirements is a user story – a one-sentence summary of the intel obtained during interviews, workshops, surveys, and others.

How to Create User Stories 

A user story is a 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 to purchase them later.”

A user story is the end form of requirements. It’s convenient to use throughout development because user stories are precise, brief, and straightforward.

Barriers to Effective Requirements Elicitation

Gathering software requirements comes with many dependencies. The elicitation process requires engagement from all parties and time commitments.

Here are some common challenges to consider:

• Unengaged stakeholders. Stakeholders may be reluctant to engage due to the lack of trust, time, and the assumption that everything is understandable without clarifications. Yet, software development’s success depends on all stakeholders’ input.
• Short discovery timelines. When this phase is brief, 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 it’s essential.

To Conclude

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 learning more about our approach to software development? Contact us!