Requirements Engineering
Lecture 3
ConOps and Use Cases
Jerzy.Nawrocki@put.poznan.pl
www.cs.put.poznan.pl/jnawrocki/require/
Copyright, 2003 © Jerzy R. Nawrocki
Bibliography

ISO/IEC 12207 Standard for Information Technology—
Software life cycle processes—Life cycle data,
IEEE/EIA 12207.1-1997, April 1998.
IEEE Guide for Information Technology – System
Definition - Concept of Operations (ConOps)
Document, IEEE Std 1362-1998, March 1998.
S. Adolph, P. Bramble, A. Cockburn, A. Pols, Patterns for
Effective Use Cases, Addison-Wesley, Boston, 2003.
J. Nawrocki, Use Cases and ConOps
ISO/IEC 12207 contents
6.1 Acquisition plan
6.2 Change request or modification request
6.3 Concept of operations description
6.4 Database design description
6.5 Development process plan
6.6 Evaluation records
6.8 Maintenance process plan
6.9 Operation process plan
6.10 Problem report and problem resolution report
6.11 Project management plan
6.12 Software architecture description
...
J. Nawrocki, Use Cases and ConOps
Generic description - 12207
Cover page
{
a) Date of issue and status;
b) Scope;
c) Issuing organization;
d) References;
e) Context;
f) Notation for description;
g) Body;
h) Summary;
i) Glossary;
j) Change history.
J. Nawrocki, Use Cases and ConOps
Concept of Operations - 12207
Purpose: Describe, in users’ terminology, how the
system should operate to meet the users’ needs.
Use
cases
Content:
a) Generic description information (previous slide);
b) Description of current situation or system;
c) Justification for and nature of changes;
d) Concepts for the proposed system;
e) Operational scenarios;
f) Summary of impacts;
g) Analysis of the proposed system;
h) Priorities, assumptions, constraints, advantages,
limitations, alternatives, and trade-offs considered.
J. Nawrocki, Use Cases and ConOps
IEEE Std 1362 History
R.J. Lano, A Structured Approach for Operational Concept
Formulation, TRW SS-80-02, Redondo Beach, CA, 1980.
1992: Software Systems Technical Committee of the
American Institute of Aeronautics and Astronautics
(AIAA), a standard for and Operational Concept
Document.
1993: MS thesis, California State University, Sacramento;
accepted as MIL-STD-498.
IEEE Std 1362-1998 by R. Thayer, R. Fairley, P. Bjorke.
J. Nawrocki, Use Cases and ConOps
ConOps structure - 1362
1. Scope
2. Referenced documents
3. Current system or situation
4. Justification for and nature of changes
5. Concepts for the proposed system
6. Operational scenarios
7. Summary of impacts
8. Analysis of the proposed system
9. Notes
Appendices
Glossary
J. Nawrocki, Use Cases and ConOps
1. Scope
1.1 Identification
Number, title, and abbreviation of the system
1.2 Document overview
Purpose, audience, security, ConOps outline
1.3 System overview
Purpose, sponsors, context diagram
Person 1
Institution
System
Person 2
J. Nawrocki, Use Cases and ConOps
Device
3. Current system or situation
3.1 Background, objectives, and scope
3.2 Operational policies and constraints
Constraints on the hardware, the hours of operation of
the system, the number of available personnel, ..
J. Nawrocki, Use Cases and ConOps
3. Current system or situation
3.1 Background, objectives, and scope
3.2 Operational policies and constraints
3.3 Description of the current system or situation
The operational environment
Major system components and their interconnections
Interfaces to external systems or procedures
Functions (features)
Inputs, outputs, data flows
Cost of system operations
Operational risk factors
Performance // Safety and security aspects // ...
J. Nawrocki, Use Cases and ConOps
3. Current system or situation
3.1 Background, objectives, and scope
3.2 Operational policies and constraints
3.3 Description of the current system or situation
3.4 Modes of operation for the current system or situation
Operational, degraded, maintenance, training, ..
3.5 User classes and other involved personnel
3.5.1 Organizational structure
3.5.2 Profiles of user classes
3.5.3 Interactions among user classes
3.5.4 Other involved personnel
3.6 Support environment
J. Nawrocki, Use Cases and ConOps
4. Justification for changes
4.1 Justication for changes
New user needs, environments etc. Disadvantages of
the current system.
4.2 Description of desired changes
Features, processing, interfaces, personnel,
environment, ..
4.3 Priorities among changes
Essential, desirable, optional
4.4 Changes considered but not included
J. Nawrocki, Use Cases and ConOps
5. Concepts for the proposed ..
5.1 Background, objectives, and scope
5.2 Operational policies and constraints
5.3 Description of the current system or situation
5.4 Modes of operation for the current system or situation
5.5 User classes and other involved personnel
5.5.1 Organizational structure
5.5.2 Profiles of user classes
5.5.3 Interactions among user classes
5.5.4 Other involved personnel
5.6 Support environment
J. Nawrocki, Use Cases and ConOps
Operational scenarios
A step-by-step description of system’s operation and
interaction with its users and external interfaces under
a given set of circumstances.
J. Nawrocki, Use Cases and ConOps
7. Summary of impacts
7.1 Operational impacts
Changes in procedure; use of new data sources;
changes in type and timing of data to be input
7.2 Organizational impacts
Job positions, skill levels, responsibilities, ..
7.3 Impacts during development
User involvement in software development;
parallel operation of the new and old system, ..
J. Nawrocki, Use Cases and ConOps
Analysis of the proposed system
8.1 Summary of improvements
New, enhanced, and deleted capabilities.
Improved performance.
8.2 Disadvantages and limitations
8.3 Alternatives and trade-offs considered
J. Nawrocki, Use Cases and ConOps
ConOps structure - 1362
.., terms and
definitions
1. Scope
2. Referenced documents
3. Current system or situation
4. Justification for and nature of changes
5. Concepts for the proposed system
6. Operational scenarios
7. Summary of impacts
8. Analysis of the proposed system
9. Notes
Appendices
Glossary
J. Nawrocki, Use Cases and ConOps
What is a use case?
A story describing how an actor (user or device)
cooperates with the system to accomplish a given purpose.
Abstraction
level
Use cases
IEEE SRS
Size
J. Nawrocki, Use Cases and ConOps
Advantages of use cases
• They are semiformal. They introduce structure to stories.
• They describe also error situations.
• They are part of O-O software development.
• They are basis for estimates, detailed requirements,
interface designs, and test scenarios.
J. Nawrocki, Use Cases and ConOps
Poorly written use case
Register for Course (Main Scenario)
1. Display a blank schedule.
2. Display a list of all classes in the following way: The left window lists
all the courses in the system in alphabetical order. The lower window
displays the times the highlighted course is available. The third
window shows all the courses currently in the schedule.
3. Do.
4. Student clicks on a course.
5. Update the lower window to show the times the course is available.
6. Student clicks on a course time and then clicks on the „Add Course”
button.
J. Nawrocki, Use Cases and ConOps
Poorly written use case
Register for Course (Main Scenario cont.)
7. Check if the Student has the necessary prerequisites and that the
course offering is open.
8. If the course is open and the Student has the necessary
prerequisites, add the Student to the course. Display the updated
schedule showing the new course. If no, put up a message „You are
missing the prerequisites. Choose another course.”
9. Mark the course offering as „enrolled” in the schedule.
10. End do when the Student clicks on „Save Schedule.”
11. Save the schedule and return to the main selection screen.
J. Nawrocki, Use Cases and ConOps
Poorly written use case
Too much user interface detail.
1. Display a blank schedule.
2. Display a list of all classes in the following way: The left window lists
all the courses in the system in alphabetical order. The lower window
displays the times the highlighted course is available. The third
window shows all the courses currently in the schedule.
3. Do.
4. Student clicks on a course.
5. Update the lower window to show the times the course is available.
6. Student clicks on a course time and then clicks on the „Add Course”
button.
J. Nawrocki, Use Cases and ConOps
Other frequent defects
Too many use cases at low goal levels („Authorize user”).
Using a use case for non-behavioral information (e.g.
forms description – use adornments).
Too long (should be short, usually 3-9 steps).
Not a complete goal accomplished (also lack of alternative
behaviors description).
Sentence fragments (e.g. omitting the actors’ names in
steps).
J. Nawrocki, Use Cases and ConOps
Well-written use case
Register for Course (Main Scenario)
1. Student requests a new schedule.
2. The system prepares a blank schedule form and pulls in a list of
open and available courses from the Course Catalog System.
3. Student selects primary and alternate courses from the available
offerings.
4. For each course, the verifies taht the Student has the necessary
prerequisites and adds the Student to the course, marking the
Student as „enrolled” in that course in the schedule.
5. When the Student indicates the schedule is complete, the system
saves the schedule.
J. Nawrocki, Use Cases and ConOps
Patterns for effective use cases
Shared Clear Vision:
Prepare a statement of purpose for the system that clearly
describes the objectives of the system.
• The objectives of the system
• The problems that the system will solve
• The problems the system will not solve
• Who the stakeholders are
• How the system will benefit the stakeholders
J. Nawrocki, Use Cases and ConOps
Patterns for effective use cases
Visible Boundary:
Establish a visible boundary between the system and its
environment by enumerating both the people and equipment
that interact with the system.
J. Nawrocki, Use Cases and ConOps
IEEE Std 1362 - Scope
1.1 Identification
Number, title, and abbreviation of the system
1.2 Document overview
Purpose, audience, security, ConOps outline
1.3 System overview
Purpose, sponsors, context diagram
Person 1
Institution
System
Person 2
J. Nawrocki, Use Cases and ConOps
Device
Patterns for effective use cases
Clear Cast Of Characters:
Identify the actors the system must interact with and the
role each plays with respect to the system. Clearly describe
each.
Receptionist: The Receptionist welcomes Customers to the
pharmacy. He or she takes the Customer’s prescription.
Anyone on the pharmacy staff can play the role of
receptionist.
Pharmacist: The Pharmacist fills and dispenses prescriptions
for customers. Only the Pharmacist can check and
authorize the prescription.
J. Nawrocki, Use Cases and ConOps
Patterns for effective use cases
User Valued Transactions:
Identify the valuable services that the system delivers to
the actors to satisfy their business purposes.
Book trip
Search for flights
Promote vacations
Create trip itinerary
Update trip itinerary
Delete trip itinerary
J. Nawrocki, Use Cases and ConOps
Book trip
Search for flights
Promote vacations
Change booking
Cancel booking
Patterns for effective use cases
Ever Unfolding Story:
Organize the use case set as a hierarchical story that can
be either unfolded to get more detail or folded up to hide
detail and show more context.
J. Nawrocki, Use Cases and ConOps
Use case goal levels
Summary
Level
Book trip
Book trip
Book flight
User Goal
Level
Book hotel
Book trip
Book flight
Find flight
Subfunction
Level
Book hotel
Reserve
seat
Find hotel
J. Nawrocki, Use Cases and ConOps
Reserve
room
Ever Unfolding Story
Book Flight
Leel: User Goal
Main Success Scenario
1. This use case begins when a customer calls and requests a flight.
2. The customer describes her flight needs by specifying her
origination, destination, travel dates, and preferred departure times
3. The system looks up all flights that match the customer’s
preferences and presents the travel options to the customer.
4. The customer selects a flight.
5. The system builds a flight itinerary for the customer.
6. The system reserves the flight for the customer.
7. The customer provides a credit card number and charges the price
of the flight against it.
8. The system issues the ticket to the customer.
J. Nawrocki, Use Cases and ConOps
A detailed version of Book Flight
Find flight
Construct
itinerary
Travel
agent
Reserve
flight
Issue
ticket
J. Nawrocki, Use Cases and ConOps
Airline
reservation
Merchant
bank
Ever Unfolding Story
Find Flight
Leel: Subfunction
1. This use case begins when a customer contacts the travel agency
and requests a flight.
2. The travel agent captures the customer’s trip origin and destination.
3. The travel agent looks up the airport codes for the origin and dest.
4. The travel agent captures the preferred departure times for the
customer.
5. The travel agent captures the customer’s preferred class of service
6. The travel agent confirms that the customer’s preferences are
correct.
7. The system requests from the airline reservation system a list of the
flights available that match the customer’s preferences, which is
presented to the travel agent.
J. Nawrocki, Use Cases and ConOps
Summary
ISO/IEC Std 12207 and ConOps
IEEE Std 1362 and ConOps:
• Current system
• Justification for change
• Concepts for new system
• Operational scenarios
• Impacts
Use cases:
Shared clear vision
Visible boundary
Clear cast of characters
User valued transactions
Ever unfolding story
J. Nawrocki, Use Cases and ConOps
Quality assessment
1. What is your general
impression? (1 - 6)
2. Was it too slow or too fast?
3. What important did you learn
during the lecture?
4. What to improve and how?
J. Nawrocki, Use Cases and ConOps