Các yêu cầu phần mềm

Chia sẻ: Nguyễn Thịnh Chiến | Ngày: | Loại File: PPT | Số trang:60

Thêm vào BST

Báo xấu

137
lượt xem 23
download

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

Yêu cầu có thể giới hạn từ một phát biểu trừu tượng mức cao về một dịch vụ hoặc một ràng buộc hệ thống đến một đặc tả chức năng toán học chi tiết. l Giới hạn này là không tránh khỏi vì các yêu cầu có thể: • Được sử dụng để đấu giá, do đó chúng phải dễ hiểu cho mọi đối tượng người đọc • Có thể là cơ sở của bản hợp đồ

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Các yêu cầu phần mềm

Các yêu cầu phần mềm ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 1
Mục tiêu Giới thiệu các khái niệm về yêu cầu người q dùng và yêu cầu hệ thống Mô tả các yêu cầu chức năng và các yêu cầu q phi chức năng Giải thích cách thức các yêu cầu phần mềm q được tổ chức trong tài liệu yêu cầu ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 2
Các chủ đề Yêu cầu là gì? Các yêu cầu chức năng và phi chức năng Các yêu cầu người dùng Các yêu cầu hệ thống Đặc tả giao diện Tài liệu yêu cầu phần mềm Kỹ nghệ yêu cầu (RE) ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 3
Yêu cầu là gì? Yêu cầu có thể giới hạn từ một phát biểu trừu q tượng mức cao về một dịch vụ hoặc một ràng buộc hệ thống đến một đặc tả chức năng toán học chi tiết. Giới hạn này là không tránh khỏi vì các yêu cầu q có thể: • Được sử dụng để đấu giá, do đó chúng phải dễ hiểu cho mọi đối tượng người đọc • Có thể là cơ sở của bản hợp đồng – do đó chúng phải được định nghĩa chi tiết ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 4
Sự trừu tượng hóa yêu cầu (Davis) “If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organisation’s needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.” ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 5
Các kiểu yêu cầu Yêu cầu người dùng q • Là các phát biểu bằng ngôn ngữ tự nhiên và các biểu đồ v ề các dịch vụ mà hệ thống cung cấp và các ràng buộc vận hành của nó. Được viết cho các khách hàng. Các yêu cầu hệ thống q • Là các mô tả chi tiết về các chức năng của hệ th ống, các dịch vụ và các ràng buộc vận hành, được trình bày trong một tài liệu có cấu trúc. Tài liệu này phải định nghĩa chính xác nh ững gì nên được cài đặt và có thể là một phần của bản h ợp đồng giữa khác hàng và nhà thầu. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 6
Các định nghĩa và các đặc tả User requir ement definition 1. T he softw ar e m ust pr ovide a means of r epr esenting and 1. accessing e xternal files cr ea ted b y other tools . Syst em requir ements specification 1.1 The user should be pr ovided with facilities to define the type of 1.2 external files . 1.2 Each e xternal file type ma y ha ve an associa ted tool w hich ma y be 1.2 applied to the file . 1.3 Each e xternal file type ma y be r epr esented as a specific icon on 1.2 the user’ s displa y . 1.4 F acilities should be pr o vided f or the icon r epr esenting an 1.2 e xternal file type to be defined b y the user . 1.5 When a user selects an icon r epr esenting an e xternal file , the 1.2 effect of that selection is to apply the tool associated with the type of 1.2 the external file to the file represented by the selected icon. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 7
Những người đọc yêu cầu Client mana gers S ystem end-users User Client eng ineers requir ements Contr actor mana gers S ystem ar chitects S ystem end-users S ystem Client eng ineers requir ements S ystem ar chitects Softw ar e de velopers Client eng ineers (perha ps) Softw are design S ystem ar chitects specifica tion Softw ar e de velopers ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 8
Các yêu cầu chức năng & phi chức năng Các yêu cầu chức năng q • Là các phát biểu về các dịch vụ mà hệ thống sẽ cung cấp, cách thức hệ thống phản ứng với các đầu vào đặc biệt và cách thức hệ thống ứng xử với các tình huống đặc biệt. Các yêu cầu phi chức năng q • Là các ràng buộc trên các dịch vụ hoặc các chức năng được yêu cầu bởi hệ thống như các ràng buộc về thời gian, các ràng buộc về tiến trình phát triển, các chuẩn, … Các yêu cầu miền q • Là các yêu cầu đến từ miền ứng dụng của hệ thống, thay vì đến từ người dùng và phản ứng các đặc tính của miền đó. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 9
Các yêu cầu chức năng Mô tả chức năng hoặc các dịch vụ hệ thống q Phụ thuộc vào: q • kiểu phần mềm, • những mong đợi của người dùng và • kiểu hệ thống ở đó phần mềm được sử dụng. Các yêu cầu chức năng của người dùng có thể: q • là các phát biểu mức cao về những gì không là các yêu cầu chức năng hệ thống • không là các mô tả dịch vụ hệ thống chi tiết. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 10
Ví dụ: Xét hệ thống LIBSYS LIBSYS: q • là hệ thống cung cấp một giao diện đơn cho một số CSDL bài báo trong các thư viện khác nhau. • Người dùng có thể tìm kiếm, download và in các bài báo này cho các nghiên cứu cá nhân. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 11
Ví dụ: các yêu cầu chức năng của LIBSYS Người dụng có thể tìm kiếm trên toàn bộ các q CSDL hoặc một tập nhỏ các CSDL. Hệ thống sẽ cung cấp các hiển thị phù hợp cho q người dùng đọc các tài liệu trong kho tài liệu. Mọi đơn đặt hàng phải có một định danh duy q nhất (ORDER_ID) mà người dùng có thể copy đến vùng lưu trữ thường trực của tài khoản. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 12
Sự mơ hồ của các yêu cầu Các vấn đề phát sinh khi các yêu cầu không q được phát biểu chính xác. Các yêu cầu mập mờ có thể được hiểu theo các q cách khác nhau bởi những người phát triển và người dùng. Xét thuật ngữ ‘appropriate viewers’: q • Ý định của người dùng – Hiển thị với mục đích cụ thể cho mỗi kiểu tài liệu khác nhau; • Người phát triển hiểu – Cung cấp một hiển thị văn bản mà chỉ ra các nội dung của tài liệu. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 13
Tính đầy đủ & tính phù hợp của các yêu cầu Về nguyên tắc, các yêu cầu phải đầy đủ và thống q nhất. Tính đầy đủ q Chúng nên chứa mọi mô tả về các tiện ích được yêu cầu. Thống nhất q Chúng không chứa các xung đột hoặc các mâu thuẫn trong các mô tả về các tiện ích hệ thống. => Trong thực tế, rất khó có thể tạo ra tài liệu yêu cầu th ống nhất và đầy đủ ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 14
Các yêu cầu phi chức năng Các yêu cầu này định nghĩa các thuộc tính và các ràng q buộc của hệ thống. Ví dụ yêu cầu về độ tin cậy, các yêu cầu về thời gian phản hồi, yêu cầu về lưu trữ. Các ràng buộc như khả năng của thiết bị vào/ra, các biểu diễn hệ thống, … Các yêu cầu phi chức năng có thể quan trọng hơn các q yêu cầu chức năng. Nếu chúng không được thỏa mãn, hệ thống có thể trở nên vô ích. Ví dụ: Hệ thống điều khiển máy bay nếu không tin cậy q => không được phê chuẩn, không được sử dụng. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 15
Phân loại các yêu cầu phi chức năng Các yêu cầu về sản phẩm q • Các yêu cầu đặc tả rằng sản phẩm được phát hành phải ứng xử theo cách đặc biệt, ví dụ: tốc độ thực thi, độ tin cậy, etc. Các yêu cầu tổ chức q • Các yêu cầu nẩy sinh từ các chính sách và các thủ tục của tổ chức, ví dụ các chuẩn tiến trình được sử dụng, các yêu cầu cài đặt, etc. Các yêu cầu bên ngoài q • Các yêu cầu nẩy sinh từ các nhân tố nằm ngoài hệ thống và tiến trình phát triển nó, ví dụ: Các yêu cầu về khả năng tương tác, các yêu cầu tương thích, etc. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 16
Các kiểu yêu cầu phi chức năng Non-functional requir ements Pr oduct Organisational E xternal r equir ements requir ements r equir ements E fficiency Relia bility Por ta bility Inter oper a bility Ethical requir ements r equir ements requir ements requir ements r equir ements Usa bility Deli very Implementa tion Standar ds Leg islativ e r equir ements requir ements requir ements requir ements requir ements Per for mance Space Pri vacy Safety requir ements r equir ements r equir ements requir ements ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 17
Các VD về yêu cầu phi chức năng Yêu cầu về sản phẩm q 8.1 Giao diện người dùng cho LIBSYS nên được cài đặt bởi HTML mà không chứa các frame hoặc Java applets. Yêu cầu tổ chức q 9.3.2 Tiến trình phát triển hệ thống và các tài liệu phát hành phải theo những gì được định nghĩa trong XYZCo-SP-STAN- 95. Yêu cầu ngoài q 7.6.5 Hệ thống không được lộ thông tin cá nhân của các khách hành như họ tên và số tham chiếu đến các thao tác c ủa h ệ thống. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 18
Các mục tiêu và các yêu cầu Các yêu cầu phi chức năng có thể rất khó phát biểu q chính xác và các yêu cầu không chính xác rất khó đ ể thẩm định. Mục tiêu q • Mục tiêu phổ biến/chung của người dùng là dễ sử dụng. Các yêu cầu phi chức năng có thể thẩm định q • Một phát biểu sử dụng một số phép đo có thể được kiểm thử một cách khách quan. Các mục tiêu hữu ích cho những nhà phát triển vì chúng q truyền tải được các ý định/mong muốn của những người dùng hệ thống. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 19
Các ví dụ Mục tiêu hệ thống q • Hệ thống nên dễ sử dụng bởi những người điều khiển có kinh nghiệm và nên được tổ chức theo cách tối thiểu hóa các lỗi người dùng. Yêu cầu phi chức năng có thể thẩm định q • Những người điểu khiển hệ thống có kinh nghiệm có th ể sử dụng mọi chức năng của hệ thống sau 2 tiếng huấn luyện. Sau thời gian huấn luyện này, số lỗi được tạo bởi họ không vượt quá 2 lỗi/1 ngày. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 Slide 20