SOFTWARE DESIGN is the process of applying various techniques and principles for the purpose of defining a device, a process or a system in sufficient detail to permit its physical realisation. (IEEE / Taylor's definition, restated) IT SITS BETWEEN two very different kinds of document: REQUIREMENTS problem-oriented, in the customer's language, says WHAT DESIGN solution-oriented, in the engineer's language, says HOW CODE the executable realisation Design is a CREATIVE activity — there is no algorithm that converts a requirements document into a design. Two competent teams given the same SRS produce different designs, and both may be correct. What design methods provide is not an answer but a way of ORGANISING the search and of CHECKING the result. DESIGN IS A WICKED PROBLEM: you cannot fully understand the problem until you have attempted a solution, and the attempt changes your understanding of the problem. This is why design is iterative and why the first design is always wrong in places. TWO LEVELS, the standard split: ARCHITECTURAL DESIGN (high-level / preliminary design) Identify the SUBSYSTEMS making up the system and the framework for subsystem control and communication. Output: an architecture description. → decides the properties you cannot retrofit: performance ceiling, availability, scalability, security boundary DETAILED DESIGN (low-level design) For each subsystem, design its components, their interfaces, their data structures and their algorithms. Output: component specifications, data designs, algorithms. → decides how pleasant the code is to write and maintain Between them sits INTERFACE DESIGN, which specifies the boundaries so that detailed design of each subsystem can proceed INDEPENDENTLY AND IN PARALLEL. This is the practical reason architecture comes first.

A GENERIC DESIGN PROCESS, activity by activity. In practice these overlap and iterate; the ordering below is the dependency order, not a schedule. 1. ARCHITECTURAL DESIGN Identify subsystems, and the relationships between them. Output: block diagram / architecture description. 2. ABSTRACT SPECIFICATION For each subsystem, an abstract specification of the services it provides and the constraints it operates under. 3. INTERFACE DESIGN Design and document each subsystem's interface, so that the subsystem can be used without knowing how it works. Once frozen, parallel development becomes possible. 4. COMPONENT DESIGN Allocate services to components and design their interfaces. 5. DATA STRUCTURE DESIGN Design the data structures the implementation will use in detail. 6. ALGORITHM DESIGN Design the algorithms used to provide the services. DESIGN OUTPUTS at each stage feed the next, and every one of them is a document that will be reviewed: architecture spec → subsystem specs → interface specs → component specs → data structure spec → algorithm spec THE THREE CHARACTERISTICS OF A GOOD DESIGN (Pressman): 1. It must IMPLEMENT ALL EXPLICIT REQUIREMENTS from the analysis model, and accommodate all IMPLICIT requirements desired by the stakeholder. 2. It must be a READABLE, UNDERSTANDABLE guide for those who generate code and for those who test and subsequently maintain the software. 3. It should provide a COMPLETE PICTURE of the software, addressing the data, functional and behavioural domains from an implementation perspective. QUALITY GUIDELINES a design should satisfy: · exhibit an architecture created using recognisable architectural styles or patterns, composed of components with good design characteristics, implementable in an evolutionary fashion · be MODULAR — logically partitioned into elements or subsystems · contain distinct representations of data, architecture, interfaces and components · lead to data structures appropriate for the classes to be implemented, drawn from recognisable data patterns · lead to components exhibiting independent functional characteristics · lead to interfaces that reduce the complexity of connections between components and with the external environment · be derived using a REPEATABLE METHOD driven by information obtained during requirements analysis · be represented using a NOTATION that effectively communicates its meaning

WHY DESIGN EFFORT PAYS — with numbers. The relative cost of fixing a defect, by the phase in which it is FOUND (the classic Boehm curve, order-of-magnitude figures that every textbook quotes): found in requirements 1× found in design 5× found in coding 10× found in unit test 20× found in acceptance test 50× found after release 100× (up to 1000× for safety-critical) A DESIGN DECISION is not a defect, but a BAD design decision behaves like a defect found after release: it is discovered in production, and fixing it means changing the architecture. WORKED: the cost of getting the boundary wrong. Suppose a system is designed as one module where it should have been two, and this is discovered during maintenance. · the tangled module is 4,000 LOC · separating it requires understanding all of it, defining a new interface, and re-testing everything that calls it · at an industry-typical maintenance productivity of ~300 LOC/person-month for comprehension-heavy work, understanding alone is 4000/300 ≈ 13 person-months Had the boundary been drawn at design time, the same separation would have cost the time to draw one more box on a diagram. THIS IS THE WHOLE ARGUMENT FOR DESIGN. Not that design prevents bugs — it does, somewhat — but that design decisions made early are nearly free and the same decisions made late are nearly impossible. WHERE THE EFFORT GOES, typical distribution across a project: requirements ~15% design ~20% implementation ~20% testing ~30–40% (and maintenance, over the life of the system, exceeds all of the above combined — commonly quoted at 60–70% of total lifetime cost) READ THAT LAST LINE AGAIN. If most of the money is spent AFTER delivery, then the property design should optimise for is not "quick to build" but "cheap to change". Every design concept in the next topic — abstraction, modularity, information hiding — exists to serve that one economic fact.