requirements hierarchy - a journey through the requirements lifecycle

1 / OCTOBER 2008 / EDS INTERNAL

REQUIREMENTS HIERARCHY:A Journey through the Requirements LifecycleMarie Halsey, Sr. Business Analyst

Global Business Analysis Capability

Insert photo here

2 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle

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


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)

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

Determine Scope of Solution

Determine High Level Requirements

Determine Detailed Requirements

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

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

The EDS RDP methodology identifies the following phases when defining requirements for a release:


Business Rules

Statements that define, constrain, or enable a business policy, business process or a detailed requirement.

Requirements Hierarchy – Definitions

High Level Requirements

A collection of statements that identify the breadth of what a solution must provide in order to meet the business needs.


Must meet quality criteria (e.g. unambiguous, testable, etc).

Scope Statement

Identifies the key business features of the proposed solution and the systems, agents and organizations which define the boundaries for the solution.


RDP Phase

Overview of end-to-end business activities, groupings of functions, identification of interfaces, applicable business policies & non-functional constraints.

Detailed functional and non-functional requirements documented with textual statements, Use Cases, data models, interface definitions, etc.

A business rule uses domain-specific vocabulary and can be represented in different formats such as plain language, state diagrams, formulas, and decision trees/tables.

This is the scope of the solution rather than the project scope.

Detailed Requirements


Functional & Non-Functional

A set of detailed declarative statements and models that define what the solution must provide.


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

Scope of Solution



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

The components are not mandatory. Use them where appropriate.


Scope Statement Components

Glossary

Scope Statement

Business Objectives & Goals

Affected Systems, Ops and Orgs

Features & Functions

System Context & Interfaces

Stakeholders

While the primary ownership of the Scope Statement lies with the Project Manager, the BA is the primary contributor to the components shown which are used to drive the High Level Requirements effort. Other components include architecture, risks, and what is OUT of scope.

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


High Level Requirements Components

Glossary


System Interface Requirements

Business Process Model

Functional Requirements

User Interface Requirements

Non-Functional Constraints

Business Policies

Conceptual Business Class Model

Stakeholders

Initial Use Case List


Derive High Level Requirements from Scope

Glossary






Business Policies


High Level RequirementsScope Statement

Affected Systems, Ops and Orgs



Business Objectives & Goals

Stakeholders



Detailed Requirements Components

Glossary



Use Case Model


User I/F Reqts & Prototype

Non-Functional Requirements

Business Rules

Logical Business Class Model & DD

User Descriptions


Derive Detailed Req’ts from High Level Req’ts

Glossary


Business Process Model & Initial Use Case List




Business Policies


Stakeholders

High Level Requirements Detailed Requirements


Use Case Model



Non-Functional Requirements

Business Rules

Logical Business Class Model & DD

User Descriptions


Incremental Refinement




Approved baseline

Approved baseline

Requirements determination is a process of refinement … and iteration

Approved baseline

New increment:

• new release

• new iteration

• change request

What about Agile?


Examples

Scope of Solution



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


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

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

Scope Statement


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.



Business Process: Fulfill Customer Service Installation Request

Drive this to the next level


Evolution - Example #1 (2 of 8)


Business Process: Fulfill Customer Service Installation Request


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

Assign ResourcesThe Engineer selects inventory and installation locations that will fulfill the requested service.

Etc.



Identify initial use cases





Etc.



Components:

• Actors and descriptions

• Detailed Use Cases

• Activity diagrams, as appropriate

• Use Case diagrams

Use Case Model

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



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.

Use Case Model


Order Clerk Create Customer Order

Install Switch Install Router




Etc.





Basic Flow

Detailed Use Case: UCnnn Create Customer Order

Use Case Model


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 Name4 The user specifies the following prospective order information:

a. Service/Product, selected from a list of services/productsb. Primary Service Location (invoke UC Maintain Location Associations)

5. Etc.

1. An order has been successfully submitted for processing (Order Process State is ‘Submitted’).

Post-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).

Pre-Conditions

Order Clerk (a.k.a. the user)Order Management System (a.k.a. the system)

Actor(s)

The Order Clerk enters the Customer Installation Order information and submits the order for processing.

Summary


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:



5. Etc.


Basic Flow


Use Case Model

Detailed Requirements Identify business rules

RULE001: Order and Order Detail StatesRefer 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



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

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’.

Business Rules




Basic Flow


Use Case Model


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:



5. Etc.

RULE001.1: New Order is Prospective.When a new Order is initially created, it is placed into a state of ‘Prospective’.

Business Rules

(RULE001.1 New Order is Prospective)

Include reference to new Business Rule

in the use case


Evolution of a Requirement– Example #2

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

Glossary

Business Objective: Increase repeat business by 25%.

Scope Statement

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


Business Rules

RULE001: Volume DiscountIf 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)

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



Business Rules are not contained in the



Evolution of a Requirement – Example #3 (1 of 3)

Scope Statement


Order SystemMarketing

External to ABC Company

CatalogueInfo

Credit Information

Internal to ABC Company

Financial Institutions

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

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




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

Scope Statement

Order SystemCredit

Information

Financial Institutions



Order System

Credit Rating

XYZ BankCredit Card Validation

Credit Bureau

BankThe XYZ Bank will provide Credit Card Validation services.

Credit BureauThe Credit Bureau will confirm the credit rating of potential customers.





Credit Card Validation1. The system shall provide the following Credit Card information to the Bank:

i. Credit Card Numberii. Expiry Date

2. The system shall receive the following Credit Card Validation information from the Bank:i. Authorized Indicatorii. Authorization Number





Order System XYZ Bank

Credit Card Validation



Guidelines for Requirements

(continued on next slide)

• 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)).

Glossary

• 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)

Scope Statement


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)


• 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)

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

Category /Subcategory Meaning Examples

Term

Derivation

Inference

Nouns in the business and their definition. Terms constrain business concepts and are the building blocks for all other business rules. Note: All business terms should be documented in the Glossary.

A Job is defined as a set of services provided to a Customer, at a specific location, on a specific day.

A special book is one defined as not available in the store’s stock at the time the customer requests to buy it.

Calculations that use terms to arrive at new terms.

Discounted total is calculated as the sum of the prices of all ordered items minus any applicable discounts.

Job Discount = (Job Total x Customer Discount).

Definitions of how knowledge is transformed by operating on terms & facts. Note: may be a mirror image of Glossary term (don’t use both methods for the same business rule)

If customer’s combined purchases are >$999.99 during the last 12 calendar months then customer is considered a loyal customer.

A Customer who has paid for 2 or more Jobs in the prior 12 months is considered a Repeat Customer.


Business Rule Categories (2 of 2)

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

Category /Subcategory Meaning Examples

Fact Necessary connections between terms.

Note: Facts can be documented as natural language sentences, as relationships on a data model, or as attributes of an entity in a data model.

Each estimate must have an Estimated Amount.

Each order must include at least one book.

Constraint Prohibits behaviour or prevents information from being created or action from being taken if certain conditions are not met.

An order must only be paid by one payment method.

A rush order must not be accepted if order payment method is C.O.D.

Action Enabler

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

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


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

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

Glossary

• 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.

Scope Statement

• 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: [email protected] 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

Documents

nonfunctional requirements

evolution of requirements

requirements evolution

requirements questions

requirements lifecycle2

requirements lifecycle3

requirements lifecycle4

requirements lifecycle5