Requirements Engineering and Use Case Modeling
Prerequisite Knowledge
This lecture builds on the following concepts from earlier lectures. If any feel unfamiliar, review the linked notes before proceeding.
Previously Covered in This Subject
- The Unified Development Process and the iterative model — covered in Lectures 2 and 3
- Use case analysis and naming use cases (verb + noun) — covered in Lecture 2
- Writing requirements as use case stories — covered in Lecture 3
- What makes a valid use case — covered in Lecture 4
- Rapid prototyping — covered in Lectures 2 and 3
This topic covers two connected areas. The first part recaps the unified development process (UDP) model and then explains why requirements engineering is the hardest part of building software. The second part defines what a software requirement is, walks through the requirements engineering process, lists the techniques used to capture requirements, and ends with use case modeling, the de facto standard technique for requirement analysis. These notes are the foundation for the object-oriented analysis phase that follows.
5.1 The Unified Development Process Model (Recap)
The topic opens by returning to the unified development process (UDP) model. The discussion centers on a diagram of the model, and the instructor first asks what the diagram implies. The answers show that the diagram is about planning the entire project work.
Hook. A software project can go wrong in a thousand ways, and most of them are only discovered months after they were introduced. What would a development process have to look like so that problems surface while they are still cheap to fix — rather than in the last week before delivery? That is exactly the question the UDP diagram answers.
5.1.1 What the UDP Diagram Shows
The UDP diagram shows the project lifespan running from inception to transition. Three key observations follow from the diagram:
- Inception and transition are very small phases, so they need very small iterations. Within one iteration, the team completes a small slice of work.
- Most of the work is done by elaboration and construction. The project lifespan is shown as the progress across these phases.
- Different colors in the diagram stand for different aspects of the work. The circles are iterations. The team starts with small iterations and keeps building on them.
The most important message of the diagram is that iterations reduce risk. As the project moves on, the team is able to identify problems early, because each iteration surfaces issues that would otherwise stay hidden until late in the project.
Intuition + analogy. Think of the UDP diagram as the blueprint for building a multi-floor building. You do not pour the foundation, then silently construct all ten floors, and only discover at the end that the sixth floor cannot bear its own weight. Instead, you build one floor, inspect it, fix what is wrong, and then build the next floor on top of a floor you already trust. Each iteration is one completed floor: a small slice of working, tested software. The analogy breaks in one place — a building cannot be restructured cheaply, but software iterations are exactly where restructuring is still affordable, because only a small amount of code exists yet.
The four phases of the UDP. The horizontal flow of the diagram runs through four phases, each with a distinct goal:
| Phase | Goal | Typical size |
|---|---|---|
| Inception | Establish the business case, vision, and scope; decide whether the project is worth doing at all | Small — a few days to a few weeks |
| Elaboration | Build the core architecture and resolve the highest risks; most use cases are written here | Largest analysis-and-design effort |
| Construction | Build the remaining, lower-risk features iteratively until the product is ready to deploy | Largest implementation effort |
| Transition | Beta testing, deployment, training, and handover to users | Small — the final stretch |
Inside each phase the work is organized into iterations: short, timeboxed cycles in which the team analyzes, designs, implements, and tests a small slice of functionality. The different colors in the diagram represent different kinds of work (requirements, design, implementation, testing, and so on); the curves rise and fall through the phases because the emphasis of the work shifts — design work peaks in elaboration, implementation work peaks in construction.
Worked example: tracing a library system through the UDP. Suppose a university wants a new library loan system.
- Inception, one short iteration: The team interviews the librarian, writes a two-page vision statement ("students and staff can borrow, return, and reserve books online"), lists the actors, and sketches a rough schedule. The university decides the project is worth funding.
- Elaboration, three iterations: Iteration 1 builds the riskiest piece — the loan/reservation logic and its database, with a prototype screen. Iteration 2 adds search and the fine-calculation rules; Iteration 3 hardens the architecture (concurrency when 200 students reserve the same book). Each iteration ends with tested, working code and a demo to the librarian.
- Construction, two iterations: With the architecture proven, the remaining work is mostly straightforward: reports, the librarian's administration screens, and email notifications. Problems now are cheap because they are small and localized.
- Transition, one iteration: The system is deployed on the library's servers, staff are trained, and the old card catalog is retired.
The numbers are illustrative, but the pattern is the point: the riskiest work happens first, while the iteration count is small enough that each problem found still fits in one iteration to fix.
This is the normal flow of the unified development process model in general. Specific projects have their own specific variations, and nothing in the model is mandatory.
Q: What does this diagram show about the unified development process model? A: The diagram shows iterations, not phases running in parallel. Inception and transition are small phases with small iterations, and most of the work is done by elaboration and construction. The circles are iterations that start small and reduce risk as they build up, and problems get identified as the project moves on. This is the normal flow of the unified development process in general.
Pitfalls.
- Treating the phases like waterfall stages: "finish all analysis, then all design, then all code." In the UDP, every iteration mixes analysis, design, implementation, and testing.
- Assuming the diagram's curves mean phases run in parallel. The phases run in sequence, one after another; it is the work within each phase that is divided into iterations.
- Believing the diagram is a contract. It is a template; a specific project is allowed — and expected — to reshape the iteration plan to its own risks and team.
- Expecting an iteration to deliver "everything." An iteration is a small slice of working functionality, not the whole product.
Real-world: Teams do not have to adopt the UDP as a rigid framework. Any project can be started with the UDP and customized with variations that fit the team and the problem. Modern agile methods (Scrum, XP) are variations of the same underlying idea: short iterations, early feedback, and risk reduction through frequent delivery.
5.1.2 Optional by Design: Only the Fundamentals Are Required
The UDP is deliberately flexible. A team does not need to stick to a single label such as waterfall, iterative, or agile. It is free to use any best practices that suit a particular project.
- Everything is optional. Nothing is mandatory, and a particular team can grow its own way of working.
- A few fundamental things must still be there: iterative development, an architecture-oriented approach, and a user-centric approach.
- The product should be developed as early as possible. Programming and testing should start early by building prototypes.
- Agile best practices are welcome wherever the goal is to deliver the product as early as possible through iterative approaches.
In practice, all the different process models studied in earlier software engineering and management courses are part of the unified development process. For any project you can customize the UDP and start with variations.
The disciplines behind the colors. The colors in the UDP diagram are the disciplines — the ongoing streams of work that run through the whole project:
- Business modeling — understanding the organization and its processes.
- Requirements — discovering and recording what the system must do (the subject of the rest of this lecture).
- Design — translating requirements into a solution structure (the OO design phases of this course).
- Implementation — writing and integrating code.
- Test — verifying each iteration's slice of work.
- Deployment — packaging, releasing, and handing over the product.
Supporting disciplines (project management, environment/tools, configuration and change management) plan and enable the work. The relative effort of each discipline rises and falls across the phases, which is why the diagram uses colored curves rather than fixed blocks.
Scope of the flexibility. The UDP is optional by design, but three fundamentals are not negotiable: iterative development (small slices, frequent feedback), an architecture-oriented approach (the core structure is designed early, in elaboration, because that is where the risk lives), and a user-centric approach (users and their goals drive what gets built). A team that drops all three has stopped following the UDP and is doing unplanned development.
5.1.3 Questions to Prepare
Exam note: Prepare basic questions that an interviewer may ask: what are the different phases in the unified development process, what happens in each phase, what business process disciplines exist in the model, what are the major differences between the UDP and the waterfall model, and what are the advantages and disadvantages of each.
Recap + bridge. The UDP diagram is a plan for the whole project: four sequential phases, each split into small iterations, with work streams (disciplines) that shift emphasis as the project advances. Its single most important idea is that iterations reduce risk — every iteration is a chance to discover a problem while it is still cheap. That process model is only useful if the team knows what to build, and the next topic explains why that part — requirements — is the hardest part of all.
5.2 Why Requirements Engineering Is Hard
From this point the course moves from process models into requirements engineering, which comes before object-oriented analysis. Requirements have already been declared one of the most problematic areas of software development, so it is worth understanding why.
Hook. In civil engineering nobody asks "what is this bridge for?" after the steel is in place — the purpose was fixed before the first pillar was poured. In software, teams routinely discover that the thing they spent a year building is not the thing that was needed. Why is this the one engineering discipline where the hardest question is simply: what are we building?
5.2.1 Requirements Are the Leading Cause of Project Failure
A large number of projects fail because requirements were not done in the right manner: the requirements were not clear, or the requirements were changing. All those challenges are part of the requirements problem. If the requirements are not taken properly, the project will definitely fail, because you need to understand the real requirements.
The class is asked what makes requirements engineering difficult compared with any other engineering discipline. The following answers come back:
Q: Why is requirements engineering difficult for software projects? A: Non-functional requirements stay implicit; they are not explicit. Requirements keep changing as the business needs change, so change management or requirements management is needed and changes must be welcomed. A human element is involved, and the situation varies from project to project.
To capture the real requirements you have to interact with the end users and the domain experts and get the business rules as well. This is the single hardest part of building a software system: deciding what the software system is. No other part of the work ripples through the resulting system so completely if it is done wrongly. It is very difficult to rectify a requirement that was captured and understood wrongly. Requirements guide both the technical process and the management process.
Intuition. A wrong requirement is not a small error — it is a decision error. A coding bug is local: fix one function and the rest of the system is untouched. A wrong requirement is global: the design, the code, the tests, and the documentation are all built around it, and correcting it later means revisiting every layer of the project. That is why requirements mistakes are the most expensive mistakes, and why the activity that produces them is the one that must be done most carefully.
Why requirements lead the list of failure causes. Requirements are the starting point of everything: the plan is built from them, the design is derived from them, and the tests verify them. Three properties of requirements make them dangerous:
- Uncertainty — no two people interpret the same sentence the same way.
- Instability — the business changes while the project runs, so the "final" list is never final.
- Invisibility — the hardest requirements (reliability, security, usability) are never written down anywhere by anyone.
Because all three are present at once, requirements failure is the most common project failure.
Real-world: The software industry runs two parallel streams: a management stream that plans and manages the overall process, and a technical team that does the analysis, design, implementation, and testing. These four phases appear everywhere in the course as OO analysis, OO design, OO implementation, and OO testing, and requirements are the initial part of it.
Worked example: the two streams in a hospital project. Consider the hospital drug information system used later in this lecture. The management stream plans the iterations, assigns the team, and tracks budget and schedule; it never touches code. The technical stream analyzes the pharmacists' needs (requirements), designs the solution (OO analysis and design), writes it (implementation), and checks it (testing). If the requirements step in the technical stream is wrong — say, the team captures "drug interactions" but the pharmacists meant "side-effect warnings for patients" — the error silently flows through design and implementation, and only testing (or worse, the first real deployment) exposes it. The management stream cannot catch this, because management tracks the plan, not the meaning of the system.
5.2.2 Why Requirements Cannot Be Fixed in Advance
In any other engineering discipline the requirements are always fixed. Whether it is a car, an electrical fan, or any device, the requirements are fixed before building. Software is different: if we try to fix all requirements up front, we will fail.
A well-known study supports this. In 65% of projects where the waterfall model was followed, 65% of the requirements that were gathered initially were never implemented. So all the requirements cannot be defined beforehand for software.
The learning lesson is that requirements must be elicited as the project proceeds. Even so, the basic idea of the business case of the project needs to be defined so that the work can start somewhere. That is what requirements engineering does: get as much understanding as needed, because what the customers say they want may not be what they need.
Intuition + analogy. Fixing all requirements in advance is like a chef asking a dinner guest to choose the entire menu six months before the dinner. The guest cannot possibly know what they will feel like eating on the day; the chef who insists on the fixed menu will serve a lot of untouched plates. Software requirements behave the same way: the business discovers what it needs while the system is being built, because building it changes what the business imagines. Requirements engineering is not about getting one perfect menu — it is about a menu that is allowed to change, one course at a time.
Worked example: why the fixed list failed. A government agency plans a permit-tracking system using a strict waterfall. In month 2, analysts collect 200 requirements and freeze them. By month 12, a new regulation changes the approval process, the agency reorganizes, and customers begin submitting applications online instead of on paper. Of the original 200 requirements, roughly two thirds are never implemented — not because they were wrong on day one, but because the world moved. The statistics quoted in the lecture say this is the norm, not the exception: in 65% of waterfall projects, about 65% of the initially gathered requirements were never implemented. The lesson is structural: do not freeze; elicit continuously.
Q: Why can requirements not be fixed for software, when they can be fixed in other engineering disciplines? A: A car, an electrical fan, or any device has fixed requirements. Software is different. In 65% of projects where the waterfall model was followed, 65% of the requirements gathered initially were never implemented. So requirements cannot all be defined beforehand; they are elicited as the project proceeds.
Pitfall — the frozen requirements list. The tempting antidote to "requirements keep changing" is to freeze the list and refuse changes. That is exactly the waterfall trap: the list freezes, the business does not, and the delivered system satisfies a document nobody still wants. The UDP answer is the opposite of freezing — requirements are re-visited every iteration, and change is handled by a change-management process rather than by pretending change does not exist.
5.2.3 Implicit Requirements and Constraints
When someone says "requirements", they usually mean the behavioral or functional aspect very specifically. The non-functional requirements are different: they are implicit in the project.
- The software should be reliable. If the software is not reliable, nobody will use it.
- The software should be efficient.
- The software should be highly usable. People should be happy to use the software.
- The software should be dependable.
Nobody states these requirements explicitly. Top managers may mention them collectively, but in general you have to take real effort to get them, and you have to ask questions, because the user may not be able to say them.
Two more categories are usually missed when people capture only functional and non-functional requirements:
- Constraints: restrictions, resource restrictions, or language restrictions. These should also be mentioned in the SRS.
- Business rules or domain rules: general rules such as government rules and legal data protection laws apply everywhere, but a particular organization also has internal business rules that only domain experts know. All applications must follow them.
Usually all the requirements are grouped as functional requirements plus a supplementary specification. If some issues are not clear, you can document them as open issues as well. Too much documentation is not required.
The four categories of requirements — and which ones get missed.
| Category | What it is | Example | Why it is missed |
|---|---|---|---|
| Functional requirements | What the system must do | "The system shall print a receipt" | Rarely missed — these are the obvious "requirements" |
| Non-functional requirements | How well the system must do it | reliability, efficiency, usability, dependability | Implicit — nobody writes them down |
| Constraints | Boundaries on the solution | budget, deadline, technology, language, platform | Forgotten in the SRS unless explicitly added |
| Business rules / domain rules | Rules the domain obeys, independent of any system | tax law, data protection law, company credit-limit policy | Only domain experts know them; they are invisible to outsiders |
The standard packaging: functional requirements (plus non-functional and constraints) are grouped in the requirements document — the SRS, or the supplementary specification for the non-functional part — and open questions are recorded as open issues rather than being silently resolved. The lecture's warning applies to all of this: too much documentation is not required; capture what is needed, not everything imaginable.
Pitfall — treating non-functional requirements as decoration. A system that performs all functions but is slow, unreliable, or unusable will be rejected in practice. Non-functional requirements are not optional extras; they are often the difference between software that exists and software that is used. Since nobody states them, the analyst must actively question users and managers about reliability, efficiency, usability, and dependability — and record the answers.
Real-world: A full requirements analysis course is not offered here, but some guidelines are needed to start. Given any documents or the requirements that are there, you need to understand them first; only then can you perform use case analysis. Functional requirements are usually given as a high-level requirements list that you need to analyze to see whether each one is really needed.
5.2.4 Challenges Teams Face
The functional part of requirements is not that difficult by itself, but sometimes even complete functional requirements become challenging. The main challenges to remember are:
- Non-functional requirements are not explicit and must be drawn out.
- Requirements keep changing as the business needs change, so change management is needed.
- A human element is involved, and the situation varies from project to project.
- If requirements are captured wrongly, the project will definitely fail.
Recap + bridge. Requirements are the leading cause of failure because they are uncertain, unstable, and invisible: they cannot be frozen in advance, the most important ones are implicit, and every mistake ripples through the whole project. The remedy starts with a precise definition of what a requirement actually is — and that is exactly the next topic.
5.3 What Is a Software Requirement?
The instructor asks the class to write a definition of a software requirement in their own words. Definitions matter, and an interviewer may ask for one.
Hook. "Make the app fast." "The system should be user friendly." These sound like requirements — until two engineers read them and build two different systems. Every requirements failure starts with a definition problem: a sentence that seems clear and is not. A rigorous definition of requirement is not academic pedantry; it is the first line of defense against ambiguity.
5.3.1 A Working Definition of a Software Requirement
Student definitions of a software requirement included the following ideas:
- It is not about digitizing the existing way of working.
- It is the capability or the conditions fulfilled by your software system.
- The system, seen as a black box, provides these services and shows the user the outcome result.
- It is the capability needed by the user and the need for software to accomplish a desired goal.
- The system will provide the exact behavior needed to accomplish the goal.
The instructor confirms that a requirement is a capability, and it must be defined in an unambiguous manner. It is not exactly mathematical, but it must be written in a way that removes ambiguity, because English statements carry a lot of ambiguity. The IEEE definition captures this: a capability needed by the user to solve a problem or achieve an objective, and a condition that must be met by the system. When you say a condition, it must be something where you can tell whether the condition is there or not.
The IEEE 610.12 definition of a requirement (verified against IEEE Std 610.12-1990). The definition quoted in the lecture is the standard two-part IEEE definition of a software requirement:
A requirement is (1) a condition or capability needed by a user to solve a problem or achieve an objective, and (2) a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
The first part is the user's need — the problem to be solved. The second part is the system's obligation — what the delivered system must satisfy. Note the two words that do the work:
- Capability — the system can do something; a requirement is about behavior, not about internal design.
- Condition — a testable state of affairs; you must be able to tell whether the condition holds or not.
That second word is what makes a requirement engineering material rather than a wish: if you cannot check whether the condition is present, you have not written a requirement.
Intuition + analogy. Think of a requirement as a contract between a buyer and a builder — like the specification for a custom kitchen. The buyer does not say "make it nice"; the contract says "a 60 cm oven, induction hob, 8 electrical sockets, cabinets that open with a soft close". Each clause is a condition you can walk into the kitchen and check. A software requirement is the same: a black-box promise. The user cares about what the system delivers (the service and its result), not about which classes or modules produce it. That is why the system is viewed as a black box: requirements describe behavior at the boundary, not internal structure.
A requirement is usually written as a contract or an agreement: when the system is used, this is the capability or service it will give. A specification is a formally imposed document of what we wish to have.
Q: How do you define a software requirement? A: A software requirement is a capability needed by the user to solve a problem or achieve an objective, and a condition the system must meet. It must be defined in an unambiguous manner and is usually written as a contract or specification. Q: Should we capture everything the client wants? A: No. Find the user needs. Needs can be fulfilled, while wants or wishes can never be fulfilled.
5.3.2 Requirements Must Be Testable
Each requirement that you write should be testable. It cannot be ambiguous. For example, "good performance" is not a requirement; "within 10 milliseconds it should be able to answer" is measurable, and you can test it.
There are a lot of misconceptions when requirements are collected. The instructor quotes the classic saying: "I know you believe you understood what you think I said, but I'm not sure you realize that what you heard is not what I mean." This is the biggest challenge in requirements work. We do not want to specify what the client wants; we need to say what the user needs. Needs can be fulfilled; wants or wishes can never be fulfilled.
Worked example: making a requirement testable.
| Written as a wish | Written as a requirement | Why it passes |
|---|---|---|
| The system should have good performance. | The system shall return search results within 10 milliseconds on the standard dataset. | Measurable: a stopwatch test decides pass/fail. |
| The system should be user friendly. | A new user shall complete a checkout without assistance in under 2 minutes, based on usability tests with 10 users. | Observable: the condition can be checked. |
| The system should handle many users. | The system shall support 500 concurrent users with no more than 5% error rate under the load test. | Concrete: the load test is defined. |
The pattern: replace adjectives ("good", "friendly", "fast") with numbers, time limits, and observable criteria. Every requirement you write should be checkable — if a tester cannot write a test for it, an engineer cannot build it deterministically.
5.3.3 Needs versus Wants
If the team tries to go after all the user wishes, it will never implement anything. There are high expectations from software: people think that anything can be implemented in software, and that any change should be made only to the software system. But software also needs an architecture, and not everything should be done. If this is not figured out, the chances of success fall.
Intuition + analogy. The wants-versus-needs distinction is like a patient describing symptoms to a doctor. The patient wants "a pill that fixes everything immediately"; what the patient needs may be a change of diet and exercise over months. If the doctor merely fills every wish, no real problem is treated. The analyst plays the same role: listening to what is said, questioning it, and separating the wish from the underlying need. "Needs can be fulfilled; wants or wishes can never be fulfilled" — because a wish is a moving target, and a need is a stable problem to solve.
Real-world: Product owners and analysts spend most of their time separating stated wishes from genuine needs. The needs are the requirements; the wishes are options for later iterations.
5.3.4 Prioritization and Categorization
A requirement is defined as a system feature, capability, or constraint. Constraints must be defined and always given priorities.
- Prioritization is very important for ranking requirements. The most important or most critical requirements should be done first, in the early iterations.
- Categorize the requirements so that you can target and plan your iterations. The whole project management plan is built through these requirements.
- If some requirements are not done, that is acceptable, but the main things must be done.
Different types of requirements exist, and many books are written on requirements, so you should at least categorize what you capture. Every organization has its own template for use cases and requirements. When teams run interactions or workshops, they fill in requirements under those headings through questionnaires.
When collecting requirements, also capture the following context:
- The physical requirement environment in which the software will be deployed.
- The different interfaces through which the software will interact, as part of the overall system.
- The different features of the system.
- The different users, their roles, and their rules.
- The human factors, which are always challenging: level of productivity, academic qualifications, and so on.
About 80% of the work focuses on functionality, and functional software is needed. But once functionality exists, a lot of software has failed or was not used because it was not usable. Documentation and training matter, as do data requirements, existing resources, and constraints such as reliability, security, and portability.
Prioritization and categorization. Requirements are ranked and grouped so the project can be planned:
- Prioritize — rank requirements by importance and criticality; the top-ranked ones are built first, in the early iterations, because they carry the project's value.
- Categorize — group requirements into types (functional, non-functional, constraints, business rules; also environment, interfaces, features, users and roles, human factors). Categories let the team target and plan iterations; the whole project management plan is built from the categorized list.
- Accept trade-offs — not every requirement will be done; what is mandatory is that the main things are done. "If some requirements are not done, that is acceptable, but the main things must be done."
The context matters too: where the software will be deployed (physical environment), which systems it will talk to (interfaces), who will use it (users, roles, rules), and the human factors (productivity levels, qualifications, usability expectations). And the balance to remember: roughly 80% of the effort goes into functionality, but software that is functional yet unusable still fails — documentation, training, data requirements, and constraints (reliability, security, portability) decide whether the software is actually used.
Pitfall — over-capturing. The objective is to get the facts about the system, not very detailed requirements. Every requirement should have a clear objective and be checkable; but drowning the project in documents and fine-grained detail has its own cost: effort spent on text that will change anyway. Capture what is needed — no more, no less. Too much documentation is not required.
5.3.5 Everything Is Not Possible
People think anything can be implemented in software, and any change can be made to the software system. That is a major challenge, because software also needs an architecture. The user wants all changes to be done because it is software, but not everything should be done. If the team does not figure this out, the chances of success drop.
Recap + bridge. A software requirement is an unambiguous, testable capability the user needs and a condition the system must meet — a contract, not a wish list. Requirements are prioritized and categorized so iterations can be planned, and the team must resist the belief that everything is possible. With a definition in hand, the next question is the process: how do we systematically go from these definitions to a validated set of requirements? That is the requirements engineering process.
5.4 The Requirements Engineering Process
Requirement analysis is the process by which customers' needs are understood and documented. It specifies what is to be built, with no solution and no how. In object-oriented analysis we talk only about the requirements and the what of the system.
Hook. When two people disagree about what a system should do, the disagreement is almost never about programming — it is about meaning. The requirements engineering process exists to make meaning explicit: a documented agreement that both the customer and the developer sign, and that every later phase of the project is measured against.
5.4.1 The Requirement Analysis Process
The process follows a simple cycle:
- Find or elicit the requirements.
- Communicate and get an agreement.
- Document them.
Intuition + analogy. The cycle is like a translator's job between two people who do not share a language: first listen carefully (elicit), then confirm what was understood by repeating it back until both nod (communicate and agree), then write it down so the agreement survives (document). A cycle, not a one-way street, because the listening never truly ends — requirements keep changing, so the loop runs repeatedly throughout the project.
Documentation is only for understanding and analysis purposes, through models and pictures rather than heavy text. The requirements will keep changing, and the techniques used for elicitation include use case modeling for functional requirements, plus interviews, interactions, and requirements workshops in which various users take part. User involvement is very important to get the real requirements.
The requirements should be written in the simplest possible English statements. If technical terms are used, the user will not understand. Requirement analysis is often done by people who know computer science and also understand the business, but the technicality should not show in the document.
The documentation is required because it works as a contract between the customer and the developers. It will be used for testing the system and for guiding the whole project development, its increments, and its iterations. Everything is governed by this requirements document, the software requirements specification (SRS).
Pitfall — writing requirements for the wrong audience. A requirements document full of technical jargon is useless for the customer, who must be able to say "yes, this is what we want". Plain-English statements are not a sign of weak analysis; they are the deliverable. Technical precision has its place — in the developer requirements, written afterwards, not in the customer-facing document.
5.4.2 Customer Requirements versus Developer Requirements
There is often conflict between customers and developers. The IT team thinks the requirements should be given to them in a very well formatted way. The client thinks the developer has to come to the workplace and get the requirements. These conflicts need to be simplified.
The solution is to divide the work into two parts:
- Customer requirements (C requirements): the focus is the customer. The customer should be able to say "yes, this is what we want". Write them in whatever format you like, review them with the customer, and update them whenever necessary, in whatever language the customer is happy with.
- Developer requirements (D requirements): a more technical expression of the same content, written in a consistent, clear, and unambiguous manner for the developers.
To do this, identify the customers and their representatives. Interact with every kind of user who will use the system, and with the domain experts. Then write the C requirements, review them with the customer, and later write the D requirements, making sure all inconsistencies are removed.
Capture all the wants and needs first, and then convert them into the real needs. That is the job of the requirement analysis. Then write or document in a manner the user can understand, and later convert the content into a more formal form for the developers.
The two-sided requirements document. One content, two expressions:
| Customer requirements (C) | Developer requirements (D) | |
|---|---|---|
| Audience | The customer and end users | The development team |
| Language | The customer's own language; simplest possible English | Consistent, clear, unambiguous technical form |
| Purpose | The customer signs it: "yes, this is what we want" | The developers build and test from it |
| Review cycle | Reviewed with the customer and updated whenever necessary | Derived from C; all inconsistencies removed |
The analyst's job: interact with every kind of user and the domain experts, capture the wants and needs, convert wants into real needs, document for the customer, then reformulate into a formal D form — and keep the two consistent.
Real-world: This C-to-D conversion is a standard industry practice. Analysts with a computer science background and business knowledge act as the bridge between the two groups.
5.4.3 Worked Example: Hospital Drug Information System
The instructor gives one idea through which requirements analysis can be practiced, from business requirement to developer requirement.
- Business requirement: the hospital needs this system so that doctors and pharmacists know everything about the drugs that are available.
- User requirement: the end user, a doctor or a pharmacist, should be able to enter a drug name and get back information about side effects and other details.
- Developer requirements: take a database of drug names with the scientific name, generic name, or brand names. The system will return all drug names that match a full or partial name. You must specify whether you want an exact match or a partial match. If more than one drug matches, the user will have an option to select one of the drugs.
These challenges need to be listed down. They are the exceptions, and exception handling is part of use case modeling as well.
Worked example: from business requirement to developer requirement (hospital drug information system). This example is the lecture's demonstration of the C-to-D conversion, traced through three levels:
- Business requirement (the "why"). The hospital needs this system so that doctors and pharmacists know everything about the drugs that are available. The value: correct and safe drug information at the moment it is needed.
- User requirement (the "who and what"). The end user — a doctor or a pharmacist — should be able to enter a drug name and get back information about side effects and other details. Notice how the sentence is written in the user's language: no database, no matching algorithm, nothing technical.
- Developer requirements (the "how precisely"). Take a database of drug names containing the scientific name, generic name, or brand names. The system will return all drug names that match a full or partial name. The analyst must specify whether the match is exact or partial. If more than one drug matches, the user will have an option to select one of the drugs.
The jump from level 2 to level 3 is where the analysis happens: "enter a drug name" becomes "full or partial match, exact or partial, one drug or many". Every such decision is a hidden assumption the user never stated — for example, that "Aspirin" should also find "Acetylsalicylic acid" (scientific name) and "Bayer" (a brand). And each decision breeds an exception: what if nothing matches? What if two different drugs share the same brand name? These challenges must be listed down — they are the exceptions, and exception handling is part of use case modeling as well.
5.4.4 Worked Example: Exception Handling in a Cash Payment System
What does exception handling mean in requirements? Exceptions are error conditions. In Java programming or C++, you have done exception handling with a try-catch block. Exceptions are usually missed when the requirements are being captured, and they must be captured too.
There is a normal behavior: in a use case, this is how the case is executed in the normal manner. Normal behavior covers about 90% of the time. The other 10% of the cases are abnormal situations. For each one you need to say: if this happens, this is the way to resolve it.
Worked example: the cash payment use case and its exception paths. The normal path of the payment use case: the cashier accepts cash, counts it, and the system records the payment — this covers about 90% of transactions. The other 10% are abnormal situations, and each one must have a stated resolution:
- A customer pays with a credit card → the system must run a card authorization and record the authorization number.
- A customer pays with an ATM card → a different authorization path.
- The cash amount received differs from the amount due → a "change due" calculation, or a return-to-customer dialog.
- The card is declined → the use case must state what happens next (retry, or switch to cash).
None of these appear in a one-line requirement like "the system shall accept payment". Each is an error condition that must be listed and resolved — if this happens, this is the way to resolve it. This is exactly what the try-catch habit teaches: the happy path is one branch; the error paths are the rest.
Q: What is exception handling in requirements? Give an example. A: Exceptions are error conditions, handled with a try-catch block in Java or C++, covering about 10 percent of the cases. Normal behavior runs about 90 percent of the time. For each abnormal situation you must state how to resolve it. For example, a cashier normally accepts cash, but when somebody comes with a credit card, that option must also be handled.
Exam note: Remember the 90% / 10% split for normal behavior versus exceptions, and the cashier example with cash, credit card, and ATM options.
5.4.5 A Top-Down Approach to Requirement Engineering
Another way to do requirement analysis is top-down. Start at the top with the business case:
- Business case: what is the scope of the system, and what business value will come out of it? Unless there is business value, nobody is going to use the software. Define the vision and scope for the project at this top level.
- User requirements: get the user requirements, because ultimately the users are going to use the system. If the users are not interested in using the system, it is of no use. Use cases are the second aspect.
- System specifications: once the business case and the use cases are defined, define the overall behavior of the system in terms of system specifications, with all the details and data components.
The objectives of the customers or users are the tasks the user needs to accomplish with the system, for which they get some value or result outcome. The functional requirements specify the system behavior that will allow users to perform their task, in a technical manner.
Intuition + analogy. The top-down approach is like planning a restaurant before designing its kitchen: first decide the business case (what kind of restaurant, who comes, why it will succeed), then the user experience (the menu the guests order from), and only then the technical specifications (the equipment and processes that produce the menu). Reverse the order — buy the fryer first, ask questions later — and you get a restaurant nobody wants to eat in. Business value first, user interest second, technical detail last.
Real-world: For the course project, form a group of three or four people and apply object orientation to any system of your choice. The course works through four or five case studies, but you should also work on your own idea.
5.4.6 The SRS, Traceability, and Consistency
In a more organized manner, the C requirements are collected and organized, converted into a more complete set of D requirements, validated, and signed by the customers. The organization of the SRS varies from organization to organization; each company has its own structure and format.
Several properties of a good SRS were emphasized:
- Traceability: it is very important to know who gave each requirement. Later, nobody should be able to say "I don't know this requirement, I didn't give it". Keep a traceability matrix through which you can go back and see who gave what.
- Testability: you should be able to test each of your requirements and have a proof that this is what was done.
- Categorization and prioritization: rank requirements to organize the pool of iterations and increments. The most critical, core architectural requirements should be fulfilled first, then the use cases critical for the business, and the highest risk should be prioritized first.
- Completeness: if a requirement is missing, nobody will use the system and users will say "this is not there".
- Consistency: when different requirements are connected and they are inconsistent, there is ambiguity. Writing 250 miles per hour in one place and 300 miles per hour in another is not acceptable. Give a number to each requirement so you can tell whether it is done.
- Error conditions: exception and error conditions are very difficult to capture. Once the system is deployed, users will show scenarios that were never told when the requirements were captured. Plan for graceful degradation: the software should degrade gracefully and should not crash.
Non-functional requirements are very difficult to isolate. They apply to a particular component or to the overall product, so every non-functional requirement may not be relevant to everything. Document each one wherever it is needed.
The six properties of a good SRS.
| Property | What it means in practice |
|---|---|
| Traceability | Each requirement is linked to its origin — who gave it and why. The traceability matrix lets anyone go back and see who said what; nobody can later deny their own requirement. |
| Testability | Each requirement can be tested, and passing the test is proof the requirement was fulfilled. |
| Categorization and prioritization | Requirements are ranked to organize the pool of iterations and increments: the most critical, core-architectural requirements first, then business-critical use cases, with the highest risk prioritized first. |
| Completeness | Nothing needed is missing — a missing requirement means "this is not there" at delivery, and users refuse the system. |
| Consistency | Connected requirements must not contradict each other. Example: one section states the car's top speed as 250 miles per hour, another states 300 — that is ambiguity, a defect. Numbering each requirement helps check whether it is done. |
| Error conditions | Exception and error paths are captured explicitly, and the system is designed for graceful degradation — it should degrade gracefully, not crash. |
Non-functional requirements are the hardest to place: they may apply to one component or to the whole product, so every non-functional requirement is not necessarily relevant everywhere — document each one wherever it is needed.
Exam note: Remember the consistency example: the same speed written once as 250 miles per hour and once as 300 miles per hour is a defect, and the traceability matrix shows who gave which requirement.
Recap + bridge. The requirements engineering process is a cycle — elicit, agree, document — expressed in two forms: customer requirements the customer signs, and developer requirements the team builds from. The worked examples (drug information system, cash payment) show that hidden decisions and exceptions live inside every requirement, and a good SRS makes them visible through traceability, testability, prioritization, completeness, consistency, and explicit error handling. The remaining question is how the requirements are actually gathered — the capture techniques — which is the next topic.
5.5 Techniques for Capturing and Documenting Requirements
Several techniques capture requirements. Some are conversational, some are visual, and some build working versions of the system.
Hook. If requirements are a contract, how do you get the other party to actually state their terms? Users cannot always say what they need — often because they have never seen anything like the software being proposed. The techniques in this topic are the analyst's toolkit for making the invisible requirements speak.
5.5.1 Interviews, Workshops, and Questionnaires
- Interviews or interactions: talk with users one at a time and ask questions.
- Requirements workshops: conduct workshops and involve various users, making them participate. User involvement is very important to get the real requirements, the real need of the software.
- Questionnaires with templates: every organization has its own template for requirements. During interactions and workshops, people fill the requirements under those headings.
Ask questions about the non-functional requirements as well, because the user may not be able to say them.
The three conversational techniques.
| Technique | How it works | Strength | Watch out for |
|---|---|---|---|
| Interviews / interactions | One user at a time, asked questions directly | Deep, focused answers; follow-up questions are easy | One person's view only; time-consuming per user |
| Requirements workshops | Many users together, actively participating | Different perspectives surface and clash; real needs emerge from discussion | Needs a skilled facilitator; dominant voices can drown others |
| Questionnaires with templates | Organization's own template; participants fill requirements under fixed headings | Consistent, comparable, fast to collect from many people | Template headings may not fit unusual needs; no follow-up |
The common thread: user involvement is the only way to get the real requirements. And because non-functional requirements are implicit, the analyst must ask about them explicitly — the user will not volunteer reliability, usability, or security concerns on their own.
5.5.2 Rapid Prototyping
Rapid prototyping is a very popular technique to connect the requirements and get them from the user. The reason is that users have not seen the software yet. They do not know the capabilities of the system and cannot specify what they need.
With a prototype, users can say what they want. Show only the key functionalities. Do not try to make the prototype perfect; let it crash many times, that is fine. Modify it as early as possible, then convert it into the requirements.
Intuition + analogy. Asking a user to specify software they have never seen is like asking someone to describe the house they want while standing in an empty field. Show them a rough sketch of one room, and suddenly they know: "no, the kitchen should be here, and the window there." A prototype is that sketch — a cheap, throwaway version of the key screens. Users react to something concrete far more easily than they imagine something abstract. The point is not to build a beautiful prototype; it is to trigger reactions. Let it be rough, even broken — reactions are what it is for.
Exam note: A prototype is a requirements tool, not a finished product. The point is to help users make changes early, when changes are cheap.
5.5.3 Diagrams and Storyboards
The D requirements can be expressed with use cases, data flow diagrams, context diagrams, user interfaces, or storyboards. The instructor does not go into detail on each, but points out the following:
- Data flow diagrams were popular in structured analysis for C-programming-like environments. They capture the different processes and the data flow through them. They are still popular and well used in industry.
- In object orientation, data and behavior live together in one capsule, so the data flow diagram is not part of object-oriented analysis and design. The activity diagram is the UML diagram that replaces it.
- State transition diagrams: the system is in different states. An elevator, a fan, or a light button is in an on state or an off state. Users take the system from one state to another, and the diagram captures the states and the events that move the system between them.
- Storyboards or paper prototypes: create some drawings of user screens, connect the user interfaces, and show the workflow with the major elements and actions. The user agrees on the screens and the workflow.
Everything is acceptable; there is no single correct technique. The main challenge is to get the requirements from the customers.
The visual techniques at a glance.
| Technique | What it captures | Where it belongs |
|---|---|---|
| Use cases | Who does what with the system, and the steps | The de facto standard for functional requirements; the main technique of this course |
| Data flow diagrams (DFD) | Processes and the data flowing between them | Structured analysis tradition (C-style environments); still used in industry — but not part of OO analysis, because in OO, data and behavior live together in one capsule |
| Activity diagrams | The UML replacement for DFDs in object orientation; workflows and business processes | UML; used when use case text needs a visual workflow companion |
| State transition diagrams | The states a system can be in, and the events that move it between them | A light button, fan, or elevator: on ↔ off; a user takes the system from one state to another |
| Storyboards / paper prototypes | Drawings of user screens connected to show the workflow, with major elements and actions | User agrees on the screens and the workflow before any code exists |
There is no single correct technique — use the mix that works for the project. The main challenge is always the same: getting the requirements out of the customers.
5.5.4 Worked Example: Writing Measurable Requirements
Write the functional requirements in simple statements that leave no room for doubt:
- Functional: the blood pressure monitor will measure the blood pressure displayed on the filter screen.
- Performance: within 10 seconds.
- Reliability: the failure should be less than 0.01 during the first 500 readings.
All requirements must be testable. You should have a proof that this is what was done, and you should be paid for this. Specify all GUI requirements, interface requirements, and any constraints, timing, and accuracy requirements, each in its own category.
Worked example: a blood pressure monitor requirement set.
| Category | Requirement | How it is tested |
|---|---|---|
| Functional | The blood pressure monitor will measure the blood pressure displayed on the filter screen. | Run the measurement; verify the reading appears on the filter screen. |
| Performance | The measurement completes within 10 seconds. | Time the measurement; it must finish within 10 seconds. |
| Reliability | The failure rate must be less than 0.01 during the first 500 readings. | Run 500 readings; fewer than 5 (0.01 × 500) may fail. |
Every category is documented separately — GUI requirements, interface requirements, constraints, timing, accuracy — and every requirement is testable, because the requirement is the proof of what was done, and the basis for being paid. If you cannot test it, you cannot prove it was done.
Exam note: Remember the numbers: 10 seconds, 0.01, and 500 readings for the blood pressure example.
Recap + bridge. Requirements are captured conversationally (interviews, workshops, questionnaires), experientially (rapid prototyping), and visually (use cases, DFDs, activity diagrams, state diagrams, storyboards) — with no single correct technique. Whatever the technique, the output must be measurable and testable, as the blood pressure example shows. The techniques exist to feed one main artifact, and the lecture now turns to the most important one of them: use case modeling.
5.6 Use Case Modeling
Use case modeling is the de facto standard technique for requirement analysis. The users are the most important part of a software system, and use cases write the users' requirements in context.
Hook. "The system shall print a receipt." Does that sentence mean the cashier prints it, the customer does, or it happens automatically after payment? Out of context, a requirement can mean anything. Use case modeling solves this by refusing to write requirements out of context: every requirement is written as a story of a specific user trying to reach a specific goal.
5.6.1 Use Case Modeling: A De Facto Standard
The earlier challenge with traditional requirement analysis was that requirements were written out of context. A requirement only makes sense in a specific context; outside it, the same text can have multiple meanings. Use case modeling keeps the requirements in context, because the end users and their goals drive the analysis.
The goal is to identify the user goals. In goal-based use case analysis:
- Identify the different users and their goals.
- Prepare a goal list.
- Based on the different goals, define the use cases and the corresponding system functions of the business processes.
The users are roles, not individual persons. Business processes are the rules that are there; the users of those rules are nothing but the rules as well.
Intuition + analogy. A use case is a scene in a movie script. The script does not say "the hero receives information" — it says: the hero enters the café, asks the bartender about the shipment, the bartender checks the ledger and answers. Every line has a speaker and a purpose. A use case is the same: it names the actor, the goal, and the exact exchange between actor and system that achieves the goal. Requirements written this way cannot float free of context — they are anchored to a person, a goal, and a sequence of steps.
5.6.2 Writing Use Cases Is the Main Skill
Writing use cases means writing the textual content of the use cases. Text is more important than drawing the diagrams; the diagram is only a pictorial representation. The main skill to learn is how to write the use cases: the narration of the sequence of events of an actor using the system.
A use case is written as a story:
- When does the use case get started, and when does it end? You write the pre conditions and post conditions.
- What happens in the use case as a sequence of events while the actor is using the system?
Different formats and templates are used in the industry, from big formats to casual formats. One popular format writes the use case as a conversation between the actor and the system: the actor initiates something, the system does something in response. Use cases are just-in-time requirements: you do not need an attachment to those requirements, because they will keep changing, and you will keep enhancing and refining them.
Several references cover use case analysis in depth: chapter six of Larman's Applying UML and Patterns — verified: Larman's Applying UML and Patterns, chapter six, "Use Cases", is devoted to use case analysis and includes the actor-goal list, the Boss/EBP/Size tests, and the fully dressed use case template used in this course. The book Writing Effective Use Cases — verified: Writing Effective Use Cases (Addison-Wesley, 2001) by Alistair Cockburn, the most widely used reference on writing use case text. And the extensive work of Ivar Jacobson — verified: the spelling is Ivar Jacobson, the originator of use cases, whose work includes Object-Oriented Software Engineering (1992) and The Unified Software Development Process (1999).
5.6.3 Actors: Primary and Secondary
In the notation, an actor is drawn outside the system boundary and interacts with the use case. An actor is usually a person or a role, and it is an external system.
- Actors are always external to the system. Sometimes people make the actors part of the system itself, which is wrong. Actors give input to your software system.
- Define the system boundary before starting to build the software. The system is your software application, and all the object-oriented analysis and design happens for it.
- An actor can be a human or a non-human: any other device, any other software, or any other hardware device. An actor stimulates the system with input, starts the use case or provides its inputs, receives output from the system, and gets benefit out of the system.
There are two kinds of actors:
- Primary actors: they get the main benefit out of the system.
- Secondary actors: they provide services to the system.
Q: What is the difference between primary actors and secondary actors? A: Primary actors get the main benefit from the system. Secondary actors participate in a passive manner and provide services to the system to complete the use case. They are also called supporting actors. Q: A student said that secondary actors give input and get benefit. Is that correct? A: No. Secondary actors do not get the main benefit. They provide services to the system, such as an authentication system that provides login. Primary actors are the ones who get benefit.
Actors in detail. An actor is drawn outside the system boundary as a stick figure (human) or a box with «actor» (computer system), and it interacts with the use cases inside the boundary.
- Always external. The system boundary — the software application being built — separates what is inside (the system) from everything else. Actors are outside it. A common mistake is placing part of the system itself as an actor; that is wrong.
- Human or non-human. People, other software, other hardware devices: anything that stimulates the system with input, starts a use case, provides inputs, receives outputs, and gets a benefit.
- Primary actors get the main benefit — their goals drive the use case (the cashier in Process Sale).
- Secondary (supporting) actors provide services to the system to complete the use case — they are passive helpers, not beneficiaries (the payment authorization service in Process Sale).
Why this distinction matters: it decides who the use case is written for. The primary actor's goal defines the use case; secondary actors appear only where the flow needs their service.
Real-world: An authentication service such as Active Directory is a secondary actor: it provides the service of login or authentication to the system. Any hardware, software, or individual process can be an actor.
5.6.4 What Is a Use Case?
A use case is a collection of scenarios in which users participate, interact with the system, and get benefit out of the system. In UML, use case diagrams are in the category of dynamic diagrams: they are about interaction, not structure.
- Use cases cover various scenarios, both success scenarios and failure scenarios. Exception handling is handled in the use case model, which is another good point about use cases.
- A use case is a set of sequences of actions the system performs that yield an observable result of value to a particular actor. The observable result is very important: the user should be able to specify that this is the outcome, and this is the sequence of tasks the system performs to give that benefit. Then only is it a requirement.
- Actions can involve communicating with a number of actors: the computer system does some calculation, stores some data, or checks some conditions.
- The system is treated as a black box. Define the system boundary and look at the system from outside.
- Describe the use case in clean text. Both the visual representation and the text representation give the complete view of the system, the use case view. UML provides different views of the system: the user view, the component view, and the deployment view. The use case view is one of the most important.
In a use case diagram you show the actors, the use cases, and the relationships among them. Define the system boundary first, then the different actors, the use case names, and the arrows. An arrow without a direction means the interaction is bidirectional; an arrow with a direction is a one-way interaction.
Each use case must be connected to an actor. There should not be a use case that is not connected to an actor. A use case is initiated by an actor as the primary actor, and the system gives the actor a result or a value. It is a high-level requirement, and you must completely describe the story, the narration, of the use case.
The anatomy of a use case.
- A use case is a collection of scenarios — one normal success scenario plus the failure and variation scenarios (this is where exception handling lives in the use case model).
- Each scenario is a sequence of actions the system performs — calculating, storing data, checking conditions, communicating with actors.
- The sequence must produce an observable result of value to a particular actor — if there is no observable outcome the user can point to, it is not a requirement.
- The system is a black box: we describe behavior from outside the system boundary, never internal implementation.
- Every use case is connected to at least one actor — a use case with no actor is a use case nobody starts and nobody benefits from; it does not belong in the model.
- Diagram and text. The use case diagram shows the system boundary, actors, use cases, and relationships (an arrow with a direction is a one-way interaction; without a direction, bidirectional). The text is the real content. Together they form the use case view of the system — one of UML's several views (user view, component view, deployment view) and one of the most important.
5.6.5 Function List versus Use Cases
Use cases are often compared with feature lists or function lists. The class is asked to compare and contrast a function list with use cases.
Q: How does a function list compare with use cases? A: A function list has no interaction. A use case is an interaction between an actor and the system, with a specific sequence of actions. A collection of related scenarios makes a use case, and the very specific goal of the user is captured, so each use case benefits the user, the actor, goal-wise.
The key points of the comparison:
- A function list only names capabilities; it says nothing about who uses them, when, or in what order.
- A use case captures the goal of an actor and the sequence of actions that produces an observable result of value.
Worked example: the same content, two forms. Consider an online ticket system.
| Function list (1970s style) | Use case |
|---|---|
| FEAT1.1 — The system shall accept booking requests. | Use case: Book a Ticket. Primary actor: Customer. Goal: reserve a seat on a chosen journey and receive a booking reference. Main flow: Customer selects a journey → system shows available seats → Customer chooses a seat → system books it, records the payment, and returns a booking reference. Exceptions: no seats available → system offers the waiting list. |
The function list says what must exist; the use case says who wants it, why (the goal), how it happens step by step, and what happens when it fails. That context is exactly what traditional requirements lacked. In the words of Larman's book on requirements in context: use cases pull the requirements together into stories of use.
5.6.6 Finding Actors and Use Cases
Finding the actors is an important part of finding the use cases. Ask a lot of questions; through questions only will you get what you really need from the system:
- Who will be using the system?
- Who will be using the functionality of the system?
- Who is going to maintain the system?
- What devices should the system handle?
- Which other systems will your system interact with?
- Who has any interest in the result of the system?
A user will use the system only if they get a benefit out of it.
Finding the use cases is another challenge, because use cases are very abstract in nature. The definitions look simple, but doing this in a real scenario is really challenging. The guidance given:
- Use cases mainly capture the behavior of the system, the functional requirements: what functions an actor requires from the system, and what the actor needs to do.
- Ask whether the actor's work could be simplified or made more efficient by new functions in the system. That is where you sell your product or your idea.
- Use event-based use case identification: the system is in different states, and events trigger the system to move from one state to another. Transactions are such events. The system must have the capability to handle these events; that is why the system is being built.
- Use cases solve existing problems: know what problem exists in the current system. The inputs and outputs of the system also help you understand what is really required.
How to find actors and use cases. The discipline of finding the model:
Finding actors — ask questions:
| Question | What it reveals |
|---|---|
| Who will be using the system? | The obvious human actors |
| Who will be using the functionality of the system? | Actors behind specific functions |
| Who is going to maintain the system? | Administrator/maintenance actors |
| What devices should the system handle? | Hardware actors |
| Which other systems will your system interact with? | External system actors |
| Who has any interest in the result of the system? | Stakeholders who may be primary actors |
Finding use cases — three strategies:
- Actor-goal analysis — ask who uses the system and what are their goals (not "what are the tasks"). The name of a use case should reflect the goal: goal "process a sale" → use case Process Sale. This focuses on business value instead of existing procedures.
- Event analysis — identify the external events: what happens, where from, why. A group of events often belongs to the same use case (the event "enter sale line item" and "enter payment" both belong to Process Sale). Transactions are such events; the system exists to handle them.
- Problem and input/output analysis — know the problems in the current system and study the inputs and outputs of the system; they reveal what is really required.
And the sales perspective: ask whether the actor's work could be simplified or made more efficient with new functions — that is where the product's value is sold.
Pitfall — the untestable use case. "Log In" may fail the Boss Test (your boss is not impressed that you spent the day logging in), "Move Piece on Game Board" fails the Size Test (a single step is not a use case), and "Negotiate a Supplier Contract" is too big (a business use case, not a system use case). A useful use case sits at the user-goal level: an Elementary Business Process — one person, one place, one time, with measurable business value. Reasonable violations exist (an Authenticate User use case can be worth writing for a single-sign-on feature), but the default target is the EBP level.
5.6.7 The Use Case Template and Naming Use Cases
The template used to write a use case includes the following fields:
- Use case name, and a use case number so that you have a reference.
- Authors, and what events are there.
- The actors.
- An overview: a brief statement of the use case.
- Related use cases.
- A typical process description, written as an algorithm: what is really happening.
- The exceptions and how to handle them.
All these are requirements within the framework of what is going on in the system. Write the use case in the form of a story: while using the system, you are getting a benefit, or your goal is being met by the system.
Use case names follow the format verb plus noun. The class is asked to give examples:
Q: Give examples of use case names. A: Show patient records, order food, make payment, book a ticket, play movie, provide feedback, show order, stock items, borrow book. The name is always verb plus noun. "User login" is not in that format, so it is not a valid use case name.
Worked example: a use case in the template form — Search Drug Information. This continues the hospital drug information system from section 5.4, showing how the developer requirement becomes a use case.
| Field | Content |
|---|---|
| Use case name | Search Drug Information (UC-01) |
| Authors / events | Analyst team; user enters a drug name |
| Actors | Primary: Doctor, Pharmacist. Secondary: Drug Database |
| Overview | The user enters a full or partial drug name and receives information about the drug, including side effects |
| Typical process | 1. The user enters a drug name. 2. The system searches the drug database for names matching the input (scientific, generic, or brand). 3. The system returns all matching drug names. 4. If more than one drug matches, the system shows the list and the user selects one. 5. The system displays the drug details, including side effects |
| Exceptions | 1. No match found → the system reports "no drug found" and offers a new search. 2. Partial match requested vs. exact match requested → the user specifies the match type before searching. 3. Database unavailable → the system reports the error gracefully and does not crash |
The name is verb + noun ("Search Drug Information"), every field is a requirement within the framework of what is going on in the system, and the exceptions — the same ones listed in section 5.4 — are carried into the use case model.
Exam note: Homework for the next class: write at least five use cases for any system, at least in the template form, as stories. Be ready to give one example of a use case name.
5.6.8 References and Homework
Use case modeling is one of the most important techniques of requirement analysis, and it comes before object-oriented analysis. To prepare:
- Read chapter six of Larman's book, Applying UML and Patterns, on use case analysis.
- Read Writing Effective Use Cases for writing use cases.
- Study the work of Ivar Jacobson on use case analysis.
- Knowing the notations and knowing what a use case is, is not enough. Work on some new case studies and start building and writing the use cases; writing use cases is the main skill.
- Homework: write at least five use cases for any system in the template form, as stories.
Recap + bridge. Use case modeling is the de facto standard because it keeps requirements in context: actors (primary and secondary, always external) pursue goals, and each goal becomes a use case — a narrated sequence of actions yielding an observable result of value, with exceptions handled as part of the model. Writing the text is the main skill; the diagram is only a picture. Use cases are the bridge from requirements into object-oriented analysis: the use case view drives the analysis of objects and their responsibilities in the next phase of the course.
Exam Guidance Summary
Exam guidance for this lecture.
- 5.1 The UDP model: Prepare the basic questions: the phases of the unified development process, what happens in each phase, the business process disciplines, and the major differences between the UDP and the waterfall model, with the advantages and disadvantages of each. Remember the one-line argument: iterations reduce risk, because problems surface early while they are cheap to fix.
- 5.2 Why requirements engineering is hard: Explain why requirements cannot be fixed up front, and quote the 65 percent figure: in 65% of projects following the waterfall model, 65% of the requirements gathered initially were never implemented. Name the challenges: non-functional requirements are implicit, requirements keep changing (change management), a human element is involved, and the situation varies from project to project.
- 5.3 Defining a software requirement: Define a software requirement in your own words: a capability needed by the user to solve a problem or achieve an objective, and a condition that must be met by the system (IEEE 610.12). Make each requirement testable, and remember the 10 milliseconds example — "good performance" is not a requirement, "answers within 10 milliseconds" is. Needs can be fulfilled; wants or wishes can never be fulfilled.
- 5.4 The requirements engineering process: Distinguish customer requirements (C — what the customer signs) from developer requirements (D — the technical expression). Explain the traceability matrix (who gave which requirement), the consistency rule (250 miles per hour vs 300 miles per hour is a defect), and the 90% / 10% exception handling split (normal behavior vs abnormal situations, e.g. the cashier and the credit card).
- 5.5 Techniques for capturing requirements: Remember the numbers: 10 seconds, 0.01, and 500 readings for the blood pressure monitor example (performance within 10 seconds; failure rate below 0.01 over the first 500 readings). Rapid prototyping shows key functionality early; let the prototype crash and change it early — a prototype is a requirements tool, not a finished product.
- 5.6 Use case modeling: Write at least five use cases in story form. Name use cases with verb plus noun ("User login" is not a valid name). Know the difference between primary actors (get the main benefit) and secondary actors (provide services), and between a function list (no interaction) and use cases (interaction between actor and system with a sequence of actions).
Key Industry Applications
Where this lecture's ideas show up in industry.
- Use case modeling is the de facto standard technique for requirement analysis in industry; each organization uses its own template for use cases and requirements. Writing the use case text is the core skill — the diagram is only the picture.
- Requirements traceability matrices are standard practice in regulated industries (healthcare, finance, aerospace, government), where auditors must trace every requirement back to the person who gave it and to the test that proves it was delivered.
- The SRS acts as a contract between customer and developers and drives testing, increments, and iterations; it is signed by the customer, and its completeness, consistency, and testability decide whether the project can be planned at all.
- Authentication services such as Active Directory appear in use case diagrams as secondary actors providing login — a classic example of a non-human supporting actor.
- Rapid prototyping is used by agile teams to confirm user needs early, before heavy development starts — showing key screens early is cheaper than changing an implemented system.
- C-to-D requirements conversion is a standard analyst practice: analysts with a computer science background and business knowledge bridge the customer group and the development group, keeping the two documents consistent.
OODAP Lecture 5 notes · Requirements Engineering and Use Case Modeling
Sections Breakdown
Recap of the unified development process model: the phases, the iterations in the diagram, and the fundamentals the UDP requires.
Why requirements engineering is the hardest part of building software: implicit and changing requirements, the human element, and the 65 percent figure.
The definition of a software requirement, testability as a hard requirement, and needs versus wants.
The requirements engineering process: the SRS as a contract, customer versus developer requirements, traceability, consistency, and exception handling.
Techniques for capturing and documenting requirements: interviews, workshops, questionnaires, rapid prototyping, and the blood pressure monitor example.
Use case modeling: actors, use cases as stories, verb-plus-noun naming, include relationships, and the function list contrast.
The professor's exam guidance for this lecture.
Where the lecture's ideas show up in industry.
Exam Revision Notes
Below is the distilled, exam-ready core. Every entry comes from the full explanation above. Use this section for rapid review; return to the main notes when a point needs more context.
5.1 The Unified Development Process Model (Recap)
Must-know: The phases of the unified development process, what happens in each phase, the business process disciplines, and the major differences between the UDP and the waterfall model with the advantages and disadvantages of each.
⚠️ Top pitfall: Reading the UDP diagram as four phases running in parallel: the diagram shows iterations, with small iterations in inception and transition and most of the work in elaboration and construction.
Self-check: Why does the UDP diagram draw small iterations under inception and transition but large ones under elaboration and construction?
Connects to: 5.2 Why Requirements Engineering Is Hard; 5.4 The Requirements Engineering Process; 5.6 Use Case Modeling.
5.2 Why Requirements Engineering Is Hard
Must-know: Why requirements cannot be fixed up front, and the 65 percent figure: in 65% of projects following the waterfall model, 65% of the requirements gathered initially were never implemented.
⚠️ Top pitfall: Assuming requirements are like a car's spec, fixed once at the start; software requirements stay implicit and keep changing with the business.
Self-check: Why can requirements not be fixed for software when they can be fixed in other engineering disciplines?
Connects to: 5.1 The Unified Development Process Model (Recap); 5.3 What Is a Software Requirement?; 5.4 The Requirements Engineering Process.
5.3 What Is a Software Requirement?
Must-know: Define a software requirement in your own words: a capability needed by the user to solve a problem or achieve an objective. Make each requirement testable, and remember the 10 milliseconds example.
⚠️ Top pitfall: Capturing everything the client wants: needs can be fulfilled, while wants or wishes can never be fulfilled; software also needs an architecture, and not everything should be done.
Self-check: How do you define a software requirement, and what makes it testable?
Connects to: 5.2 Why Requirements Engineering Is Hard; 5.4 The Requirements Engineering Process; 5.6 Use Case Modeling.
5.4 The Requirements Engineering Process
Must-know: Distinguish customer requirements from developer requirements. Explain the traceability matrix, the consistency rule (250 miles per hour vs 300 miles per hour), and the 90% / 10% exception handling split.
⚠️ Top pitfall: Missing the exceptions when capturing requirements: exceptions are usually missed and they must be captured too; writing 250 miles per hour in one place and 300 in another is not acceptable.
Self-check: What is exception handling in requirements, with an example?
Connects to: 5.3 What Is a Software Requirement?; 5.5 Techniques for Capturing and Documenting Requirements; 5.6 Use Case Modeling.
5.5 Techniques for Capturing and Documenting Requirements
Must-know: Remember the numbers: 10 seconds, 0.01, and 500 readings for the blood pressure monitor example. Rapid prototyping shows key functionality early; let the prototype crash and change it early.
⚠️ Top pitfall: Letting the prototype live forever or hiding its crashes: let the prototype crash many times and modify it as early as possible.
Self-check: Which numbers from the blood pressure monitor example are worth remembering, and what does rapid prototyping do early?
Connects to: 5.4 The Requirements Engineering Process; 5.6 Use Case Modeling; 3.9 The Software Process and the SRS.
5.6 Use Case Modeling
Must-know: Write at least five use cases in story form. Name use cases with verb plus noun. Know the difference between primary actors and secondary actors, and between a function list and use cases.
⚠️ Top pitfall: Believing secondary actors give input and get benefit: secondary actors do not get the main benefit; they provide services to the system, such as an authentication system that provides login.
Self-check: What is the difference between primary actors and secondary actors, and why is a function list not a use case?
Connects to: 5.4 The Requirements Engineering Process; 5.5 Techniques for Capturing and Documenting Requirements; 3.3 Use Cases.
Exam Guidance Summary
Must-know: Every exam guidance bullet is a task the exam can set: practice the doing (draw the UDP diagram, define a requirement, write use cases in story form), not just the reading; quote the 65% figure and the 90% / 10% split exactly.
⚠️ Top pitfall: Preparing by reading instead of doing; the exam guidance items are hands-on tasks such as writing at least five use cases in story form.
Self-check: Which exam guidance items are writing tasks (definitions, use cases), which are number-memory tasks (65%, 10 ms, 10 s, 0.01, 500, 90/10), and which are explanation tasks (UDP vs waterfall)?
Connects to: Entire session 5.1-5.6.
Key Industry Applications
Must-know: Connect each industry application to its session concept: CHAOS report and 65% to 5.2, SRS contract and consistency to 5.4, testable criteria to 5.3, prototyping to 5.5, use case modeling and Larman/Cockburn references to 5.6.
Self-check: Which industry application corresponds to each of sections 5.2, 5.3, 5.4, 5.5, and 5.6?
Connects to: 5.2 Why Requirements Engineering Is Hard; 5.3 What Is a Software Requirement?; 5.4 The Requirements Engineering Process; 5.5 Techniques for Capturing and Documenting Requirements; 5.6 Use Case Modeling.
Was this lecture useful?
BitsNotes AI Assistant
Subject Notes AssistantConfigure AI Chat
Choose how to access the chatbotSigned in as
Powered by BitsNotes — 20 messages per day. No API key needed. Want unlimited access? Use "Bring Your Own Key" mode.
Sign in to use AI Chat
Get 20 free AI messages per day to ask questions about your lecture notes. Sign in with Google or GitHub — it takes 5 seconds.
Sign In to BitsNotesSwitch to "Bring Your Own Key" tab above for unlimited access with any OpenAI-compatible provider.