Effective Requirements Gathering: The Key to Success with IT Outsourcing

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 

1. Self-contained
2. Complete
3. Aligned with identified needs
4. Concise
5. Feasible
6. Unambiguous
7. Testable
8. Ranked and grouped
9. Understandable

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.

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 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: 

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

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

Functional Requirements

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 

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” 

How to Gather 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 keep such discussions productive and result-oriented, you need to keep the conversations well-scoped and structured.

To do so, follow these requirement gathering best practices: 

• Define roles: Determine who will need to participate in the requirement gathering process. Typically, you will need to engage business leaders, department heads, end-users, and delivery teams (developers, BA, testers, designers, and customer support). But depending on your project, you might also need to elicit requirements from your contractors, investors, suppliers, or organizations you partner with. 

• Have regular communication: 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 feedback from stakeholders throughout the whole 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 that everyone understands what each requirement entails. As you go through each iteration, make sure you refine requirements with the team, based on the new feedback or changes in market conditions. 

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

Examples of Requirement Elicitation Techniques 

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

• Stakeholder interviews
• Requirements workshops
• Documentation analysis
• Surveys and questionnaires

Stakeholder Interviews

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

Requirements Workshops

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

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. 

Despite the fact that requirements elicitation techniques provide a breadth of information, they should be structured in a digestible manner.

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 midway through 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 always remain up-to-date and in line with dynamic business needs, user preferences, and market conditions. For instance, half of the “2022 State of Agile” respondents indicate that this methodology helps them achieve better alignment with business needs.

Agile SDLC:

How to Gather Requirements in Agile 

For agile projects, requirements are mostly gathered during the discovery phase and then constantly refined at the beginning of every software development iteration. The most common end-form of requirements in agile 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. 

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 learn more about our approach to software development, contact us!