SD - C5

Chapter 5 – Understanding Requirements

Overview of Requirements Engineering

  • Requirements engineering aids software engineers in comprehensively understanding the problems they aim to address.

  • Building a technically elegant solution that disregards customer needs serves no purpose; understanding customer requirements is crucial before design or development.

  • The requirements engineering process includes:

    • Inception: Initial gathering of stakeholders and understanding basic problems.

    • Elicitation: Identifying detailed customer needs and uses.

    • Negotiation: Sorting and prioritizing requirements to reach a consensus.

    • Specification: Documenting the requirements precisely.

    • Validation: Reviewing specifications to ensure quality and adherence to standards.

  • The primary goal of requirements engineering is to create a clear, documented understanding of the customer's issues.

  • Various communication tools may be employed to convey this understanding, including user scenarios, function and feature lists, analysis models, or specifications.

Adaptability and Continuity in Requirements Engineering

  • Requirements engineering must be tailored to the specific context, project, product, and people involved.

  • The process begins during the communication phase of software engineering and extends into modeling.

  • Although it can be abbreviated, requirements engineering cannot be omitted.

  • It is critical for the software development team to grasp the problem requirements before attempting to implement solutions.

Requirements Engineering Tasks

  1. Inception

    • Software engineers utilize context-free questions to grasp basic knowledge about the problem, stakeholders, desired solutions, and effectiveness of collaboration between developers and customers.

  2. Elicitation

    • Gathering information from the customer regarding product objectives, business integration, and daily usage of the product.

  3. Elaboration

    • Developing a detailed technical model outlining software functions, behaviors, and information structures.

  4. Negotiation

    • Categorizing and organizing requirements into subsets, identifying relationships, reviewing for correctness, and prioritizing based on customer needs.

  5. Specification

    • Producing written work products that describe the functionality, performance, and constraints of the intended software system.

  6. Requirements Validation

    • Conducting technical reviews to evaluate specification work products for quality and adherence to agreed standards.

  7. Requirements Management

    • Implementing activities to assist teams in recognizing, managing, and tracking requirements and modifications throughout a project, akin to software configuration management (SCM) methods.

Initiating the Requirements Engineering Process

  • Identification of Stakeholders: Recognize individuals or groups with interests in the project.

  • Understanding Diverse Stakeholder Perspectives: Acknowledge the variety of viewpoints among stakeholders and work towards collaboration.

Context-Free Questions for Requirement Identification

  • Address questions such as:

    • Who is initiating the work requests?

    • Who will be the end-users of the solution?

    • What economic benefits can emerge from a successful solution?

    • Are alternative solutions available?

Additional Context-Free Questions for Problem Understanding

  • Formulate inquiries to better grasp:

    • Characteristics of outputs from successful solutions.

    • Problems that the solution aims to address.

    • Description of the business environment where the solution will be applied.

    • Any performance constraints that may impact the approach to the solution.

Communication Effectiveness Questions

  • Engage stakeholders with questions like:

    • Am I the best person to provide official answers?

    • Are my questions relevant to the problem at hand?

    • Are there others who can offer more information?

    • Am I asking an overwhelming number of questions?

    • Should I be asking different questions altogether?

Goals of Requirements Gathering

  • Identify the core problem, propose solution components, negotiate on approaches, and establish a preliminary set of solution requirements.

Collaborative Requirements Gathering Guidelines

  • Conditions for meetings should include:

    • Attendance by both developers and customers.

    • Established rules regarding preparation and participation.

    • A flexible agenda.

    • A facilitator guiding the meeting.

    • Mechanisms (stickers, sheets, electronic boards) to measure group consensus.

Quality Function Deployment (QFD)

  • A quality management technique aimed at converting customer requirements into technical software specifications through a customer voice table.

  • Identifies three types of requirements:

    • Normal

    • Expected

    • Exciting

  • QFD uses:

    • Function Deployment: Assesses the importance/value of each function needed for the system within customer meetings.

    • Information Deployment: Links required data objects and system events to functions.

    • Task Deployment: Reviews the system's behavior considering the environmental context.

    • Value Analysis: Determines the relative priority of requirements from the deployment activities.

Elicitation Work Products

  • Essential outputs of the elicitation process include:

    • A bounded statement outlining the system's scope.

    • A list of stakeholders engaged in requirements gathering.

    • Description of the technical environment surrounding the system.

    • An organized list of requirements by function and domain constraints.

    • Usage scenarios (use cases) that provide insights into the operational aspects of the deployed system.

    • Prototypes created to enhance the understanding of requirements.

Elicitation Problems

  • Common challenges faced during elicitation encompass:

    • Understanding Issues: Customers may be unclear about their needs or unable to communicate them effectively.

    • Volatility: Requirements can evolve over time, complicating stability.

    • Scope Definition: Boundaries of the system may be poorly defined.

Developing Use-Cases

  • Use cases narrate stylized stories of user interactions with the system under specific circumstances. Key steps include:

    • Identification of Actors: Recognize primary (interacting directly with the system) and secondary (supporting roles) actors.

    • Objectives of actors: Outline the goals for each actor involved.

    • Establish preconditions for the use case to begin.

    • Define the main tasks performed by actors and consider possible exceptions.

    • Assess variations in interactions by actors.

    • Determine the information involved with the system that actors acquire, produce, or modify.

    • Ascertain if actors need to report changes in the external environment to the system.

    • Identify information that actors seek from the system.

    • Assess if actors need notifications about unexpected changes.

Use-Case Template

  • A comprehensive use case template includes:

    • Use Case Name

    • Primary actor

    • Goal in context

    • Preconditions

    • Trigger

    • Scenario details

    • Exception handling

    • Priority

    • Availability

    • Frequency of use

    • Communication channels to primary actors

    • Secondary actors

    • Channels to secondary actors

    • Open issues

Analysis Model Intent

  • The purpose is to provide detailed descriptions of the necessary information, functionality, and behavior for computer-based systems through:

    • Scenario-based Elements: Depict system functionality from user perspectives using use cases.

    • Class-based Elements: Illustrate relationships between objects manipulated by actors, showing their attributes as classes.

    • Behavioral Elements: Represent system and class behavior through states and transitions between states.

    • Flow-oriented Elements: Show how information is processed and transformed through system functions.

Analysis Patterns

  • Speed up the development of abstract models by utilizing reusable analysis strategies with associated pros and cons.

  • Assist in moving from analysis models to design models by proposing applicable design patterns and dependable solutions for frequent patterns.

  • Suggest reusable solutions (classes, functions, or behaviors) for future application modeling.

Negotiating Requirements

  • The aim is to formulate a project plan that satisfies stakeholder needs and adheres to real-world limitations including time, personnel, and budget. Negotiation activities may involve:

    • Identifying key stakeholders involved in the system.

    • Clarifying stakeholders’ “win conditions.”

    • Reaching agreements that merge various stakeholders’ win conditions into a collective, favorable outcome for all parties, including developers.

Requirement Review (Validation)

  • Assess each requirement by checking the following:

    • Is it consistent with the overall project or system objectives?

    • Are they adequately specified in terms of abstraction level?

    • Is each requirement critical to system objectives, or is it merely an auxiliary feature?

    • Are requirements clearly defined and unambiguous?

    • Are the sources for each requirement known?

    • Do any requirements conflict with each other?

    • Are requirements feasible within the technical environment intended for the system?

    • Are all requirements testable post-implementation?

    • Does the requirements model accurately mirror the information, functionality, and behaviors intended for the system?

    • Is the requirements model partitioned to reveal additional details progressively?

    • Have all requirements been validated and deemed consistent with customer expectations?