SOFTWARE

REQUIREMENT
ENGINEERING
LECTURE 1

Sundas Shireen Awan

BEFORE WE
BEGIN…
YOU KNOW MOST OF THE
STUFF
• Discipline and Respect
• Course Policies
• Attendance
• Originality of work
• Timely submission
• Etc [Link].

3
LET’S RECALL
• Discipline & Respect: Upholding professionalism and ethical
behavior is essential.
• Conduct yourself in a manner aligned with family, cultural, and
ethical values.
• Show respect and consideration for peers and instructors.
• Adhere to classroom rules and guidelines.
• Punctuality is crucial; always be on time.
• Regular attendance is mandatory—avoid missing classes.
• Take responsibility for your role as a student and community
member.

4
COURSE POLICIES
• Attendance as per the university requirement (75%)
• Attendance will be marked at any point during the class session,
and you need to be present to get yourself marked as that
• A zero tolerance will be shown against the use of unfair means
for your assessments
• If you miss your assessment or assignment, you miss it, no
makeups will be done
• All academic material will be provided on the GCR, and you will
be responsible to access it from there.
• You can also contact me at [Link]@[Link]

5
LECTURE 1
 SOFTWARE ENGINEERING
Consistency in
Follow structured practice Measurable and
processes trackable progress

• “The application of a systematic, disciplined, quantifiable approach

to the development, operation, and maintenance of software".[IEEE]
• Software must meet defined standards
Scope

Quality

Cost Schedule 7
 SUCCESSFUL SOFTWARE
“Successful software development is about creating value, not just
software”
• Success Factors:
• Meets the purpose it was designed for
• Maintains high quality standards
• Operates reliably with minimum risk
• Delivers within budget and time constraints
• Has a useful lifecycle and warranty

• A successful system must satisfy both technical and business goals.

8
USER REQUIREMENTS

9
USER REQUIREMENTS

10
 REQUIREMENTS – A PROBLEM
• Approximately 60%-70% of IT project failures result from poor
requirements gathering, analysis, and management.
- Meta Group, March 2003

• “If you do a post-mortem evaluation on unsuccessful software

projects, you'll find that most of them failed because the person
responsible didn't properly manage the project's requirements
and expectations.”
- Andy Feibus

11
 REQUIREMENTS – A PROBLEM
• A study by project management consulting company identifies five
top causes of troubled projects:
• Requirements: Unclear, lack of agreement, lack of priority,
contradictory, ambiguous, imprecise.
• Resources: Lack of resources, resource conflicts, turnover of key
resources, poor planning.
• Schedules: Too tight, unrealistic, overly optimistic.
• Planning: Based on insufficient data, missing items, insufficient
details, poor estimates.
• Risks: Unidentified or assumed, not managed.

12
REQUIREMENTS – A PROBLEM

13
PROJECT SUCCESS &
REQUIREMENTS

Source: “Chaos Chronicles, III, 2003”. [Link]

14
 THE HARDEST SINGLE PART OF
BUILDING A SOFTWARE SYSTEM
“… is deciding what to build … No other part of the work so
cripples the resulting system if done wrong. No other part is
more difficult to rectify later”
F.P. Brooks 15
WHO ARE YOU AS A REQUIREMENT
ENGINEER?

16
 NO OTHER PART IS MORE
DIFFICULT TO RECTIFY LATER
• Companies pay a premium of as much as 60% on time and budget
when they use poor requirements practices on their projects.
Requirements
10 - 20
The later you find a mistake, the more
Design expensive it becomes to fix.
50 That’s why good requirements practices
are critical → catch errors early, save money
Coding
and time.
100
Unit Testing
200
Acceptance Test
500
Maintenance
2000 17
 WHAT ARE REQUIREMENTS?
• “A condition or capability to which a system must conform”.
(RUP)
• “The descriptions of the services and constraints are the
requirements for the system”. (Sommerville)
• “Something required, something wanted or needed”. (Webster’s
dictionary)
• There is a huge difference between wanted and needed and it
should be kept in mind all the time
• Need- something you have to have, Essential for functionality
• Want -something you would like to have, Nice-to-have, optional

18
 WHAT ARE REQUIREMENTS?
• The IEEE definition
1. A condition or capability needed by a user to solve a problem
or achieve an objective.
2. 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.
3. A documented representation of a condition or capability as is
1 and 2.
functionali
ty
Can be
constraint
19
 SOFTWARE REQUIREMENTS
• A complete description of what the software system will do
without describing how it will do it is represented by the software
requirements.
• Software requirements are complete specification of the desired
external behavior (Response of software against the input) of the
software system to be built.
• Software requirements may be:
• Abstract statements of services
• Detailed mathematical functions
• Part of the bid of contract
• The contract itself
• Part of the technical document, which describes a product
20
 REQUIREMENTS ENGINEERING
• “The process of finding out, analyzing, documenting and
checking services and constraints is called Requirements
Engineering.” (Sommerville)
• A systematic approach to eliciting, organizing, and documenting
the requirements of the system, and a process that establishes and
maintains agreement between the customer and the project team
on the changing requirements of the system.

21
 REQUIREMENTS ENGINEERING
PROCESS
• Elicitation: Work with the customer on
gathering requirements
• Analysis: Process this information to
understand it, classify in various categories,
and relate the customer needs to possible
software requirements
• Specification: Structure the customer input
and derived requirements as written
documents and diagrams
• Validation: you’ll ask your customer to
confirm that what you’ve written is accurate
and complete and to correct errors.
22
 SOURCES OF REQUIREMENTS
• Stakeholders
• Documents
• Existing Systems
• Domain/Business Area

23
COMPONENTS OF REQUIREMENT
ENGINEERING

24
GOOD VS BAD REQUIREMENTS

25
TYPES OF SOFTWARE
REQUIREMENTS

Functional requirements
Types of Software
Requirements Non-functional
requirements

Domain requirements

Inverse requirements

Design and implementation

constraints
26
 FUNCTIONAL REQUIREMENTS
• In software engineering, a functional requirement defines a function
of a software system or its component. Functional Requirements
• A function is described as a set of inputs, the behavior, and outputs.
are Backbone of any
System’s Requirements
• Functional requirements may be calculations, technical details, data
manipulation and processing and other specific functionality that
define what a system is supposed to accomplish.
• Functional requirements are the statements and services that
system should provide in two clearly described external behaviors
✔ Reaction to particular input (e.g give some input to software, and it
produces a result)
✔ Behavior in particular situations (e.g If I click on an exit button then
system behaves in a particular way)

27
 NON-FUNCTIONAL
REQUIREMENTS
• In requirements engineering, a non-functional
requirement is requirement that specifies
criteria that can be used to judge the
operation of a system, rather than specific
behaviors.
• Non-functional requirements are often called
qualities of a system.
• Other terms for non-functional requirements
are "constraints", "quality attributes", "quality
goals", "quality of service requirements" and
"non-behavioral requirements".
• Informally these are sometimes called the
"ilities", from attributes like stability and
portability.
28
FUNCTIONAL VS
NON-FUNCTIONAL
REQUIREMENTS

29
TYPES OF NON-FUNCTIONAL
REQUIREMENTS
Types Explanation

Specify that the delivered product must behave in a particular way

Product Requirements
e.g. execution speed, reliability, etc.

Are a consequence of organizational policies and procedures e.g.

Organizational Requirements
process standards used, implementation requirements, etc.

Arise from factors which are external to the system and its
External Requirements development process e.g. interoperability requirements, legislative
requirements, etc.

30
NON-FUNCTIONAL REQUIREMENTS

31
 DOMAIN REQUIREMENTS
• Requirements that come from the application domain and reflect
fundamental characteristics of that application domain.
• These can be both the functional or non-functional requirements.
• These requirements, sometimes, are not explicitly mentioned.
• Their absence can cause significant dissatisfaction.
• Domain requirements can impose strict constraints on solutions.
• Domain-specific terminology can also cause confusion.
• For Example:
✔ In a mostly University grading System, there is no concept of CGPA greater
than 4.0.
✔ However, if care is not taken novice developers can be tempted into
developing systems, which calculates CGPA more than 4.0.
32
 INVERSE REQUIREMENTS
• They explain what the system shall not do.
• Inverse requirements describe the constraints on the allowable
behaviors.
• Many people find it convenient to describe their needs in this manner.
• These requirements indicate the indecisive nature of customers
about certain aspects of a new software product.
• Example:
• The system shall not use red color in the user interface, whenever it
is asking for inputs from the end-user.
• Safety and security requirements are usually stated in this manner.

33
 DESIGN AND IMPLEMENTATION
CONSTRAINTS
• They explain the restrictions on how the system will be built or deployed.
• These constraints limit the design choices and technologies that can be
used.
• They are often imposed by business needs, technology standards, or
external regulations.
• Such requirements guide developers and architects to stay within feasible
boundaries.
• Example:
• The system shall be developed in Java (not any other language).
• The database shall be Oracle to integrate with existing company systems.
• The software must run on Windows Server 2022.
• These constraints ensure compatibility, maintainability, and compliance.

34
 The problem domain is

PROBLEM DOMAIN where we start — it's

about understanding
"what" to solve before
• The problem domain is the real world where the users live and work. deciding "how" to solve it.
• It’s where the actual problems exist that the software is supposed to
solve.
• It includes the users, their tasks, their goals, and the challenges they
face.
• These people might not be technical — they just want a tool to make their
work easier.
• Our job is to understand their problems, in their language, and design the
right solution.
• If we misunderstand the problem domain, we’ll likely build the wrong
system, even if the software works perfectly.
• Example:
✔ If you're building a school management system, the problem domain includes
teachers, students, and admin staff, their daily routines (taking attendance,
managing grades) and rules like exam policies or grading standards
35
 STAKEHOLDERS
• Stakeholders are the people who are connected to the project in
some way.
• They may use the system, benefit from it, be affected by how it
works or have authority over it (like a manager or client). Stakeholders are
everyone who cares
• Examples: about or is impacted by
the system — and we
• Users (students, employees, customers)
must build with their
• Clients (the person or company who requested the system) needs in mind.

• Managers or decision-makers
• Developers and testers
• Government or legal authorities (in some projects)

36
 STAKEHOLDER NEEDS
• Each stakeholder has their own needs, goals, or concerns.
• Our job is to listen, understand, and balance those needs
when designing the system.
• If we ignore even one important stakeholder, the system might
fail.
• As we talk to different stakeholders, we collect their needs
and arrange them like a pyramid.

Needs

37
 MOVING TOWARDS THE
SOLUTION DOMAIN
• Once we fully understand the problem
domain (real-world user needs), we
move to the solution domain — this is
where we design and build the actual
system.
• The solution domain is our world — full
of technology, programming,
software tools, servers, and
networks.
• Here, we use our technical skills to
create a system that solves the user's
problem.
• It’s where we translate real needs into 38
 MOVING TOWARDS THE
SOLUTION DOMAIN
• A feature is a service or function the system provides to
satisfy a stakeholder’s need.
• Think of features as user-friendly statements that
describe what the system can do.
• Examples:
• “The car will have power windows.”
• “The phone allows screen locking using a pattern.”
• “Student attendance will be marked using face
recognition.”
• These are not technical details—they're written in the
user’s language to show how the system will help them.

39
 MOVING TOWARDS THE
SOLUTION DOMAIN
• Once we've listed the features the system should have (based on user
needs), the next step is to define the software requirements.
• Features are general — like “Face recognition for attendance”. Software
Requirements are detailed, specific instructions for how the system must
work to deliver those features.
• Feature: “Mark attendance through face recognition”.
• Software Requirement:
• “The system must detect and identify a student’s face within 3 seconds.”
• “The system must store attendance data securely in the database.”
• “Only registered faces should be allowed to mark attendance.”
• They guide developers in building the system.
• They ensure everyone agrees on exactly what the system should do.
• They help verify that the final system meets user needs.
40
 MOVING TOWARDS THE
SOLUTION DOMAIN
• We have moved from the problem domain, represented by the user needs.
• We discovered, to a definition of a system that will constitute the solution domain,
represented by the features of the system and the software requirements that will
drive its design and implementation.
Problem
Domain

Problem Domain = Understand

the need
Needs
Solution Domain = Build the
solution
Features = Bridge between Features
users and developers

Software
Requirements 41
 ACTIVITY
Draw a scenery with the following requirements:
• A house or a hut
• Mountains and sun
• Trees
• Water Stream
• Some animals and birds
Time Allowed: 5 min (To draw) and 5 min (For
Discussion)

42
[Link]

43
THANK
YOU
☺
44