Chapter 5 Đặc tả yêu cầu

1. Chapter 5Đặc tả yêu cầu Requirement specifications Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

2. Nội dung • Requirement specifications (Đặc tả yêu cầu) • Đặc tả yêu cầu phần mềm • Từ điển dữ liệu Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

3. Đặc tả yêu cầu Đặc tả yêu cầu là người xây dựng hệ thống phải trả lời các câu hỏi sau: • Đầu ra của hệ thống là gì • Hệ thống phải làm cái gì để có kết quả mong muốn nghĩa là phải xử lý những cái gì • Những tài nguyên mà hệ thống yêu cầu là gì • Các hệ thống phần mềm lớn luôn đòi hỏi cải tiến từ hiện trạng. Mặc dù các khó khăn của hệ thống hiện tại có thể xác định được nhưng các ảnh hưởng và hiệu ứng của hệ thống mới khó dự đoán trước được. • Hệ thống lớn thường có nhiều cộng đồng sử dụng khác nhau. Họ có các yêu cầu và ưu tiên khác nhau. Các yêu cầu hệ thống cuối cùng là gì • Người trả tiền cho hệ thống và người sử dụng khác nhau là ai? Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

4. Phân Loại Đặc tả yêu cầu Đặc tả yêu cầu có thể chia thành 2 loại: • Đặc tả phi hình thức (ngôn ngữ tự nhiên) • Đặc tả hình thức (dựa trên kiến trúc toán học) Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

5. Đặc tả Phi Hình Thức Là đặc tả sử dụng ngôn ngữ tự nhiên. Tuy không được chặt chẽ bằng đặc tả hình thức nhưng được nhiều người biết và có thể trao đổi với nhau để làm chính xác hóa các điểm chưa rõ, chưa thống nhất giữa các bên phát triển hệ thống. Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

6. Đặc tả Hình Thức • Là đặc tả mà ở đó các từ ngữ, cú pháp, ngữ nghĩa được định nghĩa hình thức dựa vào toán học. • Đặc tả hình thức có thể được coi là một phần hoạt động của đặc tả phần mềm. • Các đặc tả yêu cầu được phân tích chi tiết. Các mô tả trừu tượng của các chức năng chương trình có thể được tạo để làm rõ yêu cầu Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

7. Đặc tả Hình Thức Có hai phương pháp đặc tả hình thức để phát triển các hệ thống tương đối phức tạp • Tiếp cận đại số, hệ thống được mô tả dưới dạng các toán tử và các quan hệ • Tiếp cận mô hình, mô hình hệ thống được cấu trúc sử dụng các thực thể toán học như là tập hợp các thứ tự Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

8. Đặc tả Hình Thức Thuận lợi khi sử dụng đặc tả hình thức: • Cho phép chúng ta thấy và hiểu được bản chất bên trong của các yêu cầu, đây là cách tốt nhất để làm giảm các lỗi, các thiếu sót có thể xảy ra và giúp cho công việc thiết kế được thuận lợi. • Do chúng ta sử dụng toán học cho việc đặc tả nên có thể dựa vào các công cụ toán học khi phân tích và điều này làm tăng thêm tính chắc chắn và tính đầy đủ của hệ thống • Đặc tả hình thức bản thân nó cho chúng ta 1 cách thức cho việc kiểm tra hệ thống sau này Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

9. Đặc tả Hình Thức Hạn chế khi sử dụng đặc tả hình thức: • Quản lý phần mềm có tính bảo thủ cố hữu của nó, không sẵn sàng chấp nhận các kỹ thuật mới • Chi phí thường cao hơn so với các đặc tả khác • Phần lớn những người đặc tả không được đào tạo 1 cách chính qui về việc sử dụng đặc tả hình tả hình thức cho việc đặc tả hệ thống mà dựa trên thói quen của họ • Nhiều thành phần của hệ thống là khó cho việc đặc tả bằng ngôn ngữ hình thức. Thêm vào đó khách hàng không thể hiểu được nó. • Khách hàng không thích đặc tả toán học Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

10. Nguyên lý đặc tả • Phân tách chức năng với cài đặt: đặc tả là mô tả điều mong muốn chứ không phải cách thức thực hiện (cài đặt). Kết quả thu được theo dạng cái gì chứ không phải thế nào. • Cần tới ngôn ngữ đặc tả hệ thống hướng tiến trình: cần thiết đặc biệt trong trường hợp môi trường là động và sự thay đổi của nó ảnh hưởng tới hành vi của thực thể nào đó tương tác với môi trường nào đó • Đặc tả phải bao gồm hệ thống có phần mềm là một thành phần: vì hệ thống bao gồm các thành phần tương tác với nhau, chỉ bên trong hoàn cảnh của toàn bộ hệ thống và tương tác giữa các thành phần của nó thì hành vi của một thành phần mới có thể xác định Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

11. Nguyên lý đặc tả • Đặc tả phải bao gồm cả môi trường mà hệ thống vận hành • Đặc tả hệ thống phải là mô hình nhận thức: không phải là mô hình thiết kế hay cài đặt. Nó phải mô tả 1 hệ thống như cộng đồng người sử dụng cảm nhận thấy • Đặc tả phải vận hành: phải đầy đủ và hình thức để có thể được dùng trong việc xác định liệu một cài đặt được đề nghị có thỏa mãn đặc tả trong những trường hợp kiểm thử tùy ý hay không Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

12. Nguyên lý đặc tả • Đặc tả hệ thống phải dung sai về tính không đầy đủ và tính nâng cao. Đặc tả không thể hoàn toàn đầy đủ do môi trường phức tạp • Đặc tả phải được cục bộ hóa và được ghép lỏng lẻo: đặc tả làm cơ sở cho thiết kế và cài đặt, không phải tĩnh mà là sự vận động, đang trải qua thay đổi đáng kể nên nội dung và cấu trúc phải phù hợp. Sự thay đổi khi cần sửa đổi là tối thiểu, chỉ một phần nhỏ các thành phần có thể thêm vào hay loại bớt một cách dễ dàng Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

13. Tài liệu về yêu cầu • Kết quả của quá trình phát triển yêu cầu là bảng thỏa thuận (agreement) giữa khách hàng và developer về sản phẩm cần xây dựng. • Tài liệu về Vision and scope chứa các quy tắc nghiệp vụ, và yêu cầu người dùng thường dưới dạng các use cases. • Yêu cầu chức năng và phi chức năng của sản phẩm sẽ nằm trong đặc tả yêu cầu phần mềm (software requirements specification SRS) Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

14. Ba cách diễn tả yêu cầu phần mềm • Văn bản: Tài liệu phải được viết 1 cách cẩn thận, có bố cục rõ ràng bằng ngôn ngữ tự nhiên. • Mô hình: để mô tả quy trình biến đổi, trạng thái hệ thống và các thay đổi giữa chúng, các quan hệ dữ liệu, dòng logic, lớp và mối quan hệ giữa các lớp. • Đặc tả hình thức: xác định các yêu cầu bằng ngôn ngữ logic toán học. Cách nào thông dụng hơn??? Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

15. Đặc tả yêu cầu phần mềmSoftware requirements specification (SRS) • Đôi khi còn được gọi là • functional specification, • product specification, • requirements document, • system specification Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

16. Quy tắc nghiệp vụ và SRS • Để tránh dư thừa, không nên lặp lại các quy tắc từ business rules catalog vào SRS mà nên chỉ ra nơi tham chiếu các qui tắc • Phòng tránh được việc phải thay đổi cùng lúc cả qui tắc nghiệp vụ và yêu cầu chức năng khi qui tắc thay đổi • Giữ cho SRS luôn phản ánh các qui tắc vừa thay đổi vì nó tham chiếu đến bản sao chính của qui tắc • Thuận lợi trong việc dùng lại cùng 1 qui tắc trong nhiều nơi khác nhau của SRS và cho nhiều dự án khác nhau mà vẫn giữ được sự nhất quán. Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

17. Quy tắc nghiệp vụ và SRS • Lý do khác để tách qui tắc nghiệp vụ và yêu cầu chức năng: qui tắc thường được tách ra 1 cách riêng biệt, vì vậy có thể không nhạy bén khi xem thực tế có liên quan đến nhiều yêu cầu khác. • Không có 1 giải pháp nào là perfect và simple để cho một qui tắc nghiệp vụ thực thi cùng nhau trong mọi hoàn cảnh Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

18. Các đối tượng sử dụng SRS • Customers, the marketing department, và sales staff cần biết họ được phân phối sản phẩm gì. • Project managers cần biết các ước tính về lịch biểu, tài nguyên, thời gian trong phần mô tả sản phẩm. • SRS cho đội SW development biết cần xây dựng cái gì. • Nhóm kiểm thử dùng SRS để phát triển kế hoạch test, các test cases và thủ tục kiểm thử • Giúp cho nhân viên maintenance &support biết mỗi phần của sản phẩm cần hỗ trợ gì. Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

19. Các đối tượng sử dụng SRS • Người viết tài liệu (Documentation writer) • Người hướng dẫn sử dụng (Training personnel) • Quan chức luật pháp (Legal staff) dựa vào SRS để bảo đảm là các yêu cầu phù hợp với luật và chính sách của chính quyền và tổ chức. Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

20. Đặc trưng của SRS • SRS chứa các chức năng và khả năng mà hệ thống phần mềm phải cung cấp và các ràng buộc phải tuân theo. • SRS là cơ sở cho tất cả các giai đoạn planning, design, coding, testing và tạo tư liệu cho người dùng. • SRS cũng mô tả các hành vi của hệ thống dưới các điều kiện khác nhau nhưng không chứa design, construction, testing. Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

21. Đặc trưng của SRS • Không cần phải viết SRS cho cả sản phẩm trước khi bắt đầu, nhưng cần cung cấp yêu cầu cho mỗi increment trước khi bắt đầu increment. • Phát triển theo hướng tăng tiến (incremental) là phù hợp khi stakeholders không thể xác định được tất cả yêu cầu lúc đầu và cần nhận một cách nhanh chóng 1 số chức năng từ người dùng Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

22. Cách bố trí SRS • Đặt nhãn cho mỗi phần một cách thống nhất. • Không nên gióng thẳng lề phải. • Sử dụng các phần cần nhấn mạnh một cách hình ảnh như in đậm, in nghiêng, các kiểu font khác nhau một cách thống nhất và đúng mực. • Tạo bảng mục lục và chỉ mục giúp người đọc tìm thông tin dễ dàng. • Đánh số và tạo tiêu đề tất cả hình ảnh và bảng biểu Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

23. Cách bố trí SRS • Use your word processor's cross-reference facility rather than hard-coded page or section numbers to refer to other locations within a document. • Sử dụng hyperlink để người đọc chuyển đến các phần có liên quan trong SRS hay trong các tài liệu khác. • Sử dụng template thích hợp để sắp xếp lại tất cả các thông tin cần thiết. Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

24. SRS Template • Mỗi tổ chức SW nên thừa nhận cách viết SRS cho các dự án theo 1 hay 1 số mẫu tiêu chuẩn. • Xem phụ lục D Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

25. SRS Template Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

26. Hướng dẫn viết SRS – Phần Introdution 1.1. Purpose • Xác định sản phẩm cùng với số phiên bản sẽ phát hành 1.2. Document Conventions • Mô tả qui ước tiêu chuẩn bao gồm định dạng văn bản, ký hiệu,…được dùng trong tài liệu • Indented Audience and Reading Suggestions 1.3. Liệt kê các người đọc khác nhau. • Mô tả các phần trong SRS được sắp xếp như thế nào. Đề nghị đọc tài liệu sao là phù hợp nhất Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

27. Hướng dẫn viết SRS – Phần Introdution 1.4. Project Scope • Cung cấp mô tả vắn tắt về phần mềm với mục tiêu người dùng. Nếu đã có sẵn tài liệu vision and scope thì nên tham chiếu hơn là viết trùng lặp 1.5. References • Liệt kê bất kỳ tài liệu và tài nguyên nào mà SRS tham chiếu đến. Cung cấp thông tin đủ để người đọc có thể truy xuất đến các tham chiếu này, bao gồm tiêu đề, tác giả, số phiên bản, ngày, Url,… Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

28. Hướng dẫn viết SRS – Phần Introdution 2.1. Project perspective • Mô tả nguồn gốc hoặc hoàn cảnh xuất xứ sản phẩm: phiên bản kế tiếp, thay thế sản phẩm cũ hay sản phẩm hoàn toàn mới • Nếu SRS này chỉ xác định 1 phần của cả hệ thống lớn hơn, cần chỉ ra phần mềm này liên quan đến cả hệ thống lớn như thế nào và xác định giao diện chính giữa hai phần mềm Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

29. Hướng dẫn viết SRS – Phần Introdution 2.2. Project Feature • Liệt kê các tính năng chính của sản phẩm. Hình ảnh của các nhóm yêu cầu chính và mối liên hệ giữa chúng chẳng hạn lược đồ DFD, lược đồ Use case,… 2.3. User Classes and characteristics • Xác định các lớp người dùng khác nhau và các tính năng phù hợp với mỗi lớp người dùng. Các lớp người dùng là 1 tập con của các stakeholder đã được mô tả trong tài liệu vision and scope. Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

30. Hướng dẫn viết SRS – Phần Introdution 2.4. Operating Environment • Mô tả môi trường mà phần mềm sẽ vận hành bao gồm phần cứng, hệ điều hành, vị trí địa lý của người dùng, server và database. Tài liệu vision and scope có thể chứa 1 số thông tin ở mức cao Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

31. Hướng dẫn viết SRS – Phần Introdution 2.5. Design and Implementation Constraints • Mô tả các ràng buộc liên quan đến thiết kế và thực thi hệ thống • Các ràng buộc như sau: • Công nghệ, tool, ngôn ngữ lập trình, databases cần dùng hay phải tránh. • Các hạn chế vì môi trường vận hành sản phẩm như loại và phiên bản version của Web browsers Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

32. Hướng dẫn viết SRS – Phần Introdution • Các ràng buộc như sau: • Các qui ước và tiêu chuẩn phát triển SW • Tích hợp ngược với các sản phẩm trước đó • Các hạn chế dựa vào qui tắc nghiệp vụ • Giới hạn về phần cứng như yêu cầu thời gian, bộ nhớ, vi xử lý,… • Các qui ước về giao diện người dùng hiện thời cần được tuân theo khi mở rộng sản phẩm mới. Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

33. Hướng dẫn viết SRS – Phần Introdution 2.6. User Documentation • Liệt kê các tài liệu sẽ phát hành kèm theo SW bao gồm user manuals, online help, tutorial. 2.7. Assumptiom and Dependencies • Giả thiết (assumption) là các phát biểu được tin là đúng nhưng chưa được chứng minh. Giả thiết sai có thể gây ra các rủi ro cho dự án. Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

34. Hướng dẫn viết SRS – Phần Introdution 2.7. Assumptiom and Dependencies • Một vài ví dụ về giả thiết • Một số người đọc SRS có thể giả thiết sản phẩm phù hợp với qui ước về giao diện người dùng, một số khác giao diện phải khác. • Nhà phát triển có thể giả thiết các chức năng này là phù hợp với ứng dụng nhưng nhà phân tích lại cho rằng họ sẽ dùng lại các chức năng từ dự án trước Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

35. Hướng dẫn viết SRS – Phần Introdution 2.7. Assumptiom and Dependencies • Xác định các phụ thuộc của dự án vào các yếu tố bên ngoài như ngày phát hành phiên bản kế tiếp hay các vấn đề liên quan đến tiêu chuẩn kỹ thuật. • Nếu hệ thống cần tích hợp với 1 số thành phần của dự án khác đang phát triển thì hệ thống sẽ phụ thuộc vào lịch trình của dự án đó. • Nếu các phụ thuộc này đã được ghi chép trong một tài liệu khác như project plan thì phải chỉ ra việc tham chiếu tài liệu đó Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

36. Hướng dẫn viết SRS – Phần Introdution • Trình bày lần lượt từng tính năng của hệ thống theo mẫu sau: • 3.x System Feature X: Phát biểu ngắn gọn tên tính năng như “3.1 Spell Check” • 3.x.1 Description and Priority: mô tả ngắn gọn về tính năng và chỉ ra độ ưu tiên của tính năng (high, mediem hay low) • 3.x.2 Stimulus/Response Sequences: liệt kê chuỗi các tác nhân đầu vào và đáp ứng của hệ hệ thống • 3.x.3 Functional Requirements: Đánh số thứ tự các yêu cầu chức năng chi tiết liên quan đến tính năng đang xét Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

37. Hướng dẫn viết SRS – Phần Introdution 4.1. User Interface • Mô tả các tính năng của mỗi giao diện người dùng. Các tiêu chuẩn GUI như: • Fonts, icons, button lables, images, coloe schemes, field tabling sequences, commonly used controls,… • Screen layout or resolution constraints • Standard buttons, functions, or navigation links that will appear on every screen such as help button Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

38. So sánh SRS và vision document • Có 1 số phần trùng nhau giữa SRS và vision & scope document như project scope, product features, operating environment ….) • Vì có 1 số dự án nhỏ chỉ cần tạo 1 tài liệu về requirement là đủ. Do đó nếu muốn dùng cả 2 loại thì cần điều chỉnh để loại trừ phần trùng lặp giữa 2 tài liệu. • Có thể sử dụng các section tương đương nhau nhưng trong SRS thì mô tả chi tiết hơn các thông tin có tính sơ bộ hay mức cao trong vision and scope document. Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

39. Cách viết requirement • Không có cách chính thống nào để viết requirement một cách tốt nhất; mà chủ yếu là từ kinh nghiệm (experience). • Những vấn đề vấp phải trong quá khứ sẽ cho ta bài học đáng giá trong tương lai. Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

40. Một vài gợi ý để viết requirement • Viết câu đúng văn phạm, đúng chính tả. Câu văn và đoạn văn nên ngắn gọn và trực tiếp. • Sử dụng thể chủ động (active voice) • VD: "The system shall do something," không dùng "Something shall happen.” • Assignment 21: Gợi ý viết requirement Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

41. Ví dụ 1 về yêu cầu mẫu • "The Background Task Manager shall provide status messages at regular intervals not less than every 60 seconds." Nhận xét gì về phát biểu trên • Phân tích: • Status messages là gì? Chúng được cung cấp cho người dùng trong điều kiện gì và theo kiểu gì? • Nếu thông báo hiển thị, thì chúng xuất hiện trong bao lâu? Khoảng thời gian “every 60 seconds” không rõ ràng. Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

42. Ví dụ 1 về yêu cầu mẫu • Khoảng thời gian giữa các status messages phải ít nhất là 60 seconds, vậy thì nếu cho 1 thông báo mới xuất hiện 1 lần/năm có được không? Hoặc nếu không được nhiều hơn 60 second giữa các thông báo, vậy thì khoảng thời gian 1 millisecond có quá ngắn không? • Tuy các cách hiểu cực đoan này đều tương thích với yêu cầu gốc nhưng rõ ràng nó không phải là cái mà người dùng muốn quan tâm tới. Yêu cầu này không thể kiểm chứng được. Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

43. Ví dụ 1 về yêu cầu mẫu Sau khi thảo luận với khách hàng thì yêu cầu trên nên sửa lại như sau: The Background Task Manager (BTM) shall display status messages in a designated area of the user interface. • 1.1  The messages shall be updated every 60 plus or minus 10 seconds after background task processing begins. • 1.2 The messages shall remain visible continuously. Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

44. Ví dụ 1 về yêu cầu mẫu 1.3  Whenever communication with the background task process is possible, the BTM shall display the percent completed of the background task. 1.4  The BTM shall display a "Done" message when the background task is completed. 1.5  The BTM shall display a message if the background task has stalled. Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

45. Các ví dụ còn lại • Assignment 22: năm ví dụ về yêu cầu không thể kiểm chứng và cách sửa lại để có yêu cầu rõ ràng ( sách SW requirement.chm) Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

46. Từ điển dữ liệu(Data dictionary) • Data dictionary—a shared repository that defines the meaning, data type, length, format, necessary precision, and allowed range or list of values for all data elements or attributes used in the application. Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

47. Từ điển dữ liệu(Data dictionary) • Thông tin trong 1 từ điển dữ liệu có thể được dùng cho nhiều đặc tả yêu cầu khác nhau. • Các lỗi khi tích hợp thành phần sẽ giảm nếu tất cả developers đều tuân theo các định nghĩa chung trong từ điển dữ liệu. • Việc tập hợp các định nghĩa dữ liệu nên bắt đầu ngay trong lúc thu thập yêu cầu. Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

48. Từ điển dữ liệu(Data dictionary) • Từ điển dữ liệu có thể được đưa vào như 1 phụ lục của SRS hay tách ra thành 1 tài liệu riêng. Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

49. Lợi ích của từ điển dữ liệu • Dễ tìm kiếm thông tin • Tránh dư thừa và không đồng bộ (thay vì để các định nghĩa dữ liệu nằm rải rác trong phần yêu cầu chức năng) Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI

50. Từ yêu cầu người dùng đến mô hình phân tích • Từ yêu cầu của khách hàng, analyst có thể nhặt ra các từ khóa (keyword) và chuyển thành các phần tử của 1 mô hình nào đó. Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI