intTypePromotion=1
zunia.vn Tuyển sinh 2024 dành cho Gen-Z zunia.vn zunia.vn
ADSENSE

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

Chia sẻ: Hấp Hấp | Ngày: | Loại File: PPT | Số trang:52

62
lượt xem
5
download
 
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

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.

Chủ đề:
Lưu

Nội dung Text: Bài giảng Thu nhận yêu cầu: Chương 5 - Trần Thị Kim Chi

  1. Chapter 5 ̣ ̉ Đăc ta yêu cầu Requirement specifications 1 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 2 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? 3 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) 4 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. 5 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 6 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ự 7 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 8 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 9 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI
  10. Nguyên lý đặc tả 1. 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. 2. 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 đó 3. Đặ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 10 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI
  11. Nguyên lý đặc tả 4. Đặc tả phải bao gồm cả môi trường mà hệ thống vận hành 5. Đặ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 6. Đặ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 11 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI
  12. Nguyên lý đặc tả 7. Đặ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 8. Đặ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 12 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) 13 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI
  14. ̉ Ba cách diễn ta 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??? 14 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI
  15. ̣ ̉ Đăc ta yêu câ ̀u phần mềm Software requirements specification (SRS)  Đôi khi còn được gọi là  functional specification,  product specification,  requirements document,  system specification 15 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. 16 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 17 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI
  18. Các đối tượng sử dung 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ì. 18 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI
  19. Các đối tượng sử dung 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. 19 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI
  20. ̣ ưng cua SRS Đăc tr ̉  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. 20 Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI
ADSENSE

CÓ THỂ BẠN MUỐN DOWNLOAD

 

Đồng bộ tài khoản
2=>2