Software Requirement Engineering

(SE311)
Lecture 01
Today’s objective
Today we will discuss
Course Objective
Course Outline and Lesson Plan
Course Policies (Attendance/Mobile etc)
Assignment Guideline
My course rules
Attendance at lectures is mandatory.
A lot of course material, lecture notes and interpretation are
covered during lectures may not be present in textbooks or
lecture notes.
No mobile telephones ringing or texting during the class
Questions can be asked anytime during lecture
All lecture notes, articles, case studies and reference
material would be shared with students.
Attendance policy of university will be adhered strictly.
No alternative/make up test would be taken for any
missed test/exam
Marks Distribution
Assignments: 15%
Midterm: 25%
Final Exam: 60%

A student 10 minutes late in class will be

considered absent.
75% attendance policy will hold.
Course Objective
The course objective is to
Gain understanding of
Software Requirement Engineering,
Its different stages and concepts,
Its activities.
To give student a practical knowledge on
making a requirement engineering artifacts.
Course Outline
Software Requirements
Engineering, System
Basic Requirement Engineering activities
Planning and Eliciting Requirements
Modeling and Analyzing Requirements
Communicating and Agreeing
Requirements
Realizing and Evolving Requirements
Course Material
G. Kotonya and I. Sommerville, Requirements
Engineering: Processes and Techniques, Wiley,
1998.
P. Loucopoulos and V. Karakostas, System
Requirements Engineering, McGraw Hill, 1995.
Software Requirement Engineering
Software Requirements
It is about WHAT not HOW
Requirements are the descriptions of the services
provided by a system and its operational
constraints
High level abstract statement/Detailed mathematical
specification
Complex (500 pages of description)
May serve as the basis for a bid/RFP for a contract
Can be part of contract
Requirements Engineering
“it is a process”
A process in which “what is to be done” is
elicited, modeled and communicated (Freeman)
The descriptions of the services and constraints
are the requirements for the system” (Somerville)
The process of finding out, analyzing,
documenting and checking these services and
constraints is called Requirements Engineering.”
(Somerville)
Why do we do RE?
Complete set of documented requirements that
Ensures the user (not the developer) drives system
functionalities
Helps avoiding confusion and arguments
Helps minimizing the changes
Changes in requirements are expensive.
Cost impact is
3 x as much during the design phase
5-10 x as much during implementation
10-100 x as much after release
Two third of finished system errors are due
to requirements or design errors.
Requirements process doesn’t guarantee no
future changes
Average project experiences about 25% changes
in the requirements
70-80% if the rework of the project
Must for critical applications
Some questions!!!!
What happens when the requirements are
wrong?
Systems are late, unreliable and don’t meet
customers needs
Is there an ideal requirements engineering
process?
No - processes must be tailored to organizational
needs
What is a requirements document?
The formal statement of the system requirements
What are system stakeholders?
Anyone affected in some way by the system
What is the relationship between requirements
and design?
Requirements and design are interleaved. Ideally
should be separate processes but in practice it is
impossible.
What is requirements management?
The processes involved in managing changes to
requirements
Systems Requirement Engineering
Systems engineering
There is a close relationship between
software and more general system
requirements
Computer-based systems fall into two broad
categories:
User-configured systems where a purchaser puts
together a system from existing software
products
Custom systems where a customer produces a
set of requirements for hardware/software system
and a contractor develops and delivers that
Classes of custom systems
Information systems
Primarily concerned with processing information
which is held in some database.
Examples: Executive Support System, Management
Information Systems, Decision-Support Systems,
Knowledge Management Systems, Transaction
Processing Systems, Office Automation Systems
Embedded systems
Systems where software is used as a controller in
some broader hardware system
Telecom, Smart Cards, Routers, Smart TVs, etc…
Command and control systems
Essentially, a combination of information
systems and embedded systems where special
purpose computers provide information which is
collected and stored and used to make decisions
Example: Situation Aware, Patriot Missile
Defense
Emergent properties
Emergent properties are properties of the system as
a whole
and only emerge once al of its individual sub-systems
have been integrated
Examples of emergent properties
Reliability
Maintainability
Performance
Usability
Security
Safety
 Systems engineering process
System System
requirements validation
engineering

Architectural System
design integration

Requirements Sub-system
partitioning development

Software
requirements
engineering
Systems engineering process
System requirements engineering
The requirements for the system as a whole are established
and written to be understandable to all stakeholders
Architectural design
The system is decomposed into sub-systems
Requirements partitioning
Requirements are allocated to these sub-systems
Software requirements engineering
More detailed system requirements are derived for the
system software
Sub-system development
The hardware and software sub-systems are
designed and implemented in parallel.
System integration
The hardware and software sub-systems are put
together to make up the system.
System validation
The system is validated against its requirements.
RE: Some observations
RE is not necessarily a sequential process:
RE is a set of activities that continue throughout
the development process
The problem statement will be imperfect
RE models are approximations of the world
 will contain inaccuracies and inconsistencies
 will omit some information.
detailed analysis can reduce the risk that these will
cause serious problems…
" …but that risk can never be reduced to zero
Perfecting a specification may not be cost-
effective
Requirements analysis has a cost
For different projects, the cost-benefit balance will be
different
Problem statement should never be treated as
fixed
Change is inevitable, and therefore must be planned for
There should be a way of incorporating changes
periodically
Importance of Requirement Engineering: Problems

Increased reliance on software

" E.g. cars, dishwashers, cell phones, web services, …
Software now the biggest cost element for mission
critical systems
 E.g. Boeing 777
Wastage on failed projects
 E.g. 1997 GAO report: $145 billion over 6 years on
software that was never delivered
High consequences of failure
" E.g. Ariane 5: $500 million payload
" E.g. Intel Pentium bug: $475 million
Testing Cost
E.g. Boeing 777: >40% of software budget spent
on testing
Re-work from defect removal
 E.g. Motorola: 60-80% of software budget (was)
spent on re-work
Changing Requirements
E.g. California DMV system
Requirements Engineers: Agents of Change
The requirements engineer must identify the
“problem”/”opportunity” and become an expert in the
problem domain
 Which problem needs to be solved? (identify problem Boundaries)
 Where is the problem? (understand the Context/Problem Domain)
"Whose problem is it? (identify Stakeholders)
" Why does it need solving? (identify the stakeholders’ Goals)
" How might a software system help? (collect some Scenarios)
" When does it need solving? (identify Development Constraints)
" What might prevent us solving it? (identify Feasibility and Risk)

A Requirements Engineer is an agent of change

Key points
 Requirements define what the system
should provide and define system
constraints
 Requirements problems lead to late delivery
and change requests after the system is in
use
 Requirements engineering is concerned with
eliciting, analyzing, and documenting the
system requirements
Systems engineering is concerned with systems as
a whole including hardware, software and
operational processes
The requirements document is the definitive
specification of requirements for customers,
engineers and managers.
The requirements document should include a
system overview, glossary, statement of the
functional requirements and the operational
constraints
Thankyou!!!