Requirements Process Requirements Process Traceability and Associations Use Case Model

BSA is responsible for IT requirements 3 4 5 The focus is always on the user and what the system
Roles and Scope Requirements traceability
BA is responsible for business process changes and all non- Scope Requirements Requirements
associations
can do for them, not on the design of the system or its
Responsibilities
system requirements. No handoff from BA to BSA post Gate 3 Requirements Plan inner workings
Business BA
Analysis Joint BA and BSA Plan Scope
Req’s Business BSA Business
A Use Case
Planning and Iterations (breadths or depths) through requirements Business Use Case Non-
Monitoring
Business
Process
Implementation
Implementation
Process Functional - represents a sequence of actions a system
Model Model
Shared performs that yields an observable result of value
Emphasis on workshops instead of only interviews
Elicitation Core Team (BA, BSA, Business, Tech Lead, QA Lead) attend Scope Use Case Data Rules User Project to the business.
workstream workshops Iteration Model Interface Doc - models the dialogue between an automated
Requirements Tools like Problem Opportunity Analysis (in the High Level Non- User Business Data system and those who use it.
Functional Catalogue Interface Rules
Analysis Requirements), Use cases for System Requirements
Model
Requirements validation through small incremental reviews Scope Impact
Detailed Requirements Iterations
System
Iteration
Requirements - The System, or the subject is the visual
Single Requirements Package, replaces BRD and SRS
Management & Requirements Package representation of the scope of the automated
Captured once with structured catalogues
Communication system.
PC DOU CTD
Solution Small incremental reviews per work stream Scope BOA FPP - Review the business process map – system swim
Assessment and Core Team (BA, BSA, Business, Tech Lead, QA Lead) attend lane will include the scope of the system (s)
Validation workstream reviews participating in the end-to-end process.
- Identify one system per diagram.
How it All fits together Complete System Requirements - Do not distinguish between system UI, services,
Use Case Model middle tier, or database as long as you are talking
Benefits
System
about a single application.
Use Case 1
Presentation Description Detail
System Context
- Ability to see the “big picture”, as well as
System Description
- the business value of individual requirements - Describes the system from the user’s view point
Rules Use Case 1 - the context of individual requirements - Executive summary, do not refer to specific
List of - the relationship among requirements
Actors and Use Case 2 project
- Data, Business rules and presentation requirements are seen as support
Process Description Use Case 2 Detail
mechanisms for the user-system interaction
The interaction between the system and user, other systems, or between the Actors
users to achieve a goal – Who? When? Where? Actor Actor - Represent a party that is external to the
Rules Use Case 3 Maintainability: “one fact in one place”
List of Use automated system and that has direct interaction
Logic the system or business worker follows to achieve a goal – Why? Cases and Use Case 3 - Actors may be (a) Humans (b) Other systems (c)
Data Description Detail Reusability
- Use Cases document the complete future state of the system, not just the
Schedule
Information used in the process of achieving a goal – What? - Are identified by the nature of interaction
delta like plain text requirements do.
User Interface - Typically, the more actors the system interacts
Application navigation, content presentation and user assistance when using the
system to achieve a goal. Future Proofing with, the bigger the scope is.
Non-Functional Requirements - Descriptions do not refer to specific technologies or implementation - An actor that is a system may itself by the Subject
Non-
Non- details, so if these things change, the documentation is still valid. in another Use Case Diagram
Quality of service characteristics of the system Business User
Data Functional
Functional
Business Implementation Requirements Catalogue
Rules Interface
Req’
- Primary Actor initiates Use Case and is drawn on
Catalogue Catalogue Req’
Project non-automated requirements for business groups not including IT Catalogue
Catalogue the left of the subject (can be multiple)
- Secondary Actor interacts with Use Case once its
initiated and is drawn on the right of the subject
(can be multiple)
System Description: ATM System is an application used by ATM terminals. It allows ATM users to Use Case Detail - The same actor maybe a primary actor for one
Use Case Diagram - Example perform financial and other transactions on their accounts at the ATM Terminal Use Case and secondary for another
Step-by-step description of system response to actor actions and other detailed - Use Cases that describe batch processes will be
Use Case Diagram – List of Actors and Description
Automated Teller Systems system requirements, consists of: initiated by the actor Schedule (time)
Modified by - Use case description
Actor Name Description
Deposit Project - Primary and Secondary actors
Funds ATM User A person who accesses the ATM to perform financial transaction 1111-11 - Trigger: Is the actor’s request for a service from the system that initiates the use case (Trigger Use Case
A system that is a source and a destination for client, account is a requirement) - Use Cases describe how system behaves in
Bank System 1111-11
Withdraw and transaction information - Use Case Flows: Represents all interactions between the actor and the system to achieve the response to a request for service from an actor.
ATM User Funds Bank System A person who receives reports. This role can be played by goal, documented as a numbered sequence of steps, each one representing a distinct action
Report Receiver 1111-11 - In Use Case Diagram (UCD), the entire
Branch manager performed by the system or actor.
- Basic flow: Represents the error and exception free execution of the Use Case when functionality provided by the system is
Pay Bill Use Case Diagram – List of Use Cases and Description everything is working as planned (normal functioning business situation). represented by all identified Use Cases.
Use Case Modified Use Case - Alternative flows: Is any variation to the basic flow, it can start from basic flow or another - In UCD, each Use Case symbol represents
ID Use Case Description alternate flow (and returns to calling basic / alternate flow)
Generate Name by Project Exists (Y/N) complete end-to-end automated process, not the
Report - Pre-conditions: Documents the testable state of the system that must be true for the Use
Schedule Report Receiver This Use Case describes a process where the ATM Case to begin (not all Use Cases have pre-conditions and UC’s do not dependent on each other) steps in the process.
UC001
Withdraw user withdraws cash from their account. After the
1111-11 Y - Post-conditions: Describe the testable state of the system that must be true following the - Expressed as a verb-noun pair using business
Cash withdrawal, the ATM posts the transaction to the completion of a Use Case (they may serve as pre-conditions for another UC) language.
Bank System, which updates the user’s account.
- References to Data, Business Rules and System to User Messages - Each Use Case must provide business value to at
least one actor when using the system.
 Use Case Flows Preconditions User Interface List and Map
Basic Flow - ATM User has been authenticated with the ATM System ID UI Name UI Description Modified by Project UID Exists
- All user accounts are known to ATM System
Steps Trigger Alternative Flow / Data / Message / Business Rule This is the home page where clients enter the
UI001 Welcome 1111-11 Y
1. This Use Case begins when ATM User requests to withdraw cash application
Post Conditions
2. System prompts for withdrawal cash information DS001 – Withdrawal Cash Info - Cash has been dispensed
Welcome Request Assistance
3. ATM User provides withdrawal cash information and requests to proceed - ATM User’s account has been updated with withdrawal transaction information
- Transaction receipt has been printed to ATM user
DS001 – Withdrawal Cash Info
4. System successfully validates information provided Search View Account Details
AF001 – Invalid User Input
BR001 – Determine sufficient funds in ATM Related Artefacts
5. System successfully validates sufficient funds in ATM.
AF002 – Insufficient funds in ATM - Use Cases only tell the process part of the story
6. [other steps] - Use Cases require Business Rules, Data, Messages to be complete
View Client Profile View Offers
- Use Cases must be represented in the Use Case Diagram
7. Use Case Ends
Component name Location / Link
Use Case Diagram Use Case Diagram(sample).doc Update Client Profile Action Offer

Data Catalogue Data (sample).xls

Alternate Flow Business Rules Catalogue Business Rules (sample).xls
AF1 – Invalid User Input Message User Interface Catalogue (sample).xls Storyboard List and Storyboards
Steps Alternative Flow / Data / Message / Business Rule Storyboard Modified
ID Storyboard Description Use Case ID
1. This flow starts at step 4 of basic flow when system determines that Name by Project
information provided by user is invalid RBC Standard Verb Dictionary Update Client Employee updates client profile UC001 – Manage client profile
SB001 1111-11
User English Use Case Profile Success successfully – Basic Flow
2. System informs user that information provided is invalid MSG001 – Invalid User Input
User Wants to, clicks on next / starts / conitnue Requests Update Client UC001 – Manage client profile
3. The flow resumes at step 2 of basic flow Employee attempts to update client
Selects, clicks on selection menu, picks, opts Chooses SB002 Profile – Invalid – Basic Flow, AF1 – Invalid User 1111-11
profile but has user input errors
User Input Profile
Types, Enters Provides
Looks, Views Reviews Storyboard – Update Client Profile
Referencing Business Rules
System Requests User to Enter Prompts
- Some steps of a Use Case flow requires the System to make a decision or apply some logic UI001 - Welcome UI004 - Search UI005 – Client Profile
Runs Validation, Checks Validates
- Use Case documents the step of applying the logic and the reference to the Business Rule
- A Business Rule defines the reasons and the logic behind these system actions Maps, Generates Calculates
Searches for Retrieves UI007 - Update Client Profile
Business Rules Catalogue
ID Rule Name Description Modified by Project Sends, Submits, Generates Provides
Creates, Populates Adds
Determine sufficient funds Sufficient funds in ATM is True when DE010-Amount in ATM is equal to User Interface Design and Component Table
BR001 1111-11 Modifies, Populates Updates
in ATM or greater than DE004-Transaction Amount using DE012-Currency
Deletes Removes Order Entry - Status
Determine transaction
BR002 Transaction is accepted when DE009-Transaction Status is “Accepted” 1111-11 Determines Determines
acceptance
Account ID: 123456789 Symbol
Prints Prints Type: RRSP Quantity
Stores, Saves, Updates DB Retains
Account Summary Transaction Buy
Cancels Cancels
Referencing Data Buying Power $25,000 CAD Order Type
Prepares Prepares
- Some steps of a Use Case flow require use of Data business information, or Data
- Use cases indicate the use of Data by referring to Data Sets. Displays, Shows Presents Preview Quote
- Use Case documents the step of using the data and the reference to the Data Set
- Data Set defines all the Data Elements used in the step and the details about them Comp Component Component Displayed Enabled
Label English DE ID DE Name
ID Name Type Y/N/condition Y/N/condition
Data Catalogue User Interface Model Screen Order Entry -
DE Valid Multiple Mandatory User modifiable Mapping / Data DS001 – - Is application navigation, content presentation, and user assistance when using the 1 N/A N/A Text Y Y
ID Description Name Stocks
Name values Y/N/condition Y/N/condition Y/N/condition calculation rules Source ATM info. system to achieve a goal
Account Account
Amount The amount of ATM - Supplements Use Cases, Business Rules, Data, and Messages by providing application 2 Account ID DE009 Data Display Y Y
DE010 N Y N Y x Number Number
in ATM cash in ATM System look, feel, and navigation
- Consists of
Default Value Presentation format Help (message ID) Tab Order User Action System Response
Currency of ATM - An inventory of all screens in application User Interface List
DE012 Currency CAD N Y N Y x
transaction System - Navigation between screens in application UI Relationship Map
- Instances of Use Case realization in screens in application Storyboard List and N/A N/A N/A N/A N/A N/A
Storyboards
- Screen / report image and description in application User Interface Design set N/A 999999999 N/A N/A N/A N/A
Referencing System to User Messages User Interface is a Use Case realization in presentation format which can be visual or
auditory
- Some steps of a Use Case flow requires the system to communicate with users via System to Messages. Message types are User Interface and Use Cases are linked through Storyboards Messages
informational, warning, or error.
- Use Case documents the step of presenting the Message to the user and the reference to the Message. Messages are stored in the ID Name Type Message Description English Text French Text
User Interface Model. Storyboards
- is an order of screens realizing a Use Case scenario Inform user that their Account does not Le Compte ne contient
Insufficient
- explicitly refers to Use Case scenario by listing the Use Case flows the scenario MSG00 account does not contain contain sufficient pas les fonds suffisants
funds in Error
includes 4 sufficient funds to process funds to process pour traiter votre
account
- will be multiple per Use Case – need to create for majority of viable scenarios request your request demande