CSE 370: Software Engineering Principles

W02 Learning Activity: Requirements Elicitation

Overview

One of the most important parts of the software development life cycle (SDLC) is to clearly define the requirements of the system or product that you will build. The requirements that you document during this phase will be used throughout the rest of the life cycle as each part of the design, development, and testing should trace back to a clearly stated requirement.

Preparation Material

In its simplest form, gathering requirements amounts to asking customers or end-users what they want and writing it down. As it turns out, this is an incredibly hard problem!

When we ask customers what they want, in a way we are asking them to define the solution to their problem—but this can be an unfair question. In some cases, customers know exactly what they want, but in most cases, they simply know they have a problem, and it is your job to help solve it.

The requirements gathering process helps customers define their needs and desires. Since these needs are often unknown, agile methods have become very popular, because they can adapt as the customer's understanding and desires change.

Requirements Elicitation in the SDLC

Whether in an agile or a more traditional approach, requirements elicitation is one of the first steps in any iteration of the Software Development Life Cycle (SDLC). It is where you determine and document what the project should do.

All of the SDLC phases that follow requirements elicitation rely on clear, precise requirements. When designing the project, each element in the design should trace back to one or more requirements. During development, everything that is written also traces back to these requirements. Requirements are especially critical in the verification and testing phases, because this is where you ensure that the code or product actually meets the requirement. Finally, as you rollout the new features, you monitor how well the users' needs are being met to refine the requirements or to define new ones as you plan for the next iteration of the project.

Working with the Customer

As mentioned, working with the customer or another stakeholder is an important part of determining the requirements of the project. This section highlights principles of effectively working with customers.

Initiate Communication (Identifying Stakeholders)

Initiating communication is the first step in working with the customer. You need to identify key stakeholders that you can work with to define what the project should do. Establishing clear lines of communication with people directly involved or affected by the project is crucial. Communicating with the customer will help you understand their perspectives, needs, and expectations.

You should also recognize that no project exists in isolation. Each project can be impacted by many other projects or factors at a company, including budgets and timelines. In addition, there are also external factors to consider such as the politics at the company, where different people have their own agendas they are pursuing. Each of these factors can present risks to the project's success, so understanding these dynamics early-on is very important.

Explore Similar Projects

Exploring similar projects is a valuable approach in understanding customer requirements. Sometimes a customer may be able to point to an existing application and say they want something similar to it. You can then walk through that application together talking about similarities and differences.

By examining projects with similarities, analysts can gain insights into successful solutions and potential challenges. This comparative analysis aids in formulating effective strategies and identifying best practices that can inform the current project's requirements.

Prioritizing Requirements

Not all requirements carry the same weight, and understanding their significance helps in making informed decisions. By prioritizing requirements, the team can focus on critical aspects first, ensuring that essential elements are addressed before less crucial ones. This is a critical part of working with the key stakeholders—to understand what really matters to them.

One way to consider the prioritization of requirements is to analyze the risks or problems that would occur if that requirement was not satisfied and prioritizing them accordingly. Similarly, you may be able to identify the elements that are needed by the customer now as opposed to those that can be added in the future.

As you work with the stakeholders, you may need to educate them about the features that are feasible and prudent, because in many cases, seemingly simple requirements can be quite technically difficult.

Importance of Documenting Assumptions

Documenting assumptions is a critical part of the requirements gathering process. Since not all details may be immediately available, it's important to capture any assumptions made during the initial stages. This documentation ensures transparency and provides a reference point for future decision-making.

Iterate (Gathering More Information)

Iteration is a key aspect of the requirements gathering process. When gaps or uncertainties are identified, it's essential to go back and gather more information from the key stakeholders. This iterative approach allows for refinement and adjustment, ensuring that the requirements are accurate and aligned with the evolving understanding of the project.

Techniques for Gathering

There are many different techniques for gathering requirements depending on the type of customer or end-user you are working with. The following are a few common approaches. You could spend weeks or months learning the details of each of these methods, but for the purposes of this course, it's most important to simply be aware of these common approaches.

Document Analysis

Document analysis involves thoroughly reviewing existing project documents like reports or manuals. This helps gather important info about the project's current state and requirements. By digging into these written materials, analysts can figure out what's missing and understand the project's context and goals.

Interviewing

Interviewing means having direct talks with stakeholders. By visiting with people involved in or impacted by the project, analysts can learn more about their needs and concerns. This method helps get a clear picture of different perspectives and identifies specific requirements that might not be obvious otherwise.

Observation

Observation is about watching processes, systems, or users in action. By directly seeing how things work, analysts can understand real-world scenarios, find challenges, and spot chances for improvement. This method is great for capturing practical knowledge and making sure requirements match the project's real-life aspects.

Prototyping

Prototyping is a hands-on approach that involves creating simple versions of the system or product to test specific features. Stakeholders can interact with these prototypes, giving feedback on design and functionality. This feedback helps refine requirements, catch potential issues early, and make sure the final product meets user expectations.

Validating

Validating is a crucial step that ensures gathered requirements are accurate and relevant. It includes feedback sessions and reviews to confirm that the proposed solution aligns with project goals and stakeholder expectations. By validating requirements, analysts can improve the quality of the gathered information and reduce the risk of misunderstandings during development.

Documenting Requirements

Once you have identified the necessary requirements, you need to document them in some fashion. Various companies and projects have very different approaches to the way they document requirements, ranging from more strict and well-defined, to just capturing the important principles.

The approach you choose is driven by the kind of problem you are working on and the risks associated with failure. For example, a project for a national defense company is likely fairly well defined, but the cost of error is so dramatic that you have to be very rigorous and detailed in documenting each requirement. On the other hand, many business problems, such as creating a new app for people to use, may have so many unknowns and may change so rapidly, that trying to document it to the same detailed level would be not only very difficult, but also not very useful.

The decision of the amount of detail and formality is therefore not a question of whether your personal style is more formal or not, but rather it is about understanding the software you are writing and the context associated with it.

Bulleted Lists

In the most simple terms, requirements can be documented by creating a bulleted list of desired features. While some companies may use this method, you should carefully consider whether this is appropriate for your problem. In most cases, a bulleted list does not contain sufficient detail to inform the design and development stages that follow.

The following are examples of requirements listed in a bulleted list format:

User Stories

User stories are written in a narrative format that focuses on describing a feature from an end user's perspective. Typically user stories use the format of "As a [user], I want [action] so that [benefit]." For example, "As a client at the bank, I want to see my account balance when I first log in, so that I know how much money I can spend." User stories emphasize the user's needs and goals. Because the format is based on a specific user or role, it makes it easier to prioritize and understand requirements based on the user's experience and value.

User stories also contain acceptance criteria that are the conditions that must be met for the user story to be considered complete. They provide specific details and scenarios to ensure the functionality meets the user's needs. The acceptance criteria typically use the format of "Given ______ when ______ then ______" such as "Given that I have logged into my bank account, when I arrive at the landing page, then I should see my account balance."

User stories contain some of the same simplicity benefits that bulleted lists may have, but they provide better direction and context by connecting the feature to a role, a goal, and a reason for the feature. This provides traceability for the features in the system, so that the end product aligns with the actual needs of the customer.

The following is an example of a user story that describes logging into the system.

This user story may be accompanied by the following acceptance criteria:

Use Cases

Use cases are a detailed and systematic way of documenting requirements, often in the form of a structured narrative. They describe how a system interacts with external entities, or actors as they are often called, to achieve a specific goal. Use cases provide a step-by-step breakdown of scenarios, detailing the interactions, conditions, and outcomes. This format is beneficial for understanding the functional requirements and system behavior in different situations.

The following are standard components of a use case:

• Title: A concise name that summarizes the use case.
• Actors: The entities (users or other systems) that interact with the system. Actors can be primary (direct users) or secondary (support systems or users).
• Preconditions: Conditions that must be true before the use case can start.
• Main Flow (Basic Path): The primary sequence of steps taken by the actor to achieve the goal.
• Alternate Flows: Variations in the main flow that lead to the same goal but follow a different path.
• Exception Flows: Paths that deviate from the main flow due to errors or unexpected conditions.
• Postconditions: The state of the system after the use case has been executed.
• Triggers: Events that initiate the use case.

The following is an example of this format for the use case of a user logging into the system:

Notice that the Use Case approach has many similarities to the User Story approach for the same requirement, but it follows a different pattern that is more process-focused as opposed to the short statement from the user's point of view.

Other Requirements Specification Formats

Requirements can be documented in other ways or formats, including some that are more formal and detailed, and some that are very simple. Most companies will have a standard format that they prefer, so, as you get started at the company, you will learn their expectations.

Types of Requirements

Not all requirements are the same. Some refer to the functionality of a system, while others refer to other characteristics such as how quickly the feature must work, which are referred to as non-functional requirements.

Functional Requirements:

Functional requirements define the specific functionalities or features that a system must possess to meet the needs of its users. These requirements outline the system's capabilities, specifying how it should behave and what actions it should be able to perform. Functional requirements serve as the foundation for designing and developing the desired system functionalities.

Functional requirements may include the following areas:

• System Behaviors: The operations or tasks a system must support. These include the detailed sequences of operations that the system must follow for specific tasks. They also include data input, processing, and output.
• Data Management: The exact type of data and format that a service will accept or return as well as how it must be stored. This is particularly relevant for interfaces between systems such as API endpoints.
• External Interactions: Interfaces with other systems, including internal systems or third-party integrations.
• User Interactions: The user's connection to the system, including both user interfaces (including the design and behavior of screens, buttons, or menus) and also user roles (including the different types of users and their permissions in the system).

Non-Functional Requirements

While the functional requirements define what a system must do, the non functional requirements define how it does those things. These include areas such as performance and the environment.

• Performance Requirements: The operational aspects of a system, detailing how well it should perform under certain conditions. These requirements specify criteria such as response time, throughput, and scalability, ensuring that the system meets predefined performance standards. Performance requirements are crucial for guaranteeing the efficiency and effectiveness of the system in real-world scenarios.
• Environment Requirements: The conditions under which the system will operate. These conditions may include factors such as the operating environment, software dependencies, and external interfaces. Understanding and documenting environment requirements are essential for ensuring the compatibility and seamless integration of the system within its intended surroundings.
• Hardware Requirements: The specifications and characteristics of the physical components necessary for the system to function properly. These requirements may include details about the required processing power, memory, storage, and other hardware-related aspects. Accurate hardware requirements are critical for designing and configuring a system that can meet its performance and functionality goals.

Evaluating the quality of requirements artifacts

As you gather and document the requirements of a system, you need to ensure that they meet the following criteria:

Completeness

Does the requirement capture everything that needs to happen in that use case?

The requirement specification should cover every aspect of the desired functionality, leaving no gaps that could lead to misunderstandings during development.

Completeness in your requirements is important to ensure that all stakeholder needs are addressed and that an accurate design and plan can be created. It also helps reduce the risk of missing critical functionality later in the project.

Ambiguity (Precision)

Is the requirement sufficiently clear so that it is not misunderstood by others that will implement or test it later?

Ambiguity in requirements refers to the presence of unclear, vague, or open-to-interpretation language that can lead to different understandings among stakeholders and developers. The term, Precision, may be used to indicate the lack of ambiguity.

Eliminating ambiguity is important to ensure that everyone has a shared understanding of what must be built. It also reduces the risk of errors and rework due to misinterpretations.

The following indicate that you may have ambiguity in your requirements and should be avoided:

• Use of imprecise terms (for example, user-friendly, fast, efficient).
• Lack of specific details (for example, "the system should handle many users" instead of specifying exact numbers).
• Requirements that can be interpreted in multiple ways.

To eliminate ambiguity, consider the following:

• Use clear, concise, and specific language.
• Include examples and scenarios to illustrate requirements.
• Review requirements with stakeholders to ensure clarity.

Feasibility

Is it even possible to implement the desired behavior? Are there technical or other limitations that will prevent success?

Feasibility refers to the practicality and possibility of the requirements within the constraints of time, budget, technology, and resources available.

Feasible requirements are important to ensure that the project can be realistically completed. It helps to identify risks early in the project and to guide the prioritization of features and resources.

To help assess the feasibility of requirements consider the following:

• Conduct feasibility studies or proof-of-concept exercises.
• Involve technical experts to assess technical challenges.
• Evaluate budget and resource constraints against the project scope.

Timeline (Scope)

Is there a clear time frame or scope for the requirement to be completed? Is this timeline reasonable?

The timeline in the context of requirements refers to making sure there is a clear time frame or scope in which the requirement must be completed. It helps set realistic expectations for everyone on the team.

Meeting all criteria

If a requirement does not meet all of these criteria it will lead to major problems down the road.

As you analyze the case study in this lesson or projects at your work, if you find there are problems with the requirements, you can most likely trace the problems back to one or more of these criteria.

Continue the conversation

After completing this reading, ask 3-5 follow up questions about requirements elicitation to an AI system of your choice. (You may use ChatGPT, Bing, Claude AI, Gemini, or any other system of your choosing.)

Good questions may include:

• What are potential problems that can arise with software requirements?
• What are good ways to gather software requirements?
• How can software requirements be documented?
• What are the differences between functional and non-functional requirements?
• How can you evaluate the quality of software requirements?

Submission

After you are comfortable with these topics, return to Canvas to take the associated quiz.

Other Links:

• Return to: Week Overview | Course Home

ChatGPT assisted in the creation of this learning material.