Software Requirements

Engineering
Lecture # 1
CODE OF ETHICS
• All students must come to class on time
(Attendance will be taken in last 5 to 10 mins)

• Students should remain attentive during class and

avoid use of Mobile phone, Laptops or any gadgets

• Respect faculty and staff through actions and

speech

• Class participation is encouraged

 Course Introduction
• Course Objectives:
• This course provides an in-depth knowledge about Requirement
Engineering i.e. elicitation, analysis, specifications, verification, and
management of software requirements
• The ability to understand and apply different software
requirements elicitation techniques.
• The ability to identify stakeholders and their needs.
• The ability to prepare software requirements specifications as per
industry standards.
• Enhance practical skills through project work
• Prerequisites:
• Introduction to Software Engineering
• Mode
• Mix of lectures, presentations, discussions, exams
 Text Book
• Primary
• Managing Software Requirements: A Use Case
Approach, Second Edition By Dean Leffingwell,
Don Widrig, Addison-Wesley
• Reference
• Mastering the Requirements Process, Second Edition,
By Suzanne Robertson, James Robertson, Addison-
Wesley
• Software Requirements, Second Edition by Karl E.
Wiegers ISBN:0735618798, Microsoft Press
Course Outline
• Introduction to Requirements Engineering
1. Analyzing the Problem
• The Five Steps in Problem Analysis, Business Modeling, Systems
Engineering of Software-Intensive Systems

2. Understanding User and Stakeholder Needs

• The Challenge of Requirements Elicitation, The Features of a
Product or System, Interviewing, Requirements Workshops,
Brainstorming and Idea Reduction, Storyboarding
3. Defining the System
• A Use Case Primer, Organizing Requirements Information, The
Vision Document, Product Management
4. Managing Scope
• Establishing Project Scope, Managing Your Customer
Course Outline
5. Refining the System Definition
• Software Requirements—A More Rigorous Look, Refining the Use
Cases, Developing the Supplementary Specification, On Ambiguity
and Specificity, Technical Methods for Specifying Requirements
6. Building the Right System
• From Use Cases to Implementation, From Use Cases to Test Cases,
Tracing Requirements, Managing Change, Assessing Requirements
Quality in Iterative Development
Evaluation Components
• Quizzes - 10
• Assignments - 10
• Midterm - 30
• Final - 50
 Sequence [Todays Agenda]
Content of Lecture
• Introduction
• Different State-of-the-art definitions
• Sources, levels & Importance of Software Requirements
• Scope of Requirement Engineering
• Role of requirements in Software Engineering
• The challenges of the Requirements Engineering
• Requirements Engineering Process
Introduction
• Goal of software developments is to develop software
• On time
• On budget
• Meet customer’s needs

• Requirements form the basis for all software products

• Requirements engineering is the process, which enables us to

systematically determine the requirements for a software
product
 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

 Want-something you would like to have

Software Requirement Engineering 10

 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 of the software system to be built

Response of software
 Software requirements may be: against the input

 Abstract statements of services

 Detailed mathematical functions

 Part of the technical document, which

describes a product

Software Requirement Engineering

 Can be
functionality
constraint

 A condition or capability that must be met or possessed by a

system...tosatisfy a contract, standard, specification, or other formally
imposed document.
IEEE Std729

Software Requirement Engineering

 Stakeholders
People affected in some way
by the system

 Documents

 Existing Systems

Software Requirement Engineering

Levels of Software Requirements

• Stakeholders describe requirements at different levels of

detail

• “One person’s floor is another person’s ceiling”

 Importance of Software
Requirements
• 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 difficult
to rectify later

• Fred Brooks
Examples of Requirements - 1
• The system shall maintain records of all payments made to
employees on accounts of salaries, bonuses, travel/daily
allowances, medical allowances, etc.
Examples of Requirements - 2
• The system shall allow users to search for an item by title,
author, or by International Standard Book Number

• The system’s user interface shall be implemented using a web

browser
Agenda for Introduction

• Role of requirements in Software

Engineering
• The challenges of the Requirements
Engineering
• Requirements Engineering Process
Software Engineering: Goal

• GOAL: to develop quality software—on

time and on budget—that meets
customers' real needs
• A software is good if it MEETS
STAKEHOLDERS EXPECTATIONS: (?)
• However, stakeholders are different!
• Then?
—it should be(at least) correct, reliable,
maintainable, user-friendly …
—the total cost it incurs over all phases of its
life cycle should be minimal and within the
budget
Software Requirement: definition

“A software capability that must be met or

possessed by a system or system component to
satisfy a contract, standard, specification, or
other formally imposed documentation.”
[Leffingwell & Widrig 2003]

• Writing requirements is a two-way process.

• It allows developer to map problem domain concepts

to solution domain concepts
Why User Requirements are Important
Role of Requirements: A Contract
• The set of requirements constitute a
contract between the client and the
software developer
—Software requirement documents are the
medium used to communicate user
requirements to technical people responsible for
developing the software.
• Serves as a basis for project planning
(schedule, budget)
• Requirements document is used both to
drive the design stage, and as a basis for
test planning.
 Reality …

• 31.1% of computer software projects get

canceled before they are completed,

• 52.7% will overrun their initial cost

• 94% of project start-ups are restarts of

previously failed projects.
The Root Causes of Project
Failure/Success (Standish)

• The Three Largest Problems in Software

Industry:
— Lack of user input: 13 percent of all “challenged” projects
— Incomplete requirements and specifications: 12 percent of
all “challenged” projects
— Changing requirements specifications: 12 percent of all
“challenged” projects

• The Three Primary Success Factors:

— User involvement: 16 percent of all successful projects
— Executive management : 14 percent of all successful
projects
— Clear statement of requirements: 12 percent of all
successful projects
Largest Software Development
Problems by Category
 High Cost of Requirements Errors

If a unit cost of one is

assigned to the effort
required to detect and repair
an error during the coding
stage ….
High Cost of Requirements Errors
• In order to repair the defect, we are likely to
experience costs in some or all of the following areas:
— Respecification.
— Redesign.
— Recoding.
— Retesting.
— Change orders (telling users and operators to replace a
defective version of the system with the corrected
version).
— Corrective action (undoing whatever damage may have
been done by erroneous operation of the improperly
specified system, which could involve sending refund
checks to angry customers, and so on).
High Cost of Requirements Errors
• Scrap (including code, design, and test cases that were
carried out with the best of intentions but then had to be
thrown away when it became clear they were based on
incorrect requirements).

• Product liability (if the customer sues for damages caused

by the defective software).

• Service costs for a company representative to visit a

customer's field location to reinstall the new software.
 IEEE Standard Glossary of Software
Engineering Terminology (1990) :
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 component to satisfy a
contract, standard, specification, or other
formally imposed document.
 Sommerville and Sawyer, 1997:
 Requirements are…a specification of what should
be implemented. They are descriptions of how the
system should behave

 Karl Wiegers
 Understanding what you intend to build before
you’re done building it
Software Requirement Engineering
Today’s Agenda

• Role of requirements in Software

Engineering

• The challenges of the Requirements

Engineering

• Requirements Engineering Process

Requirements: Challanges

• Insufficient user involvement

• Ambiguous requirements
• Gold plating
• Minimal specification
 Write User Requirements from
User’s Point of View!

Example 1: Login Validation

BAD (system’s perspective):

System shall prompt for user identification
and password.
GOOD (user's perspective):
User shall start accessing the system by
identifying himself.
 “Specific user Classes”

The more specific the user Classes the better will

be the requirement documentation

Example 2: Sample requirement for time tracking system

BAD (very generic):

User will enter number of hours worked per day for the tasks that
are assigned to him. User will be able to view his tasks and
view his team members task if he has a team.

GOOD (addresses specific requirements of individual Users

):
Supervisors, Team members will use the system for
assignment of tasks and monitoring tasks.
The Supervisor is interested in transferring his project plan of
individual tasks into the system.
Team Members will report time spent against each task.
 Building the Right System vs.
Building the System Right

Don’t Just Build the

System Right, Build
the Right System:

• Verification: Are we
building the system
right?
• Validation: Are we
building the right
system?
How Do We … ?

• … know what the system is supposed to

do?
• … keep track of the current status of
requirements?
• … determine the impact of a
requirements change?
• Answer: By proper requirements
engineering
Today’s Agenda

• Role of requirements in Software

Engineering

• The challenges of the Requirements

Engineering

• Requirements Engineering Process

 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
• Validation: you’ll ask your customer to
confirm that what you’ve written is accurate
and complete and to correct errors.
Requirements Engineering Process