OOAD: Requirements

Presenter: Dr. Ha Viet Uyen Synh.

Part A

GENERAL SYSTEM THEORY

System’s Concept
Def. A system is a set of components that interact with
other ones and serve for a common purpose or goal.

Systems may be: (1) abstract or (2) physical

• An abstract system is conceptual, a product of a
human mind. That is, it cannot be seen or pointed to as
an existing entity. However, they do exist and can be
discussed, studied and analyzed.
• A physical system, in contrast, has a material nature.
It is based on material basis rather than on ideas or
theoretical notions.
Example _ an abstract system
Example _ a physical system

SCADA System
Nine System’s Characteristics
“Systems” Thinking
Identify something as a system

Involves being able to identify subsystems

Identify system characteristics and functions

Identify where the boundaries are (or should be)

Identify inputs and outputs to systems

Identify relationships among subsystems

7
Information Systems
Def. An Information System (IS) is a collection of
interrelated components that collect, process, store, and
provide as output the information needed to complete a
business task.

Example: A payroll system collects information on

employees and their work, processes and stores that
information, and than produces paychecks and payroll
reports for the organization. Then information is
provided to manufacturing so the department can
schedule production.

8
Types of Information Systems

9
Hierarchy of Information Systems
Hierarchy: System, Subsystem, Supersystem
Ex: customer support system: order entry subsystem, order fulfillment
subsystem, shipping and back order subsystem, product catalog
maintenance, etc.

Supersystem – a larger system that includes the system. The system

is a subsystem of the larger supersystem
Ex: production system includes other systems, such as inventory
management and manufacturing and customer support system.

10
System Boundary vs. Automation
Boundary
System boundary: separates system from other
systems and from its environment

Automation boundary - separates the automated part

of the IS (where work is done by computers) from the
manual part (where work is done by the people).

11
Example _ System Boundary
Example _ Automation Boundary
Part B

REQUIREMENT ANALYSIS
Conceptual Model for SW Architectures
Requirements Analysis
Traditional SE suggests requirements analysis should
remain unsullied by any consideration for a design

However, without reference to existing architectures it

becomes difficult to assess practicality, schedules, or
costs

In engineering, new products come from the observation

of existing solution and their limitations

17
New Perspective on Requirements
Analysis
Existing designs and architectures provide the solution
vocabulary

Our understanding of what works now, and how it works,

affects our wants and perceived needs

The insights from our experiences with existing systems

helps us imagine what might work and enables us to
assess development time and costs

→ Requirements analysis and consideration of design

must be pursued at the same time

18
Software Architecture’s Elements
A software system’s architecture typically is not (and
should not be) a uniform monolith

A software system’s architecture should be a

composition and interplay of different elements:
Processing
Data, also referred as information or state
Interaction
Deployment
• A software system cannot fulfill its purpose
until it is deployed
• Executable modules are physically placed on the
hardware devices on which they are supposed to
run

• The deployment view of an architecture can

be critical in assessing whether the system
will be able to satisfy its requirements

• Possible assessment dimensions

• Available memory
• Power consumption
• Required network bandwidth
Components
Elements that encapsulate processing and data in a
system’s architecture are referred to as software
components

Definition
A software component is an architectural entity that
encapsulates a subset of the system’s functionality and/or data
restricts access to that subset via an explicitly defined interface
has explicitly defined dependencies on its required execution
context

Components typically provide application-specific

services
Connectors
In complex systems interaction may become more
important and challenging than the functionality of the
individual components

Definition
A software connector is an architectural building block
tasked with effecting and regulating interactions among
components

In many software systems connectors are usually simple

procedure calls or shared data accesses

Connectors typically provide application-independent

interaction facilities
Some types of Connectors
Procedure call connectors

Shared memory connectors

Message passing connectors

Streaming connectors

Distribution connectors

Wrapper/adaptor connectors

23
Configurations
Components and connectors are composed in a specific
way in a given system’s architecture to accomplish that
system’s objective

Definition
An architectural configuration, or topology, is a set of
specific associations between the components and
connectors of a software system’s architecture
Example for Context Diagram
Small
Individuals Businesses

Users
act as act as

Buyers Sellers
buy items from the

sell and ship items to the

Accountants

buy sell
items items
in the in the
perform
accounting duties
Security using the
Employees Officers
Global
handle sends
Personal
security violations information
Marketplace
of the to the
(GPM)
provide
User Support
user support
work for Agents authorizes
for the
credit card
transactions
via the

Global
Personal
Marketing Authorization
Corp. Processor
Gateway
Deployment Diagram
Network Architecture Diagram
What’s the difference between software that
works and software that works well?
Example
You’ve been hired to build an online store

You’ve gone ahead and applied the feature/use case-driven

approach to design

You’ve done that process of identifying the use cases,

planning and estimating them with user stories, and
thinking about how you can write those stories as tests

Looking back at what you’ve done, you’ve acceptance

tested the use cases, integration tested the infrastructure
code that interacts with external APIs and the outside
world, and even did a little bit of end-to-end testing to
ensure things work from front to back.

Has everything been OK?

Example _ Complaints from
customers.
• “The cart page takes around 10 seconds to load — it’s way too
slow! If it’s already this slow under regular traffic, I’m not sure
what’s going to happen when we have our boxing day sale. Will
the site just go down completely?”

• “We keep having to refund orders! Customers are purchasing

products that are out of stock, so I’m not sure how you did the
sync to our backend inventory but it’s either taking too long to
sync or it’s not syncing at all.”

• “The site looks weird on mobile.”

• “Customers are confused about how to get to the page where

they can see the status of their orders.”

• “The animations moving between pages feels kind of choppy. I

was expecting it to be smoother. Can you fix that?”

Where did we go wrong?

What is a non-functional requirement?
Where functional requirements describe what the system should do
(ie: the use cases or features), non-functional requirements
(sometimes called constraints or behavioral requirements) describe
what the system should be (ie: the system level properties).
Types of non-functional requirements

Capacity

Localization Regulatory

Performance Portability

Reliability
Example
• Scalability, performance, efficiency: “The website
should process each request within 4 seconds or less
99% of the time.”

• Scalability, performance: “In standard network

conditions, the website should fully load in less than
5 seconds when the total number of simultaneous
users on the website are greater than 50,000.”

• Security, data integrity, capacity: “Every unauthorized

request to a resource must be logged and stored for
audit over the next 5 years.”
Functional vs. non-functional requirements
Non-functional requirement
Functional

Constrains the functional

Describes what the
Description requirements and describes
system should do
“how the system should be”
No, but some are more
Mandatory Yes
important than others
As a use case / feature - As a system-level property
Scope
component level against the system as a whole
More difficult (it can be
difficult to make qualitative
Ease of
Straightforward properties quantitative — we
definition
sometimes have to use
indicators instead).
Unit, integration,
Performance, stress, security,
Test types acceptance, end-to-end
usability testing (for example)
tests
Given a user has not (1) The site should be able to
created an account, when process 99.9% of requests in
they register, a new users less than 6 seconds. (2)
Example
should be created and an Emails should be sent no later
email should be sent to than 20 minutes after the
them. triggering event.
Why should we learn about non-
functional requirements
• It’s one of the main reasons why projects fail

• It has a massive influence on architecture (execution

qualities)

• Makes good design techniques necessary (evolution

qualities)
Best practices for dealing with
non-functional requirements

• Uncover non-functional requirements early

• Make requirements as measurable as possible

• Use popular products as a quality baseline

Exercise #1
Are these procedures written for system boundary or
automation boundary?
Exercise #2
Exercise #3
Given the following list of requirements of a sales system:

The system should do

1. Be accessible to Web users.
2. Include the company standard logo and color scheme.
3. Restrict access to profitability information.
4. Include actual and budgeted cost information
5. Provide management reports
6. Include sales information that is updated at least daily.
7. Have two-second maximum response time for predefined queries
and ten-minute maximum response time for ad-hoc queries.
8. Include information from all company subsidiaries
9. Print subsidiary reports in the primary language of the subsidiary
10. Provide monthly rankings of salesperson performance

Questions:
1. Which requirements are functional business requirements?
2. Which requirements are non-functional business requirements?
3. What kinds of non-functional requirements are they? Provide two
additional examples.
Any Questions?