Software Engineering I - Chapter 5

Functional Requirement

Describe the services, tasks, or functions the system is expected to perform.

Non-functional Requirements

How the system performs its functions

Input Requirements

Specify how the system should capture and handle user inputs.

Process Requirements

Describe the specific workflows, actions, and interactions that the system should perform to achieve its intended functionalities.

Data Requirements

Specify how the system should manage and store data.

Product Requirements

Specify or limit how the software behaves during execution

Organizational Requirements

Are system constraints based on company and developer’s policies or procedures, including how the system is used, what tools or languages are allowed, and the system’s required environment.

External Requirements

Come from outside influences like laws, regulations, or ethical standards, and dictate what the system must comply with to be legally and socially acceptable.

Functional Requirement

Specify what the system should do

Functional Requirement

Describe specific features, operations, and behaviors.

Non-Functional Requirement

Specify how the system performs its functions.

Non-Functional Requirement

Describe quality attributes such as performance, usability, and security.

Requirements Gathering

The process of collecting the needs and expectations of stakeholders for a new or modified product.

Interview Technique

Conducting one-on-one or group discussions with stakeholders to extract detailed information.

Structured
Semi-structured
Unstructured interviews

Types of Interview Technique

Surveys and Questionnaires

Distributing a set of predefined questions to a large audience to gather information.

Workshops

Facilitated sessions involving stakeholders to collaboratively define requirements.

Brainstorming Sessions

Group activity aimed at generating a wide range of ideas and solutions.

Focus Groups

Guided discussions with selected stakeholders to obtain feedback on specific topics.

Observation

Watching users interact with a system to identify needs and issues.

Passive (no interaction)
Active (with interaction)

Types of Observation Technique

Document Analysis

Reviewing existing documentation to extract relevant information.

Prototyping

Developing preliminary versions of a system to refine requirements through user feedback.

Use Cases and Scenarios

Creating narratives that describe how users interact with the system.

Role-Playing

Stakeholders act out interactions with the system to uncover requirements.

Joint Application Development (JAD)

Structured workshops involving stakeholders and developers to define requirements collaboratively.

Reverse Engineering

Analyzing existing systems to identify components and interrelationships.

Interface Analysis

Examining interactions between systems, users, and interfaces to identify requirements.

Software Requirement Specification

is a formal document describing the purpose and environment of software under development.  Serves as a contract between client and developer and defines what the system should do and constraints on it.

Functional Requirements
Non-Functional Requirements
Domain Requirements
Interface Requirements
Constraints

Key components of an SRS:

User Requirements

High-level, in natural language

System Requirements

Detailed, precise, often technical

Requirements elicitation

Understand stakeholders and their work

Interview
Closed Interview
Open Interview
Ethnography
Requirements Specification

Requirement Elicitation Techniques

Requirements Elicitation and Specification

Collect raw data from stakeholders and document it clearly.

Requirements Analysis

is a foundational step in software engineering that ensures a product aligns with user needs and expectations.

Verification

Ensure requirements are correctly written.

Validation

Ensure requirements reflect the actual user needs.

Requirements Management & Traceability

Maintain requirements throughout the project and ensure they are traceable to design, code, and testing.

UML Diagrams

Use case, sequence, and activity diagrams to visualize system behavior.

Prototyping Tools

Tools like Figma and Balsamiq for mockups to get early feedback.

Requirements Management Software

Tools like JIRA, IBM DOORS, ReqView, and Trello to manage and track changes.

Traceability Matrix

Ensures every requirement is mapped to design, code, and testing.

Formal Specification Methods

Use mathematical models for critical systems needing precision.

Functional Requirements

Define system behavior or functions (e.g., user login, data processing).

Non-Functional Requirements

Specify performance, usability, and security expectations.

Business Requirements

Reflect strategic goals and market needs from a business viewpoint.

Technical Requirements

Include specific technical specs like hardware, software, and integration.

Regulatory Requirements

Ensure compliance with laws, standards, and policies.

Elicitation

Gathering information from stakeholders via interviews, surveys, focus groups, or workshops.

Analysis

Identifying ambiguities, conflicts, redundancies, or gaps in gathered data.

Specification

Converting the information into a formal document of functional and non-functional requirements.

Validation

Checking if requirements are realistic, complete, and aligned with project goals.

Management

Tracking changes and maintaining traceability of requirements throughout the project lifecycle.

UML (Unified Modeling Language)

A standardized language used to specify, visualize, construct, and document artifacts of software systems, facilitating clear communication among stakeholders

Structural diagrams

Visualize the components that make up a system and the relationship between them — showing the static aspects of a system.

Behavioral diagrams

Represent what happens within a system — including how the components interact with each other and with other systems or users.

Class Diagram

Shows system classes, attributes, and relationships.

Object Diagram

Like class diagrams, they also show the relationship between objects but they use real-world examples.

Component Diagram

Describes structural relationship of components of the system.

Deployment Diagram

Shows hardware nodes and software deployment

Composite Structure Diagram

Shows the internal structure of a class and the collaborations that this structure makes possible

Package Diagram

shows the dependencies between different packages in a system

Profile Diagram

Provides a way to extend UML for particular domains or platforms (custom stereotypes, tagged values). New diagram and rare to use.

Use Case Diagram

Describes system functionalities and interactions with actors.

Sequence Diagram

Displays interactions ordered in time between objects.

Activity Diagram

Illustrates workflows and control flow with decision points.

State Diagram

Depicts the states of an object and transitions

Communication Diagram

Similar to sequence diagram but focuses on the structure of message passing between objects.

Interaction Overview Diagram

combines activity and sequence diagrams to show control flow with interaction nodes.

Timing Diagram

shows object behaviors over time with respect to time constraints and changes.

Use Cases

It tells a stylized story about how an end user interacts with the system under a specific set of circumstances.

Actor

The user or external system that interacts with the system.

Goal

The desired outcome or purpose of the interaction.

Main Flow

The typical, straightforward sequence of steps to achieve the goal.

Alternate Flows / Extensions

Variations or exceptions in the scenario

Preconditions

What must be true before the use case begins.

Post-conditions

What must be true when the use case ends.

Primary actors

They directly interact with the system to accomplish a specific task or goal.

Secondary actors

They are basically the support of the primary actors.

Data Flow Diagram

A graphical representation of how data flows through a system

External Entities (squares)

Represent sources or destinations of data outside the system, such as people, organizations, or external systems.

Process (Circles)

Indicate activities that transform input data into output, such as calculations, decision-making, or data routing.

Data Store (Open Rectangles)

Holds data and information for future use, like databases, files, repositories or forms.

Data flows (Arrows)

Show the movement of data between entities, processes, and data stores, illustrating how information flows through the system.

Logical DFD

shows only the processes and where the data flows.

Physical DFD

 includes the tools and technologies used in each process.

Level 0 Diagram (Context Diagram)

It represents the entire system as a single process and shows the interaction between the system and external entities.

Level 1 Diagram

This level decomposes the single process in the context diagram into multiple sub processes to show more detail about the internal operations.

Level 2 Diagram

Further decomposition of Level 1 processes into more detailed sub-processes, showing a finer level of detail.