Software Requirements Engineering

Spring 2020

Dr Muhammad Ali Memon

And Mr. Kamran Dahri
IICT, UoS, Jamshoro
Books
Software Requirements (2nd Edition)
• Karl E. Wiegers

Managing Software Requirements: A Use Case

Approach (Second Edition)
• Dean Leffingwell
• Don Widrig

The Guide to the Business Analysis Body of

Knowledge (Version 2.0)
• International Institute of Business Analysis
Course Benefits
 Improve the quality of your project’s
requirements early in the development cycle,
which reduces rework and improves
productivity.
 Meet schedule objectives by controlling scope

creep and requirements changes.

 Achieve higher customer satisfaction.
 Reduce maintenance and support costs.
Factors that contribute to Project
Failure?
1. Lack of User Input
2. Incomplete Requirements & Specifications
3. Changing Requirements &Specifications
4. Lack of Executive Support
5. Technology Incompetence
6. Lack of Resources
7. Unrealistic Expectations
8. Unclear Objectives
9. Unrealistic Schedule
10. New Technology
Size is Important!
The High Cost of Requirement Errors
Taking your requirements pulse
 Ask yourself how many of the following
conditions apply to your most recent project.
◦ The project's vision and scope are never clearly defined.

◦ Customers are too busy to spend time working with

analysts or developers on the requirements.

◦ User surrogates, such as product managers,

development managers, user managers, or marketers,
claim to speak for the users, but they don't accurately
represent user needs.
Taking your requirements pulse
◦ Requirements exist in the heads of "the experts" in your
organization and are never written down.

◦ Customers claim that all requirements are critical, so

they don't prioritize them.

◦ Developers encounter ambiguities and missing

information when coding, so they have to guess.

◦ Communications between developers and customers

focus on user interface displays and not on what the
users need to do with the software.
Taking your requirements pulse
◦ Your customers sign off on the requirements and then change them
continuously.

◦ The project scope increases when you accept requirements changes,

but the schedule slips because no additional resources are provided
and no functionality is removed.

◦ Requested requirements changes get lost, and you and your

customers don't know the status of all change requests.

◦ Customers request certain functionality and developers build it, but

no one ever uses it.

◦ The specification is satisfied, but the customer is not.

1.1 Software Requirements Defined
 Consultant Brian Lawrence suggests that a
requirement is "anything that drives design choices"
(Lawrence 1997).
 The IEEE Standard Glossary of Software Engineering

Terminology (1990) defines a requirement as

◦ A condition or capability needed by a user/stakeholder 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.
◦ A documented representation of a condition or capability as
in 1 or 2.
1.1 Software Requirements Defined
 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 and Sawyer 1997)

Don't assume that all your project stakeholders share

a common notion of what requirements are. Establish
definitions up front so that you're all talking about the
same things.
Levels of Requirements
 Business Requirements

 User Requirements

 Functional Requirements
Levels of Requirements
Levels of Requirements
 Enterprise/ Business Requirements
◦ represent high-level objectives of the organization or customer
who requests the system.

◦ come from the funding sponsor for a project, the acquiring

customer, the manager of the actual users, the marketing
department, or a product visionary.

◦ describe why the organization is implementing the system—the

objectives the organization hopes to achieve.

◦ recorded in a Vision and Scope document, Project Charter or a

Market Requirements document.
Levels of Requirements
 User Requirements
◦ describe user goals or tasks that the users must be
able to perform with the product.

◦ describe what the user will be able to do with the

system

◦ valuable ways to represent user requirements

include use cases, scenario descriptions and event
response tables.
Levels of Requirements
 Functional Requirements
◦ specify the software functionality that the
developers must build into the product to enable
users to accomplish their tasks, thereby satisfying
the business requirements.

◦ also called behavioural requirements

◦ recorded in a Software Requirements Specification

(SRS).
Levels of Requirements
 System Requirements
◦ Describes the top level requirements for a product that contains
multiple subsystems – that is, a system

◦ A system can be all software or it can include both software and

hardware subsystems

 Business Rules
◦ Include corporate policies, government regulations, industry
standards, accounting practices and computational algorithms

◦ Business Rules are not themselves software requirements because

they exist outside the boundaries of any specific software system
Levels of Requirements
 Software Requirements Specifications Document

◦ Functional requirements are documented in SRS document

which describes as fully as necessary the expected behaviour
of the software system.

◦ Development, Testing, Quality Assurance, Project Management

and related project functions

◦ Non functional requirements- performance goals and

descriptions of quality attributes. They describe external
interfaces between system and the outside world and design
and implementation constraints.
Levels of Requirements
 Quality Attributes
◦ They augment the description of the product’s functionality by describing the
product’s characteristics in various dimensions that are important to users
such as portability, integrity, efficiency and robustness.

 Constraints
◦ Impose restrictions on the choices available to the developer for design and
construction of the product

 Product Features
◦ A feature is a set of logically related functional requirements that provides a
capability to the user and enables the satisfaction of a business objective.

◦ A feature can encompass multiple use cases and each use case requires that
multiple functional requirements be implemented to allow the user to performs
the task
What Requirements Are NOT !

 Software Requirement Specification Don’t

Include following
◦ Design or implementation details
◦ Project Planning Information
◦ Testing Information
◦ Schedule or Budget Limitation
◦ Tutorial Needs
◦ Requirements for releasing the product
Requirements Development &
Management
Requirements Development &
Management
 Requirements Development
◦ Identifying the product's expected user classes
◦ Eliciting needs from individuals who represent each
user class
◦ Understanding user tasks and goals and the
business objectives with which those tasks align
◦ Analyzing the information received from users to
distinguish their task goals from functional
requirements, non-functional requirements,
business rules, suggested solutions, and
extraneous information
Requirements Development &
Management
 Requirements Management
◦ Defining the requirements baseline (a snapshot in
time representing the currently agreed-upon body
of requirements for a specific release)
◦ Reviewing proposed requirements changes and
evaluating the likely impact of each change before
approving it
◦ Incorporating approved requirements changes into
the project in a controlled way
Requirements Development &
Management

◦ Keeping project plans current with the

requirements
◦ Negotiating new commitments based on the
estimated impact of requirements changes
◦ Tracing individual requirements to their
corresponding designs, source code, and test cases
◦ Tracking requirements status and change activity
throughout the project
Requirements Development &
Management
Every project has Requirements
 The hardest single part of building a software
system is deciding precisely what to build.

(Frederick Brooks: No Silver Bullet: Essence

and Accidents of Software Engineering)
When Bad Requirements Happen to
Nice People
When Bad Requirements Happen to
Nice People
 Insufficient User Involvement

 Creeping User Requirements

 Ambiguous Requirements

 Gold Plating

 Minimal Specification

 Overlooked User Classes

 Inaccurate Planning
Benefits from a High-Quality
Requirements Process
 Fewer requirements defects

 Reduced development rework

 Fewer unnecessary features

 Lower enhancement costs

 Faster development
Benefits from a High-Quality
Requirements Process
 Fewer miscommunications

 Reduced scope creep

 Reduced project chaos

 More accurate system-testing estimates

 Higher customer and team member

satisfaction
Requirement Statement Characteristics

 Complete

 Correct

 Feasible

 Necessary

 Prioritized

 Unambiguous

 Verifiable
Requirements Specification Characteristics

 Complete

 Consistent

 Modifiable

 Traceable
Unambiguous Requirement
 A requirement is unambiguous if it has only
one interpretation.

Mary had a little lamb.

Mary had a little lamb
 had - Past of have
 have
◦ 1a: To hold in possession as property
◦ 4a: To acquire or get possession of: OBTAIN (best to be
had)
◦ 4c: ACCEPT; to have in marriage
◦ 5a: To be marked or characterized by (have red hair)
◦ 10a: To hold in a position of disadvantage or certain defeat
◦ 10b: TRICK, FOOL (been had by a partner)
◦ 12: BEGET, BEAR (have a baby)
◦ 13: To partake of (have dinner)
◦ 14: BRIBE, SUBORN (can be had for a price)
Mary had a little lamb
 lamb –
◦ 1a: A young sheep esp. less than one year old or
without permanent teeth
◦ 1b: The young of various other animals (as smaller
antelopes)
◦ 2a: A person as gentle or weak as a lamb
◦ 2b: DEAR, PET
◦ 2c: A person easily cheated or deceived especially
in trading securities
◦ 3a: The flesh of lamb used as food
Mary had a little lamb
Have Lamb Interpretation
1a 1a Mary owned a little sheep under one year of age or
without permanent teeth.
4a 1a Mary acquired a little sheep under one year of age or
without permanent teeth.
5a 1a Mary is the person who owned a little sheep under
one year of age or without permanent teeth.
10a 1a Mary held a little sheep under one year of age or
without permanent teeth in a position of
disadvantage.
10b 1a Mary tricked a little sheep under one year of age or
without permanent teeth.
Mary had a little lamb
Have Lamb Interpretation
12 1b Mary gave birth to a young antelope.
12 2a Mary is (or was) the mother of a particular small,
gentle
person.
13 3a Mary ate a little of the flesh of lamb.
14 2c Mary bribed a small person trading in securities who
was easily cheated.
What is RE Really about?
End
Requirements Development &
Management

◦ Allocating portions of the top-level requirements to

software components defined in the system architecture
◦ Understanding the relative importance of quality
attributes
◦ Negotiating implementation priorities
◦ Translating the collected user needs into written
requirements specifications and models
◦ Reviewing the documented requirements to ensure a
common understanding of the users' stated
requirements and to correct any problems before the
development group accepts them