Bài giảng Thu nhận yêu cầu - Chương 5: Đặc tả yêu cầu cung cấp cho người học các kiến thức: Requirement specifications (đặc tả yêu cầu), đặc tả yêu cầu phần mềm, từ điển dữ liệu. Mời các bạn tham khảo nội dung chi tiết.
Chapter Đặc tả yêu cầu Requirement specifications Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 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 Đặc tả yêu cầu Đặc tả yêu cầu người xây dựng hệ thống phải trả lời câu hỏi sau: •Đầu hệ thống •Hệ thống phải làm để có kết quả mong muốn nghĩa phải xử lý những •Những tài ngun mà hệ thống u cầu •Các hệ thống phần mềm lớn ln đòi hỏi cải tiến từ hiện trạng Mặc dù khó khăn hệ thống hiện có thể xác định ảnh hưởng hiệu ứng hệ thống khó dự đốn trước •Hệ thống lớn thường có nhiều cợng đồng sử dụng khác Họ có yêu cầu ưu tiên khác Các u cầu hệ thống cuối •Người trả tiền cho hệ thống người sử dụng khác ai? Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI Phân Loại Đặc tả yêu cầu Đặc tả yêu cầu có thể chia thành loại: •Đặc tả phi hình thức (ngơn ngữ tự nhiên) •Đặc tả hình thức (dựa kiến trúc tốn học) Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI Đặc tả Phi Hình Thức Là đặc tả sử dụng ngôn ngữ tự nhiên Tuy không chặt chẽ đặc tả hình thức nhiều người biết có thể trao đổi với để làm xác hóa điểm chưa rõ, chưa thống giữa 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 Đặc tả Hình Thức Là đặc tả mà từ ngữ, cú pháp, ngữ nghĩa định nghĩa hình thức dựa vào tốn học Đặc tả hình thức có thể coi một phần hoạt động đặc tả phần mềm Các đặc tả yêu cầu phân tích chi tiết Các mô tả trừu tượng chức chương trình có thể tạo để làm rõ u cầu Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI Đặc tả Hình Thức Có hai phương pháp đặc tả hình thức để phát triển hệ thống tương đối phức tạp Tiếp cận đại số, hệ thống mơ tả dạng tốn tử quan hệ Tiếp cận mơ hình, mơ hình hệ thống cấu trúc sử dụng thực thể toán học tập hợp thứ tự Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI Đặc tả Hình Thức Thuận lợi sử dụng đặc tả hình thức: •Cho phép thấy hiểu bản chất bên yêu cầu, cách tốt để làm giảm lỗi, thiếu sót có thể xảy giúp cho cơng việc thiết kế thuận lợi •Do sử dụng toán học cho việc đặc tả nên có thể dựa vào cơng cụ tốn học phân tích điều làm tăng thêm tính chắn tính đầy đủ hệ thống •Đặc tả hình thức bản thân cho cách thức cho việc kiểm tra hệ thống sau Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI Đặc tả Hình Thức Hạn chế 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 nó, khơng sẵn sàng chấp nhận kỹ thuật •Chi phí thường cao so với đặc tả khác •Phần lớn những người đặc tả khơng đào tạo cách qui 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 thói quen họ •Nhiều thành phần hệ thống khó cho việc đặc tả ngơn ngữ hình thức Thêm vào khách hàng khơng thể hiểu •Khách hàng khơng thích đặc tả tốn học Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI Nguyên lý đặc tả Phân tách chức với cài đặt: đặc tả mô tả điều mong muốn không phải cách thức thực hiện (cài đặt) Kết quả thu theo dạng khơng phải 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 trường hợp môi trường động thay đổi ảnh hưởng tới hành vi thực thể tương tác với mơi trường Đặc tả phải bao gồm hệ thống có phần mềm mợt thành phần: hệ thống bao gồm thành phần tương tác với nhau, bên hoàn cảnh tồn bợ hệ thống tương tác giữa thành phần hành vi mợt thành phần có thể xác định 10 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI So sánh SRS vision document Có số phần trùng giữa SRS vision & scope document project scope, product features, operating environment ….) Vì có số dự án nhỏ cần tạo tài liệu requirement đủ Do muốn dùng cả loại cần điều chỉnh để loại trừ phần trùng lặp giữa tài liệu Có thể sử dụng section tương đương SRS mơ tả chi tiết thơng tin có tính sơ bợ hay mức cao vision and scope document 38 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI Cách viết requirement Khơng có cách thống để viết requirement một cách tốt nhất; mà chủ yếu từ kinh nghiệm (experience) Những vấn đề vấp phải khứ cho ta học đáng giá tương lai 39 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI Một vài gợi ý để viết requirement Viết câu văn phạm, tả Câu văn đoạn văn nên ngắn gọn trực tiếp Sử dụng thể chủ động (active voice) VD: "The system shall something," không dùng "Something shall happen.” Assignment 21: Gợi ý viết requirement 40 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI Ví dụ 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 phát biểu Phân tích: 41 Status messages gì? Chúng cung cấp cho người dùng điều kiện theo kiểu gì? Nếu thơng báo hiển thị, chúng xuất hiện 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 Ví dụ yêu cầu mẫu Khoảng thời gian giữa status messages phải 60 seconds, cho thơng báo xuất hiện lần/năm có khơng? Hoặc khơng nhiều 60 second giữa thông báo, khoảng thời gian millisecond có q ngắn khơng? Tuy cách hiểu cực đoan tương thích với u cầu gốc rõ ràng khơng phải mà người dùng muốn quan tâm tới Yêu cầu không thể kiểm chứng 42 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI Ví dụ yêu cầu mẫu Sau thảo luận với khách hàng yêu cầu nên sửa lại 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 43 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI Ví dụ 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 44 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI Các ví dụ cịn lại Assignment 22: năm ví dụ u cầu khơng thể kiểm chứng cách sửa lại để có yêu cầu rõ ràng ( sách SW requirement.chm) 45 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI 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 46 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI Từ điển dữ liệu (Data dictionary) Thông tin từ điển dữ liệu có thể dùng cho nhiều đặc tả yêu cầu khác Các lỗi tích hợp thành phần giảm tất cả developers tuân theo định nghĩa chung từ điển dữ liệu Việc tập hợp định nghĩa dữ liệu nên bắt đầu lúc thu thập yêu cầu 47 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI Từ điển dữ liệu (Data dictionary) Từ điển dữ liệu có thể đưa vào phụ lục SRS hay tách thành tài liệu riêng 48 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI Lợi ích từ điển dữ liệu Dễ tìm kiếm thông tin Tránh dư thừa không đồng bộ (thay để định nghĩa dữ liệu nằm rải rác phần yêu cầu chức năng) 49 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI Từ u cầu người dùng đến mơ hình phân tích Từ yêu cầu khách hàng, analyst có thể nhặt từ khóa (keyword) chuyển thành phần tử mơ hình 50 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI Vai Trị Từ Điển 51 Bài giảng mơn Thu nhận yêu cầu - BM HTTT - HUI Từ khóa thành phần mơ hình phân tích 52 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI ... 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 Đặc tả yêu cầu Đặc tả yêu cầu người xây dựng hệ... phần mềm Các đặc tả yêu cầu phân tích chi tiết Các mơ tả trừu tượng chức chương trình có thể 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 Đặc tả Hình Thức... môn Thu nhận yêu cầu - BM HTTT - HUI SRS Template Mỗi tổ chức SW nên thừa nhận cách viết SRS cho dự án theo hay số mẫu tiêu chuẩn Xem phụ lục D 24 Bài giảng môn Thu nhận yêu cầu - BM