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 2 / OCTOBER 2008 / EDS INTERNAL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 36 / OCTOBER 2008 / EDS INTERNAL

Requirements Hierarchy - A Journey through the Requirements Lifecycle

by Marie Halsey

Accessibility

Upload Details

Usage Rights

1 Embed 1

Statistics

Requirements Hierarchy - A Journey through the Requirements Lifecycle Presentation Transcript