HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG

VIỆN KINH TẾ BƯU ĐIỆN

-----🙞🙜🕮🙞🙜-----

IMFORMATION SYSTEM ANALYSIS & DESIGN

BÀI TẬP 1
NHÓM MÔN HỌC: 02

Giảng viên : Trần Đình Quế

Sinh viên : Vũ Thị Yến
Mã số sinh viên : B20DCCN754
Nhóm bài tập lớn : 15
Lớp : D20CNPM05
BÀI TẬP 1:
1. Trình bày ngắn gọn (>2 trang) 4 pha trong framework phát triển yêu cầu phần mềm.

Phát triển yêu cầu là một quá trình lặp đi lặp lại.
a. Thu thập yêu cầu (Requirements Elicitation)
- Xác định tầm nhìn và phạm vi dự án: làm rõ yêu cầu kinh doanh của sản
phẩm thông qua tài liệu tầm nhìn và phạm vi. Tầm nìn mô tả kết quả sản phẩm,
phạm vi xác định ranh giới cho từng phiên bản hoặc vòng lặp vụ thể
- Xác định lớp người dùng và đặc điểm của họ: Để không bỏ sót nhu cầu của
bất kỳ người dùng nào, chúng ta phải xác định các nhóm người dùng khác nhau cho
sản phẩm và mô tả đặc điểm của họ.
- Chọn người biểu trưng cho từng lớp người dùng: Xác định người đại diện có
thể đại diện cho từng lớp người dùng và thể hiện nhu cầu của họ.
- Tổ chức cuộc họp tập trung với người dùng điển hình: Tổ chức các cuộc họp
với người dùng trước đó hoặc các sản phẩm tương tự để thu thập ý kiến về chức
năng và chất lượng sản phẩm.
- Làm việc cùng với đại diện người dùng để xác định yêu cầu người dùng:
Thảo luận với đại diện người dùng về nhiệm vụ họ cần hoàn thành và giá trị mà họ
muốn đạt được.
- Xác định sự kiện và phản hồi của hệ thống: Liệt kê các sự kiện bên ngoài mà
hệ thống có thể trải qua và phản hồi mong đợi cho mỗi sự kiện.
- Thực hiện cuộc phỏng vấn để thu thập yêu cầu: Cuộc phỏng vấn có thể thực
hiện một cách cá nhân hoặc nhóm nhỏ để thu thập yêu cầu cụ thể từ các bên liên
quan.
- Tổ chức các cuộc họp tập trung để thu thập yêu cầu: Cuộc họp tập trung dẫn
dắt cho phép sự hợp tác giữa các nhà phân tích và khách hàng để tạo điều kiện để
khám phá nhu cầu của người dùng và lập tài liệu yêu cầu.
- Quan sát người dùng thực hiện công việc của họ: Theo dõi người dùng thực
hiện nhiệm vụ kinh doanh của họ để thiết lập ngữ cảnh cho việc sử dụng sản phẩm.
- Phân phát các bảng câu hỏi: Sử dụng bảng câu hỏi để khảo sát các nhóm
người dùng lớn để xác định nhu cầu của họ.
- Thực hiện phân tích tài liệu hiện tại: Xem xét tài liệu hiện tại để hiểu cách hệ
thống hoạt động hoặc những gì nó nên làm.
 - Kiểm tra các báo cáo vấn đề của các hệ thống hiện tại để tìm ý tưởng yêu
cầu: Sử dụng báo cáo vấn đề và yêu cầu cải tiến từ người dùng để xác định tính năng
để bao gồm trong sản phẩm mới.
- Tái sử dụng yêu cầu hiện có: Xem xét khả năng tái sử dụng các yêu cầu đã
có nếu chức năng tương tự được yêu cầu.
b. Phân tích yêu cầu (Requirements Analysis)
Phân tích yêu cầu đòi hỏi việc làm rõ yêu cầu để đảm bảo tất cả các bên liên quan
hiểu rõ chúng và kiểm tra chúng để tìm kiếm lỗi, thiếu sót và các vấn đề khác. Phân
tích bao gồm việc phân rã các yêu cầu cấp cao thành các cấp độ chi tiết thích hợp,
xây dựng mẫu thử nghiệm, đánh giá khả thi, và thương lượng về ưu tiên. Mục tiêu
là phát triển các yêu cầu đủ chất lượng và chính xác để quản lý có thể xây dựng các
ước tính dự án thực tế và nhân viên kỹ thuật có thể tiến hành thiết kế, xây dựng và
kiểm thử. Việc biểu diễn một số yêu cầu dưới nhiều hình thức khác nhau rất quan
trọng - ví dụ, cả trong hình thức văn bản và hình thức hình ảnh hoặc trong hình thức
yêu cầu và kiểm thử. Những cách biểu diễn khác nhau này sẽ tiết lộ thông tin và vấn
đề mà không một cách biểu diễn đơn lẻ nào có thể cung cấp.
- Mô hình môi trường ứng dụng: Context diagram là một mô hình phân tích
đơn giản thể hiện cách hệ thống mới phù hợp với môi trường của nó. Nó xác định
ranh giới và giao diện giữa hệ thống đang được phát triển và các thực thể bên ngoài
như người dùng, thiết bị phần cứng và các hệ thống khác. Một bản đồ hệ sinh thái
hiển thị các hệ thống khác nhau trong không gian giải pháp tương tác với nhau và
tính chất của các kết nối của chúng.
- Tạo giao diện người dùng và mẫu thử nghiệm kỹ thuật: Khi nhà phát triển
hoặc người dùng không chắc chắn về yêu cầu, họ sẽ xây dựng một mẫu thử nghiệm
để làm cho các khái niệm và khả năng trở nên cụ thể hơn. Mẫu thử nghiệm cho phép
nhà phát triển và người dùng đạt được sự hiểu biết chung về vấn đề đang được giải
quyết, cũng như giúp xác thực yêu cầu.
- Phân tích khả thi về yêu cầu: BA nên làm việc cùng với nhà phát triển để
đánh giá khả năng thực hiện mỗi yêu cầu với chi phí và hiệu suất chấp nhận được
trong môi trường hoạt động dự định. Điều này cho phép các bên liên quan hiểu về
các rủi ro liên quan đến việc thực hiện mỗi yêu cầu.
- Ưu tiên các yêu cầu: Quá trình ưu tiên yêu cầu rất quan trọng để đảm bảo
nhóm triển khai các chức năng có giá trị cao nhất hoặc cần thiết nhất trước hết. Áp
dụng một phương pháp phân tích để xác định sự ưu tiên tương đối trong việc triển
khai các tính năng sản phẩm, các trường hợp sử dụng, câu chuyện người dùng hoặc
yêu cầu chức năng. Dựa trên mức độ ưu tiên, xác định phiên bản hoặc giai đoạn nào
sẽ chứa mỗi tính năng hoặc tập hợp yêu cầu.
- Tạo từ điển dữ liệu: Định nghĩa các mục dữ liệu và cấu trúc liên quan đến hệ
thống nằm trong từ điển dữ liệu. Điều này cho phép tất cả mọi người làm việc trên
dự án sử dụng các định nghĩa dữ liệu nhất quán. Khi yêu cầu được phát triển, từ điển
dữ liệu nên xác định các mục dữ liệu từ lĩnh vực vấn đề để tạo điều kiện cho việc
giao tiếp giữa khách hàng và nhóm phát triển.
- Mô hình hóa yêu cầu: Một mô hình phân tích là một biểu đồ thể hiện yêu cầu
một cách hình ảnh, trái ngược với biểu diễn văn bản của danh sách yêu cầu chức
năng. Các mô hình có thể tiết lộ yêu cầu sai, không nhất quán, thiếu sót và thừa thải.
- Phân tích giao diện giữa hệ thống của bạn và thế giới bên ngoài: Tất cả các
hệ thống phần mềm đều có kết nối với các phần khác trong thế giới bên ngoài thông
qua giao diện bên ngoài. Hệ thống thông tin có giao diện người dùng và thường trao
đổi dữ liệu với các hệ thống phần mềm khác. Hệ thống nhúng liên quan đến sự kết
nối giữa phần mềm và các thành phần phần cứng. Ứng dụng kết nối mạng có giao
diện truyền thông.
- Phân bổ yêu cầu cho các hệ thống con: Các yêu cầu cho một sản phẩm phức
tạp chứa nhiều hệ thống con phải được chia phần cho các hệ thống con và các thành
phần phần mềm, phần cứng và con người. Một ví dụ về sản phẩm như vậy là hệ
thống truy cập vào một tòa nhà an ninh bảo mật bao gồm các thẻ từ từ tích hợp, máy
quét, máy quay video và máy ghi âm, khóa cửa và người bảo vệ.
c. Xác định yêu cầu (Requirements Specification)
Yêu cầu chi tiết về chức năng và không chức năng của phần mềm được ghi lại trong
một tài liệu yêu cầu phần mềm (SRS) hoặc một kho lưu trữ thay thế, như một công
cụ quản lý yêu cầu.
- Sử dụng mẫu tài liệu yêu cầu: Sử dụng các mẫu tiêu chuẩn cho việc ghi chép
yêu cầu trong tổ chức của bạn để đảm bảo cấu trúc đồng nhất cho việc ghi chép các
thông tin liên quan đến yêu cầu.
- Xác định nguồn gốc của yêu cầu: Theo dõi mỗi yêu cầu để biết tại sao mỗi
yêu cầu đó cần thiết. Điều này có thể là từ một trường hợp sử dụng hoặc phản hồi
từ khách hàng, một yêu cầu hệ thống cấp cao hoặc một quy tắc kinh doanh. Xác
định nguồn gốc của yêu cầu giúp khi cần thay đổi.
- Gán nhãn định danh duy nhất cho mỗi yêu cầu: Định nghĩa một quy ước để
gán cho mỗi yêu cầu một nhãn định danh duy nhất. Điều này giúp theo dõi yêu cầu
và ghi chép các thay đổi.
- Ghi chép các quy tắc kinh doanh: Quy tắc kinh doanh bao gồm các chính
sách doanh nghiệp, quy định của chính phủ, tiêu chuẩn và thuật toán tính toán. Hãy
tài liệu riêng về các quy tắc kinh doanh bởi vì chúng thường tồn tại ngoài phạm vi
của một dự án cụ thể. Một số quy tắc sẽ dẫn đến các yêu cầu chức năng để thực thi
chúng, vì vậy xác định các liên kết theo dõi giữa các yêu cầu và các quy tắc tương
ứng.
- Xác định yêu cầu không chức năng: Để tránh triển khai một giải pháp chỉ
đúng công việc của nó mà không đáp ứng kỳ vọng về chất lượng của người dùng,
bạn cần đánh giá các đặc điểm chất lượng quan trọng. Điều này bao gồm hiệu suất,
 độ tin cậy, tính sử dụng, khả năng sửa đổi và nhiều yếu tố khác. Việc chỉ định các
yêu cầu không chức năng là quan trọng để đảm bảo sự thành công của sản. phẩm.
d. Xác minh yêu cầu (Requirements Validation)
Xác thực đảm bảo rằng các yêu cầu là chính xác, thể hiện các đặc điểm chất lượng
mong muốn và sẽ đáp ứng nhu cầu của khách hàng. Bạn cần phải sửa những vấn đề
này nếu muốn các yêu cầu đóng vai trò là một nền tảng đáng tin cậy cho thiết kế,
kiểm tra hệ thống cuối cùng và kiểm tra chấp nhận của người dùng.
- Xem xét yêu cầu: Xem xét yêu cầu là một bước quan trọng để tìm ra các lỗi
và không rõ ràng. Việc này có thể bao gồm kiểm tra yêu cầu bằng cách sử dụng
kiểm tra đồng nghiệp hoặc kiểm tra cẩn thận hơn được gọi là "inspection". Đội ngũ
kiểm tra nên đại diện cho các góc độ khác nhau như nhà phân tích, khách hàng, nhà
phát triển và người kiểm thử.
- Kiểm tra yêu cầu: Tạo các bài kiểm tra dựa trên yêu cầu người dùng để xác
định cách kiểm tra tính đúng đắn của chức năng được triển khai. Duyệt qua các bài
kiểm tra với khách hàng để đảm bảo rằng chúng phản ánh mong đợi của người dùng.
- Xác định tiêu chí chấp nhận: Hỏi người dùng cách họ sẽ xác định xem giải
pháp có đáp ứng nhu cầu của họ và có phù hợp để sử dụng hay không. Tiêu chí chấp
nhận bao gồm các bài kiểm tra chấp nhận dựa trên yêu cầu của người dùng và các
yêu cầu không chức năng cụ thể khác.
- Mô phỏng yêu cầu: Sử dụng công cụ mô phỏng để tạo ra một hệ thống mô
phỏng của giải pháp dự kiến. Mô phỏng cho phép người dùng tương tác với hệ thống
giả lập để xác minh yêu cầu và đưa ra các lựa chọn thiết kế.
Những bước trên đảm bảo rằng yêu cầu được kiểm tra và chắc chắn sẽ dẫn đến một
sản phẩm cuối cùng phù hợp với nhu cầu của khách hàng và đáp ứng chất lượng
mong muốn.
2. Giải thích Figure 4.1 (>1 trang).
 Business analyst là một vai trò trong dự án, không nhất thiết là một chức
danh công việc. Từ đồng nghĩa cho business analyst bao gồm requirements analyst,
systems analyst, requirements engineer, requirements manager, application analyst,
business systems analyst, IT business analyst, và chỉ đơn giản là analyst.

 Project Sponsor (Nhà Tài trợ Dự án): Đây là người hoặc tổ chức
chịu trách nhiệm chủ đạo về dự án và cung cấp tài chính hoặc hỗ trợ cho dự án. Họ
có vai trò quan trọng trong việc xác định mục tiêu và phạm vi của dự án, đồng thời
họ cũng có thể đóng một vai trò quan trọng trong việc xác định yêu cầu và ủng hộ
chung cho dự án.
 Project Management (Quản lý Dự án): Đây là các nhà quản lý dự
án, bao gồm Project Manager (Quản lý Dự án) và các thành viên của nhóm quản lý
dự án. Họ có nhiệm vụ quản lý và điều hành dự án, đảm bảo rằng nó được thực hiện
theo kế hoạch và đạt được mục tiêu dự án.
 Development (Phát triển): Đây là phần của dự án liên quan đến việc
phát triển phần mềm hoặc sản phẩm. Các nhà phát triển và kỹ sư phần mềm tham
gia vào giai đoạn này để xây dựng và triển khai các giải pháp dự án.
 Users Representatives (Đại diện của Người dùng): Đây là những
người đại diện cho người dùng cuối, tức là những người sẽ sử dụng sản phẩm hoặc
phần mềm cuối cùng. Họ giúp xác định và đưa ra yêu cầu từ góc nhìn của người
dùng, đảm bảo rằng sản phẩm đáp ứng nhu cầu của họ.
 Other Stakeholders (Các Bên Liên Quan Khác): Đây là những bên
liên quan khác đối với dự án, bao gồm các bên có quyền quyết định, đối tác liên
quan, hoặc những người ảnh hưởng đến dự án một cách trực tiếp hoặc gián tiếp.
Việc liên lạc và hợp tác với các bên liên quan này là quan trọng để đảm bảo sự thành
công của dự án.
 Testing (Kiểm tra): Phần này bao gồm các nhà kiểm tra (Testers) và
quá trình kiểm tra sản phẩm hoặc phần mềm để đảm bảo tính đúng đắn và hiệu suất
của nó. Kiểm tra thường diễn ra trong quá trình phát triển và trước khi sản phẩm
được triển khai để đảm bảo rằng không có lỗi nghiêm trọng và rằng nó đáp ứng yêu
cầu của người dùng cuối.

Hình này biểu thị mối quan hệ và tương tác giữa các vai trò và phần tử quan trọng trong
một dự án phát triển phần mềm hoặc sản phẩm. Business Analyst đóng vai trò trung
tâm trong việc tương tác với các bên liên quan và đảm bảo rằng yêu cầu của người dùng
được hiểu rõ và triển khai một cách chính xác trong quá trình phát triển.
3. Công việc của người làm BA: Knowledge & Skills? Để trở thành BA?
a. Công việc của người làm BA: Knowledge & Skills
Nhà phân tích trước tiên phải hiểu mục tiêu kinh doanh của dự án và sau đó
xác định người dùng, các yêu cầu về chức năng và chất lượng cho phép các nhóm
ước tính và lập kế hoạch cho dự án cũng như thiết kế, xây dựng và kiểm tra sản
phẩm. BA còn là người lãnh đạo và là người giao tiếp, biến những điều khách hàng
còn mơ hồ thành các thông số kỹ thuật rõ ràng nhằm hướng dẫn công việc của nhóm
phần mềm.
 Xác định các yêu cầu kinh doanh: Người BA xác định các yêu cầu kinh doanh
của dự án và có thể đề xuất mẫu cho tài liệu tổng quan và làm việc với những người
có tầm nhìn để giúp họ thể hiện nó một cách rõ ràng.
 Lập kế hoạch tiếp cận: yêu cầu Nhà phân tích nên phát triển các kế hoạch để
suy ra, phân tích, ghi lại, xác nhận và quản lý các yêu cầu trong suốt dự án. Làm
việc chặt chẽ với người quản lý dự án để đảm bảo các kế hoạch này phù hợp với kế
hoạch tổng thể của dự án và sẽ giúp đạt được các mục tiêu của dự án.
 Xác định các bên liên quan của dự án và các lớp người dùng, làm việc với
các nhà tài trợ kinh doanh để lựa chọn đại diện phù hợp cho từng loại người dùng,
tranh thủ sự tham gia của họ và thương lượng trách nhiệm của họ. Giải thích những
gì mong muốn từ cộng tác viên của khách hàng và thống nhất về mức độ tham gia
phù hợp của mỗi người.
 Gợi ý các yêu cầu: Một nhà phân tích chủ động giúp người dùng trình bày rõ
ràng các khả năng của hệ thống mà họ cần để đáp ứng các mục tiêu kinh doanh của
họ bằng cách sử dụng nhiều kỹ thuật thu thập thông tin.
 Phân tích yêu cầu: Tìm kiếm các yêu cầu phái sinh là hệ quả logic của những
gì khách hàng yêu cầu và những yêu cầu tiềm ẩn mà khách hàng dường như mong
đợi mà chưa được nói ra. Sử dụng các mô hình yêu cầu để nhận ra các mẫu, xác
định các lỗ hổng trong các yêu cầu, phát hiện các yêu cầu xung đột và xác nhận rằng
tất cả các yêu cầu được chỉ định đều nằm trong phạm vi. Làm việc với các bên liên
quan để xác định mức độ chi tiết cần thiết để xác định người dùng và chức năng yêu
cầu.
 Yêu cầu về tài liệu: Nhà phân tích có trách nhiệm ghi lại các yêu cầu một
cách logic chặt chẽ, mô tả rõ ràng giải pháp sẽ giải quyết các vấn đề của khách hàng.
 Truyền đạt các yêu cầu: BA phải truyền đạt các yêu cầu một cách hiệu quả
và hiệu quả cho tất cả các bên. BA nên xác định khi nào việc thể hiện các yêu cầu
bằng cách sử dụng các phương pháp là hữu ích ngoài văn bản, bao gồm nhiều loại
mô hình phân tích trực quan khác nhau. Giao tiếp không chỉ đơn giản là việc đưa ra
những yêu cầu, nó liên quan đến sự hợp tác liên tục với nhóm để đảm bảo rằng họ
hiểu được thông tin được truyền đạt.
 Xác thực các yêu cầu: chính BA phải đảm bảo rằng các tuyên bố yêu cầu có
những đặc điểm mong muốn và rằng một giải pháp dựa trên các yêu cầu sẽ đáp ứng
được nhu cầu của các bên liên quan. Các nhà phân tích là người tham gia chính để
đánh giá các yêu cầu. BA cũng nên xem lại các thiết kế và thử nghiệm được rút ra
từ các yêu cầu để đảm bảo rằng các yêu cầu được giải thích một cách chính xác.
 Tạo điều kiện thuận lợi cho các yêu cầu ưu tiên: Sự hợp tác và đàm phán
giữa các nhà môi giới phân tích các bên liên quan khác nhau và các nhà phát triển
để đảm bảo rằng họ đưa ra các quyết định ưu tiên hợp lý và phù hợp với việc đạt
được mục tiêu kinh doanh.
 Quản lý yêu cầu: Một nhà phân tích kinh doanh tham gia vào toàn bộ quá
trình phát triển phần mềm, vì vậy BA nên giúp tạo, xem xét và thực hiện quản lý
yêu cầu của kế hoạch dự án. Sau khi thiết lập cơ sở yêu cầu cho một lần phát hành
hoặc lặp lại quá trình phát triển sản phẩm nhất định, trọng tâm của BA chuyển sang
theo dõi trạng thái của các yêu cầu đó, xác minh sự hài lòng của khách hàng trong
sản phẩm và quản lý các thay đổi đối với yêu cầu.
Skills
Công việc bao gồm nhiều “kỹ năng mềm” hướng tới con người hơn là kỹ
thuật. Nhà phân tích cần biết cách sử dụng nhiều kỹ thuật gợi ý khác nhau và cách
trình bày thông tin dưới các hình thức khác nhau. Một BA làm việc hiệu quả khi kết
hợp khả năng giao tiếp, những điều kiện thuận lợi và kiến thức về lĩnh vực kỹ thuật
và kinh doanh cũng như tính cách phù hợp với công việc. Sự kiên nhẫn và mong
muốn thực sự được làm việc với mọi người là những yếu tố thành công then chốt.
 Kỹ năng nghe: Để thành thạo giao tiếp hai chiều, hãy học cách lắng nghe
hiệu quả. Lắng nghe tích cực bao gồm việc loại bỏ sự xao lãng, duy trì tư thế chăm
chú và giao tiếp bằng mắt, và trình bày lại những điểm chính để xác nhận sự hiểu
biết về vấn đề. BA cần nắm bắt những gì mọi người đang nói và cũng để có thể phát
hiện những gì họ còn do dự khi nói. Tìm hiểu tính cách của khách hàng và tránh áp
đặt suy nghĩ cá nhân lên những gì nghe được.
 Kỹ năng phỏng vấn và đặt câu hỏi: Hầu hết các yêu cầu đầu vào đều được
đưa ra thông qua thảo luận, vì vậy BA phải có khả năng tương tác với các cá nhân
và nhóm khác nhau về nhu cầu của họ. Nó có thể không thoải mái khi làm việc với
các nhà quản lý cấp cao và với những cá nhân có thái độ cố chấp hoặc hung hăng.
BA cần đặt những câu hỏi phù hợp để tìm ra thông tin yêu cầu thiết yếu.
Với kinh nghiệm, bạn sẽ trở nên thành thạo trong nghệ thuật đặt câu hỏi tiết lộ và
làm rõ những điều không chắc chắn, những bất đồng, giả định và những kỳ vọng
không được nói ra (Gause và Weinberg 1989).
 Suy nghĩ đa phương diện: Các nhà phân tích kinh doanh luôn cần phải nhận
thức được các thông tin hiện có và để xử lý thông tin mới chống lại nó. Họ cần phát
hiện ra những mâu thuẫn, sự không chắc chắn, mơ hồ và giả định để họ có thể thảo
luận chúng vào thời điểm thích hợp. BA có thể viết kịch bản bộ câu hỏi phỏng vấn;
tuy nhiên, sẽ luôn cần hỏi những điều mà nhà phân tích kinh doanh không thể đoán
trước được. BA cần soạn thảo những câu hỏi hay, lắng nghe rõ ràng câu trả lời và
nhanh chóng đưa ra câu tiếp theo.
  Kỹ năng phân tích: Một nhà phân tích kinh doanh hiệu quả có thể suy nghĩ ở
cả mức độ trừu tượng cao và thấp và biết khi nào nên di chuyển từ nơi này sang nơi
khác. Đôi khi, phải đi sâu vào từ cấp độ cao và chi tiết. Trong các tình huống khác,
BA sẽ cần khái quát hóa từ một nhu cầu cụ thể từ một người dùng được mô tả theo
một tập hợp các yêu cầu để đáp ứng được nhiều bên liên quan. BA cần phải hiểu
thông tin phức tạp đến từ nhiều nguồn và giải quyết các vấn đề khó khăn liên quan
đến từ thông tin đó. Họ cần đánh giá nghiêm túc thông tin để dung hòa xung đột,
tách biệt người dùng “mong muốn” với nhu cầu thực sự cơ bản và phân biệt ý tưởng
giải pháp với yêu cầu.
 Kỹ năng tư duy hệ thống: Mặc dù một nhà phân tích kinh doanh phải có định
hướng chi tiết, nhưng cũng phải nhìn thấy tổng quan bức tranh lớn. BA phải kiểm
tra các yêu cầu dựa trên những hiểu biết về toàn bộ doanh nghiệp, môi trường kinh
doanh và ứng dụng để tìm kiếm sự không nhất quán và tác động. BA cần phải hiểu
sự tương tác và mối quan hệ giữa con người, quy trình và công nghệ liên quan. Nếu
khách hàng yêu cầu một yêu cầu về khu vực chức năng của mình, BA cần đánh giá
liệu yêu cầu có ảnh hưởng đến các phần khác của hệ thống theo những cách không
rõ ràng hay không.
 Kỹ năng học tập: Các nhà phân tích phải học tập và cập nhật kiến thức mới
một cách nhanh chóng, cho dù đó là về các yêu cầu mới, phương pháp tiếp cận hoặc
miền ứng dụng. Họ cần có khả năng áp dụng kiến thức đó vào thực tế một cách hiệu
quả. Các nhà phân tích phải là những độc giả hiệu quả và có óc phê phán vì họ phải
trải qua rất nhiều tình huống và phải nắm bắt được bản chất một cách nhanh chóng.
Nếu không phải là chuyên gia trong lĩnh vực đó, đừng ngần ngại đặt câu hỏi làm rõ.
Hãy trung thực về những gì không biết. Không sao cả khi không biết, nhưng không
thể che giấu sự thiếu hiểu biết của mình.
 Kỹ năng điều phối: Khả năng tạo điều kiện cho các cuộc thảo luận về yêu
cầu và hội thảo khơi gợi là một khả năng phân tích quan trọng. Tạo điều kiện là
hành động dẫn dắt một nhóm hướng tới thành công. Tạo thuận lợi là cần thiết khi
hợp tác xác định các yêu cầu, ưu tiên các nhu cầu và giải quyết xung đột. Một người
điều phối trung lập có kỹ năng đặt câu hỏi, quan sát và điều phối giỏi có thể giúp
nhóm xây dựng niềm tin và cải thiện mối quan hệ đôi khi căng thẳng giữa doanh
nghiệp và nhân viên CNTT.
 Kỹ năng lãnh đạo: Một nhà phân tích giỏi có thể tác động đến một nhóm các
bên liên quan để họ đi theo một hướng nhất định, thực hiện mục tiêu chung. Lãnh
đạo đòi hỏi phải hiểu biết nhiều kỹ thuật khác nhau để đàm phán, thỏa thuận giữa
các bên liên quan của dự án, giải quyết xung đột và đưa ra quyết định. Nhà phân
tích nên tạo ra một môi trường hợp tác, nuôi dưỡng niềm tin giữa các nhóm bên liên
quan khác nhau, gồm những người có thể không hiểu động cơ, nhu cầu và ràng buộc
của nhau.
  Kỹ năng quan sát: Một nhà phân tích có óc quan sát sẽ phát hiện những nhận
xét được đưa ra thoáng qua có thể khiến vấn đề trở nên đáng kể. Bằng cách quan sát
BA thực hiện công việc của mình, một người quan sát giỏi có thể phát hiện ra những
điều tinh tế mà người khác có thể không nghĩ tới. Kỹ năng quan sát mạnh mẽ đôi
khi đưa ra các vấn đề mới để thảo luận khơi gợi, từ đó bộc lộ các yêu cầu bổ sung.
 Kỹ năng giao tiếp: Sản phẩm chính có thể chuyển giao từ quá trình phát triển
yêu cầu là một tập hợp các yêu cầu bằng văn bản để truyền đạt thông tin một cách
hiệu quả giữa các khách hàng, tiếp thị, quản lý, nhân viên kỹ thuật. Nhà phân tích
cần có trình độ ngôn ngữ vững chắc và khả năng để diễn đạt những ý tưởng phức
tạp một cách rõ ràng, cả bằng văn bản và bằng lời nói. Bạn phải có khả năng viết
cho nhiều đối tượng, bao gồm cả những khách hàng phải xác thực các yêu cầu và
những nhà phát triển cần có yêu cầu rõ ràng, chính xác để thực hiện. BA cần ăn nói
rõ ràng, thích nghi với các thuật ngữ và sự khác biệt trong phương ngữ.
 Kỹ năng tổ chức thiết lập kiến trúc thông tin: Ngoài ra, BA phải có khả năng
tóm tắt và trình bày thông tin ở mức độ chi tiết mà đối tượng mục tiêu cần. Các BA
phải đối mặt với một lượng lớn thông tin lộn xộn được thu thập trong quá trình suy
diễn và phân tích. Đối phó với thông tin thay đổi nhanh chóng và cấu trúc tất cả
thành một tổng thể mạch lạc đòi hỏi những kỹ năng tổ chức đặc biệt cũng như sự
kiên nhẫn và bền bỉ. Là một nhà phân tích, BA cần có kỹ năng tổ chức thiết lập kiến
trúc thông tin để hỗ trợ thông tin dự án khi nó phát triển trong suốt dự án (Beatty và
Chen 2012).
 Kỹ năng lập mô hình: Các mô hình bao gồm từ biểu đồ luồng công việc
truyền thống cho đến các mô hình phân tích có cấu trúc (đồ thị luồng dữ liệu, đồ thị
quan hệ thực thể và các biểu đồ tương tự). sang Ngôn ngữ mô hình hóa thống nhất
(UML) phải là một phần trong vốn liếng của mỗi nhà phân tích (Beatty và Chen
2012). BA sẽ cần biết khi nào nên chọn các mô hình cụ thể dựa trên cách chúng tăng
thêm giá trị. Ngoài ra, BA cần hướng dẫn các bên liên quan khác về giá trị của việc
sử dụng các mô hình này và cách đọc chúng.
 Kỹ năng giao tiếp và tương tác cá nhân: Người phân tích phải có khả năng
đưa những người có lợi ích cạnh tranh làm việc cùng nhau như một đội. Một người
phân tích nên cảm thấy thoải mái khi nói chuyện với những người thuộc các chức
năng công việc khác nhau và ở mọi cấp bậc trong tổ chức. Một người phân tích nên
sử dụng ngôn ngữ phù hợp với đối tượng người nghe, không sử dụng thuật ngữ kỹ
thuật với các bên liên quan kinh doanh. Cô ấy có thể cần làm việc với các nhóm ảo
có thành viên phân tán về địa lý, múi giờ, văn hóa hoặc ngôn ngữ bản địa. Một người
phân tích nên dễ giao tiếp và rõ ràng và nhất quán trong việc giao tiếp với các thành
viên trong đội.
 Khả năng sáng tạo: BA không chỉ đơn thuần là người ghi chép những gì
khách hàng nói. Các nhà phân tích giỏi nhất phát hiện ra các yêu cầu tiềm năng của
khách hàng. Họ nghĩ ra sự đổi mới của sản phẩm, tưởng tượng ra các thị trường và
cơ hội kinh doanh mới và nghĩ ra cách để gây bất ngờ và làm hài lòng khách hàng
của họ. Một BA thực sự có giá trị sẽ tìm ra những cách sáng tạo để đáp ứng những
nhu cầu mà người khác không làm được. Tuy nhiên, các nhà phân tích phải cẩn thận
để tránh giải pháp mạ vàng; đừng chỉ thêm các yêu cầu mới vào đặc tả mà không
cần sự chấp thuận của khách hàng.
Kiến thức phân tích cần thiết: Knowledge
Ngoài những khả năng cụ thể và đặc điểm cá nhân, người phân tích kinh
doanh cần có kiến thức đa dạng, một phần lớn được đạt được thông qua kinh nghiệm.
Họ cần hiểu về các phương pháp kỹ thuật yêu cầu hiện đại và cách áp dụng chúng
trong ngữ cảnh của các vòng đời phát triển phần mềm khác nhau. Họ có thể cần giáo
dục và thuyết phục những người không quen thuộc với các phương pháp yêu cầu đã
được thiết lập.
Người phân tích hiệu quả có một bộ công cụ phong phú các kỹ thuật và biết
khi nào - và khi không - sử dụng mỗi kỹ thuật. Người phân tích kinh doanh cần liên
kết các hoạt động phát triển và quản lý yêu cầu trong suốt quá trình dự án. Một
người phân tích hiểu biết về quản lý dự án, vòng đời phát triển, quản lý rủi ro và kỹ
thuật chất lượng có thể giúp ngăn chặn các vấn đề liên quan đến yêu cầu làm đổ dự
án. Trong một môi trường phát triển thương mại, người phân tích sẽ có lợi từ kiến
thức về các khái niệm quản lý sản phẩm. Người phân tích có lợi từ một mức độ kiến
thức cơ bản về kiến trúc và môi trường hoạt động, để có thể tham gia vào các cuộc
trò chuyện kỹ thuật về ưu tiên và yêu cầu phi chức năng.
Kiến thức về doanh nghiệp, ngành công nghiệp và tổ chức là tài sản mạnh
mẽ cho một người phân tích kinh doanh hiệu quả. Người phân tích có hiểu biết về
kinh doanh có thể giảm thiểu các sự không hiểu với người dùng. Những người phân
tích hiểu về tổ chức và lĩnh vực kinh doanh thường phát hiện ra các giả định chưa
được nêu rõ và yêu cầu ngầm. Họ có thể đề xuất các cách người dùng có thể cải
thiện quy trình kinh doanh hoặc đề xuất các chức năng có giá trị mà không có bất
kỳ bên liên quan nào nghĩ tới. Hiểu biết về lĩnh vực ngành công nghiệp có thể hữu
ích đặc biệt trong một môi trường thương mại để người phân tích có thể cung cấp
phân tích thị trường và sản phẩm cạnh tranh
b. Để trở thành BA?
Những người phân tích kinh doanh xuất sắc được phát triển từ các nền tảng
giáo dục và kinh nghiệm làm việc đa dạng, do đó họ có thể có những khoảng trống
trong kiến thức và kỹ năng của mình. Tất cả các nhà phân tích nên quyết định những
kiến thức và kỹ năng mô tả trong chương này liên quan đến tình hình của họ và tích
cực tìm cách bổ sung những khoảng trống của mình. Viện Quốc tế về Phân tích
Kinh doanh (IIBA) mô tả các năng lực mà những người phân tích kinh doanh cấp
nhập môn, cấp trung, và cấp cao nên thể hiện trong các hoạt động phổ biến của
ngành BA (IIBA 2011). Tất cả những người mới làm ngành BA sẽ được hưởng lợi
từ việc được hướng dẫn và đào tạo từ những người có kinh nghiệm hơn, có thể thông
qua hình thức thực tập. Hãy khám phá cách mà những người có nền tảng khác nhau
có thể chuyển sang vai trò người phân tích và xem một số thách thức và rủi ro mà
họ sẽ đối mặt.
 Người dùng trước đây
Các phòng ban công nghệ thông tin của các công ty thường có những người
phân tích kinh doanh đã chuyển sang vai trò đó sau khi làm việc phía kinh doanh
như là người sử dụng hệ thống thông tin. Những cá nhân này hiểu về doanh nghiệp
và môi trường làm việc, do đó họ dễ dàng có được sự tin tưởng của đồng nghiệp cũ.
Họ nói chuyện theo ngôn ngữ của người dùng và hiểu về hệ thống hiện tại và quy
trình kinh doanh.
Tuy nhiên, điều tiêu cực là những người dùng trước đây giờ đây làm ngành
BA có thể không biết nhiều về kỹ thuật phần mềm hoặc cách giao tiếp với những
người kỹ thuật. Nếu họ không quen thuộc với các kỹ thuật mô hình hóa, họ sẽ diễn
đạt tất cả thông tin dưới dạng văn bản. Những người dùng trở thành BA cần phải
tìm hiểu thêm về phía kỹ thuật trong phát triển phần mềm để có thể đại diện cho
thông tin theo hình thức phù hợp nhất với nhiều đối tượng người nghe.
Một số người dùng trước đây tin rằng họ hiểu về những gì cần thiết tốt hơn
so với người dùng hiện tại, do đó họ không tìm kiếm hoặc tôn trọng ý kiến đóng
góp từ những người sẽ thực sự sử dụng hệ thống mới. Người dùng gần đây có thể
bị mắc kẹt trong cách làm việc hiện tại, đến mức họ không nhìn thấy cơ hội để cải
thiện quy trình kinh doanh với sự trợ giúp của hệ thống thông tin mới. Đối với một
người dùng trước đây, dễ dàng chỉ tập trung vào giao diện người dùng. Tập trung
vào ý tưởng giải pháp có thể áp đặt các ràng buộc thiết kế không cần thiết và thường
không giải quyết được vấn đề thực sự.
 Nhà phát triển hoặc người kiểm thử trước đây
Các quản lý dự án thiếu một người phân tích kinh doanh cố định thường kỳ
vọng một nhà phát triển thực hiện công việc đó. Thật không may, những kỹ năng và
tính cách cần thiết cho việc phát triển yêu cầu không giống như những kỹ năng cần
thiết cho phát triển phần mềm. Một số nhà phát triển có ít kiên nhẫn với người dùng,
thích làm việc với mã nguồn và khẳng định sự hấp dẫn của công nghệ. Tất nhiên,
nhiều nhà phát triển khác nhận ra tính quan trọng của quá trình xác định yêu cầu và
có thể làm việc như những người phân tích khi cần thiết. Những người thích cộng
tác với khách hàng để hiểu nhu cầu thúc đẩy phát triển phần mềm là những ứng viên
tốt để chuyên môn hóa trong phân tích kinh doanh. Nhà phát triển chuyển sang vai
trò người phân tích có thể cần tìm hiểu thêm về lĩnh vực kinh doanh.
 Nhà phát triển dễ dàng rơi vào suy nghĩ kỹ thuật và ngôn ngữ chuyên môn,
tập trung vào việc xây dựng phần mềm thay vì nhu cầu của khách hàng. Họ sẽ cần
nắm bắt những phương pháp tốt nhất hiện tại trong kỹ thuật xác định yêu cầu. Nhà
phát triển sẽ được hưởng lợi từ việc đào tạo và hướng dẫn trong các kỹ năng mềm
đa dạng mà những người phân tích giỏi nhất đã nắm vững.
Người kiểm thử không thường được yêu cầu đảm nhận vai trò người phân
tích. Tuy nhiên, người kiểm thử thường có tư duy phân tích có thể giúp trở thành
một người phân tích kinh doanh giỏi. Người kiểm thử đã quen với việc suy nghĩ về
các trường hợp ngoại lệ và cách phá vỡ các yêu cầu, đây là một kỹ năng hữu ích để
phát hiện những khoảng trống trong yêu cầu. Tương tự như một nhà phát triển trước
đây, một người kiểm thử sẽ phải tìm hiểu về các phương pháp kỹ thuật tốt trong kỹ
thuật xác định yêu cầu. Cô ấy cũng có thể cần nắm vững hơn về lĩnh vực kinh doanh.
 Người quản lý dự án trước đây (hoặc đồng thời)
Đôi khi, người quản lý dự án được yêu cầu đảm nhận vai trò của người phân
tích kinh doanh, có lẽ vì họ có một số kỹ năng và kiến thức lĩnh vực tương tự cần
thiết. Đây có thể là một sự thay đổi vai trò hiệu quả. Người quản lý dự án đã quen
với việc làm việc với các nhóm thích hợp, hiểu về tổ chức và lĩnh vực kinh doanh,
và thể hiện kỹ năng giao tiếp mạnh mẽ. Họ có thể giỏi trong việc lắng nghe, đàm
phán và tạo điều kiện thuận lợi. Họ cũng nên có kỹ năng tổ chức và viết tốt.
Tuy nhiên, người quản lý dự án trước đây sẽ phải tìm hiểu thêm về các
phương pháp kỹ thuật tốt trong kỹ thuật xác định yêu cầu. Điều đó khác biệt giữa
việc lập kế hoạch, phân bổ tài nguyên và phối hợp các hoạt động của các nhà phân
tích và các thành viên khác trong nhóm. Đó là một vấn đề rất khác khi thực hiện vai
trò người phân tích kinh doanh một cách độc lập. Người quản lý dự án trước đây
phải học cách tập trung vào việc hiểu nhu cầu kinh doanh và ưu tiên những nhu cầu
đó trong khuôn khổ dự án hiện tại, thay vì tập trung vào tiến độ, tài nguyên và ràng
buộc ngân sách. Họ sẽ cần phát triển kỹ năng phân tích, mô hình hóa và phỏng vấn,
những kỹ năng ít quan trọng đối với người quản lý dự án nhưng lại là quan trọng
đối với sự thành công của người phân tích kinh doanh.
 Chuyên gia về lĩnh vực
Young (2001) đề nghị rằng người phân tích kinh doanh nên là một chuyên
gia lĩnh vực ứng dụng hoặc một chuyên gia về lĩnh vực (SME), thay vì chỉ là một
người dùng thông thường: "SME có thể xác định, dựa trên kinh nghiệm của họ, liệu
các yêu cầu có hợp lý, cách chúng mở rộng hệ thống hiện có, cách kiến trúc đề xuất
nên được thiết kế và tác động lên người dùng, trong số những vấn đề khác." Một số
tổ chức phát triển sản phẩm thuê người dùng chuyên gia của họ, có kinh nghiệm
 lĩnh vực rộng, để làm việc trong công ty của họ, có thể làm người phân tích hoặc
người đại diện cho người dùng.
Tuy nhiên, cũng có những rủi ro ở đây. Người phân tích kinh doanh là chuyên
gia lĩnh vực có thể đặc tả các yêu cầu hệ thống sao cho phù hợp với sở thích của
mình, thay vì đáp ứng nhu cầu hợp lệ của các lớpngười dùng khác nhau. Anh ta có
thể có những hạn chế khi suy nghĩ về yêu cầu và ít sáng tạo trong việc đề xuất ý
tưởng mới. Chuyên gia lĩnh vực thường am hiểu về hệ thống "như hiện tại"; họ đôi
khi gặp khó khăn trong việc tưởng tượng về hệ thống "như mong muốn". Thường
thì việc có một người phân tích kinh doanh từ nhóm phát triển làm việc cùng với
chuyên gia lĩnh vực, người sau đó sẽ đóng vai trò là người đại diện người dùng quan
trọng hoặc nhà bảo trợ sản phẩm. Chương 6 mô tả về nhà bảo trợ sản phẩm.
 Người mới vào nghề
Trở thành một người phân tích kinh doanh là một điểm khởi đầu tốt vào lĩnh
vực công nghệ thông tin cho những người mới ra trường hoặc đến từ một công việc
hoàn toàn không liên quan. Những người mới tốt nghiệp sẽ có ít kinh nghiệm hoặc
kiến thức liên quan, nếu có thì rất ít. Họ có thể được thuê vào vai trò người phân
tích kinh doanh vì họ thể hiện nhiều kỹ năng cần thiết để trở thành một người phân
tích giỏi. Một lợi thế khi thuê một người mới vào nghề là họ không có nhiều quan
điểm định sẵn về cách thức công việc phân tích yêu cầu nên diễn ra. Do thiếu kinh
nghiệm và kiến thức liên quan, người mới tốt nghiệp sẽ phải học rất nhiều về cách
thực hiện các nhiệm vụ người phân tích kinh doanh và những chi tiết phức tạp của
các phương pháp. Người mới tốt nghiệp cũng cần tìm hiểu đủ về quy trình phát triển
phần mềm để hiểu rõ những thách thức mà các nhà phát triển, những người kiểm
thử và các thành viên khác trong nhóm đang đối mặt, từ đó có thể hợp tác hiệu quả
với họ. Sự hướng dẫn có thể giảm thiểu sự khó khăn của quá trình học đối với một
người phân tích kinh doanh mới và tạo ra những thói quen tốt từ đầu.
Bất kể quá trình học tập và công việc trước đó, một người phân tích kinh
doanh sáng tạo có thể áp dụng chúng để nâng cao hiệu suất của mình. Người phân
tích cần tích lũy kiến thức và kỹ năng mà anh ta thiếu, xây dựng trên bất kỳ kinh
nghiệm nào trong quá khứ và thực hành thực hiện các nhiệm vụ người phân tích
kinh doanh để trở nên thành thạo hơn. Tất cả những điều này giúp tạo ra một người
phân tích kinh doanh đa năng
4. Tiến trình phát triển phần mềm Agile & Waterfall. BA trong các dự án Agile.
Mô hình thác nước được phát triển theo 6 giai đoạn cơ bản. Các bước được thực
hiện tuần tự như sau:
▪ Phân tích yêu cầu
▪ Thiết kế hệ thống
 ▪ Thực hiện
▪ Kiểm thử hệ thống
▪ Triển khai hệ thống
▪ Bảo trì hệ thống
Cụ thể mỗi giai đoạn sẽ thực hiện một số thao tác và nhiệm vụ nhất định. Đặc biệt
bước trước sẽ là tiền đề cho bước sau phát triển. Cụ thể:

Phân tích yêu cầu

Pha đầu tiên trong mô hình thác nước là phân tích yêu cầu. Đúng như tên gọi, pha
này có nhiệm vụ chính là tìm hiểu và xác định nhu cầu khách hàng đối với sản phẩm
đang phát triển. Người nghiên cứu sẽ phải trả lời được các câu hỏi: Đây có phải điều
người dùng đang cần? Đâu là các ràng buộc? Rủi ro có thể xảy ra là gì? Họ mong
muốn nhận được gì?… Từ đó các kỹ sư IT sẽ xác định được yêu cầu có thực sự phù
hợp và có thể kiểm chứng được hay không.
Thiết kế hệ thống
Dựa vào các yêu cầu đã được tìm hiểu, các kỹ sư IT sẽ thiết kế hệ thống phần
cứng/phần mềm; ngôn ngữ lập trình và cả lưu trữ dữ liệu. Sau đó ghi chú lại trên
từng phần để đảm bảo quy trình thiết kế, kiểm thử được diễn ra thuận lợi. Quá trình
thiết kế sẽ không tốn quá nhiều thời gian nhưng cần sự tập trung, tỉ mỉ.
Thực hiện
Đây là một pha quan trọng ảnh hưởng đến chất lượng sản phẩm. Các kỹ sư IT sẽ
dựa vào bản thiết kế ở giai đoạn 2 để viết code. Sau đó, tạo ra các chương trình,
phần mềm và chuyển qua pha tiếp theo.
Kiểm thử hệ thống
Giai đoạn kiểm thử được thực hiện trong quá trình phát triển phần mềm. Trong đó,
các thành viên QA và tester sẽ có nhiệm vụ kiểm tra hoạt động của hệ thống; tìm
kiếm lỗi sai và góp ý sửa chữa hoàn thiện chương trình. Quá trình này rất quan trọng
và cần được thực hiện tỉ mỉ. Nhất là trước khi đưa sản phẩm đến tay khách hàng.
Các công việc cần thực hiện gồm có:
▪ Sử dụng unit tested code để đảm bảo các chức năng hoạt động bình thường.
 ▪ Thực hiện các thử nghiệm (Functional and non functional) dựa trên kịch
bản test để chắc chắn rằng hệ thống đáp ứng được yêu cầu đặt ra.
▪ Theo dõi và viết báo cáo test.
Triển khai hệ thống
Sau khi đã chắc chắn sản phẩm đáp ứng được yêu cầu kiểm thử thì chúng ta sẽ đến
với giai đoạn sử dụng và trải nghiệm. Đây chính là lúc chương trình, phần mềm sẽ
thực sự đi vào hoạt động. Các lập trình viên cần đảm bảo môi trường hoạt động bình
thường, không có lỗi mở server, đáp ứng được các tiêu chí test. Sau đó thực hiện
kiểm tra về môi trường hoạt động để đảm bảo mọi thứ không xảy ra sai sót.
Bảo trì hệ thống
Đây là giai đoạn cuối nhưng cũng là một phần không thể thiếu trong toàn bộ quy
trình dự án. Mặc dù sản phẩm đã được bàn giao cho khách hàng nhưng vẫn có thể
xảy ra các lỗi phát sinh không mong muốn. Lúc này, các kỹ sư phần mềm sẽ phải
tìm hiểu nguyên nhân và khắc phục để đảm bảo rằng ứng dụng luôn hoạt động một
cách tốt nhất. Bên cạnh đó, các bản update cũng được tiến hành thường xuyên để
nâng cấp và sửa lỗi. Mục tiêu cuối cùng vẫn là đáp ứng tối đa nhu cầu cũng như
mong muốn của người dùng.
6 bước triển khai mô hình Agile
• Xây dựng kế hoạch dự án
Tương tự như những dự án khác, đầu tiên, nhóm phát triển phải xác định mục tiêu
cuối cùng, giá trị mà dự án đem lại cho khách hàng là gì. Sau đó, đội ngũ phải vạch
ra những công việc cần thực hiện để đạt được mục tiêu đã đề ra. Cần lưu ý, trong
quá trình áp dụng mô hình Agile, các công việc thực hiện này hoàn toàn có thể được
điều chỉnh để phù hợp hơn với sự thay đổi trong nhu cầu.
• Thiết lập lộ trình sản phẩm Lộ trình sản phẩm được hiểu là những giai
đoạn, cột mốc quan trọng trên hành trình tạo ra sản phẩm cuối cùng. Ở giai đoạn
này, đội ngũ thực hiện cần xây dựng lộ trình cụ thể, đầy đủ nhất để có thể cho ra sản
phẩm cuối cùng hoàn thiện.
• Xây dựng kế hoạch phát hành Một trong những khác biệt của mô hình Agile
và Waterfall truyền thống là mô hình Agile cho phép người thực hiện hoàn thành
một tính năng/ công việc cụ thể sau mỗi giai đoạn ngắn. Thay vì phải chờ đợi hàng
tháng hay cả năm trời để nhìn được sản phẩm cuối cùng, đội nhóm thực hiện và các
bên liên quan có thể mường tượng được thông qua các tính năng được hoàn tất trong
từng chu kỳ ngắn. Vì thế, trước khi bắt đầu triển khai dự án, hãy xây dựng một kế
hoạch cho các bản phát hành tính năng. Từ đó, các bên liên quan có thể dễ dàng truy
cập và đánh giá lại kế hoạch phát hành cho mỗi tính năng ấy.
• Xây dựng kế hoạch từng sprint Trước khi mỗi Sprint bắt đầu, những bộ
phận có liên quan phải lên kế hoạch Sprint và xác định những công việc gì cần phải
hoàn thành. Lưu ý, cần phân chia nhiệm vụ đồng đều giữa những cá nhân trong
nhóm để đảm bảo nhiệm vụ được hoàn thành đúng hạn trước thời gian chạy nước
rút.
• Đánh giá hiệu quả dự án hàng ngày Vận hành dự án theo mô hình Agile
đòi hỏi nhóm thực hiện phải tổ chức những cuộc họp, trao đổi ngắn hàng ngày để
đánh giá và cân nhắc công việc. Trong cuộc trao đổi đó, mỗi người sẽ thông tin ngắn
gọn về những công việc đang đảm nhận, có gặp khó khăn hay vấn đề gì không.
• Đánh giá Sprint Sau khi kết thúc mỗi Sprint, nhóm thực hiện sẽ tổ chức hai
cuộc họp. Đó là cuộc họp với những bộ phận liên quan để nghiệm thu sản phẩm đã
hoàn thành, và một cuộc họp trực tiếp để các bên thảo luận về những phát sinh về
sản phẩm (nếu có).
Có nhiều phương pháp Agile khác nhau trong kiểm thử nhanh

1. Scrum
SCRUM là một phương pháp phát triển nhanh tập trung đặc biệt vào cách
quản lý các nhiệm vụ trong môi trường phát triển dựa trên nhóm. Về cơ bản, Scrum
có nguồn gốc từ hoạt động xảy ra trong một trận đấu bóng bầu dục. Scrum tin tưởng
vào việc trao quyền cho nhóm phát triển và ủng hộ việc làm việc trong các nhóm
nhỏ (ví dụ – 7 đến 9 thành viên). Agile và Scrum bao gồm ba vai trò và trách nhiệm
của chúng được giải thích như sau:
Scrum Master
 Scrum Master chịu trách nhiệm thiết lập nhóm, cuộc họp chạy nước
rút và loại bỏ các trở ngại đối với tiến độ
 Product owner
 The Product Owner tạo product backlog, đánh giá độ ưu tiên của
backlog và chịu trách nhiệm cung cấp chức năng ở mỗi lần lặp lại.
Scrum Team
 Nhóm tự quản lý công việc của mình và tổ chức công việc để hoàn
thành sprint hoặc cycle
Product Backlog
Đây là một kho lưu trữ mà các yêu cầu được theo dõi với các chi tiết về
không có yêu cầu (câu chuyện người dùng) được hoàn thành cho mỗi bản phát hành.
Nó nên được Product Owner duy trì và ưu tiên, và nó nên được phân phối cho nhóm
scrum. Nhóm cũng có thể yêu cầu bổ sung hoặc sửa đổi hoặc xóa yêu cầu mới
Scrum Practices
Các thực hành được mô tả chi tiết:

Quy trình kiểm tra scrum như sau:

 Mỗi lần lặp lại của một scrum được gọi là Sprint
 Product backlog là một danh sách nơi tất cả các chi tiết được nhập để
có được sản phẩm cuối cùng
 Trong mỗi Sprint, các câu chuyện người dùng hàng đầu về Product
backlog được chọn và chuyển thành Sprint backlog
 Nhóm làm việc trên sprint backlog đã xác định
  Nhóm kiểm tra công việc hàng ngày
 Vào cuối sprint, nhóm cung cấp chức năng sản phẩm
2. Extreme Programming (XP)
Kỹ thuật Extreme Programming rất hữu ích khi có nhu cầu hoặc yêu
cầu thay đổi liên tục từ khách hàng hoặc khi họ không chắc chắn về chức năng của
hệ thống. Nó ủng hộ việc “phát hành” sản phẩm thường xuyên trong các chu kỳ phát
triển ngắn, điều này vốn giúp cải thiện năng suất của hệ thống và cũng giới thiệu
một điểm kiểm tra nơi có thể dễ dàng thực hiện bất kỳ yêu cầu nào của khách hàng.
XP phát triển phần mềm giữ khách hàng trong tầm ngắm.

Các yêu cầu nghiệp vụ được tập hợp dưới dạng các câu chuyện. Tất cả
những câu chuyện đó được lưu trữ ở một nơi gọi là parking lot.
Trong loại phương pháp luận này, các bản phát hành dựa trên các chu kỳ
ngắn hơn được gọi là Lặp lại với khoảng thời gian 14 ngày. Mỗi lần lặp lại bao gồm
các giai đoạn như mã hóa, thử nghiệm đơn vị và thử nghiệm hệ thống, trong đó ở
mỗi giai đoạn, một số chức năng nhỏ hoặc chính sẽ được xây dựng trong ứng dụng.
Các giai đoạn của lập trình eXtreme:
Có 6 giai đoạn có sẵn trong phương pháp Agile XP và chúng được giải
thích như sau:
Planning
 Identification of stakeholders and sponsors
 Infrastructure Requirements
 Security related information and gathering
 Service Level Agreements and its conditions
Analysis
 Capturing of Stories in Parking lot
 Prioritize stories in Parking lot
 Scrubbing of stories for estimation
 Define Iteration SPAN(Time)
 Resource planning for both Development and QA teams
Design
 Break down of tasks
 Test Scenario preparation for each task
 Regression Automation Framework
Execution
 Coding
 Unit Testing
 Execution of Manual test scenarios
 Defect Report generation
 Conversion of Manual to Automation regression test cases
 Mid Iteration review
 End of Iteration review
Wrapping
 Small Releases
 Regression Testing
 Demos and reviews
 Develop new stories based on the need
 Process Improvements based on end of iteration review comments
Closure
 Pilot Launch
  Training
 Production Launch
 SLA Guarantee assurance
 Review SOA strategy
 Production Support
Có hai phân cảnh có sẵn để theo dõi công việc hàng ngày và chúng được
liệt kê bên dưới để tham khảo.
 Story Cardboard
 Đây là một cách truyền thống để thu thập tất cả các câu chuyện trong
một bảng dưới dạng ghi chú que để theo dõi các hoạt động XP hàng ngày. Vì hoạt
động thủ công này đòi hỏi nhiều nỗ lực và thời gian hơn, nên tốt hơn là chuyển sang
hình thức trực tuyến.
 Online Storyboard
 Online tool Storyboard có thể được sử dụng để lưu trữ stories. Several
teams có thể sử dụng nó cho các mục đích khác nhau.
3. Crystal Methodologies
Phương pháp luận tinh thể dựa trên ba khái niệm
1. Chartering: Các hoạt động khác nhau liên quan đến giai đoạn này là
tạo nhóm phát triển, thực hiện phân tích tính khả thi sơ bộ, phát triển kế hoạch ban
đầu và tinh chỉnh phương pháp phát triển
2. Cyclic delivery: Giai đoạn phát triển chính bao gồm hai hoặc nhiều
chu kỳ phân phối, trong đó
1. Nhóm cập nhật và tinh chỉnh kế hoạch phát hành
2. Triển khai một tập hợp con các yêu cầu thông qua một hoặc nhiều lần
lặp lại tích hợp kiểm tra chương trình
3. Sản phẩm tích hợp được chuyển đến tay người dùng thực
4. Rà soát kế hoạch dự án và phương pháp phát triển được thông qua
3. Wrap Up: Các hoạt động được thực hiện trong giai đoạn này là triển
khai vào môi trường người dùng, đánh giá sau triển khai và phản ánh được thực
hiện.
 4. Dynamic Software Development Method (DSDM)
DSDM là cách tiếp cận Rapid Application Development (RAD) để phát
triển phần mềm và cung cấp một khung phân phối dự án nhanh. Khía cạnh quan
trọng của DSDM là người dùng bắt buộc phải tham gia tích cực và các nhóm được
trao quyền đưa ra quyết định. Việc phân phối sản phẩm thường xuyên trở thành tâm
điểm tích cực với DSDM. Các kỹ thuật được sử dụng trong DSDM là
1. Time Boxing
2. MoSCoW Rules
3. Prototyping
Dự án DSDM bao gồm 7 giai đoạn
1. Pre-project
2. Feasibility Study
3. Business Study
4. Functional Model Iteration
5. Design and build Iteration
6. Implementation
7. Post-project
5. Feature Driven Development (FDD)
Phương pháp này tập trung vào các tính năng “thiết kế và xây dựng”.
Không giống như các phương pháp Agile khác trong kỹ thuật phần mềm, FDD mô
tả các giai đoạn rất cụ thể và ngắn của công việc phải được thực hiện riêng biệt cho
từng tính năng. Nó bao gồm domain walkthrough,design inspection, promote to
build, code inspection và design. FDD phát triển sản phẩm tuân theo những điều
trong mục tiêu
1. Domain object Modeling
2. Development by feature
3. Component/ Class Ownership
4. Feature Teams
5. Inspections
6. Configuration Management
 7. Regular Builds
8. Visibility of progress and results
6. Lean Software Development
Lean software development method dựa trên nguyên tắc “Sản xuất đúng
lúc”. Nó nhằm mục đích tăng tốc độ phát triển phần mềm và giảm chi phí. Lean
development có thể được tóm tắt trong bảy bước.
1. Eliminating Waste
2. Amplifying learning
3. Defer commitment (deciding as late as possible)
4. Early delivery
5. Empowering the team
6. Building Integrity
7. Optimize the whole
7. Kanban
Kanban ban đầu xuất phát từ từ tiếng Nhật có nghĩa là, một thẻ chứa tất
cả thông tin cần thiết để thực hiện trên sản phẩm ở mỗi giai đoạn dọc theo con đường
hoàn thành của nó. Khung hoặc phương pháp này được áp dụng khá phổ biến trong
phương pháp kiểm thử phần mềm, đặc biệt là trong các khái niệm Agile.
Dưới đây là một mô tả về các bước trong tiến trình phát triển phần mềm
Kanban:
1. Xác định bảng Kanban: Ban đầu, bạn cần xác định bảng Kanban của
mình, gồm các cột đại diện cho các giai đoạn khác nhau trong quy trình phát triển
phần mềm của bạn. Các cột thường gồm "To Do" (Cần làm), "Doing" (Đang làm),
và "Done" (Đã hoàn thành), nhưng bạn có thể tùy chỉnh chúng để phù hợp với quy
trình làm việc của bạn.
2. Tạo ra các thẻ công việc: Mỗi công việc được tạo thành một thẻ và đặt
trong cột "To Do" để biểu thị rằng nó cần được thực hiện. Thẻ công việc nên được
mô tả rõ ràng về nhiệm vụ, thời gian ước tính và các yêu cầu khác.
3. Di chuyển thẻ công việc qua các cột: Khi một thành viên trong nhóm
hoặc bạn chịu trách nhiệm cho một công việc, thẻ công việc sẽ được di chuyển từ
cột "To Do" sang cột "Doing". Khi công việc hoàn thành, nó sẽ được di chuyển sang
cột "Done". Việc di chuyển thẻ công việc này sẽ giúp mọi người trong nhóm có cái
nhìn tổng quan về tiến độ và trạng thái của các công việc.
4. Quản lý công việc đang thực hiện: Trong quá trình thực hiện công
việc, các thành viên trong nhóm có thể cập nhật tiến độ, thời gian dự kiến hoàn
thành và thêm bất kỳ thông tin cần thiết nào liên quan đến công việc trên thẻ công
việc. Điều này giúp cải thiện khả năng giao tiếp và theo dõi tiến trình công việc.
5. Quản lý luồng công việc: Một nguyên tắc quan trọng của Kanban là
giới hạn số lượng công việc đang được thực hiện trong cột "Doing". Điều này nhằm
mục đích tránh quá tải và tăng cường hiệu suất làm việc của nhóm. Khi số lượng
công việc trong cột "Doing" đạt đến giới hạn, không thêm công việc mới được bắt
đầu cho đến khi một công việc hoàn thành và được di chuyển sang cột "Done".
6. Đánh giá và cải tiến: Quá trình Kanban liên tục được cải tiến dựa trên
phản hồi và đánh giá. Nhóm cần thường xuyên kiểm tra tiến độ công việc, hiệu suất
làm việc và tìm cách để cải thiện quy trình phát triển phần mềm. Các điểm yếu và
vấn đề phát sinh được xác định và giải quyết trong quá trình này.
BA trong các dự án Agile
Vai trò của người phân tích trên các dự án Agile
Trên các dự án sử dụng phương pháp phát triển Agile, các chức năng của
người phân tích kinh doanh vẫn cần được thực hiện, nhưng người thực hiện chúng
có thể không được gọi là BA. Một số phương pháp Agile có một thành viên quan
trọng được gọi là chủ sở hữu sản phẩm. Người đảm nhiệm vai trò đó có thể thực
hiện một số hoạt động phân tích kinh doanh truyền thống, cung cấp tầm nhìn về sản
phẩm, truyền đạt các ràng buộc, xác định ưu tiên cho danh sách công việc còn lại
của sản phẩm và đưa ra quyết định cuối cùng về sản phẩm (Cohn 2010). Các dự án
khác duy trì một vai trò người phân tích kinh doanh riêng biệt so với chủ sở hữu sản
phẩm. Ngoài ra, các thành viên khác trong nhóm, như các nhà phát triển, thực hiện
một phần công việc của người phân tích kinh doanh. Điểm quan trọng là, bất kể
phương pháp phát triển dự án, các nhiệm vụ liên quan đến vai trò người phân tích
kinh doanh vẫn phải được hoàn thành. Nhóm sẽ có lợi từ việc có các thành viên sở
hữu những kỹ năng liên quan đến người phân tích kinh doanh.
Thường, trong một tổ chức chuyển đổi sang phương pháp phát triển
Agile, người phân tích kinh doanh thường cảm thấy không chắc chắn về cách thức
cống hiến hiệu quả nhất cho dự án. Theo tinh thần của phát triển Agile, người phân
tích phải sẵn lòng thoát ra khỏi vai trò định trước của "người phân tích kinh doanh"
và đóng vai trò cần thiết để giúp giao hàng một sản phẩm thành công. Ellen
Gottesdiener (2009) cung cấp một danh sách chi tiết về cách các hoạt động phân
tích kinh doanh truyền thống có thể được điều chỉnh trong môi trường Agile. Dưới
đây là một số gợi ý để người phân tích kinh doanh áp dụng kỹ năng của mình trong
dự án Agile:
- Xác định một quy trình yêu cầu linh hoạt, nhẹ nhàng và điều chỉnh nó
theo yêu cầu của dự án.
- Đảm bảo tài liệu yêu cầu ở mức phù hợp: không quá ít và không quá
nhiều. (Nhiều người phân tích kinh doanh thường có xu hướng ghi chép mọi thứ
trong các tài liệu yêu cầu. Một số người tán thành cho rằng các dự án Agile nên có
ít hoặc không có tài liệu yêu cầu. Cả hai cực đoan đều không lý tưởng.)
- Giúp xác định phương pháp tốt nhất để tài liệu hóa danh sách công việc
còn lại, bao gồm xem liệu việc sử dụng thẻ story hay các công cụ hình thức hơn là
phù hợp hơn.
- Áp dụng kỹ năng tạo điều kiện và lãnh đạo để đảm bảo các bên liên
quan thường xuyên traothoại với nhau về các yêu cầu, câu hỏi và quan ngại liên
quan.
- Giúp xác nhận rằng nhu cầu của khách hàng được đại diện một cách
chính xác trong danh sách công việc còn lại của sản phẩm và tạo điều kiện cho việc
ưu tiên danh sách công việc.
- Làm việc với khách hàng khi họ thay đổi ý kiến về yêu cầu và ưu tiên,
và giúp ghi lại những thay đổi đó. Làm việc với phần còn lại của nhóm để xác định
tác động của các thay đổi lên nội dung vòng lặp và kế hoạch phát hành.
Việc có một vai trò như chủ sở hữu sản phẩm để đại diện cho người dùng
trong suốt quá trình phát triển mang lại rất nhiều giá trị. Tuy nhiên, người đảm nhiệm
vai trò chủ sở hữu sản phẩm có thể không có đầy đủ kỹ năng phân tích kinh doanh
hoặc thời gian để thực hiện tất cả các hoạt động liên quan. Một người phân tích kinh
doanh có thể mang lại những khả năng quan trọng đó cho nhóm.
Tạo ra một nhóm cộng tác
Các dự án phần mềm đôi khi gặp khó khăn trong việc xây dựng mối quan
hệ căng thẳng giữa các nhà phân tích, nhà phát triển, người dùng, quản lý và tiếp
thị. Các bên không luôn tin tưởng vào động cơ của nhau hoặc đánh giá đúng nhu
cầu và ràng buộc của nhau. Tuy nhiên, thực tế là những người sản xuất và người
tiêu dùng của một sản phẩm phần mềm có các mục tiêu chung. Đối với việc phát
triển hệ thống thông tin doanh nghiệp, tất cả các bên đều làm việc cho cùng một
công ty, vì vậy tất cả đều hưởng lợi từ việc cải thiện kết quả kinh doanh của công
 ty. Đối với các sản phẩm thương mại, khách hàng hài lòng tạo ra doanh thu cho nhà
sản xuất và sự hài lòng cho những nhà phát triển.
Người phân tích kinh doanh có trách nhiệm quan trọng trong việc xây
dựng một mối quan hệ cộng tác giữa các đại diện người dùng và các bên liên quan
khác trong dự án. Một người phân tích hiệu quả đánh giá đúng những thách thức mà
các bên liên quan kinh doanh và kỹ thuật đối mặt và luôn thể hiện sự tôn trọng đối
với đồng nghiệp của mình. Người phân tích điều hướng các thành viên dự án đến
một thỏa thuận yêu cầu dẫn đến kết quả win-win-win như sau:
- Khách hàng hài lòng với sản phẩm.
- Tổ chức phát triển hài lòng với kết quả kinh doanh.
- Tất cả thành viên trong nhóm tự hào về công việc tốt mà họ đã làm trong
một dự án đầy thách thức và đáng giá.
5. Mô hình yêu cầu phần mềm: Liệt kê các biểu đồ có thể sử dụng cho mô hình yêu
cầu phần mềm.
Trả lời:
Các nhà phân tích kinh doanh có thể hy vọng tìm ra một kỹ thuật có thể kết
hợp mọi thứ lại với nhau thành một tổng thể mô tả các yêu cầu của hệ thống. Nhưng
không có sơ đồ nào bao gồm tất cả như vậy. Thực tế, nếu bạn có thể mô hình hóa
toàn bộ hệ thống trong một sơ đồ duy nhất thì sơ đồ đó sẽ không thể sử dụng được.
Như một danh sách dài các yêu cầu riêng. Mục tiêu ban đầu của phân tích hệ thống
có cấu trúc là thay thế đặc tả chức năng cổ điển là sử dụng ngôn ngữ, tường thuật
chữ bằng các sơ đồ và ký hiệu mang tính hình thức. Tuy nhiên, kinh nghiệm đã chỉ
ra rằng các mô hình phân tích nên tăng cường - thay vì thay thế - một đặc tả yêu cầu
được viết bằng ngôn ngữ tự nhiên.
Các mô hình yêu cầu trực quan có thể giúp bạn xác định các yêu cầu thiếu,
thừa và không nhất quán. Với những hạn chế của bộ nhớ ngắn hạn của con người,
việc phân tích một danh sách gồm một nghìn yêu cầu để tìm sự không nhất quán,
trùng lặp và yêu cầu thừa thì gần như không thể. Đến khi bạn đọc yêu cầu thứ mười
lăm, bạn có thể đã quên đi một số yêu cầu đầu tiên mà bạn đã đọc. Bạn khó lòng tìm
thấy tất cả các lỗi chỉ bằng cách xem xét các yêu cầu văn bản.
Các biểu đồ có thể sử dụng cho mô hình yêu cầu phần mềm:
+ Sơ đồ dòng dữ liệu (Data Flow Diagrams - DFDs)
+ Sơ đồ luồng quy trình (Process Flow Diagrams)
+ Sơ đồ chuyển trạng thái (State-Transition Diagrams - STDs) và bảng trạng
thái
+ Bản đồ đối thoại (Dialog Maps)
+ Bảng quyết định và cây quyết định (Decision Tables and Decision Trees)
 + Bảng phản ứng sự kiện (Event-Response Tables)
+ Cây tính năng (Feature Trees)
+ Sơ đồ trường hợp sử dụng (Use Case Diagrams)
+ Sơ đồ hoạt động (Activity Diagrams)
+ Sơ đồ mối quan hệ thực thể (Entity-Relationship Diagrams - ERDs)
a. Sơ đồ dòng dữ liệu (Data Flow Diagrams - DFDs)
Sơ đồ dòng dữ liệu (DFD) là một công cụ mạnh mẽ để mô hình hóa cách
thông tin di chuyển trong hệ thống. DFDs chia cấu trúc của hệ thống thành các
thành phần chính gồm các quy trình (processes), dòng dữ liệu (data flows), lưu
trữ dữ liệu (data stores), và người dùng hoặc thực thể bên ngoài (external
entities). Các quy trình biểu diễn các hoạt động hoặc chức năng trong hệ thống,
dòng dữ liệu đại diện cho thông tin được truyền đi và đến, còn các lưu trữ dữ
liệu đại diện cho nơi dữ liệu được lưu trữ trong hệ thống.
DFDs giúp bạn hiểu cách dữ liệu được xử lý và di chuyển trong hệ thống, từ
đó giúp xác định yêu cầu về dữ liệu và quy trình.
b. Sơ đồ luồng quy trình (Process Flow Diagrams)
Sơ đồ luồng quy trình là một loại biểu đồ thường được gọi là "sơ đồ
swimlane" do nó chia quy trình làm việc thành các hàn động riêng biệt tương
ứng với các bên tham gia (người dùng, bộ phận, vị trí). Điều này giúp hiển thị
cách các bên liên quan tham gia vào quy trình làm việc và tương tác với nhau.
Sơ đồ swimlane rất hữu ích để hiểu quy trình làm việc, phân chia trách nhiệm
và tương tác giữa các phần tử trong hệ thống
c. Sơ đồ chuyển trạng thái (State-Transition Diagrams - STDs) và bảng trạng
thái
Sơ đồ chuyển trạng thái được sử dụng để mô hình hóa trạng thái của các thực
thể trong hệ thống và cách chúng chuyển đổi giữa các trạng thái. Mỗi trạng thái
đại diện cho một tình huống hoặc điều kiện cụ thể. Các sự kiện và điều kiện xác
định cách thực thể chuyển đổi từ một trạng thái này sang trạng thái khác.
Bảng trạng thái là một biểu đồ hoặc bảng liệt kê tất cả các trạng thái có thể
của một đối tượng hoặc hệ thống và cách chúng chuyển đổi dựa trên các sự kiện.
d. Bản đồ đối thoại (Dialog Maps)
Bản đồ đối thoại là một công cụ hữu ích để mô hình hóa giao diện người
dùng của hệ thống. Nó cho phép bạn vẽ các cửa sổ, điều khiển (như nút và ô
nhập liệu), và cách họ tương tác với người dùng. Bản đồ đối thoại giúp xác định
cách người dùng tương tác với hệ thống, bao gồm các tương tác bất thường và
các luồng làm việc khác nhau.
e. Bảng quyết định và cây quyết định (Decision Tables and Decision Trees)
Bảng quyết định là một phương pháp biểu diễn các quyết định và logic quyết
định trong hệ thống bằng cách sử dụng các bảng. Các bảng quyết định liệt kê các
điều kiện và quyết định tương ứng với các kết quả hoặc hành động.
 Cây quyết định là một biểu đồ dạng cây có thể được sử dụng để biểu diễn
dạng cây quyết định với các điều kiện và kết quả tương ứng.
f. Bảng phản ứng sự kiện (Event-Response Tables)
Bảng phản ứng sự kiện là một công cụ để mô hình hóa cách hệ thống phản
ứng khi xảy ra sự kiện cụ thể. Nó liệt kê các sự kiện và phản ứng tương ứng, cho
phép bạn hiểu cách hệ thống xử lý các sự kiện này.
g. Cây tính năng (Feature Trees)
Cây tính năng là một cách để tổ chức và hiển thị các tính năng của hệ thống
và cách chúng liên quan đến nhau. Các tính năng được tổ chức theo cấp độ và
mức độ ưu tiên.
h. Sơ đồ trường hợp sử dụng (Use Case Diagrams)
Sơ đồ trường hợp sử dụng được sử dụng để biểu diễn các tình huống sử dụng
của hệ thống và các tương tác giữa các thực thể trong hệ thống. Nó giúp xác định
các chức năng và tương tác chính của hệ thống từ góc nhìn của người dùng.
i. Sơ đồ hoạt động (Activity Diagrams)
Sơ đồ hoạt động giúp mô hình hóa các hoạt động và quy trình trong hệ thống.
Nó tập trung vào dòng thời gian của các hoạt động và quy trình, cho phép bạn
hiểu cách chúng diễn ra và tương tác với nhau.
j. Sơ đồ mối quan hệ thực thể (Entity-Relationship Diagrams – ERDs)
ERDs được sử dụng để biểu diễn cấu trúc cơ sở dữ liệu và mối quan hệ giữa
các thực thể. Chúng mô tả cách các đối tượng và dữ liệu liên kết với nhau trong

hệ thống.
Các loại biểu đồ này là những công cụ quan trọng trong quá trình phân tích và mô
hình hóa yêu cầu phần mềm. Sử dụng chúng một cách hiệu quả giúp đảm bảo rằng
 bạn hiểu rõ yêu cầu của hệ thống và cách các yếu tố trong hệ thống tương tác với
nhau.
Liên hệ giữa yêu cầu của khách hàng với các thành phần của mô hình phân
tích
- Danh từ: Những người, tổ chức, hệ thống phần mềm, thành phần dữ liệu hoặc
đối tượng tồn tại
■ Các thực thể bên ngoài, kho dữ liệu hoặc dòng dữ liệu (DFD)
■ Diễn viên (sơ đồ trường hợp sử dụng)
■ Thực thể hoặc các thuộc tính của chúng (ERD)
■ Lanes (sơ đồ swimlane)
■ Đối tượng với các trạng thái (STD)
- Động từ Hành động, những điều mà người dùng hoặc hệ thống có thể thực
hiện hoặc các sự kiện có thể xảy ra
■ Quy trình (DFD)
■ Các bước trong quy trình (sơ đồ swimlane)
■ Trường hợp sử dụng (sơ đồ trường hợp sử dụng)
■ Mối quan hệ (ERD)
■ Chuyển tiếp (STD)
■ Hoạt động (sơ đồ hoạt động)
■ Sự kiện (bảng phản ứng sự kiện)
- Câu điều kiện Câu điều kiện logic, như if/then
■ Quyết định (cây quyết định, bảng quyết định hoặc sơ đồ hoạt động)
■ Nhánh (sơ đồ swimlane hoặc sơ đồ hoạt động)
6. Chọn kỹ thuật mô hình hay biểu diễn thích hợp. Cho ví dụ minh họa.
Trả lời:
a. Giao diện bên ngoài của hệ thống
Kỹ thuật biểu diễn đầu tiên chúng ta sẽ khám phá có liên quan đến các giao diện
bên ngoài của hệ thống. Các giao diện này đóng một vai trò quan trọng trong việc
phát triển hệ thống vì chúng xác định cách hệ thống tương tác với các thực thể bên
ngoài. Để truyền đạt thông tin này một cách hiệu quả, một số kỹ thuật có thể được
sử dụng.
a) Biểu đồ ngữ cảnh: Biểu đồ ngữ cảnh cung cấp sự trừu tượng hóa ở
mức độ cao của hệ thống bằng cách xác định các đối tượng bên ngoài hệ thống kết
nối với nó. Ví dụ, hãy xem xét sự phát triển của một nền tảng thương mại điện tử.
Biểu đồ ngữ cảnh sẽ hiển thị hệ thống ở trung tâm, được bao quanh bởi các thực thể
bên ngoài như khách hàng, nhà cung cấp và cổng thanh toán.
 b) Biểu đồ use case: Những biểu đồ này giúp xác định các trường hợp sử
dụng khác nhau và các tác nhân tương tác với hệ thống. Ví dụ: trong nền tảng thương
mại điện tử của chúng tôi, biểu đồ use case sẽ phác thảo các tác nhân như "Khách
hàng" và các trường hợp sử dụng như "Đặt hàng".
c) Biểu đồ luồng dữ liệu (DFD): DFD minh họa luồng dữ liệu trong hệ
thống và các giao diện bên ngoài của nó. Ví dụ: DFD có thể hiển thị cách dữ liệu
đặt hàng của khách hàng truyền từ trang web đến cổng thanh toán.
d) Bản đồ hệ sinh thái: Kỹ thuật này vượt xa các giao diện trực tiếp, lập
bản đồ toàn bộ hệ sinh thái của các hệ thống có thể tương tác với dự án. Nó giúp
xác định cả sự phụ thuộc trực tiếp và gián tiếp, cung cấp cái nhìn toàn diện về bối
cảnh của hệ thống.
e) Biểu đồ swimlane: Khi xử lý sự tương tác giữa các hệ thống, biểu đồ
swimlane có thể là vô giá. Chúng minh họa những gì xảy ra trong các tương tác này,
phân công trách nhiệm cho các “làn đường” hoặc các thực thể khác nhau.
Ví dụ: Biểu đồ swimlane cho hệ thống thương mại điện tử của chúng tôi
có thể mô tả các bước liên quan đến xử lý đơn hàng, với mỗi làn đại diện cho một
hệ thống hoặc tác nhân khác nhau.
Ngoài ra, chi tiết giao diện bên ngoài có thể được ghi lại ở nhiều định
dạng khác nhau như định dạng tệp đầu vào và đầu ra hoặc bố cục báo cáo. Trong
trường hợp hệ thống bao gồm cả thành phần phần mềm và phần cứng, thông số kỹ
thuật giao diện có thể bao gồm các định nghĩa thuộc tính dữ liệu, thường ở dạng
giao diện lập trình ứng dụng (API) hoặc tín hiệu đầu vào và đầu ra cụ thể cho thiết
bị phần cứng.
Ví dụ: Hãy tưởng tượng một hệ thống an ninh nhà thông minh có giao
diện với nhiều thiết bị bên ngoài khác nhau như camera, cảm biến và ứng dụng di
động. Biểu đồ ngữ cảnh sẽ mô tả cốt lõi của hệ thống, được bao quanh bởi các thực
thể bên ngoài này. Biểu đồ use case sẽ minh họa sự tương tác giữa người dùng và
hệ thống, trong khi DFD sẽ trình bày chi tiết cách truyền dữ liệu giữa hệ thống và
các thiết bị bên ngoài.
b. Business Process Flow
Hiểu cách thức hoạt động của Business Process Flow là nền tảng để phát triển
hệ thống. Việc trình bày rõ ràng các luồng quy trình kinh doanh sẽ hỗ trợ việc xác
định các yêu cầu và đảm bảo thiết kế hệ thống hiệu quả.
- Biểu đồ luồng dữ liệu cấp cao nhất (DFD): Ở mức độ trừu tượng cao,
DFD cấp cao nhất thể hiện cách quy trình kinh doanh xử lý dữ liệu. Ví dụ: trong
một doanh nghiệp bán lẻ, DFD cấp cao nhất có thể mô tả luồng đơn đặt hàng của
khách hàng từ nơi đặt hàng đến khi thực hiện.
- Biểu đồ swimlane: Những biểu đồ này đặc biệt hữu ích để thể hiện các
vai trò tham gia thực hiện các bước khác nhau trong luồng quy trình công việc.
Trong một công ty sản xuất, biểu đồ swimlane có thể minh họa cách các bộ phận
khác nhau, chẳng hạn như sản xuất và kiểm soát chất lượng, cộng tác như thế nào
trong quá trình sản xuất.
Flowcharts: Flowcharts rất linh hoạt và có thể được sử dụng để xác định
cả quy trình cấp cao và quy trình chi tiết. Chúng cung cấp sự trình bày trực quan về
các bước, quyết định và vòng lặp tuần tự trong một quy trình. Trong một công ty du
lịch, một biểu đồ có thể phác thảo các bước liên quan đến việc đặt gói kỳ nghỉ.
- Biểu đồ hoạt động (Activity Diagram): Tương tự như flowcharts, biểu
đồ hoạt động mô tả trực quan dòng chảy của một quy trình nhưng đặc biệt hiệu quả
để mô hình hóa các quy trình phức tạp.
Ví dụ, trong bệnh viện, biểu đồ hoạt động có thể biểu thị quy trình tiếp
nhận bệnh nhân, bao gồm các điểm quyết định khác nhau và các hoạt động song
song.
Các mức DFD hoặc biểu đồ swimlane được tinh chỉnh có thể thể hiện các
luồng quy trình kinh doanh một cách chi tiết đáng kể. flowcharts và biểu đồ hoạt
động có thể được điều chỉnh để xác định mức độ phức tạp của một quy trình, đảm
bảo rằng không có bước hoặc điểm quyết định nào bị bỏ qua.
Ví dụ: Hãy xem xét một hệ thống ngân hàng trực tuyến. DFD cấp cao
nhất sẽ cung cấp cái nhìn tổng quan về cách khách hàng bắt đầu giao dịch và cách
hệ thống xử lý chúng. Biểu đồ làn bơi có thể minh họa vai trò của khách hàng, nhân
viên ngân hàng và hệ thống tự động trong các quy trình ngân hàng khác nhau. Sau
đó, flowcharts hoặc biểu đồ hoạt động có thể chia nhỏ các quy trình cụ thể như
chuyển tiền hoặc truy vấn số dư tài khoản thành các bước và điểm quyết định chi
tiết.
c. Định nghĩa dữ liệu và mối quan hệ đối tượng dữ liệu
Dữ liệu là huyết mạch của nhiều hệ thống và việc thể hiện chính xác các định
nghĩa và mối quan hệ dữ liệu là rất quan trọng để phát triển hệ thống.
- Sơ đồ mối quan hệ thực thể (ERD): ERD hiển thị mối quan hệ logic giữa
các đối tượng hoặc thực thể dữ liệu. Trong hệ thống chăm sóc sức khỏe, ERD có
thể minh họa cách hồ sơ bệnh nhân được liên kết với chẩn đoán, điều trị và nhà cung
cấp dịch vụ y tế.
 - Biểu đồ lớp: Mặc dù chủ yếu liên quan đến lập trình hướng đối tượng,
nhưng biểu đồ lớp cũng dùng để mô tả các kết nối logic giữa các lớp đối tượng và
dữ liệu liên quan đến chúng. Trong một dự án phát triển phần mềm, biểu đồ lớp sẽ
hiển thị mối quan hệ giữa các lớp phần mềm khác nhau và thuộc tính của chúng.
- Từ điển dữ liệu (data dictionary): Từ điển dữ liệu chứa các định nghĩa
toàn diện về cấu trúc dữ liệu và các mục dữ liệu riêng lẻ. Nó dần dần chia nhỏ các
đối tượng dữ liệu phức tạp thành các phần tử dữ liệu cấu thành của chúng.
Ví dụ: trong hệ thống quản lý hàng tồn kho, từ điển dữ liệu sẽ cung cấp định
nghĩa chi tiết về các mặt hàng, bao gồm các thuộc tính như tên, giá và số lượng hiện
có.
Ví dụ: Hãy tưởng tượng sự phát triển của hệ thống quản lý quan hệ khách
hàng (CRM) cho nhóm bán hàng. ERD sẽ minh họa cách các thực thể dữ liệu khách
hàng liên quan đến khách hàng tiềm năng, cơ hội và liên hệ bán hàng. Biểu đồ lớp
có thể mô tả cấu trúc logic của các thành phần phần mềm chịu trách nhiệm quản lý
dữ liệu khách hàng. Từ điển dữ liệu sẽ xác định từng thành phần dữ liệu trong hồ sơ
khách hàng, chỉ định các thuộc tính như tên, email và số điện thoại.
d. Trạng thái hệ thống và đối tượng
Các hệ thống và đối tượng thường trải qua nhiều trạng thái khác nhau và hiểu
được những chuyển đổi này là điều cần thiết để phát triển hệ thống hiệu quả.
- Sơ đồ chuyển trạng thái: Những sơ đồ này cung cấp cái nhìn tổng thể về
các trạng thái có thể có của một hệ thống hoặc đối tượng và những thay đổi giữa các
trạng thái trong các trường hợp cụ thể. Khi phát triển trò chơi điện tử, sơ đồ chuyển
đổi trạng thái có thể cho thấy cách nhân vật có thể chuyển đổi giữa các trạng thái
như "nhàn rỗi", "đi bộ" và "tấn công" dựa trên đầu vào của người dùng.
- Bảng trạng thái: Bảng trạng thái cung cấp cách trình bày dưới dạng bảng
về các chuyển đổi trạng thái, giúp dễ dàng hình dung các trạng thái khác nhau cũng
như các sự kiện hoặc điều kiện kích hoạt chuyển đổi. Ví dụ: trong hệ thống điều
khiển thang máy, bảng trạng thái sẽ trình bày chi tiết cách thang máy di chuyển giữa
các trạng thái như "di chuyển lên", "di chuyển xuống" và "dừng" để phản hồi lại các
lần nhấn nút và đầu vào cảm biến.
- Bảng phản hồi sự kiện: Bảng phản hồi sự kiện đóng vai trò là công cụ xác
định phạm vi bằng cách xác định các sự kiện bên ngoài xác định ranh giới phạm vi
của hệ thống. Họ cũng có thể chỉ định các yêu cầu chức năng riêng lẻ bằng cách nêu
chi tiết cách hệ thống sẽ hoạt động để đáp ứng với từng sự kết hợp giữa sự kiện bên
ngoài và trạng thái hệ thống. Trong hệ thống đặt phòng, bảng phản hồi sự kiện có
thể phác thảo cách hệ thống phản hồi khi khách hàng cố gắng đặt phòng khách sạn
đã kín người.
Các yêu cầu chức năng đóng một vai trò quan trọng trong việc mô tả cáchành
vi của hệ thống dẫn đến thay đổi trạng thái, đảm bảo rằng hệ thống hoạt động như
mong đợi trong các tình huống khác nhau.
Ví dụ: Hãy xem xét một nền tảng phát trực tuyến như Netflix. Sơ đồ chuyển
đổi trạng thái có thể hiển thị cách tài khoản của người dùng chuyển đổi giữa các
trạng thái như "đăng nhập", "duyệt web" và "xem nội dung" dựa trên tương tác của
người dùng. Bảng trạng thái có thể xác định thêm các điều kiện để chuyển đổi giữa
các trạng thái này. Bảng phản hồi sự kiện có thể chỉ định cách hệ thống phản hồi
khi người dùng cố gắng phát video ở các trạng thái khác nhau, chẳng hạn như khi
người dùng đăng xuất hoặc có video bị tạm dừng trong hàng đợi của họ.
d. Logic phức tạp
Logic phức tạp thường phát sinh trong quá trình phát triển hệ thống, đòi hỏi các
kỹ thuật hiệu quả để thể hiện các quá trình ra quyết định phức tạp.
- Cây quyết định: Cây quyết định cung cấp sự trình bày trực quan về các kết
quả có thể xảy ra do một loạt các quyết định hoặc điều kiện liên quan. Trong hệ
thống đề xuất, cây quyết định có thể minh họa cách hệ thống chọn nội dung để đề
xuất cho người dùng dựa trên các yếu tố như lịch sử xem và sở thích của họ.
- Bảng quyết định: Bảng quyết định xác định các yêu cầu chức năng duy
nhất liên quan đến sự kết hợp khác nhau giữa kết quả đúng và sai cho một loạt quyết
định hoặc điều kiện. Trong hệ thống hậu cần, bảng quyết định có thể chỉ định cách
lựa chọn các tùy chọn vận chuyển khác nhau dựa trên các yếu tố như kích thước gói
hàng, tốc độ giao hàng và hạn chế về chi phí.
Ví dụ: Hãy xem xét một trang web thương mại điện tử cung cấp các đề xuất
sản phẩm được cá nhân hóa. Cây quyết định có thể hiển thị cách hệ thống quyết
định có đề xuất sản phẩm hay không dựa trên các yếu tố như sở thích của người
dùng, lịch sử mua hàng và lượng hàng tồn kho có sẵn. Sau đó, bảng quyết định có
thể trình bày chi tiết các đề xuất cụ thể để hiển thị cho các kết hợp khác nhau của
các yếu tố này, đảm bảo trải nghiệm mua sắm phù hợp cho người dùng.
g. Giao diện người dùng
Giao diện người dùng (UI) là một khía cạnh quan trọng trong quá trình phát
triển hệ thống vì chúng ảnh hưởng trực tiếp đến trải nghiệm người dùng. Việc thể
hiện hiệu quả các thành phần và tương tác trên giao diện người dùng là điều cần
thiết.
 - User stories: User stories cung cấp chế độ xem cấp cao về giao diện người
dùng thực tế hoặc được đề xuất, minh họa các thành phần hiển thị khác nhau và các
đường dẫn điều hướng có thể có giữa chúng. Trong thiết kế ứng dụng dành cho thiết
bị di động, user stories có thể phác thảo các màn hình chính và luồng tương tác giữa
chúng, bao gồm các hành động như đăng ký và đăng nhập.
- Bảng phân cảnh và nguyên mẫu có độ chân thực thấp: Bảng phân cảnh
và nguyên mẫu có độ chân thực thấp cung cấp chế độ xem chi tiết hơn về giao diện
người dùng bằng cách hiển thị nội dung mỗi màn hình sẽ chứa mà không mô tả chi
tiết chính xác. Chúng có giá trị trong việc tinh chỉnh trải nghiệm người dùng trước
khi đầu tư vào các thiết kế có độ chân thực cao. Đối với nền tảng học tập điện tử,
bảng phân cảnh có thể phác thảo bố cục của trang bài học, bao gồm văn bản, hình
ảnh và các yếu tố tương tác.
- Mô hình hiển thị-hành động-phản hồi: Các mô hình này mô tả các yêu
cầu về hiển thị và hành vi của từng màn hình trong giao diện người dùng. Trong quá
trình phát triển nền tảng truyền thông xã hội, mô hình phản hồi hành động hiển thị
có thể chỉ định cách trang hồ sơ người dùng hiển thị thông tin, phản hồi các tương
tác như nhấp vào ảnh và kích hoạt các hành động như gửi yêu cầu kết bạn.
- Bố cục màn hình chi tiết và Nguyên mẫu có độ trung thực cao: Để có
cái nhìn chi tiết về giao diện người dùng, bố cục màn hình chi tiết và nguyên mẫu
có độ trung thực cao hiển thị chính xác các thành phần hiển thị sẽ trông như thế nào.
Khi tạo ứng dụng email khách dựa trên web, bố cục màn hình chi tiết sẽ xác định
cách sắp xếp các thành phần như hộp thư đến, thành phần email và xem trước thư.
Ngoài ra, định nghĩa trường dữ liệu và mô tả kiểm soát giao diện người dùng
cung cấp thêm chi tiết, đảm bảo rằng các thành phần giao diện người dùng được xác
định chính xác và phù hợp với mong đợi của người dùng.
Ví dụ: Hãy khám phá sự phát triển của ứng dụng chia sẻ chuyến đi. Bản đồ
hộp thoại sẽ phác thảo các màn hình chính, bao gồm màn hình chính, màn hình yêu
cầu chuyến đi và màn hình thanh toán, làm nổi bật các tương tác có thể có của người
dùng. Các nguyên mẫu có độ chính xác thấp có thể cung cấp bản phác thảo của
những màn hình này, phác thảo vị trí của các nút và văn bản. Mô hình phản hồi hành
động hiển thị sẽ chỉ định cách ứng dụng sẽ phản hồi khi người dùng yêu cầu chuyến
đi hoặc hủy đặt chỗ, đảm bảo trải nghiệm người dùng liền mạch.
h. Mô tả tác vụ của người dùng
Hiểu nhiệm vụ của người dùng là nền tảng để phát triển hệ thống đáp ứng
nhu cầu của người dùng. Có thể sử dụng nhiều kỹ thuật biểu diễn khác nhau để mô
tả các nhiệm vụ này một cách hiệu quả.
 - User stories: User stories cung cấp các mô tả ngắn gọn về nhiệm vụ của
người dùng, thường ở dạng tường thuật ngắn. Trong quá trình phát triển công cụ
quản lý dự án, user stories có thể nêu: "Là người quản lý dự án, tôi muốn tạo và
phân công nhiệm vụ cho các thành viên trong nhóm để tôi có thể theo dõi tiến độ
dự án."
- Scenarios: Scenarios cung cấp tường thuật chi tiết hơn về tương tác của
người dùng với hệ thống, cung cấp bối cảnh và tài khoản từng bước của các nhiệm
vụ. Trong nền tảng thương mại điện tử, một scenario có thể mô tả cách khách hàng
tìm kiếm sản phẩm, thêm sản phẩm vào giỏ hàng và hoàn tất mua hàng.
- Đặc tả use case: Đặc tả use case đi sâu vào chi tiết cụ thể về nhiệm vụ của
người dùng, phác thảo các điều kiện tiên quyết, các luồng chính và các luồng thay
thế. Đối với ứng dụng ngân hàng, đặc tả use case có thể trình bày chi tiết các bước
liên quan đến việc chuyển tiền giữa các tài khoản, bao gồm cả các tình huống xử lý
lỗi.
- Biểu đồ Swimlane: Như đã mô tả trước đó, biểu đồ swimlane cũng có hiệu
quả trong việc minh họa sự tương tác giữa nhiều tác nhân và hệ thống trong các tác
vụ của người dùng. Chúng cung cấp sự trình bày trực quan về quá trình thực hiện
nhiệm vụ, làm rõ ai chịu trách nhiệm cho từng bước. Trong quá trình phát triển hệ
thống yêu cầu hỗ trợ khách hàng, biểu đồ swimlane sẽ cho thấy cách các đại lý hỗ
trợ và phản hồi tự động xử lý các yêu cầu của khách hàng.
- Yêu cầu chức năng: Yêu cầu chức năng đưa ra mô tả chi tiết về cách hệ
thống và người dùng sẽ tương tác để đạt được kết quả có giá trị. Ví dụ: trong quá
trình phát triển nền tảng cộng tác tài liệu, một yêu cầu chức năng có thể chỉ định
rằng người dùng có thể nhận xét về các phần cụ thể của tài liệu và giải quyết các
nhận xét.
- Test cases: Test cases cung cấp một cái nhìn thay thế, ít trừu tượng hơn về
các tác vụ của người dùng bằng cách mô tả chính xác hành vi hệ thống mong đợi
trong các điều kiện cụ thể về đầu vào, trạng thái hệ thống và hành động. Trong giai
đoạn thử nghiệm của phần mềm quản lý dự án, một test case có thể phác thảo các
bước để xác minh rằng một nhiệm vụ dự án có thể được giao cho nhiều thành viên
trong nhóm mà không gặp lỗi.
Ví dụ: Hãy xem xét việc phát triển hệ thống bán vé hỗ trợ khách hàng. Câu
chuyện của người dùng có thể nêu rõ: "Là khách hàng, tôi muốn gửi phiếu hỗ trợ để
có thể yêu cầu hỗ trợ về vấn đề sản phẩm." Một scenario có thể cung cấp tài khoản
chi tiết về cách khách hàng điền vào biểu mẫu phiếu hỗ trợ, đính kèm các tệp liên
quan và gửi yêu cầu. Đặc tả use case sẽ phác thảo thêm các bước liên quan, bao gồm
cách hệ thống chỉ định phiếu cho nhân viên hỗ trợ. Biểu đồ swimlane có thể trực
 quan hóa toàn bộ quá trình, hiển thị các tương tác giữa khách hàng, nhân viên hỗ
trợ và hệ thống.
i. Yêu cầu phi chức năng (Thuộc tính chất lượng, ràng buộc)
Các yêu cầu phi chức năng, bao gồm các thuộc tính chất lượng và các ràng
buộc, thường bị bỏ qua nhưng lại rất quan trọng đối với sự thành công của hệ thống.
Những yêu cầu này xác định các đặc tính về hiệu suất, bảo mật và vận hành của hệ
thống.
- Thuộc tính chất lượng: Các thuộc tính chất lượng, chẳng hạn như hiệu
suất, độ tin cậy và khả năng sử dụng, thường được viết bằng văn bản ngôn ngữ tự
nhiên. Tuy nhiên, điều cần thiết là phải đảm bảo độ chính xác và đầy đủ khi mô tả
các thuộc tính này. Ví dụ: trong quá trình phát triển dịch vụ lưu trữ dựa trên đám
mây, thuộc tính chất lượng có thể chỉ định rằng hệ thống phải hỗ trợ tải tệp lên tới
100 MB với thời gian tải lên dưới 10 giây.
- Ràng buộc: Ràng buộc nêu ra những hạn chế hoặc hạn chế mà hệ thống
phải tuân thủ. Những điều này có thể bao gồm việc tuân thủ quy định, hạn chế về
ngân sách hoặc yêu cầu về khả năng tương thích. Trong thiết kế hệ thống thông tin
chăm sóc sức khỏe, một ràng buộc có thể chỉ định rằng hệ thống phải tuân thủ các
quy định của Đạo luật về trách nhiệm giải trình và cung cấp thông tin bảo hiểm y tế
(HIPAA) để bảo vệ dữ liệu bệnh nhân.
Điều đáng lưu ý là có thể sử dụng một kỹ thuật dứt khoát gọi là Plingu để
xác định chính xác các yêu cầu phi chức năng, đảm bảo rằng chúng được xác định
rõ ràng và có thể đo lường được.
Ví dụ: Hãy khám phá sự phát triển của nền tảng giao dịch chứng khoán thời
gian thực. Thuộc tính chất lượng sẽ bao gồm các yêu cầu về hiệu suất, nêu rõ rằng
hệ thống phải cung cấp thông tin cập nhật giá cổ phiếu theo thời gian thực với độ
trễ dưới một giây. Yêu cầu về độ tin cậy có thể chỉ định rằng hệ thống phải có
thờigian hoạt động 99,99%. Các ràng buộc có thể bao gồm các yêu cầu pháp lý,
chẳng hạn như tuân thủ các quy định của ngành tài chính về bảo mật dữ liệu và xác
thực khách hàng.
7. Trình bày ngắn gọn 14 biểu đồ UML (refer to https://www.uml-diagrams.org/uml-
25-diagrams.html). Biểu đồ UML nào thích hợp cho mô hình yêu cầu phần mềm.
Trả lời:
a. 14 biểu đồ UML
- Structure diagrams
Sơ đồ cấu trúc hiển thị cấu trúc tĩnh của hệ thống và các bộ phận của nó ở
các mức độ trừu tượng và triển khai khác nhau cũng như cách các bộ phận đó liên
 quan với nhau. Các thành phần trong sơ đồ cấu trúc thể hiện các khái niệm có ý
nghĩa của một hệ thống và có thể bao gồm các khái niệm trừu tượng, thế giới thực
và triển khai.
Sơ đồ cấu trúc không sử dụng các khái niệm liên quan đến thời gian, không
hiển thị chi tiết về hành vi động. Tuy nhiên, chúng có thể thể hiện mối quan hệ với
hành vi của các bộ phân loại được trình bày trong sơ đồ cấu trúc

Diagram Mục đích Yếu tố

Class diagram Hiển thị cấu trúc của hệ thống, hệ thống con hoặc thành class, interface,
phần được thiết kế dưới dạng các lớp và giao diện liên feature,
quan, vớicác tính năng, ràng buộc và mối quan hệcủa constraint,
chúng - liên kết, khái quát hóa, phụ thuộc, v.v. association,
generalization,
dependency
Object Biểu đồ của các đối tượng, bao gồm các đối tượng và instance
diagram giá trị dữ liệu. Sơ đồ đối tượng tĩnh là một thể hiện của specification,
sơ đồ lớp; nó hiển thị ảnh chụp nhanh về trạng thái chi object, slot,
tiết của hệ thống tại một thời điểm. Nócũng tuyên bố link.
rằng sơ đồ đối tượng là "sơđồ lớp có đối tượng và
không có lớp.
Package Hiển thị package và mối quan hệ giữa các package. package,
diagram packageable
element,
dependency,
element import,
package import,
package merge.
Model Sơ đồ cấu trúc phụ trợ UML là một loại sơ đồ được sử model,
diagram dụng để mô tả các khía cạnh kiến trúc, logic hoặc hành package,
vi của một hệ thống một cách trừu tượng hoặc cụ thể. packageabe
Nó có thể hiển thị ví dụ như kiến trúc của một ứng element,
dụng đa tầng (còn được gọi là ứng dụng đa tầng) - xem dependency
mô hình ứng dụng đa tầng.
Composite Có thể dùng sơ đồ để biểu diễn:
structure • Cấu trúc bên trong của một bộ phân loại
diagram • Hành vi hợp tác
Internal Hiển thị cấu trúc nội bộ của một bộ phân loại - một structured class,
structure phân tách của bộ phân loại thành các thuộc tính, phần part, port,
diagram tử và mối quan hệ của nó. connector,
usage.
Collaboration Hiển thị các đối tượng trong hệ thống hợp tác với nhau collaboration,
use diagram để tạo ra một hành vi của hệ thống. connector, part,
dependency.
Component Hiển thị các thành phần và sự phụ thuộc giữa chúng. component,
diagram Loại sơ đồ này được sử dụng cho Phát triển dựa trên interface,
thành phần ( CBD), để mô tả các hệ thống có Kiến provided,
trúchướng dịch vụ ( SOA ).. interface,
required,
interface,
class,port,
connector,
artifact,
Manifestation Mặc dù sơ đồ thành phần (component diagrams) hiển manifestation,
diagram thị các thành phần và mối quan hệ giữa chúng và các component,
bộ phân loại, và sơ đồ triển khai (deployment artifact.
diagrams) - việc triển khai các artifacts đến các mục
tiêu triển khai, tuy nhiên, có một sơ đồ trung gian bị
thiếu, đó là sơ đồ biểu hiện (manifestation diagram)
được sử dụng để hiển thị sự biểu hiện (thực thi) của
các thành phần bằng các artifacts và cấu trúc nội bộ
của các artifacts.
Bởi vì sơ đồ biểu hiện không được định nghĩa trong
thông lệ UML 2.5, việc hiển thị sự biểu hiện của các
thành phần bằng các artifacts có thể được thực hiện
bằng cách sử dụng sơ đồ thành phần hoặc sơ đồ triển
khai.
Deployment Hiển thị kiến trúc của hệ thống dưới dạng triển deployment,
diagram khai (phân phối) các tạo phẩm phần mềm cho các mục artifact,
tiêu triển khai. deployment
Lưu ý rằng các thành phần đó đã được triển khai trực target, node,
tiếp tới các nút trong sơ đồ triển khai UML 1.x. Trong device,
UML 2.x, các tạo phẩm được triển khai tới các nút và execution
các tạo phẩm có thể biểu hiện (triển khai) các thành environment,
phần. Các thành phần được triển khai gián tiếp đến các communicatin
nút thông qua các tạo phẩm. path,
Sơ đồ triển khai mức đặc tả (còn gọi là cấp loại) deployment
hiển thị một số tổng quan về việc triển khai các tạo specification,
phẩm cho các mục tiêu triển khai mà không tham chiếu
đến các phiên bản cụ thể của các tạo phẩm hoặc nút.
Sơ đồ triển khai cấp phiên bản hiển thị việc triển
khai các phiên bản của thành phần lạ cho các phiên bản
cụ thể của mục tiêu triển khai. Ví dụ: nó có thể được
sử dụng để hiển thị sự khác biệt trong việc triển khai
 tới môi trường phát triển, dàn dựng hoặc sản xuất với
tên/id của máy chủ hoặc thiết bị xây dựng hoặc triển
khai cụ thể.
Network Sơ đồ triển khai có thể được sử dụng để hiển thị kiến node, switch,
architecture trúc mạng logic hoặc vật lý của hệ thống. Loại sơ đồ router, load
diagram triển khai như vậy - không được định nghĩa chính thức balancer,
trong UML 2.5 - có thể được gọi là sơ đồ kiến trúc firewall,
mạng (network architecture diagrams) communicatin
path, network
segment,
backbone.
Profile Sơ đồ UML phụ trợ cho phép định nghĩa các phép ảnh profile,
diagram tùy chỉnh, các giá trị được gắn thẻ, và các ràng buộc metaclass,
như một cơ chế mở rộng nhẹ cho tiêu chuẩn UML. stereotype,
Profiles (hồ sơ) cho phép điều chỉnh mô hình UML cho extension,
các nền tảng khác nhau (như J2EE hoặc .NET), hoặc reference,
các lĩnh vực (như mô hình thời gian thực hoặc quy profile
trình kinh doanh). Sơ đồ Profile được giới thiệu lần đầu application.
trong UML 2.0.

- Behavior Diagrams
Sơ đồ hành vi cho thấy hành vi động của các đối tượng trong hệ thống, có thể
được mô tả như một chuỗi các thay đổi đối với hệ thống theo thời gian.
Diagram Mục đích Yếu tố
Use case Mô tả một tập hợp các hành động (trường hợp sử use case,
diagram dụng) mà một số hệ thống hoặc các hệ thống (chủ thể) actor,
nên hoặc có thể thực hiện cùng với một hoặc nhiều subject,
người dùng bên ngoài của hệ thống (tác nhân) để cung extend,
cấp một số kết quả có giá trị và có thể quan sát được include,
cho các tác nhân hoặc các bên liên quan khác của hệ association.
thống.
Activity Hiển thị trình tự và điều kiện để phối hợp các hành vi activity,
diagram cấp thấp hơn, thay vì trình phân loại nào sở hữu các partition,
hành vi đó. Chúng thường được gọi là mô hình luồng action,
điều khiển và luồng đối tượng object,
control,
activity edge.
State machine Được sử dụng để mô hình hóa hành vi rời rạc thông
diagram qua chuyển đổi trạng thái hữu hạn. Ngoài việc thể
hiện hành vi của một phần hệ thống, máy trạng thái
còn có thể được sử dụng để thể hiện giao thức sử dụng
của một phần hệ thống. Hai loại máy trạng thái này
 được gọi là máy trạng thái hành vi và máy trạng thái
giao thức.
Interaction Sơ đồ tương tác bao gồm một số loại sơ đồ khác nhau:
diagram • Sơ đồ trình tự
• Sơ đồ giao tiếp (được gọi là sơ đồ cộng tác trong
UML 1.x),
• Sơ đồ thời gian
• Sơ đồ tổng quan về tương tác
Sequence Loại sơ đồ tương tác phổ biến nhất tập trung vào việc lifeline,
diagram trao đổi thông điệp giữa các dây cứu sinh (đối tượng). execution
specification,
message,
combined
fragment,
interaction
use, state
invariant,
destruction
occurrence.
Communication Tập trung vào sự tương tác giữa các dây cứu sinh lifeline,
diagram trong đó kiến trúc của cấu trúc bên trong và cách thức message.
này tương ứng với việc truyền thông điệp là trọng
tâm. Trình tự của các thông điệp được đưa ra thông
qua sơ đồ đánh số thứ tự.
Timing Hiển thị các tương tác khi mục đích chính của sơ đồ lifeline, state
diagram là lý giải về thời gian. Biểu đồ thời gian tập trung vào or condition
các điều kiện thay đổi bên trong và giữa các đường timeline,
dây cứu sinh dọc theo trục thời gian tuyến tính. destruction
event,
duration
constraint,
time
constraint.
Interaction Xác định các tương tác thông qua một biến thể của sơ initial node,
overview đồ hoạt động theo cách thúc đẩy tổng quan về luồng flow final
diagram điều khiển. Sơ đồ tổng quan về tương tác tập trung node, activity
vào tổng quan về luồng điều khiển trong đó các nút là final node,
tương tác hoặc sử dụng tương tác. Dây cứu sinh và decision
thông báo không xuất hiện ở cấp độ tổng quan này. node, merge
node, fork
node, join
node,
interaction,
 interaction
use, duration
constraint,
time
constraint.

b. Biểu đồ UML thích hợp cho mô hình yêu cầu phần mềm
Mức độ trừu tượng phù hợp cho việc phân tích yêu cầu, một số mô hình:
 Class diagrams, để hiển thị các lớp đối tượng liên quan đến miền ứng
dụng; của họ thuộc tính, hành vi và thuộc tính; và mối quan hệ giữa các lớp, cũng
có thể được sử dụng để mô hình hóa dữ liệu, nhưng ứng dụng hạn chế này không
khai thác đầy đủ các khả năng ngữ nghĩa của sơ đồ lớp.
 Usecase diagrams, tmối quan hệ giữa các tác nhân bên ngoài hệ thống
và các trường hợp sử dụng mà chúng tương tác.
 Activitydiagrams, để chỉ ra cách các dòng khác nhau đan xen trong
một ca sử dụng hoặc vai trò nào thực hiện một số hành động nhất định như trong sơ
đồ làn đường bơi hoặc để mô hình hóa dòng chảy của quy trình kinh doanh.
 State diagram, để thể hiện các trạng thái khác nhau mà một hệ thống
hoặc đối tượng dữ liệu có thể đảm nhận và các chuyển đổi được phép giữa các trạng
thái.
8. Trình bày các đặc trưng phi chức năng hay thuộc tính chất lượng phần mềm.
Trả lời:
a. Thuộc tính chất lượng phần mềm
Vài chục đặc điểm của sản phẩm có thể được gọi là thuộc tính chất lượng,
mặc dù hầu hết các nhóm dự án đều chỉ cần xem xét cẩn thận một số ít trong số họ.
Nếu nhà phát triển biết đặc điểm nào trong số này quan trọng nhất để thành công,
họ có thể lựa chọn các phương pháp thiết kế và xây dựng phù hợp để đạt được mục
tiêu chất lượng. Các thuộc tính chất lượng được phân loại theo nhiều tiêu chí khác
nhau các sơ đồ. Một số tác giả đã xây dựng hệ thống phân cấp rộng rãi để nhóm các
thuộc tính liên quan thành một số loại chính.
Một cách để phân loại các thuộc tính chất lượng là phân biệt những đặc điểm
có thể thấy rõ thông qua việc thực thi phần mềm (chất lượng bên ngoài) với những
đặc điểm không có (chất lượng bên trong). Các yếu tố chất lượng bên ngoài chủ yếu
quan trọng đối với người dùng, trong khi chất lượng bên trong lại quan trọng hơn
đối với nhân viên phát triển và bảo trì. Các thuộc tính chất lượng bên trong góp phần
gián tiếp vào sự hài lòng của khách hàng bằng cách làm cho sản phẩm dễ dàng nâng
cao, sửa chữa, thử nghiệm và di chuyển sang nền tảng mới.
Một số khía cạnh bên trong và bên ngoài của chất lượng mà mọi dự án nên
xem xét.
- Chất lượng bên ngoài (External quality):
 Tính sẵn có (Availability): Mức độ các dịch vụ của hệ thống có
sẵn khi nào và ở đâu cần thiết.
 Tính cài đặt được (Installability): Việc cài đặt, gỡ cài đặt và cài đặt
lại ứng dụng một cách chính xác.
 Tính toàn vẹn (Integrity): Mức độ mà hệ thống bảo vệ chống lại
sự thiếu chính xác và mất mát dữ liệu.
 Tính tương tác (Interoperability): Hệ thống có thể kết nối và trao
đổi dữ liệu với các hệ thống hoặc thành phần khác dễ dàng như thế
nào.
 Hiệu suất (Performance): Hệ thống phản hồi nhanh chóng và có
thể dự đoán được như thế nào với thông tin đầu vào của người
dùng hoặc các sự kiện khác.
 Độ tin cậy (Reliability): Hệ thống chạy được bao lâu trước khi gặp
lỗi.
 Độ chắc chắn (Robustness): Hệ thống phản ứng tốt như thế nào
với các điều kiện vận hành không mong muốn.
 Tính an toàn (Safety): Hệ thống bảo vệ khỏi thương tích hoặc hư
hỏng tốt đến mức nào.
 Tính bảo mật (Security): Hệ thống bảo vệ chống truy cập trái phép
vào ứng dụng và dữ liệu của nó tốt đến mức nào.
 Tính khả dụng (Usability): Mọi người có thể học, ghi nhớ và sử
dụng hệ thống dễ dàng như thế nào.
- Chất lượng bên trong (Internal quality):
 Tính hiệu quả (Efficiency): Hệ thống sử dụng tài nguyên máy
tính hiệu quả như thế nào.
 Tính sửa đổi được (Modifiability): Việc duy trì, thay đổi, nâng
cao và cơ cấu lại hệ thống dễ dàng như thế nào.
 Tính di động (Portability): Hệ thống có thể được thực hiện dễ
dàng như thế nào để hoạt động trong các môi trường điều hành
khác.
 Tính tái sử dụng (Reusability): Các thành phần có thể được sử
dụng ở mức độ nào trong các hệ thống khác.
 Tính mở rộng (Scalability): Hệ thống có thể phát triển dễ dàng
như thế nào để xử lý nhiều người dùng, giao dịch, máy chủ
hoặc tiện ích mở rộng khác hơn.
 Tính kiểm chứng được (Verifiability): Các nhà phát triển và
người thử nghiệm có thể dễ dàng xác nhận rằng phần mềm đã
được triển khai chính xác như thế nào.
 Một số thuộc tính có tầm quan trọng đặc biệt đối với một số loại dự án:
- Hệ thống nhúng: hiệu suất, hiệu quả, độ tin cậy, độ bền, an toàn, bảo mật,
khả năng sử dụng.
- Internet và các ứng dụng của công ty: tính sẵn sàng, tính toàn vẹn, khả
năng tương tác, hiệu suất, khả năng mở rộng, bảo mật, khả năng sử dụng.
- Hệ thống máy tính để bàn và thiết bị di động: hiệu suất, bảo mật, khả
năng sử dụng.
Ngoài ra, các phần khác nhau của hệ thống có thể cần nhấn mạnh các thuộc
tính chất lượng khác nhau. Hiệu suất có thể rất quan trọng đối với một số thành phần
nhất định, trong khi khả năng sử dụng là tối quan trọng đối với những thành phần
khác. Môi trường của bạn có thể có các thuộc tính chất lượng độc đáo khác không
được đề cập ở đây. Ví dụ: các công ty trò chơi có thể muốn nắm bắt các yêu cầu về
mặt cảm xúc cho phần mềm của họ (Callele, Neufeld và Schneider 2008).
b. Khám phá các thuộc tính chất lượng
Trong một vũ trụ lý tưởng, mọi hệ thống sẽ thể hiện giá trị tối đa có thể có
cho tất cả các thuộc tính của nó. Hệ thống sẽ luôn sẵn sàng, không bao giờ bị lỗi, sẽ
cung cấp kết quả tức thời luôn chính xác, sẽ chặn mọi nỗ lực truy cập trái phép và
sẽ không bao giờ gây nhầm lẫn cho người dùng. Trên thực tế, có sự đánh đổi và
xung đột giữa các thuộc tính nhất định khiến cho việc tối đa hóa tất cả chúng cùng
một lúc là không thể.
Các dự án khác nhau sẽ yêu cầu các tập hợp thuộc tính chất lượng khác nhau
để thành công. Jim Brosseau (2010) đề xuất cách tiếp cận thực tế sau đây để xác
định và chỉ định các thuộc tính quan trọng nhất cho dự án của bạn.
- Bước 1: Bắt đầu với phân loại tổng quát (Start with a broad taxonomy)
- Bước 2: Giảm danh sách (Reduce the list)
- Bước 3: Ưu tiên các thuộc tính (Prioritize the attributes)
- Bước 4: Đưa ra những kỳ vọng cụ thể cho từng thuộc tính (Elicit
specific expectations for each attribute)
- Bước 5: Xác định các yêu cầu chất lượng có cấu trúc rõ ràng (Specify
well-structured quality requirements)
c. Xác định yêu cầu chất lượng
- Thuộc tính chất lượng bên ngoài (External quality attributes): Thuộc
tính chất lượng bên ngoài mô tả các đặc điểm được quan sát thấy khi phần mềm
đang thực thi. Chúng ảnh hưởng sâu sắc đến trải nghiệm người dùng và nhận thức
của người dùng về chất lượng hệ thống
 Tính sẵn có (Availability): Tính sẵn có là thước đo thời gian
hoạt động theo kế hoạch trong đó các dịch vụ của hệ thống có sẵn cho sử dụng và
vận hành đầy đủ. Về mặt hình thức, tính khả dụng bằng tỷ lệ thời gian hoạt động
trên tổng thời gian hoạt động và thời gian xuống. Còn chính thức hơn, tính khả dụng
bằng với thời gian trung bình giữa các lần hỏng hóc (MTBF) của hệ thống chia cho
tổng MTBF và thời gian sửa chữa trung bình (MTTR) của hệ thống sau khi xảy ra
lỗi đang gặp phải. Thời gian bảo trì theo lịch trình cũng ảnh hưởng đến tính khả
dụng. Sự sẵn có có liên quan chặt chẽ với độ tin cậy và bị ảnh hưởng mạnh mẽ bởi
tiểu thể loại khả năng bảo trì của khả năng sửa đổi
 Tính cài đặt được (Installability): Phần mềm không hữu ích
cho đến khi nó được cài đặt trên thiết bị hoặc nền tảng thích hợp. Một số ví dụ về
cài đặt phần mềm là: tải ứng dụng về điện thoại hoặc máy tính bảng; chuyển phần
mềm từ PC sang máy tính máy chủ web; cập nhật hệ điều hành; cài đặt một hệ thống
thương mại lớn, chẳng hạn như một doanh nghiệp công cụ hoạch định nguồn lực;
tải xuống bản cập nhật chương trình cơ sở vào hộp giải mã truyền hình cáp; và cài
đặt một ứng dụng của người dùng cuối trên PC. Khả năng cài đặt mô tả mức độ dễ
dàng thực hiện các thao tác này một cách chính xác. Việc tăng khả năng cài đặt của
hệ thống giúp giảm thời gian, chi phí, sự gián đoạn của người dùng, tần suất lỗi, và
trình độ kỹ năng cần thiết cho hoạt động cài đặt. Khả năng cài đặt giải quyết các
hoạt động sau:
 Cài đặt ban đầu
 Khôi phục sau quá trình cài đặt không đầy đủ, không chính
xác hoặc do người dùng hủy bỏ
 Cài đặt lại phiên bản tương tự
 Cài đặt phiên bản mới
 Hoàn nguyên về phiên bản trước
 Cài đặt các thành phần hoặc bản cập nhật bổ sung
 Gỡ cài đặt.
 Tính toàn vẹn (Integrity): Tính toàn vẹn liên quan đến việc
ngăn ngừa mất thông tin và duy trì tính chính xác của dữ liệu được nhập vào hệ
thống. Yêu cầu về tính toàn vẹn không có sai số: dữ liệu ở trạng thái tốt và được bảo
vệ, hoặc không. Dữ liệu cần được bảo vệ chống lại các mối đe dọa như mất mát vô
tình hoặc hỏng hóc, các bộ dữ liệu có vẻ giống hệt nhau nhưng không khớp, hư hỏng
vật lý đối với phương tiện lưu trữ, vô tình xóa tập tin hoặc ghi đè dữ liệu bởi người
dùng. Các cuộc tấn công có chủ ý cố tình Dữ liệu bị hỏng hoặc bị đánh cắp cũng là
một rủi ro. Bảo mật đôi khi được coi là một tập hợp con của tính toàn vẹn, bởi vì
một số yêu cầu bảo mật nhằm ngăn chặn việc người dùng trái phép truy cập vào dữ
liệu. Chính trực yêu cầu phải đảm bảo rằng dữ liệu nhận được từ các hệ thống khác
khớp với dữ liệu được gửi và ngược lại. Bản thân các phần mềm thực thi có thể bị
tấn công, do đó tính toàn vẹn của chúng cũng phải được đảm bảo được bảo vệ. Tính
toàn vẹn dữ liệu cũng đề cập đến tính chính xác và định dạng phù hợp của dữ liệu.
Cái này bao gồm các mối quan tâm như định dạng các trường cho ngày tháng, hạn
chế các trường ở loại dữ liệu chính xác hoặc độ dài, đảm bảo rằng các phần tử dữ
liệu có giá trị hợp lệ, kiểm tra mục nhập thích hợp trong một trường khi một trường
khác có một giá trị nhất định, v.v. Sau đây là một số yêu cầu về tính toàn vẹn mẫu
 Tính tương tác (Interoperability): Khả năng tương tác cho biết
hệ thống có thể trao đổi dữ liệu và dịch vụ với phần mềm khác dễ dàng như thế nào
hệ thống và mức độ dễ dàng tích hợp với các thiết bị phần cứng bên ngoài. Để đánh
giá khả năng tương tác, bạn cần biết những ứng dụng nào khác mà người dùng sẽ
sử dụng cùng với sản phẩm của bạn và dữ liệu nào họ mong đợi trao đổi. Người sử
dụng Hệ thống Theo dõi Hóa chất đã quen với để vẽ các cấu trúc hóa học bằng một
số công cụ thương mại, vì vậy họ đã trình bày những điều sau đây
 Hiệu suất (Performance): Hiệu suất là một trong những thuộc
tính chất lượng mà người dùng thường đưa ra một cách tự nhiên. Hiệu suất thể hiện
khả năng đáp ứng của hệ thống đối với các yêu cầu và hành động khác nhau của
người dùng. Hiệu suất kém gây khó chịu cho người dùng đang chờ truy vấn hiển thị
kết quả. Nhưng các vấn đề về hiệu suất cũng có thể gây ra những rủi ro nghiêm
trọng đối với an toàn, chẳng hạn như khi một quy trình thời gian thực hệ thống điều
khiển bị quá tải. Yêu cầu nghiêm ngặt về hiệu năng ảnh hưởng mạnh mẽ đến thiết
kế phần mềm chiến lược và lựa chọn phần cứng, từ đó xác định mục tiêu hiệu suất
phù hợp với hoạt động
 Độ tin cậy (Reliability): Xác suất để phần mềm thực thi không
bị lỗi trong một khoảng thời gian cụ thể đã được biết như độ tin cậy. Các vấn đề về
độ tin cậy có thể xảy ra do đầu vào không đúng, sai sót trong bản thân mã phần
mềm, các thành phần không có sẵn khi cần và lỗi phần cứng. Sự mạnh mẽ và tính
sẵn sàng có liên quan chặt chẽ đến độ tin cậy. Các cách xác định và đo lường phần
mềm độ tin cậy bao gồm tỷ lệ phần trăm các hoạt động được hoàn thành chính xác,
độ dài trung bình thời gian hệ thống chạy trước khi bị lỗi (thời gian trung bình giữa
các lần lỗi hoặc MTBF) và thời gian tối đa xác suất xảy ra sự cố có thể chấp nhận
được trong một khoảng thời gian nhất định. Thiết lập độ tin cậy định lượng yêu cầu
dựa trên mức độ ảnh hưởng nghiêm trọng nếu xảy ra lỗi và liệu chi phí tối đa hóa
độ tin cậy là hợp lý. Các hệ thống yêu cầu độ tin cậy cao cũng cần được thiết kế cho
khả năng xác minh cao để giúp dễ dàng tìm ra các khiếm khuyết có thể ảnh hưởng
đến độ tin cậy.
 Độ chắc chắn (Robustness): Tính chắc chắn là mức độ mà hệ
thống tiếp tục hoạt động bình thường khi gặp phải đầu vào không hợp lệ, lỗi trong
các thành phần phần cứng hoặc phần mềm được kết nối, sự tấn công từ bên ngoài
hoặc các điều kiện hoạt động không mong muốn. Phần mềm mạnh mẽ phục hồi một
cách khéo léo sau các tình huống có vấn đề và tha thứ cho những sai sót của người
dùng. Nó phục hồi sau các lỗi nội bộ mà không ảnh hưởng xấu đến trải nghiệm của
người dùng cuối. Lỗi phần mềm được xử lý theo cách mà người dùng cho là hợp lý,
không gây khó chịu.
  Tính an toàn (Safety): Yêu cầu an toàn giải quyết nhu cầu ngăn
chặn hệ thống gây thương tích cho con người hoặc thiệt hại về tài sản. Yêu cầu an
toàn có thể được quyết định bởi các quy định của chính phủ hoặc các quy tắc kinh
doanh khác và các vấn đề pháp lý hoặc chứng nhận có thể liên quan đến với việc
đáp ứng những yêu cầu đó. Yêu cầu an toàn thường được viết dưới dạng điều kiện
hoặc hành động mà hệ thống không được phép xảy ra.
 Tính bảo mật (Security): Bảo mật liên quan đến việc chặn truy
cập trái phép vào các chức năng hoặc dữ liệu của hệ thống, đảm bảo rằng phần mềm
được bảo vệ khỏi các cuộc tấn công của phần mềm độc hại, v.v. Bảo mật là vấn đề
lớn với Internet phần mềm. Người dùng hệ thống thương mại điện tử muốn thông
tin thẻ tín dụng của họ được bảo mật. Web người lướt sóng không muốn thông tin
cá nhân hoặc hồ sơ về các trang web họ truy cập bị sử dụng không thích hợp. Các
công ty muốn bảo vệ trang web của họ khỏi các cuộc tấn công từ chối dịch vụ hoặc
hack. Như với yêu cầu về tính toàn vẹn, yêu cầu về bảo mật không có khả năng chấp
nhận lỗi. Sau đây là một số những cân nhắc cần kiểm tra khi đưa ra các yêu cầu bảo
mật
 Tính khả dụng (Usability): cân bằng khả năng sử dụng tối ưu
cho toàn bộ đối tượng người dùng chứ không chỉ cho một cộng đồng duy nhất. Điều
này có thể có nghĩa là một số người dùng nhất định không hài lòng với kết quả như
họ mong muốn. Người dùng các tùy chọn tùy chỉnh có thể mở rộng sức hấp dẫn của
ứng dụng.
- Thuộc tính chất lượng bên trong (Internal quality attributes)
 Tính hiệu quả (Efficiency): Hiệu quả có liên quan chặt chẽ với
thuộc tính chất lượng bên ngoài là hiệu suất. Hiệu quả là thước đo của hệ thống sử
dụng dung lượng bộ xử lý, dung lượng ổ đĩa, bộ nhớ hoặc băng thông liên lạc tốt
như thế nào. Nếu như một hệ thống tiêu tốn quá nhiều tài nguyên sẵn có, người dùng
sẽ gặp phải tình trạng hiệu suất bị suy giảm. Hiệu quả—và do đó là hiệu suất—là
yếu tố thúc đẩy trong kiến trúc hệ thống, ảnh hưởng đến cách thức một nhà thiết kế
chọn phân phối các tính toán và chức năng trên các thành phần hệ thống. Hiệu quả
yêu cầu có thể làm tổn hại đến việc đạt được các thuộc tính chất lượng khác. Xem
xét tối thiểu cấu hình phần cứng khi xác định mục tiêu hiệu quả, năng lực và hiệu
suất. Cho phép lợi nhuận kỹ thuật cho các điều kiện không lường trước được và sự
tăng trưởng trong tương lai (do đó ảnh hưởng đến khả năng mở rộng)
 Tính sửa đổi được (Modifiability): Tính sửa đổi được đề cập
đến việc các thiết kế và mã phần mềm có thể được hiểu, thay đổi, và mở rộng. Khả
năng sửa đổi bao gồm một số thuật ngữ thuộc tính chất lượng khác có liên quan đến
các hình thức bảo trì phần mềm khác nhau. Nó liên quan chặt chẽ đến khả năng
kiểm chứng. Nếu các nhà phát triển dự kiến thực hiện nhiều cải tiến, họ có thể chọn
các phương pháp thiết kế phù hợp tối đa hóa khả năng sửa đổi của phần mềm. Khả
năng sửa đổi cao là rất quan trọng đối với các hệ thống sẽ trải qua sửa đổi thường
xuyên, chẳng hạn như những bản sửa đổi được phát triển bằng cách sử dụng vòng
đời tăng dần hoặc lặp lại.
 Tính di động (Portability): Nỗ lực cần thiết để di chuyển phần
mềm từ môi trường hoạt động này sang môi trường hoạt động khác là thước đo khả
năng tính di động. Một số người thực hiện bao gồm khả năng quốc tế hóa và nội địa
hóa một sản phẩm theo tiêu đề của tính di động. Các phương pháp thiết kế làm cho
phần mềm có thể di chuyển được cũng tương tự như các phương pháp thiết kế làm
cho nó có thể tái sử dụng được. Tính di động ngày càng trở nên quan trọng vì các
ứng dụng phải chạy trên nhiều nền tảng các môi trường như Windows, Mac và
Linux; iOS và Android; và PC, máy tính bảng và điện thoại.
 Tính tái sử dụng (Reusability): Khả năng sử dụng lại cho biết
nỗ lực tương đối cần thiết để chuyển đổi một thành phần phần mềm để sử dụng cho
mục đích khác các ứng dụng. Phần mềm có thể tái sử dụng phải có tính mô-đun,
được ghi chép đầy đủ, độc lập với một phần mềm cụ thể ứng dụng và môi trường
hoạt động, và có phần chung chung về khả năng. Nhiều dự án các tạo phẩm cung
cấp tiềm năng tái sử dụng, bao gồm các yêu cầu, kiến trúc, thiết kế, mã, kiểm thử,
quy tắc kinh doanh, mô hình dữ liệu, mô tả lớp người dùng, hồ sơ các bên liên quan
và thuật ngữ thuật ngữ. Việc làm cho phần mềm có thể tái sử dụng được tạo điều
kiện thuận lợi bằng cách đặc tả các yêu cầu và thiết kế, tuân thủ nghiêm ngặt các
tiêu chuẩn mã hóa, duy trì bộ hồi quy các trường hợp thử nghiệm và một thư viện
tiêu chuẩn được duy trì gồm các thành phần có thể tái sử dụng.
 Tính mở rộng (Scalability): Yêu cầu về khả năng mở rộng đề
cập đến khả năng ứng dụng phát triển để đáp ứng nhiều người dùng hơn, dữ liệu,
máy chủ, vị trí địa lý, giao dịch, lưu lượng mạng, tìm kiếm và các dịch vụ khác mà
không cần ảnh hưởng đến hiệu suất hoặc tính chính xác. Khả năng mở rộng có ý
nghĩa cả về phần cứng và phần mềm. Mở rộng quy mô hệ thống có thể có nghĩa là
có được máy tính nhanh hơn, thêm bộ nhớ hoặc dung lượng ổ đĩa, thêm máy chủ,
cơ sở dữ liệu phản chiếu hoặc tăng dung lượng mạng. Các phương pháp tiếp cận
phần mềm có thể bao gồm phân phối tính toán lên nhiều bộ xử lý, nén dữ liệu, tối
ưu hóa thuật toán, và các kỹ thuật điều chỉnh hiệu suất khác. Khả năng mở rộng có
liên quan đến khả năng sửa đổi và độ bền, bởi vì một loại độ bền có liên quan đến
cách hệ thống hoạt động khi có giới hạn về công suất đã đạt tới hoặc vượt quá.
 Tính kiểm chứng được (Verifiability): Được gọi một cách hẹp
hơn là khả năng kiểm thử, khả năng kiểm chứng đề cập đến mức độ tốt của các
thành phần phần mềm hoặc sản phẩm tích hợp có thể được đánh giá để chứng minh
liệu hệ thống có hoạt động như mong đợi hay không. Thiết kế để có thể kiểm chứng
là rất quan trọng nếu sản phẩm có các thuật toán và logic phức tạp hoặc nếu nó chứa
mối quan hệ chức năng tinh tế. Khả năng xác minh cũng rất quan trọng nếu sản
phẩm sẽ được sửa đổi thường xuyên, bởi vì nó sẽ trải qua quá trình kiểm tra hồi quy
 thường xuyên để xác định xem những thay đổi làm hỏng bất kỳ chức năng hiện có
nào. Các hệ thống có khả năng kiểm chứng cao có thể được kiểm tra một cách hiệu
quả và một cách hiệu quả. Thiết kế phần mềm có khả năng kiểm chứng có nghĩa là
làm cho phần mềm dễ dàng được đưa vào hệ thống trạng thái mong muốn trước khi
thử nghiệm, để cung cấp dữ liệu thử nghiệm cần thiết và để quan sát kết quả thử
nghiệm
9. Khảo sát trên mạng 3 Hệ thống sau đây:
a. Hệ quản lý thư viện (Library Management System LibMaS)
b. Hệ thương mại điện tử e-commerce (E-commerce Management System EcoMaS)
c. Hệ đăng ký học theo tín chỉ ở trường Đại học (Register Management System
RegMaS).
A. Hệ quản lý thư viện (Library Management System LibMaS

1. Trình bày bằng ngôn ngữ tự nhiên và biểu đồ context cho hệ thống
a. Ngôn ngữ tự nhiên
- Mục đích: Hệ thống Quản lý Thư viện được phát triển với mục đích cung cấp
một nền tảng tổ chức, quản lý và cung cấp dịch vụ cho thư viện. Hệ thống
này giúp đảm bảo việc quản lý sách, tài liệu và thông tin liên quan được thực
hiện một cách hiệu quả và chính xác. Đồng thời, nó cung cấp một giao diện
tương tác dễ dàng giữa độc giả và thư viện, giúp họ tìm kiếm sách, thực hiện
mượn/trả sách và nhận thông báo quan trọng.
- Phạm vi hệ thống:
+ Thủ thư:
● Đăng nhập vào hệ thống với tư cách thủ thư.
● Quản lý danh mục sách và tài liệu.
● Thêm, sửa, xóa thông tin sách.
● Quản lý thông tin độc giả và lịch sử mượn/trả sách.
● Tạo phiếu mượn/trả sách.
+ Độc giả:
● Đăng nhập vào hệ thống với tư cách độc giả.
● Tìm kiếm thông tin sách.
● Mượn sách và tạo phiếu mượn.
● Trả sách và tạo phiếu trả.
+ Quản trị viên hệ thống:
● Đăng nhập vào hệ thống với quyền quản trị viên.
● Quản lý tài khoản người dùng và quyền truy cập.
● Thêm, sửa, xóa tài khoản độc giả và thủ thư.
● Xem các hoạt động của người dùng trong hệ thống.
- Hoạt động nghiệp vụ của các chức năng:
+ Tìm kiếm sách của độc giả: Độc giả đăng nhập vào tài khoản -> Chọn
"Tìm kiếm sách" từ menu -> Nhập thông tin tên sách, tác giả hoặc thể loại -
> Hệ thống hiển thị danh sách các sách phù hợp -> Độc giả chọn một cuốn
sách để xem thông tin chi tiết.
+ Mượn sách của độc giả: Độc giả truy cập vào tài khoản -> Chọn
"Mượn sách" từ menu -> Tìm kiếm sách theo tên hoặc mã số -> Chọn sách
cần mượn ->Hệ thống ghi nhận thông tin mượn sách và cập nhật số lượng
tồn.
+ Quản lý sách của thủ thư: Thủ thư đăng nhập vào tài khoản -> Chọn
"Quản lý sách" từ menu -> Thêm, sửa hoặc xóa thông tin sách -> Lưu thông
tin sách sau khi chỉnh sửa.
+ Quản lý độc giả của thủ thư: Thủ thư đăng nhập vào tài khoản -> Chọn
"Quản lý độc giả" từ menu -> Thêm, sửa hoặc xóa thông tin độc giả -> Lưu
thông tin độc giả sau khi chỉnh sửa.
+ Quản trị tài khoản của quản trị viên: Quản trị viên đăng nhập vào tài
khoản quản trị -> Chọn "Quản trị tài khoản" từ menu -> Thêm, sửa hoặc xóa
tài khoản người dùng -> Xác nhận và lưu thay đổi vào hệ thống.
- Thông tin các đối tượng được quản lí, xử lí:
+ Độc giả: Tên đăng nhập, mật khẩu, họ tên, địa chỉ, số điện thoại, email,
mã độc giả.
+ Sách: Mã sách, tên sách, tác giả, năm xuất bản, thể loại, số lượng tồn.
+ Thủ thư: Tên đăng nhập, mật khẩu, họ tên, địa chỉ, số điện thoại,
email, mã thủ thư.
+ Quản trị viên: Tên đăng nhập, mật khẩu, họ tên, địa chỉ, số điện thoại,
email.
+ Phiếu mượn: Mã phiếu, ngày mượn, ngày hẹn trả, trạng thái (đang
mượn, quá hạn).
+ Phiếu trả: Mã phiếu, ngày trả, trạng thái (đã trả, quá hạn).
- Quan hệ giữa các đối tượng:
+ Mỗi độc giả có thể mượn nhiều sách thông qua các phiếu mượn.
+ Mỗi sách có thể được mượn bởi nhiều độc giả thông qua các phiếu
mượn.
+ Mỗi phiếu mượn liên kết độc giả và sách cụ thể.
+ Mỗi phiếu trả liên kết độc giả, sách và phiếu mượn tương ứng.
+ Thủ thư quản lý và tạo phiếu mượn/trả sách.
 + Quản trị viên quản lý người dùng, tài khoản và có quyền truy cập toàn
bộ hệ thống.

b. Biểu đồ context cho hệ thống

2. Mô tả các actor (primary & secondary actor) của hệ thống

a. Primary actor:
- Độc giả:

 Mô tả: Độc giả có quyền truy cập vào hệ thống để tìm kiếm sách, tạo
phiếu mượn/trả sách và xem thông tin chi tiết về sách. Họ cần đăng nhập vào
hệ thống bằng tên đăng nhập và mật khẩu.

- Thủ thư:
  Mô tả: Thủ thư là người quản lý thư viện và có trách nhiệm quản lý
thông tin về sách, tài liệu, độc giả và quản lý quy trình mượn/trả sách. Thủ
thư có quyền truy cập vào hệ thống để quản lý sách và tài liệu, tạo phiếu
mượn/trả sách cho độc giả và xem thông tin về độc giả. Họ cũng có quyền
thực hiện các chức năng quản trị cần thiết.

- Quản trị viên:

 Mô tả: Quản trị viên là người có quyền cao nhất trong hệ thống quản
lý thư viện. Họ có khả năng quản lý vai trò và quyền truy cập của người dùng
khác trong hệ thống. Quản trị viên có quyền thêm, sửa và xóa tài khoản độc
giả và thủ thư. Họ cũng có khả năng quản lý các thiết lập chung của hệ thống
và giám sát hoạt động của các actor khác.

b. Secondary actor

- Nhân viên kĩ thuật:

Mô tả: Nhân viên kĩ thuật là người chịu trách nhiệm về phát triển,

triển khai và duy trì hệ thống quản lý thư viện. Họ đảm bảo rằng hệ thống
hoạt động ổn định, xử lý các vấn đề kỹ thuật và cung cấp hỗ trợ kỹ thuật khi
cần thiết.

- Nhân viên hỗ trợ:

Mô tả: Nhân viên hỗ trợ là người cung cấp hỗ trợ cho người dùng

trong việc sử dụng hệ thống quản lý thư viện. Họ giải đáp các câu hỏi, cung
cấp hướng dẫn và hỗ trợ kỹ thuật cho độc giả, thủ thư và quản trị viên khi
gặp sự cố hoặc cần giúp đỡ.

- Nhà cung cấp sách:

Mô tả: Nhà cung cấp sách là các tổ chức hoặc cá nhân cung cấp sách
và tài liệu cho thư viện. Họ có thể cung cấp thông tin về sách, báo giá, quy
trình đặt hàng và cung cấp sách mới cho thư viện. Thủ thư có thể tương tác
với nhà cung cấp sách để cập nhật thông tin sách trong hệ thống.

3. Mô tả yêu cầu các chức năng và phi chức năng của hệ thống bằng ngôn ngữ tự
nhiên và dạng Bảng

- Mô tả bằng ngôn ngữ tự nhiên:

+ Chức năng:
+ Đăng nhập: Chức năng này cho phép người dùng truy cập vào hệ
thống bằng việc nhập tên đăng nhập và mật khẩu. Người dùng cần tạo
tài khoản và đăng nhập để sử dụng các tính năng của hệ thống.
+ Quản lý sách và tài liệu: Chức năng này giúp thủ thư quản lý thông
tin về sách và tài liệu trong thư viện. Thủ thư có thể thêm, sửa hoặc
xóa thông tin sách, bao gồm mã sách, tên sách, tác giả, năm xuất bản
và thể loại.
+ Quản lý độc giả và lịch sử mượn/trả sách: Chức năng này cho phép
thủ thư quản lý thông tin về độc giả, bao gồm tên đăng nhập, mật khẩu,
họ tên, địa chỉ và thông tin liên hệ. Hệ thống cũng ghi lại lịch sử mượn
và trả sách của độc giả để theo dõi hoạt động sử dụng sách.
+ Tạo phiếu mượn/trả sách: Chức năng này cho phép thủ thư tạo phiếu
mượn sách cho độc giả. Phiếu này ghi nhận thông tin về ngày mượn
và ngày hẹn trả sách. Thủ thư cũng có thể tạo phiếu trả sách khi độc
giả trả sách.
+ Tìm kiếm sách và thông tin chi tiết: Chức năng này cho phép độc giả
tìm kiếm sách dựa trên tên sách, tác giả hoặc thể loại. Độc giả có thể
xem thông tin chi tiết về sách khi chọn cuốn sách cụ thể.
+ Phân quyền truy cập và quản trị: Chức năng này liên quan đến việc
quản lý vai trò và quyền truy cập của người dùng. Quản trị viên có
khả năng quản lý tài khoản người dùng, thêm, sửa và xóa tài khoản
độc giả và thủ thư.
+ Phi chức năng:
+ Bảo mật và quyền truy cập: Phi chức năng này đảm bảo an toàn thông
tin người dùng và dữ liệu sách trong hệ thống. Nó cũng liên quan đến
việc xác định và quản lý quyền truy cập của từng người dùng, đảm
bảo họ chỉ có quyền truy cập vào những phần mà họ được phép.
+ Hỗ trợ thông báo và nhắc nhở: Phi chức năng này bao gồm khả năng
gửi thông báo và nhắc nhở đến độc giả về các hạn trả sách sắp đến
hoặc sách trễ hạn. Điều này giúp đảm bảo việc trả sách đúng hẹn và
giữ cho việc sử dụng thư viện trở nên thuận tiện.
+ Xử lí sách mất hoặc hỏng: Phi chức năng này đảm nhận việc xử lí tình
huống sách bị mất hoặc hỏng trong quá trình mượn. Hệ thống cung
cấp cơ chế cho người dùng để báo cáo sách mất hoặc hỏng, và sau đó
thực hiện các bước xử lí như đình chỉ tài khoản, yêu cầu bồi thường
hoặc thay thế sách theo quy định.
- Mô tả bằng dạng bảng:
+ Chức năng

Chức năng Mô tả

Đăng nhập
Chức năng này cho phép người
dùng truy cập vào hệ thống bằng
việc nhập tên đăng nhập và mật
khẩu. Người dùng cần tạo tài
khoản và đăng nhập để sử dụng các
tính năng của hệ thống.

Quản lý sách và tài liệu

Chức năng này giúp thủ thư quản
lý thông tin về sách và tài liệu
trong thư viện. Thủ thư có thể
thêm, sửa hoặc xóa thông tin sách,
bao gồm mã sách, tên sách, tác giả,
năm xuất bản và thể loại

Quản lý độc giả và lịch sử Chức năng này cho phép thủ thư
mượn/trả sách quản lý thông tin về độc giả, bao
gồm tên đăng nhập, mật khẩu, họ
tên, địa chỉ và thông tin liên hệ. Hệ
thống cũng ghi lại lịch sử mượn và
trả sách của độc giả để theo dõi
hoạt động sử dụng sách.

Tạo phiếu mượn/trả sách Chức năng này cho phép thủ thư
tạo phiếu mượn sách cho độc giả.
Phiếu này ghi nhận thông tin về
ngày mượn và ngày hẹn trả sách.

Tìm kiếm sách và thông tin chi tiết
Phân quyền truy cập và quản trị
+ Phi chức năng
Phi chức năng
Bảo mật và quyền truy cập
Thủ thư cũng có thể tạo phiếu trả
sách khi độc giả trả sách.
Chức năng này cho phép độc giả
tìm kiếm sách dựa trên tên sách,
tác giả hoặc thể loại. Độc giả có thể
xem thông tin chi tiết về sách khi
chọn cuốn sách cụ thể.
Chức năng này liên quan đến việc
quản lý vai trò và quyền truy cập
của người dùng. Quản trị viên có
khả năng quản lý tài khoản người
dùng, thêm, sửa và xóa tài khoản
độc giả và thủ thư
Mô tả
Phi chức năng này đảm bảo an
toàn thông tin người dùng và dữ
liệu sách trong hệ thống. Nó cũng
liên quan đến việc xác định và
quản lý quyền truy cập của từng
người dùng, đảm bảo họ chỉ có
quyền truy cập vào những phần mà
họ được phép.
 Hỗ trợ thông báo và nhắc nhở Phi chức năng này bao gồm khả
năng gửi thông báo và nhắc nhở
đến độc giả về các hạn trả sách sắp
đến hoặc sách trễ hạn. Điều này
giúp đảm bảo việc trả sách đúng
hẹn và giữ cho việc sử dụng thư
viện trở nên thuận tiện.

Xử lí sách mất hoặc hỏng Phi chức năng này đảm nhận việc
xử lí tình huống sách bị mất hoặc
hỏng trong quá trình mượn. Hệ
thống cung cấp cơ chế cho người
dùng để báo cáo sách mất hoặc
hỏng, và sau đó thực hiện các bước
xử lí như đình chỉ tài khoản, yêu
cầu bồi thường hoặc thay thế sách
theo quy định.

4. Biểu đồ use case cho Hệ thống

5. Biểu đồ activity

- Độc giả
- Quản trị viên

- Thủ thư
 6. Biểu đô state cho Hệ thống

B. Hệ thống thương mại điện tử e-commerce (E-commerce Management System

EcoMaS)
1. Trình bày bằng ngôn ngữ tự nhiên và biểu đồ context cho hệ thống
a. Trình bày bằng ngôn ngữ tự nhiên
- Mục đích hệ thống
Hệ thống quản lý thương mại điện tử EcoMaS (E-commerce Management
System) là một nền tảng hoàn chỉnh được thiết kế để quản lý và điều hành mọi hoạt
động liên quan đến kinh doanh trực tuyến. Được xây dựng trên cơ sở công nghệ
hiện đại, EcoMaS cung cấp một loạt các tính năng mạnh mẽ để giúp doanh nghiệp
tạo, quản lý và phát triển doanh số bán hàng qua mô hình thương mại điện tử.
- Phạm vi hệ thống
1. Quản lý sản phẩm và danh mục: EcoMaS cho phép người dùng quản lý
danh mục sản phẩm và sản phẩm cụ thể một cách dễ dàng. Bạn có thể thêm, sửa đổi,
xóa sản phẩm, tạo ra các danh mục con hoặc đa cấp, và nhanh chóng cập nhật thông
tin sản phẩm như giá, mô tả và hình ảnh.
2. Quản lý đơn hàng: Hệ thống này cho phép bạn theo dõi và quản lý các
đơn đặt hàng từ khách hàng. Bạn có thể xem chi tiết đơn hàng, cập nhật trạng thái
đơn hàng, và tạo hóa đơn điện tử.
3. Quản lý khách hàng: EcoMaS cho phép bạn tạo hồ sơ khách hàng và lưu
trữ thông tin liên hệ, lịch sử mua hàng và hoạt động tương tác với khách hàng.
4. Thanh toán và giao hàng: Hệ thống hỗ trợ nhiều phương thức thanh toán
và tích hợp vận chuyển. Bạn có thể cấu hình giá vận chuyển dựa trên vị trí giao hàng
và cung cấp tùy chọn theo dõi đơn hàng cho khách hàng.
5. Quản lý khuyến mãi và giảm giá: EcoMaS cho phép bạn tạo các chương
trình khuyến mãi, mã giảm giá và ưu đãi đặc biệt để kích thích mua sắm và tăng
doanh số bán hàng.
6. Báo cáo và thống kê: Hệ thống cung cấp các báo cáo và thống kê liên quan
đến doanh số bán hàng, xu hướng mua sắm, hoạt động khách hàng và nhiều khía
cạnh kinh doanh khác để giúp bạn hiểu rõ hơn về hiệu suất của doanh nghiệp.
7. Quản lý trang web thương mại điện tử: EcoMaS cho phép bạn tùy chỉnh
giao diện và trải nghiệm người dùng của trang web thương mại điện tử. Bạn có thể
thêm các chức năng, tạo trang landing page và tùy chỉnh giao diện theo ý muốn.
8. Hệ thống thương mại điện tử: Đây là hệ thống trung tâm của mô hình e-
commerce, cung cấp giao diện và chức năng để người sử dụng thực hiện các giao
dịch mua bán và dịch vụ trực tuyến.
9. Cơ sở dữ liệu: Đây là nơi lưu trữ thông tin về sản phẩm, danh mục sản
phẩm và thông tin về người dùng. Hệ thống e-commerce truy cập vào cơ sở dữ liệu
này để hiển thị thông tin sản phẩm và quản lý thông tin người dùng.
10. Ngân hàng: Là nơi tiếp nhận và xử lý thanh toán của khách hàng.
 11. Hệ thống quản lý đơn hàng và thanh toán: Phần này xử lý quá trình đặt
hàng, tính toán giá trị đơn hàng và quản lý quá trình thanh toán. Nó đảm bảo rằng
giao dịch diễn ra một cách trơn tru và an toàn.
- Ai vào hệ thống và làm chức năng gì?
Hệ thống Quản lý Thương mại Điện tử (EcoMaS) được thiết kế để phục vụ
nhiều vai trò và người dùng khác nhau trong môi trường thương mại điện tử. Dưới
đây là một số ví dụ về các vai trò và chức năng tương ứng khi họ truy cập vào hệ
thống:
Admin:
- Tạo và quản lý tài khoản người dùng.
- Quản lý thông tin sản phẩm và danh mục.
- Theo dõi trạng thái và quản lý đơn hàng.
- Xem báo cáo thống kê kinh doanh.
- Tùy chỉnh giao diện cửa hàng trực tuyến.
Customer (Khách hàng):
- Duyệt và tìm kiếm sản phẩm trong cửa hàng trực tuyến.
- Thêm sản phẩm vào giỏ hàng và tiến hành đặt hàng.
- Thực hiện thanh toán an toàn và chọn phương thức giao hàng.
- Theo dõi tình trạng đơn hàng và lịch sử mua hàng.
Người phát triển và quản trị hệ thống:
- Quản lý cấu hình hệ thống và cơ sở dữ liệu.
- Đảm bảo an toàn và bảo mật thông tin người dùng.
- Thực hiện các nâng cấp và cải tiến hệ thống.
Vai trò và chức năng của mỗi người dùng trong hệ thống EcoMaS phụ thuộc
vào quyền truy cập và phân quyền được xác định bởi người quản trị hệ thống. Điều
này giúp đảm bảo rằng mỗi người dùng có quyền truy cập và thực hiện các chức
năng phù hợp với vai trò của họ.
- Các chức năng
Đăng ký:
- Người dùng truy cập vào trang đăng ký và cung cấp thông tin cá nhân
như tên, địa chỉ email và mật khẩu.
- Hệ thống kiểm tra tính hợp lệ của thông tin và tạo một tài khoản cho
người dùng mới.
- Sau khi đăng ký thành công, người dùng có thể sử dụng tên đăng
nhập và mật khẩu để đăng nhập vào hệ thống.
Đăng nhập:
- Người dùng nhập tên đăng nhập và mật khẩu vào trang đăng nhập.
 - Hệ thống kiểm tra thông tin đăng nhập và xác nhận tính hợp lệ.
- Nếu thông tin đúng, hệ thống cho phép người dùng truy cập vào tài
khoản và hiển thị giao diện cá nhân.
Thanh toán:
- Khi người dùng hoàn tất việc đặt hàng, họ chọn phương thức thanh toán và
nhập thông tin liên quan (thông tin thẻ tín dụng, ví điện tử, v.v.).
- Hệ thống xử lý thông tin thanh toán và kiểm tra tính hợp lệ của giao dịch.
- Nếu thanh toán thành công, hệ thống ghi nhận đơn hàng và gửi xác nhận
thanh toán đến người dùng.
Đặt hàng:
- Người dùng duyệt qua danh sách sản phẩm và thêm các sản phẩm
mình muốn mua vào giỏ hàng.
- Sau khi hoàn tất việc chọn sản phẩm, người dùng chuyển đến trang
thanh toán để hoàn tất quá trình đặt hàng.
- Hệ thống kiểm tra tính hợp lệ của thông tin và ghi nhận đơn hàng.
Cập nhật hệ thống:
- Người quản trị và nhóm phát triển có quyền truy cập vào hệ thống
quản trị.
- Họ có thể thực hiện việc cập nhật thông tin sản phẩm, danh mục, giá
cả và thay đổi cấu hình hệ thống.
- Cập nhật cũng có thể bao gồm việc thêm tính năng mới, tối ưu hóa
hiệu suất và bảo mật.
Các hoạt động này hoạt động song song và tương tác với nhau để tạo ra một
trải nghiệm mua sắm trực tuyến mượt mà và an toàn cho người dùng. Hệ thống phải
đảm bảo tính bảo mật, chính xác và hiệu quả trong việc xử lý các thao tác này.
b. Biểu đồ context
2. Mô tả các actor (primary & secondary actor) của hệ thống
a. Primary actor
Admin:
Admin là một trong những người dùng quan trọng nhất trong hệ thống Quản
lý Thương mại Điện tử (EcoMaS). Họ có quyền truy cập cao và có khả năng quản
lý toàn bộ hệ thống, từ tài khoản người dùng đến dữ liệu sản phẩm và cấu hình hệ
thống. Dưới đây là mô tả chi tiết về Actor Admin:
 Quản lý tài khoản:
- Admin có khả năng tạo, chỉnh sửa và xóa tài khoản người dùng khác
trong hệ thống.
- Họ có quyền thay đổi thông tin tài khoản, thiết lập vai trò và phân
quyền tương ứng.
 Quản lý sản phẩm:
- Người quản trị có quyền thêm, sửa và xóa thông tin sản phẩm.
- Họ có thể cập nhật hình ảnh, mô tả, giá cả và các thông tin liên quan
khác về sản phẩm.
 Quản lý đơn hàng:
 - Admin có thể xem danh sách đơn hàng, tình trạng và chi tiết của
chúng.
- Họ có khả năng cập nhật trạng thái đơn hàng để thể hiện tiến trình xử
lý.
 Quản lý tài nguyên:
- Admin có thể quản lý các tài nguyên như hình ảnh sản phẩm, biểu đồ
thống kê, và tài liệu hướng dẫn.
- Họ có khả năng tải lên, sửa đổi và xóa các tài nguyên này.
 Giải quyết sự cố:
- Khi có sự cố hoặc lỗi xảy ra trong hệ thống, người quản trị có khả
năng giải quyết vấn đề và thực hiện các biện pháp khắc phục.
- Admin chịu trách nhiệm đảm bảo rằng hệ thống EcoMaS hoạt động
một cách mượt mà và hiệu quả. Vai trò của họ là quan trọng để duy trì và nâng cao
chất lượng và hiệu suất của hệ thống trong môi trường thương mại điện tử.
Customer:
Customer là những người dùng chính của hệ thống Quản lý Thương mại Điện
tử (EcoMaS). Họ là những người sử dụng cửa hàng trực tuyến để duyệt sản phẩm,
thêm vào giỏ hàng, thực hiện thanh toán và theo dõi tình trạng đơn hàng. Dưới đây
là mô tả chi tiết về Actor Customer:
 Duyệt và tìm kiếm sản phẩm:
- Customer có khả năng duyệt qua danh sách sản phẩm, sử dụng các bộ
lọc và tìm kiếm để tìm sản phẩm cụ thể.
- Thêm sản phẩm vào giỏ hàng:
- Customer có thể thêm sản phẩm vào giỏ hàng bằng cách chọn số lượng
và nhấn nút "Thêm vào giỏ hàng".
 Xem giỏ hàng: Customer có thể xem danh sách sản phẩm trong giỏ
hàng, điều chỉnh số lượng hoặc xóa sản phẩm khỏi giỏ.
 Đăng ký tài khoản: Nếu chưa có tài khoản, Customer có khả năng
đăng ký tài khoản mới bằng cách cung cấp thông tin cá nhân.
 Đăng nhập: Customer có thể đăng nhập vào tài khoản đã đăng ký
trước đó để quản lý thông tin cá nhân và xem lịch sử đơn hàng.
Thực hiện thanh toán: Customer chọn phương thức thanh toán (thẻ tín
dụng, ví điện tử, v.v.) và nhập thông tin liên quan để hoàn tất giao dịch thanh toán.
 Đặt hàng: Sau khi xem giỏ hàng và thực hiện thanh toán, Customer
hoàn tất việc đặt hàng và gửi yêu cầu đến hệ thống.
 Theo dõi đơn hàng: Customer có thể xem tình trạng đơn hàng, từ khi
đặt hàng đến khi giao hàng thành công.
  Xem lịch sử mua hàng: Customer có thể xem lịch sử các đơn hàng đã
thực hiện trong quá khứ.
 Liên hệ hỗ trợ: Customer có khả năng liên hệ với dịch vụ hỗ trợ khách
hàng để giải quyết các vấn đề hoặc đặt câu hỏi liên quan đến sản phẩm và đơn hàng.
 Đăng xuất: Customer có thể đăng xuất khỏi tài khoản sau khi hoàn tất
các hoạt động mua sắm.
Customer đóng vai trò quan trọng trong việc sử dụng hệ thống, tạo ra các
giao dịch mua sắm và cung cấp thông tin quan trọng giúp doanh nghiệp hiểu rõ hơn
về nhu cầu của họ.
b. Secondary actor
Nhà cung cấp (Supplier):
Nhà cung cấp là một trong các actor quan trọng trong hệ thống Quản lý
Thương mại Điện tử (EcoMaS). Họ đại diện cho các đối tác cung cấp sản phẩm cho
cửa hàng trực tuyến. Nhà cung cấp tương tác với hệ thống để cung cấp thông tin sản
phẩm, quản lý lượng tồn kho và xác nhận xử lý đơn hàng từ khách hàng. Dưới đây
là mô tả chi tiết về Actor Nhà cung cấp:
 Cung cấp thông tin sản phẩm: Nhà cung cấp có khả năng cung cấp
thông tin chi tiết về sản phẩm cho hệ thống. Họ cung cấp mô tả, hình ảnh, giá cả và
các thông tin liên quan khác.
 Cập nhật lượng tồn kho: Nhà cung cấp cập nhật lượng tồn kho của
các sản phẩm. Họ cập nhật thông tin về số lượng sản phẩm có sẵn để đảm bảo rằng
khách hàng không đặt hàng cho sản phẩm đã hết hàng.
 Xác nhận đơn hàng: Khi nhận được yêu cầu đặt hàng từ khách hàng,
Nhà cung cấp xác nhận xem họ có khả năng xử lý đơn hàng hay không. Họ có thể
xác nhận hoặc từ chối xử lý đơn hàng dựa trên lượng tồn kho và khả năng cung cấp.
 Cập nhật trạng thái đơn hàng: Sau khi xác nhận xử lý đơn hàng, Nhà
cung cấp có khả năng cập nhật trạng thái đơn hàng để thể hiện tiến trình xử lý (đang
chuẩn bị, đã giao hàng, v.v.).
 Hỗ trợ giao hàng: Nếu hệ thống hỗ trợ tích hợp vận chuyển, Nhà cung
cấp cung cấp thông tin về việc vận chuyển và giao hàng cho khách hàng.
 Cập nhật thông tin sản phẩm: Nếu có sự thay đổi về sản phẩm, Nhà
cung cấp có khả năng cập nhật thông tin sản phẩm như mô tả, hình ảnh, giá cả.
 Liên hệ hỗ trợ: Nhà cung cấp có thể liên hệ với dịch vụ hỗ trợ để giải
quyết các vấn đề hoặc đặt câu hỏi liên quan đến việc cung cấp sản phẩm.
Vai trò của Nhà cung cấp là cung cấp thông tin sản phẩm chính xác và đảm
bảo quá trình xử lý đơn hàng diễn ra một cách suôn sẻ từ phía nhà cung cấp đến
khách hàng.
 Nhân viên giao hàng (Delivery Personnel):
- Là người thực hiện việc giao hàng tới khách hàng.
- Nhận thông tin về đơn hàng cần giao và cập nhật trạng thái giao hàng.
- Tương tác với chức năng Quản lý Đơn hàng và Cập nhật trạng thái giao
hàng.
Người phân tích kinh doanh (Business Analyst):
- Là người dùng có nhiệm vụ phân tích dữ liệu kinh doanh và tạo báo
cáo.
- Truy cập vào thông tin thống kê kinh doanh và tạo báo cáo để đưa ra
quyết định liên quan đến chiến lược kinh doanh.
- Tương tác với chức năng Thống kê Kinh doanh và Tạo báo cáo.
Người phát triển và quản trị hệ thống (Developer/System Administrator):
- Là người có quyền truy cập vào hệ thống từ phía bên trong.
- Cập nhật và quản lý cấu hình hệ thống, cải thiện tính năng và bảo mật,
và thực hiện việc bảo trì.
- Tương tác chủ yếu qua chức năng Cập nhật hệ thống và Quản lý cấu
hình.
Các primary và secondary actors trong hệ thống EcoMaS tham gia vào các
tương tác và chức năng khác nhau, hỗ trợ hệ thống hoạt động một cách toàn diện và
hiệu quả
3. Mô tả yêu cầu các chức năng và phi chức năng của hệ thống bằng ngôn ngữ tự
nhiên và dạng Bảng
a. Yêu cầu chức năng
- Ngôn ngữ tự nhiên
 Đăng nhập và đăng ký: Cho phép người dùng đăng nhập vào hệ thống
hoặc đăng ký tài khoản mới. Ghi nhớ thông tin đăng nhập.
 Tìm kiếm sản phẩm: Cung cấp khả năng tìm kiếm sản phẩm dựa trên
tên, danh mục, giá, và các tiêu chí khác.
 Xem chi tiết sản phẩm: Cho phép người dùng xem thông tin chi tiết về
sản phẩm, bao gồm mô tả, hình ảnh, đánh giá và giá bán.
 Thêm/Xóa sản phẩm vào giỏ hàng: Người dùng có thể thêm sản phẩm
vào giỏ hàng hoặc xóa sản phẩm khỏi giỏ hàng.
 Quản lý giỏ hàng: Cho phép xem và chỉnh sửa giỏ hàng, cập nhật số
lượng sản phẩm và tính tổng giá trị.
 Thanh toán: Hỗ trợ thanh toán bằng nhiều phương thức (thẻ tín dụng,
chuyển khoản, ví điện tử) và lưu trữ thông tin thanh toán an toàn.
  Đặt hàng: Người dùng có thể xác nhận đơn hàng và chọn phương thức
giao hàng. Tạo đơn hàng và xác nhận đặt hàng.
 Xem lịch sử đơn hàng: Cho phép người dùng xem lịch sử các đơn hàng
đã đặt, cập nhật trạng thái đơn hàng.
 Quản lý tài khoản: Người dùng có thể cập nhật thông tin cá nhân, đổi
mật khẩu, và quản lý địa chỉ giao hàng.
 Đánh giá và nhận xét sản phẩm: Cho phép người dùng đánh giá và viết
nhận xét về sản phẩm sau khi mua hàng.
 Hỗ trợ khách hàng: Cung cấp kênh liên hệ với bộ phận hỗ trợ khách
hàng để giải quyết vấn đề hoặc yêu cầu hỗ trợ.
 Quản trị sản phẩm (Cho người bán): Người bán có thể thêm, sửa đổi
hoặc xóa sản phẩm, quản lý hàng tồn kho và theo dõi đơn đặt hàng.
 Quản trị người dùng (Cho quản trị viên): Quản trị viên có quyền duyệt
đăng ký người bán, quản lý tài khoản người dùng, và kiểm soát hoạt động
trên hệ thống.
 Thống kê doanh số bán hàng và báo cáo: Hệ thống cung cấp thống kê
về doanh số bán hàng, xu hướng sản phẩm và tạo báo cáo tài chính.
 Quảng cáo và tiếp thị sản phẩm: Cho phép người bán quảng cáo sản
phẩm của họ thông qua hệ thống.
 Hệ thống gửi Email thông báo và cập nhật: Hệ thống tự động gửi email
thông báo về đơn hàng, cập nhật về sản phẩm và các thông tin liên quan.
- Dạng bảng

STT Chức năng Mô tả chức năng

Cho phép người dùng đăng nhập vào hệ thống hoặc

1 Đăng nhập và đăng ký
đăng ký tài khoản mới. Ghi nhớ thông tin đăng nhập.

Cung cấp khả năng tìm kiếm sản phẩm dựa trên tên,
2 Tìm kiếm sản phẩm
danh mục, giá, và các tiêu chí khác.
 Cho phép người dùng xem thông tin chi tiết về sản
3 Xem chi tiết sản phẩm
phẩm, bao gồm mô tả, hình ảnh, đánh giá và giá bán.

Thêm/Xóa sản phẩm Người dùng có thể thêm sản phẩm vào giỏ hàng hoặc
4
vào giỏ hàng xóa sản phẩm khỏi giỏ hàng.

Cho phép xem và chỉnh sửa giỏ hàng, cập nhật số lượng
5 Quản lý giỏ hàng
sản phẩm và tính tổng giá trị.

Hỗ trợ thanh toán bằng nhiều phương thức (thẻ tín dụng,
6 Thanh toán chuyển khoản, ví điện tử) và lưu trữ thông tin thanh toán
an toàn.

Người dùng có thể xác nhận đơn hàng và chọn phương

7 Đặt hàng
thức giao hàng. Tạo đơn hàng và xác nhận đặt hàng.

Cho phép người dùng xem lịch sử các đơn hàng đã đặt,
8 Xem lịch sử đơn hàng
cập nhật trạng thái đơn hàng.

Người dùng có thể cập nhật thông tin cá nhân, đổi mật
9 Quản lý tài khoản
khẩu, và quản lý địa chỉ giao hàng.
 Đánh giá và nhận xét Cho phép người dùng đánh giá và viết nhận xét về sản
10
sản phẩm phẩm sau khi mua hàng.

Cung cấp kênh liên hệ với bộ phận hỗ trợ khách hàng để

11 Hỗ trợ khách hàng
giải quyết vấn đề hoặc yêu cầu hỗ trợ.

Quản trị sản phẩm (Cho Người bán có thể thêm, sửa đổi hoặc xóa sản phẩm,
12
người bán) quản lý hàng tồn kho và theo dõi đơn đặt hàng.

Quản trị viên có quyền duyệt đăng ký người bán, quản

Quản trị người dùng
13 lý tài khoản người dùng, và kiểm soát hoạt động trên hệ
(Cho quản trị viên)
thống.

Thống kê doanh số bán Hệ thống cung cấp thống kê về doanh số bán hàng, xu
14
hàng và báo cáo hướng sản phẩm và tạo báo cáo tài chính.

Quảng cáo và tiếp thị Cho phép người bán quảng cáo sản phẩm của họ thông
15
sản phẩm qua hệ thống.

Hệ thống gửi Email Hệ thống tự động gửi email thông báo về đơn hàng, cập
16
thông báo và cập nhật nhật về sản phẩm và các thông tin liên quan.

b. Yêu cầu Phi Chức Năng:

- Ngôn ngữ tự nhiên
  Bảo Mật: Đảm bảo rằng thông tin người dùng và giao dịch được bảo mật
và mã hóa.
 Hiệu Năng: Hệ thống phải hoạt động một cách nhanh chóng và mượt mà,
đáp ứng tốt cho số lượng người dùng lớn.
 Khả Năng Mở Rộng: Hệ thống phải có khả năng mở rộng để xử lý thêm
người dùng và sản phẩm khi cần thiết.
 Tương Thích Đa Nền Tảng: Hệ thống phải hoạt động trên nhiều nền
tảng (máy tính, điện thoại di động, máy tính bảng) và trình duyệt web.
 Khả Năng Sao Lưu và Khôi Phục Dữ Liệu: Có khả năng sao lưu và
khôi phục dữ liệu quan trọng trong trường hợp sự cố hoặc mất dữ liệu.
 Tuân Thủ Quy định Pháp Luật: Hệ thống phải tuân thủ các quy định
pháp luật liên quan đến giao dịch thương mại điện tử và bảo vệ dữ liệu cá
nhân.
- Dạng bảng

STT Phi chức năng Mô tả phi chức năng

Đảm bảo rằng thông tin người dùng và giao dịch được bảo
1 Bảo mật
mật và mã hóa.

Hệ thống phải hoạt động một cách nhanh chóng và mượt

2 Hiệu năng
mà, đáp ứng tốt cho số lượng người dùng lớn.

Hệ thống phải có khả năng mở rộng để xử lý thêm người

3 Khả năng mở rộng
dùng và sản phẩm khi cần thiết.
 Tương thích đa nền Hệ thống phải hoạt động trên nhiều nền tảng (máy tính,
4
tảng điện thoại di động, máy tính bảng) và trình duyệt web.

Khả năng sao lưu và Có khả năng sao lưu và khôi phục dữ liệu quan trọng trong
5
khôi phục dữ liệu trường hợp sự cố hoặc mất dữ liệu.

Hệ thống phải tuân thủ các quy định pháp luật liên quan
Tuân thủ quy định
6 đến giao dịch thương mại điện tử và bảo vệ dữ liệu cá
pháp luật
nhân.

4. Trình bày Biểu đồ use case cho Hệ thống

a. Biểu đồ use case tổng quát
b. Biểu đồ use case chi tiết
- Đăng nhập

- Đặt hàng
- Thanh toán

- Thêm sản phẩm

5. Trình bày Biểu đồ activity cho các Hệ thống
a. Biểu đồ activity đăng nhập
b. Biểu đồ activity đặt hàng
c. Biểu đồ activity thêm sản phẩm
6. Trình bày Biểu đô state cho các Hệ thống
a. Biểu đồ trạng thái thể hiện lớp Customer

b. Biểu đồ trạng thái thể hiện lớp Admin

 c. Biểu đồ trạng thái thể hiện lớp sản phẩm

C. Hệ thống đăng ký học theo tín chỉ ở trường Đại học (Register Management
System RegMaS)
Hệ thống đăng ký tín chỉ của trường đại học là một nền tảng kỹ thuật tiên tiến và
hoàn chỉnh, được xây dựng để tạo điều kiện thuận lợi cho quá trình đăng ký và quản
lý tín chỉ của sinh viên. Với mục tiêu giúp sinh viên tự do lựa chọn các môn học phù
hợp với chương trình học của mình và tối ưu hóa thời gian học tập, hệ thống này đã
được thiết kế với sự chú trọng đến tính bảo mật, hiệu suất và trải nghiệm người dùng
thân thiện.
Hệ thống không chỉ đảm bảo tính nhất quán thông tin về môn học và lớp học phần, mà còn
kết nối linh hoạt với các hệ thống khác trong trường như quản lý sinh viên và thời khóa
biểu. Điều này giúp tạo nên một môi trường học tập liên kết, thông tin và tiện ích cho cả
sinh viên và cán bộ quản lý.
Với khả năng thích ứng trên nhiều nền tảng và giao diện thân thiện, hệ thống đăng ký tín
chỉ của trường đại học đã đóng góp không nhỏ vào việc cải thiện quá trình đăng ký và quản
lý tín chỉ, mang lại sự thuận tiện và hiệu quả cho cả cộng đồng học tập và giảng dạy.

1. Trình bày bằng ngôn ngữ tự nhiên và biểu đồ context cho hệ thống
a. Trình bày ngôn ngữ tự nhiên
Các bước thực hiện:
- Bước 1: Giới thiệu mục đích của hệ thống
- Bước 2: Phạm vi hệ thống: Ai dùng được phần mềm hệ thống? Mỗi người vào hệ
thống được phép thực hiện các chức năng nào?
- Bước 3: Với mỗi chức năng mà người dùng được phép thực hiện ở bước 2, mô tả
chi tiết hoạt động nghiệp vụ của chức năng đấy diễn ra như thế nào?
- Bước 4: Các đối tượng nào được quản lý, xử lý trong hệ thống? Mỗi đối tượng cần
quản lý các thuộc tính nào?
- Bước 5: Quan hệ giữa các đối tượng đã nêu ở bước 4
Áp dụng cho hệ thống đăng lý tín chỉ ở trường đại học
Bước 1: Mục đích của hệ thống: Hệ thống trang web đăng ký tin chỉ của trường đại học
phục vụ công tác quản lý đăng ký tín của sinh viên, đăng ký giảng dạy của giảng viên của
một trường đại học.
Bước 2: Phạm vi hệ thống: Những người dùng được vào hệ thống và thực hiện các chức
năng mỗi người được phép thực hiện khi vào hệ thống được quy định như sau:
- Thành viên hệ thống:
 Đăng nhập
 Đăng xuất
 Đổi mật khẩu cá nhân
- Sinh viên:
 Được thực hiện các chức năng của thành viên hệ thống
 Đăng ký học, hiển thị danh sách môn học đã đăng ký
 Xem lịch học cá nhân
 Đóng tiền phí dịch vụ, học phí
 - Giảng viên:
 Đăng ký dạy, sửa thông tin đăng ký dạy
 Xem lịch giảng dạy cá nhân
 Xem thống kê liên quan đến các lớp giảng viên dạy
- Nhân viên giáo vụ
 Quản lý thông tin sinh viên: thêm, sửa, xóa theo yêu cầu của sinh viên
 Quản lý thông tin giảng viên theo yêu cần từ giảng viên
 Quản lý thông tin môn học
 Quản lý thông tin lớp học phần
- Nhân viên quản lý:
 Xem các loại thống kê
Bước 3: Hoạt động chính của các chức năng
- Sinh viên đăng ký tín: Sinh viên đăng nhập vào hệ thống  Chọn chức năng đăng
ký tín chỉ (đang trong thời gian đăng ký tín chỉ mới được chọn)  Chọn kỳ đăng ký
tín + ngành học (có thể có sinh viên đồng thời học hai chuyên ngành)  Hệ thống
đăng ký hiện danh sách các môn học có thể đăng ký (mã, tên môn học, số tín chỉ,
mô tả)  Sinh viên chọn môn học  Hiện thống hiện danh sách các lớp học phần
của môn đấy (mã, tên, sĩ số tối đa, sĩ số hiện tại, phòng học, giảng viên, thời khóa
biểu): chỉ có thể chọn các lớp mà không bị trùng lịch học với các môn đã chọn trước
 Sinh viên chọn lớp học phần mình thích  Hệ thống quay lại trang bắt đầu đăng
lý với lớp học phần vừa chọn được bổ dung vào danh sách các lớp học phần đã chọn.
Sinh viên lặp lại các bước trên cho đến khi chọn đủ số tín chỉ trong ngưỡng cho
phép  Nút Lưu được hoạt động  Sinh viên chọn Lưu thì thông tin đăng ký mới
chính thức được lưu vào hệ thống, hệ thống quay về giao diện chính của sinh viên.

- Giảng viên đăng ký dạy học: Giảng viên đăng nhập vào hệ thống  Chọn chức
năng “Đăng ký dạy học”  Hệ thống hiện thị giao diện Đăng ký giảng dạy lên trên
màn hình  Giảng viên chọ kỳ học đang active  Hệ thống hiển thị danh sách các
học phần trong kỳ học  Giảng viên chọn học phần muốn đăng ký: chỉ chọn được
những học phần không bị trùng với những học phần đã đăng ký  Hệ thống hiển
thị đăng ký thành công và quay trở lại trang đăng ký giảng dạy. Giảng viên thực
hiện lặp lại các bước thực hiện đăng ký giảng dạy  Thực hiện xác nhận và lưu
thông tin đăng ký  Thông báo xác nhận: Hệ thống thông báo xác nhận đăng ký
giảng dạy thành công  Quay lại giao diện chính của giảng viên.
Bước 4: Thông tin các đối tượng cần xử lý, quản lý
 - Nhóm các đối tượng liên quan đến con người:
 Thành viên: Tên đăng nhập, mật khẩu, họ và tên, địa chỉ, ngày sinh, email
sinh viên, số điện thoại
 Sinh viên: Giống thành viên, có thêm: mã sinh viên. Theo mỗi ngành học còn
có khóa học, ngành học
 Nhân viên: Giống thành viên, có thêm: vị trí công tác
 Nhân viên quản lý: Giống nhân viên
 Nhân viên giáo vụ: Giống nhân viên
 Giảng viên: Giống nhân viên
- Nhóm các thông tin liên quan đến cơ sở vật chất:
 Tòa nhà: Tên, mô tả
 Phòng học: Tên, sức chứa tối đa, mô tả
- Nhóm các thông tin liên quan đến đơn vị, tổ chức:
 Trường: Tên, địa chỉ, mô tả
 Khoa: Tên, mô tả
 Bô môn: Tên, mô tả
- Nhóm các thông tin liên quan đến chuyên môn, vận hành
 Năm học: Tên, mô tả
 Kỳ học: Tên, mô tả
 Tuần học: Tên, mô tả
 Ngày trong tuần: Tên, mô tả
 Kíp học trong ngày: Tên, mô tả
 Môn học: Tên, số tín chỉ, mô tả
 Lớp học phần: Tên, mô tả, sĩ số tối đa, sĩ số hiện tại, giảng viên dạy, phòng
học, tuần học, ngày học, kíp học
- Nhóm các thông tin liên quan đến thống kê:
 Thống kê học kỳ theo số sinh viên
Bước 5: Quan hệ giữa các đối tượng thông tin
- Một trường có nhiều khoa
- Một khoa có nhiều bộ môn
- Một khoa có nhiều ngành học
- Một bộ môn quản lí chuyên môn nhiều môn học
- Một bộ môn có nhiều giảng viên
- Một năm học có nhiều học kì
 - Một học kì liên quan đến nhiều năm học. Một năm học + một học kì tạo ra một kì
học.
- Một kì học có nhiều môn học
- Một môn học, vào một kì học, có nhiều lớp học phần
- Một lớp học phần có thể học vào nhiều buổi, mỗi buổi có thể liên quan đến 1 tuần
khác nhau, 1 ngày khác nhau, 1 kíp khác nhau, 1 phòng học khác nhau, 1 giảng
viên khác nhau.
- Một giảng viên có thể dạy nhiều môn học trong mỗi kì học
- Một môn học, trong một kì học, giảng viên có thể dạy nhiều lớp học phần khác
nhau, miễn sao không trùng lịch buổi nào.
- Một lớp học phần, có thể có nhiều giảng viên dạy. Nhưng mỗi buổi học chỉ có một
giảng viên dạy.
- Một môn học có nhiều đầu điểm thành phần.
- Mỗi đầu điểm thành phần, đối với mỗi môn học, có tỉ lệ % tính điểm nhất định.
- Một tuần có thể có nhiều buổi dạy/học
- Một ngày có thể có nhiều buổi học/dạy
- Một kíp có thể có nhiều buổi học/dạy của nhiều lớp học phần khác nhau
- Một phòng học có thể có nhiều lớp học phần vào học ở những buổi khác nhau.
- Một sinh viên có thể đăng kí học nhiều ngành khác nhau (tối đa 2 ngành đồng
thời).
- Với mỗi ngành, sinh viên phải học một số môn nhất định, và điểm tính theo từng
ngành. Các môn trùng nhau giữa các ngành thì sinh viên chỉ phải học 1 lần, qua là
được.
- Mỗi sinh viên, mỗi môn học, có một diểm trung bình môn.

b. Biểu đồ context cho hệ thống

Biểu đồ context là một loại biểu đồ được sử dụng trong phân tích và thiết kế hệ
thống thôn tin để trình bày một cái nhìn tổng quan về mối quan hệ giữa hệ thống chính và
các thành phần hoặc yếu tố xung quang. Biểu đồ context thường được sử dụng trong kỹ
thuật phát triển phần mềm, quản lý dự án và thiết kế hệ thống
Mục đích chính của biểu đồ context bao gồm:
- Hiển thị phạm vi hệ thống: Biểu đồ context giúp xác định rõ ràng phạm vi của hệ
thống bằng cách chỉ ra các thành phần hoặc yếu tố ngoại vi mà hệ thống tương tác.
- Hiểu mối quan hệ: Biểu đồ context cho thấy cách mà hệ thống chính tương tác với
môi trường xung quanh thông qua các liên kết, giao diện hoặc luồng dữ liệu. Điều
này giúp người thiết kế hoặc phân tích hiểu rõ hơn về cách mà hệ thống tương tác
với các thành phần bên ngoài.
- Truyền tải thông tin cho các bên liên quan: Biểu đồ context thường được sử dụng
để trình bày cho các bên liên quan, như người dùng cuối, nhà phát triển, nhà quản
lý dự án, một cái nhìn rõ ràng về cách hệ thống tương tác với môi trường xung
quanh.
- Định hướng phân tích chi tiết hơn: Biểu đồ context có thể được sử dụng để xác định
các yếu tố quan trọng mà cần phải phân tích chi tiết hơn. Nó giúp xác định các giao
diện quan trọng và các chức năng chính của hệ thống
- Căn cứ thiết kế: Biểu đồ context cung cấp cơ sở để xây dựng thiết kế chi tiết hơn
cho hệ thống, bao gồm việc thiết kế giao diện, quy trình và các thành phần nội bộ
của hệ thống
2. Mô tả các actor (primary & secondary actor) của hệ thống
+ Primary actor
- Người dùng: Là những người có thể vào hệ thống để thực hiện các khả năng khác
nhau theo nhiệm vụ. Các hoạt động của Người dùng:
 Đăng nhập vào hệ thống: Người dùng có thể đăng nhập vào hệ thống bằng
tên đăng nhập và mật khẩu cá nhân
 Đăng xuất: Người dùng có thể đăng xuất khỏi hệ thống
 Đổi mật khẩu: Khi quên mật khẩu hoặc cập nhật lại mật khẩu khác, người
cùng có thể chọn chức năng để thay đổi mật khẩu

- Sinh viên: Sinh viên là người dùng chính và chủ yếu của hệ thống đăng ký tín chỉ,
tương tác trực tiếp với hệ thống. Các hoạt động của Sinh viên
 Đăng ký tín chỉ: Người dùng có thể thực hiện đăng ký tín chỉ cho kỳ sau, để
phù hợp với thời gian, lịch trình công việc cá nhân
 Đóng tiền phí dịch vụ, học phí: Có thể thực hiện thanh toán liên quan đến các
khoản đóng của trường.
 Hiển thị danh sách môn học: Danh sách môn học đã đăng ký thành công sẽ
được hiển thị cho sinh viên
 Xem lịch học cá nhân: Dựa vào lịch học và lớp học phần đã đăng ký, sinh
viên có thể xem được lịch học của mình theo tuần, hoặc theo lớp tin chỉ

- Giảng viên: Đăng ký giảng dạy, xem lịch dạy, xem thống kê cá nhân
- Nhân viên giáo vụ: Quản lý thông tin của sinh viên theo yêu cầu của sinh viên, quản
lý môn học, lớp học phần
- Nhân viên quản lý: Quản lý thông tin chung, quản lý thông tin giảng viên theo yêu
cầu, xem các loại thống kê
+ Secondary actor
- Hệ thống thông báo: Một hệ thống sẽ tự động gửi thông báo từ trường đến sinh viên
và giảng viên liên quan đến việc đăng ký, thay đổi lịch, hay các thông tin quan trọng
khác
- Phòng đào tạo: Phòng đào tạo có thể tham gia vào việc điều chỉnh lịch học, lịch
giảng dạy của sinh viên, giảng viên và sắp xếp các yêu cầu đặc biệt hoặc các đăng
ký quá hạn
- Kế toán trường: Kế toán trường có thể liên quan đến việc xác nhận thanh toán học
phí của sinh viên sau khi sinh viên đóng học phí
3. Mô tả yêu cầu các chức năng và phi chức năng của hệ thống bằng ngôn ngữ
tự nhiên và dạng bảng
a. Mô tả yêu cầu các chức năng và phi chức năng của hệ thống bằng ngôn ngữ
tự nhiên
Yêu cầu chức năng:
Đăng nhập: Người dùng có khả năng sử dụng tên đăng nhập và mật khẩu cá nhân để truy
cập vào hệ thống. Sau khi nhập thông tin, hệ thống sẽ xác thực và cho phép người dùng
truy cập vào giao diện chính của hệ thống. Nếu thông tin đăng nhập không chính xác, hệ
thống sẽ cung cấp thông báo lỗi tương ứng.
Đổi mật khẩu: Trong trường hợp người dùng quên mật khẩu hoặc muốn cập nhật mật khẩu,
hệ thống cung cấp chức năng đổi mật khẩu. Người dùng cần cung cấp mật khẩu hiện tại để
xác nhận danh tính và sau đó nhập mật khẩu mới hai lần để xác nhận. Hệ thống sẽ kiểm tra
tính hợp lệ của mật khẩu cũ và thực hiện việc cập nhật mật khẩu mới.
Đăng ký tin chỉ: Trong khoảng thời gian mà hệ thống cho phép đăng ký tín chỉ, sinh viên
có thể đăng ký các môn học. Hệ thống sẽ hiển thị danh sách các môn học trong kỳ học và
ngành đã chọn. Sinh viên có khả năng chọn số lượng tín chỉ mong muốn và hệ thống sẽ
hiển thị danh sách các môn học có thể đăng ký dựa trên số tín chỉ đã chọn (sinh viên học
đồng thời tối đa 2 ngành học)
Hiển thị danh sách môn học: Sau khi chọn kỳ học và ngành, hệ thống sẽ hiển thị danh sách
các môn học mà sinh viên đã đăng ký. Mỗi môn học sẽ được hiển thị với thông tin chi tiết
như mã môn, tên môn, số tín chỉ, giảng viên, và thời khóa biểu.
Xem lịch học cá nhân: Dựa vào danh sách các môn học đã đăng ký, hệ thống cho phép sinh
viên xem lịch học cá nhân của mình. Sinh viên có khả năng xem lịch học theo từng tuần
hoặc theo học kỳ, bao gồm thông tin về thời gian, ngày, phòng học, và giảng viên. Việc
này giúp sinh viên dễ dàng quản lý thời gian học tập và chuẩn bị cho các buổi học.
Đăng ký giảng dạy: Giảng viên có thể sử dụng chức năng đăng ký giảng dạy để đăng ký
môn học mà giảng viên sẽ giảng dạy trong kỳ học. Hệ thống cho phép giảng viên chọn môn
học, lớp học phần và thời gian dạy tương ứng. Quá trình này giúp hệ thống xác định thông
tin về giảng dạy và hiển thị cho sinh viên.
Quản lý thông tin sinh viên: Nhân viên giáo vụ có quyền thêm, sửa và xóa thông tin của
sinh viên trong hệ thống. Nếu có yêu cầu từ phía sinh viên về việc thay đổi lịch học hoặc
thông tin cá nhân, nhân viên giáo vụ sẽ thực hiện điều chỉnh để đảm bảo tính chính xác và
phù hợp với kế hoạch học tập.
Quản lý thông tin giảng viên: Khi có yêu cầu thêm, sửa xóa thông tin của giảng viên thì
nhân viên giáo vụ sẽ thực hiện chức năng của mình. Trong trường hợp giảng viên hủy học
phần đã đăng ký thì nhân viên giáo vụ sẽ điều chỉnh lại theo nguyện vọng của giảng viên
hoặc theo yêu cầu của trường học
Quản lý thông tin môn học: Nhân viên giáo vụ có trách nhiệm quản lý thông tin về các môn
học trong hệ thống. Họ sẽ cập nhật và điều chỉnh thông tin về các môn học theo kế hoạch
của trường, đảm bảo rằng thông tin về môn học luôn được cập nhật chính xác và đầy đủ
Yêu cầu phi chức năng:
Bảo mật: Hệ thống cần đảm bảo tính bảo mật cao, đảm bảo rằng dữ liệu của sinh viên,
giảng viên và thông tin đăng ký không bị lộ ra ngoài.
Hiệu suất: Hệ thống cần đảm bảo hiệu suất tốt, có khả năng xử lý nhanh và đáp ứng được
nhiều yêu cầu truy cập cùng lúc trong thời gian đăng ký (Đặc biệt là trong các khung giờ
đăng ký, hạn chế việc xảy ra việc hệ thống ngừng hoạt động, hoạt động chậm khi số lượng
sinh viên tham gia đăng ký quá tải)
Giao diện thân thiện: Giao diện người dùng phải được thiết kế đơn giản, thân thiện và dễ
sử dụng, giúp người dùng dễ dàng thực hiện các thao tác.
Tích hợp cơ sở dữ liệu: Hệ thống cần kết nối và tương tác tốt với cơ sở dữ liệu để lưu trữ
và truy xuất thông tin đăng ký.
Đa nền tảng: Giao diện người dùng phải tương thích trên nhiều nền tảng và trình duyệt
khác nhau.
b. Mô tả yêu cầu các chức năng và phi chức năng của hệ thống bằng ngôn dạng bảng
Yêu cầu chức năng:
STT Yêu cầu Mô tả
FR1 Đăng nhập Người dùng có khả năng sử dụng tên đăng nhập
và mật khẩu cá nhân để truy cập vào hệ thống.
Sau khi nhập thông tin, hệ thống sẽ xác thực và
cho phép người dùng truy cập vào giao diện
chính của hệ thống. Nếu thông tin đăng nhập
không chính xác, hệ thống sẽ cung cấp thông báo
lỗi tương ứng.
FR2 Đổi mật khẩu Trong trường hợp người dùng quên mật khẩu
hoặc muốn cập nhật mật khẩu, hệ thống cung cấp
chức năng đổi mật khẩu. Người dùng cần cung
cấp mật khẩu hiện tại để xác nhận danh tính và
sau đó nhập mật khẩu mới hai lần để xác nhận.
Hệ thống sẽ kiểm tra tính hợp lệ của mật khẩu
cũ và thực hiện việc cập nhật mật khẩu mới.

FR3 Đăng ký tin chỉ Trong khoảng thời gian mà hệ thống cho phép
đăng ký tín chỉ, sinh viên có thể đăng ký các môn
học. Hệ thống sẽ hiển thị danh sách các môn học
trong kỳ học và ngành đã chọn. Sinh viên có khả
năng chọn số lượng tín chỉ mong muốn và hệ
thống sẽ hiển thị danh sách các môn học có thể
đăng ký dựa trên số tín chỉ đã chọn (sinh viên
học đồng thời tối đa 2 ngành học)

FR4 Hiển thị danh sách môn học Sau khi chọn kỳ học và ngành, hệ thống sẽ hiển
thị danh sách các môn học mà sinh viên đã đăng
ký. Mỗi môn học sẽ được hiển thị với thông tin
chi tiết như mã môn, tên môn, số tín chỉ, giảng
viên, và thời khóa biểu.

FR5 Xem lịch học cá nhân Dựa vào danh sách các môn học đã đăng ký, hệ
thống cho phép sinh viên xem lịch học cá nhân
của mình. Sinh viên có khả năng xem lịch học
theo từng tuần hoặc theo học kỳ, bao gồm thông
tin về thời gian, ngày, phòng học, và giảng viên.
Việc này giúp sinh viên dễ dàng quản lý thời
gian học tập và chuẩn bị cho các buổi học.

FR6 Đăng ký giảng dạy Giảng viên có thể sử dụng chức năng đăng ký
giảng dạy để đăng ký môn học mà giảng viên sẽ
giảng dạy trong kỳ học. Hệ thống cho phép giảng
viên chọn môn học, lớp học phần và thời gian
dạy tương ứng. Quá trình này giúp hệ thống xác
 định thông tin về giảng dạy và hiển thị cho sinh
viên.

FR7 Quản lý thông tin sinh viên Nhân viên giáo vụ có quyền thêm, sửa và xóa
thông tin của sinh viên trong hệ thống. Nếu có
yêu cầu từ phía sinh viên về việc thay đổi lịch
học hoặc thông tin cá nhân, nhân viên giáo vụ sẽ
thực hiện điều chỉnh để đảm bảo tính chính xác
và phù hợp với kế hoạch học tập.

FR8 Quản lý thông tin giảng Khi có yêu cầu thêm, sửa xóa thông tin của giảng
viên viên thì nhân viên giáo vụ sẽ thực hiện chức
năng của mình. Trong trường hợp giảng viên
hủy học phần đã đăng ký thì nhân viên giáo vụ
sẽ điều chỉnh lại theo nguyện vọng của giảng
viên hoặc theo yêu cầu của trường học

FR9 Quản lý thông tin môn học Nhân viên giáo vụ có trách nhiệm quản lý thông
tin về các môn học trong hệ thống. Họ sẽ cập
nhật và điều chỉnh thông tin về các môn học theo
kế hoạch của trường, đảm bảo rằng thông tin về
môn học luôn được cập nhật chính xác và đầy đủ

Yêu cầu phi chức năng:

STT Yêu cầu Mô tả
NFR1 Bảo mật Hệ thống cần đảm bảo tính bảo mật cao, đảm bảo
rằng dữ liệu của sinh viên, giảng viên và thông
tin đăng ký không bị lộ ra ngoài

NFR2 Hiệu suất Hệ thống cần đảm bảo hiệu suất tốt, có khả năng
xử lý nhanh và đáp ứng được nhiều yêu cầu truy
cập cùng lúc trong thời gian đăng ký (Đặc biệt
là trong các khung giờ đăng ký, hạn chế việc xảy
ra việc hệ thống ngừng hoạt động, hoạt động
 chậm khi số lượng sinh viên tham gia đăng ký
quá tải)

NFR3 Giao diện thân thiện Giao diện người dùng phải được thiết kế đơn
giản, thân thiện và dễ sử dụng, giúp người dùng
dễ dàng thực hiện các thao tác.

NFR4 Tích hợp cơ sở dữ liệu Hệ thống cần kết nối và tương tác tốt với cơ sở
dữ liệu để lưu trữ và truy xuất thông tin đăng ký.

NFR5 Đa nền tảng Giao diện người dùng phải tương thích trên
nhiều nền tảng và trình duyệt khác nhau.

4. Trình bày biểu đồ Usecase cho hệ thống

Usecase tổng quan
Các bước thực hiện vẽ biểu đồ usecase tổng quan:
- Bước 1: Đề xuất các actor. Với mỗi người dùng, đề xuất thành một actor tương ứng.
Nếu các actor có đặc điểm gì chung, có thể đề xuất actor trừu tượng thành actor cha
của các actor tương ứng. Ngoài ra, cần xem xét cần có các actor gián tiếp tác động
vào để thực hiện các chức năng hay không.
- Bước 2: Đề xuất use case. Với mỗi chức năng, đề xuất thành một use case tương
ứng
- Bước 3: Mịn hóa các use case. Nếu có ít nhất 2 use case trùng nhau, cần xem xét
gộp lại thành 1. Nếu gộp lại gây hiểu nhầm về số các actor tác động vào, thì có thể
dùng use case trừu tượng cho các use case giống nhau, mỗi use case con liên quan
đến nhóm các actor tương ứng mà thôi.
Áp dụng vẽ usecase tổng quan cho Hệ thống đăng ký tín chỉ
Đề xuất được các actor của hệ thống: sinh viên, giảng viên, nhân viên quản lí, nhân viên
giáo vụ. Tất cả đều có chức năng giống thành viên nên kế thừa từ thành viên. Riêng giảng
viên, nhân viên quản lí, nhân viên giáo vụ còn kế thừa từ actor nhân viên của trường. Nhân
viên kế thừa trực tiếp từ thành viên.
Các chức năng tương ứng với từng actor:
Thành viên: đăng nhập, đổi mật khẩu
Sinh viên: đăng ký tín chỉ, hiển thị danh sách môn học, xem thời khóa biểu
Giảng viên: đăng ký học phần, xem lịch giảng dậy cá nhân, xem thống kê cá nhân
Nhân viên giáo vụ: quản lý sinh viên, quản lý giảng viên, quản lý môn học, quản lý lớp học
phần
Nhân viên quản lý: Xem báo cáo thống kê

Usecase chi tiết

Các bước để vẽ biểu đồ usecase chi tiết
- Bước 1: Trích phần use case của chức năng tương ứng từ biểu đồ use case tổng
quan.
- Bước 2: Phân rã use case chính thành các use case con: mỗi giao diện (hoặc một số
giao diện) tương tác với người dùng có thể đề xuất thành một use case con.
 - Bước 3: Xác định quan hệ của use case con với use case chính: generalization,
include, hay extend.
- Bước 4: Gộp các use case con tương tự nhau bằng cách dùng các use case trừu tượng
tổng quát hơn.
Áp dụng với usecase đăng ký tín chỉ
Đề xuất actor: Sinh viên được kế thừa tất cả các chức năng của người dùng. Sinh viên đăng
nhập vào hệ thống. Hệ thống chuyển sang giao diện đăng ký tín chỉ. Sinh viên tiến thành
đăng ký tín chỉ: chọn môn học, chọn lớp học phần

Áp dụng với usecase đăng ký học phần

Đề xuất actor: Giảng viên được kế thừa từ nhân viên, nhân viên được kế thừa tất cả các
chức năng của người dùng. Giảng viên đăng nhập để vào hệ thống, khi đăng nhập thành
công hệ thống sẽ chuyển đến giao diện của giảng viên. Giảng viên chọn chức năng đăng
ký học phần: chọn môn, chọn lớp học phần
Áp dụng với usecase xem thời khóa biểu
Đề xuất actor: Sinh viên được kết thừa từ người dùng, có các chức năng của người dùng.
Sinh viên sau khi đăng nhập thành công vào hệ thống sẽ được chuyển sang giao diện của
sinh viên. Sinh viên chọn chức năng xem thời khóa biểu. Giao diện hiện ra. Sinh viên chọn
một trong hai chức năng xem thời khóa biểu theo tuần và xem thời khóa biểu theo học kỳ.
Giao diện hiện ra sinh viên chọn kỳ (và tuần đối với xem thời khóa biểu theo tuần) xxeer
xem thời khóa biểu
5. Trình bày biểu đồ activity cho hệ thống
Biểu đồ Activity là một phần quan trọng trong phân tích và thiết kế hệ thống thông tin.
Được sử dụng trong khuôn khổ của UML (Unified Modeling Language), biểu đồ Activity
giúp mô hình hóa và hiểu rõ luồng công việc, quy trình và hoạt động trong hệ thống.
Mục tiêu của Biểu đồ Activity trong phân tích và thiết kế hệ thống thông tin:
- Mô hình hóa luồng công việc: Biểu đồ Activity cho phép mô tả cụ thể các bước và
quyết định trong quy trình làm việc của hệ thống. Điều này giúp xác định các hoạt
động cần thiết để thực hiện một tác vụ cụ thể.
- Hiểu rõ quy trình: Biểu đồ Activity giúp mọi người trong dự án (như nhà phân tích
hệ thống, nhà thiết kế, nhà phát triển và người dùng) hiểu rõ quy trình hoạt động
của hệ thống. Điều này giúp giảm thiểu sự nhầm lẫn và cải thiện sự tương tác giữa
các bên liên quan.
- Xác định logic và điều kiện: Biểu đồ Activity cho phép xác định các điều kiện, quyết
định và nhánh thực hiện khác nhau trong quy trình. Điều này giúp mô hình hóa các
tình huống khác nhau mà hệ thống phải xử lý.
- Phân rã quy trình phức tạp: Biểu đồ Activity có thể được sử dụng để phân rã các
quy trình phức tạp thành các phần nhỏ và quản lý được. Điều này làm cho việc quản
lý và hiểu rõ quy trình trở nên dễ dàng hơn.
- Kiểm tra logic và dòng thời gian: Biểu đồ Activity cho phép kiểm tra logic của quy
trình và xác định dòng thời gian của các hoạt động. Điều này giúp tối ưu hóa quy
trình và xác định các vấn đề có thể xảy ra.
Biểu đồ Activity của sinh viên
Biểu đồ Activity cho giảng viên

6. Trình bày biểu đồ State cho hệ thống

Biểu đồ State trong phân tích và thiết kế hệ thống thông tin có vai trò quan trọng để mô
hình hóa và hiểu rõ quy trình hoạt động của hệ thống. Đây là một công cụ mạnh giúp biểu
diễn các trạng thái khác nhau mà hệ thống có thể tồn tại và cách chúng chuyển đổi theo
thời gian dựa trên các sự kiện và tương tác.
Cách biểu đồ trạng thái có thể được sử dụng trong phân tích và thiết kế hệ thống thông tin:
- Mô hình hóa luồng làm việc: Biểu đồ trạng thái giúp mô tả cách hệ thống hoạt động
từ trạng thái này sang trạng thái khác dưới sự tác động của các sự kiện hoặc hành
động. Điều này giúp hiểu rõ hơn về các bước cần thực hiện để hoàn thành một tác
vụ cụ thể.
 - Xác định luồng điều kiện: Biểu đồ trạng thái cho phép biểu diễn các điều kiện và
quyết định dẫn đến các hành động và chuyển trạng thái khác nhau. Điều này rất hữu
ích khi cần mô tả các kịch bản phức tạp có nhiều điều kiện phụ thuộc vào trạng thái
hiện tại của hệ thống.
- Quản lý trạng thái của đối tượng: Trong hệ thống thông tin, các đối tượng thường
có những trạng thái riêng biệt trong quá trình hoạt động. Biểu đồ trạng thái giúp
hiểu rõ cách mà các trạng thái của đối tượng chuyển đổi khi nhận được các sự kiện
hoặc thực hiện các hành động.
- Hiểu rõ quy trình: Biểu đồ trạng thái giúp biểu diễn và hiểu rõ các quy trình trong
hệ thống thông tin, từ đó tạo ra cơ hội để tối ưu hóa và cải thiện chúng.
Biểu đồ State của sinh viên
Biểu đồ State của giảng viên