ConOps and Use Cases Copyright, 2003 © Jerzy R. Nawrocki [email protected] Requirements...

ConOps and Use Cases ConOps and Use Cases

Copyright, 2003 © Jerzy R. Nawrocki

[email protected]

www.cs.put.poznan.pl/jnawrocki/require/

Requirements EngineeringRequirements Engineering

Lecture Lecture 33

Requirements EngineeringRequirements Engineering

Lecture Lecture 33

J. Nawrocki, Use Cases and ConOps

BibliographyBibliographyBibliographyBibliography

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.


ISO/IEC 12207 contentsISO/IEC 12207 contentsISO/IEC 12207 contentsISO/IEC 12207 contents

6.1 Acquisition plan6.2 Change request or modification request6.3 Concept of operations description6.4 Database design description 6.5 Development process plan6.6 Evaluation records6.8 Maintenance process plan6.9 Operation process plan6.10 Problem report and problem resolution report6.11 Project management plan6.12 Software architecture description. . .


Generic description - 12207Generic description - 12207Generic description - 12207Generic description - 12207

a) Date of issue and status;b) Scope;c) Issuing organization;{Cover page

d) References;e) Context;f) Notation for description;g) Body;h) Summary;i) Glossary;j) Change history.


Concept of Operations - 12207Concept of Operations - 12207Concept of Operations - 12207Concept of Operations - 12207

Purpose: Describe, in users’ terminology, how the system should operate to meet the users’ needs.

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.

Use cases


IEEE Std 1362 HistoryIEEE Std 1362 HistoryIEEE Std 1362 HistoryIEEE 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.


ConOps structure - 1362ConOps structure - 1362ConOps structure - 1362ConOps structure - 1362

1. Scope1. Scope2. Referenced documents3. Current system or situation4. Justification for and nature of changes5. Concepts for the proposed system6. Operational scenarios7. Summary of impacts8. Analysis of the proposed system9. NotesAppendicesGlossary


1. Scope1. Scope1. Scope1. Scope

1.1 Identification Number, title, and abbreviation of the system1.2 Document overview Purpose, audience, security, ConOps outline1.3 System overview Purpose, sponsors, context diagram

SystemSystem

Person 1

Person 2

Institution

Device


3. Current system or situation3. Current system or situation3. Current system or situation3. Current system or situation

3.1 Background, objectives, and scope3.2 Operational policies and constraints Constraints on the hardware, the hours of operation of

the system, the number of available personnel, ..



3.1 Background, objectives, and scope3.2 Operational policies and constraints3.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 // ...



3.1 Background, objectives, and scope3.2 Operational policies and constraints3.3 Description of the current system or situation3.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 personnel3.6 Support environment


4. Justification for changes4. Justification for changes4. Justification for changes4. 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, optional4.4 Changes considered but not included


5. Concepts for the proposed ..5. Concepts for the proposed ..5. Concepts for the proposed ..5. Concepts for the proposed ..

5.1 Background, objectives, and scope5.2 Operational policies and constraints5.3 Description of the current system or situation5.4 Modes of operation for the current system or situation5.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 personnel5.6 Support environment


Operational scenariosOperational scenariosOperational scenariosOperational scenarios

A step-by-stepstep-by-step description of system’s operation and interactioninteraction with its usersusers and external interfacesexternal interfaces under a given set of circumstancescircumstances.


7. Summary of impacts7. Summary of impacts7. Summary of impacts7. Summary of impacts

7.1 Operational impacts Changes in procedure; use of new data sources;

changes in type and timing of data to be input7.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, ..


Analysis of the proposed systemAnalysis of the proposed systemAnalysis of the proposed systemAnalysis of the proposed system

8.1 Summary of improvements New, enhanced, and deleted capabilities.

Improved performance.8.2 Disadvantages and limitations8.3 Alternatives and trade-offs considered


ConOps structure - 1362ConOps structure - 1362ConOps structure - 1362ConOps structure - 1362

1. Scope2. Referenced documents3. Current system or situation4. Justification for and nature of changes5. Concepts for the proposed system6. Operational scenarios7. Summary of impacts8. Analysis of the proposed system

9. Notes9. NotesAppendices

GlossaryGlossary

.., terms and definitions


What is a use case?What is a use case?What is a use case?What is a use case?

A story describing how an actor (user or device) cooperates with the system to accomplish a given purpose.

Use cases

IEEE SRS

Abstraction level

Size


Advantages of use casesAdvantages of use casesAdvantages of use casesAdvantages 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.


Poorly written use casePoorly written use casePoorly written use casePoorly written use case

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.

Register for Course (Main Scenario)



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.



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.

Too much user interface detail.


Other frequent defectsOther frequent defectsOther frequent defectsOther 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).


Well-written use caseWell-written use caseWell-written use caseWell-written use case

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.

Register for Course (Main Scenario)


Patterns for effective use casesPatterns for effective use casesPatterns for effective use casesPatterns for effective use cases

Shared Clear VisionShared 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



Visible BoundaryVisible Boundary:

Establish a visible boundary between the system and its environment by enumerating both the people and equipment that interact with the system.


IEEE Std 1362 - ScopeIEEE Std 1362 - ScopeIEEE Std 1362 - ScopeIEEE Std 1362 - Scope

1.1 Identification Number, title, and abbreviation of the system1.2 Document overview Purpose, audience, security, ConOps outline1.3 System overview Purpose, sponsors, context diagram

SystemSystem

Person 1

Person 2

Institution

Device



Clear Cast Of CharactersClear Cast Of Characters:

Identify the actors the system must interact with and the role each plays with respect to the system. Clearly describe each.

ReceptionistReceptionist: 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.

PharmacistPharmacist: The Pharmacist fills and dispenses prescriptions for customers. Only the Pharmacist can check and authorize the prescription.



User Valued TransactionsUser Valued Transactions:

Identify the valuable services that the system delivers to the actors to satisfy their business purposes.

Book tripSearch for flightsPromote vacationsCreate trip itineraryUpdate trip itineraryDelete trip itinerary

Book tripSearch for flightsPromote vacationsChange bookingCancel booking



Ever Unfolding StoryEver 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.


Use case goal levelsUse case goal levelsUse case goal levelsUse case goal levels

Book trip

Book hotelBook flight

User Goal Level

Book trip Summary Level

Book trip

Book hotelBook flight

Find flightReserve

seat Find hotelReserve

room

Subfunction Level


Ever Unfolding StoryEver Unfolding StoryEver Unfolding StoryEver Unfolding Story

Book FlightBook FlightLeelLeel: User GoalMain Success ScenarioMain Success Scenario1. 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 times3. The system looks up all flightslooks 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 abuilds a flight itineraryflight itinerary for the customer.6. The system reserves the flightreserves 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 ticketissues the ticket to the customer.


A detailed version of Book FlightA detailed version of Book FlightA detailed version of Book FlightA detailed version of Book Flight

Construct itinerary

Merchant bank

Find flight

Travel agent

Airline reservationReserve

flight

Issue ticket


Ever Unfolding StoryEver Unfolding StoryEver Unfolding StoryEver Unfolding Story

Find FlightFind FlightLeelLeel: Subfunction1. 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 service6. 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.


SummarySummarySummarySummary

ISO/IEC Std 12207 and ConOpsIEEE Std 1362 and ConOps:• Current system• Justification for change• Concepts for new system• Operational scenarios• ImpactsUse cases:Shared clear visionVisible boundaryClear cast of charactersUser valued transactionsEver unfolding story


Quality assessmentQuality assessmentQuality assessmentQuality 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?

Date post:	25-Dec-2015
Category:	Documents
Upload:	imogene-martin
View:	215 times
Download:	1 times

ConOps and Use Cases Copyright, 2003 © Jerzy R. Nawrocki [email protected] Requirements...

Documents