Bài giảng Nhập môn Công nghệ học Phần mềm - Phần III: Yêu cầu người dùng

Nhập môn Công nghệ học Phần mềmIntroduction to Software EngineeringDepartment of Software EngineeringFaculty of Information TechnologyHanoi University of TechnologyTEL: 04-8682595 FAX: 04-8692906 Email: cnpm@it-hut.edu.vnHUT, Falt. of IT1 Dept. of SE, 2002Phần IIIYêu cầu người dùngUser’s RequirementsChương 5: Phương pháp xác định yêu cầu5.1. Kỹ thuật xác định yêu cầu 5.2. Nội dung xác định yêu cầu5.3. Các nguyên lý phân tích yêu cầuHUT, Falt. of IT2 Dept. of SE, 20025.1. Kỹ thuật xác định yêu cầu phần mềmSW Requirements EngineeringYêu cầu phần mềm: là tất cả các yêu cầu về phầm mềm do khách hàng - người sử dụng phần mềm - nêu ra, bao gồm: các chức năng của phần mềm, hiệu năng của phần mềm, các yêu cầu về thiết kế và giao diện, các yêu cầu đặc biệt khácHUT, Falt. of IT3 Dept. of SE, 2002Thông thường các yêu cầu phần mềm được phân loại theo 4 thành phần của phần mềm:Các yêu cầu về phần mềm (Software)Các yêu cầu về phần cứng (Hardware)Các yêu cầu về dữ liệu (Data)Các yêu cầu về con người (People, Users)Mục đích: mục đích của yêu cầu phần mềm là xác định được phần mềm đáp ứng được các yêu cầu và mong muốn của khách hàng - người sử dụng phần mềmHUT, Falt. of IT4 Dept. of SE, 2002 Tại sao cần phải đặt ra yêu cầu phần mềm ?Khách hàng chỉ có những ý tưởng còn mơ hồ về phần mềm cần phải xây dựng để phục vụ công việc của họ, chúng ta phải sẵn sàng, kiên trì theo đuổi để đi từ các ý tưởng mơ hồ đó đến “Phần mềm có đầy đủ các tính năng cần thiết”Khách hàng rất hay thay đổi các đòi hỏi của mình, chúng ta nắm bắt được các thay đổi đó và sửa đổi các mô tả một cách hợp lýHUT, Falt. of IT5 Dept. of SE, 20025.2. Nội dung xác định yêu cầu phần mềmContents of Requirements EngineeringPhát hiện các yêu cầu phần mềm (Requirements elicitation)Phân tích các yêu cầu phần mềm và thương lượng với khách hàng (Requirements analysis and negotiation)Mô tả các yêu cầu phần mềm (Requirements specification)Mô hình hóa hệ thống (System modeling)Kiểm tra tính hợp lý các yêu cầu phần mềm (Requirements validation)Quản trị các yêu cầu phần mềm (Requirements management)HUT, Falt. of IT6 Dept. of SE, 2002Quy trình xác định yêu cầu phần mềmthe problemRequirementselicitationBuild aprototypeCreateanalysismodelsDevelopspecificationReviewHUT, Falt. of IT7 Dept. of SE, 2002The Analysis ModelData ModelBehavioralModelFunctionalModelHUT, Falt. of IT8 Dept. of SE, 20025.2.1. Phát hiện yêu cầu phần mềm (Requirements Elicitation)Các vấn đề của phát hiện yêu cầu phần mềm (Problems)Phạm vi của phần mềm (Scope)Hiểu rõ phần mềm (Understanding)Các thay đổi của hệ thống (Volatility)HUT, Falt. of IT9 Dept. of SE, 2002Phương pháp phát hiện yêu cầu phần mềm Requirements Elicitation MethodologyXác định các phương pháp sử dụng phát hiện các yêu cầu phần mềm: phỏng vấn, làm việc nhóm, các buổi họp, gặp gỡ đối tác, v.v.Tìm kiếm các nhân sự (chuyên gia, người sử dụng) có những hiểu biết sâu sắc nhất, chi tiết nhất về hệ thống giúp chúng ta xác định yêu cầu phần mềm Xác định “môi trường kỹ thuật - technical environment”Xác định các “ràng buộc lĩnh vực domain constraints”Thu hút sự tham gia của nhiều chuyên gia, khách hàng để chúng ta có được các quan điểm xem xét phần mềm khác nhau từ phía khách hàngThiết kế các kịch bản sử dụng của phần mềmHUT, Falt. of IT10 Dept. of SE, 2002Sản phẩm (output) của “phát hiện yêu cầu phần mềm”Bảng kê (statement) các đòi hỏi và chức năng khả thi của phần mềmBảng kê phạm vi ứng dụng của phần mềmMô tả môi trường kỹ thuật của phần mềmBảng kê tập hợp các kịch bản sử dụng của phần mềmCác nguyên mẫu xây dựng, phát triển hay sử dụng trong phần mềm (nếu có)Danh sách nhân sự tham gia vào quá trình phát hiện các yêu cầu phần mềm - kể cả các nhân sự từ phía công ty- khách hàng HUT, Falt. of IT11 Dept. of SE, 20025.2.2. Phân tích các yêu cầu phần mềm và thương lượng với khách hàngSoftwareEngineeringGroupCustomerGroupHUT, Falt. of IT12 Dept. of SE, 2002Requirements Analysis and NegotiationPhân loại các yêu cầu phần mềm và sắp xếp chúng theo các nhóm liên quan Khảo sát tỉ mỉ từng yêu cầu phần mềm trong mối quan hệ của nó với các yêu cầu phần mềm khácThẩm định từng yêu cầu phần mềm theo các tính chất: phù hợp, đầy đủ, rõ ràng, không trùng lặpHUT, Falt. of IT13 Dept. of SE, 2002Requirements Analysis and NegotiationPhân cấp các yêu cầu phần mềm theo dựa trên nhu cầu và đòi hỏi khách hàng / người sử dụngThẩm định từng yêu cầu phầm mềm để xác định chúng có khả năng thực hiện được trong môi trường kỹ thuật hay không, có khả năng kiểm định các yêu cầu phần mềm hay khôngThẩm định các rủi ro có thể xảy ra với từng yêu cầu phần mềmHUT, Falt. of IT14 Dept. of SE, 2002Requirements Analysis and NegotiationĐánh giá thô (tương đối) về giá thành và thời gian thực hiện của từng yêu cầu phần mềm trong giá thành sản phẩm phần mềm và thời gian thực hiện phần mềmGiải quyết tất cả các bất đồng về yêu cầu phần mềm với khách hàng / người sử dụng trên cơ sở thảo luận và thương lượng các yêu cầu đề raHUT, Falt. of IT15 Dept. of SE, 20025.2.3. Đặc tả yêu cầu phần mềmĐặc tả các yêu cầu phần mềm là công việc xây dựng các tài liệu đặc tả, trong đó có thể sử dụng tới các công cụ như: mô hình hóa, mô hình toán học hình thức (a formal mathematical model), tập hợp các kịch bản sử dụng, các nguyên mẫu hoặc bất kỳ một tổ hợp các công cụ nói trênChất lượng của hồ sơ đặc tả đánh giá qua các tiêu thứcTính rõ ràng, chính xácTính phù hợpTính đầy đủ, hoàn thiệnHUT, Falt. of IT16 Dept. of SE, 2002Requirements SpecificationCác thành phần của hồ sơ đặc tảĐặc tả phi hình thức (Informal specifications) được viết bằng ngôn ngữ tự nhiênĐặc tả hình thức (Formal specifications) được viết bằng tập các ký pháp có các quy định về cú pháp (syntax) và ý nghĩa (sematic) rất chặt chẽĐặc tả vận hành chức năng (Operational specifications) mô tả các hoạt động của hệ thống phần mềm sẽ xây dựngĐặc tả mô tả (Descriptive specifications) – đặc tả các đặc tính đặc trưng của phần mềmHUT, Falt. of IT17 Dept. of SE, 2002Requirements SpecificationĐặc tả chức năng (Operational Specifications): thông thường khi đặc tả các chức năng của phần mềm người ta sử dụng các công cụ tiêu biểu sauBiểu đồ luồng dữ liệu (Data Flow Diagrams)Máy trạng thái hữu hạn (Finite State MachinesMạng Petri (Petri nets)HUT, Falt. of IT18 Dept. of SE, 2002Requirements SpecificationĐặc tả mô tả (Descriptive Specifications)Biểu đồ thực thể liên kết (Entity-Relationship Diagrams)Đặc tả Logic (Logic Specifications)Đặc tả đại số (Algebraic Specifications)HUT, Falt. of IT19 Dept. of SE, 2002Biểu đồ luồng dữ liệu (DFD)Hệ thống (System): tập hợp các dữ liệu (data) được xử lý bằng các chức năng tương ứng (functions)Các ký pháp sử dụng: Thể hiện các chức năng (functions) Thể hiện luồng dữ liệu Kho dữ liệu Vào ra dữ liệu và tương tác giữa hệ thống và người sử dụngHUT, Falt. of IT20 Dept. of SE, 2002Ví dụ mô tả biểu thức toán học bằng DFD+**+baadc(a+b)*(c+a*d)HUT, Falt. of IT21 Dept. of SE, 2002Ví dụ đặc tả các chức năng của thư viện qua DFDCã s¸chT×m theo chñ ®ÒYªu cÇu tõ ng­êi m­înKho s¸chDanh s¸ch t¸c gi¶Danh s¸ch tªn s¸chDanh s¸ch chñ ®ÒChñ ®Ò yªu cÇu §­a ra Tªn s¸chDanh s¸ch ng­êi m­înTh«ng tin vÒ s¸chS¸chChñ ®ÒTªn t¸c gi¶Tªn s¸chLiÖt kª c¸c tªn s¸ch liªn quan ®Õn chñ ®ÒTªn s¸ch;Tªn ng­êi m­înS¸chTªn s¸ch, t¸c gi¶Tªn ng­êi m­înHUT, Falt. of IT22 Dept. of SE, 2002Các hạn chế của DFDý nghĩa của các ký pháp sử dụng được xác định bởi các định danh lựa chọn của NSDVí dụ của chức năng tìm kiếm:If NSD nhập vào cả tên tác giả và tiêu đề sách Then tìm kiếm sách tương ứng, không có thì thông báo lỗiElseif chỉ nhập tên tác giả Then hiển thị danh sách các sách tương ứng với tên tác giả đã nhập và yêu cầu NSD lựa chọn sách Elseif chỉ nhập tiêu đề sách Then . . .EndifHUT, Falt. of IT23 Dept. of SE, 2002Trong DFD không xác định rõ các hướng thực hiện (control aspects)Biểu đồ DFD này không chỉ rõ đầu vào là gì để thực hiện chức năng D và đầu ra là gì sau khi thựchiện chức năng D.ABCDFEHUT, Falt. of IT24 Dept. of SE, 2002Chức năng D có thể cần cả A, B và CChức năng D có thể chỉ cần một trong A, B và C để thực hiệnChức năng D có thể kết xuất kết quả cho một trong E và FChức năng D có thể kết xuất kết quả chung cho cả E và FChức năng D có thể kết xuất kết quả riêng cho cả E và FABCDFEHUT, Falt. of IT25 Dept. of SE, 2002DFD không xác định sự đồng bộ giữa các chức năng / mô-đunA xử lý dữ liệu và B được hưởng (nhận) các kết quả được xử lý từ AA và B là các chức năng không đồng bộ (asynchronous activities) vì thế cần có buffer để ngăn chặn tình trang mất dữ liệuABHUT, Falt. of IT26 Dept. of SE, 2002Finite State Machines (FSM)FSM chứa Tập hữu hạn các trạng thái QTập hữu hạn các đầu vào ICác chức năng chuyển tiếp ONOFFHigh pressure alarmHigh temp. alarmRestartHUT, Falt. of IT27 Dept. of SE, 2002Đặc tả các yêu cầu phần mềm bằng FSMXem xét ví dụ về thư viện với các giao dịch như sau:Mượn sách / Trả sáchThêm đầu sách / Loại bỏ đầu sáchLiệt kê danh sách các đầu sách theo tên tác giả hay theo chủ đềTìm kiếm sách theo các yêu cầu của người mượnTìm kiếm sách quá hạn trả, . . .HUT, Falt. of IT28 Dept. of SE, 2002Đặc tả . . .Các yêu cầu đặc biệt của thư viện:Độc giả không được mượn quá một số lượng sách nhất định, trong một thời gian nhất địnhMột số sách không được mượn vềMột số người không được mượn một số loại sách nào đó, . . .HUT, Falt. of IT29 Dept. of SE, 2002Các đối tượng – Tên sách Mã quyển Nhân viên phục vụ Người mượnChúng ta cần có tập hợp (danh sách) các tiêu đề sách, danh sách các tác giả cho từng quyển sách, danh sách các chủ đề liên quan của các quyển sáchTa có tập hợp các sách (mỗi đầu sách có thể có nhiều quyển sách trong thư viện). Mỗi quyển sách có thể có 1 trong 5 trạng thái sau:(AV) - Available được phép mượn, (CO) - (BR) - đã mượn (Check Out; Borrow), (L): Last, (R): RemoveHUT, Falt. of IT30 Dept. of SE, 2002FSM đặc tả các trạng tháiCOAVBRLRCó thể có hạn chế về số sách được mượn cho 1 nhóm độc giả hoặc mọi độc giả, . . .HUT, Falt. of IT31 Dept. of SE, 2002Mô hình đặc tả : Mô hình thực thể liên kếtMô hình khái niệm cho phép đặc tả các yêu cầu logic của hệ thống, thường được sử dụng trong các hệ thống dữ liệu lớn ER ModelThực thểQuan hệThuộc tính Biểu đồ thực thể HUT, Falt. of IT32 Dept. of SE, 2002Thực thể – tập hợp các thông tin liên quan cần được xử lý trong phần mềm Thực thể có thể có mối quan hệ: – person owns carPersonOwnsCarHUT, Falt. of IT33 Dept. of SE, 2002Thực thể có các thuộc tínhThuộc tính: Tính chất của một thực thể hoặc một đối tượng dữ liệuđặt tên cho 1 mẫu (instance) của đối tượng dữ liệumô tả mẫu (instance)tạo liên kết (reference) đến các mẫu khác CarFordBlueIDAutomobile CompanyFordTập các thuộc tính của 1 đối tượng dữ liệu được xác định thông qua ngữ cảnh của bài toánHUT, Falt. of IT34 Dept. of SE, 2002Quan hệ – chỉ ra mối liên quan gữa các đối tượng dữ liệuBookstoreOrdersBooks1N Cardinality : chỉ ra định lượng của mối quan hệ1:1 one-to-one 1:N one-to-many M:N many-to-many Modality : 0 – có thể có, có thể không có quan hệ 1 – bắt buộc có quan hệCustomerIs provided withRepair Action1NHUT, Falt. of IT35 Dept. of SE, 2002Ví dụ ERD mô tả thư việnAreaTitleAuthorDeals withWritten byBelongs toCopyholdsWas held byBorrowerstate1MNNNText1ER diagram for a librarylimitHUT, Falt. of IT36 Dept. of SE, 2002Các yêu cầu của một đặc tả tốtĐẽ hiểu với người dùngCó ít điều nhập nhằngCó ít quy ước khi mô tả, có thể tạo đơn giảnVới phong cách từ trên xuống (topdown)Dễ triển khai cho những pha sau của vòng đời: thiết kế hệ thống và thiết kế chương trình và giao diện dễ làm, đảm bảo tính nhất quán, . . .HUT, Falt. of IT37 Dept. of SE, 20025.3. Các nguyên lý phân tích yêu cầu sử dụngNguyên lý I. Mô hình hóa dữ liệuXác định các đối tượng dữ liệuXác định các đặc tính của các đối tượng dữ liệuThiết lập các mối quan hệ giữa các đối tượng dữ liệuHUT, Falt. of IT38 Dept. of SE, 2002Các nguyên lý phân tích yêu cầu sử dụngNguyên lý II. Mô hình hóa các chức năngXác định các chức năng chuyển đổi đối tượng dữ liệuChỉ ra luồng dữ liệu đi qua hệ thống như thế nàoBiểu diễn bộ phận sản sinh dữ liệu và bộ phận tiêu thụ dữ liệuHUT, Falt. of IT39 Dept. of SE, 2002Các nguyên lý phân tích yêu cầu sử dụng Nguyên lý III. Mô hình hóa hành viChỉ ra các trạng thái (states) khác nhau của hệ thốngĐặc tả các hiện tượng (events) làm hệ thống thay đổi trạng tháiHUT, Falt. of IT40 Dept. of SE, 2002Các nguyên lý phân tích yêu cầu sử dụngNguyên lý IV. Partition the ModelsTinh lọc từng mô hình để biểu diễn các mức trừu tượng thấp hơn Lọc đối tượng dữ liệuTạo ra phân cấp chức năngBiểu diễn hành vi (behavior) ở các mức chi tiết khác nhauHUT, Falt. of IT41 Dept. of SE, 2002Các nguyên lý phân tích yêu cầu sử dụngNguyên lý V. Bản chất (Essence)Hãy bắt đầu bằng cách tập trung vào bản chất của vấn đề chứ không xem xét những chi tiết cài đặt (begin by focusing on the essence of the problem without regard to implementation details)New Tool: Unified Modeling Language (UML)!HUT, Falt. of IT42 Dept. of SE, 2002