# Presentation: 299687

## Use Case Driven Requirements Analysis for Large Scale Business System Development Second Annual Census SEPGConference April 27-28, 2004 Frank ArmourArmourIT, LLCfrank.armour@brambleton.net

## Introduction to Use Case Driven Requirements Analysis

- Are use cases sufficient to capture all the requirements, or are other requirement types needed on a large-scale development?
- How do uses cases “fit” with other forms of requirements?
- How should use cases be described and structured for a large-scale iterative development process?
- A process for creating and maintaining use case models in a framework that can be fully customized for your organization will also be discussed.

## Introduction to Requirements Analysis and its Artifacts

## Characteristics of Today's Information Technology Based Systems

- Large, complex, critical applications
- Systems are long-lived
- Must change based on rapidly changing business and technology conditions
- Many internal and external interfaces
- Are “System of Systems”
- Must be enterprise wide - migrate across platforms- Processor and location independent

## “As an Industry, we are not doing a very good job at IT system development .”(Standish Group, 1995)

- Of all US IT projects only 16% come in on-time, on-budget, and with all features.
-  30% of software projects are canceled before completion.
-  Average project comes in approximately 3 times projected budget and 3 times beyond projected delivery schedule!

## “Major problem sources in two thirds of systems examined...” [GAO 92] 
“Survey of large aerospace firms identified requirements as most critical software development issue...” [Faulk 92] 
“Study of industry projects shows that requirements errors are the most costly...” [Boehm 81] 

- “Survey of large aerospace firms identified requirements as most critical software development issue...” [Faulk 92]
- “Study of industry projects shows that requirements errors are the most costly...” [Boehm 81]

***Studies Consistently Identify Poor Requirements as Major Cause of Project Failure***

## Requirements Analysis Key to Successful Development

- “The hardest single part of building a software system is deciding what to build. ...No other part of the work so cripples the resulting system if done wrong.  No other part is more difficult to rectify later.”
- - Fred Brooks, _No Silver Bullet:  Essence and Accidents of Software Engineering_

## Characteristics of Large Business Systems Include

- Large diverse set of requirements
- Many complex business rules
- Significant user and system interaction
- Many reporting needs
- Complex, horizontal, cross organizational business processes
- Many data requirements

## Requirements are Defined at Different Levels

**Business Needs**

**System  Level **
**Requirements**

**Release Level **
**Requirements**

- What are the objectives/goals
- of the business?

- What does system have to do
- to meet the business’ requirements?

- To meet these needs, what process,
- procedures etc. are required??

- When and how will these
- requirements be met?

**Business Level Requirements**

## Use Cases Are One Approach Used to Capture and Model Requirements During Analysis

***Use Cases Are One Approach Used to Capture and Model Requirements During Analysis***

- Descriptive “scenarios” of how an actor interacts with system
- Models system behaviors initiated by an actor
- Constitutes a complete event course initiated by an actor
- Set of use cases collectively describes system functionality
- During requirements analysis a use case models a business event

## Challenges Using Use Cases as Requirements

- Trying to maintain, update, track and validate requirements in a use case form can be difficult.
- It is hard to organize the requirements in any other way than in an event-driven format.
- A single use case can have multiple requirements.
- Will miss requirements not modeled in use cases such as relationships, data, non-behavioral etc.
- Capturing a complete set of functionality in the use cases can result in an enormous, unwieldy set of use cases.
- Our experience is that use cases should be used to elicit and model requirements but be careful in using only use cases
- Will need to specify them for the purposes of formally tracking, documenting and testing what the system’s functionality.

## GenericRequirements Analysis 

- Business
- Processes

- System
- Use Cases

- Use Case
- Alternatives /
- Exceptions

- Business Rules
- and
- Detailed
- Requirements

- Global
- Non Functional
- Requirements

- Features

- Interfaces

- Reports

- Test Case

- Test Plan

- Issues

- Design
- Elements

- These artifacts should be traced to the requirements with which they are associated.

- Non Requirement types

***Generic******Requirements Analysis ***
***Artifact Map***

## Key Mistakes When Developing Use Case Models

- Not involving the end user
- Modeling the use cases as processes and not events
- Modeling the GUI interface, and not the logic requirements
- Not creating project wide standards for representing the use cases
- Not training the staff in good use case model techniques
- Trying to represent every requirement in use cases
- Not understanding the use case model place in the large requirements analysis picture
- Not scaling your use case, and over all requirements analysis effort, based on your unique project characteristics

## Business Process Modeling with UML Activity Diagrams

## GenericRequirements Analysis 

- Business
- Processes

- System
- Use Cases

- Use Case
- Alternatives /
- Exceptions

- Business Rules
- and
- Detailed
- Requirements

- Global
- Non Functional
- Requirements

- Features

- Interfaces

- Reports

- Test Case

- Test Plan

- Issues

- Design
- Elements

- These artifacts should be traced to the requirements with which they are associated.

- Non Requirement types

***Generic******Requirements Analysis ***
***Artifact Map***

## Business Process Diagrams

- Model the integrated processes that needs to be implemented in the system.
- The *Business Process Diagrams* should cover a range of the core business processes to provide the stakeholders with a sense of what the organization's operating environment will be like when the system is implemented.
- Each process should be as intuitive as possible, because they provide a high level reference for stakeholders to review and approve.
- Not every possible business process needs to be depicted in a business process diagram.

## Why Business Process Models?

- Can use Use Cases to represent Business Processes
- However, in order to capture scope and length, Use Cases may be very long and broad
- May have to give up readability, modifiability and details

## Business Process Diagrams

- Processes present an integrated horizontal view of the enterprise wide business processes.  They can include:
- One level to capture overview of System
- Another level to capture processes within each subfunctional grouping (IF NEEDED)
- Can be then partitioned into use cases
- Can be Represented with UML Activity Diagrams

## Possible Business Activity Levels

**Functional**

**Groupings**

**System**

**Use Cases**

- Is

- partitioned

- into

- Is elaborated

- into

- Is elaborated

- into

- Is elaborated

- into

**Functional**

**Groupings (if needed)**

**System**

**Use Cases**

**System **
**overview**

- Is

- partitioned

- into

- Is elaborated

- into

- Is elaborated

- into

## Activity Diagram of Workflow Process, With Each Activity as a Use Case

## Modeling Business Activities with UML Activity Diagrams

- Provide a visual reference for the understanding and documentation of complex, global, enterprise wide processes.
- Are an excellent means to present complex requirements to the stakeholders.
- Are used to understand the dependencies and relationships between the activities within an global enterprise.
- Can be used to help clarify and model parallel activities using synchronization bars.

## Business Process Diagrams are Useful in Modeling Workflow 

- In modern organizations, work groups are no longer static groupings of individuals working within the confines of a single department.
- They now include roles, such as customers, employees and suppliers, that cross organizational and physical boundaries.
- Workflow concepts can be used to develop an integrated system to support work groups and organizations that straddle these conventional boundaries.
- Workflow is all about the way in which work flows from person to person and from place to place.
- It can be described as the flow of information and control within a business process. The processes are usually a definable, repetitive and well-understood set of activities.
- Business Process Diagrams can be used to model workflow activities, such approving a loan or approving a travel voucher.

## Mapping a Business Process Diagram to a  Use Case Model

- The workflow process can be represented as series of use cases.
- Existing Business Activity diagrams can be mapped to a set of system use cases.
- First, consider each role as an actor, then look at the routes to determine what events occur at each stop in the workshop process.
- These events become candidate use cases.
- Each individual use case(s) can be then described in more detail based on what happens at each stop.
- The rules on the routes can be placed in the use case flow of events or places on the transition lines of an activity diagram. (An alternative modeling approach would be to use UML state diagrams).
- Remember that each use case should provide value to an actor.

## Processing Travel Vouchers 

- The travel voucher business activity Diagram would include the following use cases:
- _Actor__	__	__System Use Case_
- Employee		Submit Travel Voucher
- Manager		Review Travel Voucher
- Travel Accounting
- Analyst			Analyze Travel Voucher
- Travel Accounting
- Analyst			Disburse Funds

## Basic Use Case Requirements Concepts

## GenericRequirements Analysis 

- Business
- Processes

- System
- Use Cases

- Use Case
- Alternatives /
- Exceptions

- Business Rules
- and
- Detailed
- Requirements

- Global
- Non Functional
- Requirements

- Features

- Interfaces

- Reports

- Test Case

- Test Plan

- Issues

- Design
- Elements

- These artifacts should be traced to the requirements with which they are associated.

- Non Requirement types

***Generic******Requirements Analysis ***
***Artifact Map***

## Example of Partial ATM System Use Case Diagram

***Example of Partial ATM System Use Case Diagram***

## Elaboration of Use Case Details

## Partial Flow of Events for Submit Loan Request (I)

- The *applicant completes* the online loan application and submits it to the
- 		bank via the Internet
- 2) 		In initial preparation for evaluating the loan request:
- 		2.1) The *system performs* validation that the information on the 		loan application is correct and complete as possible. This includes		determining that all mandatory fields are completed and that basic		information such as zip codes, state codes are present and the format
- 				of account numbers are correct.
- 		2.2) The *system forwards* a request to an external *credit bureau* for		 a credit report on this applicant. The request includes the		 applicant’s name, social security number and current and previous		 addresses.
- 		2.3) The *system retrieves* the applicant’s account history (if any)		 from the *accounts management system*.
- 		2.4) The *system calculates* the applicant’s credit score based on
- 		 		credit reports and the applicant’s history with the bank.

## Alternative Flows as Requirements

## GenericRequirements Analysis 

- Business
- Processes

- System
- Use Cases

- Use Case
- Alternatives /
- Exceptions

- Business Rules
- and
- Detailed
- Requirements

- Global
- Non Functional
- Requirements

- Features

- Interfaces

- Reports

- Test Case

- Test Plan

- Issues

- Design
- Elements

- These artifacts should be traced to the requirements with which they are associated.

- Non Requirement types

***Generic******Requirements Analysis ***
***Artifact Map***

## Alternative Flows

- Normally be a large number of possible variations, alternatives and exceptions that can occur when a use is executed. (e.g. What behaviors will occur if the borrower’s credit is bad? What if a customer attempts to withdrawal funds from an ATM machine and the customer’s account does not have sufficient funds?)
- These alternatives and variations can represent significant functionality.  It is necessary to think out the implications of the alternatives.
- An alternative can be developed in different development increments than the main flow or other alternatives.
- Alternative flows show the flow of events that occurs when an alternative or exception occurs in the use case.
- Document the alternatives through the use of  separate alternative flow descriptions.

## Types of Alternative Flows

- Alternative Flows can be characterized as:
- Alternative Business Logic
- Complex Exception Logic
- Known Technical Exceptions (used very, very rarely in use cases!)

## Base Use Case Description and Alternative Flow Descriptions

## Documenting Alternative Flows

- If the details are viewed as representing important requirements, they can be written in separate description templates.
- Document the specific behaviors that will occur if an alternative or variation from the base flow of events is taken.
- An alternative can include such things as different processing option based on user input, a decision taken within the use case flow of events or an exception condition that results in a different set of behaviors executing.
- Alternatives flows can be documented quickly and briefly in the base use case description.

## Documenting Alternative Flows in the Base Use Case Description

- Provide the Alternative with a unique requirements ID
- Name the alternative and provide a short (a few words to a few sentences) description of the alternative
- Include the insertion point into the base flow
- Include a requirements priority

## Business Rules and Detailed Requirements 

## GenericRequirements Analysis 

- Business
- Processes

- System
- Use Cases

- Use Case
- Alternatives /
- Exceptions

- Business Rules
- and
- Detailed
- Requirements

- Global
- Non Functional
- Requirements

- Features

- Interfaces

- Reports

- Test Case

- Test Plan

- Issues

- Design
- Elements

- These artifacts should be traced to the requirements with which they are associated.

- Non Requirement types

***Generic******Requirements Analysis ***
***Artifact Map***

## Business Rules and Detailed Requirements (I)

- Associated with the execution of a single use case, can be detailed requirements or business rules.
- While important to capture, if placed directly into the use case event course (flow of events) can “clutter” or make the course very long and hard to read as well as manage.
- These rules and requirements can be placed in a separate field within the use case template, in a separate business rule template.

## Categories of Business Rules

*While no standard taxonomy of the categories exist, common types of business rules include**:*

**Type of Rule****	****Example****	****	**
- Constraint		An applicant must have exactly one 			primary email
- Calculation		The sales tax for an order is 				calculated by multiplying the total 			order price by .05.
- Validation		The due date of the book must be 			greater than the current date.
- Derivation		A student is in good standing if they 			have a GPA of 2.0 or greater

## Determining Business Rules

- Select those detailed business rules, processing logic and other functional requirements that don’t fit naturally or neatly in the use cases or other requirement types.
- This can be subjective; however, the most important thing is to capture the requirement somewhere.
- These rules and requirements are normally numbered, and if needed, referenced and traced from a point in the use case.
- There should be traceability between the use case step that contains the business and the business rule itself.

## Non Functional Requirements 

## GenericRequirements Analysis 

- Business
- Processes

- System
- Use Cases

- Use Case
- Alternatives /
- Exceptions

- Business Rules
- and
- Detailed
- Requirements

- Global
- Non Functional
- Requirements

- Features

- Interfaces

- Reports

- Test Case

- Test Plan

- Issues

- Design
- Elements

- These artifacts should be traced to the requirements with which they are associated.

- Non Requirement types

***Generic******Requirements Analysis ***
***Artifact Map***

## Non-Functional (Non Behavioral) Requirements Associated with the Use Case

- Use cases provide a good mechanism for describing system behavior and functionality.
- There are often non-functional aspects associated with an event that are not easily captured in the flow of events.
- Some requirements associated with a use case, such as performance or security, are difficult to model in the use case flow of events.
- They should be documented in the non-functional SRS  requirements section or with the specific use cases they apply to.

## Non Functional: Performance 

- Once an instance of a use case is initiated, how long will it take to respond to the actor with results?
- For example, once a loan application is entered into the system, within what time period is it expected that a credit analysis will be completed?
- What is the number of transactions performed in the use case?
- Within what time frame that will the transaction occur? What is the amount of information that is to be processed within certain periods for both normal and peak work-load conditions?

## Non Functional: Capacity

- How many instances of an actor will need to be supported in the business environment? For example, how many applicants can apply for a loan concurrently.
- Consider if there will be a business need to grow in capacity. This requirement type can also include the number of terminals to be supported, and the number of simultaneous users that are expected to be supported.

## Non Functional: Reliability and Availability 

- How reliable does the business need the use case to be? Will the use case be expected to execute correctly 99% of the time?
- How available will the behaviors in this use case be? Will the use case be expected to execute 24/7?
- Will there be a need for regular down time due to system maintenance?

## Non Functional: Security 

- Are there any unique security requirements specific to this use case?
- For example, is there a need to log specific events, implement an audit trail or use certain cryptographic techniques?

## Non Functional: Design Constraints 

- Although it is important to avoid premature design during an analysis, sometimes design constraints are unavoidable.
- For example, the customer may have an existing database or mainframe computer that they require the proposed system to use, or they may have a strong desire to use a web interface.
- Record design constraints that are specific to this use case if design constraints are system wide (i.e. effort multiple use case, list them in a global non functional section requirements model).

## Logical Interfaces

## GenericRequirements Analysis 

- Business
- Processes

- System
- Use Cases

- Use Case
- Alternatives /
- Exceptions

- Business Rules
- and
- Detailed
- Requirements

- Global
- Non Functional
- Requirements

- Features

- Interfaces

- Reports

- Test Case

- Test Plan

- Issues

- Design
- Elements

- These artifacts should be traced to the requirements with which they are associated.

- Non Requirement types

***Generic******Requirements Analysis ***
***Artifact Map***

## Interface Definition

- The interface definition identifies transactional inputs and outputs that must be received from or be output to systems outside the application being developed.
- Interfaces may be to existing legacy systems or to third-party offerings.
- The project team creates the interface definition based on the functional analysis of the new system, along with its analysis of existing legacy systems and the requirements of third-party offerings. The mechanisms for implementing the interfaces will be determined by the application and technical architecture.

## Provide the Following Information on Each Interface:

**Interface name.** Identify the interface.
**Definition.** Describe the purpose of the interface, as well as the source and target application or application subsystem. Give the source or target system.
**In/out.** State whether the interface provides input to or output from the application being developed.
**Composition.** Cite existing interface layouts, content edit rules, and other related documentation.
**Frequency.** Define when and how frequently the interface will be used by the application being developed.
**Volume.** Identify the anticipated average and maximum volume of information to be relayed over the interface.
**Service levels.** Specify the required, or contractually agreed-upon, service levels for the interface. This typically includes availability, throughput, and response time. For example, how long will it take to authorize a credit card transaction? When will an interface not be available (due to systems maintenance, for example)?
**Audits and controls.** Identify the location of summary information recorded about the interface transactions. This might represent summary statistics regarding interface transactions, a complete transaction log, or both.

## Organizing the Use Cases

## Organizing the Use Cases

- Several organizational mechanisms – such as the use case diagrams that help represent the relationships between individual use cases and actors as well the includes, extends and general relationships between use cases.
- We look at three additional techniques to help organize the system use cases:
- 	Functional Business Packages
- 	Informal Dependency Streams
- 	Use Case Model Views
- We find that we can use UML concepts such as packages and activity diagrams to help us represent these concepts.

## Why Organize the Use Cases?

- The human mind has difficulty understanding and comprehending large amounts of information.
- Remember, the 7 plus or minus 2 rule.
- The idea is that when the human mind looks at something it can most effectively conceptualize and remember about seven major items when reviewing a diagram or other artifact.
- In a system of any meaningful size, there will be a large number of use cases. Throwing 50 use cases at a customer without any meaningful ordering or organization will usually be decidedly unsuccessful.
- Grouping the use cases by actor or by use case family is useful in many situations; however, there will be times when a customer may wish to view the use case in different arrangements.

## User Needs to See How the Use Cases Fit Together

- When a user is presented with a set of use cases, they may understand the individual use cases, but not how the use cases are organized to satisfy the overall business requirements.
- It is natural for the customer and user to ask: What are all the use cases dealing with “billing” or what are all the use cases that deal with “loan generation”?
- When a large number of use cases are presented to the users without some form of organization that meaningfully reflects the business functions, the users will respond with, “I don’t get the Big Picture, or I don’t see how the use cases relate!”.
- The user will not be able to validate that the use cases completely cover the requirements for  specific business functions. Why is this?

## Grouping the Use Cases

- When customers and users view system behavior, it is natural for them to think of a system as a set of key business functions or features that the system provides.
- These business functions are broad responsibilities of the system and can be viewed from a functional perspective.
- The business functions are the next level of abstraction down from a system level context or use case diagram.
- For example, the business functions of a library system might include such functions as circulation, acquisitions, inventory and management reporting.

## Functional Business Packages

- Use cases can be grouped by functionality. We refer to these grouping as *Functional Business Package*s.
- Each functional business package represents a major business activity supported by the system.
- In the loan processing system there are unique business functions associated with both loan submission as well as loan maintenance and customer care.
- These are defined as separate business functional packages.
- For a large system, partitioning system behavior into business functional packages is also critical for understanding the system architecture and effectively defining a development strategy.

## Functional Business Packages For Loan System

## Loan Submission and Origination Functional Business Package

- Submit Loan Request

- Applicant

- Request Information on Loan

- Program

- Loan Officer

- Evaluate Loan Request

- Loan Assistant

- Enter Validated Credit References

- Book a New Loan

- Generate Approval Letter

- Loan Clerk

- Generate  Loan Agreement

- Request Credit Report

- <<include>>

## Loan Portfolio Analysis and Reporting Functional Business Package

- Generate Account Activity Sheet

- Loan  Manager

- Report on Portfolio Performance

- Measures

- Forward Summarized Loan

- Information

- Report on Delinquent Loans

- Loan  Manager

## Loan Account Management and Care Functional Business Package

## Credit Management Domain Functional Business Package

## Benefits of Functional Business Packages

- Organizes the use cases into logical grouping to assist in making the use case model more structured and organized.
- Helps to validate that the needed use cases exist for each business function and that there are no missing use cases.
- Provides input into the system architecture definition process to help to create the functional architecture.

## Creating Functional Business Packages

- When developing the use cases, look for natural groupings or partitioning of use cases *based *on the customer’s or user’s perspective.
- Look at documentation such as previously developed business use cases, BPR results, or organizational grouping of responsibilities based on the stakeholder analysis.
-  In most cases, this grouping will become clear as the use case model is created.
- Name the business functional packages in a way that reflects the user and customers understanding of the package, and that package’s responsibilities within the system.
- An individual use case belongs to one package, and each of these packages can contain multiple use cases

## Use Case Views

**Use Case Views**
-  List is not meant to be all inclusive, individual projects will no doubt discover additional views that are useful for them.
-  The key idea is to think of the use case model as multi-dimensional and rearrange it in ways that help to discover, model and represent quality requirements.

## Conclusions

- Use cases are not always sufficient to capture all the requirements on a large-scale development.
- Uses cases “fit” with other forms of requirements.
- Use cases need to be described and structured for a large-scale iterative development process.
- A process for creating and maintaining use case models in a framework that can be fully customized for your organization is critical.