Lecture 11B Trimester 1 2019

You might also like

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 24

STAGE ONE DIPLOMA

PRG01S1 PROGRAMMING

Your pathway to Curtin. On campus. On track. www.curtincollege.edu.au


COMMONWEALTH OF AUSTRALIA
Copyright Regulations 1969
WARNING
This material has been reproduced and communicated to
you by or on behalf of Curtin College pursuant to Part
STAGEVBONE of the Copyright Act 1968 (the Act).
DIPLOMA
The material in this communication may be subject to
copyright under the Act. Any further reproduction or
communication of this material by you may be the
subject of copyright protection under the Act.
Do not remove this notice.
Your pathway to Curtin. On campus. On track. www.curtincollege.edu.au
Lecture 11B – Requirements II
Software Requirement Specification
Functional and Non-functional
REQUIREMENTS SPECIFICATION

• Requirements specification involves:


• Organising the requirements into a Software
Requirements Specification (SRS) document.
• The SRS document focuses on what the
system must do (i.e. the problem). It must not
describe how the software works.
• The SRS document is useful in various ways:
• A statement of customer needs.
• A basis for costing.
• A specification for design, implementation, testing.
• A reference document for maintenance.
SRS DOCUMENT

• The SRS is a legal contract between the developer and the


customer:
• It can be used to settle disagreements.
• The final product must be accepted by the customer if it
matches the SRS document.
• The SRS is written using domain terminology:
• Complete, concise, consistent & unambiguous.
• Easy to read and understand by the client.
• Easy to modify and maintain.
• Most importantly, the SRS must be verifiable during
acceptance testing.
SRS DOCUMENT LAYOUT

1. Introduction:
• Background and system environment.
2. Functional Requirements:
• A numbered list of functions, with inputs & outputs.
3. Non-Functional Requirements:
• system characteristics;
• external interfaces (e.g. user interface).
4.Constraints.
5. Verification (Acceptance) Criteria.
FUNCTIONAL REQUIREMENTS

• Functional requirements describe a software


system as a set of functions {fi}.
• Each function fi transforms a domain of inputs to
a corresponding range of outputs:
Input Data fi Output
Data

• Each function is described in terms of:


• The input from and output to the user.
• The processing required.
FUNCTIONAL REQUIREMENTS:
A BLACK BOX SPECIFICATION
• The functional requirements are a black box
specification of the system:
• Only externally visible behaviour (i.e. input and output)
is documented.
• The internal details of the system are not known.

Input Output
The System
Data Data

• In short, the functional requirements describe


what the system must do, but not how!
EXAMPLE:
A NARRATIVE SPECIFICATION

1.When the system is used to Find Books,


the user is asked for one or more keyword.
The system displays details of any books
with titles containing the keyword(s). Book
details include the Author, Title, Publisher,
Year of Publication, and ISBN.
EXAMPLE: FUNCTIONAL
REQUIREMENTS
• F1: Find Books
• Input:
• Keyword(s).
• Output:
• Book Details
• Processing:
• Search for books with titles containing the keyword(s).
• [Definition]:
• Book details include the Author, Title, Publisher, Year
of Publication, ISBN.
EXAMPLE:
A NARRATIVE SPECIFICATION

1.When the system is used to Renew Loans,


the user is asked to provide a membership
number. After membership validation the
system lists details of any books currently
on loan to the member. The user may
choose to renew one or more book loans,
after which they are informed of the new due
date for each book loan that is successfully
renewed.
EXAMPLE

• F2: View Loans


• Input:
• membership number.
• Output:
• Current book loan details.
• Processing:
• Validate the membership number and retrieve book
loan details.
• [Error]:
• Invalid membership number.
EXAMPLE

• F3: Renew Loans


• Input:
• Book to renewed.
• Output:
• New due date(s).
• Processing:
• Update the due date for each book that is renewed.
• [Error]:
• One or more books has been recalled.
IN-CLASS TASK

A computer system is needed for a hospital to keep track of the patients.


The system will need to check patients in when they arrive. As they are
checked in they are allocated a room. The system will need to check
patients out when they leave again. The system will need to be able to
display available rooms. Doctors will need to be able to find patients as well
as move patients if the room is unsuitable for that particular patient.

You should form yourselves into groups of 2-3 students and attempt the
exercises below as a group. Discussion will form a large part of the
exercise so working individually is a tad pointless.

Exercise
As a group produce a list of functional requirements. Using the lecture
examples as a guide, write them out as a list of numbered requirements
with input, output and a description of the functionality.
NON-FUNCTIONAL
REQUIREMENTS
• These are characteristics of the system that cannot be
expressed as functions.
• Security – e.g. internet systems.
• Reliability – e.g. safety-critical systems.
• Performance – e.g. real-time systems.
• Usability (human-computer interface).
• Maintainability and portability.
• They describe characteristics of the system rather than
explicit behaviour.
• Within the control of the developer.
• Non-functional requirements must be able to be measured
via specified metrics.
EXAMPLES: POOR

• Software must have a good response time.


• Software must be high quality.
• User interface must be easy to use.
• Software must be secure.
• Software must easy to add functionality to.
• Web pages must display in all browsers.
EXAMPLES: BETTER

• Each web page must be fully rendered within


5 seconds using Firefox.
• Web pages must look and function as
specified in Firefox, Safari, Opera and ie.
• Server downtime must not exceed 1 hour per
month.
• Database must be able to process 500
transactions per second.
• Only registered buyers can submit bids.
IN-CLASS TASK

A computer system is needed for a hospital to keep track of the patients.


The system will need to check patients in when they arrive. As they are
checked in they are allocated a room. The system will need to check
patients out when they leave again. The system will need to be able to
display available rooms. Doctors will need to be able to find patients as well
as move patients if the room is unsuitable for that particular patient.

You should form yourselves into groups of 2-3 students and attempt the
exercises below as a group. Discussion will form a large part of the
exercise so working individually is a tad pointless.

Exercise
Discuss the non-functional requirements for the system. As a group,
produce a list of non-functional requirements. Don't forget to specify a
metric for each one.
CONSTRAINTS

• Most systems must satisfy constraints that


are beyond the control of the developers:
• Management constraints:
• e.g. budget, schedule, and resource limits.
• Standards compliance:
• e.g. ANSI C/C++, and many others.
• Compatibility:
• e.g. hardware, operating system, or DBMS.
• Interfaces with other systems.
FURTHER EXAMPLES

• Software must operate on vista or windows


10.
• Software must be operational in the client
installation by 30th June 2010.
• Software memory footprint must not exceed
200 MB.
IN-CLASS TASK

A computer system is needed for a hospital to keep track of the patients.


The system will need to check patients in when they arrive. As they are
checked in they are allocated a room. The system will need to check
patients out when they leave again. The system will need to be able to
display available rooms. Doctors will need to be able to find patients as well
as move patients if the room is unsuitable for that particular patient.

You should form yourselves into groups of 2-3 students and attempt the
exercises below as a group. Discussion will form a large part of the
exercise so working individually is a tad pointless.

Exercise
Discuss the constraints for the system. As a group, produce a list of
constraints.
THINGS TO AVOID

• Verbosity:
• Rambles rather than being clear and concise.
• Incompleteness:
• Often a side effect of verbosity, things are left out or vaguely
mentioned.
• Subjectivity:
• Every requirement or constraint must be verifiable so cannot use
subjective terms (e.g. fast, good).
• Inconsistency:
• Use the same terms throughout document.
• Unrealistic:
• Don't make promises that cannot be kept within your life time!
WORKSHOP TASK

A computer system is needed for a hospital to keep track of the patients.


The system will need to check patients in when they arrive. As they are
checked in they are allocated a room. The system will need to check
patients out when they leave again. The system will need to be able to
display available rooms. Doctors will need to be able to find patients as well
as move patients if the room is unsuitable for that particular patient.

Exercise
Each group member should take a copy of the notes that you have
produced during the lecture exercises. From those notes, write your own
SRS. Use the lecture notes to guide you as to what information is required
in an SRS.

This must be 100% your own SRS.


NEXT WEEK

• Test 3
• Exam preparation

You might also like