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 requirement
Gathering, Analyzing, and Documenting Software Requirements.pptx
Requirements Hierarchy - A Journey through the Requirements Lifecycle
1. 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
2. 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
2 / OCTOBER 2008 / EDS INTERNAL
3. 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?
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
3 / OCTOBER 2008 / EDS INTERNAL
4. 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: A Journey through the Requirements Lifecycle
4 / OCTOBER 2008 / EDS INTERNAL
5. 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.
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
5 / OCTOBER 2008 / EDS INTERNAL
6. 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
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
6 / OCTOBER 2008 / EDS INTERNAL
7. 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
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
7 / OCTOBER 2008 / EDS INTERNAL
8. 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.
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
8 / OCTOBER 2008 / EDS INTERNAL
9. 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
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
9 / OCTOBER 2008 / EDS INTERNAL
10. Derive High Level Requirements from Scope
Scope Statement High Level Requirements
Business Objectives & Goals Business Process Model
Functional Requirements
Features & Functions
User Interface Requirements
System Context & Interfaces
System Interface Requirements
Affected Systems, Ops and Orgs Non-Functional Constraints
Business Policies
Conceptual Business Class Model
Initial Use Case List
Stakeholders
Glossary
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
10 / OCTOBER 2008 / EDS INTERNAL
11. Detailed Requirements Components
Detailed Requirements
Use Case Model
Functional Requirements
User I/F Reqts & Prototype
System Interface Requirements
Non-Functional Requirements
Business Rules
Logical Business Class Model & DD
User Descriptions
Glossary
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
11 / OCTOBER 2008 / EDS INTERNAL
12. Derive Detailed Req’ts from High Level Req’ts
High Level Requirements Detailed Requirements
Business Process Model
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
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
12 / OCTOBER 2008 / EDS INTERNAL
13. 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
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
13 / OCTOBER 2008 / EDS INTERNAL
14. 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
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
14 / OCTOBER 2008 / EDS INTERNAL
15. 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.
High Level Requirements
Business Process Model
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.
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
15 / OCTOBER 2008 / EDS INTERNAL
16. Evolution - Example #1 (2 of 8)
High Level Requirements
Identify initial use
Business Process Model
cases
Business Process: Fulfill Customer Service Installation Request
High Level Requirements
Initial Use Case List
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.
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
16 / OCTOBER 2008 / EDS INTERNAL
17. Evolution - Example #1 (3 of 8)
High Level Requirements
Initial Use Case List
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.
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
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
17 / OCTOBER 2008 / EDS INTERNAL
18. Evolution - Example #1 (4 of 8)
High Level Requirements Drive this to the
next level
Initial Use Case List
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.
Detailed Requirements
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
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
18 / OCTOBER 2008 / EDS INTERNAL
19. Evolution - Example #1 (5 of 8)
Detailed Requirements
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.
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
19 / OCTOBER 2008 / EDS INTERNAL
20. Evolution - Example #1 (6 of 8)
Detailed Requirements Identify business
rules
Use Case Model
Detailed Use Case: UCnnn Create Customer Order
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.
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’.
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
20 / OCTOBER 2008 / EDS INTERNAL
21. Evolution - Example #1 (7 of 8)
Detailed Requirements
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
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
21 / OCTOBER 2008 / EDS INTERNAL
22. Evolution - Example #1 (8 of 8)
Detailed Requirements
Use Case Model
Detailed Use Case: UCnnn Create Customer Order
Basic Flow
1 The user requests that a new Order be created for the selected Customer.
2 The system creates a prospective order. (RULE001.1 New Order is Prospective)
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.
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’.
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
22 / OCTOBER 2008 / EDS INTERNAL
23. 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
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)
Detailed Requirements
Functional & Non-Functional
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)
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
23 / OCTOBER 2008 / EDS INTERNAL
24. 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.
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
24 / OCTOBER 2008 / EDS INTERNAL
25. 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
High Level Requirements
System Interface Requirements
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.
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
25 / OCTOBER 2008 / EDS INTERNAL
26. Evolution - Example #3 (3 of 3) Drive this to the
next level
High Level Requirements
System Interface Requirements
Credit Card Validation
Order System XYZ Bank
Detailed Requirements
System Interface Requirements
Credit Card Validation
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
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
26 / OCTOBER 2008 / EDS INTERNAL
27. 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)
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
27 / OCTOBER 2008 / EDS INTERNAL
28. Guidelines for Requirements (cont’d)
High Level Requirements
• 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.
(continued on next slide)
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
28 / OCTOBER 2008 / EDS INTERNAL
29. Guidelines for Requirements (cont’d)
Detailed Requirements
• 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.
Functional & Non-Functional
• 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).
(continued on next slide)
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
29 / OCTOBER 2008 / EDS INTERNAL
30. 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)
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
30 / OCTOBER 2008 / EDS INTERNAL
31. 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
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
31 / OCTOBER 2008 / EDS INTERNAL
32. 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
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
32 / OCTOBER 2008 / EDS INTERNAL
33. 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
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
33 / OCTOBER 2008 / EDS INTERNAL
34. 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
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
34 / OCTOBER 2008 / EDS INTERNAL
35. 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.
High Level Requirements
• 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.
Detailed 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!!!
REQUIREMENTS HIERARCHY: A Journey through the Requirements Lifecycle
35 / OCTOBER 2008 / EDS INTERNAL