Bài giảng Thu nhận yêu cầu - Chương 5: Đặc tả yêu cầu - Trần Thị Kim Chi

Chapter 5Đặc tả yêu cầuRequirement specificationsBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI1Nội dungBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI2Requirement specifications (Đặc tả yêu cầu)Đặc tả yêu cầu phần mềmTừ điển dữ liệuĐặc tả yêu cầuBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI3Đặ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?Phân Loại Đặc tả yêu cầuBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI4Đặ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)Đặc tả Phi Hình ThứcBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI5Là đặ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.Đặc tả Hình ThứcBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI6Là đặ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Đặc tả Hình ThứcBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI7Có 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ạpTiế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ựĐặc tả Hình ThứcBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI8Thuậ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Đặc tả Hình ThứcBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI9Hạ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ớiChi 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ọcNguyên lý đặc tảBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI10Phâ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 địnhNguyên lý đặc tảBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI11Đặ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ôngNguyên lý đặc tảBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI12Đặ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 Tài liệu về yêu cầuBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI13Kế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)Ba cách diễn tả yêu cầu phần mềmBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI14Vă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???Đặc tả yêu cầu phần mềmSoftware requirements specification (SRS)Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI15Đôi khi còn được gọi là functional specification,product specification, requirements document,system specificationQuy tắc nghiệp vụ và SRSBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI16Để 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ắcPhò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 đổiGiữ 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ắcThuậ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.Quy tắc nghiệp vụ và SRSBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI17Lý 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ảnhCác đối tượng sử dụng SRSBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI18Customers, 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ì.Các đối tượng sử dụng SRSBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI19Ngườ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.Đặc trưng của SRSBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI20SRS 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. Đặc trưng của SRSBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI21Khô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ùngCách bố trí SRSBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI22Đặ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ểuCách bố trí SRSBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI23Use 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. SRS TemplateBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI24Mỗ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 SRS TemplateBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI25Hướng dẫn viết SRS – Phần IntrodutionBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI261.1. PurposeXác định sản phẩm cùng với số phiên bản sẽ phát hành1.2. Document ConventionsMô 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ệuIndented Audience and Reading Suggestions1.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ấtHướng dẫn viết SRS – Phần IntrodutionBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI271.4. Project ScopeCung 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ặp1.5. ReferencesLiệ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,Hướng dẫn viết SRS – Phần IntrodutionBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI282.1. Project perspectiveMô 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ớiNế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ềmHướng dẫn viết SRS – Phần IntrodutionBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI292.2. Project FeatureLiệ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 characteristicsXá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.Hướng dẫn viết SRS – Phần IntrodutionBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI302.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 caoHướng dẫn viết SRS – Phần IntrodutionBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI312.5. Design and Implementation ConstraintsMô tả các ràng buộc liên quan đến thiết kế và thực thi hệ thốngCá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 browsersHướng dẫn viết SRS – Phần IntrodutionBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI32Các ràng buộc như sau:Các qui ước và tiêu chuẩn phát triển SWTí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.Hướng dẫn viết SRS – Phần IntrodutionBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI332.6. User DocumentationLiệ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 DependenciesGiả 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.Hướng dẫn viết SRS – Phần IntrodutionBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI342.7. Assumptiom and DependenciesMột vài ví dụ về giả thiếtMộ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ướcHướng dẫn viết SRS – Phần IntrodutionBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI352.7. Assumptiom and DependenciesXá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 đóHướng dẫn viết SRS – Phần IntrodutionBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI36Trì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ống3.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étHướng dẫn viết SRS – Phần IntrodutionBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI374.1. User InterfaceMô 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 constraintsStandard buttons, functions, or navigation links that will appear on every screen such as help buttonSo sánh SRS và vision document Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI38Có 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. Cách viết requirementBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI39Khô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. Một vài gợi ý để viết requirementBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI40Viế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 requirementVí dụ 1 về yêu cầu mẫuBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI41"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ênPhâ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. Ví dụ 1 về yêu cầu mẫuBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI42Khoả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. Ví dụ 1 về yêu cầu mẫuBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI43Sau 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.Ví dụ 1 về yêu cầu mẫuBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI441.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.Các ví dụ còn lạiBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI45Assignment 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)Từ điển dữ liệu(Data dictionary)Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI46Data 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.Từ điển dữ liệu(Data dictionary)Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI47Thô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.Từ điển dữ liệu(Data dictionary)Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI48Từ đ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. Lợi ích của từ điển dữ liệuBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI49Dễ 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) Từ yêu cầu người dùng đến mô hình phân tíchBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI50Từ 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 đó. Vai Trò của Từ ĐiểnBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI51Từ khóa và các thành phần mô hình phân tíchBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI52