Usability, Architecturally Significant Requirements, and Agile Architecture

6.1 Usability as a First-Class Quality Attribute

6.1.1 From Afterthought to Survival Trait

There was a time when design talk centered on performance, availability, security, maintainability, and testability. Usability was treated as decoration. The attitude went: the creative people will come along later and make the application pleasant to use.

That view has flipped over the last five to ten years. The most important thing now is to keep people glued to your application. Why did it flip? Because the market changed shape. The software space is crowded, and alternatives sit one click away. Most applications follow a pay-as-you-use model — you pay only while you use the service — so nobody makes a huge capital investment before trying you out.

An everyday picture makes the economics visible. Think of a food court: twenty stalls, one hungry customer, zero entry cost to try any of them. If your stall makes people queue with no sign of what they get, they walk two steps to the next counter. Old enterprise software was more like a wedding banquet hall booked a year in advance and paid in full — the guests ate what was served, like it or not. The analogy breaks where business software is concerned: some corporate systems still enjoy captive users, which is exactly why their interfaces lag behind consumer software by years.

This connects directly to the textbook view of usability: how easy it is for the user to accomplish a desired task, and the kind of support the system provides while doing it. Notice that this definition is architectural, not cosmetic. "The kind of support the system provides" means cancel buttons that actually work, help that appears when needed, and state that survives an interruption — all of these are properties of system structure, not skin-deep styling. In fact, usability has five recognized sub-areas, and each one maps to something an architect must plan for:

• Learning system features — what does the system do to make the first task easy for an unfamiliar user?
• Using the system efficiently — can the user redirect the system mid-task, suspend one activity, do something else, and resume?
• Minimizing the impact of errors — can a wrong command be canceled or undone before damage spreads?
• Adapting the system to user needs — does the system fill in known details, remember preferences, adjust to the person?
• Increasing confidence and satisfaction — does the user get feedback that the right thing is happening, especially during long operations?

6.1.2 Software That Assumes No Manual

Open any modern application and compare it with software from twenty or thirty years ago. Today's software does not expect anyone to read a user manual before operating it. At most, customized software offers a one-page pullout or a first screen that asks: "Want to see more? Would you like some guidance?" Most people skip even that. They believe they are smart enough to start immediately.

Here is the design consequence, and it is the sharpest sentence in this whole lecture:

That standard must sit at the back of your mind right through design, baked into every little piece of the product — not bolted on afterward. This is why usability is an architectural concern rather than a late-stage paint job. Guidance at the moment of need requires somewhere to hook it: the system must know what task the user is attempting (a model of the task), who the user is (a model of the user), and what the system itself is currently doing (a model of the system). We meet those three models formally in section 6.6 — but notice already that "know what the user is doing" is a structural property you must design in, not a color scheme you apply later.

Assumptions and scope deserve a word here. The no-manual expectation assumes a walk-up audience: people who arrive with no training and no obligation to stay. It applies with full force to consumer web applications and mobile apps. Inside a bank's back office, staff may still get weeks of training on a terminal system — but even there the tide moves the same way, because every trained person who leaves takes the training with them and the replacement expects modern ease.

6.1.3 Questions from the Class: WYSIWYG

Why did WYSIWYG matter so much? Because it removes a hidden learning tax. Before it, a user had to hold a mental translation table in their head — "this code on screen becomes that layout on paper" — and every document was an act of faith. WYSIWYG moved that translation into the machine, which is the general pattern behind most usability progress: take a burden the user carried and make the system carry it. Every modern editor, mail client, and word processor treats screen-print resemblance as table stakes; nobody ships one whose output surprises you.

Real-world: pay-as-you-use pricing removed the switching cost that once trapped customers with unloved software. Streaming services, cloud platforms, and ride-hailing apps all live or die by the second session — nobody signs a year-long lease before trying the interface.

6.2 Measuring Usability: Learnability in Action

6.2.1 Target-Audience Testing

Learnability is how quickly a chosen kind of user can learn to complete a real task. The word hides two variables that people often blur: who is learning, and how fast. A screen a shop-floor user masters in two minutes might baffle a chartered accountant, and neither finding says anything about the other group. That is why the test always starts by naming the audience.

The test itself is simple enough to run next week:

1. Declare the audience — for example, class-8 or class-12 graduates working on a shop floor.
2. State the bar — people of that type should perform a defined activity on this application within so many minutes.
3. Draw a random sample of such people — not your colleagues, not the developers.
4. Ask them to execute the activity while you observe silently.
5. Check completion against time. Completion within time is the pass mark.

Notice what makes this scientific rather than a vibe: the pass mark is a number attached to a named population. "Users find it intuitive" is an opinion; "eight of ten class-12 graduates complete a booking within five minutes" is a measurement.

6.2.2 The Airline Booking Benchmark

Put two similar applications side by side, both able to book an airline ticket. The one on which you can book quicker is the one we consider more usable.

Walk through what a good first page does:

• It asks only: where do you want to go, from where?
• The date field is optional and already filled in (today or tomorrow).
• One button says submit search — and it works.
• You get results immediately.

Then needs surface later, one by one. You realize the date is wrong, so you change it. Then you decide you want direct flights only. Then only particular airlines. Then a particular time of day. Each of these refinements should be easy to locate at the moment the need appears.

The lesson: win the first transaction, then reveal depth gradually. This is also why comparing two apps on booking speed is fair even when their feature lists differ — features are cheap to add behind a clean flow, but a crowded first screen taxes every single user on every single visit.

6.2.3 Error Prevention by Design

Take date entry. Type 31.4.2024 — a day that April does not have — and most systems today just laugh along with you, because the widget handles it. Not too long ago you could not take that for granted. You would enter the wrong date and receive an error saying the date is not supported.

Today the widget silently turns 31 April into 30 April, often without informing you. Edit an old stored record whose day reads 31, change the month to one with fewer days, and the day may roll over to the 1st. Here is the full correction table the widget is applying:

And when editing an existing record: day 31 stored, month changed to April → some widgets clamp to 30 April, others roll over to the 1st of May. Either way, the program shifts 31 down to 30, 28, or 29 depending on the last day of the month involved.

Destinations work the same way. When you type the destination, only destinations that exist can be typed, and a type-ahead help lists similar names as you go. Wrong input becomes impossible instead of punished. This is the same trick as the date widget at a higher level: constrain the input space so illegal values have nowhere to live.

Business rules join in. Book a ticket for an unaccompanied minor and the system immediately tells you: minors are not permitted to travel alone to this destination. If you go ahead, the booking must include airline assistance, and the cost is picked up automatically.

Real-world: Cleartrip, Easy Trip, MakeMyTrip, and every airline's own booking portal compete on exactly this feel. Users gravitate to whichever gives them confidence. IRCTC is a standing case discussion — its pros and cons then versus today, and the alternate sites selling the same services. Confidence, or the lack of it, is a usability outcome, not a slogan.

6.3 Aesthetics, Look-and-Feel, and the User Learning Curve

6.3.1 First Impressions and Substance

Aesthetics is very much part of usability. People say do not judge a book by its cover, yet that is exactly where most people end up judging it. So invest in appearance — but be careful.

A useful way to order the work: treat aesthetics as the packaging of a promise the rest of the system must keep. A polished screen sets an expectation of quality; if the cancel button then does nothing and the search takes thirty seconds, the same polish now works against you, because the gap between promise and delivery feels like deception rather than mere clumsiness.

6.3.2 Upgrades and the Learning Curve

DevOps-style environments roll out upgrades continuously, which creates a peculiar pattern worth naming:

Picture the learning curve as a graph: the horizontal axis is time using the application, the vertical axis is skill at it. Every feature addition bends that curve upward at the start — a steeper initial climb — before it flattens again. Users feel the steep part as "the new update ruined everything." The architect's job is not to stop adding features (that is slow death) but to flatten each new climb: introduce features behind menus users already understand, keep familiar actions in familiar places, and let power surface gradually.

WhatsApp is the standing example: it keeps its core dead simple while layering features carefully, which is why feature additions rarely trigger revolt there. Voice notes, statuses, payments, and communities arrived without ever moving the basic send-message act.

6.3.3 Specialization and Shared Conventions

Usability has grown its own specializations: human-computer interaction (HCI), human factors, aesthetics. There is a dedicated course many students take on human-computer interaction.

Shared conventions lower the curve. Learning is minimized when all applications share the same look and feel — the gear icon means settings everywhere, the hamburger opens a menu everywhere, red means destructive everywhere. Each convention your app adopts is knowledge the user gets for free; each convention you break is knowledge they must pay for. In fact, nowadays it is risky not to follow established best practices — a theme this course returns to.

Think of it the way Charles Darwin framed natural selection. Certain species survive; certain species of software survive too — the ones that feel standard and keep evolving. And evolve they must, because users get sick of the same look and feel after too long. Malls repaint and rearrange their getup every year or two to keep footfall coming. Software needs the same gradual evolution.

This is the same separation principle the textbooks push for the whole user interface: keep the interface layer loosely coupled from the rest of the system so its look can change freely — we will meet this again as defer-binding and encapsulation tactics later in the lecture.

6.4 The Usability General Scenario

6.4.1 Six Parts of the Scenario

The quality scenario gives usability a testable shape. Every quality attribute in this course uses the same six-part skeleton; for usability it fills in like this:

One concrete target shows the flavor:

The response-measure row deserves special attention because it is where most student answers go thin. "Users liked it" is not a measure. Task time in minutes, error counts per session, tasks completed per hour, satisfaction survey scores, and post-use knowledge checks all are — pick the ones your stakeholder actually cares about.

6.4.2 Configuration-Time Usability: Installation War Stories

Configuration-time usability deserves its own war stories, because the environment row has two legal values and the second one is easy to forget.

Generations improved, and each improvement is a usability tactic in disguise. First came hard disks big enough to dump whole stacks of floppies onto before configuring — staging media locally instead of swapping packs. Then CD drives arrived and boxes shrank from dozens of discs to a handful. Now everything downloads from the net, with resumable installers that save state after every step — exactly the staged-save pattern we meet under user-initiative tactics in section 6.5.

Buy a new laptop today and the experience of getting it working is smooth and short. Had Microsoft not evolved that setup experience, the world might be ruled by Mac or Linux instead. Even operating-system-level setup counts as usability, and it shapes which platforms win.

6.5 Usability Tactics: User Initiative

6.5.1 Cancel, Undo, Pause, Aggregate

User-initiative tactics put control in the user's hands: cancel an action, undo it, pause midway, resume later, aggregate scattered pieces into one view, and reuse earlier entries. The name matters: user initiative means the human decides when to act and the system must be ready to respond at any moment.

Behind those buttons sit supporting structures:

• Save the work at every stage, so nothing dies with a dropped connection or closed tab.
• Provide separate pages for separate tasks so navigation stays easy.
• Show which tasks are already completed, so the user always knows where they stand.
• Let the user review whatever was uploaded, gather everything together, check which points remain, run a final checkout, and only then allow submission.

6.5.2 Case Study: Online Visa Applications

Watch a visa portal through ten years of use and the evolution is huge — it is the four supporting structures above appearing one by one.

Yet even today the usability may not be good enough for everybody. People still try to apply for visas to major countries and wrestle with the portal for a day or two. Then they hire a paid consulting service to do it for them.

Real-world: Passport Seva Kendra-style government portals show the same arc — painful beginnings, then staged saving and appointment systems that work — while some national visa portals still push applicants toward paid agents.

6.6 Usability Tactics: System Initiative Models

6.6.1 User Model

System-initiative tactics flip the roles of section 6.5: now the system reaches toward the user instead of waiting for commands. To do that responsibly, the system must predict — and prediction requires a model. Three models exist, one for each thing worth predicting: the user, the task, and the system itself.

The user model keeps track of the user and gives continuity:

• Log in and it picks up where you left off.
• If you were mid-task and never logged out, the system remembers what you were doing.
• Working on a mobile? The application remembers which activity you had done — start on the laptop, continue on the phone.

Deeper still, the user model represents the user's knowledge of the system and typical responses. A well-built model can pace itself to the user: slow down suggestions for a newcomer, speed up shortcuts for an expert, control how much assistance appears automatically. Enter your name once and it can help fill in name, address, pin code — the works.

Personalization flows from the same idea. Ask what food someone would like for dinner and hear "biryani"; ask further and learn the preference order between biryani, South Indian food, and continental. Taste differs for every person, so focus on the user segment rather than the individual where individual data is thin. Marketing's old idea of market segmentation applies directly: know your market, figure out what your users require, and ultimately convert that knowledge into revenue. A streaming service that cannot name its five biggest audience segments is not personalizing; it is guessing loudly.

6.6.2 Task Model

The task model says: while the user executes a particular task, surface all the features that task requires, and check whether the task has been completed. The system knows what you are trying to do and brings exactly that toolset forward — nothing more, nothing missing.

Step-by-step workflow screens are the visible face of this model. They lay out the whole path and show exactly where you stand at present and where you will navigate next — the visa portal's eight-step progress bar from section 6.5 is a task model made visible.

6.6.3 System Model

The system model maintains an explicit model of the system itself — what the system is currently doing and what it will do next — so it can give the user honest feedback about its own state. On a visa application system, it knows which option you chose across the various categories of visas, and it knows the behavior of the processing pipeline. Come back tomorrow and the first thing it tells you is: your application is in process, awaiting response.

Because processing times are standardized — normally ten days end to end, five days between given checkpoints — it can even show a countdown, giving progressive feedback on where you stand. That countdown is the textbook's classic manifestation of this tactic: the progress bar. A progress bar is only possible because somewhere the system keeps an explicit expectation of its own behavior and compares reality against it.

The system also keeps track of the types of problems users have had and how to respond to them — if thousands of users stall at the payment step, the system (and its owners) learn to surface help right there.

Together, user model, task model, and system model form the system-initiative toolkit for enhancing user behavior. Keep them distinct in your head by their objects: the user model predicts the person, the task model predicts the work, the system model predicts the machine.

6.7 Responsibility Allocation and Proactive Support

6.7.1 Assigning the Work

Usability tasks will not happen on their own. Allocation of responsibility means assigning duties to systems, subsystems, and people so the tasks required for usability are efficiently performed. This is a standard architectural design decision — every duty needs an owner, and "the user will figure it out" is not an owner.

As part of the development effort, work through the allocation deliberately:

• Decide what the learning model will be — who or what teaches a new user the system.
• Decide how each task gets achieved and how the flow is worked out.
• Brainstorm configuration questions with the people actually involved in deployment — the folks who install the system know where setup hurts.
• Stand up a system for logging system errors, define how they are attended, and keep asking how the handling can enhance the user's experience rather than merely record its failure.

A wave of experts publishing videos on informing and enhancing usability has appeared in recent years — useful material for anyone involved in system design.

6.7.2 Reaching Out When Things Break

The strongest usability moves are proactive: the system notices trouble first and reaches out before frustration sets in.

Chatbots belong in the same family: automated conversational helpers that catch users the moment trouble starts, available at the exact second of need — which is precisely what section 6.1 demanded support should be.

Real-world: banks calling about failed payments of a lakh rupees, WhatsApp recovery nudges within sixty seconds, and IVRS-authenticated telephone bookings are all production patterns today; chatbots extend the same channel family.

6.8 Architectural Decisions That Shape Usability

Usability is not decided in the paint layer; it is decided in a handful of recurring architectural decision categories. Sections 6.7 and 6.9 cover two more of them (allocation of responsibilities, binding time, choice of technology); this section walks the middle four.

6.8.1 Coordination Model

Usability has much to do with timeliness, currency, completeness, correctness, and consistency of behavior. The coordination model defines how those properties get achieved across interacting parts.

Concretely, ask questions like these of any design:

• Can the system respond to mouse events and give meaningful feedback in real time?
• Can a long-running event be canceled within a reasonable amount of time? (Recall from 6.5 that cancel needs an unblocked listener — that listener lives here.)
• When two parts of the system show related information, do they agree — or does the cart page disagree with the checkout page?

Each "no" is a coordination decision waiting to be made, and every one lands directly on the user's experience.

6.8.2 Data Model

The data model decides where data lives: centralized storage, local storage, application-level storage, storage in RAM, in a file, or in a database. On mobile devices you may specifically want SQLite — the lightweight embedded database that runs inside the app process with no separate server, which is why it is the default workhorse for on-device state.

6.8.3 Mapping Among Architectural Elements

Achieving any task may involve third-party APIs. Uber makes huge use of Google Maps; travel sites integrate banking systems for payments. Within your own system, certain activities run on the device, others on the server, some at the application level, some at the database level.

Mapping means tying each activity to the hardware or software unit that will perform it — and doing that mapping well is part of usable design. The key question: which mappings are visible to the end user? A user who can tell that the map loads locally but prices come from a remote service experiences helpful structure; a user who stares at a blank screen because a remote call stalls has experienced a bad mapping. Put slow, remote operations behind progress feedback and local-first interactions wherever possible.

6.8.4 Resource Management

Resource management asks: what type of resources must be provided, and where will they be provided, so the task can be achieved? Bandwidth, compute, storage, and third-party quotas all need homes before the user ever feels a stall.

Two checks keep this honest:

1. User-controlled configurations must not sabotage tasks. If users can choose settings that change resource use — offline mode, sync frequency, video quality — ensure no reachable configuration produces response times that make tasks effectively impossible.
2. Resource limits must not tax learning or confidence. A first-time user on a low-end phone should learn the system just as easily as one on a flagship device; if your tutorial videos assume bandwidth the user's plan denies, the resource decision just became a usability failure.

Real-world: SQLite inside mobile apps, Uber's deep Google Maps integration, and payment-gateway integrations on travel sites are all mapping-and-data-model decisions made years before a user ever tapped a button.

6.9 Binding Time and Technology Choice

6.9.1 Decisions at Different Moments

Binding time is the classic architecture question: runtime binding versus compile-time binding — deciding when a choice gets frozen. For usability, ask finer questions:

• Which decisions must be taken when the system is set up?
• Which when the user starts, say, a booking?
• Which can wait until even later?

The same logic runs inside development too: deferring binding of user-interface choices lets you change screens without recoding the core — which is why interface prototyping works at all.

6.9.2 Plugins Added While Operating

Plugins push late binding further: capabilities you attach without deciding up front. Flight-booking assistance comes as plugins — a wheelchair, or a meet-and-assist service such as Marhaba, the airport hospitality service operating at major Gulf hubs. For a charge, somebody escorts you from the entrance gate to the aeroplane; the escort then walks back with you through customs and baggage until you meet the people who came to receive you.

Such facilities matter for senior citizens and people with special abilities. And notice the binding-time point: you do not need to decide about them when the booking starts. They attach to an existing itinerary while the system is already in operation. Many features like these get added to systems while they are running — no rebuild, no redeployment of the core.

6.9.3 Two Restaurant Analogies

Where the analogy maps onto software: the classy restaurant's capability is a flexible platform plus skilled operators — cost per request is higher, response is immediate, and surprises are absorbed. The catered party's configuration is deployment-time setup and testing — expensive once, then cheap and uniform at scale. Choose early binding when the requirement is known, stable, and must scale identically thousands of times; choose late binding when needs arrive unpredictably and variety is the product.

6.9.4 Late Binding with Third-Party Services

In software, late binding means services hosted anywhere in the world become reachable through an orchestrating service or a service-lookup facility. They plug in and behave as if they had always been part of your system. Binding third-party services this way, purely to give a better usability experience, is late binding in action — the payment gateway appears mid-checkout era, the maps layer appears when the tracking page is designed, and neither required rebuilding the application.

6.9.5 Choice of Technology

Technology choice serves interaction. For a company application you might standardize one brand, size, and configuration of tablet, mobile, or desktop — one device profile means every usability test generalizes. For public-facing service you might evaluate kiosks: look up available brands, their capabilities, their size, their touch and feel.

6.10 Architecturally Significant Requirements

6.10.1 What ASRs Are and Why They Hide

ASR stands for architecturally significant requirement — the few requirements that actually determine the shape of the architecture.

How do you gather them? Smell them out. It sounds like a joke, but it is nearly literal — the professional literature itself talks of "sniffing out" ASRs from requirements documents, because they do not arrive on a platter. Plenty of requirements pour in; you must figure out which handful are architecturally significant. A practical filter from the same source: if a requirement would change one of your critical architectural decisions — allocation of responsibilities, coordination model, data model, resource management, mapping among elements, binding time, choice of technology — then it is by definition significant. Everything else is detail that the architecture can absorb without changing shape.

The tell-tale comes afterward. Once you identify them, the customer insists, "I told you that — that's exactly what I told you." They did tell you, buried somewhere in the pile. Digging the significant ones out is your job, and it starts at the very first meeting — competent architects begin by talking to the important stakeholders whether or not any document exists yet.

6.10.2 Business Goals Come First

To understand requirements at all, understand business goals. Requirements point toward business goals, and the architecturally significant ones are the requirements the architecture is determined by. Many ASRs never appear in any requirements document at all — they derive from the business goals of the organization building or buying the system, which is why reading documents alone is never enough.

6.10.3 NFRs Are Quality Requirements

Decode the jargon here. In IT circles people chant NFR, NFR, NFR. NFR means non-functional requirement, and an NFR is nothing but a quality attribute wearing an acronym.

Real-world: hiring interviews and design reviews constantly probe this skill — given a pile of stakeholder statements, which three reshape the architecture? That is the daily exercise of the job this lecture is preparing you for, and the assignment in the next section makes you do it deliberately.

6.11 Documenting an Existing System: The Assignment Blueprint

6.11.1 Purpose and Seven Parts

The assignment, worth five marks, builds familiarity with software architecture by having you choose an existing system from your workplace. The reason: exposure to a real system you may actually work on. Understand why the system exists, its goals, its key requirements, who the stakeholders are, what components it has, and how it is laid out. Do all that analysis — but report only seven things:

1. Purpose — state in one line why the system exists.
2. Key requirements — functional and non-functional. Booking an airline ticket, from selecting the flight through making the payment, is a functional responsibility. Non-functional means one or two specific quality scenarios — availability, or another quality, spelled out concretely.
3. Utility tree — architecturally significant requirements listed as a tree (next subsection).
4. Tactics for the top five ASRs — not every tactic studied in recent lectures; only the tactics your chosen system actually uses to satisfy its significant requirements. Smell out the requirements, then name the tactics you observe in action.
5. Diagrams — context diagram, module decomposition, component-and-connector, deployment. One or two good diagrams can be enough; the cap is tight — at most four diagrams.
6. How the system works — a brief description.
7. Key learning — how the exercise benefited YOU as a student and software engineer. Not the benefit to the system. Did executing this activity make you better at working in the IT space? Candor is allowed: if it truly taught nothing, say so — though the hope is you leave able to use what the course taught.

Notice how the seven parts mirror this lecture's own arc: purpose and requirements are section 6.10's ASR hunt, the utility tree is ASR capture, tactics are the usability-and-quality tactic catalogs, and the diagrams are the views we take up again in section 6.12.

6.11.2 The Utility Tree

Why call it a utility tree? In the professional literature, "utility" names the overall goodness of a system — the root expresses everything the system should be good at. The trunk says quality. Under quality hang branches — the various quality attributes covered in this course. Stick to the course attributes; inventing new ones is not wanted. Under each attribute, write the scenario in plain English: what the situation is, in one readable sentence.

The tree turns vague quality wishes into placed, inspectable leaves — and empty branches tell you something too: a quality attribute with no scenarios under it means that area has not been thought through.

6.11.3 Staying High-Level; Confidentiality; Honest Learning

Confidentiality rules protect you. Never violate company policy. Say you work somewhere secretive and the real architecture is confidential. Describe what the company itself prints on its public website — that cannot be confidential — with a little added description. Nothing is so secret that even the customer does not know it; claiming otherwise goes too far. If your domain is genuinely sensitive — the class heard the example of proprietary tactics that hide drones from radars — pick an application outside that domain entirely. Using a generic name instead of the real product name is fine, and a bit of insider knowledge, where permitted, makes the report stronger.

6.12 Documentation in an Agile World

6.12.1 The Right Dose

Agile environments are rightly wary of over-documentation, yet documentation matters more in agile settings, not less, because people join and leave projects constantly. Every departure walks out the door with undocumented knowledge; every newcomer arrives needing exactly what a good document holds.

The contrast with the past is stark. Sybase was then a major competitor to Oracle as a database, an excellent product. Buying a copy meant building a cabinet to host the manuals: around twenty volumes. Books were scarce in the market, so you depended on manuals, and manuals were printed and bound. The accounts department inspected the physical manuals before releasing payment — and plenty of old-fashioned managers still want paper before they pay.

Against that backdrop, modern documentation is need-based: document the architecture briefly so people who onboard know what they will be doing and stakeholders know what will be delivered. Then stop. Do not over-document. Ask of every proposed page: who reads this, and when? If no named reader exists, neither does the page's job.

6.12.2 Views and Scenario-Based Quality Documentation

A documentation package contains a number of views — each view is a rendering of the architecture from one angle, suited to one kind of reader. Part of the architect's job is figuring out which combination of views fits the project. Several combinations are possible, and the options repay quick study.

Whatever the mix, documentation should capture three kinds of things:

1. The elements themselves — the module view: what the code is divided into, and which modules depend on which.
2. The behavior — the component-and-connector view: what runs at runtime, how the pieces talk, what the channels are.
3. The quality attributes — often forgotten, always decisive. A third family, allocation views, maps software elements onto the hardware, teams, or environments that host them, closing the loop between design and deployment.

Quality enters the document through scenarios written the way this course teaches them. Each scenario names a source of stimulus, a stimulus, an artifact, an environment, and a response that is measurable — the six-part skeleton from section 6.4 doing duty as documentation.

Real-world: Facebook, Twitter, LinkedIn, WhatsApp, and MS Teams thrive with no visible end-user documentation — working software over comprehensive paperwork — yet each maintains internal architecture documents for its engineers, which is precisely the need-based dose this section prescribes.

6.13 Architecture Stability in a Changing World

6.13.1 Detailed Design Is a Flying Bird

Yet an architect must produce an architecture that stays more or less stable across the entire development run. That means finding cornerstones — decisions true enough about the future that you can hold the system to them while everything else shifts.

What qualifies as a cornerstone? Decisions whose change would be catastrophic: the split into major subsystems, the choice of coordination style between them, where the system's data lives, the qualities it must guarantee. What does not? Screen layouts, table columns, message formats — things detailed design can keep moving with. If everything changes — cornerstones included — you end up starting from the very beginning, which is precisely what a stable architecture exists to prevent.

6.13.2 The School-to-Mall Thought Experiment

A building makes the idea concrete. Suppose you construct a building for a school, and later the owner wants to turn it into a shopping mall with a multiplex. Where do the multiplex screens even go? The play area probably becomes a courtyard lined with stalls. Classrooms become individual shops — except the rooms are too large to sell as single shops, so walls must subdivide them. Doors move. The window layout may misfit. The walking area is wrong: mall customers expect generous movement space outside shops, while classrooms need only narrow corridors.

Now sharpen it, because the first version flatters architecture too much:

But suppose everyone had known from day one that the building would become a shopping mall. Then the facade, the look and feel, the movement plan, and the traffic flow would have been designed for that purpose. Details could fill in gradually as tenants appeared — a pharmacy here, a food court there — without touching pillars or beams.

Software is identical: understand the significant requirements early (section 6.10), freeze the cornerstones, and variations stop wrecking your timelines. The ASRs are the pillars; everything else is drywall.

6.13.3 What Makes an Architect

An architect has to be a visionary, technically very strong, and clear about which items must freeze early so project timelines survive later variation. Creating a stable architecture takes real creativity, which is why the role demands enormous experience — and not only of the domain.

A running argument illustrates the tension. Someone insisted core technical knowledge matters more than domain knowledge, since one can switch domains any number of times and technical skill travels freely. Hiring reality disagrees — when organizations look for people, they look for domain exposure.

Real-world: architects who survive a decade in banking systems become rare and expensive precisely because the domain knowledge compounds on top of the technical base — either half alone is half an architect.

6.14 Agile and Architecture Together

6.14.1 How Waterfall Projects Broke

Software architecture as a named discipline dates to the early 1990s — roughly thirty to thirty-five years of practice. Before that, large projects meant a series of programs run top-down, the style of the 1970s and 1980s, which is not worth comparing here.

The old recipe went: understand the customer's requirement thoroughly, document it, get sign-off, build with only occasional clarification calls, then deliver. The job never got done. The customer rejected most of the delivery with the feeling that it simply did not serve the requirements. Practitioners called it the late break — the discovery that requirements had moved arrived latest of all, after the money was spent. Then came redoing; if luck ran out, a restart from zero. Restarts slid into litigation, because neither the developer could afford the loss nor the customer accept the result.

Agility exists for exactly this. Start climbing the wrong hill and somebody calls from behind: pal, that is not it — because everybody is watching you climb. Interaction with users stays dense, and in today's DevOps environment it is absolutely continuous.

6.14.2 Both, Not Either

People say: either I have architecture or I have agile; I cannot have both. That is false. You must formally document the architecture and still stay agile — and while doing it, minimize the documentation. The professional literature states the real question directly: not "Agile or architecture?" but "how much architecture, up front versus deferred, and how much documented?" The two are critical companions, not rivals.

The Agile Manifesto frames the balance. Dating deserves one careful sentence, because two numbers float around: the manifesto itself was signed in 2001 by seventeen leading figures of the software industry, nearly every big name of the era, many still influential today — while the movement's roots extend back into the early-to-mid 1990s, in practices like Extreme Programming and Scrum that predate the signing by years. Both facts are true; they answer different questions. Its four values:

1. Individuals and interactions over processes and tools. Good people make processes work.

Even today, with artificial intelligence everywhere, the best people keep their place; tools replace only the people whose work was process-shaped anyway.

1. Working software over comprehensive documentation. If your software works, who cares about the documentation? Nobody has seen documentation for Facebook, Twitter, LinkedIn, or WhatsApp — nor for MS Teams, nor attended a training program to start using it. The software works and is usable intuitively, so documentation finds no role for the end user. Keep need-based documents internally: a brief architecture description so newcomers know the mission and stakeholders know what will be delivered. Just that much — section 6.12's medicine dose.

1. Customer collaboration over contract negotiation. Years past saw enormous effort — even court cases — determining whether work matched the contract. Collaborative work is what actually succeeds. Constant contact gives the customer flexibility and a proper appreciation of what the paid value buys, while the developer stays interested in giving value for money. With good collaboration, negotiation stops helping. When variation appears there is room for give and take — we will do this, we cannot do that. Then pen it, paper it, and take it through the project control board or whatever change-management mechanism exists.

1. Responding to change over following a plan. Never start without a plan — but hold it loosely. With a plan you can change it; without one, what would you change? Respond to shifting requirements and environment, and always know why you are making a change: this was the plan, it becomes that, for this stated reason.

6.14.3 The Twelve Principles and the People

Beyond the values sit twelve principles, published at agilemanifesto.org — one word, no dash — and worth reading directly rather than taking second-hand. They include early and continuous delivery of valuable software, welcoming changing requirements even late in development, frequent delivery in weeks rather than months, daily collaboration between business people and developers, building around motivated individuals, face-to-face conversation as the most efficient communication, working software as the primary measure of progress, sustainable pace, continuous attention to technical excellence, simplicity (maximizing the work not done), self-organizing teams, and regular reflection on how to become more effective.

The names behind the manifesto read like an industry hall of fame — all seventeen signatories were leading practitioners, and the roster includes Robert C. Martin, famous as Uncle Bob (if you are a designer in any form, watch his videos); Martin Fowler, the authority on UML; Ward Cunningham of Cunningham fame; Alistair Cockburn and the Cockburn rules; James Grenning; Jeff Sutherland; Dave Thomas; and Ken Schwaber. Books by these authors are famous and repay reading.

Real-world: Scrum and Extreme Programming grew from those early-1990s roots into today's default vocabulary of sprints, stand-ups, and refactoring — the movement the seventeen signatories gave a name in 2001.

6.15 Planning Investment versus Rework Cost

6.15.1 Reading the KSLOC Curves

KSLOC means kilo software lines of code — a way of measuring the volume of a software product. (Texts usually expand it as thousands, or kilo, of source lines of code; same measure either way — one KSLOC is one thousand lines.) A well-known chart — analyzed by Boehm and Turner from historical data on 161 industrial projects, using the COCOMO II cost model's architecture-and-risk-resolution factor — plots how much of a project's schedule should go into up-front planning.

The pattern is simple: the larger the project, the steeper the rework curve falls as planning rises — so the larger the project, the larger the percentage of investment that should go into up-front architecture and risk resolution. For a very small project the payoff curve is virtually flat; planning buys almost nothing because there is little enough work that redoing it is cheap anyway. For a mediocre project the curve is shallower. For a very large project it climbs steeply — unplanned errors multiply across a million lines.

6.15.2 Worked Numbers: The 90 Percent Penalty

Each planning curve pairs with a rework curve: the less you spend on planning, the more schedule you burn reworking. Add the two curves and you get the total percentage added to the schedule — rework addition plus planning addition. The lowest point of that total is the sweet spot: the planning level that minimizes total cost.

For large projects the total comes out least at the sweet spot, and good planning plus good stakeholder interaction carries huge weight.

6.15.3 Sweet Spots and Residual Risk

The sweet spot moves with project size:

For a very small project, the minimum of the total curve sits right at the beginning. There is no point spending heavily on architecture or flying in big-name architects to plan a tiny job. For a very large project — think 10,000 KSLOC — invest near the top of the planning range so rework is cut down. Rework is a headache in any case: it messes up your code, your project, everything else.

Real-world: capacity planners and engineering managers use exactly this trade-off when they decide how many weeks of design review a new service deserves before code may start — small internal tools ship in days, while core payment ledgers get months of architecture and risk work first.

Exam Guidance Summary

• Exam note: the quiz opens on the 19th and runs to the 28th. It is time-limited to 30 minutes and allows a single attempt — do not log in until you truly have 30 minutes free.
• Exam note: when the quiz closes, the result announces automatically, so no extension is possible even if requested.
• Exam note: do the quiz in its first five days and treat the last five days as a makeup buffer. No extra time comes with a makeup, and life intervenes — illness, weddings, sudden duty travel.
• Exam note: Assignment 1 opens on the 19th and closes on the 28th, with a few extra days likely for this one. Assignment 2 will NOT get extra days — do not assume symmetry.
• Exam note: Assignment 1 format — five marks, one page per part, PDF preferred, ten pages total, at most four diagrams, high-level views only.
• Exam note: before the next session, read up on utility trees using internet research; next week's material may be released early for deeper preparation.
• Exam note: midterm pattern questions barely help at this stage; the topic moves to next week.
• Exam note: trade-off analysis is the subject of an upcoming session in the near future.

Key Industry Applications

• Real-world: WhatsApp — restrained feature layering protects usability across continuous DevOps upgrades; the core send-message act never moves, so each addition flattens its own learning curve.
• Real-world: Cleartrip, Easy Trip, MakeMyTrip, and airline-owned portals compete on booking speed and confidence — two fields and a working submit button win the first transaction; IRCTC's evolution is a standing case discussion.
• Real-world: Passport Seva Kendra — online passport applications evolved dramatically, and the in-person center experience is polished; TCS served as the support provider for many centers.
• Real-world: Oracle installations from version four/five through eleven trace configuration-time usability pain: driver hunts, OS patches, roughly fifteen CDs, restart-on-error — the environment row of the general scenario done badly.
• Real-world: Sybase shipped around twenty manual volumes needing a cabinet — the anti-pattern for need-based documentation.
• Real-world: Microsoft, Mac, and Linux platform setup experiences show OS-level usability shaping market outcomes; smooth setup is why Windows kept the desktop.
• Real-world: SQLite serves as the mobile-side storage choice inside the data model decision — an embedded database with no server, ideal for local-first drafts that survive dropped connections.
• Real-world: Uber leans heavily on Google Maps via third-party APIs; banking integrations power payments — mapping activities to external units is part of usable design.
• Real-world: Banks proactively call about failed payments of a lakh rupees and reactivate them; IVRS authenticates telephone bookings — proactive support converting failures into saved transactions.
• Real-world: Government visa portals illustrate staged saving, task models, and remaining usability gaps that push applicants to paid consultants — abandonment to consultants as the sharpest usability signal.
• Real-world: Facebook, Twitter, LinkedIn, WhatsApp, and MS Teams thrive with no visible end-user documentation — working software over comprehensive documentation.
• Real-world: Chatbots extend proactive support channels alongside WhatsApp, SMS, and telephone callbacks, catching users at the moment of need.
• Real-world: Marhaba-style meet-and-assist airport services ship as late-bound plugins for senior citizens and travelers with special abilities — capabilities attached while the system operates.
• Real-world: WYSIWYG editors made screen-print resemblance the minimum expectation of interactive software — the machine absorbing a translation burden users once carried.
• Real-world: agilemanifesto.org hosts the Agile Manifesto and its twelve principles; videos and books by Robert C. Martin (Uncle Bob), Martin Fowler, Ward Cunningham, Alistair Cockburn, Jeff Sutherland, Dave Thomas, James Grenning, and Ken Schwaber are standard professional reading.
• Real-world: HCI, human factors, and aesthetics grew into dedicated specializations and university courses, mirroring medicine's drift from MBBS to retina specialists.