1 / 30

Requirements Engineering & System Modeling

Fundamental Concepts in Software Engineering

A comprehensive exploration of requirements elicitation, analysis, validation, and system modeling techniques using UML and modern engineering practices.

Requirements Engineering Overview

Requirements Engineering is the systematic process of establishing services that customers require from a system and the constraints under which it operates and is developed.

Definition: The process of establishing the services that a customer requires from a system and the constraints under which it operates and is developed.

System requirements are the descriptions of system services and constraints generated during the requirements engineering process.

Requirements Engineering Process Components

Elicitation

Discovering stakeholder needs and system requirements

Analysis

Understanding and organizing requirements

Validation

Checking requirements correctness and completeness

Management

Handling changes throughout development

Iterative Requirements Engineering Process

Requirements engineering is an iterative process where activities are interleaved rather than sequential, allowing for continuous refinement and adaptation.

Requirements Elicitation

The process of discovering what stakeholders need from the system through systematic investigation and communication.

Discovery

Identifying and understanding stakeholder needs and system constraints

Classification

Organizing requirements into coherent clusters and categories

Negotiation

Resolving conflicts and prioritizing requirements

Specification

Documenting requirements for the next development iteration

Requirements Elicitation Techniques

Interviewing

Formal and informal conversations with stakeholders to understand their needs and expectations

Ethnography

Observational technique to understand how people actually work in their environment

Stories & Scenarios

Real-life examples that stakeholders can relate to and provide feedback on

Prototyping

Creating early versions of the system to elicit requirements through interaction

Interviewing Techniques

Closed Interviews

  • Pre-determined list of questions
  • Structured approach
  • Consistent data collection
  • Limited exploration

Open Interviews

  • Exploratory discussions
  • Flexible questioning
  • Deep understanding
  • Unexpected insights

Best Practice: Be open-minded, avoid preconceptions, and use springboard questions to encourage discussion.

Ethnography in Requirements Engineering

Definition

A social science research method where analysts observe and analyze how people actually work in their natural environment.

Advantages

  • Reveals actual work practices
  • Uncovers tacit knowledge
  • Identifies social factors
  • No need for articulation

Limitations

  • Cannot identify new features
  • Time-intensive process
  • Limited to existing processes
  • Observer effect possible

Stories & Scenarios

Real-life examples of how a system may be used for particular tasks, providing concrete context for stakeholder discussions.

Example Scenario: Online Banking

"Sarah, a busy professional, needs to transfer money to her landlord while traveling. She opens the banking app on her phone, logs in using her fingerprint, navigates to transfers, enters the recipient details, confirms the amount, and receives immediate confirmation of the successful transaction."

Benefits

Stakeholders can relate to concrete examples and provide meaningful feedback on realistic usage patterns.

Usage

Facilitate requirements discussions and validate system concepts with end users.

Common Requirements Elicitation Problems

Unclear Stakeholder Needs

Stakeholders often don't know exactly what they want from the system

Domain-Specific Language

Stakeholders express requirements using their own specialized terminology

Conflicting Requirements

Different stakeholders may have contradictory or competing needs

Political Factors

Organizational and political influences may affect requirement specifications

Changing Requirements

Requirements evolve during analysis as understanding develops

Emerging Stakeholders

New stakeholders may be identified as the project progresses

Requirements Specification

The process of documenting user and system requirements in a structured requirements document.

User Requirements

High-level statements written in natural language for customers and end-users who lack technical background.

System Requirements

Detailed technical specifications that define what should be implemented, often part of development contracts.

Requirements may form part of a contract for system development, making completeness and precision crucial.

Requirements Specification Approaches

Natural Language

Expressive and intuitive but can lack precision and clarity

Structured Natural Language

Standard forms and templates that limit writer freedom for consistency

Graphical Notations

UML diagrams supplemented with text annotations for visual clarity

Mathematical Specifications

Formal mathematical notations that eliminate ambiguity but require expertise

Natural Language Specification Challenges

Lack of Clarity

Achieving precision without making documents difficult to read presents ongoing challenges.

Requirements Confusion

Functional and non-functional requirements often become mixed together.

Requirements Amalgamation

Multiple different requirements may be expressed as a single statement.

Ambiguous Language

Natural language inherently contains ambiguities that can lead to misinterpretation.

Form-based Specifications

Standard Template Structure

Function: Brief description of the function or entity

Description: Detailed explanation of the functionality

Inputs: Description of inputs and their sources

Outputs: Description of outputs and destinations

Action: Detailed description of the action to be taken

Pre-conditions: Conditions that must be true before execution

Post-conditions: Conditions guaranteed after execution

Side effects: Any additional effects of the function

Form-based specifications provide structure while maintaining readability for technical stakeholders.

Requirements Validation

The process of checking requirements for validity, consistency, completeness, realism, and verifiability.

Validity

Does the system provide functions that best support customer needs?

Consistency

Are there any conflicting requirements within the specification?

Completeness

Are all functions required by the customer included in the specification?

Realism

Can requirements be implemented within available budget and technology?

Requirements Validation Techniques

Requirements Reviews

Systematic manual analysis involving both client and contractor staff in formal or informal review sessions.

Test-case Generation

Developing tests for requirements to verify their testability and completeness.

Prototyping

Using executable models of the system to check requirements with stakeholders.

Automated Checking

Using tools to check consistency, completeness, and other formal properties.

Requirements Management

The process of managing changing requirements during requirements engineering and system development.

Identification

Unique identification for cross-referencing

Change Process

Formal process for assessing impact and cost

Traceability

Policies for tracking relationships

Tool Support

Automated management systems

Requirements Change Management Process

A systematic approach to analyzing, evaluating, and implementing changes to requirements throughout the development lifecycle.

System Modeling

System modeling is the process of developing abstract models of a system, with each model presenting a different view or perspective of that system.

Purpose

  • Understand system functionality
  • Communicate with customers
  • Document system design
  • Support implementation

Benefits

  • Visual representation
  • Shared understanding
  • Design validation
  • Communication tool

Four Modeling Perspectives

External Perspective

Models the context or environment of the system, showing what lies outside system boundaries.

Interaction Perspective

Models interactions between system and environment, or between system components.

Structural Perspective

Models the organization of a system or the structure of data processed by the system.

Behavioral Perspective

Models the dynamic behavior of the system and how it responds to events.

UML Diagram Types

Use Case Diagrams

Show interactions between system and its environment

Sequence Diagrams

Show interactions between actors and system components over time

Class Diagrams

Show object classes and associations between them

Activity Diagrams

Show activities involved in processes or data processing

State Diagrams

Show how system reacts to internal and external events

Context Diagrams

Show system boundaries and external dependencies

Context Models

Context models illustrate the operational context of a system, showing what lies outside the system boundaries.

Purpose: Define system scope, identify external dependencies, and establish system boundaries for stakeholder understanding.

Use Case Diagrams

Components

  • Actors: External entities that interact with the system
  • Use Cases: Discrete tasks involving external interaction
  • System Boundary: Defines scope of the system
  • Relationships: Associations between actors and use cases

Sequence Diagrams

Sequence diagrams model interactions between actors and objects within a system, showing the sequence of interactions over time.

Key Elements: Actors/objects listed horizontally, time flows vertically, interactions shown as annotated arrows between lifelines.

Class Diagrams

Purpose

Show the static structure of classes in a system and the associations between these classes.

Components

  • Class names
  • Attributes
  • Methods
  • Associations
  • Multiplicities

Behavioral Models

Models of the dynamic behavior of a system as it executes, showing responses to stimuli from the environment.

Data-Driven Models

Show sequence of actions for processing input data and generating output. Useful for business systems.

Event-Driven Models

Show how systems respond to external and internal events. Based on finite state assumptions.

State Machine Models

Model system behavior in response to stimuli, showing states as nodes and events as transitions.

Activity Models

Show the flow of control and data through system processes and activities.

Model-View-Controller (MVC) Pattern

Model

Represents application domain and business logic

View

Handles display of application state to users

Controller

Processes user interactions and coordinates between Model and View

Model-Driven Engineering (MDE)

An approach where models rather than programs are the principal outputs of the development process.

Advantages

  • Higher level of abstraction
  • Platform independence
  • Automatic code generation
  • Easier system adaptation

Challenges

  • Model complexity
  • Tool development costs
  • Translation overhead
  • Platform-specific optimization

MDE Abstraction Levels

Computation Independent Model (CIM)

Models important domain abstractions and business requirements without implementation details

Platform Independent Model (PIM)

Models system operation without reference to specific implementation platforms using UML

Platform Specific Model (PSM)

Transformations of PIM with platform-specific details for particular execution environments

Key Takeaways

Iterative Process

Requirements engineering is iterative with interleaved activities of elicitation, analysis, validation, and management

Multiple Techniques

Use diverse elicitation techniques including interviews, ethnography, and scenarios for comprehensive understanding

Systematic Validation

Validate requirements for validity, consistency, completeness, realism, and verifiability

Multiple Perspectives

System modeling requires external, interaction, structural, and behavioral perspectives

UML Integration

UML provides comprehensive notation for modeling different aspects of software systems

Design Patterns

MVC and other patterns provide proven approaches for system architecture and maintainability