What Makes Good Requirements? Engineering Essentials

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

What Makes Good Requirements? Engineering Essentials

Software Engineering · Chapter 6: Requirements Engineering and PrototypingSection 6.3 · lesson 40 of 1038 min · free with a free account

← Prototyping Software: Building to LearnNext lesson: Capturing Requirements Through Real-World Scenarios →

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

5 characteristics of a good requirement, and the 5 activities that keep it good.

  • Explain why the quality of each requirement matters
  • Identify the 5 characteristics of a good requirement
  • Describe the 5 activities of requirements engineering
  • Rewrite a weak requirement, and explain why management never stops

Transcript

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

Requirements Engineering and Prototyping

What Makes Good Requirements?

Some requirements help a team enormously. Others actively mislead it. This section covers what separates the two. The five characteristics of a good requirement, and the five activities that gather requirements and keep them correct.

"Quickly"

Nobody Was Careless

A client tells a team that the search feature should return results quickly. Six months later, the team delivers a search that returns results in about three seconds. The client is furious. They expected well under a second. Nobody involved was careless, and nobody disagreed with what was written down. The requirement itself simply never said what quickly meant, in a number anyone could check.

Why Quality Matters

The Foundation Everything Rests On

A requirement is a statement of something the software must do, or a quality it must have. It is described from the perspective of what is needed, rather than how it will be built. Requirements are the foundation every later activity depends on. Modeling, construction, and testing all rest on them. And a flawed requirement does not stay contained. It gets built into a design, then written into code. Then it is covered by tests drawn from the same flawed understanding. The longer it goes unnoticed, the more it costs.

Table 1

5 Characteristics of a Good Requirement

Five characteristics separate a requirement a team can build against from one that only looks finished. Clear means plain, specific language. The system should handle errors gracefully fails it. Unambiguous means only one reasonable interpretation. The report should update regularly fails it. How often is regularly? Testable means a concrete way exists to check it. The app should feel fast fails it. Feasible means achievable within real technology, time, budget, and skill. And traceable means linked to where it came from, and to what implements and verifies it.

A Fine Distinction

Clear Is Not the Same as Unambiguous

Two of these are easy to confuse. Clear, and unambiguous. Clear is about how easy the requirement is to read and parse. Unambiguous is about how many readings it allows. Two different readers, given the same text, should describe the same thing. A requirement can technically have only one correct reading, and still be hard to parse. So a good requirement needs both.

Table 2

5 Activities of Requirements Engineering

Producing good requirements is a small process of its own, with five activities. Elicitation gathers requirements from stakeholders, through conversation, observation, and other means. Analysis examines what was gathered for conflicts, overlaps, and gaps, and turns it into an organized set. Specification writes the analyzed requirements down in a clear, structured, agreed form. Validation checks with stakeholders that the specification reflects what is actually needed. And management keeps requirements current and traceable as the project proceeds. It routinely reopens the earlier activities.

Before and After

Rewriting "Quickly"

Let's go back to the opening requirement. The search feature should return results quickly. It has no measurable threshold, so quickly means something different to each reader. Here is a rewritten version. A keyword search over the product catalog must return the first page of results within five hundred milliseconds, for ninety-five percent of queries. And that is measured under normal production load.

Why the Rewrite Works

All 5 Characteristics at Once

The rewrite passes all five characteristics at once. It is clear, because it names the specific feature and condition in plain language. It is unambiguous, because five hundred milliseconds for ninety-five percent of queries admits no competing reading. It is testable, because a team can measure response time directly and compare it to the number. It is feasible, as long as the number was set with real infrastructure in mind. And it becomes traceable once it is linked back to the stakeholder who needed it, and forward to the code and test that satisfy it.

A Process, Not a Step

Requirements Keep Moving

Requirements are not gathered once and then frozen. Stakeholder understanding evolves, business needs shift, and new information surfaces throughout a project. That is exactly why management is ongoing, rather than a step that finishes at sign-off. How often the other activities get revisited depends partly on the process. A single pass typically front-loads requirements work once. An iterative effort revisits it every cycle.

Figure 4

Frozen Requirements, Moving Need

This picture shows what happens over time. The solid line is the actual need. It keeps moving as the project goes on. The dashed line is what the requirements say when nobody manages them. They stay frozen at sign-off, and the gap keeps growing. That gap is effort spent building the wrong thing. The stepped line shows managed requirements. They are brought back in line with the real need every cycle, so the two keep tracking each other.

Table 4

When Management Lapses

Here is what a lapse in requirements management tends to cost. The team builds the wrong thing, putting effort into an outdated understanding of the need. Traceability is lost. Nobody can say why a requirement exists, or what depends on it. Scope becomes disputed, as stakeholders and the team disagree about what was promised. And the correction comes late and expensive, when the mismatch finally surfaces after delivery.

Apply It

"The System Should Be Secure"

Let's practice on another weak requirement. The system should be secure. It fails testable, because there is no concrete way to check whether secure has been achieved. And it fails unambiguous, because different readers could mean entirely different protections. A rewrite might say that user passwords must be stored with an approved hashing algorithm. And that login attempts must be limited to no more than five failures per account per hour. Both parts can be verified directly, and linked to whoever required them.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. A requirement states something software must do, or a quality it must have. Elicitation gathers requirements, and specification writes them down in an agreed form. Validation confirms, with stakeholders, that the specification reflects the real need. Requirements management keeps requirements current and traceable as the project proceeds. Traceability is the ability to track a requirement forward to what implements and verifies it, and backward to its origin. And a testable requirement has a concrete, objective way to check whether it has been satisfied.

Key Takeaways

What to Carry Forward

To pull this together. A flawed requirement gets built into the design, the code, and the tests before it is caught. Good requirements are clear, unambiguous, testable, feasible, and traceable. The requirements engineering process has five activities. Elicitation, analysis, specification, validation, and management. Adding a measurable threshold turns a vague wish into something a team can build and test against. And management is ongoing. Left alone, documented requirements drift away from the real need.

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 What Makes Good Requirements? Engineering Essentials

What are the characteristics of a good software requirement?
A good requirement is clear, unambiguous, testable, feasible, and traceable. Clear means plain, specific language. Unambiguous means only one reasonable interpretation. Testable means a concrete way exists to check it. Feasible means it is achievable within real technology, time, budget, and skill. Traceable means it links back to its origin and forward to the code and tests that satisfy it.
What are the five activities of requirements engineering?
The five activities are elicitation, analysis, specification, validation, and management. Elicitation gathers requirements from stakeholders. Analysis examines them for conflicts, overlaps, and gaps. Specification writes them down in a clear, agreed form. Validation checks with stakeholders that the specification reflects the real need. Management keeps requirements current and traceable throughout the project and often reopens the earlier activities.
How do you make a vague requirement testable?
Replace vague words with a measurable threshold and specific conditions. For example, the search should return results quickly can be rewritten as a keyword search over the product catalog must return the first page of results within 500 milliseconds for 95 percent of queries under normal production load. A team can then measure response time directly and compare it to the number.
What is the difference between a clear requirement and an unambiguous requirement?
Clarity concerns how easy a requirement is to read and parse, while unambiguity concerns how many interpretations it allows. An unambiguous requirement leads different readers to describe the same thing. A requirement can technically have only one correct reading and still be hard to parse, so a good requirement needs to be both clear and unambiguous.

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 →