Formal Techniques in Software Engineering: Concepts and Practice

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

Formal Techniques in Software Engineering: Concepts and Practice

Software Engineering · Chapter 2: Iterative, Incremental, and Specialized Process ModelsSection 2.7 · lesson 17 of 1036 min · free with a free account

← Constructing Software from Reusable Components (CBSE)Next lesson: Putting the Unified Process to Work in Projects →

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

Precise, mathematical specification - what it is, where it fits, and when it pays.

  • Explain what makes an approach formal
  • Explain why formality is independent of process shape
  • Define precondition, postcondition, and invariant
  • Weigh the strengths and costs, and where formal methods are used

Transcript

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

Iterative, Incremental, and Specialized Process Models

Formal Techniques

Every process model so far answers one question. When does work happen, and in what order? This section turns to a completely different question. How precisely is what is being built actually stated? Formal techniques answer it, and they can attach to almost any approach already covered.

A Different Question

How Precisely Is It Stated?

Most requirements and designs are written in ordinary language, in English sentences describing what a system should do. Ordinary language is flexible and easy to read. But it is genuinely ambiguous. Two careful readers can take the same sentence two different, equally reasonable ways. That rarely matters on a restaurant menu. It matters a great deal for a system controlling a medical device, or moving money between accounts. Formal techniques replace, or supplement, the natural-language description with a specification in precise mathematical notation. Every statement has exactly one meaning. And because it is mathematical, it becomes possible to prove that certain properties hold, rather than simply testing the cases someone happened to check.

Where It Fits

A Separate Axis

This chart shows where formal techniques fit. Across the bottom are the process patterns covered so far. Linear, iterative, and risk-driven. They decide how the work is scheduled. Up the side is a second, independent axis. How rigorously the work is specified, from natural language up to formal mathematics. Formal methods sit on that second axis. So they can pair with any of the process patterns below them.

Not a Rival Process

Formality Pairs With Any Model

Formal techniques do not compete with the process models for the job of organizing work. A project could run a strictly sequential process, with a fully formal specification written during its requirements stage. Or an iterative process, where each cycle's design is formally checked before construction begins. It is tempting to list formal methods alongside the process patterns, as if choosing them meant giving up an iterative structure. That is a mistake. Formality is about the specification's language, not the project's schedule. In practice, formal techniques are rarely applied to a whole large system. They appear around specific components, where being provably right justifies the effort.

Formal Specification

3 Ideas Do Most of the Work

A formal specification describes an operation with a few precise statements, instead of a paragraph of prose. Three ideas do most of the work. A precondition states what must already be true before an operation may run. For a bank withdrawal, the balance must be at least the amount being withdrawn. A postcondition states what must be true immediately after the operation completes. The new balance equals the old balance, minus the amount withdrawn. And an invariant states what must remain true at every point, whichever operation just ran. The account balance can never drop below zero.

Written Precisely

Withdraw, as a Checkable Claim

Here is the withdrawal written in a formal style. The precondition says the balance is greater than or equal to the amount. The postcondition says the new balance, written balance prime, equals the old balance minus the amount. And the invariant says the balance is always greater than or equal to zero. Stated this way, withdraw funds is no longer a sentence open to interpretation. It is a precise claim, which can be checked against an implementation with mathematical rigor, rather than only tested on a few examples.

Strengths and Costs

Certainty, at a Price

The appeal of formal techniques is confidence. For the properties written into the specification, a formal proof is a much stronger guarantee than a test suite, which only shows that the tried cases worked. That is why formal techniques show up disproportionately where failure is catastrophic, not merely inconvenient. Flight control software, medical device firmware, rail signaling, and security-critical components, where one unnoticed flaw could cost lives. The cost is real, too. Writing and checking a formal specification takes specialized mathematical and logical training most teams do not have, and it is slow next to an ordinary requirements document.

Why This Matters

Proven Right, or Right to Prove?

It is worth being clear about what a formal proof guarantees. It shows only that an implementation satisfies its specification. If the specification itself failed to capture what people actually needed, a perfectly proven system can still be the wrong system. Formality buys certainty about a narrow, precisely stated claim. Not certainty that it was the right claim to make. Getting the specification right still depends on the careful analysis work covered earlier. That is why formal techniques tend to appear around small, well-bounded, high-consequence components.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. Formal methods specify or verify a system using precise mathematical notation, instead of, or alongside, natural language. A precondition states what must be true before an operation may run. A postcondition states what must be true immediately after it finishes. And an invariant states what must remain true at every point in a system's operation.

Key Takeaways

What to Carry Forward

To pull this together. Formal techniques replace or supplement ambiguous prose with precise, mathematical specification. Formality is independent of process shape, and pairs with linear, iterative, or risk-driven work. Preconditions, postconditions, and invariants turn an operation into a precise, checkable claim. A proof gives far stronger certainty than testing, but costs real skill and time. And a proof shows that a system meets its specification. It does not show that the specification was right.

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 Formal Techniques in Software Engineering: Concepts and Practice

What are formal methods in software engineering?
Formal methods specify or verify a system using precise mathematical notation instead of, or alongside, natural language. Every statement has exactly one meaning, so certain properties can be proven rather than only tested. Formality concerns how precisely work is specified, not how it is scheduled, so it can pair with linear, iterative or risk-driven processes, usually around specific high-consequence components.
What is the difference between a precondition, a postcondition and an invariant?
A precondition states what must be true before an operation may run, a postcondition what must be true right after it finishes, and an invariant what must remain true at every point. For a bank withdrawal, the precondition is that the balance is at least the amount, the postcondition is that the new balance equals the old balance minus the amount, and the invariant is that the balance never drops below zero.
Where are formal methods used and what do they cost?
Formal methods appear disproportionately where failure is catastrophic, such as flight control software, medical device firmware, rail signaling and security-critical components. For the properties in the specification, a proof is a much stronger guarantee than a test suite. The cost is real: writing and checking a formal specification takes specialized mathematical and logical training, and it is slow compared with an ordinary requirements document.
Does a formal proof guarantee that software is correct?
Not entirely. A formal proof shows only that an implementation satisfies its specification. If the specification failed to capture what people actually needed, a perfectly proven system can still be the wrong system. Formality buys certainty about a narrow, precisely stated claim, not certainty that it was the right claim, so careful requirements analysis is still essential.

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 →