Software Requirements

Engineering

Dr. Faheem Ahmed

Assistant Professor, FET
 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.
 Course Overview

1. Software Requirements: What,

why,who,when and how
2. Requirements Development
3. Requirements for Specific Project Classes
4. Requirements Management
5. Implementing Requirements Engineering
Software Requirements (3rd Edition)
• Karl E. Wiegers
• Joy Beatty

Books
Managing Software Requirements: A Use Case
Approach (Second Edition)
• Dean Leffingwell
• Don Widrig

The Guide to the Business Analysis Body of Knowledge

(Version 3.0)
• International Institute of Business Analysis
 PART 1
Software Requirements: What,
Why,How,When and Who
The Essential Software
Requirement

Chapter 1
 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
 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
 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.
 1.1 Software Requirements
Defined

• Requirements are specific descriptions of the

client’s needs
 Requirements are Not :

• Requirements specifications do not include design or

implementation details (other than known constraints),
project planning information, or testing information
(Leffingwell and Widrig 2000).
• Requirements are independent of design, showing
“what” the system should do, rather than “how” it
should be done.
 Levels of Requirements

• Business Requirements
• User Requirements
• Functional Requirements
• Non-Functional Requirements

In addition, every system has an assortment of

nonfunctional requirements
 Levels of Requirements
• Business Requirements
A high-level business objective of the
organization that builds a product or of a customer
who procures it.
• 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
A goal or task that specific classes of users must be
able to perform with a system, or a desired product
attribute.
• 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
A description of a behavior that a system will
exhibit under specific conditions.
• 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
A top-level requirement for a product that
contains multiple subsystems, which could be all
software or software and hardware
• 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
 Levels of Requirements
• Business Rules
A policy, guideline, standard, or regulation that
defines or constrains some aspect of the business.
Not a software requirement in itself, but the origin of
several types of software requirements.
• 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
• 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

• External interface requirement

• A description of a connection between a software system
and a user, another software system, or a hardware
device.
 Levels of Requirements

• Product Features
• One or more logically related system capabilities
that provide value to a user and are described by a
set of functional requirements.
• 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
 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
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
• 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
 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
• Each requirement must fully describe the functionality to be delivered.

• Correct
• Each requirement must accurately describe the functionality to be
built.

• Feasible
• It must be possible to implement each requirement within the known
capabilities and limitations of the system and its operating
environment

• Necessary
• Each requirement should document a capability that the customers
really need or one that's required for conformance to an external
system requirement or a standard.
 Requirement Statement
Characteristics
• Prioritized
• Assign an implementation priority to each functional
requirement, feature, or use case to indicate how essential it is
to a particular product release.

• Unambiguous
• All readers of a requirement statement should arrive at a single,
consistent interpretation of it, but natural language is highly
prone to ambiguity.

• Verifiable
• See whether you can devise a few tests or use other verification
approaches, such as inspection or demonstration, to determine
whether the product properly implements each requirement.
 Requirements Specification
Characteristics
• Complete
• No requirements or necessary information should be absent.
• Consistent
• Consistent requirements don't conflict with other requirements of
the same type or with higher-level business, system, or user
requirements..
• Modifiable
• You must be able to revise the SRS when necessary and to
maintain a history of changes made to each requirement.
• Traceable
• A traceable requirement can be linked backward to its origin and
forward to the design elements and source code that implement
it and to the test cases that verify the implementation as correct.