rrc requirements and use cases

Software Engineering ProcessDisciplined, Modern, and Mature

An Overview Workshop for the Railroad Commission of Texas

January 21 & 22, 2003

http://www.rrc.state.tx.us/index.html

Project InceptionProject Inception

Vision Artifact

• The Vision defines the stakeholders view of the product to be developed, specified in terms of the stakeholders key needs and features

• It contains an outline of the envisioned core requirements, it provides the contractual basis for the more detailed technical requirements

• Typically, the approval of the Vision document is a prerequisite for moving forward with the project

Project InceptionProject Inception

Group Discussion - Vision

• Discuss the types of ‘Vision’ Artifacts used by the RRC to launch a project

• Is there an organizational standard or does it vary from project to project?

• Review the STARS Project Management Plan• Review the Vision Template in RUP

Requirements Requirements ManagementManagement

Introduction

• Managing requirements involves the translation of stakeholder requests into a set of key stakeholder needs and system features

• These, in turn, are detailed into specifications for functional and non-functional requirements

• Functional requirements are then detailed into use case specifications (system or report), which are the basis for system design, implementation, system testing, and user documentation


Needs

Features

Software Requirements

System DesignImplementation System Testing

User Documentation

Problem ProblemSpace

SolutionSpace

Trac

eabi

lity

ProductTo BeBuilt


Functional and Nonfunctional Requirements

• Functional Requirements express how the system behaves

• These requirements are usually action oriented• More often than not, Functional Requirements

can be stated in simple declarative statements (i.e., shall/will/must statements)

• Most functional requirements can be stated in a one- or two-statement sentence



• While Functional Requirements are important, they cannot fully capture the requirements of the system

• To complete the description of the system, Nonfunctional Requirements are required

• Nonfunctional Requirements typically express some of the “attributes of the system” or “attributes of the system environment”



• Nonfunctional Requirements are also stated in simple declarative statements (i.e., shall/will/must statements)

• Nonfunctional Requirements include states that describes the systems: Usability Reliability Performance Supportability


Nonfunctional Requirements

• Usability requirements describe the ease with which the system can be learned and operated by the intended users

• Reliability describe the degree to which the system must behave in a user-acceptable fashion Availability (24 hours a day, 7 days a week) Mean time between failures Mean time to repair Defect rates, maximum bugs, bugs per type


Nonfunctional Requirements

• Performance requirements usually cover such categories as: Transaction response times Throughput, or transactions per second Capacity, or the number of customers or

transactions the system can support (i.e., workload)

• Supportability is the ability of the software to be easily modified to accommodate change


Requirement Types (FURPS+)

• Functionality• Usability• Reliability• Performance• Supportability• + - indicates that there are more possible

categories to be considered as required by any given project


Requirements and Use Cases Exercise – Part 1

• Organize into the groups formed yesterday• Using the Railroad Commission Requirements

and Use Cases Exercise, review each requirement as a team and identify the requirement as either Functional on Nonfunctional

• Note the team’s decision on the exercise sheet• Each team member should do the same on their

individual sheets• Each team will then report to the group


Software Requirements Specification

• The Software Requirements Specification (SRS) captures the complete software requirements for the system

• When using use-case modeling, this deliverable includes both the use cases within the Use Case Model as well as the Nonfunctional Requirements documented in the project’s Supplementary Specification


Requirements Management Discussion

• Discuss JRP Sessions – a requirements elicitation techniques

• Review the STARS Requirements Traceability Matrix and note the logical grouping of requirements

• Review the STARS Software Requirements Specification and STARS Supplementary Specification

• Review the SRS Template in RUP


Stakeholders’ Requests

Features

Use Cases Supplementary

Functional

Requirements

Nonfunctional

Requirements

ResourcesResources

Dean Leffingwell and DonWidrig (2000). Managing Software Requirements A Unified Approach. Addison-Wesley Publishing Company, Inc.

Use Case ModelingUse Case Modeling

What is Use Case Modeling?

• A means for capturing the desired behavior for the system under development

• A way to communicate the system’s behavior• Identifies who or what interacts with the system

and what the system should do• A way to verify all requirements are captured• A planning instrument


Benefits of Use Cases

• Give context to requirements• Are easy to understand• Facilitate agreement with customer regarding

the required behavior of the system• A way to verify all requirements are captured• A planning instrument


Actors and Use Cases

• Actor Someone or something outside the system that interacts with the system

• Use CaseWhat an actor wants to use the system to do


What is a Use Case?

• Defines a sequence of actions Atomic activities, decisions, and requests

• Performed by the systemThe actions performed by the system are the functional requirements

• That yields an observable result of valuePost-Condition – ensures that the use case results in an observable value

• To the actor


What is a Use Case?

• To the actor Deciding which particular actor receives the value helps avoid use cases that are too large

Often the sequence of interactions in a use case involves several actors, but only one actor receives the value of the result

This is usually the actor who initiates the use case (or the primary actor)


Steps to Create a Use Case Model

• Identify actors and use cases• Outline each use case• Detail each use case• Structure each use case’s flow of eventsNote: Similar to the actual software application,

use cases are often refined over multiple iterations as the project team learns more about the intended system


Group Exercise - Actors

• Using a brainstorming technique, lets identify the actors for a proposed RRC project

• Remember, actors are external to the system and initiate, or communicate, with the system

• Following this activity, lets again review the Course Registration System’s Use Case Model and the STARS Use Case Model


Use Case Pattern

• Earlier we discussed organizing your functional requirements into logical groupings(Note: this also applies to nonfunctional requirements in terms of URPS)

• Each group was referred to as a high-level feature

• The next step in the process is identifying the use case(s) that will be required to support your functional requirements


Use Case Pattern

• As you may imagine, this can be rather challenging at first

• To assist you in this effort, I will offer for your consideration the use case pattern that we applied on the STARS Project

• This use case pattern is based upon the understanding that there are certain types of tasks that typically occur within any given software application


Use Case Pattern

• General Types of Use Cases Maintain Process View Generate Report


Use Case Pattern

• Maintain Use Cases This type of use case supports maintaining of

system information These are CRUD (i.e., create, read, update,

and delete) type use cases The thing of value that this type of use case

supplies is making data persistent, typically in a relational database management system (RDBMS)


Use Case Pattern

• Process Use Cases This type of use case supports analytical

processes While some information that results from the

analysis is made persistent, the primary purpose for the use case is supporting analytical processes

The thing of value that this type of use case supplies is its support for an analytical process and making analysis data persistent


Use Case Pattern

• View Use Cases This type of use case supports the searching

and viewing of information Nearly every system will require this

functionality The thing of value that this type of use case

supplies is the viewing of information, whether in a report or as the result of a search, which actually is a type of report


Use Case Pattern

• Generate Use Cases This type of use case supports the generation

of a data file from system information If the system must supply data to other

entities or legacy systems, this type of use case will be needed

The thing of value that this type of use case supplies is the generation of a data file external to the system


Use Case Pattern

• Report Use Cases This type of use case supports all of your

report requirements Nearly every system has report requirements While a ‘View a Report’ Use Case supports

the viewing of a report, this type of use case is the report itself

The thing of value that this type of use case supplies is the report



• Organize into your groups• Using the Railroad Commission Requirements

and Use Cases Exercise, review each functional requirement as a team and identify the type of use case (i.e., maintain, process, view, generate, or report) that will be required to support the requirement

• Note the team’s decision on the exercise sheet



• Each team member should do the same on their individual sheets

• Each team will then report to the group


Use Case Structure

• There are many documented ways to structure a use case

• The reason for this is that the art and science of use cases is evolving; it is in process

• What follows is the structure of the use cases created by the STARS Project Development Team


System Use Case Structure

• Business ContextThis use case is used when the actor . . .

• Pre-ConditionsWhat must be true before the use case can be executed

• OverviewThis use case enables the actor . . .The use case ends . . .



• Flow of Events Primary Flow Alternate Flow Warning Flow Exception Flow

• Post-ConditionsIdentifies the thing of value the use case provides to the actor



• Non-Functional RequirementsSecurity, etc.

• Use Interface RequirementsUser experience prototypesNote: Will be replaced in Design by the User Interface Design Document

• Design CommentsScratch pad for capturing design considerations discovered throughout the lifecycle and specific to the use case


Report Use Case Structure

• The STARS Project Development Team also created over 100 report use cases

• While the report use case structure is the same, there are some variations specific to reports

• Report Specific Considerations Report Title Report Body Report Specifications Chart Presentation


Use Case Tips

• Describe only the events visible to the actor What the actor does What the system does in response

• Make use cases provide value to the actor who initiated the use case

• Detail until everyone (i.e., your customer) has a common understanding of the requirements

• Use agreed-upon terms and vocabulary• Use precise language


Avoid Functional Decomposition

• Functional decomposition is the breaking down of a problem into small isolated parts

• The parts: Work together to provide the functionality of

the system Often do not make sense in isolation

• Use Cases: Are not functional decomposition


Avoid Functional Decomposition

• Functional decomposition is the breaking down of a problem into small isolated parts

• The parts: Work together to provide the functionality of

the system Often do not make sense in isolation

• Use Cases: Use Case describe the complete use of the

system to achieve a goal


Use Case Names

• Use case should be named consistent with the business process it is supporting

• The name should be meaningful to you the business owner of the software application

• Use an active verb in the use case name to reflect the value the use case provides to the actor

Group Activity

• Review STARS System Use Case Template• Review STARS Report Use Case Template• Review sample STARS System Use Cases• Review sample STARS Report Use Cases


rrc requirements and use cases

Documents