Week 3, second lecture. Lecture 1 listed what an architect does; this one gives the order in which it is done, and then studies the first step, understanding the requirements, in detail.

Part 1 is the five-step architecture process (slide 3).

Part 2 is requirements engineering, the discipline behind step 1, with its four activities: elicitation, analysis, specification, validation.

Understand and evaluate requirements: find the architectural drivers, meaning the requirements, quality attributes and constraints that will shape the structure.

Design the architecture: define the major structures (components, connectors) and the design decisions behind them.

Evaluate the architecture: check whether it satisfies the important requirements and stakeholder concerns before building on it.

Document the architecture: communicate the structures and decisions to everyone who needs them (chapter 9).

Monitor and control implementation: check that the code stays consistent with the architecture. This is design synchronicity from Lecture 1, and it is why architecture work doesn’t end when coding starts.

Requirements engineering is the part of software engineering concerned with a systematic approach to requirements: getting them, understanding them and writing them down properly.

It has four activities, explained on the next slides: elicitation (discover), analysis (clean up), specification (document) and validation (confirm).

Architects spend a lot of time here. Even after requirements are specified they keep going back and forth between requirements and design, because designing exposes gaps and conflicts. On some projects they are completely immersed in the requirements phase and help write the specification.

Elicitation is the discovery activity: identify the stakeholders, uncover what the customer needs and wants, and determine the non-functional requirements (which customers rarely state unprompted).

It starts by listing every source of information that can produce requirements, before collecting a single requirement.

Sources may have similar but different visions of the system: two departments can describe “the same” workflow differently. Spotting that early prevents conflicts later.

Common sources: stakeholders; goals (the business objectives the system serves); domain knowledge (how banking, medicine or education works); and the operational and organisational environment (existing systems, policies, hardware the new system must live with).

Interviews: ask stakeholders directly, one at a time or in small groups. Good for detail; limited by what people remember to say.

Facilitated meetings (workshops): bring stakeholder groups together with a facilitator so conflicting views surface and get discussed in one place.

Observation: watch users do their current work. It reveals steps and workarounds that people never mention in interviews because they take them for granted.

Scenarios: walk through concrete stories of use (“a student registers for a full course…”) to discover what the system must do and how it should respond.

Analysis takes requirements in their raw form and fixes the ones that are contradictory, incomplete, vague or simply wrong.

Contradiction example: one requirement says the system runs 24/7, another needs daily maintenance downtime. Both can’t be true as written, so someone must decide.

Analysis lets architects clear the air about what really needs to be done before they invest in detailed designs.

Its four tasks: classification (slide 9), prioritisation and negotiation (slide 10), and conceptual modelling (slide 11).

R1 Secure login is vague: “secure” could mean a password, two-factor authentication or a fingerprint. Resolution: clarify the exact login method with the stakeholders.

R2 Fast & seamless experience may conflict with R1, since strong security slows things down. Resolution: a design that balances the two (efficient encryption, smart caching).

R3 Multiple payment methods is incomplete: which methods (card, PayPal, crypto)? Resolution: define them explicitly.

R4 24/7 availability contradicts the need for maintenance downtime. Resolution: rolling updates or redundant servers, so updates happen without the service going down. Each row is one of slide 7’s problem types.

Classification identifies the nature of each requirement, along three independent axes.

Functional vs. non-functional: functional says what the system does (“users can log in”); non-functional says how well it behaves (“the page loads within 2 seconds”).

Product vs. process: a product requirement is about the delivered software (“the app supports online payments”); a process requirement is about how it is developed (“the app must be developed using Agile”).

Imposed vs. derived: an imposed requirement comes straight from stakeholders (“the app runs on iOS and Android”); a derived one is worked out by the team to meet a higher goal (“to support both platforms, use Flutter”).

Prioritisation identifies the most important functions: login security matters more than a theme colour.

Done well, it refines the schedule by deciding which requirements are handled first: payment and security early, less urgent features later.

It also defines the builds (releases): Release 1 has the core features, Release 2 adds the chatbot and extras.

And it supports negotiation when requirements conflict: “security now, chatbot in a later update” is a negotiated outcome based on priority.

Conceptual models help identify requirements by showing their context, the system’s boundaries, and how the system interacts with its environment.

Boundaries decide what is inside and outside the system. Online banking: login, balance and transfers are inside; ATM hardware and cash withdrawal are outside. Getting this wrong means designing (or forgetting) whole subsystems.

This is often where architectural design begins, because building a good conceptual model already requires decomposing the system into parts. The slide marks this as important.

Specification formally captures the results of elicitation and analysis in a document format that every stakeholder can use and review (the SRS).

Validation: stakeholders review the documented requirements to confirm they are accurate, complete and feasible, i.e. that they really represent their needs.

Each requirement must have six characteristics: specific, correct, complete, consistent, attainable, verifiable. Slides 13–18 take them one at a time.

Specific has three parts: the requirement is clear, concise and exclusive.

Clear: not open to interpretation. Ambiguity leads to wrong designs, wrong code, and deceptive validation: a test can “pass” against one reading of the requirement while the stakeholder meant another.

Concise: short and to the point, so it is easy to understand.

Exclusive: each requirement states one and only one thing, which makes it easy to verify; a requirement that bundles two things can be half met.

Specific examples: searching by product ID, authenticating with user ID and password, acknowledging within ½ second. Each says exactly what, how, or how much.

“The software shall search the database” is not specific: search for what, by which criteria, returning what?

“The software shall be secure” is not specific: security covers encryption, authentication, access control… which one is required?

“Secure and fast” fails twice: two vague qualities in one sentence (not exclusive), with no measurable meaning for either.

A requirement is correct when it accurately describes a function the stakeholders actually want. A wrong requirement, implemented perfectly, still gives wrong or undesired behaviour.

The cartoon is an incorrect requirement in action. The specification said each user ID + password combination must be unique, so registering as user123/pwd123 is rejected with “you must use a unique combination”. But that error tells the new user that someone else already has exactly that username and password: the system has just given away another person’s login. The code did what the requirement said; the requirement was wrong. (Usernames should be unique; passwords should never be compared across users.)

Complete applies at two levels. Individually, each requirement is specified thoroughly enough to describe fully the function it asks for.

Collectively, the whole set in the SRS (software requirements specification) must cover all the required functionality: nothing missing, everything specified. A perfect login requirement doesn’t make the SRS complete if account recovery was never written down.

Incompleteness propagates: incomplete requirements → incomplete design → incomplete construction.

Consistent: requirements don’t preclude (prevent) the design or construction of other requirements, i.e. no conflicts.

Consistent pair: “support online payments” and “support credit-card payments” work together. Conflicting pair: “the system must be offline only” and “the system must support online payments”.

Attainable: unattainable requirements serve no purpose. A requirement is attainable if it can realistically be achieved within the project’s constraints of time, technology, budget and resources, and this applies to both product and process requirements.

Attainable: “handle 1,000 simultaneous users”. Not attainable: “handle 1 billion users on a $500 budget”.

Verifiable is perhaps the most obvious desirable characteristic: there must be a suitable way (test, measurement, demonstration) to confirm the requirement has been met.

A requirement that can’t be verified can’t be claimed as met, and being unable to verify a requirement points to a serious flaw early in development: nobody knows what “done” means.

“The system shall maximise speed” is not verifiable (maximise compared with what?). “The system’s data rate shall be at least 1 Mbps” is. Rule of thumb: use numbers, limits or conditions.

This lecture gave the basics of requirements engineering, enough to write good requirements: elicit, analyse, specify and validate, then check each requirement against the six characteristics.

Next: designing the architecture with the 4+1 view model: logical, development, process and physical views, plus the user (scenario) view that ties them together.