FIT3SQA – Software Quality Assurance

Lecture 3

Software Quality Assurance

+ Software Quality Assurance

+ Capturing Software Requirements

Faculty of Information Technology

Hanoi University
Part 1

SOFTWARE QUALITY ASSURANCE

 Elements of SQA (1)
• Standards (IEEE, ISO…)
– A standard contains concepts, definitions and brief
guidelines for SQA.
• Reviews & Audits
– Review: assessment of the work product's quality at
any given stage.
– Audit: check if a suitable process is followed at any
given stage to increase the likelihood of success.
• Testing
• Error/defect collection & analysis
 Elements of SQA (2)
• Change management
– How to respond to changes.
• Education
– Teaching software engineers and stakeholders.
• Vendor management
– How to utilize 3 types of external sources:
• Packaged software (e.g. MISA, MS Outlook,…)
• Tailored software (e.g. Customized Magento Website)
• Custom-designed software: built based on customer
requirements, from scratch
 Elements of SQA (3)
• Security management
– Make sure developed software does not contain bugs that
allow cyber criminals to steal user's data or take control of
user's device.
• Safety
– Make sure user inputs never lead to dangerous situations
(e.g. user accidentally deletes all data?).
– Make sure the software remains correctly operational in all
situations.
• Risk management
– Misunderstanding of requirements, underestimated costs,
employee leaving, sudden change of requirements, etc.
SQA General Process
 SQA Tasks
• Prepare an SQA plan for a project
• Participate in the development of the
software process (with project manager)
• Verify that project activities follow the defined
software process.
• Record and report deviations from software
process and non-compliant work products.
• Assist in change management.
• Collect & analyze software metrics.
 SQA Goals & Metrics
• Requirements quality
– By reviewing requirements.
• Design quality
– By reviewing software designs.
• Code quality
– By planning and monitoring testing.
• Effectiveness of quality control
– Ensure that every activity achieve the best result
for the least cost.
(*) See Pressman (2019), Table 17.1 for a table of attributes
which help to measure each goal's level of success.
 Formal Approaches to SQA
• A small segment of software engineering
community.
• Computer programs are considered
mathematical objects.
• The use of proofs to ensure program
correctness → program quality.
• Suitable for algorithm-heavy programs.
 Statistical SQA
Suitable to large software companies
1. Errors and defects are collected and categorized.
2. Find the underlying causes of errors/defects.
3. Use the Pareto principle (80% of defects can be
traced to 20% of all possible causes), isolate the
20%.
4. Once the 20% causes are identified, make changes
to the processes correct them.
This requires collecting a large amount of errors/defects.
 Software Metric: Reliability

• Definition: The probability of failure-free

operation of a computer program in a
specified environment for a specified time
(Musa et. al., 1987).
• Mean time between failures (MTBF) (1):

– In short: it is the average time that users have to

wait per software failure.
• Do slow responses count as failure?
 Software Metric: Reliability
• Mean time to repair (MTTR) (2):

• Mean time to failure (MTTF) (3):

MTBF = MTTF + MTTR
• Mean time to acknowledge (MTTA) (4)
 Software Metric: Reliability
• Software Reliability is also measured by
performing Reliability Testing.
• Read more at:
https://en.wikipedia.org/wiki/Software_reliability_testing
Part 2

CAPTURING REQUIREMENTS
 Requirements challenges
• Customers cannot describe the software.
– They only have very faint ideas.
• Customers propose problematic functional
description (everyone thinks differently).
– They will later blame software developers for data
conflicts.
• Customers talk a lot and their ideas just don't
add up.
– These customers do not like to write it down.
 Requirements Tasks
• Finding out what users need
• Documenting users' needs
• Avoiding premature design assumptions
• Resolving conflicting requirements
• Eliminating redundant requirements
– Customers often want to build a software that can
do everything.
• Make sure requirements are traceable
– Track the changes to requirements.
 Sources of Requirements
• Stakeholders
– People affected in some way by the system
– Stakeholders describe requirements at different
levels of detail
• Documents
• Existing system
• Understanding of business domain
 User Requirements Examples - 1
• The system shall maintain records of all payments
made to employees on accounts of salaries, bonuses,
travel/daily allowances, medical allowances, etc.
• The system shall connect with the central computer
to send daily sales and inventory data from every
retail store.
• The system shall maintain records of all library
materials including books, serials, newspapers and
magazines, video and audio tapes, reports,
collections of transparencies, CD-ROMs, DVDs, etc.
 User Requirements Examples - 2
• The app should let a shipper see a list of customer
orders around a chosen area.
• The app should let a shipper make a phone call to
the customer of the orders that he has picked.
• The app should let a shipper take a photo and save it
to the system as proof that he has received the
shipment package.
• The response time of all operations should be less
than 1 second.
• The app should operate on Android 5 or later and iOS
10 or later.
 Functional vs. Non-Functional
• Functional requirement: description of the
software's explicit behaviors, what it should and
shouldn't do.
– Are often specific & measurable
• Non-functional requirement: constraints on the
services or functions offered by the software.
– Performance, security, availability…
– Speed, size, ease of use…
– Development constraints: time, process, policies
– Applies to the whole software system
Quatitative non-functional requirements

Adapted from Sommerville, 2011

Requirements Engineering Activities
 Requirements Elicitation
• Determining the system requirements from
sources of requirements.
– stakeholders
– existing systems
– documents
– domain knowledge
– market studies
• Can be acquisition or discovery of requirements.
 Tips for capturing requirements
• Talk to the customer to understand his/her concepts
and viewpoints.
– Sometimes what the customer says may not be what he
means because he understands a certain concept
differently from you.
• Use critical thinking to find mistakes in customer's
requirements and discuss with him to refine the
requirements.
• Ask the customer to give examples and imply
requirements from those examples.
• Ask the customer about the final goals that make
him want to build the software.
 Requirements Analysis and Negotiation
• Adjustment of customer requirements to achieve
a successful result.
• Incomplete and inconsistent information needs to
be tackled.
• Some analysis and negotiation needs to be done
on account of budgetary constraints.
• Negotiations among different stakeholders and
requirements engineers.
 Methods of specifying requirements
• Data-flow diagrams
• E-R models
• Use cases
• Activity diagrams
• Wireframes/mock-ups
• Prototypes
(and many others)
 Data-flow diagrams
• A type of diagram which
has simple notations and is
close to real-life business
operations.
 E-R diagrams
• Can be used to model data and relationships between data.
• Can be easily converted into a database design.
 Use-case diagrams

Action

Check out is done

Actor after View cart
 Activity diagrams

• A type of diagram
where actions can be
presented as part of
activity flows.

• It has the ability to

describe conditional
control flow.
 Wireframe
A wireframe is a rough layout of a website's elements.
 Mockup vs. Prototype
• Mock-up: A draft version of the software's UI that is
more detailed and closer to the finished product
than the wireframe.
• Prototype: An early version of the software that
shows the UI design and is interactive (clickable, with
fake functionality).
• Evolutionary Prototyping: A prototype is first
constructed from user requirements and will be
updated as customer sends feedbacks. Each version
adds more functionality or improvements, until the
final product is obtained.
Example mockup
Example prototype
Example Interactive Prototype