User and System

Requirements

Maryam Javed
6th Nov 2019
SRS

Document
 Objectives

• To introduce the concepts of user requirements

and system requirements
• To describe functional and non-functional
requirements
• To explain how software requirements may be
organised in a requirements document

3
Requirements engineering

• The process of finding out, analysing,

documenting, and checking the services that the
customer requires from a system and its
operational constraints is called RE.
• Requirement may range from a high-level abstract
statement of a service or of a system constraint to
a detailed mathematical functional specification.
Prof. Loganathan R., CSE, HKBKCE

4
 Requirements abstraction
“If a company wishes to let a contract for a large software
development project, it must define its needs in a
sufficiently abstract way that a solution is not pre-defined.
The requirements must be written so that several
contractors can bid for the contract, offering, perhaps,
different ways of meeting the client organisation’s needs.
Once a contract has been awarded, the contractor must
write a system definition for the client in more detail so
that the client understands and can validate what the
software will do. Both of these documents may be called
the requirements document for thesystem.”
5
 Types of requirement
• User requirements (high level abstract requirements)
– Statements in natural language plus diagrams of what
services the system provides and its operational
constraints. Written for customers.
• System requirements (description of what system shoulddo)
– A structured document(also called functional specification)
setting out detailed descriptions of the system’s functions,
services and operational constraints. Defines what should
be implemented so may be part of a contract between
client and contractor.
6
Definitions and specifications
User requirement Definition

1. LIBSYS shall keep track of all data required by copyright licensing

agencies in INDIA and elsewhere
System Requirements Specification

1. On making a request for a document from LIBSYS, the requestor shall be

presented with a form that records details of user and the request made
.
2. LIBSYS request forms shall be stored on the system for 5 years from the
date of the request.
3. All LIBSYS reque.st forms must be indexed by user, by the name of the
material requested and by the supplier of the request
4. LIBSYS shall maintain a log of all request.s that have been made to the
system.
5. For material where authors lending rights apply, loan details shall be sent
monthly to copyright licensing agencies that have registered with LIBSYS.
6
Requirements
readers
Client Managers
System End-Users
User
Client Engineers
Requirements
Contractor Managers
System Architect

System End-Users
System Client Engineers
Requirements System Architect
Software Developers

8
Functional and non-functional requirements
• Software system requirements are classified as:
• Functional requirements
– Statements of services the system should provide, how the
system should react to particular inputs and how the system
should behave in particular situations(and sometimes what it
should NOTdo).
• Non-functional requirements
– constraints on the services or functions offered by the system
such as timing constraints, constraints on the development
process, standards, etc. Apply to the system as whole.
• Domain requirements
– Requirements that come from the application domain of the
system and that reflect characteristics of that domain. 9
 Functional requirements
• Describe what the system should do.
• Depend on the type of software, expected users
and the type of system where the software is
used.
• Functional user requirements may be high-level
statements of what the system should do but
functional system requirements should describe
the system services in detail, its i/o, exceptions
and soProf.
on. Loganathan R., CSE, HKBKCE

1
0
 Example: The LIBSYS system

• A library system that provides a single interface to

a number of databases of articles in different
libraries.
• Users can search for, download and print these
articles for personal study.
 Examples of functional requirements of
LIBSYS

• The user shall be able to search either all of the

initial set of databases or select a subset fromit.
• The system shall provide appropriate viewers for
the user to read documents in the document
store.
• Every order shall be allocated a unique identifier
(ORDER_ID) which the user shall be able to copy
to the account’s permanent storagearea.
 Requirements imprecision

• Problems arise when requirements are not

precisely stated.
• Ambiguous requirements may be interpreted in
different ways by developers and users.
• Consider the term ‘appropriate viewers’
– User intention - special purpose viewer for each
different document type;
– Developer interpretation - Provide a text viewer that
Prof. Loganathan R., CSE, HKBKCE
shows the contents of the document.
 Non-functional requirements

• Related to emergent properties and constraints .

Emergent properties are reliability, response time,
storage requirements and so on. Constraints are
I/O device capability, data representations, etc.
• Process requirements may also be specified
mandating a particular CASE system, programming
language or development method.
• Non-functional requirements may be more critical
than functional requirements. If these are not
met, the system is useless.
Problems in non-functional requirements

• Non-functional requirements may be very difficult to

state precisely and imprecise requirements may be
difficult to verify.
• Goal
– A general intention of the user such as ease of use, recovery
from failure, etc.
• Verifiable non-functional requirement
– A statement using some measure that can be objectively tested.
• Goals are helpful to developers as they convey the
intentions of the systemusers.
 Examples

• A systemgoal
– The system should be easy to use by experienced controllers and should be
organised in such a way that user errors are minimised.
• A verifiable non-functionalrequirement
– Experienced controllers shall be able to use all the system functions after a
total of two hours training. After this training, the average number of errors
made by experienced users shall not exceed two perday.
Requirements Measures
Property Measure
Processed transactions/second
Speed User/Event response
time Screen refresh
time
M Bytes
Size
Number of ROM chips
Training time
Ease ofuse
Number of help frames
Mean time to failure
Probability of
Reliability
unavailability Rate of
failure occurrence
Availability
Time to restart after failure
Robustness Percentage of events causing failure
Probability of data corruption on
Prof. Loganathan R., CSE, HKBKCE
failure
Percentage of target dependent statements
Portability
Number of target systems
 User requirements
• Should describe functional and non-functional
requirements in such a way that they are
understandable by system users who don’t have
detailed technical knowledge.
• User requirements are defined using natural
language, tables and diagrams as these can be
understood by all users.
A user requirement for accounting
system in LIBSYS

4..5 LIBSYS shall provide a financial accounting

system that maintains records of all payments
made by users of the system. System managers
may configure this system so that regular users
may receive discounted rates.
Guidelines for writing UserRequirements

• Invent a standard format and use it for all

requirements.
• Use language in a consistent way. Use shall for
mandatory requirements, should for desirable
requirements.
• Use text highlighting(Bold, Italic or Colour) to
identify key parts of the requirement.
• Avoid the use of computerjargon.
 IEEErequirements standard
• Defines a structure for a requirements document.
1. Introduction.
1. Purpose of the requirements document
2. Scope of the product
3. Definition, acronyms & abbreviations
4. References
5. Overview of the remainder of thedocument
2. General description.
1. Product perspective
2. Product functions
3. User characteristics
4. General constraints
5. Assumptions & dependencies
3. Specific requirements.(covers functional, non-functional & interfacerequirements)
Prof. Loganathan R., CSE, HKBKCE
4. Appendices.
5. Index.
Requirements document structure
• Organisation for a requirements document based on IEEEstandard

– Preface : Defines expected readership, version history & changes in eachversion

– Introduction : Describes the needs of the system
– Glossary : Defines technical terms used in thedocument
– User requirements definition : Describes services provided & non-
functional requirements
– System architecture : Presents high level overview ofsystem
– System requirements specification : Describes functional & non-
functional requirements in detail
– System models : Provides 1 or more systemmodels
– System evolution : Describes anticipated changes
– Appendices
– Index