1. GV: Phan Thị Kim Loan
Mô hình hoá yêu cầu

2. 3- Mô hình hoá yêu cầu
Nội dung trước
Hệ thống hướng chức năng vs. Hệ thống hướng đối tượng
Các đặc điểm cơ bản của hệ thống hướng đối tượng
Giới thiệu UML – UML 2.0
Phân tích thiết kế hướng đối tượng với UML 2.0
2

3. 3- Mô hình hoá yêu cầu
3
Nội dung
Mô hình hóa yêu cầu:
Lược đồ Use-case
Khái niệm Actor và Usecase
Ví dụ
Mô hình hóa các dòng dữ liệu của mỗi Use-case
Giới thiệu Mô hình DFD
Sử dụng mô hình DFD để mô hình hóa yêu cầu lưu trữ, tra cứu, tính toán, kết xuất

4. 3- Mô hình hoá yêu cầu
Mục tiêu
Tìm hiểu các khái niệm cơ bản về xác định yêu cầu người dùng và tác dụng của chúng lên Phân tích và Thiết kế
Tìm hiểu cách ghi nhận và diễn dịch các yêu cầu của người dùng, là những thông tin được dùng để bắt đầu việc phân tích và thiết kế
4

5. 3- Mô hình hoá yêu cầu
Các yêu cầu người dùng trong ngữ cảnh
5
IBM _ Rational Unified Process

6. 3- Mô hình hoá yêu cầu
Các yêu cầu người dùng trong ngữ cảnh
6
IBM _ Rational Unified Process
Mục đích của bước xác định yêu cầu người dùng là: • Ði đến thỏa thuận với khách hàng về các chức năng của hệ thống (những gì hệ thống phải thực hiện). • Cho phép các nhà phát triển hệ thống (system developer) hiểu rõ hơn các yêu cầu đối với hệ thống. • Phân định các ranh giới của hệ thống. • Cung cấp cơ sở để hoạch định nội dung kỹ thuật của các vòng lặp. • Xác định giao diện người dùng cho hệ thống.

7. 3- Mô hình hoá yêu cầu
Các dạng thông về yêu cầu người dùng
 Use case Model
Các Use Case
Use Case Report
Bảng chú giải
Các đặc tả bổ sung
7

8. 3- Mô hình hoá yêu cầu
Mở đầu
Đặt vấn đề:
Các mô tả về yêu cầu trong giai đoạn xác định yêu cầu:
•Chỉ mô tả chủ yếu các thông tin liên quan đến việc thực hiện các nghiệp vụ trong thế giới thực, chưa thể hiện rõ nét việc thực hiện các nghiệp vụ trên máy tính
•Mô tả thông quá các văn bản dễ gây ra nhầm lẫn và không trực quan
 Mô hình hóa yêu cầu
8

9. 3- Mô hình hoá yêu cầu
Khái niệm Actor
9
Tên Actor
Tác nhân BÊN NGOÀI hệ thống
Có tương tác với hệ thống
Phần mềm
Con người
Phần cứng
Phần mềm khác

10. 3- Mô hình hoá yêu cầu
Actor
An actor represents anything that interacts with the system. An actor is EXTERNAL!
Actors are not part of the system, they represent roles a user of the system can play.
An actor may actively interchange information with the system.
An actor may be a passive recipient of information.
An actor can represent a human, a machine or another system.
10

11. 3- Mô hình hoá yêu cầu
Actor  Nhóm người sử dụng
11
Tên Actor
Tác nhân BÊN NGOÀI hệ thống
Có tương tác với hệ thống
Phần mềm
Con người
Phần cứng
Phần mềm khác

12. 3- Mô hình hoá yêu cầu
Actor Generalization
12
Student
Full-time Student
Part-time Student

13. 3- Mô hình hoá yêu cầu
1 User có thể có nhiều vai trò (Role)
13
Student
Lecturer
John
John có vai trò như
Một sinh viên
John có vai trò như
Một giảng viên

14. 3- Mô hình hoá yêu cầu
Actors & System Boundary
14
System Boundary – Giới hạn của hệ thống

15. 3- Mô hình hoá yêu cầu
Ví dụ
STT
Yêu cầu
1
Tiếp nhận học sinh
2
Lập danh sách lớp
3
Tra cứu học sinh
4
Nhận bảng điểm môn
5
Xem báo cáo tổng kết
6
Thay đổi quy định
15
Nhóm người dùng
Giáo vụ?
Giáo vụ?
Mọi người? Phụ huynh? Học sinh?
Giáo viên? Giáo vụ?
Ban giám hiệu?
Ban giám hiệu? Quản trị hệ thống?
Xét phần mềm Quản lý học sinh cấp III
Một nhóm người dùng = một Actor
Mỗi Nhóm người dùng (Actor) được quyền sử dụng một hay nhiều chức năng trong hệ thống
Một chức năng có thể cho phép nhiều Nhóm người dùng sử dụng
Nhiều nhóm người dùng có cùng các quyền hạn giống nhau
Việc xác định Actor phụ thuộc ngữ cảnh và quy trình thực tế

16. 3- Mô hình hoá yêu cầu
Actor  Phần cứng ngoại vi
16
Tên Actor
Tác nhân BÊN NGOÀI hệ thống
Có tương tác với hệ thống
Phần mềm
Con người
Phần cứng
Phần mềm khác

17. 3- Mô hình hoá yêu cầu
Ví dụ
Ví dụ:
Phần mềm quản lý Siêu thị:
•Đọc thông tin từ thiết bị đọc mã vạch
Phần mềm quản lý cửa tự động:
•Đọc thông tin từ camera
•Phát lệnh điều khiển mở cửa
Phần mềm quản lý ra vào các phòng trong công sở
•Đọc tín hiệu từ đầu đọc thẻ từ
•Phát lệnh điều khiển mở cửa
Phần mềm chống trộm
•Đọc tín hiệu từ camera, sensor
•Phát lệnh điều khiển ra loa, đèn, điện thoại…
17
Các thiết bị ngoại vi mà phần mềm cần tương tác
Có cần liệt kê tất cả thiết bị ngoại vi?

18. 3- Mô hình hoá yêu cầu
Actor  Phần mềm khác
18
Tên Actor
Tác nhân BÊN NGOÀI hệ thống
Có tương tác với hệ thống
Phần mềm
Con người
Phần cứng
Phần mềm khác

19. 3- Mô hình hoá yêu cầu
Ví dụ
Kết xuất/nạp dữ liệu từ Excel
Kết xuất dữ liệu báo cáo ra phần mềm gửi email (Microsoft Outlook, Outlook Express…)
Phần mềm trung gian kết nối để chuyển đổi email từ dạng Web-based sang POP3 (ví dụ Yahoo!Pop)
…
19

20. 3- Mô hình hoá yêu cầu
Use-Case
Khái niệm Use-Case
 Một Use-Case là một chuỗi các hành động mà hệ thống thực hiện mang lại một kết quả quan sát được đối với actor.
 Có thể hiểu một Use-Case là một chức năng của hệ thống, mang một ý nghĩa nhất định đối với người dùng
20

21. 3- Mô hình hoá yêu cầu
Ví dụ
STT
Yêu cầu
1
Tiếp nhận học sinh
2
Lập danh sách lớp
3
Tra cứu học sinh
4
Nhận bảng điểm môn
5
Xem báo cáo tổng kết
6
Thay đổi quy định
21
Xét phần mềm Quản lý học sinh cấp III
Có bao nhiêu Use-case trong Ví dụ này?
Bao gồm cả tính năng Thêm mới, Xóa, và Sửa

22. 3- Mô hình hoá yêu cầu
Ví dụ
22
STT
Yêu cầu
1
Sắp đặt mạch điện
2
Cung cấp nguồn điện
3
Thay đổi thông số
4
Lưu bài thí nghiệm
5
Lấy lại thí nghiệm
6
Thay đổi quy định
Phần mềm thí nghiệm mạch điện
Có bao nhiêu Use-case trong Ví dụ này?

23. 3- Mô hình hoá yêu cầu
Sơ đồ Use-case
23
Rút tiền
Khách hàng
Kiểm tra tài khoản
Sự tương tác giữa Actor và Use-case
Chiều của mũi tên thể hiển vai trò chủ động trong sự tương tác

24. 3- Mô hình hoá yêu cầu
Tổng quát hóa giữa các Actor
24
Người sử dụng
Giáo viên
Giáo vụ

25. 3- Mô hình hoá yêu cầu
Mô tả Use-case
1. Use-Case bắt đầu khi khách hàng đưa thẻ tín dụng vào. Hệ thống đọc và thẩm tra thông tin của thẻ.
2. Hệ thông nhắc nhập số PIN. Hệ thống kiểm tra số PIN.
3. Hệ thống hỏi tác vụ nào khách hàng muốn thực hiện. Khách hàng chọn “Rút tiền.”
4. Hệ thống hỏi số lượng. Khách hàng nhập số lượng.
5. Hệ thống yêu cầu nhập kiểu tài khoản. Khách hàng chọn checking hoặc savings.
6. Hệ thống liên lạc với ATM network . . .
25

26. 3- Mô hình hoá yêu cầu
Mô tả use-case
basic flow (“Happy Path”)
Một số alternative flows
Các biến thể thường gặp (Regular variants)
Các trường hợp bất thường (Odd cases)
Exceptional flows xử lý các tình huống lỗi
26
“Happy Path”

27. 3- Mô hình hoá yêu cầu
Variations trong 1 use case
 VD: Khách hàng có thể chọn các loại giao dịch ATM sau:
Rút tiền ra
Kiểm tra tiền trong tài khoản
Điểu kiện gây ra lỗi là những bước tiến hành bất bình thường trong 1 Use Case.
VD:
Mức tiền trong TK không đủ để tiến hành giao dịch
Password nhập không đúng
ATM bị nghẽn thẻ
27

28. 3- Mô hình hoá yêu cầu
28
K
Rút tiền
K.H đưa thẻ vào ATM
Nhập password
Đúng ?
Chọn giao dịch
Đúng ?
Tiếp tục xử lý
Chọn
Tiếp tục xử lý
Tiếp tục xử lý
Tiếp tục xử lý
Điều kiện gây lỗi
Điều kiện gây lỗi
K
Thay thế bình thường
Thay thế bình thường
C
C
Vấn số dư
Vd: Các tiến tình trong hệ thống ATM

29. 3- Mô hình hoá yêu cầu
Quan hệ giữa các Use Case
 Có 3 loại:
Quan hệ sử dụng(<<uses>> hay <<includes>>)
Quan hệ mở rộng(<<extends>>)
Quan hệ kế thừa(<<generalization>>)
29

30. 3- Mô hình hoá yêu cầu
Quan hệ <<includes>>
Một nhóm các Use Case có chung 1 hành vi.
Tách hành vi đó thành 1 use case riêng (Included UC)
Use case tách riêng được các use case khác sử dụng tạo nên quan hệ <<uses>> hay <<includes>>
Biểu diễn:
Đoạn thẳng nét đứt
Với hình tam giác rỗng
Trỏ về phía UC được sử dụng
Đi kèm stereotype
<<includes>>
30
Rút tiền từ tài khoản
Kiểm tra chữ ký
In kết quả
<<includes>>
<<includes>>

31. 3- Mô hình hoá yêu cầu
Quan hệ <<extends>>
31
 Một UC cung cấp 1 phần các chức năng cần thiết cho 1 UC mới.
 UC mới = UC cũ (Base Use Case) + thêm chức năng mới.
 UC mới = UC mở rộng (Extended Use Case)
 UC mở rông không nhất thiết phải dùng toàn bộ hành vi của UC gốc
Biểu diễn:
Đoạn thẳng nét đứt
Với hình tam giác rỗng
Trỏ về phía UC gốc
Đi kèm stereotype <<extend>>
QL loại hàng
QL đơn vị tính
<<extends>>
<<extends>>
QL thông tin hàng hóa

32. 3- Mô hình hoá yêu cầu
Quan hệ <<generalization>
32
 Một số UC cùng xử lý các chức năng tương tự --> gom nhóm
 Cung cấp giá trị gia tăng cho thiết kế

Biểu diễn:
Các đoạn thẳng liền
Với hình tam giác rỗng
Trỏ về phía UC gốc
Đi kèm stereotype <<generalises>>
Make appointment
Make old appointment
Make new appointment
<<generalises>>

33. 3- Mô hình hoá yêu cầu
Sơ đồ luồng dữ liệu
Các ký hiệu
33
Tác nhân/thiết bị (Người sử dụng, thiết bị phát sinh hay tiếp nhận dữ liệu)
Khối xử lý
Luồng dữ liệu (thông tin)
Bộ nhớ phụ (Hồ sơ, Sổ sách, tập tin, csdl…)

34. 3- Mô hình hoá yêu cầu
Các cấp sơ đồ
Các cấp sơ đồ
Cấp 0: Toàn bộ phần mềm là một khối xử lý
Cấp 1: Sơ đồ cấp 0 có thể phân rã thành nhiều sơ đồ cấp 1, các sơ đồ cấp 1 này phải đảm bảo thể hiện đầy đủ ý nghĩa sở đồ cấp 0 (tác nhân, thiết bị, luồng dữ liệu, xử lý, bộ nhớ phụ)
Cấp 2: Mỗi sơ đồ cấp 1 lại có thể phân rã thành nhiều sơ đồ cấp 2 tương tự như việc phân rã của sơ đồ cấp 0
…
34

35. 3- Mô hình hoá yêu cầu
Ví dụ: sơ đồ cấp 0
35
Configuration Information
Configuration
Data
Configuration
Data

36. 3- Mô hình hoá yêu cầu
Ví dụ: sơ đồ cấp 1
36

37. 3- Mô hình hoá yêu cầu
Sơ đồ tổng quát
37
Người dùng
Thiết bị nhập
Thiết bị xuất
Xử lý …
D1
D2
D3
D4
D5
D6
Ý nghĩa từng dòng dữ liệu D1:……………. D2:……………. D3:……………. D4:……………. D5:……………. D6:…………….
Thuật toán xử lý:
-Bước 1:………………
-Bước 2:………………
-Bước 3:………………
-………………………..
Dữ liệu nhập
Dữ liệu xuất
Dữ liệu đọc
Dữ liệu ghi

38. 3- Mô hình hoá yêu cầu
Sơ đồ tổng quát cho Yêu cầu lưu trữ
D1: Thông tin cần lưu trữ (dựa vào biểu mẫu liên quan)
D5: Thông tin cần lưu trữ (chỉ có trong một số yêu cầu đặc biệt)
D3:
Các danh mục để chọn lựa
Dữ liệu cần thiết cho việc kiểm tra tính hợp lệ (dựa vào quy định)
D2:
Các danh mục để chọn lựa
Kết quả thành công/thất bại
D4: Dữ liệu được lưu trữ (dựa vào biểu mẫu).
Ghi chú: Thông thường
D4 = D1 (+ D5) (+ ID tự phát sinh)
D6: Dữ liệu kết xuất (chỉ có trong một số yêu cầu đặc biệt)
38
Người dùng
Thiết bị nhập
Thiết bị xuất
Xử lý LT
D1
D2
D3
D4
D5
D6

39. 3- Mô hình hoá yêu cầu
Sơ đồ tổng quát cho Yêu cầu lưu trữ
Xử lý lưu trữ
Đọc D3 để lấy các tham số, quy định và danh mục
Hiển thị D2 (các danh mục)
Nhận thông tin D1, D5 (nếu cần)
Kiểm tra các thông tin D1, D5 có thỏa quy định liên quan hay không (dựa vào D3 nếu cần thiết)
Nếu thỏa quy định, ghi D4, thông báo kết quả D2 (nếu cần) và xuất D6 (nếu cần thiết)
39
Người dùng
Thiết bị nhập
Thiết bị xuất
Xử lý LT
D1
D2
D3
D4
D5
D6

40. 3- Mô hình hoá yêu cầu
Sơ đồ tổng quát cho Yêu cầu lưu trữ
Ghi chú:
D1 không nhất thiết chứa toàn bộ thông tin trong biểu mẫu liên quan
Tùy theo quy định có thể có hay không có D5
D4 hoặc D6 không nhất thiết phải trùng với D1 hoặc D5
D2 không nhất thiết phải trùng với D3
40
Người dùng
Thiết bị nhập
Thiết bị xuất
Xử lý LT
D1
D2
D3
D4
D5
D6

41. 3- Mô hình hoá yêu cầu
Sơ đồ tổng quát cho Yêu cầu tra cứu
D1: Thông tin về đối tượng muốn tìm kiếm (dựa vào biểu mẫu liên quan đến đối tượng cần tìm kiếm)
D5: Thông tin về đối tượng muốn tìm kiếm (chỉ có trong một số yêu cầu đặc biệt)
D3:
Các danh mục để chọn lựa
Dữ liệu về đối tượng khi tìm thấy (dựa vào biểu mẫu liên quan đến đối tượng cần tìm kiếm)
D2:
Các danh mục để chọn lựa
Dữ liệu về đối tượng khi tìm thấy (dựa vào biểu mẫu liên quan đến đối tượng cần tìm kiếm)
D6: Dữ liệu kết xuất (thông thường là cần thiết)
D4: Dữ liệu cần lưu trữ lại
Thông thường không cần thiết
Cần thiết khi nào???
41
Người dùng
Thiết bị nhập
Thiết bị xuất
Xử lý TC
D1
D2
D3
D4
D5
D6

42. 3- Mô hình hoá yêu cầu
Sơ đồ tổng quát cho Yêu cầu tra cứu
Xử lý tra cứu
Đọc để lấy các danh mục (D3)
Hiển thị D2 (các danh mục)
Nhận thông tin về tiêu chí tìm kiếm D1, D5 (nếu cần)
Tìm kiếm theo các tiêu chí D1, D5, nhận được danh sách các đối tượng tìm được (D3)
Hiển thị thông tin kết quả (D2) và kết xuất D6 (nếu cần)
42
Người dùng
Thiết bị nhập
Thiết bị xuất
Xử lý TC
D1
D2
D3
D4
D5
D6

43. 3- Mô hình hoá yêu cầu
Sơ đồ tổng quát cho Yêu cầu tra cứu
Ghi chú:
Có rất nhiều mức độ khác nhau từ rất đơn giản đến rất phức tạp để xác định D1
D1 chức nhiều thông tin thì việc tìm kiếm sẽ dễ dàng cho người dùng và ngược lại sẽ khó khăn cho phần thiết kế và cài đặt chức năng này
D3 thông thường là danh sách các đối tượng tìm thấy cùng với thông tin liên quan.
D3 cũng có rất nhiều mức độ khác nhau để xác định các thông tin của đối tượng tìm thấy
D2 và D6 thường trùng với D3 (nhưng không nhất thiết)
43
Người dùng
Thiết bị nhập
Thiết bị xuất
Xử lý TC
D1
D2
D3
D4
D5
D6

44. 3- Mô hình hoá yêu cầu
Sơ đồ tổng quát cho Yêu cầu tính toán
D1: Thông tin về đối tượng cần thực hiện việc xử lý tính toán (dựa vào các biểu mẫu liên quan)
D5: Thông tin về đối tượng cần thực hiện việc xử lý tính toán (chỉ có trong một số yêu cầu đặc biệt)
D3:
Dữ liệu cần thiết cho việc xử lý tính toán (dựa vào biểu mẫu và quy định liên quan)
Các tham số tính toán
D4: Kết quả của xử lý tính toán
D2: Kết quả của xử lý tính toán (thường gồm cả D3 và D4)
D6: Dữ liệu kết xuất (thường gồm cả D3 và D4)
44
Người dùng
Thiết bị nhập
Thiết bị xuất
Xử lý TT
D1
D2
D3
D4
D5
D6

45. 3- Mô hình hoá yêu cầu
Sơ đồ tổng quát cho Yêu cầu tính toán
Xử lý tính toán
Nhận thông tin D1, D5 (nếu cần)
Đọc D3 để lấy các dữ liệu cần thiết cho việc tính toán (kể cả các tham số)
Sử dụng D1, D3, D5 và quy định liên quan để tính kết quả D4
Ghi kết quả D4
Hiển thị thông tin kết quả D2 và kết xuất D6
45
Người dùng
Thiết bị nhập
Thiết bị xuất
Xử lý TT
D1
D2
D3
D4
D5
D6

46. 3- Mô hình hoá yêu cầu
Sơ đồ tổng quát cho Yêu cầu tính toán
Ghi chú:
D1 thường có chứa yếu tố thời gian thực hiện xử lý tính toán
Có nhiều mức độ khác nhau xác định D1 trong xử lý tính toán (để tăng tính tiện dụng)
D1 có thể rỗng (tính toán cho mọi đối tượng trong tất cả cột mốc thời gian liên quan)
D4 có thể có hay không có
=> Khi nào cần D4?
Thông thường D2 và D6 bao gồm D3 và D4
46
Người dùng
Thiết bị nhập
Thiết bị xuất
Xử lý TT
D1
D2
D3
D4
D5
D6

47. 3- Mô hình hoá yêu cầu
Sơ đồ tổng quát cho Yêu cầu báo biểu
D1: Thông tin về báo biểu muốn thực hiện (dựa vào biểu mẫu liên quan)
D5: Thông tin về báo biểu muốn thực hiện (chỉ có trong một số yêu cầu đặc biệt)
D3: Dữ liệu cần thiết cho việc tưực hiện báo biểu (dựa vào biểu mẫu và quy định liên quan)
D4: Thông tin có trong báo biểu liên quan (cần thiết phải lưu lại) nhưng chưa được xử lý và ghi nhận lại (yêu cầu xử lý tính toán)
D2: Thông tin về báo biểu được lập (bêểu mẫu liên quan)
D6: Dữ liệu kết xuất (thường giống D2)
47
Người dùng
Thiết bị nhập
Thiết bị xuất
Xử lý BB
D1
D2
D3
D4
D5
D6

48. 3- Mô hình hoá yêu cầu
Sơ đồ tổng quát cho Yêu cầu báo biểu
Xử lý báo biểu
Nhận thông tin D1, D5 (nếu cần)
Đọc D3 để lấy các dữ liệu cần thiết cho việc lập báo biểu
Nếu có D4 thì tính toán theo quy định và Ghi kết quả D4
Hiển thị thông tin báo biểu D2 và kết xuất D6
48
Người dùng
Thiết bị nhập
Thiết bị xuất
Xử lý BB
D1
D2
D3
D4
D5
D6

49. 3- Mô hình hoá yêu cầu
Sơ đồ tổng quát cho Yêu cầu báo biểu
Ghi chú:
D1 thường có chứa yếu tố thời gian của báo biểu
Có nhiều mức độ khác nhau xác định D1 trong xử lý tính toán (để tăng tính tiện dụng)
D4 có thể có hay không có
=> Khi nào cần D4?
Thông thường D2 và D6 bao gồm D3 và D4
49
Người dùng
Thiết bị nhập
Thiết bị xuất
Xử lý BB
D1
D2
D3
D4
D5
D6

50. GV: Phan Thị Kim Loan
Thực hành
50

51. 3- Mô hình hoá yêu cầu
Tài liệu trong giai đoạn xác đinh yêu cầu
 Phát biểu bài toán (Problem Statement)
 Bảng chú giải
 Use-Case Model
 Các đặc tả bổ sung
 Checkpoints
51

52. 3- Mô hình hoá yêu cầu
Thực hành
 Làm việc với công cụ Rational Rose
 Case Study – Quản lý đăng ký học phần
 Bài thực hành 3
52

53. 3- Mô hình hoá yêu cầu
Phát biểu bài toán
 Bài toán
Tên bài toán: Course Registration
1-PhatBieuBaiToan_V1_TenDeTai.doc
53

54. 3- Mô hình hoá yêu cầu
Bảng chú giải
 Từ điển thuật ngữ (Glossary)
 2-BangChuGiai_V1_TenDeTai.doc
54
----------------- ----------------- ----------------- ----------------- ----------------- ----------------- ----------------
Glossary

55. 3- Mô hình hoá yêu cầu
Use-Case Model
 Giới thiệu
 Survey Description
 Use-Case Packages
 Use Cases
 Actors
 Relationships
 Diagrams
 Use-Case Vieww
 3-MoHinhUseCase_V1_TenDeTai.doc
55

56. 3- Mô hình hoá yêu cầu
Use-Case Model
56

57. 3- Mô hình hoá yêu cầu
Use-Case Diagram
57

58. 3- Mô hình hoá yêu cầu
Use Case
 Tên
 Brief description
 Các luồng sự kiện
 Activity & State Diagram
 Use-Case diagrams
 Special requirements
 Preconditions
 Postconditions
 Các diagram khác
58

59. 3- Mô hình hoá yêu cầu
Đặc tả use-case
Ðiểm lại đặc tả của một use-case hoàn chỉnh được cung cấp trong tài liệu, mô tả các yêu cầu của ứng dụng “Course Registration”
59

60. 3- Mô hình hoá yêu cầu
Các đặc tả bổ sung
 Functionality
 Tính khả dụng (Usabilitu)
 Tính tin cậy (Reliability)
 Tính hiệu năng (Perfromance)
 Tính hỗ trợ (Supportability)
 Các ràng buộc thiết kế
4-DacTaBoSung_V1_TenDeTai.doc
60
----------------- ----------------- ----------------- ----------------- ----------------- ----------------- ----------------
Supplementary Specification

61. 3- Mô hình hoá yêu cầu
Checkpoints: Requirement: Use-Case Model
Use-case model có dễ hiểu không?
Sau khi nghiên cứu use-case model, bạn có hình thành được một ý tuởng ràng về các chức năng của hệ thống và cách thức mà chúng liên hệ với nhau ?
Đã xác định hết tất cả các actor? Tất cả các yêu cầu chức năng được thỏa hay chưa?
Use-case model có chứa các hành vi vô dụng nào không?
Việc chia model thành các use-case package có xác đáng?
61

62. 3- Mô hình hoá yêu cầu
Checkpoints: : Requirements: Actors
Ðã xác định hết tất cả các actor?
Mỗi actor có tham gia vào ít nhất một use case?
Mỗi actor thật sự có một vai trò (role)? Có cần ghép hoặc tách các actor không?
Có tồn tại 2 actor dùng cùng một vai trò đối với 1 use case không?
Tên của các actor có gợi nhớ không? Users và customers có hiểu tên của chúng?
62

63. 3- Mô hình hoá yêu cầu
Checkpoints : Requirements: Use-Cases
Mỗi use case có ít nhất một actor tương tác?
Các use case có độc lập với nhau?
Tồn tại các use case có các luồng sự kiện và các hành vi tương tự nhau không?
Liệu các use case có tên duy nhất, gợi nhớ, và dễ hiểu để chúng không bị nhầm lẫm trong các giai đoạn sau?
Các khách hàng và người dùng có hiểu tên và mô tả của các use case không?
63

64. 3- Mô hình hoá yêu cầu
Checkpoints: Đặc tả Use-Case
Use case có đủ rõ ràng đối với những người muốn hiên thực?
Mục đích của use-case có rõ ràng?
Mô tả sơ lược (Brief description) có cho ta hình ảnh trung thực của use-case?
Có xác định rõ luồng sự kiện của use-case như thế nào và khi nào bắt đầu và kết thúc?
Chuỗi các giao tiếp giữa actor và use-case có tiện nghi không (từ góc nhìn của người dùng)?
Các tương tác và các thông tin trao đổi của actor có rõ ràng?
Có use-case nào quá phức tạp không?
Các luồng sự kiện (basic và alternative) được mô hình đúng đắn?
64

65. 3- Mô hình hoá yêu cầu
Checkpoints: Requirements: Glossary
Các thuật ngữ có định nghĩa rõ ràng và súc tích?
Mỗi thuật ngữ có dùng đâu đó trong các mô tả use- case?
Các thuật ngữ có được sử dụng hợp lý trong các mô tả ngắn về các actor và use case?
65

66. kimloanpt@gmail.com