SYSTEM DESIGN

SDE60US
Lesson 2

System Design SDE60US

Software Methods
1
LECTURER: Mrs. N. Uushini-Kagola
Lesson 2 Outline
2. Software Methods
2.1 Requirements gathering
2.2 functional, structural and behavioural modelling

System Design SDE60US

2.3 system design and system implementation

2
Requirements

System Design SDE60US

Gathering

3
 Introduction to Requirements
Gathering
 Requirements gathering is a critical phase in software development
where the needs and expectations of stakeholders are identified and
documented.
 It lays the foundation for successful project planning, design,
development, and implementation.

System Design SDE60US

 Effective requirements gathering ensures that the final product meets
the needs of users and stakeholders.

Stakeholders Identification:
• Identify all stakeholders involved in the project, including end-
users, clients, sponsors, developers, and testers.
4
• Understand their roles, perspectives, and expectations regarding
the software system.
Types of Requirements
 Functional Requirements: Describe what the system should do, its features,

and capabilities.
 Examples: - The system must record sales.
- Register a user
- Search and compare products
- Make payment using credit card

System Design SDE60US

- View the new emails

 Non-Functional Requirements: Specify qualities of the system such as

performance, usability, reliability, and security.

 Examples:- all the data transfer to server or vice versa must be encrypted and secure.

- all the pages must load in less than 2 second

- The system must be able to support more than 1, 000 000 users at a time

- The system must comply with the corporate design guidelines

 Business Requirements: Define the business goals and objectives that the 5
system should support.
Performance as a Non-Functional Requirement

 Define how well the system performs its functions under

specific conditions.
 They specify parameters such as response time,
throughput, latency, and resource utilization.

System Design SDE60US

 For example, a performance requirement might state
that the system must respond to user requests within
two seconds, even under peak loads.
 Performance requirements ensure that the software
system meets user expectations for speed and efficiency. 6
Usability as a Non-Functional Requirement
 It focus on the user experience and interface design
aspects of the software.
 They specify criteria such as ease of use,
intuitiveness, learnability, and user satisfaction.

System Design SDE60US

 For example, a usability requirement might specify
that the system must follow established user
interface guidelines and provide clear, concise error
messages.
 Usability requirements ensure that the software is
7
user-friendly and accessible to its intended audience.
Reliability as a Non-Functional Requirement

 Reliability requirements define the system's ability to perform its

functions consistently and dependably over time.

 They include aspects such as fault tolerance, availability, error

recovery, and data integrity.

System Design SDE60US

 For example, a reliability requirement might state that the

system should have a mean time between failures (MTBF) of

at least 1000 hours.

 Reliability requirements ensure that the software system

operates reliably in various conditions and minimizes the risk of 8

disruptions or failures.
Security as a Non-Functional Requirement:
 Security requirements address the protection of the system
and its data against unauthorized access, breaches, and
malicious activities.
 They encompass aspects such as authentication,
authorization, encryption, data privacy, and compliance with

System Design SDE60US

regulations.
• For example, a security requirement might specify that the
system must use strong encryption algorithms to protect
sensitive data during transmission and storage.
 Security requirements ensure that the software system
9
maintains the confidentiality, integrity, and availability of its
data and resources.
Requirements Elicitation Techniques
 Interviews: Conduct one-on-one or group interviews with stakeholders to
gather their requirements.
 Ask open-ended questions to gather insights and requirements.
 Document responses and analyse for common themes and
requirements.

System Design SDE60US

 Surveys and Questionnaires: Distribute surveys to collect feedback and
requirements from a large audience.
 Structured questions help in gathering quantitative data.
 Analyse survey results for patterns and trends.

 Workshops or Focus Groups: Organize collaborative sessions where

stakeholders can discuss and prioritize requirements.
10
 Facilitate discussions around specific topics or features.
 Encourage active participation and idea generation.
Requirements Elicitation Techniques
 Observation: Observe users in their natural environment to
understand their needs and workflows.
 Provides first hand insights into user behaviour and system usage.

 Prototyping: Develop early prototypes to demonstrate concepts and

gather feedback.

System Design SDE60US

 Allows stakeholders to visualize the proposed solution and provide
input for refinement.

 Document Analysis: Review existing documents such as business

requirements documents, user manuals, and reports.

 Extract relevant information related to system requirements and

11
constraints.
Exercise
Rate each of the previous techniques based on these criteria
(high, medium or low):
• Degree of participation with user

System Design SDE60US

• Information "richness" (depth)
• Breadth of information (scope)
• Cost (Analysts' Time)
• Cost (Users’ Time)
• Ability to integrate information
12
• User involvement /system design
Requirements Documentation

• Use Cases: Describe interactions between users

and the system to accomplish specific tasks.
• User Stories: Define system requirements from
the perspective of end-users in a narrative

System Design SDE60US

format.
• Requirement Specifications: Document
detailed requirements including functional and
non-functional specifications.
• Traceability Matrix: Establish traceability
between requirements, design, implementation, 13
and testing phases
 Exploring Functional,

System Design SDE60US

Structural, and Behavioural
Modelling

14
Introduction
In software engineering, modelling is a fundamental

technique used to represent different aspects of a

System Design SDE60US

system.

• Functional, structural, and behavioural modelling are

three essential approaches used to understand and

design complex systems. 15

Functional Modelling
Focuses on the functions or operations that a system
performs.
• Purpose: It helps in understanding what the system
does without delving into how it achieves those functions.

System Design SDE60US

• Techniques: Use case diagrams, functional
decomposition diagrams, and data flow diagrams are
common techniques used for functional modeling.
• Example: Use case diagrams depict the interactions
between actors (users or external systems) and the
16
system to accomplish specific goals or tasks.
Structural Modeling
Emphasizes the components or building blocks of a system
and their relationships.
• Purpose: It provides insights into the static architecture and
organization of the system.

System Design SDE60US

• Techniques: Class diagrams, object diagrams,
component diagrams, and deployment diagrams are
used for structural modeling.
• Example: Class diagrams illustrate the classes,
attributes, methods, and associations among objects in a 17
system, providing a blueprint for the implementation.
Structural Modeling: Core Elements
Terms Description Notation
Class A class is a blueprint for creating objects in
object-oriented programming (OOP)
languages.
Interface An interface defines a contract for classes
to implement. It specifies methods that
must be implemented by implementing « in te rfa c e »

System Design SDE60US

classes.
Component A component is a modular, reusable, and
replaceable part of a system that
encapsulates its behaviour and data.
Node A node represents a physical or virtual
computational resource, such as a server,
workstation, or cloud instance.
Constraint A constraint defines limitations, rules, or
conditions that govern the architecture or
18
design of a system. {constraint}
Structural Modeling: Core Relationships
Terms Description Notation
Association An association represents a relationship between
two or more classes, indicating that instances of
one class are related to instances of another class.

Aggregation Aggregation represents a "whole-part" relationship

where a part can exist independently of the whole.
It's a specialized form of association.

System Design SDE60US

Generalization Generalization represents the "is-a" relationship
between classes, where one class is a specialized
version of another class (superclass-subclass
relationship).

Dependency Dependency represents a relationship where a

change in one class may affect another class. It's a
weaker form of association compared to direct
association.

Realization Realization represents the implementation of an 19

interface by a class, indicating that the class
provides the behaviour specified by the interface.
Behavioural Modelling
Focuses on capturing the dynamic aspects of a system,
including how it behaves and responds to stimuli over time.
• Purpose: It helps in understanding the system's
interactions, state transitions, and event-driven behaviour.

System Design SDE60US

• Techniques: State machine diagrams, sequence diagrams,
activity diagrams, and interaction diagrams are commonly
used for behavioural modelling.
• Example: State machine diagrams depict the various
states that an object or system can be in and the
transitions between these states based on events or 20

actions.
System Design and
System

System Design SDE60US

Implementation

21
System Design
The process of defining the architecture, components, modules,
interfaces, and data for a system to satisfy specified requirements.
• Purpose: To translate the requirements specified in the system
requirements into a representation of the system that can be
implemented.

System Design SDE60US

Key Considerations
• Scalability: Design should accommodate growth in data, users,
and functionality.
• Reliability: System should be robust and fault-tolerant.
• Performance: Ensure efficient response times and throughput.
• Security: Protect against unauthorized access and data breaches.
22
• Maintainability: Facilitate ease of updates, fixes, and
enhancements.
System Design
1. Understanding Requirements:
 Gather and analyze requirements from stakeholders.
 Identify functional and non-functional requirements.
2. System Architecture:

System Design SDE60US

 Define the overall structure of the system.
 Choose an appropriate architectural style (e.g., monolithic,
microservices).
 Consider scalability, reliability, and maintainability.
3. Data Design:
 Design the data model and database schema. 23

 Consider data storage, retrieval, and relationships.

System Design
4. Component Design
 Break down the system into smaller components/modules.
 Define the responsibilities and interfaces of each
component.

System Design SDE60US

5. User Interface (UI) Design
 Design the user interface for optimal user experience.
 Consider usability, accessibility, and responsiveness.
6. Security Design
 Identify potential security threats.
 Implement security measures such as encryption, 24
authentication, and authorization.
System Design
7. Performance Design
 Optimize system performance.
 Consider factors like response time, throughput, and
resource utilization.
8. Integration Design

System Design SDE60US

 Plan how different components will interact.
 Define communication protocols and data formats.
9. Scalability and Extensibility
 Design the system to handle growth in data and users.
 Plan for future extensions and integrations.
10. Documentation 25
 Document the design decisions and rationale.
 Create architectural diagrams and specifications.
System Implementation
The phase where the designed system is built, integrated,
and tested.
Process:

System Design SDE60US

• Coding: Writing code according to design specifications.
• Integration: Combining individual components into a
complete system.
• Testing: Verifying that the system meets requirements
and functions correctly.
26
• Deployment: Rolling out the system for users.
System Implementation
1. Coding Standards
 Define and adhere to coding standards.
 Use consistent naming conventions and code organization.

2. Programming Language and Frameworks

System Design SDE60US

 Choose appropriate programming languages and
frameworks.
 Consider the expertise of the development team.

3. Version Control
 Use version control systems (e.g., Git) for tracking changes.
27
 Implement branching and merging strategies.
System Implementation
4. Testing
 Develop unit tests, integration tests, and system tests.
 Perform testing at various levels to ensure robustness.

System Design SDE60US

5. Code Reviews
 Conduct regular code reviews to ensure quality.
 Provide constructive feedback and address issues.

6. Continuous Integration/Continuous Deployment (CI/CD)

 Implement CI/CD pipelines for automated testing and
deployment.
28
 Ensure a streamlined and efficient development process.
System Implementation
7. Monitoring and Logging
 Integrate monitoring tools for tracking system performance.

 Implement logging to facilitate debugging and issue resolution.

8. Security Implementation

System Design SDE60US

 Implement security measures identified in the design phase.

 Regularly update and patch dependencies.

9. Documentation
 Maintain comprehensive code documentation.

 Provide user manuals and developer guides.

10. Training and Support

29
 Train users and support teams on the system.

 Provide ongoing support and address user issues.

References
Sommerville, Ian. Software Engineering. Pearson

Education Limited, 2016.

Wiegers, Karl E., and Joy Beatty. Software Requirements.

System Design SDE60US

Pearson Education, 2013.

Additional Resources:

IEEE Standard 830-1998: IEEE Recommended Practice

for Software Requirements Specifications.

30
 Thank You

System Design SDE60US

END OF LESSON 2

31