requirements hierarchy - a journey through the requirements lifecycle
DESCRIPTION
How do you get from “We need something different” to detailed requirements? What do requirements look like as they evolve through the phases of the requirements lifecycle? What are the deliverables in each phase? This presentation discusses three phases of requirements definition – Scope, High Level Requirements and Detailed Requirements. The components of the deliverables in each phase are described, examples of the evolution of requirements through the lifecycle phases are presented, and guidelines for each deliverable are provided. Learning Objectives: • Understand the components of the three levels of requirements – Scope, High Level Requirements and Detailed Requirements. • Understand the evolution of requirements through each level. • Guidelines for each level of requirementTRANSCRIPT
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
3 / OCTOBER 2008 / EDS INTERNAL 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?
4 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
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:
5 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
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.
Determine High Level Requirements
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.
Determine Scope of 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
Determine Detailed Requirements
Functional & Non-Functional
A set of detailed declarative statements and models that define what the solution must provide.
6 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
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
7 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
Work Product Components
Scope of Solution
High Level Requirements
Detailed Requirements
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.
8 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
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.
9 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
High Level Requirements Components
Glossary
High Level Requirements
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
10 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
Derive High Level Requirements from Scope
Glossary
System Interface Requirements
Business Process Model
Functional Requirements
User Interface Requirements
Non-Functional Constraints
Business Policies
Conceptual Business Class Model
High Level RequirementsScope Statement
Affected Systems, Ops and Orgs
Features & Functions
System Context & Interfaces
Business Objectives & Goals
Stakeholders
Initial Use Case List
11 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
Detailed Requirements Components
Glossary
Detailed Requirements
System Interface Requirements
Use Case Model
Functional Requirements
User I/F Reqts & Prototype
Non-Functional Requirements
Business Rules
Logical Business Class Model & DD
User Descriptions
12 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
Derive Detailed Req’ts from High Level Req’ts
Glossary
System Interface Requirements
Business Process Model & Initial Use Case List
Functional Requirements
User Interface Requirements
Non-Functional Constraints
Business Policies
Conceptual Business Class Model
Stakeholders
High Level Requirements Detailed Requirements
System Interface Requirements
Use Case Model
Functional Requirements
User I/F Reqts & Prototype
Non-Functional Requirements
Business Rules
Logical Business Class Model & DD
User Descriptions
13 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
Incremental Refinement
Determine Scope of Solution
Determine High Level Requirements
Determine Detailed Requirements
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?
14 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
Examples
Scope of Solution
High Level Requirements
Detailed Requirements
Let’s have a look at three examples of how to evolve requirements through the requirements determination process.
15 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
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
Features & Functions
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.
High Level Requirements
Business Process Model
Business Process: Fulfill Customer Service Installation Request
Drive this to the next level
16 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
Evolution - Example #1 (2 of 8)
High Level Requirements
Business Process: Fulfill Customer Service Installation Request
Business Process Model
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.
Initial Use Case List
High Level Requirements
Identify initial use cases
17 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
Evolution - Example #1 (3 of 8)
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.
Initial Use Case List
High Level Requirements
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
18 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
Evolution - Example #1 (4 of 8)
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
Detailed Requirements
Order Clerk Create Customer Order
Install Switch Install Router
Drive this to the next level
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.
Initial Use Case List
High Level Requirements
19 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
Evolution - Example #1 (5 of 8)
Basic Flow
Detailed Use Case: UCnnn Create Customer Order
Use Case Model
Detailed Requirements
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
20 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
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.
Evolution - Example #1 (6 of 8)
Basic Flow
Detailed Use Case: UCnnn Create Customer Order
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
21 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
Evolution - Example #1 (7 of 8)
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
Detailed Requirements
22 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
Evolution - Example #1 (8 of 8)
Basic Flow
Detailed Use Case: UCnnn Create Customer Order
Use Case Model
Detailed Requirements
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.
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
23 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
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.
High Level Requirements
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).
Functional & Non-Functional
Detailed Requirements
Business Rules are not contained in the
High Level Requirements
24 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
Evolution of a Requirement – Example #3 (1 of 3)
Scope Statement
System Context & Interfaces
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.
Drive this to the next level
25 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
Evolution - Example #3 (2 of 3)
System Interface: Financial Institutions will be used to verify customer credit information.
Scope Statement
Order SystemCredit
Information
Financial Institutions
System Interface Requirements
High Level Requirements
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.
Drive this to the next level
Drive this to the next level
26 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
Evolution - Example #3 (3 of 3)
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
System Interface Requirements
Detailed Requirements
System Interface Requirements
High Level Requirements
Order System XYZ Bank
Credit Card Validation
Drive this to the next level
27 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
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
28 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
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.
High Level Requirements
(continued on next slide)
29 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
Guidelines for Requirements (cont’d)
• 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).
Functional & Non-Functional
Detailed Requirements
(continued on next slide)
30 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
Guidelines for Requirements (cont’d)
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).
(continued on next slide)
31 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
Guidelines for Requirements (cont’d)
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
32 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
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.
33 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
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.
34 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
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
35 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
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.
High Level Requirements
• 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!!!
Detailed Requirements
36 / OCTOBER 2008 / EDS INTERNAL REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
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.