Class Notes (1,000,000)
CA (620,000)
UTSG (50,000)
CSC (1,000)
Lecture 8

CSC302H1 Lecture 8: 2014.01.30

Computer Science
Course Code
Matt Medland

This preview shows half of the first page. to view the full 2 pages of the document.
Software Quality = tness for its purpose
oSoftware is designed for a purpose
Requirements analysis needed to identify this purpose
Misunderstood purpose = poor quality software
oPurpose found in human activities
The purpose is often complex
Many dierent kinds of people and activites
Sometimes con!icting interests among them
Ex. purpose of banking systems comes from business
activites of banks and needs of their customers
Software Design process
oHard system view
Software problems can be decomposed systematically
Requirements can be represented formally in a
Specication can be validated to ensure its
Correct program = satises this specication
oSoft system view
Software dev embedded in complex organizational
Multiple stakeholders w/ dierent values and
Software design part of ongoing learning process by
Requirements can't be adequately captured in a
Participation of users during development =
oProblem & Solution
Separate the problem from the solution
Can be discussed w/ stakeholders
Can be used to evaluate design choices
Goode source of test cases
Problem Situation = in the real world
Validation checks if the implemented system
solves the real world problem
Problem Statement = formalized problem situation,
corresponds to the needs of the stake holders
Vercation checks if the implemented system is
correct w.r.t problem statement
Software Requirements & Specication
oApplication Domain – things the software cannot
observe directly
These are assumptions or truths
Domain Properties (D) – things in application
domain that are true
Whether or not we ever build the proposed
System Requirements (R) – things in the application
domain that we wish to be made true, by delivering
the porposed system
The things that solve the problem
oShared Phenomena – connects Application Domain to
Software Domain
ex. sensors, detectors, buttons
oSoftware Domain – things private to the software
oSoftware Speci%cation (S) – a description of the
behavior that the program must have, in order to meet the
requirement R
Can only be written in terms of shared phenomena
oProgram (P) – is the program that satises S
oCorrectness Criteria (Veri%cation)
1. The Program running on a particular Computer
satises the Specication
2. The Specication, in the context of the given
Domain Properties, satises the Requirement
oAppropriateness Criteria (Validation)
1. We discovered all important Requirements
2. We properly understood the relevant Domain
oIn general: S (given D)  R
oEx1. Aircraft reverse thrust system
Requirement R:
Reverse thrust shall only be enabled when the
aircraft is moving on the runway
Domain Properties D
Wheel Pulse is on i wheel is turning
Wheels turning i aircraft is moving on runway
Specication S:
Reverse thrust enabled i Wheel Pulse is on
Verication: S and D true  R is meet
Domain assumption wrong  Wheels turn during
oEx2. Database security system
Requirement R:
Database shall only be accessible by authorized
Domain Properties D:
Authorized personnel have passwords
Passowrds are never shared w/ non-authorized
Specication S:
Access to the database shall only be granted
after the user types an authorized password
Verication: S and D true  R is meet
Domain assumption wrong  passwords can be
oEx3. Elevator control system
Can move things from the application domain into the
shared pheonoma to help w/ specication
Add sensors to detect when people are waiting
Add sensors to detect when people are in the
Analysis is not necessarily a sequential process
Don't have to write the Problem Statement
before the Solution Statement
Problem statement will be imperfect
You're Reading a Preview

Unlock to view full version