SE 3140

SYSTEM DESIGN AND

MODELING

Prepared by: Dams Gabriel Fall 2021

ICT University
 CHAPTER 3:
Software Requirements

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 2

 Topics Overview
• What are Software Requirements?
• Requirements Engineering
• Eliciting Requirements
– Elicitation Work Products
• Building the Analysis Model
• Types of Requirements
– Functional Requirements
– Quality of Service (QoS) Requirements
• Requirements Imprecision
• Requirements completeness and
consistency
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 3
 Topics Overview
• Negotiating Requirements
• Validating Requirements
• Objectives of Software
Requirements Specification (SRS)

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 4

 What are Software Requirements?
• Software Requirements
– Functionality that system must provide for users
– What the system must do, but now how (design)

• Requirements are captured in a different

ways.

• Requirements Analysis and Specification

– Identify sources for requirements
– Analyze requirements
– Specify system to satisfy software
requirements
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 5
 Requirements Engineering
• The requirements are broken down into
different phases.
• Inception – ask a set of questions that
establish …
– basic understanding of the problem
– the people who want a solution
– the nature of the solution that is desired, and
– the effectiveness of preliminary communication
and collaboration between the customer and the
developer

• Elicitation – elicit requirements from all

stakeholders
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 6
 Requirements Engineering
• Elaboration – create an analysis model
that identifies data, function and
behavioral requirements

• Negotiation – agree on a deliverable

system that is realistic for developers
and customers

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 7

 Requirements Engineering
• Specification – can be any one (or more)
of the following:
–A written document
–A set of models
–A formal mathematical
–A collection of user scenarios (use-cases)
–A prototype

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 8

 Requirements Engineering
• Validation – a review mechanism that
looks for
– errors in content or interpretation
– areas where clarification may be required
– missing information
– inconsistencies (a major problem when large
products or systems are engineered)
– conflicting or unrealistic (unachievable)
requirements.

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 9

 Inception
• Identify stakeholders
– “who else do you think I should talk to?”

• Recognize multiple points of view

• Work toward collaboration
• The first questions
– Who is behind the request for this work?
– Who will use the solution?
– What will be the economic benefit of a successful
solution
– Is there another source for the solution that you
need?
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 10
 Eliciting Requirements
• Meetings are conducted and attended by
both software engineers and customers

• A "definition mechanism" (can be work

sheets, flip charts, or wall stickers or an
electronic bulletin board, chat room or
virtual forum) is used the goal is
– to identify the problem
– propose elements of the solution
– negotiate different approaches, and
– specify a preliminary set of solution requirements

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 11

 Elicitation Work Products
• A statement of need and feasibility.

• A bounded statement of scope for the

system or product.

• A list of customers, users, and other

stakeholders who participated in
requirements elicitation

• A description of the system’s technical

environment.
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 12
 Elicitation Work Products
• A list of requirements (preferably
organized by function) and the domain
constraints that apply to each.

• A set of usage scenarios that provide

insight into the use of the system or
product under different operating
conditions.

• Any prototypes developed to better define

requirements.
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 13
 User Interviews
• Typical interview questions
– What is your role? In company? In current
system?
– How do you use current system?
– What are the advantages, limitations of
current system?
– What requirements should new system
provide?

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 14

 Building the Analysis Model
• Elements of the analysis model
– Scenario-based elements
• Functional—processing narratives for software
functions
• Use-case—descriptions of the interaction between an
“actor” and the system

– Class-based elements
• Capture structure of things in the problem domain

– Behavioral elements
• Capture problem domain behavior
– Sequence and state diagrams

– Flow-oriented elements
• Data flow diagram
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 15
 Functional Requirements
• A functional requirement is something
the system must do

• A functional requirement is testable

• As a general rule, these are documented

as a series of “shall” statements
– F1: The system shall display the heart rate of
a patient connected to the patient monitor.
– F2: The system shall display the blood
pressure of a patient connected to the
patient monitor.
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 16
 Functional Requirements
• Statements should focus only on a single
thing (try to avoid compound sentences)
– Each requirement should be individually
testable

• Requirements must be traced to analysis

and design artifacts
– Typically a many-to-many relationship
between requirements, use cases, classes,
etc.
– Each functional requirement should have a
unique ID
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 17
 Functional Requirements
• Should not be a design choice (this is hard to
avoid). E.g.
– The system shall store user information including
name, DOB, address and SSN. <-- Good!
– The system shall store user information in an Oracle
database including name, DOB, address, SSN. <-- bad
• Is Oracle really REQUIRED? Hard to say… maybe, but
probably not. This is a decision you would make at
implementation design time.
• Question: Does the customer care that you use Oracle?
MySQL? Etc.. Maybe someone found some other MUCH
BETTER approach of storing the data.

• Note: Be very aware of when you are making design choices

instead of required features.
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 18
 Quality of Service (QoS) Requirements
• QoS – often referred to as “non-
functional” requirements

• Documents how the system should do

something

• Place restrictions on the product being

developed, the development process, and
specify external constraints that the
product must meet.

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 19

 Quality of Service (QoS) Requirements
• Example:
– P1: Display of the patient's vital signs shall
respond to a change in the patient's status
within 2 seconds.

• Often relate to software ‘ilities’

– Performance
– Scalability
– Availability
– Reliability
– Maintainability
– Security
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 20
 (Bad) Examples
• The system shall validate and accept
credit cards and cashier’s checks.
– Problem: two requirements instead of one.

– If the credit card processing works, but the

cashier’s check validation does not… is this
requirement pass or fail? Has to be fail, but
that is misleading.

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 21

 (Bad) Examples
• The system shall process all mouse clicks
very fast to ensure user’s do not have to
wait.
– Problem: This is not testable. Quantify how fast
is acceptable?

• The user must have Adobe Acrobat

installed.
– Problem: This is not something our system must
do. It could be in the constraints/assumptions or
maybe operating environment sections, but is not
a functional requirement of our system
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 22
 Requirements imprecision
• Problems arise when requirements are not
precisely stated.

• Ambiguous requirements may be interpreted

in different ways by developers and users.

• Consider using the term ‘appropriate

viewers’
– User intention (request) - special purpose viewer
for each different document type
– Developer interpretation - Provide a text viewer
that shows the contents of the document
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 23
 Requirements completeness and consistency
• In principle requirements should be both
complete and consistent
– Complete
• They should include descriptions of all facilities
required
– Consistent
• There should be no conflicts or contradictions in
the descriptions of the system facilities

• In practice, it is very difficult or

impossible to produce a complete and
consistent requirements document
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 24
 Negotiating Requirements
• Identify the key stakeholders
– These are the people who will be involved in
the negotiation

• Determine each of the stakeholders “win

conditions”
– Win conditions are not always obvious

• Negotiate
– Work toward a set of requirements that lead
to “win-win”

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 25

 Validating Requirements
• Is each requirement consistent with the
overall objective for the system/product?
• Have all requirements been specified at the
proper level of abstraction? That is, do
some requirements provide a level of
technical detail that is inappropriate at
this stage?
• Is the requirement really necessary or does
it represent an add-on feature that may
not be essential to the objective of the
system?
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 26
 Validating Requirements
• Is each requirement bounded and
unambiguous?

• Does each requirement have attribution?

That is, is a source (generally, a specific
individual) noted for each requirement?

• Do any requirements conflict with other

requirements?

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 27

 Validating Requirements
• Is each requirement achievable in the
technical environment that will house the
system or product?

• Is each requirement testable, once

implemented?

• Does the requirements model properly

reflect the information, function and
behavior of the system to be built.

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 28

 Validating Requirements
• Has the requirements model been
“partitioned” in a way that exposes
progressively more detailed information
about the system.

• Have requirements patterns been used to

simplify the requirements model. Have all
patterns been properly validated? Are all
patterns consistent with customer
requirements?

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 29

 Objectives of Software Requirements
Specification (SRS)
• SRS is a standard document for capturing
detailed software requirements.

• Communication vehicle among multiple

audiences
– Customers
– Users
– Analysts
– Designers

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 30

 Objectives of Software Requirements
Specification (SRS)
• Basis for Software Design
– Provide precise statement of requirements to
designers

• Basis for Software Validation

– Basis for software acceptance criteria

• Basis for controlling evolution of system

– Changes to existing requirements
– Addition of new requirements
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 31
 Contents of anSRS
• System Overview
• Interface requirements
– Users, systems, devices, …

• Constraints, dependencies, and assumptions

• Functional Requirements
– Functions to be performed by software system
– Inputs / outputs

• Quality of Service (QoS) Requirements

– Often termed “non-functional” requirements
– Performance, security, etc.
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 32
 Contents of anSRS
• Contractual style of Requirements
Specification
– The system shall …. (mandatory requirement)
– The system will/may … (optional feature)

• Use case modeling style of Requirements

Specification
– Functionality described by use cases
– Actors represent external users or entities

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 33

 Q&A

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 3: Slide 34