Requirements Engineering

Before anyone writes a line of code, someone has to answer two questions: what should this system do, and what constraints does it operate under? That answer is the starting point of every software project. This session covers the first phase of the software development life cycle — working out what the system should do before anyone builds it. We define what a requirement is, separate user-level from system-level requirements, contrast functional with non-functional requirements, walk through the requirements engineering process — elicitation, specification, validation, and change management — and see why getting this phase right is the cheapest way to avoid disaster later. The ideas here are the foundation for everything that follows in the course: system modeling, design, and even agile methods all build on the requirements established today.

3.1 Requirements and Requirements Engineering

3.1.1 What a requirement is

A requirement is a description of a service that a system should provide, or a constraint on how the system operates. The formal statement used in this course: "The requirements for a system are the descriptions of the services that a system should provide, and the constraints on its operation." Requirements reflect the needs of customers who want a system for a concrete purpose — controlling a device, providing a service, or finding information.

To see the two halves, take a bank ATM. The services: dispense cash, check a balance, accept deposits. The constraints: dispense within a few seconds, never exceed the account balance, encrypt the PIN. Services say what the system does; constraints say how well and under what rules it does it. A requirement is useful only when it says something about at least one of these two halves.

Requirements engineering is the whole process of working with those statements: "finding out requirements, analyzing them, documenting them, and checking that these services and constraints are to be offered or to be fulfilled." So the term covers four activities — collection (finding out), analysis, documentation, and validation (checking) — and it is the fundamental first step of any software development process. The name matters: this is engineering, a deliberate, structured activity, not a chat over coffee where someone happens to remember to write things down.

3.1.2 The word "requirement" means two very different documents

The software industry does not use the word requirement consistently. In some places a requirement means a simple, high-level statement — an abstract statement of a service the system is broadly expected to provide, or a constraint such as "the system should work on a particular platform." In other places the same word means a detailed requirements specification: a formal definition of a system function that can form the basis of a contract.

The two senses pull in opposite directions. The abstract version may be the basis for bidding on a contract, so it must stay open to interpretation — several contractors must be able to offer different solutions. The detailed version may be the contract itself, so it must be defined in detail. Both documents describe system services and constraints, and both are legitimately called requirements.

One of the earliest authors on requirements engineering, Alan M. Davis, explained the situation neatly. If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way so that a solution is not predefined, and it must write the requirements so that several contractors can bid for the contract, offering different ways of meeting the client organization's needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail, so that the client understands and can validate what the software will exactly do. Both documents count as requirements for the system.

Many of the problems that arise during requirements engineering come from failing to make a clear separation between these two levels of description.

3.1.3 Where this sits in the life cycle

Requirements engineering is the specification phase of the software development process — the first of the four phases (specification, development, validation, and evolution) we saw in the last session. The terms from today will be revisited frequently during the rest of the software engineering course: traceability, for example, links requirements to design, and that whole chain starts here.

Real-world connection: this two-level pattern is exactly how public procurement works. Governments publish abstract tender documents so that many vendors can bid; the winning vendor then writes the detailed system definition that becomes part of the contract. Requirements engineering consultants earn their fees precisely at the boundary between the two levels — the point where "what do you want?" turns into "here is exactly what you will get." In software economics this boundary also concentrates the most expensive errors in the whole project: a misunderstood requirement at contract level propagates through design, implementation, and testing (the cost evidence appears in Section 3.12).

Recap: a requirement is a service or a constraint; requirements engineering is the process that finds, analyzes, documents, and checks them. The word covers two very different documents, and mixing them is a common source of project trouble. The next section separates the two levels properly — user requirements and system requirements.

3.2 User Requirements and System Requirements

3.2.1 Two levels of requirement

User requirements are the high-level, abstract requirements: statements in natural language, usually accompanied by diagrams, that describe the services of the system and its operational constraints. They are written for customers and end users.

System requirements are the detailed description of what the system should do: a structured document of the various functions, services, and operational constraints of the software. They elaborate the user requirements — "on clicking this menu item, it should do this; on this condition, it should do that" — instead of merely saying that a certain set of services and functionalities should exist.

The relationship is one of expansion, not replacement: every user requirement is expanded into one or more system requirements that say exactly when, where, and under what conditions the service happens. The system requirement adds the testable detail that the user requirement deliberately leaves out.

3.2.2 The software requirements specification

The system requirements document goes by several names: functional specification, software requirements — or the SRS, as it is often called. It should define exactly what is to be implemented. It may be part of the contract between the buyer and the software developers, which is why its precision matters: a contract must be checkable, not just agreeable. "The system should be user friendly" cannot be checked; "the system shall register a patient appointment within 2 seconds of the receptionist pressing enter" can.

3.2.3 Worked example: the mentcare drug-cost report

The running example for this course is a small network of psychiatric clinics that provide psychological and psychiatric counseling and treatment to patients who need them. It is a network of medical care clinics, and the system is called the mental health care system — mentcare for short. We will use it often during the discussions on requirements and system modeling later in the course.

That is the same requirement at two levels: a simple user-level statement and its detailed, implementable, testable system-level expansion.

3.2.4 Readers decide the level of detail

Different kinds of requirements exist because different kinds of readers use them in different ways. Readers of user requirements — client managers, for example — are usually not concerned with how the system is implemented, and managers may not care about the detailed services and actions the system performs. Readers of system requirements — system end users, client engineers, developers, architects, and testers — need to know precisely what the system will do, because they will implement it, test it, or use it to support a business process.

A phrase like "the system should be user friendly" is useless to this group. They need a testable requirement: exactly how the system should respond, what its performance should be, and so on.

Real-world connection: in regulated industries the two levels have distinct legal roles. The user-level document supports the procurement decision; the system-level SRS is written into the contract and can be audited. In healthcare procurement, for example, the SRS of a mentcare-like system is the reference that both regulators and test engineers work from — one checks behavior, the other checks compliance with standards.

Recap: user requirements give the "what, for whom"; system requirements give the "exactly how"; and the SRS is the detailed document that may become part of the contract. Next we look at the people behind those requirements — the stakeholders.

3.3 Stakeholders

3.3.1 Who counts as a stakeholder

A stakeholder is anyone who is affected by the system in some way — anyone who has a legitimate interest in it. Stakeholders range from end users of a system, through managers, to external stakeholders such as government regulators who certify the acceptability of the system. End users, system managers, system owners, and external stakeholders are all examples of stakeholder groups.

The definition is deliberately wide: "affected by the system in some way" includes people who never touch the software. A regulator never logs in, yet certifies whether the system may operate at all; a patient never uses the receptionist's screen, yet their data flows through it. Anyone whose interests the system touches has a legitimate claim to be consulted.

3.3.2 The mentcare stakeholder set

For the mentcare system the stakeholders include patients, doctors, nurses, medical receptionists, and IT staff. Less obvious members of the set: a medical ethics manager, who ensures that the health care system meets the ethical guidelines for patient care; health care managers, who need to get information from the system; and medical record staff, who are responsible for the privacy of the system, for keeping the records properly maintained, and for making sure all procedures are properly followed.

The point of the list is its range: patients contribute privacy and confidentiality requirements; nurses and doctors contribute workflow and treatment requirements; the ethics manager contributes ethical-guideline requirements; record staff contribute the procedures that keep records intact over years; and IT staff contribute installation and maintenance constraints. Several of these roles could easily be forgotten by a team that only interviewed "the users."

3.3.3 Real-world: the ATM stakeholder chain

Real-world: take a bank's ATM. Stakeholders run from the customer, to the teller, to the bank manager, to the ATM maintenance engineer, to the software, to the banking system regulators — plus many others, some internal and some external to the bank. The lesson: when requirements work starts, first enumerate who has a legitimate interest, because each of them will supply and constrain requirements.

3.3.4 Enumerate stakeholders before requirements work begins

Because each stakeholder supplies requirements, the very first step of a project should be a stakeholder inventory: list every group with a legitimate interest, mark each internal or external to the organization, and note which requirements it is likely to contribute. The ATM example shows the discipline: work the chain outward from the system until the list stops growing, and you will find the requirements that the obvious names never thought to mention.

Recap: stakeholders are everyone with a legitimate interest in the system — from end users to regulators — and each group is a source of requirements. Next we place this whole activity inside the software life cycle, where it is the first stage of development.

3.4 Requirements Engineering in the Software Life Cycle

3.4.1 The first stage of development

Requirements engineering is usually presented as the first stage of the software development process. Even before a decision is made to go ahead with the procurement or development of a system, some understanding of the system requirements has to exist: what the system might do and what benefits it might provide. Today we look at requirements engineering in the traditional waterfall model; agile methods get their own treatment later in the course.

For the majority of large systems, there remains a set of identifiable activities related to requirements engineering — collection, organization, analysis, definition, specification — that must happen before the design of the system can begin. In a traditional plan-driven model like the waterfall, the outcome of the requirements engineering process is a requirement specification document, which may be part of the system development contract. Of course, subsequent changes are made to the requirements, and user requirements may be expanded into more detailed system requirements over time.

Note the ordering: requirements engineering precedes design as well as coding. The waterfall sequence from the last session — specification, development, validation, evolution — starts with this phase, and everything downstream inherits its quality. A design built on the wrong requirements is a correct answer to the wrong question.

3.4.2 The feasibility study comes first

The early, high-level view of the system feeds a feasibility study, which tries to assess whether or not the system is technically and financially feasible. The results of the feasibility study help management decide whether to go ahead with the requirements engineering for the system, or even to continue development of the system at all. Quick checks of this kind ask whether the project is technically, economically, financially, and operationally feasible.

The four quick checks in the lecture expand questions 2 and 3: technically feasible (the technology exists), economically feasible (benefits justify costs), financially feasible (the budget exists), and operationally feasible (the organization can actually run it). These checks form the management gate: they convert "we could build this" into "we should build this."

3.4.3 Plan-driven and agile requirements engineering

In agile methods the picture is different: elicitation and development happen concurrently, with the team adding detail to refine the user-level and system-level requirements as modules are built. Requirements are expressed as user stories, and the requirements engineering approach is incremental.

Real-world: user stories suit business systems, web-based applications, and mobile application development, where the requirements keep changing and you are not sure of the actual product features up front.

They are harder to apply to large critical systems that need a pre-delivery analysis of the architecture and the design before development can begin. That is why large critical systems still use plan-driven requirements engineering.

Recap: requirements engineering is the first stage of the life cycle, preceded by a feasibility study, and it takes two forms — plan-driven (formal document) and agile (user stories). Next we open the content of the requirements themselves: functional versus non-functional requirements.

3.5 Functional and Non-Functional Requirements

3.5.1 Functional requirements: the services the system must deliver

Functional requirements specify the functionality of the system — the services it provides. For example, a bank must enable withdrawal and deposit of cash. Functional requirements state how the system should respond to particular inputs and how it should behave in particular situations. Sometimes they also specify what the system should NOT do under certain circumstances: it should not allow unauthorized access, or should not allow withdrawal of cash above the available limit.

Notice the third clause: functional requirements can be negative. "The system shall not allow a withdrawal above the available balance" is as functional as "the system shall dispense cash." Both describe behavior of the system; one in the positive, one as a restriction.

3.5.2 Non-functional requirements: properties and constraints

Non-functional requirements describe the behavior or the properties of the system: performance, safety, security — all transactions should be efficient and safe, with no scope for malicious activity, for example. Usability, maintainability, reliability, performance and efficiency, and the look and feel of the software are all non-functional properties.

Non-functional requirements are constraints on the services or functions offered by the system. Timing constraints ("the ATM should dispense cash within so many seconds"), alignment with a particular protocol or method, and constraints on the development process ("use only these development process and techniques; apply these standards") are all examples. They often apply to the system as a whole rather than to individual features or services.

3.5.3 Emergent properties: the assembled-product analogy

Non-functional requirements are sometimes emergent requirements: properties you can only know once the whole system is put together. The analogy used in this course: think of the weight of a product assembled from various components. The weight of the product can be known only after all the components are assembled — it is an emergent property. In the same way, how the system performs once all components are put together is an emergent property, and so its performance and reliability apply to the assembled system rather than to any single part.

3.5.4 The boundary is fuzzy

In reality, the distinction between different types of requirements is not as clear-cut as these simple definitions suggest. A user requirement concerned with security — a statement saying restricting access to authorized users — appears to be a non-functional requirement. But developed in more detail, it generates other requirements that are unmistakably functional, like the need to include user authentication facilities in the system. This shows that requirements are not independent: one requirement often generates or constrains other requirements. System requirements then do not just specify the services or features that are required; they also specify the necessary functionality to ensure that those services or features are delivered efficiently and effectively.

3.5.5 Domain and external requirements

Beyond the properties of the system itself, external requirements come from the domain of operation. Banking, healthcare, and education each bring constraints from the regulators and from the domain itself — constraints on the system from the domain of operation. These matter as much as the system's own properties, as we will see when we classify non-functional requirements.

Real-world connection: a banking system must follow the payment-card standards of the industry; a healthcare system must follow patient-privacy law; an education platform must protect minors' data. These domain constraints are not optional features — they are conditions for the system to be allowed to exist in that domain at all. The classification promised here arrives in Section 3.7, where non-functional requirements split into product, organizational, and external categories.

Recap: functional requirements state services; non-functional requirements constrain how those services behave, often as emergent properties of the whole system; and the boundary between them is fuzzy because requirements generate each other. The next two sections look at each family in detail, starting with functional requirements.

3.6 Functional Requirements in Detail

3.6.1 What shapes functional requirements

Functional requirements depend on the type of software being developed, the kind of users who are going to use the software, and the general approach taken by the organization when writing requirements.

At the user level, functional requirements should be written in simple natural language as high-level abstract statements that end users and managers can understand. At the system level they are expanded for developers: system functions, their inputs, outputs, and exceptions, and the system services in detail. Functional requirements range from general requirements covering what the system should do, to very specific requirements reflecting local ways of working or existing organizational systems.

3.6.2 Worked example: three mentcare functional requirements

Three functional requirements for the mentcare system show the range:

3.6.3 Information requirements and ready-made systems

Functional requirements have traditionally focused on what the system should do. But if an organization decides that an existing or commercially available system can meet its needs, there is very little point in developing a detailed functional specification — you are buying a ready-made software product, not commissioning one.

Real-world: in that situation the focus shifts to information requirements: the information needed for people to work using that system, and how that information is to be delivered and organized. For the mentcare system, an information requirement might specify what information is to be included in the list of patients expected for appointments on a given day.

3.6.4 Ambiguity: the appointment-search story

Writing requirements precisely and without ambiguity matters, because ambiguity and imprecision lead to confusion, to building the wrong functionality, and to disputes between customers and developers. It is natural for a system developer to interpret an ambiguous requirement in a way that simplifies its implementation. Often, however, this is not what the customer wants. The requirements then have to be re-established and changed, which delays system delivery and could increase costs.

The first mentcare requirement is a perfect trap. A patient with mental health issues may be confused: they may have an appointment at one clinic but actually go to a different clinic, or be recorded as having attended regardless of which clinic they went to. A medical staff member specifying the search requirement may expect the search to mean that, given a patient name, the system looks for all appointments at all clinics in the city. But this is not clear from the requirement. A developer might instead interpret the requirement so that it is easier to implement: the search function may require the user to choose a specific clinic and then search for patients who attended that clinic that day. This involves more user input and could take longer to complete the search. Neither reading is derivable from the text, which is exactly the problem.

3.6.5 Completeness and consistency

Ideally, the functional requirements specification of a system should be both complete and consistent. Completeness means that all services and information required by the user are defined; consistency means that the requirements should not be contradictory. In practice, it is only possible to achieve consistency and completeness for very small programs and very small software systems. Two reasons: it is easy to make mistakes and omissions when writing specifications for very large complex systems, and large systems have many stakeholders with different backgrounds and expectations, who are likely to have different and often inconsistent needs. These inconsistencies may not be obvious when the requirements are originally specified; they may be discovered only after deeper analysis, or later on during design or implementation. Validation is how we try to ensure completeness and consistency.

3.6.6 Student exchange: writing requirements in day-to-day work

Recap: functional requirements state services, come at different levels of detail, must be unambiguous, and can never be fully complete and consistent in large systems. Next we look at their sibling family — non-functional requirements — which constrain the system as a whole.

3.7 Non-Functional Requirements in Detail

3.7.1 Properties of the whole system

Non-functional requirements define system properties and constraints: properties like reliability, performance, response time, and storage requirements; constraints like device capability, the system representations to be used, or the standards to be applied. They are not directly concerned with the specific services delivered by the system to its users; they specify or constrain characteristics of the system as a whole. They may relate to emergent system properties — reliability, response time, memory use — or they may define constraints on the system implementation: the capabilities of the devices used by the system, the data representations of the database schema, the interfaces with other systems, or the choice of a particular platform, programming language, or development method.

3.7.2 One failed non-functional requirement can sink the system

Non-functional requirements are sometimes rather more critical than individual functional requirements. System users can usually find ways to work around a system function that does not really meet their needs. However, failing to meet a non-functional requirement can mean that the whole system is unusable: if it does not work with the platform you are using for the application, or is not compatible, you cannot use it at all. If a system does not meet its safety and reliability requirements, a safety-critical system cannot be certified as safe for operation. If an embedded control system fails to meet its performance requirements, its control functions will not be operating correctly and might create hazardous consequences.

It is often possible to identify which system components implement specific functional requirements — in a word document, for example, you have formatting functions. It is more difficult with non-functional requirements, because their implementation may be spread throughout the system and affect the overall architecture. To ensure that performance requirements are met in an embedded system, for example, you may have to organize the system to minimize communication between various components. An individual non-functional requirement like a security requirement may also generate several related functional requirements — authentication at various levels — that define new system services, and it may generate requirements that constrain existing ones, for example by limiting access to information in the system.

3.7.3 Product, organizational, and external requirements

Non-functional requirements fall into three broad categories — the standard classification used in the course and the reference texts.

Product requirements constrain the runtime behavior of the software: performance requirements (how fast the system must execute, how much memory it may use), reliability requirements (the acceptable failure rate), security requirements, usability requirements, and so on.

Organizational requirements are broad system requirements derived from policies and procedures in the customer's and developer's organizations. They include operational process requirements (how the system will be used), development process requirements (the programming language, the programming environment, and the process standards to be used), and environmental requirements (the operating environment to be used).

External requirements cover everything derived from factors external to the system and the development process: legal and regulatory requirements that must be met for the system to be approved for use by a regulator — a Nuclear Safety Authority or a Traffic Control Authority, say; legislative requirements to ensure the system operates within the law; and ethical requirements that ensure the system will be acceptable to its users and the general public.

3.7.4 Worked example: mentcare non-functional requirements in each category

For the mentcare system:

Real-world connection: the three categories map directly onto real certification contexts. A nuclear power station's control software must satisfy a regulatory requirement from the Nuclear Safety Authority before it is allowed to run; a bank's systems must satisfy legislative requirements on customer data; and a medical device must satisfy ethical requirements on informed use. In each case the requirement is a condition of existence — the system may be functionally perfect and still be barred from operation if its non-functional constraints are not met.

Recap: non-functional requirements constrain the system as a whole, split into product, organizational, and external categories, and their failure can make the whole system unusable. The next section fixes the biggest practical problem with them: goals that cannot be tested.

3.8 Goals Versus Testable Non-Functional Requirements

3.8.1 Goals: good intentions, wide interpretation

A common problem with non-functional requirements: stakeholders at various levels — from high-level executives to end users at the operational level — provide requirements such as "ease of use," "the ability of the system to quickly recover from failure," or "rapid response time." These are goals: general intentions. Goals set out good intentions but cause problems for system developers because they leave wide scope for interpretation, and later create confusion and ambiguity during system development and disputes once the system is delivered.

A goal is a general intention, whereas a verifiable non-functional requirement is specific and measurable, something that can be objectively tested. Goals are helpful because they convey the intention of the system users, but in order to implement a non-functional requirement it should be verifiable, testable, and measurable.

3.8.2 Worked example: from a usability goal to a testable requirement

A manager might express the usability requirement for mentcare as a goal: the system should be easy to use by medical staff and should be organized in such a way that user errors are minimized.

This cannot be objectively verified as written, because the goal is impossible to test. It becomes testable once you include some kind of measurement and software instrumentation to check the number of errors made by users when they are testing the system. The rewritten requirements:

Wherever possible, write non-functional requirements quantitatively and precisely so that they can be objectively tested.

3.8.3 Metrics for writing non-functional requirements

For system properties like speed, size, ease of use, reliability, robustness, and portability, you can use a number of measures to specify non-functional requirements:

These measures are the standard way to turn a property into an objectively checkable requirement. Notice the pattern: every measure is a number with a unit — seconds, bytes, errors per hour, percentage — so that "test the requirement" becomes a concrete, repeatable procedure rather than a matter of opinion.

3.8.4 Customers struggle with metrics

In practice, customers for a system often find it difficult to write such precise requirements — that is the job of developers, systems engineers, software designers, and requirements engineers. The user-level requirements customers provide are generally stated as abstract goals. For some goals, like maintainability, there are no simple metrics that can be used. And even when a quantitative specification exists, customers may not be able to relate the need to these specifications: if you write reliability in terms of mean time to failure, probability of unavailability, or failure occurrence, many customers cannot relate those numbers to their everyday experience with the system. Also, the cost of objectively verifying and measuring all these measures of non-functional requirements can be quite high, and the customers paying for the system may not think these costs are justified.

3.8.5 Non-functional requirements conflict and interact

Non-functional requirements often conflict and interact with functional and other non-functional requirements. In the mentcare system, an identification requirement says users should authenticate themselves using a health authority identity card — but another requirement demands mobile access to the system from doctors' or nurses' phones, and phones are not equipped with card readers. Some alternative authentication method has to be supported.

3.8.6 Mapping functional and non-functional requirements

Because functional and non-functional requirements interact so much, it is difficult to separate them in the requirements document — but you must map them explicitly: for every functional requirement, know which non-functional requirements correspond to it. If non-functional requirements are stated separately from functional ones, the relationship between them may be hard to understand. The practical advice: highlight requirements that are closely related to emergent system properties — performance, reliability, usability, maintainability — by putting them in a separate section of the requirements document or distinguishing them in some way from the other requirements, and create a mapping between functional and non-functional requirements.

Recap: goals express intentions; verifiable requirements add measurement; and because non-functional requirements conflict and interact, they must be mapped to the functional requirements they support. Next we move from the content of requirements to the process that produces them.

3.9 The Requirements Engineering Process

3.9.1 An iterative, interleaved cycle

The requirements engineering process is a set of concurrent, interleaved activities, iterated during both plan-driven and agile methods. The activities result in various system descriptions — text narrative descriptions, graphical models, and user-level and system-level requirements — and finally a requirements document, also called a requirement specification document, a software requirement specification document, or a system requirement specification document. That document forms the basis for the subsequent development life cycle.

The process cycle starts with requirements discovery and ends with requirements documentation or specification. An analyst's understanding of the requirements improves with each round of the cycle, and the cycle ends when the requirements document has been produced — this is the requirements spiral model we saw in an earlier session. You can exit the cycle whenever required and run as many iterations as you need.

Visual intuition — the requirements spiral: picture a spiral drawn from the center outward. The four activities — elicitation, specification, validation — sit around the ring, with the discovery/classification/negotiation/documentation activities of Section 3.9.2 inside it. The inner ring handles business and user requirements at a high level; each outward ring goes deeper, refining non-functional requirements and detailed system requirements. You can step off the spiral at any point — after some or all user requirements are elicited — which is why agile teams can run the loop many times while plan-driven teams exit later with a full document. The takeaway in one sentence: every circuit of the spiral sharpens the analyst's understanding, and the effort split per ring depends on the stage of the process, the type of system, and the budget.

3.9.2 Discovery, classification, prioritization, and negotiation

Within the cycle, the second activity takes the unstructured collection of requirements, groups related requirements, and organizes them into coherent clusters. Then comes requirements prioritization and negotiation: with multiple stakeholders, requirements will inevitably conflict, so this activity prioritizes requirements and finds and resolves conflicts through negotiation — meetings where stakeholders resolve differences and agree upon certain compromises.

At the specification or documentation activity, the requirements are documented and passed into the next round or next iteration of the requirements engineering process. An early draft of the software requirements document may be produced at this stage, then validated, and then sent around the next spiral. All the requirements may simply be maintained informally on whiteboards, wikis, or other shared document spaces.

3.9.3 Viewpoints for organizing requirements

To simplify the analysis of requirements, it is helpful to organize and group the stakeholder information. One way: consider each stakeholder group to be a viewpoint, and collect all requirements from that group into the viewpoint. A viewpoint is essentially a way of collecting and organizing a set of requirements from a group of stakeholders who have something in common — the customer viewpoint in a bank, the teller viewpoint, the bank manager viewpoint, the ATM maintenance technician viewpoint, the banking regulator viewpoint, and so on. Each viewpoint includes a set of system requirements, and viewpoints might come from end users, managers, and other stakeholders. They help identify people who can provide information about their requirements and help structure the requirements for analysis. You can also use an architecture of the system to identify requirements associated with each subsystem or module.

3.9.4 Keeping stakeholders on board

Different stakeholders have different views on the importance and priorities of the requirements, and most of the time these views will be conflicting. If some stakeholders feel that their views have not been properly considered, they may deliberately attempt to undermine the requirements engineering process. The countermeasure: organize regular stakeholder meetings so that stakeholders have the opportunity to express their concerns and agree on requirements compromises. At the documentation stage, use simple language and diagrams to describe the requirements, so that stakeholders can understand and comment on them, and use shared document repositories accessible to all concerned stakeholders.

Recap: the requirements engineering process is an iterative spiral of discovery, classification, prioritization and negotiation, and documentation, organized with viewpoints and kept alive by stakeholder meetings. Next we go inside the first activity — elicitation and discovery — and its techniques.

3.10 Requirements Elicitation and Discovery

3.10.1 What elicitation is

Requirements elicitation — also called requirements discovery — involves meeting stakeholders of different kinds to discover information about the proposed system. You supplement this information with knowledge of existing systems and their usage, and with information from documents of various kinds. You need to spend time understanding how people work, how they use other systems, and how they may need to change to accommodate a new system.

Two fundamental approaches to requirements discovery exist: interviews and observation. In observation you watch people doing their jobs to see what kind of artifacts they use, what information they use, and how they collaborate. You should use a mix of interviewing and observation techniques to collect information, derive requirements, and use them as the basis for further discussions.

3.10.2 Interviews: closed and open

Two styles of interview exist. Closed interviewing uses a predefined set of questions. Open interviewing starts a conversation and explores a range of issues with system stakeholders, to develop a better understanding of their needs. Use a mix of both.

In practice, real interviews are a mix: you need answers to certain fixed questions, but those answers usually open up related issues worth exploring less formally. A completely open conversation rarely works — you need a few questions to get started and to keep the interview focused on the system being developed.

3.10.3 The jargon problem

Eliciting domain knowledge through interviews can be difficult, because the domain experts or end users use jargon specific to their work, and requirements engineers may not understand domain terminology — banking terminology, healthcare terminology, and so on. The people in the domain use words in a very precise and subtle way that outsiders may not understand, and they find it difficult to explain basic terms that are second nature to them. When you say "triage" in a healthcare system, it is understood — but a requirements engineer unfamiliar with the healthcare domain may not know the term. For a librarian, everyone knows that all acquisitions are catalogued before they are added to the library, but a requirements engineer may not know this and so cataloguing may not be taken into account in the requirements.

3.10.4 Ethnography: observe, do not ask

In addition to interviews, you may use ethnography, because software systems do not exist in isolation: they are used in social and organizational environments, and their requirements may be generated or even constrained by the organizational environment and by the way people work and use the system. This is one reason a software product may not be used as intended by its developers: end users may bypass or work around certain features to make their work convenient, especially if a feature does not accomplish their work efficiently.

Ethnography is an observational technique for understanding operational processes and deriving requirements to support them: an analyst observes the people — it is very effective for understanding how people actually work, rather than how they describe their work, because in practice people may not follow the formal processes described in the business process documents. They use informal techniques to take care of their work, and requirements may be derived from cooperation and awareness of other people's activities — for example, staff covering for each other's work when somebody else is absent.

You can combine ethnography with prototyping: develop a prototype, let people work with it, and get answers to questions that focus on the way people work.

3.10.5 Where ethnography falls short

The problem with ethnography is that it still studies existing practices, which may have a historical basis that is no longer relevant. It may be useful for understanding existing systems, but that understanding may not always help with innovation — and innovation is particularly relevant for new product development. Various commentators have suggested that ethnographic studies can reveal certain critical process details that are often missed by other techniques like interviewing. But because of its focus on the end user, it is not effective for discovering broader organizational requirements or domain requirements, or for innovations. Use ethnography as required, but always in combination with interviews and other techniques for requirements analysis.

3.10.6 User stories and scenarios

In addition to interviewing and observation, you may describe user stories and scenarios to describe the requirements, capturing how the system may be used for a particular task. At a high level, stories and scenarios are usually the same thing: a description of how the system can be used for some particular task — what people do, what information they use and produce, and what systems they may use in the process.

The differences are in how the descriptions are structured and in the level of detail. User stories are written as narrative text and present a high-level description of the system use. Scenarios are structured with specific information — inputs, outputs, and a description of the activities that are carried out. A scenario can include a description of the starting situation, a description of the normal flow of events, a description of what can go wrong and how the resulting problems can be handled, information about other activities that might be going on at the same time, and a description of the state of the system at the end. Writing a user requirement as a scenario of interaction between the user and the system is a more structured form of a user story.

3.10.7 Student exchange: who does the interviewing?

Recap: elicitation pairs interviews (closed and open) with observation, treats jargon as a first-class risk, uses ethnography to see how work really happens, and captures use through stories and scenarios. The captured material is then written down — the next activity: requirements specification.

3.11 Requirements Specification

3.11.1 Writing the requirements down

Requirements specification is the process of writing down user requirements and system requirements in a requirements document. Ideally, the user requirements and system requirements should be clear, unambiguous, easy to understand, complete, and consistent. In practice it is almost impossible to achieve all these aspects together: stakeholders may interpret the requirements in different ways, and there are often inherent conflicts and inconsistencies in the requirements.

3.11.2 Notations for system requirements

User requirements are always written in a natural language, supplemented by appropriate diagrams and tables in the requirements document. System requirements may also be written in natural language, but other notations — UML and other design forms, graphical models, mathematical models — can be used. A variety of notations can complement the narrative text: natural language, structured natural language specification in the form of a form, graphical notation like UML models, and mathematical specifications. All of these could be part of the same requirements document.

3.11.3 Requirements and design are inseparable in practice

In principle, requirements and design are distinct: requirements should set the functionality and services of the system, whereas design should describe how the system can be built to achieve this. In practice, requirements and design are interlinked and inseparable. You may have to first design the architecture, and then, based on the various modules, structure the requirements — requirements for the input module, the processing module, the output module, and so on. The system may interoperate with other systems, which generates system requirements. The use of a specific architecture to satisfy non-functional requirements may be a domain requirement itself, and there may be a regulatory requirement that must be specified first, before the system requirements specification is developed.

3.11.4 Natural language guidelines

If you use natural language specifications, follow guidelines: avoid computer jargon, or explain why requirements exist. Most importantly, the requirement should be testable. If a requirement is imprecise, if it is confusing, or if too many requirements are combined into one, you will have difficulty understanding and implementing it.

3.11.5 Form-based specification: the insulin pump

A form-based specification describes an entity, its inputs, its outputs, the information needed for computation, the action to be taken, preconditions, post-conditions, and side effects. The example used in this course is an insulin pump, which delivers insulin based on the computation of sugar level. The form for it can be structured with fields like function, description, inputs, outputs, destination, action, requirements, precondition, post-condition, and side effects.

Real-world: medical devices like the insulin pump are safety-critical, and a form-based structure forces the writer to state the computation's preconditions and side effects explicitly instead of burying them in prose.

3.11.6 Decision tables

Tables can supplement the structured description and give the logic in a clearer way: "if these conditions, then this action is to be taken." You can use decision tables to specify requirements in a more unambiguous way, especially when computations are involved or a series of decisions is to be taken, instead of writing them as narrative text.

Visual intuition — a decision table in action: the insulin pump's dose logic as a table, one row per condition and one column for the action taken:

Reading a table like this, a developer cannot miss a case, and a reviewer can check every condition against the medical rules. That is the whole point of decision tables for requirements: the logic becomes visible, and a question like "what happens when the level falls while the rate climbs?" becomes something the table forces you to answer explicitly.

3.11.7 Use cases and the mentcare example

Use cases describe the scenarios in which users interact with the system, and the interaction is described in detail. Use case diagrams will be discussed in great detail later, during system modeling. A high-level use case diagram for the mentcare system shows the actors who interact with the system through specific scenarios — the medical receptionist, for example, has her use cases. The actors in the diagram are the roles people play with the system — doctor, nurse, medical receptionist, manager — and the use cases the lecture highlights are register patient and view patient information. The course reference draws the full diagram with seven use cases: Register patient, View personal info, View record, Generate report, Export statistics, Edit record, and Setup consultation. Use cases can be elaborated further: register patient or view patient information, for example, can be elaborated into a detailed software requirements specification document, which is essentially the basis for all subsequent development.

3.11.8 The SRS serves many readers

The software requirements specification is both the definition of the user requirements and a detailed specification of the system requirements. Note that it is not a design document: it should describe the system services, functionalities, and constraints rather than how they are to be achieved. But invariably, architectural design forms the basis for structuring the software requirements — so at least the preliminary design is inseparable from the software requirements document.

A variety of users read the requirements document: customers, managers, system engineers, test engineers, and maintenance engineers, all with different needs and different purposes. The diversity of possible users means the document has to be a compromise: it has to describe the requirements for customers, define the requirements in precise detail for developers and testers, and include information about future system evolution. Information on anticipated changes helps system designers avoid restrictive design decisions and helps maintenance engineers adapt the system to new requirements.

3.11.9 How much detail? The IEEE structure

The level of detail in a requirements document depends on the type of system being developed and the development process used. Critical systems need very detailed requirements, because safety and security have to be analyzed in detail to find possible requirements errors. When the requirement is to be developed by a separate company through outsourcing, the system specifications need to be detailed and precise. With an in-house iterative development process — or in agile — the requirements document can be a little less detailed, with details added and ambiguities resolved during development.

The IEEE standards give a structure for a requirements document, and you can add as much level of detail as required in each section or chapter: introduction, user requirements definition, system architecture, system requirements definition, system models, and system evolution — plus appendices describing hardware and database details, and detailed indices such as an alphabetical index and lists of figures, tables, and functions. A document with this structure might be produced for a complex engineering system that includes hardware and software developed with different companies; it is likely to be very long and very detailed, and it should have a comprehensive table of contents and document index so that readers can find the information they need. On the other hand, for an agile, in-house software product development, you may leave out many details and focus on defining the user requirements and high-level functional and non-functional requirements, letting designers and programmers use their judgment to meet them.

Visual intuition — the IEEE structure as a document map: the full structure reads top to bottom as: preface (readership and version history), introduction (need for the system, how it fits business objectives), glossary (all technical terms defined), user requirements definition (services and non-functional requirements in customer language), system architecture (high-level overview of how functions are distributed across modules), system requirements specification (functional and non-functional requirements in detail, interfaces to other systems), system models (graphical models of relationships), system evolution (assumptions and anticipated changes), appendices (hardware and database details), and index (alphabetical, plus lists of figures, tables, functions). A complex outsourced engineering system fills every chapter; an in-house agile product keeps only the user requirements and high-level requirements, trusting designers and programmers to fill the gaps with judgment.

3.11.10 Student exchange: can requirements really be ambiguous?

Recap: specification writes requirements down using natural language (with five disciplined rules), forms (insulin pump), decision tables, and use cases — producing an SRS that serves many readers and scales from a lean agile document to the full IEEE structure. Next we check the written requirements against what the customer actually wants: validation.

3.12 Requirements Validation

3.12.1 Why validation is expensive to skip

Requirements validation checks that the requirements really define what the customer actually wants. While it overlaps with elicitation and analysis, it is concerned with finding problems with the requirements: is it complete, consistent, unambiguous? Validation is particularly important because a mistake or error in the requirements leads to extensive rework costs when the problem is discovered during development — or worse, after the system is put into service.

This is where the tree-and-swing diagram from the last class comes in: the requirements mismatch. The customer said they wanted something very simple; what you implemented is something complex and useless; and putting it right means redoing the whole thing — modifying the operational system, modifying the implementation, redoing the design. Extremely difficult and extremely expensive.

3.12.2 The checks: validity, consistency, completeness, realism, testability

When you validate requirements, you carry out different checks:

• Validity checks: does the requirement reflect the real needs of the system users? Because of changing circumstances, the user requirements may have changed since they were originally collected or discovered.
• Consistency checks: the requirements document should not be in conflict — no contradictory constraints and no different descriptions of the same system function.
• Completeness checks: the requirements document should include requirements that define all the functions and all the constraints intended by the system user.
• Realism checks: using knowledge of the technologies, check that the requirements can be implemented within the proposed budget and technology constraints for the system, and that the schedule for development is realistic.
• Verifiability and testability: is each requirement testable? To reduce the potential for dispute between customer and developer, system requirements should always be written so that they are testable — you should be able to write a set of test cases that show that the delivered system meets each and every specified requirement. This is what test-driven development in agile methods is about, and it is also used in plan-driven methods.

3.12.3 Validation techniques

A variety of techniques can validate requirements:

• Walkthroughs: reviews of the requirements by a team of reviewers to check for grammatical, spelling, and typo errors, inconsistencies, and ambiguities.
• Prototyping: create a prototype and work with the end users or the stakeholders to see if this is what they want and expect, because with a prototype they can clarify the requirements in more detail.
• Test case generation: devise tests for the requirements as part of the validation process. If a requirement says "user-friendly," how will you test it? If a test is difficult to write or difficult to design, that means the requirement will be difficult to implement and should be reconsidered. Developing tests from user requirements before any code is written is an integral part of test-driven development, especially used in agile methods but nowadays becoming more common.

Real-world: writing test cases before implementing the requirement — test-driven development — is standard practice in agile teams and is spreading into plan-driven projects. Several students in the class confirmed they already do this.

3.12.4 Testability: the "user-friendly" trap

The recurring theme of validation is testability. When you validate, you check for verifiability, comprehensibility, traceability, and adaptability — can the requirements be changed without a large impact on other requirements? Can the origin of the requirements be stated explicitly? Is the requirement properly understood? Is it realistically testable? Testability of the requirement is very important, and you should not underestimate the problems involved in requirements validation.

3.12.5 Why validation is genuinely hard

It is quite difficult to show that a set of requirements does in fact meet the user's needs. Users need to picture the system in operation and imagine how it would fit into their work. It is very difficult even for a programmer or software engineer to visualize how the system will be used by end users — and it is even more difficult for the end users themselves. Requirements problems may arise during validation, and further changes will be needed to correct omissions, incorrectness, and misunderstandings, after discussions and compromise and trade-offs on the requirements.

3.12.6 Student exchange: the silence after delivery

Recap: validation checks the requirements against what the customer really wants — via five checks and three techniques — because late requirement errors are the most expensive errors there are. The process ends where constant change begins: requirements change management.

3.13 Requirements Change Management

3.13.1 Change is constant

After validation comes requirements change: during this process the requirements keep changing, and you have to manage the change. Business requirements change, technical requirements change, and the people who buy the system and the people who use the system are different. There should then be a systematically managed approach to requirements change management throughout.

Three forces drive the change: business and technical environments change after installation (new hardware, new interfaces, new legislation); buyers and users are different people, whose constraints conflict; and a large stakeholder community keeps reprioritizing its needs. The answer is not to stop the changes — it is to manage them systematically.

3.13.2 Identification, process, and traceability

The systematic approach has three parts: identify each requirement uniquely, run a systematic change management process, and maintain traceability — every requirement should be traceable to its corresponding non-functional requirements and design entries.

3.13.3 Tool support

None of this can be done without extensive tool support. Requirements engineering CASE tools manage requirements and requirements changes. Examples include IBM DOORS — the requirements management tool named in the course reference text (the tool name is hard to catch in class) — and Rational Requisite Pro, and a student in the class reports that their team uses AHA to capture and organize requirements.

Real-world: requirements teams use tools like DOORS, Requisite Pro, and AHA to manage requirements and requirements changes in real projects. For small systems, shared documents and spreadsheets are enough; for large systems, specialist tools like DOORS make it practical to track thousands of changing requirements.

3.13.4 Handling a change request

When requirements change, you need to monitor them: see that the change does not have a great impact on, or change, all the other requirements significantly; check whether it is cost effective to make the change; then change the requirements as required and update the requirements document, keeping all necessary traceability-related information properly maintained. Without this control, there will be too many changes and the document will not be useful as a reference for subsequent development.

Recap: requirements change constantly, so requirements management identifies every requirement uniquely, runs a systematic change process with traceability, and leans on tools like DOORS, Requisite Pro, and AHA. That closes the requirements engineering process — the next section recaps the whole session.

3.14 Session Recap

3.14.1 What we covered

To recap the session: in traditional plan-driven development, requirements engineering is the first stage of the software development life cycle. It specifies what the system should do and defines the constraints on its operation and implementation. We distinguished functional requirements — the statement of the services the system must provide — from non-functional requirements, which define the constraints on the system's operation and development, including the environment, and which are emergent properties applying to the system as a whole.

The requirements engineering process is an incremental and iterative process with three main stages: requirements elicitation, requirements specification, and requirements validation. Elicitation itself is an iterative process involving requirements discovery, requirements classification and organization, requirements negotiation, and requirements documentation. The techniques for requirements collection include interviews and observation (ethnography), plus user stories and scenarios to support discussions. Specification formally documents the user requirements and system requirements to create a software requirements specification, the basis for subsequent development. Finally, we validate requirements to check for validity, consistency, completeness, realism, and verifiability — and change management, supported by requirements engineering tools, keeps the requirements systematic, traceable, and manageable.

The whole session in one map:

• Content of requirements: user level vs system level (3.2); functional vs non-functional (3.5–3.8); stakeholders (3.3).
• Position in the life cycle: first stage, after a feasibility study (3.4).
• The process: elicitation (3.10) → specification (3.11) → validation (3.12), iterated as a spiral, with change management running throughout (3.13).
• The output: the software requirements specification — the basis for development, and possibly part of the contract.

3.14.2 Where we go next

The next session moves on to agile processes: how the incremental and iterative nature of development happens in agile methods, where requirements keep changing and are expressed as user stories.

Exam Guidance Summary

The session carries limited explicit exam information, but several signals are worth collecting:

• The user-level/system-level split and the functional versus non-functional distinction are "very fundamental topics" that the course revisits throughout the rest of the software engineering processes — including traceability between requirements and design. Expect these terms to keep appearing.
• The four main activities of the requirements engineering process — elicitation, specification, validation, and change management — and the relationship between them were explicitly listed as learning objectives for the session, so be able to describe each and how they interleave.
• Study advice given in the session: go through the corresponding modules in the courseware on requirements engineering.
• The next class moves to agile processes and the incremental, iterative approach to requirements in agile methods — expect the user-story view of requirements engineering to be built on top of today's material.
• The tree-and-swing requirements-mismatch example (from the previous session) is the course's illustration of why requirements errors are catastrophic late in the life cycle — a classic exam-style "why validation matters" point.
• The mentcare (mental health care system) example is the recurring case study for requirements and system modeling later in the course. Learn its structure: a network of psychiatric clinics providing counseling and treatment.
• The goal-to-testable rewrite pattern (Section 3.8) is a repeatable exam exercise: turn "easy to use," "quick response," or "user friendly" into a requirement with a measurable property, a unit, a bound, and a verification plan.

Key Industry Applications

• Real-world: banking — the ATM is the canonical stakeholder example: customer, teller, bank manager, ATM maintenance engineer, software, and banking regulators form a stakeholder chain, both internal and external.
• Real-world: healthcare — the mentcare system shows how domain constraints (health authority identity cards, patient privacy provisions, medical ethics managers, medical record staff) shape requirements beyond functionality.
• Real-world: medical devices — the insulin pump is the form-based specification example: function, description, inputs, outputs, destination, action, requirements, precondition, post-condition, side effects.
• Real-world: embedded control systems — performance requirements are met by organizing the system to minimize communication between components; missing performance requirements create hazardous consequences.
• Real-world: safety-critical certification — regulators such as a Nuclear Safety Authority or a Traffic Control Authority must approve systems before use; approval depends on non-functional requirements.
• Real-world: commercial off-the-shelf decisions — when a ready-made product meets needs, teams write information requirements instead of a detailed functional specification.
• Real-world: web and mobile application development — agile requirements engineering with user stories suits products where requirements keep changing.
• Real-world: test-driven development — writing tests from user requirements before code is written; standard in agile teams and spreading into plan-driven projects.
• Real-world: requirements management tools — DOORS, Rational Requisite Pro, and AHA are used in industry to identify, trace, and change requirements systematically.