Bài giảng Kỹ nghệ phần mềm (Nhập môn) - Nguyễn Quốc Toản - Chương 2: Đặc tả phần mềm

___________________________________________
______________________________________________________________Ch−ơng II. 
Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng 
48 
khác đang đi kèm với các môi tr−ờng t−ơng tác. Mặc dầu vẫn còn đang trong giai đoạn sơ khai 
của phát triển và ứng dụng, những môi tr−ờng nh− vậy th−ờng đ−a ra hy vọng chủ yếu cho việc 
làm bản mẫu nâng cao và tính hiệu năng của việc phát triển phần mềm 
Một khuôn cảnh kỹ nghệ phần mềm tự động hoá 
II.4. Đặc tả các yêu cầu phần mềm 
 Bản đặc tả các yêu cầu phần mềm đ−ợc tạo ra tại đỉnh cao của nhiệm vụ phân tích. 
 Chức năng và hiệu năng đ−ợc cấp phát cho phần mềm xem nh− một phần của kỹ nghệ hệ 
thống th−ờng đ−ợc làm mịn bằng cách thiết lập phần mô tả thông tin đầy đủ nh− mô tả chức năng 
chi tiết, chỉ báo về các yêu cầu hiệu năng và những ràng buộc thiết kế, các tiêu chuẩn hợp lệ thích 
hợp và những dữ liệu khác th−ờng cần tới. Cơ quan tiêu chuẩn quốc gia, IEEE và Bộ quốc phòng Mỹ 
đề nghị các định dạng cho các đặc tả yêu cầu phần mềm. Dàn bài đơn giản hoá đ−ợc trình bày trong 
bảng sau: 
Thu thập yêu cầu 
Biểu diễn hình 
thức 
Tự động sinh bản 
mẫu 
Tối −u và tinh 
chỉnh 
Phần mềm hoàn 
chỉnh 
Kỹ nghệ phần mềm 
________________________________________________________________________
______________________________________________________________Ch−ơng II. 
Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng 
49 
Dàn bài đặc tả yêu cầu phần mềm 
I.Giới thiệu 
 A.Đại c−ơng về hệ thống 
 B.Mô tả chung 
 C.Các ràng buộc dự án phần mềm 
II.Mô tả thông tin 
 A.Biểu diễn luồng thông tin 
 1.Luồng dữ liệu 
 2.Luồng điều khiển 
 B.Biểu diễn nội dung thông tin 
 C.Mô tả giao diện hệ thống 
III.Mô tả chức năng 
 A.Phân hoạch chức năng 
 B.Mô tả chức năng 
 1.T−ờng thuật về cách xử lý 
 2.Hạn chế/giới hạn 
 3.Yêu cầu hiệu năng 
 4.Ràng buộc thiết kế 
 5.Biểu đồ trợ giúp 
 C.Mô tả điều khiển 
 1.Đặc tả điều khiển 
 2.Ràng buộc thiết kế 
IV.Mô tả hành vi 
 A.Trạng thái hệ thống 
 B.Sự kiện và hành động 
V.Tiêu chuẩn hợp lệ 
 A.Giới hạn hiệu năng 
 B.Lớp các kiểm thử 
 C.Đáp ứng phần mềm trông đợi 
 D.Các xem xét đặc biệt 
VI.Sách tham khảo 
VII.Phụ lục 
(mục tiêu, mục đích) 
(cấu trúc) 
(phạm vi) 
(chi tiết) 
(dựa vào cấu trúc thông tin ) 
(đặc biệt chú ý đến khi xét các hệ thời gian thực) 
(cho từng chức năng ) 
(lời giải thích) 
(về các mặt, kinh tế, xã hội , kỹ thuật , chi phí , 
thời gian ) 
(theo từng modul) 
(có luận giải) 
(cấu trúc tổng thể, t−ơng quan với các phần từ hệ 
thống khác) 
(có luận giải) 
(xem xét vận hành của phần mềm ) 
(mức toàn cảnh, mức đỉnh) 
(mức cụ thể, bộ phận) 
(quan trọng nhất nh−ng hay bị bỏ quên) 
(tiêu chuẩn h−ớng tới (lí t−ởng)) 
(tài liệu kỹ nghệ phần mềm khác, tham khảo kỹ 
thuật ,...) 
(Danh sách các nhà cung cấp, các chuẩn,...) 
 Trong nhiều tr−ờng hợp bản đặc tả các yêu cầu Phần mềm còn có thể còn có kèm theo một 
bản mẫu thực hiện đ−ợc ( mà trong một số tr−ờng hợp có thể thay thế đ−ợc cho bản đặc tả), một bản 
mẫu trên giấy, hay tài liệu sơ bộ của ng−ời dùng. Bản tài liệu sơ bộ của ng−ời dùng trình bày phần 
mềm nh− hộp đen. Tức là, chủ yếu nhấn mạnh vào cái vào của ng−ời dùng và cái ra kết quả. Tài liệu 
này có thể dùng nh− một công cụ có giá trị để làm lộ ra vấn đề ở giao diện ng−ời -máy. 
II.4.2.Xét duyệt đặc tả 
 Việc xét duyệt bản đặc tả các yêu cầu phần mềm (và hoặc bản mẫu) do cả ng−ời phát triển 
phần mềm và khách hàng cùng tiến hành. Bởi vì đặc tả tạo nên nền tảng cho giai doạn phát triển nên 
cần phải cực kỳ cẩn thận trong khi tiến hành cuộc họp xét duyệt . Có 2 mức xét duyệt: 
+Mức vĩ mô: 
Kỹ nghệ phần mềm 
________________________________________________________________________
______________________________________________________________Ch−ơng II. 
Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng 
50 
 Việc xét duyệt tr−ớc hết đ−ợc tiến hành ở mức vĩ mô. Tại mức này, ng−ời xét duyệt cố gắng 
đảm bảo rằng bản đặc tả đ−ợc đầy đủ, nhất quán và chính xác. Cần đề cập tới các câu hỏi sau : 
• Các mục tiêu và mục đích đ−ợc thiết lập cho phần mềm có nhất quán với mục tiêu và mục đích 
của hệ thống hay không ? 
• Những giao diện quan trọng với mọi phần tử hệ thống đã đ−ợc mô tả ch−a? 
• Luồng và cấu trúc thông tin đã đ−ợc mô tả thích hợp cho lĩnh vự vấn đề ch−a? 
• Các biểu đồ có rõ ràng không? Liệu mỗi biểu đồ có thể đứng riêng không cần lời giải thích 
không ? 
• Các chức năng chính có còn bên trong phạm vi và đã đ−ợc mô tả thích hợp ch−a? 
• Liệu hành vi của phần mềm có nhất quán với thông tin nó phải xử lý và chức năng nó phải thực 
hiện hay không ? 
• Các ràng buộc thiết kế có hiện thực không ? 
• Rủi ro công nghệ phát triển là gì? 
• Các yêu cầu phần mềm khác đã đ−ợc xem xét đến ch−a? 
• Các tiêu chuẩn hợp lệ đã đ−ợc phát biểu chi tiết ch−a? 
• Liệu có sự không nhất quán, bỏ sót hay d− thừa nào không ? 
• Việc tiếp xúc với khách hàng có đầy đủ không ? 
• Ng−ời dùng đã xét duyệt bản Tài liệu sơ bộ của ng−ời dùng hay bản mẫu ch−a? 
• Các −ớc l−ợng về Kế họach dự án phần mềm bị ảnh h−ởng thế nào? 
 Để đ−a ra câu trả lời cho nhiều câu hỏi trên, việc xét duyệt có thể tập trung vào mức chi tiết. 
Tại đây, mối quan tâm tập trung vào từ ngữ của bản đặc tả. Chúng ta cố gắng làm lộ ra vấn đề có 
thể ẩn náu bên trong nội dung đặc tả . 
+Mức chi tiết: 
 Những gợi ý sau về việc xét duyệt chi tiết bản đặc tả : 
• Phải quan sát các từ nối có sức thuyết phục (nh− "chắc chắn", "do đó", "rõ ràng", "hiển 
nhiên", "từ đó suy ra rằng") và hỏi "tại sao chúng lại có đó?". 
• Theo dõi những thuật ngữ mung lung (nh− "một số", "đôi khi", "th−ờng", "thông 
th−ờng", "bình th−ờng","phần lớn", "đa số"); yêu cầu làm sáng tỏ 
• Khi có nêu danh sách, nh−ng không đầy đủ thì phải đảm bảo mọi khoản mục đều đ−ợc 
hiểu rõ. Chú ý vào các từ nh− "vân vân","cứ nh− thế", "cứ tiếp tục nh− thế", "sao cho",... 
• Phải chắc chắn phát biểu phạm vi không chứa những giả thiết không đ−ợc nói rõ (nh− 
"mã hợp lệ trong khoảng 10 tới 100". Đó là số nguyên, số thực hay số hệ 16?) 
• Phải nhận biết về các động từ mơ hồ nh− "xử lý", "loại bỏ". Có thể có nhiều cách hiểu về 
nó. 
• Phải nhận biết các đại từ "vu vơ" (nh− "modul vào/ra liên lạc với modul kiểm tra tính 
hợp lệ dữ liệu và đặt cờ báo kiểm soát của nó".) 
• Tìm các câu có chứa sự chắc chắn (nh− "bao giờ", "mọi", "tất cả"," không một", "không 
bao giờ") rồi yêu cầu bằng chứng 
• Khi một thuật ngữ đ−ợc định nghĩa t−ờng minh tại một chỗ thì hãy thử thay thế định 
nghĩa này vào chỗ xuất hiện cuả nó 
• Khi một cấu trúc đ−ợc mô tả theo lời thì hãy vẽ ra bức tranh để giúp hiểu đ−ợc nó 
• Khi một tính toán đ−ợc xác định thì hãy thử với ít nhất 2 ví dụ 
 Một khi việc xét duyệt đã hoàn tất thì bản đặc tả các yêu cầu phần mềm sẽ đ−ợc cả khách 
hàng lẫn ng−ời phát triển "kí tắt". Bản đặc tả trở thành "hợp đồng" cho việc phát triển phần mềm. 
Những thay đổi trong yêu cầu đ−ợc nêu ra sau khi bản đặc tả đã hoàn thành sẽ không bị loại bỏ. 
Nh−ng khách hàng phải l−u ý rằng từng thay đổi sau khi ký đều là một mở rộng của phạm vi phần 
mềm và do đó có thể làm tăng thêm chi phí và/hoặc kéo dài lịch biểu 
Kỹ nghệ phần mềm 
________________________________________________________________________
______________________________________________________________Ch−ơng II. 
Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng 
51 
 Bản đặc tả rất khó "kiểm thử" theo mọi cách có nghĩa, do đó sự không nhất quán hay bỏ sót 
có thể bị bỏ qua không chú ý tới. Trong khi xét duyệt, ng−ời ta có thể khuyến cáo những thay đổi 
cho bản đặc tả. Có thể sẽ cực kỳ khó khăn để định l−ợng tác động toàn cục của thay đổi, tức là làm 
sao việc thay đổi trong một chức năng lại ảnh h−ởng tới các yêu cầu cho chức năng khác? Ng−ời ta 
đã phát triển các công cụ đặc tả tự động hoá để giúp giải quyết vấn đề này. 
___________________________ 
Tóm tắt 
 Phân tích và định rõ yêu cầu là b−ớc kỹ thuật đầu tiên trong tiến trình kỹ nghệ phần mềm . 
Chính tại điểm này mà phát biểu chung về phạm vi phần mềm đ−ợc làm mịn thành một bản đặc tả 
cụ thể để trở thành nền tảng cho mọi hoạt động kỹ nghệ phần mềm theo sau. 
 Việc phân tích phải tập trung vào các miền thông tin, chức năng và hành vi của vấn đề. Để 
hiểu rõ hơn cần cái gì, ng−ời ta tạo ra mô hình, phân hoạch vấn đề và tạo ra những biểu diễn mô tả 
cho bản chất của yêu cầu rồi sau đó xây dựng các chi tiết cài đặt 
 Trong nhiều tr−ờng hợp, không thể nào đặc tả đ−ợc đầy đủ một vấn đề tại giai đoạn đầu. 
Việc làm bản mẫu th−ờng giúp chỉ ra cách tiếp cận khác để từ đó có thể làm mịn thêm yêu cầu. Để 
tiến hành đúng đắn việc làm bản mẫu, có thể cần tới các công cụ và kỹ thuật đặc biệt. 
 Đặc tả các yêu cầu phần mềm đ−ợc xây đựng nh− kết quả của việc phân tích. Việc xét duyệt 
là bản chất để đảm bảo rằng ng−ời phát triển và khách hàng có cùng nhận biết về hệ thống ./. 
________________ 
? củng cố 
1. Mô tả bằng sơ đồ việc hình thành các yêu cầu trong tiến trình phân tích và định rõ yêu cầu? 
2. Phân tích các nguyên lý đặc tả ? 
3. Khái niệm về đặc tả, biểu diễn và mức trừu t−ợng của đặc tả ? 
4. Tại sao chúng ta phải coi việc xác định nhu cầu và phân tích khả thi là những b−ớc đầu tiên của 
tiến trình phân tích hệ thống ? 
5. Đặc tả yêu cầu bao gồm những hoạt động nào, hãy mô tả tóm tắt những hoạt động đó? 
6. Tại sao nói đặc tả yêu cầu là cơ sở cho hợp đồng làm hệ thống ? 
7. Đặc tả hệ thống đ−ợc phân biệt với đặc tả yêu cầu ở điểm nào ? 
8. Dàn bài đặc tả hệ thống tối thiểu cần bao quát những nội dung nào? 
9. Nội dung và ý nghĩa của việc xét duyệt đặc tả hệ thống ? 
10. Mục tiêu và lợi ích chủ yếu của việc tạo nguyên mẫu ? 
11. Trình bày sơ l−ợc nội dung của 4 giai đoạn phát triển nguyên mẫu? 
12. Trình bày các b−ớc tiến hành làm bản mẫu phần mềm ? 
13. Sơ l−ợc về các ph−ơng pháp và công cụ làm bản mẫu? 
14. Hãy đ−a ra 1 dàn bài chung nhất về đặc tả yêu cầu phần mềm ? 
2 December, 2008