Software Engineering Chapter 4

Software Engineering - Chapter 4

• Requirements Engineering is a crucial part of software development, with 37% of problems stemming from poor requirements.
• Requirements analysis is the phase of understanding who uses the system, what it does, and where it operates.
• Key deliverables are combined into a system proposal to determine if the project continues.
• The analysis phase includes classifying requirements: business, user, functional, and nonfunctional.
• The "As-Is" system represents the present system, which might or might not be computerized.
• The "To-Be" system is the new system that fulfills updated requirements.
• The System Proposal is the critical output from the analysis phase.
• Analysis refers to breaking down complex systems into their parts for understanding.
• The planning phase outputs are necessary inputs for the analysis phase.
• The goal in analysis is to fully grasp the new system's requirements.
• Understanding the "As-Is" system, identifying improvements, and defining the "To-Be" system are crucial.
• Business Process Automation (BPA), Business Process Improvement (BPI), and Business Process Reengineering (BPR) are used to discover user needs for the new system.
• The final analysis phase output is the software/system proposal.
• This proposal is presented as a walk-through to the approval committee for detailed explanation.
• The analysis phase's deliverables are the initial step in designing the new software/system.
• Recognizing that a customer's problem statement isn't the same as requirements is vital.
• Requirements engineering transforms high-level business requests into detailed specifications of the desired software/system functionality.
• Two key questions to ask are: "How can we identify the purpose of the system?" (i.e., features and constraints) and, "What is inside/outside the system?".
• Requirements elicitation (gathering) defines system needs, how it works in a day-to-day basis, and its role in the business.
• Requirements analysis clarifies the system's functions and specifications for the developers.
• Requirements specification formalizes the system's requirements for better clarity and consistency among stakeholders and developers.
• Requirements validation guarantees the system fulfills the needed requirements.
• Requirements are described through functional and non-functional descriptions.
• Functional requirements focus on what the system should do.
• Non-functional requirements focus on how the system should work (e.g., performance, security).
• Agile development often avoids detailed requirements, relying more on user stories and an iterative approach.
• User requirements detail tasks users must do within a system.
• Requirements should be complete and consistent, but this is typically challenging in reality.
• The analysis phase should consider business and IT perspectives, and stakeholders' needs.

Learning Objectives

• Explain the analysis phase of the Software Development Lifecycle (SDLC).
• Describe the elements of a requirements definition statement.
• Categorize requirements as business, user, functional, or non-functional.
• Understand how requirements elicitation mechanisms work.
• Define the function of each requirement elicitation technique.
• Demonstrate understanding of requirements specification and validation.

Key Definitions

• As-Is System: The current system (may or may not be computerized).
• To-Be System: The new system based on updated requirements.
• System Proposal: The main deliverable from the analysis phase.

Types of Requirements

• Functional Requirements: What the system should do.
• Non-functional Requirements: How the system should perform (e.g., performance, security).
• Business Requirements: The business needs.
• User Requirements: The needs of the user.

Information Collection Activities

• Business description and operational details (current situation).
• System environment and context.
• Existing business processes.
• Problems with the current system.
• Business or product goals.
• Users of the current and future systems.
• Customer and user priorities and needs.
• Any considerations of quality, performance, or security.

User Requirements Example

• Scheduling appointments, placing orders, re-ordering inventory, determining credit availability, and looking up account balances are typical scenarios.

Functional and Non-Functional Requirements

• Functional Requirements: Statements that define how a system serves users (e.g., input, output, behaviour).
• Non-functional Requirements: Requirements related to constraints, standards, timing, or the development process.
• Domain requirements stem from application specifics (e.g., implementation language).

Functional Requirements Examples

• User authentication, search functionality, recording and storing customer orders, generating and sending email notifications, user permissions, inventory management, and processing payments.

Requirements as User Stories

• User Stories are requirements expressed as end-user goals.
• They are expressed from the end-user's perspective emphasizing a specific user goal or action.

Requirements Imprecision

• Problems arise when functional requirements are not clearly stated, leading to ambiguity.
• Stakeholders may express requirements in their own terms.
• Conflicting requirements among stakeholders are also a problem.

Requirements Completeness and Consistency

• Requirements should fully cover all needed system features and be free from conflicts or contradictions for practicality.

Non-Functional Requirements

• These are constraints on the services offered, the development process, standards, etc. Example include performance(speed, capacity, reliability, availability), security(access constraints, safeguards) operational(physical and technical details), cultural/political requirements.

Metrics for Non-Functional Requirements

• Metrics define how to quantify and measure non-functional requirements (e.g., speed, size).

More on Non-Functional Requirements

• Operational details specify the hardware/software environments.
• Performance specifies system speed, capacity, and reliability.
• Security addresses access and safeguards.
• Specific cultural or political requirements are considered.

Process Activities

• Requirements are elicited and discovered from stakeholders.
• Requirements are organized, classified, prioritized, and negotiated.
• Requirements are formally specified.

Requirements Engineering Processes

• These processes widely vary depending on the application, domain, and the team/organization involved.
• However, they include generic activities common to all projects.
• Interleaved activities involve elicitation, analysis, specification, and validation.

The Process of Determining Requirements

• Both business and IT perspectives are key in determining requirements during the analysis phase.
• The best approach brings business, software engineering/analysis experts together.
• The team should elicit requirements from stakeholders with consideration for requirements evolution.

Requirements elicitation and analysis

• Stakeholder requirements are elicited and analyzed, covering maintainance, maintenance
• Methods help discover and document stakeholder requirements. Domain experts, users, managers, and engineers are potentially involved.

Problems in Requirements Elicitation

• Stakeholders may not precisely know what they need or understand limitations.
• People communicate in different ways.
• Conflicts and political influences may appear and change over time.
• Requirements frequently change during the process, and new stakeholders can emerge.

Stages in Requirements Elicitation

• Requirements discovery, organization, prioritization, negotiation, and specification.

Requirements Definition Report

• A document, report, or statement listing requirements in an outline.