Breaking Down Requirements: Classes, Functions, and Behaviors

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

Breaking Down Requirements: Classes, Functions, and Behaviors

Software Engineering · Chapter 7: Behavioral Models and Requirements AnalysisSection 7.4 · lesson 50 of 1037 min · free with a free account

← Modeling How Systems Behave Under Different ConditionsNext lesson: Handling Requirements for Web-Based Applications →

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

Reading the same requirements as classes, functions, and behaviors.

  • Explain why 1 perspective misses details
  • Describe the class-based, functional, and behavioral perspectives
  • Apply all 3 to a single requirement
  • Use the 3 as a check on coverage

Transcript

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

Behavioral Models and Requirements Analysis

Breaking Down Requirements

Requirements describe a problem from several angles at once. Reading them only one way leaves gaps. This section covers a technique for closing them. Reading the same requirements through three perspectives, class-based, functional, and behavioral. It brings together the class modeling and the state modeling covered earlier.

3 Readings, 1 Question

The Library Team's Blind Spots

A team analyzing requirements for a library checkout system reads through them once, and starts building. Partway through, they realize something. What happens when a member who already has five books, tries to check out a sixth? They never settled what a book actually consists of as a record, or what steps the checkout operation performs. In effect, they read the same sentences three times over. But they only ever asked one kind of question about them.

Why 1 Perspective Isn't Enough

3 Questions, Same Requirements

Requirements written in prose tangle several angles together. What things exist, what the system does, and how it behaves over time. So the technique asks three different questions of the same requirements. The class-based question asks what kinds of things are involved, and how they relate. The functional question asks what the system must actually do. And the behavioral question asks how behavior changes over time, and in response to what. This is an analysis technique, not a new notation. Its output feeds the class modeling and state modeling covered earlier.

Table 1

The Class-Based Perspective

The class-based perspective asks what distinct kinds of things a requirement describes, what data each holds, and how they relate. In practice, you notice every noun that names a meaningful thing, and ask whether it is a class, an attribute of another class, or irrelevant detail. A member checks out a book, so member and book are candidate classes. Record a new loan with a due date. So loan is a class, and the due date is its attribute. And fewer than five active loans tells you a member relates to zero or more loans.

Table 2

The Functional Perspective

The functional perspective asks what the system must actually do, independent of which objects are involved. In practice, you notice every verb phrase describing an action, and ask what triggers it, what it consumes, and what it produces. Verify the member has fewer than five active loans. That is a check, verify loan limit. Record a new loan with a twenty-one day due date. That is record loan. And mark the book unavailable. That is an update, mark unavailable.

Table 3

The Behavioral Perspective

The behavioral perspective asks how behavior changes over time, and in response to events. In practice, you watch for words of condition, timing, or events. Once, after, until, and as long as are reliable signals. Fewer than five active loans is a limit condition on the member. Unavailable until it is returned describes a change in the book. Available, then unavailable, then available again. And when a member checks out a book names the triggering event, the checkout.

Figure 2

1 Requirement, Extracted 3 Ways

Here is one requirement, extracted three ways. When a member checks out a book, verify they have fewer than five active loans. Then record a loan with a twenty-one day due date, and mark the book unavailable until it is returned. The class-based reading pulls out member, book, and loan, with the due date as an attribute of loan. The functional reading pulls out three operations. Verify the loan limit, record the loan, and mark the book unavailable. And the behavioral reading pulls out the loan limit condition, and the book's change of state at checkout and return.

Putting Them Together

A Check on Coverage

Applying all three perspectives is a way of checking coverage. If all three surface consistent, reinforcing detail, as the library requirement does, that is a sign it has been thoroughly analyzed. If a requirement fits none of the three questions, it deserves a second look. It may not be a genuine requirement, or it may have been misunderstood. And while reading, certain language signals each perspective. Nouns for class-based, verb phrases for functional, and timing and condition words for behavioral.

Apply It

Publishing a Course

Let's apply that. An instructor can publish a course only after at least one module has been added. The class-based perspective extracts instructor, course, and module, and notes that a course needs at least one module. The functional perspective extracts an operation, publish course, with a check that at least one module exists. And the behavioral perspective extracts a state change, from unpublished to published, blocked until the module condition is met.

A Common Mistake

Reading Only for the Next Deliverable

Here is a common mistake. A team applies only the class-based perspective to a whole requirements document, because their next deliverable is a class diagram. Later, major behavioral gaps, like unhandled edge cases and missing state transitions, surface only during testing. The deliverable narrowed the questions they asked. And fixing those gaps in testing costs far more than catching them during analysis.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. The class-based perspective analyzes requirements for the distinct things involved, their attributes, and their relationships. The functional perspective analyzes requirements for the specific operations the system must perform. The behavioral perspective analyzes how something changes over time, and in response to events. And those perspectives find attributes, which are data belonging to a class, functions, which are operations, and states, which are conditions something can be in.

Key Takeaways

What to Carry Forward

To pull this together. Requirements mix things, actions, and behavior. Reading through only one perspective misses what another would catch. The class-based perspective finds things and relationships. The functional perspective finds operations. The behavioral perspective finds change over time. Consistent findings across all three suggest a well-analyzed requirement, and one that fits none deserves a second look. And it is a way of reading, not a new notation. Its findings feed straight into class and state modeling.

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 Breaking Down Requirements: Classes, Functions, and Behaviors

What are the class-based, functional, and behavioral perspectives in requirements analysis?
They are three different questions asked of the same requirements. The class-based perspective asks what things are involved, what data they hold, and how they relate. The functional perspective asks what operations the system must perform. The behavioral perspective asks how behavior changes over time and in response to events. This is an analysis technique, not a new notation, and its findings feed class modeling and state modeling.
How do you analyze one requirement from three perspectives?
Read it for nouns, verb phrases, and timing or condition words. For "when a member checks out a book, verify fewer than five active loans, record a loan with a 21-day due date, and mark the book unavailable until returned," the classes are member, book, and loan, with due date as a loan attribute. The functions are verify loan limit, record loan, and mark unavailable. The behavior is the loan-limit condition and the book's state change.
Why does analyzing requirements from only one perspective miss details?
Prose requirements tangle together what things exist, what the system does, and how it behaves over time, so asking only one kind of question leaves the other angles unexamined. A team that reads only for classes because its next deliverable is a class diagram may miss edge cases and missing state transitions. Those gaps then surface during testing, where fixing them costs far more than catching them during analysis.
How can the three requirement perspectives be used as a coverage check?
If the class-based, functional, and behavioral readings all surface consistent, reinforcing detail, that is a sign the requirement has been thoroughly analyzed. If a requirement fits none of the three questions, it deserves a second look, because it may not be a genuine requirement or may have been misunderstood. Language helps: nouns signal classes, verb phrases signal functions, and words like once, after, until, and as long as signal behavior.

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 →