1. Software Engineering Process
Disciplined, Modern, and Mature
An Overview Workshop for the Railroad
Commission of Texas
January 21 & 22, 2003

2. 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

3. 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

4. RequirementsRequirements
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

5. RequirementsRequirements
ManagementManagement
Needs
Features
Software Requirements
System Design
Implementation
System Testing
User Documentation
Problem
Problem
Space
Solution
Space
Traceability
Product
To Be
Built

6. RequirementsRequirements
ManagementManagement
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

7. RequirementsRequirements
ManagementManagement
Functional and Nonfunctional Requirements
• 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”

8. RequirementsRequirements
ManagementManagement
Functional and Nonfunctional Requirements
• 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

9. RequirementsRequirements
ManagementManagement
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

10. RequirementsRequirements
ManagementManagement
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

11. RequirementsRequirements
ManagementManagement
Requirement Types (FURPS+)
• Functionality
• Usability
• Reliability
• Performance
• Supportability
• + - indicates that there are more possible
categories to be considered as required by any
given project

12. RequirementsRequirements
ManagementManagement
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

13. RequirementsRequirements
ManagementManagement
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

14. RequirementsRequirements
ManagementManagement
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

15. RequirementsRequirements
ManagementManagement
Stakeholders’ Requests
Features
Use Cases Supplementary
Functional
Requirem
ents
Nonfunctional
Requirem
ents

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

17. 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

18. Use Case ModelingUse Case Modeling
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

19. Use Case ModelingUse Case Modeling
Actors and Use Cases
• Actor
Someone or something outside the system that
interacts with the system
• Use Case
What an actor wants to use the system to do

20. Use Case ModelingUse Case Modeling
What is a Use Case?
• Defines a sequence of actions
Atomic activities, decisions, and requests
• Performed by the system
The actions performed by the system are the
functional requirements
• That yields an observable result of value
Post-Condition – ensures that the use case results
in an observable value
• To the actor

21. Use Case ModelingUse Case Modeling
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)

22. Use Case ModelingUse Case Modeling
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 events
Note: Similar to the actual software application,
use cases are often refined over multiple
iterations as the project team learns more about
the intended system

23. Use Case ModelingUse Case Modeling
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

24. Use Case ModelingUse Case Modeling
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

25. Use Case ModelingUse Case Modeling
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

26. Use Case ModelingUse Case Modeling
Use Case Pattern
• General Types of Use Cases
 Maintain
 Process
 View
 Generate
 Report

27. Use Case ModelingUse Case Modeling
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)

28. Use Case ModelingUse Case Modeling
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

29. Use Case ModelingUse Case Modeling
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

30. Use Case ModelingUse Case Modeling
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

31. Use Case ModelingUse Case Modeling
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

32. RequirementsRequirements
ManagementManagement
Requirements and Use Cases Exercise – Part 2
• 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

33. RequirementsRequirements
ManagementManagement
Requirements and Use Cases Exercise – Part 2
• Each team member should do the same on their
individual sheets
• Each team will then report to the group

34. Use Case ModelingUse Case Modeling
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

35. Use Case ModelingUse Case Modeling
System Use Case Structure
• Business Context
This use case is used when the actor . . .
• Pre-Conditions
What must be true before the use case can be
executed
• Overview
This use case enables the actor . . .
The use case ends . . .

36. Use Case ModelingUse Case Modeling
System Use Case Structure
• Flow of Events
 Primary Flow
 Alternate Flow
 Warning Flow
 Exception Flow
• Post-Conditions
Identifies the thing of value the use case provides
to the actor

37. Use Case ModelingUse Case Modeling
System Use Case Structure
• Non-Functional Requirements
Security, etc.
• Use Interface Requirements
User experience prototypes
Note: Will be replaced in Design by the User Interface Design Document
• Design Comments
Scratch pad for capturing design considerations
discovered throughout the lifecycle and specific to
the use case

38. Use Case ModelingUse Case Modeling
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

39. Use Case ModelingUse Case Modeling
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

40. Use Case ModelingUse Case Modeling
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

41. Use Case ModelingUse Case Modeling
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

42. Use Case ModelingUse Case Modeling
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

43. 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
Use Case ModelingUse Case Modeling