INTRODUCTION TO

SOFTWARE ENGINEERING
SPRING 2019 (CSSE-3113)

DR. TOQEER MAHMOOD

Today’s Agenda…
REQUIREMENTS
 A condition or capability needed by user to solve a 
problem or achieve an objective.

 A condition or capability that must be met or 
possessed by a system or system component to 
satisfy a contract, standard, specification, or other 
formally imposed document.
REQUIREMENT ENGINEERING
 Requirements are ... A specification of what 
should be implemented. They are descriptions of 
how the system should behave, or of a system 
property or attribute. They may be a constraint on 
the development process of the system. 
[Sommerville]
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 organization’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 the system.”
SOME RISKS FROM INADEQUATE REQUIREMENT PROCESS

 Insufficient user involvement leads to 
unacceptable products.
 Wrong user requirements contribute to overruns
and degrade product quality.
 Ambiguous requirements lead to ill‐spent time 
and rework.
 Gold‐plating by developers and users adds 
unnecessary features.
 Incompletely defined requirements make accurate 
project planning and tracking impossible.
LEVELS OF REQUIREMENTS
 Business Requirements
 User Requirements
 Functional Requirements
 Non‐Functional Requirements
BUSINESS REQUIREMENTS
 These are used to state the high‐level business 
objective of the organization or customer
requesting the system or product.
 They are used to document main system features 
and functionalities without going into their nitty‐
gritty details.
 They are captured in a document describing the 
vision and scope.
BUSINESS REQUIREMENTS-EXAMPLE
 User will be able to correct spelling errors in a 
document efficiently and it will be integrated with 
the existing system. 
USER REQUIREMENTS
 User requirements add further details to the 
business requirements.
 User requirements are statements of what 
services the system is expected to provide to 
system users and the constraints under which it 
must operate.
USER REQUIREMENTS - EXAMPLE
 Finding spelling errors in the document and 
decide whether to replace each misspelled word 
with the one chosen from a list of suggested 
words.
FUNCTIONAL REQUIREMENTS
 These are statements of services the system 
should provide, how the system should react to 
particular inputs, and how the system should 
behave in particular situations.
 In some cases, the functional requirements may 
also explicitly state what the system should not 
do.
FUNCTIONAL REQUIREMENTS - EXAMPLES

 Find and highlight misspelled words. 

 Display a dialog box with suggested replacements. 
NON-FUNCTIONAL REQUIREMENTS
 These are constraints on the services or functions 
offered by the system
 Design constraints: these include time 
constraints, constraints on the development 
process, and constraints imposed by standards. 
 Quality requirements: these define the properties 
or qualities of a product including usability, 
efficiency, performance, space, reliability, 
portability, etc.
NON-FUNCTIONAL REQUIREMENTS - EXAMPLE

 It must be integrated into the existing word 
processor which runs on Windows platform.