1. Mục đích của giai đoạn thiết kế trong vòng đời phát triển phần mềm là tạo ra giải pháp cho một vấn đề được đưa ra trong tài liệu SRS(Software Requirement Specification). Đầu ra của giai đoạn thiết kế là SDD (Sofware Design Document).
2. Về cơ bản, thiết kế là một quá trình lặp lại gồm hai phần:
   • Phần đầu tiên là thiết kế ý tưởng cho khách hàng biết hệ thống sẽ làm gì.
   • Thứ hai là thiết kế kỹ thuật cho phép người xây dựng hệ thống hiểu được phần cứng và phần mềm thực tế cần thiết để giải quyết vấn đề của khách hàng.

Thiết kế khái niệm hệ thống:

• Viết bằng ngôn ngữ đơn giản tức là ngôn ngữ khách hàng dễ hiểu.
• Giải thích chi tiết về đặc điểm hệ thống.
• Mô tả chức năng của hệ thống.
• Độc lập thực hiện.
• Liên kết với tài liệu yêu cầu.

Thiết kế kỹ thuật hệ thống:

• Thành phần phần cứng và thiết kế.
• Chức năng và phân cấp của thành phần phần mềm.
• Kiến trúc phần mềm.
• Kiến trúc mạng.
• Cấu trúc dữ liệu và luồng dữ liệu.
• Thành phần I/O của hệ thống.
• Giao diện hiển thị.

Modularization

Đề cập đến quá trình phân chia một hệ thống phần mềm thành nhiều module độc lập trong đó mỗi module hoạt động độc lập. Ví dụ : Những nhân viên làm việc về bảng lương, hóa đơn, hồ sơ giấy tờ nên được tách riêng ra thành một bộ phận trong công ty. Tương tự đối với những nhân viên làm việc liên quan tới coding website, android/iOS app thì cũng nên tách ra thành một bộ phận riêng.
Có nhiều lợi thế của Modularization trong công nghệ phần mềm. Một số trong số này được đưa ra dưới đây:

• Dễ hiểu hệ thống.
• Bảo trì hệ thống dễ dàng.
• Một module có thể được sử dụng nhiều lần theo yêu cầu của họ. Không cần phải viết đi viết lại.

Coupling

Đề cập đến mức độ liên quan hoặc phụ thuộc của các class/module đối với nhau. Ví dụ : kế toán viên nên làm việc ở bộ phận kế toán. Web developer nên làm việc ở bộ phận CNTT. 2 bộ phận nên tách rời nhau, không phải xung đột hay phụ thuộc nhau trong quá trình làm việc.

• Đối với High Coupling sẽ gây khó khăn cho việc thay đổi và duy trì code của bạn, vì các class/module được liên kết chặt chẽ với nhau, nên việc thay đổi có thể yêu cầu viết lại toàn bộ hệ thống.
• Đối với Low Coupling, việc thay đổi thứ gì đó trong một class/module sẽ không ảnh hưởng đến class/module kia. (Dependency Inversion Principle : xem chữ D trong SOLID)

Cohesion

Đề cập đến những class/module có thể làm những chức năng nhiệm vụ gì. Ví dụ : bộ phận kế toán nên làm việc liên quan tới bảng lương, hóa đơn, hồ sơ,... bộ phận kết toán không nên tự ý sửa đổi sourcode của bộ phận phát triển web. Tương tự bộ phận CNTT không nên tự ý sửa đổi tăng lương lên x2.

• Low Cohesion là class/module thực hiện rất nhiều hành động - phạm vi hoạt động rộng và dàn trãi không rõ ràng và chuyên biệt, không tập trung vào những gì nó nên làm (God Object).
• High Cohesion là class/module tập trung vào những gì nó nên làm, tức là chỉ các phương thức liên quan đến ý định của Class (Single Repository Principle : xem chữ S trong SOLID).