Documenting Use Cases: Diagrams, Templates, and Best Practices

UPI Study › Courses › Software Engineering › Free lessons › Lesson 7.1 Free with a free account

Documenting Use Cases: Diagrams, Templates, and Best Practices

Software Engineering · Chapter 7: Behavioral Models and Requirements AnalysisSection 7.1 · lesson 47 of 1036 min · free with a free account

← Mapping Data and Control Flow: DFDs and Control Flow Diagrams Compared and AppliedNext lesson: Defining System Boundaries with Context Diagrams →

Earn 3 college credits for Software EngineeringRecommended for credit by NCCRS · Computer Science 301 · self-paced · one payment, lifetime access
Enroll in Software Engineering · $250 →Download the syllabus (PDF)

In this lesson

Templates, flows, and best practices for use cases people can rely on.

  • Explain why a scenario needs a standardized shape
  • Identify the core fields of a use case template
  • Distinguish preconditions, postconditions, and flows
  • Apply best practices for writing complete use cases

Transcript

Everything said in the video, section by section (792 words). Read along, or search it.

Behavioral Models and Requirements Analysis

Documenting Use Cases

A scenario is raw material. Vivid, specific, and tied to the moment it was captured. Before others can rely on it, it needs a standardized shape. A written use case, with defined fields that mean the same thing every time. This section covers those fields, how flows are organized, and the habits that make use cases dependable.

From Scenario to Document

Giving Raw Material a Shape

A scenario captures one concrete walkthrough, in whatever order the conversation naturally took. A written use case reorganizes that same material into a fixed, predictable structure. The same fields appear in the same order, every time, whoever wrote them. So anyone reading it later knows exactly where to look for a precondition, a branch, or a guaranteed outcome. They do not have to reconstruct it from a narrative.

The Template

7 Core Fields

A complete use case document is built from a consistent set of fields. A name, or I D, is a short, goal-oriented title for what the actor accomplishes. The actors are who initiates or takes part. The trigger is the event that starts the use case. Preconditions are what must already be true before it can begin. The main flow is the single, expected sequence of steps from the trigger to success. Alternate flows are defined branches for when something deviates. And postconditions are what must be true once the use case has completed successfully.

Bounding the Use Case

Preconditions and Postconditions

Preconditions and postconditions bound the use case. A precondition is a gate, not a branch. It states what must already be true before the use case may start. For example, the shopper is logged in. If a precondition is not met, the use case simply does not begin. That is different from starting, and then branching. A postcondition describes the guaranteed end state. For example, the item now appears in the shopper's wishlist. A good postcondition is an outcome, not a step. It should be checkable from outside the system, whichever path got there. This is the same before and after discipline as formal specification, applied in plain language to a whole interaction.

Flows

1 Clean Path, Anchored Branches

The main flow is the single, most common path. It is written as a clean back-and-forth exchange. The actor does something, and the system responds, from trigger to success. There is no branching logic inside it. Any point where something could go differently gets pulled out into its own alternate flow, anchored to the main-flow step where it diverges. An alternate flow then either rejoins the main flow at a later step, or ends the use case in its own, still defined, outcome.

Figure 1

An Alternate Flow, Anchored

Here is the wishlist use case as a flow. The shopper selects an item, and taps save. The system checks the wishlist, adds the item, and the shopper sees a confirmation. At step three, something could go differently. The item might already be saved. That becomes alternate flow three A. The system shows a message, and adds no duplicate. Then it rejoins the main flow at step five. And the main flow itself never needed an if.

Best Practices

Use Cases That Get Relied On

A handful of habits separate a use case that gets relied on from one that quietly gets ignored. Write each step as an explicit exchange. Vague, passive steps hide who does what, and are hard to verify. Keep the main flow free of conditionals. Writing if in the main flow is a sign the content belongs in an alternate flow. Cover the alternates that have real consequences, not every conceivable edge case. Completeness is not the same as exhaustiveness. Make postconditions checkable from outside the system. And anchor every alternate flow to a step number, so it is not lost, and can be verified.

Why This Matters

Checkable, Not Just Readable

Why go to this trouble? Because a use case built this way is checkable, not just readable. Someone who never had the original conversation can still verify, step by step, whether an implementation actually satisfies it.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. A precondition is what must already be true before a use case is allowed to begin. If it is not met, the use case simply does not start. A postcondition is the guaranteed, checkable end state once a use case has completed successfully. The main flow is the single, expected sequence of steps from trigger to success, written free of branching. And an alternate flow is a defined branch, anchored to a main-flow step, that either rejoins later or ends on its own.

Key Takeaways

What to Carry Forward

To pull this together. A written use case gives a scenario fixed fields, in a fixed order. Preconditions gate whether it starts. Postconditions state a checkable outcome. The main flow stays free of branches, and every alternate flow is anchored to a step. Cover the alternates that matter, not every conceivable one. And a use case built this way can be checked by someone who was never in the room.

About Software Engineering at UPI Study

Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take Software Engineering with UPI Study

How professional software gets builtSoftware Engineering covers how teams turn requirements into working, maintainable software: process models, agile, requirements, design, testing, reliability and project management. It is a core course in computer science and software degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Thomas Edison State UniversityThomas Edison State UniversitySigned partnerUniversity of the PeopleUniversity of the PeopleSigned partnerCharter Oak State CollegeCharter Oak State CollegeSigned partnerStrayer UniversityStrayer UniversitySigned partnerColumbia Southern UniversityColumbia Southern UniversitySigned partnerIndiana TechIndiana TechSigned partnerPenn StatePenn StateWorks with NCCRSSouthern New Hampshire UniversitySouthern New Hampshire UniversityWorks with NCCRSSUNYSUNYWorks with NCCRS +many more cooperating universitiesFind my college →

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About Documenting Use Cases: Diagrams, Templates, and Best Practices

What fields should a use case template include?
A complete use case template typically includes a name or ID, the actors, the trigger, preconditions, the main flow, alternate flows, and postconditions. The name states the actor's goal, the trigger is the event that starts it, and the flows describe the steps. Using the same fields in the same order lets any reader find a precondition or branch quickly.
What is the difference between a precondition and a postcondition in a use case?
A precondition is what must already be true before a use case may begin, such as the shopper being logged in. If it is not met, the use case does not start at all. A postcondition is the guaranteed end state after successful completion, such as the item appearing in the wishlist. A good postcondition is an outcome checkable from outside the system.
What is the difference between a main flow and an alternate flow in a use case?
The main flow is the single, most common sequence of steps from the trigger to success, written as a clean exchange between actor and system with no branching. An alternate flow is a defined branch anchored to the main-flow step where things diverge, such as an item already being saved. It either rejoins the main flow later or ends with its own defined outcome.
What are best practices for writing use cases?
Write each step as an explicit exchange showing who does what, and keep the main flow free of conditionals, since an if signals content for an alternate flow. Cover alternates with real consequences rather than every conceivable edge case. Make postconditions checkable from outside the system, and anchor each alternate flow to a step number so it can be verified.

About the Software Engineering course

How many college credits is Software Engineering?
Software Engineering (Computer Science 301) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does Software Engineering cost and what is included?
$250, paid once, with lifetime access: all 103 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does Software Engineering take?
It is self-paced with no deadlines. The 103 lessons total about 11 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in Software Engineering.

103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Enroll in Software Engineering →Download the syllabusEvery course with PRO →
Software Engineering
3 credits · NCCRSEnroll →