PHÂN TÍCH, THIẾT KẾ HỆ THỐNG THÔNG TIN

v Giảng viên: ThS. Nguyễn Đức Hiếu

v Khoa: Công nghệ thông tin
v Bộ môn: Khoa học máy tính
v Email: nguyenduchieu247@gmail.com
v Mobile: 0968.240.787
Mục tiêu

v Có được một cái nhìn tổng quan về khâu nắm bắt yêu cầu.
v Có khả năng đọc, diễn giải và kiểm tra các chế tác của khâu
nắm bắt yêu cầu:
• Phát biểu vấn đề.
• Mô hình ca sử dụng.
• Từ điển thuật ngữ.
• Đặc tả bổ sung.
v Nắm được các chế tác trên ảnh hưởng đến khâu phân tích
và thiết kế hệ thống như thế nào.
2
 Một yêu cầu là gì?

v Một yêu cầu (requirement) là một tuyên bố về những gì hệ thống phải

làm hoặc những đặc tính hệ thống cần phải có (Dennis et al., 2012).
v Trong một SDLC, các yêu cầu sẽ được tạo ra để mô tả:
• Những gì tổ chức cần (business requirements).
• Những gì người dùng cần phải làm (user requirements).
• Những gì phần mềm cần phải làm (functional requirements).
• Những đặc tính hệ thống cần phải có (nonfunctional requirements).
• Hệ thống cần phải được xây dựng như thế nào (system requirements).

3
 Ví dụ các yêu cầu chức năng

v Hướng tiến trình (process-oriented): Tiến trình hệ thống phải thực hiện.
• Hệ thống phải cho phép khách hàng (đã đăng ký tài khoản) xem lại lịch sử
order của họ trong ba năm qua (e.g., một nhu cầu tiến trình).
• Hệ thống phải kiểm tra các đơn đặt hàng của khách hàng để kiểm kê hàng
tồn kho (e.g., một nhu cầu tiến trình).
v Hướng thông tin (information-oriented): Thông tin hệ thống phải chứa.
• Hệ thống phải lưu giữ lịch sử order của khách hàng trong ba năm (e.g., một
nhu cầu thông tin).
• Hệ thống phải duy trì thông tin tồn kho theo thời gian thực (e.g., một nhu cầu
thông tin).
4
 Ví dụ các yêu cầu phi chức năng

v Vận hành: Các môi trường vật lý hoặc thuộc về kỹ thuật mà hệ thống sẽ vận
hành trên đó.
• Hệ thống có thể chạy trên các thiết bị di động (e.g.).
• Hệ thống có khả năng hoạt động trên mọi trình duyệt Web (e.g.).
v Hiệu năng: Tốc độ, khả năng lưu trữ và độ tin cậy của hệ thống.
• Bất cứ tương tác nào giữa người dùng và hệ thống đều không được vượt quá 5s (e.g.).
• Hệ thống hỗ trợ 300 người dùng đồng thời từ 8h A.M đến 4h P.M (e.g.).
v An ninh: Ai được uỷ quyền truy cập hệ thống, trong những trường hợp nào?
• Khách hàng chỉ có thể xem lịch sử order của mình trong giờ làm việc (e.g.).
• Chỉ manager mới có thể xem hồ sơ của cán bộ, nhân viên mà mình trực tiếp quản lý.
v Văn hoá và chính trị: Các yếu tố văn hoá, chính trị và các yêu cầu pháp lý
ảnh hưởng đến hệ thống.
5
 Tầm quan trọng của khâu nắm bắt yêu cầu

v Để tìm ra giải pháp đúng cho một hệ thống phần mềm -> hiểu
được những yêu cầu đặt ra cho hệ thống.
v Câu hỏi đặt ra ở đây là ”Hệ thống phải làm gì?”.
v Luồng công việc “Mô hình hoá nghiệp vụ”:
• Cung cấp ngữ cảnh để tiến hành xác định và phân tích các yêu cầu.
• Hiểu chính xác về quy trình nghiệp vụ.
v Thu thập và xác định yêu cầu sai -> hệ thống bị phát triển sai, không
đáp ứng được mong đợi của khách hàng.

6
 Mục đích của khâu nắm bắt yêu cầu

v Thiết lập và duy trì những thoả thuận với khách hàng và các bên liên
quan về những gì HT cần phải làm.
v Cung cấp cho các nhà phát triển HT hiểu rõ hơn về các yêu cầu HT.
v Xác định biên của HT.
v Cung cấp một cơ sở cho việc lập kế hoạch những nội dung kỹ thuật của
các lần lặp.
v Cung cấp một cơ sở cho việc ước tính chi phí và thời gian phát triển HT.
v Định hình giao diện tương tác giữa người dùng và HT, qua đó làm rõ
được nhu cầu và mục tiêu của người dùng đối với HT.
7
 Các chế tác của khâu nắm bắt yêu cầu

v Phát biểu vấn đề (Problem Statement).

v Mô hình ca sử dụng (Use-Case Model).
v Từ điển thuật ngữ (Glossary).
v Đặc tả bổ sung (Supplementary Specification).

8
 Tài liệu phát biểu vấn đề

v Tài liệu phát biểu vấn đề là một phần của tài liệu tổng thể hệ
thống (vision document).
v Tài liệu phát biểu vấn đề làm rõ thực trạng của hệ thống hiện
thời (vấn đề, khó khăn …) -> chỉ ra được lý do và động lực
chính để phát triển hệ thống.
v Tài liệu phát biểu vấn đề có thể bao gồm các ràng buộc khác
nhau đặt ra cho hệ thống (ràng buộc về kỹ thuật, ràng buộc về
thời gian, ràng buộc về nguồn lực …).

9
 Hành vi hệ thống là gì?

v Không có hệ thống nào tồn tại riêng biệt, mỗi hệ thống tương tác với
con người hoặc các hệ thống tự động vì một số mục đích nào đó.
• Kết quả có thể dự đoán của những tương tác trên là hành vi hệ thống.
v Hành vi hệ thống là cách một hệ thống hành động và phản ứng.
• Hoạt động bên ngoài có thể thấy và kiểm tra được của hệ thống.
v Hành vi hệ thống được nắm bắt trong các ca sử dụng.
• Các ca sử dụng là cơ chế để nắm bắt hành vi mong muốn của hệ thống
đang được xây dựng, chúng không chỉ ra cách hành vi được thực hiện.
v UML chỉ định một loại mô hình để truyền đạt hành vi hệ thống -> mô
hình ca sử dụng.
10
 Các khái niệm chính trong
mô hình hoá ca sử dụng

v Một tác nhân đại diện cho bất cứ thứ gì tương tác với hệ thống.

Actor
v Một ca sử dụng là một chuỗi các hành động mà hệ thống thực
hiện nhằm mang lại một kết quả (giá trị) có thể quan sát được
bởi một tác nhân cụ thể.

Use Case

11
 Mô hình ca sử dụng là gì?

v Một mô hình mô tả các yêu cầu chức năng của một hệ thống dưới
dạng các ca sử dụng.
v Một mô hình về chức năng dự kiến của hệ thống (các ca sử dụng)
và môi trường của hệ thống (các tác nhân).
v Mô hình ca sử dụng được sử dụng trong tất cả các giai đoạn
của vòng đời phát triển hệ thống.
v Các chế tác tạo nên mô hình ca sử dụng bao gồm các đặc tả
ca sử dụng và các biểu đồ hoạt động.

12
 Vai trò của mô hình ca sử dụng

v Mô tả những gì hệ thống sẽ làm.

v Đóng vai trò như một sự cam kết giữa khách hàng, người dùng và
bên phát triển hệ thống.
• Cho phép khách hàng và người dùng kiểm tra xem hệ thống đang được
xây dựng có đúng như mong đợi của họ hay không.
• Cho phép bên phát triển đảm bảo rằng hệ thống họ đang xây dựng đúng
với mong đợi của khách hàng và người dùng.
v Vai trò quan trọng nhất của mô hình ca sử dụng là truyền đạt hành
vi của hệ thống tới khách hàng hoặc người dùng cuối.

13
Vai trò của mô hình ca sử dụng (tt.)

14
 Tài liệu đặc tả ca sử dụng
v Mỗi ca sử dụng trong mô hình ca sử dụng mô tả chi tiết:
• Làm thế nào hệ thống tương tác với các tác nhân.
• Những gì hệ thống làm trong quá trình tương tác với các tác nhân.
ÞTài liệu đặc tả ca sử dụng.
v Tài liệu đặc tả ca sử dụng sẽ định hướng cho các hoạt động phân tích
và thiết kế về sau.
v Ca sử dụng có một tập các thuộc tính, chúng có thể được ghi lại trong
tài liệu đặc tả ca sử dụng.
• Brief description: Mô tả vai trò và mục đích của ca sử dụng.
• Flow of events: Mô tả dạng văn bản về những gì hệ thống thực hiện liên quan
đến ca sử dụng (e.g., một luồng sự kiện chính và các luồng sự kiện thay thế).
• Relationships: Các liên kết giao tiếp giữa các ca sử dụng.
15
 Tài liệu đặc tả ca sử dụng (tt.)

• Activity diagrams: Sử dụng để minh hoạ cấu trúc luồng các sự kiện.
• Use-case diagrams: Sử dụng để chỉ ra các mối quan hệ liên quan đến UC.
• Special requirements: Một mô tả dạng văn bản thu thập tất cả các yêu cầu,
thường là các yêu cầu phi chức năng (không được đề cập trong mô hình ca sử
dụng) được sử dụng như các ràng buộc trong quá trình thiết kế và cài đặt.
• Pre-conditions: Định nghĩa một ràng buộc lên hệ thống về thời điểm ca sử
dụng có thể bắt đầu.
• Post-conditions: Định nghĩa một ràng buộc lên hệ thống ngay sau khi ca sử
dụng kết thúc.
• Other diagrams: Sử dụng để minh hoạ cho ca sử dụng (e.g., các bản vẽ hoặc
ảnh chụp màn hình từ một bản mẫu giao diện người dùng).
16
 Ví dụ một tài liệu đặc tả ca sử dụng
“Tìm kiếm sản phẩm”
Use Case Tìm kiếm sản phẩm
Actor User hoặc Visitor
Use Case này mô tả cách một User hoặc một Visitor tìm kiếm sản phẩm
Brief Description
trên Website bán hàng XYZ.
Pre-conditions Không có
Use Case này bắt đầu khi User/Visitor muốn tìm kiếm sản phẩm trên
Website bán hàng XYZ:
1. Hệ thống hiển thị một form (có thể nhập và chỉnh sửa thông tin) với các
tiêu chí tìm kiếm như sau:
• Danh mục
Basic Flows • Tên sản phẩm
• Phạm vi giá
• Kích cỡ
2. The User/Visitor nhập tiêu chí tìm kiếm sản phẩm. Khi User/Visitor chọn
thực hiện tìm kiếm, hệ thống sẽ thực hiện một truy vấn trong cơ sở dữ
liệu sản phẩm và hiển thị kết quả tìm kiếm.
Nếu User/Visitor không chỉ định tiêu chí tìm kiếm nào, hệ thống sẽ hiển thị
Alternative Flows một thông báo lỗi. User/Visitor có thể chỉ định lại tiêu chí tìm kiếm hoặc hủy
thao tác tìm kiếm.
Nếu Use Case này được thực hiện thành công, một danh sách các sản
Post-conditions
phẩm thỏa mãn tiêu chí tìm kiếm chỉ định được hiển thị.
Special Requirements Không có
17
 Kịch bản là gì?

v Một kịch bản (scenario) là một thể hiện của một ca sử dụng.
v Mỗi ca sử dụng có một kịch bản là một thể hiện của một luồng các
sự kiện cụ thể, kịch bản đó có thể liên quan đến luồng sự kiện
chính và bất cứ luồng sự kiện thay thế nào.
v Đối với các ca sử dụng có rủi ro cao -> soạn thảo kỹ lưỡng các kịch bản.
v Các kịch bản được sử dụng để hiểu, thẩm định các luồng sự kiện
của ca sử dụng.
v Một số người viết các kịch bản trước, sau đó trích xuất các ca sử dụng.
Một số người tìm các ca sử dụng trước, sau đó thẩm định chúng bằng
cách viết các kịch bản.
18
 Ví dụ một kịch bản ca sử dụng “Đặt mượn sách”

Một người dùng đứng trước một máy vi tính:

1. Hệ thống hiển thị một thông điệp chào mừng.
2. Người dùng chọn chức năng đặt mượn.
3. Hệ thống yêu cầu người dùng đăng nhập.
4. Người dùng nhập thông tin để đăng nhập hệ thống.
5. Hệ thống yêu cầu chọn sách muốn đặt mượn.
6. Người dùng chọn sách muốn đặt mượn.
7. Hệ thống chuyển trạng thái sách đó thành đã đặt mượn.

19
 Biểu đồ tuần tự hệ thống

v Một biểu đồ tuần tự hệ thống (system sequence diagram) là

một chế tác được tạo ra nhanh chóng và dễ dàng, nó được sử
dụng để minh hoạ các sự kiện đầu vào và đầu ra liên quan đến HT.
v UML sử dụng ký hiệu dưới hình thức biểu đồ tuần tự để minh hoạ
các sự kiện từ các tác nhân bên ngoài đến hệ thống trong biểu đồ
tuần tự hệ thống.
v Hệ thống như một hộp đen.
v Biểu đồ tuần tự hệ thống được sử dụng để đặc tả các kịch bản ca
sử dụng và quy trình nghiệp vụ.
20
Ví dụ biểu đồ tuần tự hệ thống cho
một kịch bản “Process Sale”

21
Ví dụ đặc tả ca sử dụng “Đăng ký môn học”
với biểu đồ hoạt động

Select Course

[ delete course ]
Delete Course
[ add course ]

Check Check
Schedule Pre-requisites

[ checks completed ] [ checks failed ]

Assign to Resolve
Course Conflicts

Update
Schedule

22
 Từ điển thuật ngữ
v Từ điển thuật ngữ định nghĩa các thuật ngữ trong miền vấn đề của hệ
thống, nó chứa các mô tả ở dạng văn bản và được dùng chung cho tất
cả các mô hình của hệ thống.
v Từ điển thuật ngữ cung cấp cho các nhà phát triển một cách hiểu thống nhất
để sử dụng các thuật ngữ quan trọng dành riêng cho dự án và tạo được sự
thuận tiện trong giao tiếp giữa các chuyên gia miền và các nhà phát triển.
v Từ điển thuật ngữ chủ yếu được tạo ra trong pha khởi đầu (Inception) và pha
chi tiết (Elaboration).
v Các chuyên gia miền sử dụng từ điển thuật ngữ để giải thích tất cả các thuật ngữ chuyên
biệt miền, giúp các nhà phát triển hiểu được chính xác các kịch bản trong ca sử dụng.
v Trong pha xây dựng (Construction), các nhà phát triển sử dụng từ điển thuật ngữ để giải
thích các thuật ngữ kỹ thuật trong các mô hình thiết kế.

v Tài liệu từ điển thuật ngữ thường có một định dạng riêng. 23
Một phác thảo mẫu cho từ điển thuật ngữ

24
 Đặc tả bổ sung

v Đặc tả bổ sung chứa các yêu cầu không được nắm bắt bởi các ca
sử dụng (e.g., các yêu cầu phi chức năng).
v Đặc tả bổ sung là một sự bổ sung quan trọng cho mô hình ca sử
dụng, chúng cùng nhau nắm bắt tất cả các yêu cầu cần được mô tả
cho một đặc tả yêu cầu hệ thống hoàn chỉnh.
v Đặc tả bổ sung bao gồm các yêu cầu liên quan đến:
• Tính khả dụng (usability).
• Độ tin cậy (reliability).
• Hiệu năng (performance).
• Khả năng hỗ trợ (supportability) và khả năng bảo trì (maintainability).
• Các ràng buộc thiết kế. 25
 Kiểm tra mô hình ca sử dụng

v Mô hình ca sử dụng có dễ hiểu không?

v Có thể hình thành một ý tưởng rõ ràng về các chức năng của hệ
thống và chúng có liên quan với nhau như thế nào thông qua
mô hình ca sử dụng?
v Tất cả các yêu cầu chức năng đã được đáp ứng?
v Mô hình ca sử dụng có chứa hành vi thừa nào không?
v Việc phân chia mô hình thành các gói ca sử dụng có phù hợp?

26
 Kiểm tra các đặc tả ca sử dụng

v Ai muốn thực hiện ca sử dụng có được mô tả rõ?

v Mục đích của ca sử dụng có được mô tả rõ?
v Có mô tả ngắn gọn về ca sử dụng?
v Khi nào và làm thế nào luồng các sự kiện của ca sử dụng bắt
đầu và kết thúc có được mô tả rõ?
v Trình tự trao đổi thông tin giữa tác nhân và ca sử dụng có chiếu
theo mong đợi của người dùng?
v Tác nhân tương tác và trao đổi thông tin có được mô tả rõ?
v Có ca sử dụng quá phức tạp?
27
Kiểm tra từ điển thuật ngữ

v Mỗi thuật ngữ có một định nghĩa rõ ràng và súc tích

hay không?
v Mỗi thuật ngữ trong từ điển thuật ngữ có trong các
mô tả ca sử dụng hay không?
v Các thuật ngữ được sử dụng có tính nhất quán trong
các mô tả ngắn gọn về các tác nhân và ca sử dụng
hay không?
28