Software

Requirements
Engineering
Requirements management
Managing changes to the requirements baseline
Keeping project plans current with the requirements
Controlling versions of both individual requirements and
requirements documents
Managing the relationships between requirements, and links or
dependencies between individual requirements and other project
deliverables
Tracking the status of the requirements in the baseline

Baseline and Change Management

Project Scope
Project Scope is function of
◦ The functionality that must be delivered
◦ The resources available
◦ The time available

Resources
◦ Mainly human resources
◦ Competition in market place
◦ Shorten our time lines
◦ Adding more people!

Time
◦ Typically fixed
◦ Functionality we can deliver in limited time

How does one manage to reduce scope and keep the customers happy?
Establishing project scope
The purpose of scope management is to establish a high-level
requirements baseline for the project.
We'll define the baseline as
◦ the itemized set of features, or requirements, intended to be delivered in
a specific version of the application.

This baseline for the next release must be agreed to by

◦ the customer and
◦ the development team
Creating baseline
List the features that have been defined for the application
Any new system can be described by a list of 25-99 features
◦ more than that, you are viewing the project at a level of detail
◦ fewer than that, you are viewing the project at a more abstract level

This list provides an itemized, high-level description of the capabilities

of a new or revised system
Features list – an example
Feature 1: External relational data base support
Feature 2: Multi-user security
Feature 3: Ability to clone (same) a project
Feature 4: Port to new operating system release
Feature 5: New project wizard
Feature 6: Import of external data by style
Feature 7: Implement tool tips
Feature 8: Integrate with version-manager subsystem
Priority
Priority
◦ The state of being prior
◦ Given preference

Prioritization by implementation order.

◦ Prioritizing requirements is the requirements task of determining the
implementation order of the requirements in an incremental and
iterative development cycle.

Prioritization by importance
◦ Prioritizing requirements is determining the order of importance to
some stakeholder or class of stakeholders of the requirements along
one or more dimensions (e.g., personal preference, business value,
cost of implementation, and risk).
Setting priorities
Not only understanding User Needs but establishing the
relative priorities for the feature set is integral to scope
management
Who sets priorities?
the customers and users, product managers, or other
representatives — not the development team
Initial priori­tization should be done without too much
influence from the technical community
◦ The level of difficulty in implementing the features will influence
customer priorities
◦ There will be adequate opportunity for technical input at later
phases of the prioritization process
 Example
Feature Priority
Feature 1: External relational database support Critical
Feature 2: Multiuser security Important
Feature 3: Ability to clone a project Important
Feature 4: Port to new OS release Critical
Feature 5: New project wizard Important
Feature 6: Import of external data by style Critical
Feature 7: Implement tool tips Useful
Feature 8: Integrate with version-manager subsystem Useful
Prioritization Techniques
Business Case Analysis / Return On Investment (ROI) estimation
Pair-wise comparisons
◦ Which of two the requirements is more important and to what
extent
Prioritization working groups
Scale of 1-to-10 rankings
Voting schemes
◦ e.g., give each stakeholder a specific number of votes to distribute
amongst the requirements or classes of requirements being prioritized
Weightings
◦ e.g., weight the votes of different stakeholders
Assessing Effort
The next step is to establish the rough level of effort implied by each
feature of the proposed baseline
At this stage there is little information
The question is “To estimate or not to estimate”
The best we can do is to determine a “rough order of magnitude” of
the level of effort
Why can we not allow for a process that creates detailed
requirements and design information for each feature so that we can
create more meaningful estimates?
We cannot afford to invest any resources in these scrap-producing
activities, or we will fail to optimize the resources invested.
Example
Priority Effort

Feature 1 : External relational database support Critical Medium

Feature 2: Multiuser security Important Low

Feature 3: Ability to clone a project Important High

Feature 4: Port to new OS release Critical High

Feature 5: New project wizard Important Low

Feature 6: Import of external data by style Critical Low

Feature 7: Implement tool tips Useful Low

Feature 8: Integrate with version-manager subsystem Useful High

Risk
Another aspect of managing scope is estimating the "risk" associated
with each feature
We need to be aware of the risk associated with each feature so that
intelligent decisions can be made early in the project
Risk to be the probability that the implementation of a feature will
cause an adverse impact on the schedule and the budget
A relative measure of the potential impact
A high-risk feature has the potential to negatively impact the project
Example
Feature Priority Effort Risk
Feature 1 : External relational database Critical Medium Low
Feature 2: Multiuser security Important Low High
Feature 3: Ability to clone a project Important High Medium

Feature 4: Port to new OS release Critical High Medium

Feature 5: New project wizard Important Low Low

Feature 6: Import of external data by style Critical Low High
Feature 7: Implement tool tips Useful Low High
Feature 8: Integrate with version-manager Useful High Low
subsystem
Establishing Baseline

Attribute Consider
Priority: Critical Alarm! Establish immediate risk-mitigation strategy;
Effort: High resource immediately: focus on feasibility with
Risk-: High architecture
Priority: Critical A likely critical resource-constrained item; resource
Effort: High immediately
Risk: Low
Priority: Critical Resource as a safety factor, or defer until later
Effort: Low
Risk : Low
Baseline - Example
Feature Priority Effort Risk
Feature External relational database Critical Medium Low
1:
Feature 4: Port to new OS release Critical High Medium
Feature 6: Import of external data by style Critical Low High
Feature 3: Ability to clone a project Important High Medium

Feature 2: Multiuser security Important Low High

Feature 5: New project wizard Important Low Low
Feature 7: Implement tool tips Useful Low High
Feature 8: Integrate with version-manager Useful High Low
subsystem
Documents
System requirements specification
◦ Defines requirements for the overall "system," including hardware,
software, people, and procedures

Vision document
◦ defines the features of the system in general terms

Product family requirements or Product family Vision document

◦ defines the full set of requirements for a family of products

Business requirements document, or marketing requirements

document
◦ Describes the overall business requirements and business environment in
which the product will reside
Software Requirements Specification
◦ SRS for short
◦ defines requirements in specific terms but for just the software piece
◦ defines the external behavior of the system being built
◦ defines requirements for just one specific application and for one specific
release or a specific release of a specific application within the family
Organizing Requirements
Overall
system
The System requirement
s

System System System

SubsystemSubsystemSubsystem requirement
s spec for
requirement
s spec for
requirement
s spec for
A B C Subsystem Subsystem Subsystem
A B C

SubsystemSubsystemSubsystemSubsystem
A-1 A-2 C-1 C-2
Requirements organization for a software
product family
Vision

SRS Product Family

Vision Document

Common Family Common

Software Requirements Use Case Model

Vision Vision Vision

SRS SRS SRS

HOLIS requirements
Vision

HOLIS 2000
Vision Document

HOLIS 2000
Subsystem Hardware System Level
Specifications Use Case Model

Control Switch Central Control Unit PC Programmer

SRS SRS SRS