Requirements Hierarchy - A Journey through the Requirements Lifecycle

Insert photo here

REQUIREMENTS HIERARCHY:
A Journey through the
Requirements Lifecycle
Marie Halsey, Sr. Business Analyst
Global Business Analysis Capability

1 / OCTOBER 2008 / EDS INTERNAL

What You Will Learn Today about the:
Requirements Hierarchy

• Understand the
components of
the three levels
of requirements
• Understand the
evolution of
requirements
through each
level
• General
guidelines for
documenting
the content of
each level of
requirements

REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle

Agenda

• The EDS Requirements Determination Process (RDP)
– Requirements Hierarchy – Definitions
– What Requirements are NOT…
• Work Product Components and Derivations
– Scope Statement
– High Level Requirements
– Detailed Requirements
• Evolution of a Requirement
– Three examples
• Guidelines for Requirements
• Questions?


The EDS Requirements Determination Process (RDP)
The EDS RDP methodology identifies the following phases when
defining requirements for a release:

Determine Scope of • Document the boundaries of the
proposed solution and confirm an
Solution understanding of the client’s
business direction

Determine High Level • Document the High Level Requirements
within the approved scope boundaries in
Requirements order to facilitate planning and to bound
the effort to complete the Detailed
Requirements

Determine Detailed • Document the Detailed Requirements in
order to provide a complete, unambiguous
Requirements and verifiable requirements specification to
the product realization teams


Requirements Hierarchy – Definitions
Scope Statement RDP Phase
This is the scope of the Identifies the key business features of
solution rather than the the proposed solution and the systems, Determine Scope of Solution
project scope. agents and organizations which define
the boundaries for the solution.

Overview of end-to-end
business activities, groupings High Level Requirements
of functions, identification of
A collection of statements that identify
interfaces, applicable
the breadth of what a solution must Determine High Level Requirements
business policies & non-
provide in order to meet the business
functional constraints.
needs.

Detailed functional and non-
functional requirements Detailed Requirements
documented with textual
statements, Use Cases, data
Functional & Non-Functional
models, interface definitions,
etc. A set of detailed declarative
statements and models that define
what the solution must provide.
A business rule uses domain-
specific vocabulary and can Must meet quality criteria (e.g. Determine Detailed Requirements
be represented in different unambiguous, testable, etc).
formats such as plain
Business Rules
language, state diagrams,
formulas, and decision Statements that define, constrain, or
trees/tables. enable a business policy, business
process or a detailed requirement.

What Requirements are NOT …
A requirement (high level or detailed) is not:

1. A business objective
“Reduce delinquent accounts to 10% or less, within three months.“
Should be captured in the Scope Statement (Business Objective)

2. A project constraint
“The software must be delivered by March 31st, 2000”
Should be captured in the Project Plan or Statement of Work

3. A statements about “how” the solution will work as opposed to “what” it is
intended to do
“The Location shall be selected from a drop-down list”
Should be captured in the Design documentation


Work Product Components
Let’s have a look at the components of each work product and how
one is derived from the other.

Scope of Solution

High Level
Requirements The components are not mandatory.
Use them where appropriate.

Detailed
Requirements


Scope Statement Components

Scope Statement

Business Objectives & Goals

While the primary ownership of the
Features & Functions Scope Statement lies with the Project
Manager, the BA is the primary
contributor to the components shown
System Context & Interfaces which are used to drive the High Level
Requirements effort. Other
components include architecture,
Affected Systems, Ops and Orgs risks, and what is OUT of scope.

Stakeholders

Usually initiated and maintained by
the BAs, the Glossary will also be
Glossary
referenced by other team’s
deliverables.


High Level Requirements Components
High Level Requirements

Business Process Model

Functional Requirements

User Interface Requirements

System Interface Requirements

Non-Functional Constraints

Business Policies

Conceptual Business Class Model

Initial Use Case List

Stakeholders

Glossary


Derive High Level Requirements from Scope

Scope Statement High Level Requirements

Business Objectives & Goals Business Process Model

Features & Functions

User Interface Requirements

System Context & Interfaces

Affected Systems, Ops and Orgs Non-Functional Constraints

Business Policies

Conceptual Business Class Model


Stakeholders

Glossary


Detailed Requirements Components
Detailed Requirements

Use Case Model


User I/F Reqts & Prototype


Non-Functional Requirements

Business Rules

Logical Business Class Model & DD

User Descriptions

Glossary


Derive Detailed Req’ts from High Level Req’ts
High Level Requirements Detailed Requirements

Use Case Model
& Initial Use Case List

Functional Requirements Functional Requirements

User Interface Requirements User I/F Reqts & Prototype

System Interface Requirements System Interface Requirements

Non-Functional Constraints Non-Functional Requirements

Business Policies Business Rules

Conceptual Business Class Model Logical Business Class Model & DD

Stakeholders User Descriptions

Glossary


Incremental Refinement

Requirements determination is a process of refinement … and iteration

Determine Scope of
Solution

Approved baseline
New increment:
• new release
Determine High Level • new iteration
Requirements • change request

Approved baseline

What
Determine Detailed
Requirements about
Agile?
Approved baseline


Examples
Let’s have a look at three examples of how to evolve requirements
through the requirements determination process.

Scope of Solution

High Level
Requirements

Detailed
Requirements


Evolution of a Requirement – Example #1 (1 of 8)
Scope Statement

Drive this to the
Features & Functions next level

Feature: Service Fulfillment
Provide customers with the ability to request an installation, disconnect or change to communications
services. Provide automated fulfillment, configuration and activation of communications services.



Business Process: Fulfill Customer Service Installation Request

A Customer Service Installation order is created. Available physical resources are assigned and, if insufficient, additional
equipment is ordered from the supplier. Once all necessary equipment is available, it is installed. After installation and
testing is complete, responsibility for the equipment is handed off to Production Support and the order is closed.


Evolution - Example #1 (2 of 8)
Identify initial use
cases

Business Process: Fulfill Customer Service Installation Request



Create Customer Installation Order
The Order Clerk enters a new Customer Installation Order and submits the Order for processing.
Assign Resources
The Engineer selects inventory and installation locations that will fulfill the requested service.
Etc.




Assign Resources
Etc.

Detailed Requirements Initial Use Case List evolves into a
Use Case Model
Use Case Model

Components:
• Actors and descriptions
• Detailed Use Cases
• Activity diagrams, as appropriate
• Use Case diagrams


High Level Requirements Drive this to the
next level

Assign Resources
Etc.


Use Case Model
Order Clerk Create Customer Order
Detailed Use Case: Create Customer Order

The Order Clerk enters a new Customer Installation
Order and submits the Order for processing.

The order consists of one or more order detail lines.
Each detail line pertains to a single service at a single
location for the customer.

Install Switch Install Router



Use Case Model

Detailed Use Case: UCnnn Create Customer Order
Summary The Order Clerk enters the Customer Installation Order information and submits the order
for processing.
Actor(s) Order Clerk (a.k.a. the user)
Order Management System (a.k.a. the system)
Pre-Conditions 1. The user has selected an active customer for whom the order is to be processed (e.g.,
from use case UC View Customer Information).
Post-Conditions 1. An order has been successfully submitted for processing (Order Process State is
‘Submitted’).

Basic Flow

1 The user requests that a new Order be created for the selected Customer.
2 The system creates a prospective order.
3 The system displays the following prospective order information:
a. Customer Name
4 The user specifies the following prospective order information:
a. Service/Product, selected from a list of services/products
b. Primary Service Location (invoke UC Maintain Location Associations)
5. Etc.


Detailed Requirements Identify business
rules
Use Case Model


Basic Flow

2 The system creates a prospective order.
a. Customer Name
5. Etc.

Business Rules

RULE001: Order and Order Detail States
Refer to State Transition Diagram: Order and Order Detail States.
1. New Order is Prospective (RULE001.1)
When a new Order is initially created, it is placed into a state of ‘Prospective’.




Business Rules

Order and Order Detail States (RULE001)
Refer to State Transition Diagram: Order and
Order Detail States.
1. New Order is Prospective (RULE001.1)
When a new Order is initially created, it is placed
into a state of ‘Prospective’.

2. New Order Detail is Prospective (RULE001.2)
When a new Order Detail is initially created, it is
placed into a state of ‘Prospective’.

3. Order is Submitted (RULE001.3)
When an Order is submitted for processing, the
Order and all its associated Order Details are is
placed in a state of ‘Submitted’.

4. … and so on



Use Case Model


Basic Flow

2 The system creates a prospective order. (RULE001.1 New Order is Prospective)
a. Customer Name
5. Etc.

Include reference to
Business Rules new Business Rule
in the use case
RULE001.1: New Order is Prospective.
When a new Order is initially created, it is placed into a state of
‘Prospective’.


Evolution of a Requirement– Example #2

Scope Statement Business Rules are
not contained in the
Business Objective: Increase repeat business by 25%.
High Level
Requirements

Business Policy: Provide discounts to customers with high purchase volumes.

Glossary

Customer: A Customer is a person or organization who purchases products from ABC Company stores.
(Business Rule Type: Term)



The system shall calculate the Total Order Cost (RULE001 Volume Discount).

Business Rules

RULE001: Volume Discount
If a Customer’s previous purchases exceed $1,000 within the last 12 months, subtract 15%
from the Total Order cost.
(Business Rule Type: Action Enabler)


Evolution of a Requirement – Example #3 (1 of 3)
Scope Statement Drive this to the
next level
System Context & Interfaces

Catalogue
Info
Financial
Marketing Order System
Credit Institutions
Information

Internal to ABC Company

External to ABC Company

Marketing
The Marketing system will be the source of record for order catalogue information.

Financial Institutions
Financial Institutions will be used to verify customer credit information.


Evolution - Example #3 (2 of 3) Drive this to the
next level
Scope Statement

System Interface: Financial Institutions will be used to verify customer credit information.

Drive this to the
Financial next level
Order System
Credit Institutions
Information


Credit Card Validation
XYZ Bank
Bank
The XYZ Bank will provide Credit Card Order System
Validation services.

Credit Bureau Credit
The Credit Bureau will confirm the credit Credit Rating Bureau
rating of potential customers.


Evolution - Example #3 (3 of 3) Drive this to the
next level


Order System XYZ Bank



1. The system shall provide the following Credit Card information to the Bank:
i. Credit Card Number
ii. Expiry Date
2. The system shall receive the following Credit Card Validation information from the Bank:
i. Authorized Indicator
ii. Authorization Number


Guidelines for Requirements
Scope Statement

• Must clearly define the boundaries of the proposed solution and confirm an understanding of the
client’s business direction
• Identify business objectives, impacted business processes, all key business features and functions.
• Identify all external agents with which the system must interact, and the key interfaces to each
external agent.
• Explicitly identify out-of-scope areas that might be mistaken as in-scope (avoid confusion!)
(e.g., management of supplier contracts that might be required for equipment purchasing)

Glossary

• One Glossary for the entire project; not specific to a given deliverable.
• Terms/definitions included in the Glossary should NOT be repeated in the Business Rules repository
(e.g., Customer (Term) vs. Repeat Customer (Inference)).

(continued on next slide)


Guidelines for Requirements (cont’d)

• End-to-end business processes should identify key business events and responses.
• Functional requirements should describe the full breadth of the solution functionality, at a high level.
• Identify architecturally critical User Interface requirements (e.g. multi-language, accessibility)
• Identify all reports and forms (brief description of purpose and usage only).
• Ensure all interfaces to external agents are identified.
• Interfaces are not decomposed (e.g. describe Credit Card validation, but no data attributes).
• Identify Business Policies (e.g. corporate policies, industry regulations and standards, government
regulations), but not Business Rules.
• Identify high level non-functional constraints (e.g., Mission-critical operational targets)
• Conceptual Business Class Model - only identify key business data entities (no attributes).
• Initial Use Case List should specify use case name, a brief functional summary, and estimated
difficulty.




• Must be atomic (i.e., cannot be decomposed further)
• Must meet quality criteria (e.g., unambiguous, testable, etc).
• Requirements should be solution and technology independent (unless customer constrains)
• Requirement should reflect final state - do not use words such as 'change this' function to do this,
'add this' to this function, 'increase this to this'. This wording won't be valid in subsequent releases.


• Textual requirements are stated in the imperative (e.g., the system shall…)
• In each interface describe the information flow & key business data transferred, but not to
technical levels of an Interface Specification, such as protocols, message acknowledgements
• Generic exception handling should be documented in the Non-functional requirements.
(e.g., Errors occurring within a process, or key system/application events shall be reported in
the form of system logs.)
• Error messages are typically not documented in the requirements. Ideally, language styles for
information, warning and error messages would be documented in a user interface guidelines
document, after consultation with the client (e.g., the client may have existing messaging
standards).



Use Case Model

• All business processes are supported by use cases
• All users and roles have been represented in use cases
• Use cases focus on user goals and needs – the system must provide a discernable benefit to the
user
• All use cases must be documented with at least the main flow
• Activity diagrams are recommended for complex use cases (e.g. many alternate paths)

User I/F Reqts & Prototype

• Used for requirements elicitation and validation, NOT user interface design
• Keep it SIMPLE!!! Low fidelity is better – it’s important to focus attention on content and flow,
rather than appearance (e.g., exclude widgets, branding).




Logical Business Class Model & Data Dictionary

• The Data Dictionary fully describes all business data entities and attributes, and mappings to use
cases.
• Derived attributes should be documented in the data dictionary. It is up to the Design team to
determine whether the attribute’s value should persist or be derived only when required.
• The Logical Business Class Model describes the relationships between the business data entities
• The Logical Business Class Model does not include operations; these are determined in Design
• Business rule ‘Facts’ are documented in the Class Model.

Business Rules

• Document in a separate repository and reference from Detailed Requirements and Use Cases.
• Each Business Rule must be referenced (i.e. invoked) by one or more detailed requirements.
• Each Business Rule may also be traced to one or more Business Policies in the High Level
Requirements
• Rules are explicit constraints on behaviour and/or provide support to behaviour *
• Rules are not process and not procedure. They should not be contained in either of these. * (i.e.
don’t hide rules in use case steps)

* From the Business Rules Manifesto - http://www.businessrulesgroup.org/brmanifesto.htm


Business Rule Categories (1 of 2)
Category /
Subcategory Meaning Examples
Term Nouns in the business and their A Job is defined as a set of services provided to a
definition. Terms constrain Customer, at a specific location, on a specific day.
business concepts and are the
building blocks for all other A special book is one defined as not available in the
business rules. store’s stock at the time the customer requests to buy
Note: All business terms should be it.
documented in the Glossary.

Derivation Calculations that use terms to Discounted total is calculated as the sum of the
arrive at new terms. prices of all ordered items minus any applicable
discounts.

Job Discount = (Job Total x Customer Discount).

Inference Definitions of how knowledge is If customer’s combined purchases are >$999.99
transformed by operating on during the last 12 calendar months then customer is
terms & facts. considered a loyal customer.
Note: may be a mirror image of
Glossary term (don’t use both A Customer who has paid for 2 or more Jobs in the
methods for the same business prior 12 months is considered a Repeat Customer.
rule)

Source: The Software Requirements Memory Jogger, Ellen Gottesdiener, 2005


Business Rule Categories (2 of 2)
Category /
Subcategory Meaning Examples
Fact Necessary connections between terms. Each estimate must have an
Estimated Amount.
Note: Facts can be documented as
natural language sentences, as Each order must include at least one
relationships on a data model, or as book.
attributes of an entity in a data model.

Constraint Prohibits behaviour or prevents An order must only be paid by one
information from being created or action payment method.
from being taken if certain conditions are
not met. A rush order must not be accepted if
order payment method is C.O.D.

Action Conditions or facts that trigger actions. When a Job Completion Date is > 7
days after the Job Request Date, apply
Enabler 5% discount to the total.

When customer has outstanding
balance > $200, reject new order.

Source: The Software Requirements Memory Jogger, Ellen Gottesdiener, 2005


Key Topics Covered About the:
Requirements Hierarchy

• Components of
the three levels
of requirements
• The evolution
of requirements
through each
level
• General
guidelines for
documenting
the content of
each level of
requirements


Quick Guidelines for Requirements
Scope Statement

• Defines the boundaries of the solution, business objectives, impacted business processes, all key
business features and functions, and interfaces to each external agent.
• Explicitly identifies out-of-scope areas that might be mistaken as in-scope.
Glossary

• One Glossary for the entire project; not specific to a given deliverable.

• Mile-wide, inch-deep coverage of the solution, including reports, interfaces, architecturally critical
user Interface requirements, non-functional constraints and business policies, and initial use cases.


• Atomic, technology independent, using language that reflects the final state
• Use cases provide a discernable benefit to the user; activity diagrams for complex use cases
• Data Dictionary includes derived attributes, and mappings to use cases; Logical Business Class Model
does not include operations
• Business Rules in separate repository and reference; must be referenced (i.e. invoked) by one or more
detailed requirements.
• User Interface prototype used for requirements elicitation and validation; keep it SIMPLE!!!


Questions?

Marie Halsey, CBAPTM
Sr. Business Analyst, Global Business Analysis Capability

EDS, an HP company
Ottawa ON Canada
E-mail: marie.halsey@eds.com or eds.com

EDS and the EDS logo are registered trademarks of Hewlett-Packard Development Company, LP. HP is an equal
opportunity employer and values the diversity of its people. ©2008 Hewlett-Packard Development Company, LP.


Requirements Hierarchy - A Journey through the Requirements Lifecycle

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Requirements Hierarchy - A Journey through the Requirements Lifecycle (20)

Requirements Hierarchy - A Journey through the Requirements Lifecycle