IEEE (Institute of Electrical and Electronics Engineers nghĩa là Học Viện kỹ nghệ Điện và Điện Tử) là tổ chức chuyên môn kỹ thuật lớn nhất trên thế giới với mục tiêu thúc đẩy sự sáng tạo và chuyên ngành công nghệ vì lợi ích con người.
Trang 1Nội Dung: Tìm hiểu chuẩn viết tài liệu đặc tả yêu cầu
GVHD: TS Đặng Đức Hạnh
Nhóm 2: Bùi Quang Điệp
Lớp: CHK01
Hà Nội, 2015
Trang 2Nội Dung Chính
Trang 3I Giới Thiệu
• IEEE (Institute of Electrical and Electronics Engineers nghĩa là
"Học Viện kỹ nghệ Điện và Điện Tử") là tổ chức chuyên môn
kỹ thuật lớn nhất trên thế giới với mục tiêu thúc đẩy sự sáng tạo
và chuyên ngành công nghệ vì lợi ích con người
điện như Thomas Edison, Alexander Graham Bell…ở New
York, Mỹ Tổ chức này chính thức hoạt động đầu năm 1963
Trang 4I Giới Thiệu
• IEEE là tổ chức hàng đầu trong các lĩnh vực từ các hệ thống
không gian vũ trụ, máy tính và viễn thông đến kỹ thuật hóa
sinh, năng lượng điện, điện tử tiêu dùng… với 39 hội chuyên ngành
• IEEE còn là cơ quan phát triển các tiêu chuẩn quốc tế
hàng đầu trong các lĩnh vực viễn thông, công nghệ thông tin, thiết bị sản xuất năng lượng và dịch vụ,…
Trang 5 Chuẩn IEEE/ANSI 830-1984 đưa ra cấu trúc gồm 5 mục chính
Trang 6 Ngoài ra còn có thêm các chương hay các phụ lục với các tin
Tài liệu yêu cầu cũng là 1 công cụ tham khảo cho toàn bộ hệ
II Cấu trúc chung của tài liệu IEEE
Trang 7 Chuẩn viết tài liệu IEEE gồm một số họ sau
mạng MAN
(Institute of Electrical and Electronic Engineers) công bố vào cuối năm 1995
định yêu cầu chất lượng cần đạt, đồng thời chỉ rõ cách phân tích,
II Cấu trúc chung của tài liệu IEEE
Trang 8 Ngoài ra còn có thêm các chương hay các phụ lục với các tin
Tài liệu yêu cầu cũng là 1 công cụ tham khảo cho toàn bộ hệ
III Đặc tả yêu cầu phần mềm
Trang 91) Khảo sát ( thu thập yêu cầu)
3) Đặc tả yêu cầu (các công cụ đặc tả yêu cầu)
III Đặc tả yêu cầu phần mềm
Trang 10Ta dùng kỹ thuật để lấy thông tin yêu cầu của người dùng và khách hàng.
Trang 11• Phỏng vấn cá nhân/phỏng vấn nhóm
• Người được hỏi có cảm giác thoải mái, cung cấp nhiều thông tin
• Nguy cơ: không có được những thông tin cần thiết, thông tin khó hệ thống được
1 Khảo sát (phỏng vấn)
Trang 12 Phỏng vấn có định hướng
- Người được hỏi có thể thấy không thoải mái
- Có thể định hướng nội dung cần tìm hiểu
- Làm việc với cấp lãnh đạo đầu tiên để nắm mục tiêu của hệ thống phần mềm cần xây dựng, các đối tượng cần phỏng vấn
- Yêu cầu cấp lãnh đạo thông báo xuống các phòng ban để hợp tác
1 Khảo sát (phỏng vấn)
Trang 13• Khi tìm hiểu, cần ghi nhận các thông tin:
- Nội dung: cái gì?
- Bao giờ có: thời gian + thời hạn
- Bằng cách nào có nội dung thông tin đó
- Nội dung đó ở dạng gì?
- Đánh giá của người được phỏng vấn về tình hình hiện tại
1 Khảo sát (phỏng vấn)
Trang 14• Không nên:
- Đưa nhận xét cá nhân của người phỏng vấn
- Dùng thuật ngữ/ngôn ngữ Tin học
1 Khảo sát (phỏng vấn)
Trang 15• Phải trình bày rõ:
- Mục đích của bảng câu hỏi, sử dụng những thông tin trong bảng câu hỏi, tính bảo mật thông tin trả lời phải được bảo mật
• Hình thức bảng câu hỏi phải dễ dàng để xử lý tự động
• Cần để dành chỗ để ghi câu trả lời thêm chỗ cho lời bình, dự kiến những câu hỏi nào sẽ có ý kiến thêm thì nên có sẵn chỗ
để ghi lời bình ngay dưới câu hỏi đó)
1 Khảo sát (bảng hỏi/question)
Trang 16• Các tài liệu (có thể tìm hiểu những văn bản chung)
- Rất khó có đầy đủ văn bản quy định về quy trình nghiệp vụ
1 Khảo sát (bản mẫu tài liệu)
Trang 17• Tiến hành sau cùng (nếu cần thiết)
• Kiểm tra lại:
- Đã hiểu đúng nghiệp vụ hiện tại?
- Có những ngoại lệ?
- Phát hiện những khó khăn, lỗ hổng trong quy
• trình nghiệp vụ
1 Khảo sát (quan sát)
Trang 18• Phân loại các yêu cầu
- Chức năng và phi chức năng
và nghiệp vụ trong hệ thống hiện tại
phát triển đề xuất
2 Phân tích yêu cầu
Trang 193 Các công cụ thường dùng để đặc tả yêu cầu
Đặc tả chức năng (Operational Specifications): thông thường khi
đặc tả các chức năng của phần mềm người ta sử dụng các công cụ tiêu biểu sau:
Biểu đồ phân rã chức năng (Functional Decomposition
Diagram – FDD)
Biểu đồ luồng dữ liệu (Data Flow Diagrams-DFD)
Máy trạng thái hữu hạn (Finite State Machines)
Mạng Petri (Petri nets)
Trang 20Các công cụ thường dùng để đặc tả yêu cầu
Đặc tả mô tả (Descriptive Specifications): Người ta sử dụng các
công cụ tiêu biểu sau:
Biểu đồ thực thể liên kết (Entity-Relationship Diagrams - ERD)
Đặc tả Logic (Logic Specifications)
Đặc tả đại số (Algebraic Specifications)
Trang 21Các công cụ thường dùng để đặc tả yêu cầu
Đặc tả phân rã (Functional Decomposition Diagram – FDD):
Người ta sử dụng các công cụ tiêu biểu sau:
Xác định phạm vi của hệ thống
Phân hoạch chức năng
Tạo nền tảng cho thiết kế kiến trúc hệ thống
Trang 22Các công cụ thường dùng để đặc tả yêu cầu
Ví dụ đặc tả phân rã (phân luồng chức năng)
Trang 23Các công cụ thường dùng để đặc tả yêu cầu
VD: Đặc tả yêu cầu phần mềm bằng FSM (Máy trạng thái hữu hạn)
Xem xét ví dụ về thư viện với các giao dịch như sau:
Mượn sách/Trả sách
Thêm đầu sách/Loại bỏ đầu sách
Liệt kê danh sách các sách theo tên tác giả hay theo chủ đề
Tìm kiếm sách theo các yêu cầu của người mượn
Tìm kiếm sách quá hạn trả
Trang 24Các công cụ thường dùng để đặc tả yêu cầu
Các yêu cầu đặc biệt của thư viện:
Độc giả không được mượn quá một số lượng sách nhất định, trong một thời gian nhất định
Một số sách không được mượn về
Một số người không được mượn một số loại sách nào đó,
Trang 25Các công cụ thường dùng để đặc tả yêu cầu
Trang 26Các công cụ thường dùng để đặc tả yêu cầu
Tài liệu yêu cầu
Chỉ mô tả về chức năng, ràng buộc
Không mô tả về phương pháp cài đặt
Phải dễ thay đổi (có cấu trúc)
Khó xác định được đầy đủ chính xác ngay
Trang 27Các công cụ thường dùng để đặc tả yêu cầu
Tài liệu yêu cầu
Phải qua nhiều bước xét duyệt lại
Tài liệu cần có:
o Tính rõ ràng, chính xác
o Tính phù hợp
Trang 28Mẫu đặc tả yêu cầu phần mềm
[TÊN PHẦN MỀM/DỰ ÁN] ĐẶC TẢ YÊU CẦU PM [v1.0]
Trang 29Mẫu đặc tả yêu cầu phần mềm
Ngày thay đổi Phiên bản Mô tả Tác giả/Nhóm tác giả
<dd/mm/yy> <Vx.y> <Mô tả chi tiết Mục, bảng, sơ đồ nào thay đổi; nội
dung thay đổi là gì>
<Họ tên người lập, nhóm lập>
LỊCH SỬ THAY ĐỔI TÀI LIỆU
Trang 30Mẫu đặc tả yêu cầu phần mềm
Trang 31Mẫu đặc tả yêu cầu phần mềm
Trang 32Mẫu đặc tả yêu cầu phần mềm
1 GIỚI THIỆU CHUNG
1.1 Mục đích
<Trình bày vai trò, mục đích của tài liệu SRS: Tài liệu mô tả một cách đầy đủ, toàn diện các yêu cầu của phần mềm – đó là các yêu cầu chức năng, phi chức năng, các ràng buộc về mặt thiết kế >
<Ghi chú: tài liệu SRS mô tả các yêu cầu của phần mềm đối với toàn bộ hệ thống, hoặc đối
với từng hệ thống con Có nhiều kiểu cấu trúc cho tài liệu SRS Cấu trúc giới thiệu trong tài
liệu này là cấu trúc điển hình dùng cho các dự án áp dụng mô hình use-case (use-case
modeling ) Vì vậy, tài liệu sẽ trình bày các use case, mô tả cho các use case và các đặc tả
bổ sung, cũng như các thông tin hỗ trợ khác>
Trang 33Mẫu đặc tả yêu cầu phần mềm
Trang 34Mẫu đặc tả yêu cầu phần mềm
2.1 Mô hình use case
2.2 Danh sách các tác nhân và mô tả
<Liệt kê các tác nhân của hệ thống>
Tác nhân Mô tả tác nhân Ghi chú
Trang 35Mẫu đặc tả yêu cầu phần mềm
Danh sách Use case và mô tả
<Liệt kê các use case theo mô hình use case Các use case tương ứng với các chức năng nào như đã mô tả trong tài liệu SRD Phải mapping use case và chức năng tương ứng >
UC_001 Tên use case Mô tả ngắn gọn Use case Ứng với chức năng nào
như đã mô tả trong SRD (mã số chức năng)
Trong đó:
UC: Quy cách đánh số Use case
Trang 36Mẫu đặc tả yêu cầu phần mềm
Trang 37Mẫu đặc tả yêu cầu phần mềm
Trang 38Mẫu đặc tả yêu cầu phần mềm
2.1 UC_002_Tên use case
Trong đó: UC_002: là mã use case
Tên use case: Tên use case được mô tả ở mục 2.3
2.1.1 Mô tả use case UC_002
Trang 39Mẫu đặc tả yêu cầu phần mềm
Trang 40Cám ơn!