The Design Phase Within the Software Development Life Cycle

UPI Study › Courses › System Analysis and Design › Free lessons › Lesson 4.9 Free with a free account

The Design Phase Within the Software Development Life Cycle

System Analysis and Design · Chapter 4: Requirements Validation, Modeling, and UMLSection 4.9 · lesson 32 of 699 min · free with a free account

← UML Structural Diagrams: Object Diagrams and Class Diagrams Compared and AppliedNext lesson: Universal Design: Seven Principles for Inclusive Software →

Earn 3 college credits for System Analysis and DesignRecommended for credit by NCCRS · Computer Science 390 · self-paced · one payment, lifetime access
Enroll in System Analysis and Design · $250 →Download the syllabus (PDF)

In this lesson

Objectives, logical vs. physical, high vs. low level, and what makes a design good.

  • Explain the objectives a design must achieve
  • Distinguish logical from physical, and high-level from low-level design
  • Apply modularity, coupling, and cohesion to evaluate a design
  • Describe the design specification and the design review

Transcript

Everything said in the video, section by section (1,183 words). Read along, or search it.

Requirements Validation, Modeling, and UML

The Design Phase

Back in chapter one, design was the third phase of the life cycle. This section looks inside it. We will cover what a design must achieve, two pairs of distinctions, logical versus physical, and high-level versus low-level. Then the principles that separate a good design from a bad one. And finally, the design specification, and the review that approves it.

What Design Must Achieve

6 Objectives at Once

Design takes the approved requirements, and turns them into a technical blueprint developers can build from. And a design is judged against several objectives at once, not just whether it works. Correctness. The design fully and accurately satisfies the approved requirements. Maintainability. Future changes can be made with minimal risk and effort. Efficiency. The system makes appropriate use of processing, memory, storage, and network resources. Reliability. The system behaves consistently, and fails predictably rather than catastrophically. Reusability. Components can be reused elsewhere in the system, or in future projects. And security. The design protects data and functionality from unauthorized use.

Trade-Offs

Objectives Pull Against Each Other

Here is the catch. These objectives can pull against each other. A highly secure design, for example, may add processing overhead that works against efficiency. You rarely get the maximum of every objective at once. So design is as much about making deliberate trade-offs, as it is about producing any single artifact. A good designer can explain which objective was favored, and why. And that explanation belongs in the design documents, so later maintainers understand the choice.

2 Distinctions (1 of 2)

Logical Design vs. Physical Design

The first distinction is between logical design and physical design. Logical design describes what the system will do, and how its data and processes are structured, independent of any technology. Physical design describes how that logical structure will actually be implemented. That means a specific database engine, specific tables and columns, a specific programming language, and specific hardware. Here is an example of the difference. Logically, an order has a status. Physically, orders dot status is a VARCHAR twenty column, in a PostgreSQL table. Logical design is typically produced early, close to analysis. Physical design comes later, close to construction. This mirrors the logical and physical data flow diagrams from earlier in the chapter.

2 Distinctions (2 of 2)

High-Level Design vs. Low-Level Design

The second distinction is between high-level design and low-level design. High-level design, sometimes called architectural design, describes the overall structure of the system. It covers the major components, and how they interact. Its audience is architects, senior developers, and stakeholders, and it produces architecture and component diagrams. Low-level design describes the detailed internal design of one individual component. Its classes, methods, algorithms, and data structures. Its audience is the developers implementing that component, and it produces class diagrams, pseudocode, and detailed specifications. A building is a useful analogy. High-level design is the floor plan, showing the rooms and how they connect. Low-level design is the detailed wiring diagram, for one of those rooms. You need the floor plan before the wiring makes sense. High-level design comes first.

Design Principles

Modularity, Coupling, and Cohesion

Now to what makes a design good. Three principles. Modularity is the practice of dividing a system into distinct, well-defined components, each responsible for a specific piece of functionality. Once a system is modular, two more principles decide how good that division actually is. Coupling is how dependent one module is on another module's internal details. You want it low, so modules can change independently. Cohesion is how closely related the responsibilities inside a single module are. You want it high, so each module has one clear job. Low coupling, high cohesion. That short phrase captures most of good modular design. Think of a module with high cohesion as having one clear job, which makes it easy to name, test, and replace.

Figure 4.5

Good and Bad Module Boundaries

Here are the two principles in a picture. On the left, modules A and B. Inside each module, the parts are densely connected to one another. That is high cohesion. And only a single, narrow link joins the two modules. That is low coupling. A change inside one module is unlikely to break the other. On the right, modules C and D. Inside each module, the parts share very little. That is low cohesion. And many connections cross between the two modules. That is high coupling. Here, a change to almost anything is likely to ripple across both modules. Count the teal lines crossing between modules. One on the left, four on the right. Each crossing line is a dependency someone must remember every time either module changes.

The Primary Deliverable

The Design Specification

The primary deliverable of the design phase is the design specification. It plays the same role for design that the S R S plays for requirements. A single, structured document developers can build from. The introduction covers purpose, scope, and how the document relates to the approved requirements. The architecture section, the high-level design, covers the major components, their responsibilities, and how they interact. The detailed design section, the low-level design, covers class or module specifications, algorithms, and data structures. Data design covers the database schema, and other physical data decisions. Interface design covers external and internal interfaces, such as A P Is and user interface layouts. A non-functional section explains how performance, security, and scalability requirements are addressed. And the appendices hold supporting diagrams, and a glossary. Notice how the sections echo this section's own ideas. High-level, low-level, data, and the non-functional objectives.

Design's Phase Gate

The Design Review

Before construction begins, the design specification goes through a design review. A design review is a formal evaluation, by peers, senior staff, or stakeholders. It is design's phase gate. It checks traceability. Does every requirement map to some identifiable part of the design? It checks adherence to design principles. Are there obvious modularity, coupling, or cohesion problems? It checks technical feasibility. Can the design actually be built, with the available technology and skills? It checks consistency. Do the different diagrams and documents agree with each other? And it checks completeness. Are all the required sections actually present? Like every phase gate in this course, it ends in one of three outcomes. The design is approved and construction proceeds, specific parts are sent back for rework, or the design is escalated for a larger decision.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. Logical design describes what the system does, independent of technology. Physical design describes how it is built on real technology. High-level design covers the overall architecture. Low-level design covers one component's internal detail. Coupling is how much one module depends on another's internal details, and it should be low. Cohesion is how well a module's responsibilities belong together, and it should be high. The design specification is the structured document developers build from. And the design review is the formal gate that approves the design, before construction begins.

Key Takeaways

What to Carry Forward

To pull this together. Design translates approved requirements into a technical blueprint. It balances correctness, maintainability, efficiency, reliability, reusability, and security, often through deliberate trade-offs. Logical design is technology-independent. Physical design is implemented on real technology. High-level design covers the overall architecture. Low-level design covers one component's internal detail. Modularity divides a system into components, and low coupling with high cohesion determines how well that division works. And the design specification is design's primary deliverable, approved by a design review before construction begins.

About System Analysis and Design at UPI Study

System Analysis and Design (Computer Science 390) is a self-paced online course of 69 video lessons in 9 chapters, from the analyst's role and requirements to UML modeling, interface and database design, testing, maintenance and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take System Analysis and Design with UPI Study

From business problem to working systemSystem Analysis and Design teaches how analysts study a business need and turn it into a system design: requirements, UML and data-flow models, interface and database design, implementation and project management. It is a core course in information systems and IT degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

System Analysis and Design carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Thomas Edison State UniversityThomas Edison State UniversitySigned partnerUniversity of the PeopleUniversity of the PeopleSigned partnerCharter Oak State CollegeCharter Oak State CollegeSigned partnerStrayer UniversityStrayer UniversitySigned partnerColumbia Southern UniversityColumbia Southern UniversitySigned partnerIndiana TechIndiana TechSigned partnerPenn StatePenn StateWorks with NCCRSSouthern New Hampshire UniversitySouthern New Hampshire UniversityWorks with NCCRSSUNYSUNYWorks with NCCRS +many more cooperating universitiesFind my college →

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About The Design Phase Within the Software Development Life Cycle

What objectives should a good software design achieve?
A good software design is judged against several objectives at once: correctness, maintainability, efficiency, reliability, reusability, and security. These objectives can pull against each other; for example, a highly secure design may add processing overhead that hurts efficiency. Design therefore involves deliberate trade-offs, and a good designer records which objective was favored and why so later maintainers understand the choice.
What is the difference between high-level design and low-level design?
High-level design, sometimes called architectural design, describes the overall structure of a system, its major components and how they interact, while low-level design describes the internal detail of one component, such as its classes, methods, algorithms, and data structures. High-level design produces architecture and component diagrams; low-level design produces class diagrams and pseudocode. Like a floor plan before room wiring, high-level design comes first.
Why should a design have low coupling and high cohesion?
A design should have low coupling and high cohesion so modules can change independently and each module has one clear job. Coupling measures how much one module depends on another module's internal details. Cohesion measures how closely related the responsibilities inside a single module are. With low coupling, a change inside one module is unlikely to ripple into others, and a highly cohesive module is easy to name, test, and replace.
What does a design review check before construction begins?
A design review is a formal evaluation of the design specification by peers, senior staff, or stakeholders that acts as the design phase's gate. It checks traceability of every requirement to the design, adherence to principles like coupling and cohesion, technical feasibility, consistency between diagrams and documents, and completeness of required sections. It ends with approval, rework of specific parts, or escalation for a larger decision.

About the System Analysis and Design course

How many college credits is System Analysis and Design?
System Analysis and Design (Computer Science 390) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does System Analysis and Design cost and what is included?
$250, paid once, with lifetime access: all 69 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does System Analysis and Design take?
It is self-paced with no deadlines. The 69 lessons total about 9 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in System Analysis and Design.

69 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Enroll in System Analysis and Design →Download the syllabusEvery course with PRO →
System Analysis and Design
3 credits · NCCRSEnroll →