Stakeholder Needs and

System Features
Chapter 4
Prepared by: Dr. Hayfa Abu Addous

1
Requirement Pyramid
 Depending on the format, source, and common characteristics, the requirements can
be split into different requirement types. Here are some requirement types that are
often used in projects:
 Stakeholder need: a requirement from a stakeholder (STRQ)
 Feature: a service provided by the system, usually formulated by a business analyst;
a purpose of a feature is to fulfill a stakeholder need (FEAT)
 Use case: a description of system behavior in terms of sequences of actions (UC)
 Supplementary requirement: another requirement (usually nonfunctional) that cannot
be captured in use cases (SUPL)
 Test case: a specification of test inputs, execution conditions, and expected results
(TC)
 Scenario: a specific sequence of actions; a specific path through a use case

2
Requirement Pyramid, Cont.,

3
Requirement Pyramid, Cont.,
 The main difference between needs and features is in the source of the
requirement.
 Needs come from stakeholders
 Stakeholder Requests Document include the needs
 and features are formulated by business analysts.
 The Vision document aims to derive features from stakeholder needs ( can
include the needs if there is not a separate Stakeholder Requests document)
 Use cases are derived from features that describe the system’s functionality.
 Supplementary requirements are derived from features that cannot be captured
in the use cases.
 Scenarios help derive test cases from use cases and facilitate the design and
implementation of specific paths through use cases.
 The role of test cases is to check if use cases and supplementary requirements
are implemented correctly.

4
Requirement Pyramid, Cont.,
 The lower the level, the more detailed the requirement.
For example:
 a need might be “Data should be persistent.”
 The feature can refine this requirement to be “System
should use a relational database.”
 On the supplementary specification level, the
requirement is even more specific: “System should use
Oracle 9i database.”

5
Requirement Pyramid, Cont.,
 One of the best practices of requirements management
is to have at least two different levels of requirement
abstraction.
 For example, the Vision contains high-level requirements

(features), and the lower levels in the pyramid express the

requirements at a detailed level.
 Senior stakeholders (such as vice presidents) do not
have time to read 200 pages of detailed requirements
but should be expected to read a 12-page Vision
document.

6
Traceability between Requirements
 Traceability is a technique that provides a relationship
between different levels of requirements in the system.
 This technique helps you determine the origin of any
requirement.
 requirements in requirement pyramid are traced from the
top level down

7
The Importance of Tractability
Traceability plays several important roles:
Verifying that an implementation fulfills all requirements:
Everything that the customer requested was implemented.
Verifying that the application does only what was requested:
Don’t implement something that the customer never asked
for.
Impact analysis: What elements will be affected when we
consider adding a new requirement or changing an existing
one?
Helping with change management: When some
requirements change, we want to know which test cases
should be redone to test this change.

8
Requirement to Requirement Traceability
 Check that every element is traced to something
 This ensures that all needs and features are in the requirements
 This ensures that there is not a requirement not needed by the
user – gold plating

9
Requirement to Requirement Traceability,
Cont.,
 Every need usually maps to some features. Generally, it is a many-
to-many relationship because one need can trace to many features,
but one feature may be derived from many needs. One need
mapping to one feature is also a common case.
 The features map to use cases in a many-to-many relationship.
 The features also map to supplementary requirements in a many-to-
many relationship.
 Every use case maps to one or more scenarios, so a one-to-many
relationship exists between use cases and scenarios.
 Scenarios map to test cases in a one-to-many relationship.

10
An Overview of the Requirements
Management Process
 We learned before that Requirements management is a systematic
approach to eliciting, organizing, and documenting the requirements
of the system.
 A simplified description of the requirements management process
contains the following major steps:
n Establishing a requirements management plan (RMP)
n Requirements elicitation
n Developing the Vision document
n Creating use cases
n Supplementary specification
n Creating test cases from use cases
n Creating test cases from the supplementary specification
n System design

11
Requirements Management Process
 The first step (requirements management plan) defines
the requirements pyramid.
 In each of the next seven steps, one of the elements of
the pyramid is built.

12
Requirements Management Process,
Cont.,
 Requirements management is an interactive process.
 In a typical iteration, a full pass through the pyramid is performed.
Even in the same iteration, we can go back a few steps and repeat
the activity.
 For example, during the creation of a test case, we can discover
that some information is missing, and we need more input from a
stakeholder, so we go back a step to “gathering requirements.”
 To maintain the model’s integrity, it is important to update all
affected requirements.
 In initial iterations the emphasis is placed on the first few steps (the
top of the pyramid), and in later iterations more time is spent on the
lower part of the pyramid.

13
The Features of a Product or System
Chapter 9 in the Textbook

14
Problem Domain & Solution Domain

Needs
– in user
terms Problem Domain

Features – a
service provided
by the system that
fulfills a need

Software requirements
– more specific Solution Domain

15
Needs and Features Documents
 Stakeholder Needs and Features are included in the
Vision document.
 Sometimes we include the needs in a separate
document such as “Stakeholder Requests Document”

16
Stakeholder and User Needs
 Definition: a reflection of the business, personal, or
operational problem (or opportunity) that must be
addressed in order to justify consideration, purchase, or
use of a new system.
 Examples:
 I need easier ways to understand the status of my inventory
 I’d like to see a big increase in the productivity of sales order
entry
 In RequisitePro we call the need “Stakeholders
Requests” and refer to it by STRQ.

17
Features
 Definition: a service the system provides to fulfill one or more
stakeholder needs
 Sometimes in talking to users, they will discuss features not needs
and can be hard to distinguish between them
 Features are a convenient way to describe the functionality without
getting bogged down in detail
 Features are at a high level of abstraction
 It is important to keep track of which feature was derived from which
request, so they could be traced to the features implementing them.
 In Requisite Pro we refer to a feature as FEAT.
 Usually features are one of the main requirements in the project, but
if the user can express all requirements in the form of use cases
(UC), features may not be necessary.(page 37)

18
Examples of Features
Application Domain Example of a Feature
Elevator control system Manual control of doors during fire
emergency
Inventory control system Provide up-to-date status of all inventoried
items
Defect tracking system Provide trend data to assess product
quality
Payroll system Report deductions-to-date by category

Home lighting automation Vacation settings for extended away

system (HOLIS) periods
Weapon control system Minimum of two independent confirmations
of attack authorization required
Shrink-wrap applications Windows XP compatibility

19
Managing Complexity
 Limit features to somewhere between 25-99 to avoid getting in
the details (preferred<50)
 Any more than 50 is probably too much detail
 Any less than 25 is probably not enough
 Add attributes (properties) to the features to track additional
information
 Example attributes:
 Name or Unique identifier
 Sponsor
 History data
 Allocated from
 Traced to
 Priority

20
Features Attributes
 For example, the attribute priority could be used to
capture the results of the cumulative voting in a
brainstorming session.
 the attribute version number might be used to record the
specific software release in which we intend to
implement a specific feature.
 No limit to the types of attributes you might find useful.
 However, experience has demonstrated that some
common attributes for features apply to most project
circumstances

21
Features Attributes , Cont.,
 Attributes can be either list-type (identified by the sets of predefined
descriptive values such as High, Medium, and Low) or entry-type
(text, time, date, numeric integer, numeric real).
 The default attributes of features in RequisitePro are as follows

(Page. 111):
 Priority (usually used to determine order of implementation)
 Status (tracks the progress of requirement development—Proposed,
Approved, Incorporated, and Validated)
 Difficulty (how difficult is implementing this requirement—the default
values are High, Medium, and Low)
 Stability (the probability that the feature will not change during the
project)

22
Features Attributes , Cont.,
 Risk (the probability of issues related to this requirement—problems
with implementation, missing deadlines, and so on)
 Planned iteration (for example, E1—the first iteration in the
Elaboration phase)
 Actual iteration
 Origin (source of the requirement)
 Contact Name (usually the person responsible for this requirement)
 Enhancement Request
 Defect
 Author
 Location (in which document it resides)

23
Features Attributes , Cont.,
 This list may vary depending on the version of
RequisitePro.
 Very often we need to add attributes.
 We may want to have an attribute Importance, because
it is not the same as Priority. It may help to manage the
scope in case of delays. Values that can be used include
Mandatory,Desirable, and Nice to have.
 Described attributes may be used not only for features,
but also for other requirements (such as use cases and
supplementary requirements).

24
Other possible attributes (Textbook Table
9-2)
Attribute Description

Status Tracks progress during definition of the project

baseline and subsequent development. Example:
.Proposed, Approved, Incorporated status states
Priority/benefit Assists in managing scope and determining
priority. All features are not created equal.
Ranking by relative priority or benefit to the end
user opens a dialogue between stakeholders and
members of the development team. Example:
.Critical, Important, Useful rankings

Effort Helps establish realistic schedules, goals, and

costs. Estimating the number of team- or person-
weeks, lines of code or function points, or just the
general level of effort helps set expectations of
what can and cannot be accomplished in a given
time frame. Example: Team months, or Low,
.Medium, High levels of effort

25
Other possible attributes, Cont.,
Risk Indicates a measure of the probability that
the feature will cause undesirable events,
such as cost overruns, schedule delays, or
even cancellation. Example: High, Medium,
.Low risk level
Stability Reflects a measure of the probability that
the feature will change or that the team's
understanding of the feature will change.
This attribute helps establish development
priorities and determine those items for
which additional elicitation is the
appropriate next action. Example: High,
.Medium, Low stability

Target release Records the intended product version in

which the feature will first appear. When
combined with the Status field, your team
can propose, record, and discuss various
features without committing them to
.development. Example: Version 2.3
26
Other possible attributes, Cont.,
Assigned to Indicates who will be responsible for
implementing the feature. In many
projects, features will be assigned to
"feature teams" responsible for further
elicitation, writing the software
requirements, and perhaps even
.implementation
)Contact Name in RequisitePro(
Reason Helps track the source of the requested
feature. For example, the reference
might be to a page and line number of a
product specification or to a minute
marker on a video of an important
customer interview.

27
Problem of Project Scope
 Project scope is a function of…
 The functionality that must be delivered to meet the user’s
needs
 The resources available to the project
 The time available in which to achieve the implementation

28
Problem of Project Scope
 Resources – primarily labor
 Brooks [1975] demonstrated that adding resources to a software
project is risky and would most likely hurt the schedule
 You can not make a baby with 9 women in one month
 Time
 Sometimes time is fixed – i.e. tax software
 Assume both resources and time is fixed, the scope is
depicted as the area of the box.
 Achievable scope – when the effort required to
implement the system features is equal to the resources
available during the scheduled time
Resources

Scope

Time Deadline 29
The Requirements Baseline
 Requirements baseline definition
 The itemized set of features intended to be delivered in a
specific version of the application.

30
Setting Priorities
 After all, if we could do all the work, the prioritization would be
unnecessary.
 If we can't do all the work, we still haven't figured out how much we
can do, and therefore, we do not yet know where to draw the
baseline for the project.
 Let users set the priorities not the development team.
 Priority—High: Must be implemented no later than in the first
iteration of the Construction phase.
 Priority—Medium: Must be implemented no later than by the end of
Construction.
 Priority—Low: May be implemented if time permits.
 Sometimes we use (critical-important-useful) scale instead of (high-
medium-low).

31
 Assessing Effort
 Establish the rough level of effort implied by each feature
of the proposed baseline
 Rough Order of Magnitude – ROM
 Include the development team in the estimate
 Use past project if possible
 Use expert judgment
 Do this early in the project to understand at a high level
the scope
 Delaying this until later may mean that some analysis is wasted
when it is found out that this is 200% of what can be done

Rough Order of Magnitude – ROM : An estimate of costs and time provided in the early stages of a
project when its scope and requirements has not been fully defined

32
Assessing Effort, Cont.,
Let's assume that the product or project manager is the champion for
our project and has the following dialogue with the developers for the
project
PRODUCT MANAGER: How difficult is this feature to do?
DEVELOPMENT TEAM: We don't know. We don't have any
requirements or design yet.
PRODUCT MANAGER: I respect that, but is it the easiest thing
we've ever done?
DEVELOPMENT TEAM: No.
PRODUCT MANAGER: OK, is it the most difficult feature on the
list?
DEVELOPMENT TEAM: No.
PRODUCT MANAGER: On a scale of low-medium-high, we'll
give it a medium. OK?
DEVELOPMENT TEAM: OK. Medium it is.
PRODUCT MANAGER: OK, on to the next feature.
33
Risk
 Risk in this context
 Probability that the implementation of a feature will cause an
adverse impact on the schedule and/or budget
 Can also think of this as uncertainty of the estimate
 Risk Mitigation
 No need to mitigate all risks
 But if a feature is of high risk and critical priority…then risk
mitigation is a must
 Risk—Technology High: such as using a new technology with which
the team does not have any experience.
 Risk—Technology Low: such as using a well-known technology with
which the team has a lot of experience.
 Sometimes we use the scale( high, medium, low) instead of (high,
low)

34
Example: Shrink-wrapped Software Product.
Prioritized Features List with Effort and Risk Estimates
Feature Priority Effort Risk
1. External relational database Critical Medium Low
support
4. Portability to a new operating Critical High Medium
system release
6. Import of external data by style Critical Low High

3. Ability to clone a project Important High Medium

2. Multi-user security Important Low High

5. New project wizard Important Low Low

7. Implementation of tool tips Useful Low High

8. Integration with a version- Useful High Low

manager system
35
Managing Your Customer
 Engage customers to manage their project scope
 A customer who is part of the process will own the result
 Communicate the result
 Never surprise the customer or wait until the last minute to deliver bad
news
 Negotiate with the customer
 Try to put yourself in the position to under-promise and over-deliver
 Manage the baseline
 Official Changes
 High level features added or changes, impact must be assessed and more
time given or reprioritization if necessary
 Unofficial Changes
 Internal to the development team and must be managed like any other
change

36
User’s Bill of Rights
 The user is always right. If there is a problem with the use of the system,
the system is the problem, not the user.
 The user has the right to easily install and uninstall software and hardware
systems without negative consequences.
 The user has a right to a system that performs exactly as promised.
 The user has a right to easy-to-use instructions (user guides, online or
contextual help, and error messages) for understanding and utilizing a
system to achieve desired goals and recover efficiently and gracefully from
problem situations.
 The user has a right to be in control of the system and to be able to get the
system to respond to a request for attention.

37
User’s Bill of Rights
 The user has the right to a system that provides clear, understandable, and
accurate information regarding the task it is performing and the progress
toward completion.
 The user has a right to be clearly informed about all system requirements
for successfully using software or hardware.
 The user has a right to know the limits of the system's capabilities.
 The user has a right to communicate with the technology provider and
receive a thoughtful and helpful response when raising concerns.
 The user should be the master of software and hardware technology, not
vice versa. Products should be natural and intuitive to use.

38
Key Points
 The development team must play a more active role in
eliciting the requirements for the system
 Product or system features are high-level expressions of
desired system behavior
 System features should be limited to 25-99, with fewer
than 50 preferred
 Attributes provide additional information about a feature

39