• Các đặc tính của hệ thống hay sản phẩm do khách hàng - người sử dụng phần mềm - nêu ra 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 [r]
(1)PHẦN III:
PHƯƠNG PHÁP XÁC ĐỊNH YÊU CẦU NGƯỜI DÙNG
I Tổng quan yêu cầu phần mềm II Quy trình xác định yêu cầu phần mềm III Công cụ phương pháp đặc tả yêu cầu
phần mềm
IV Nguyên lý phân tích yêu cầu sử dụng
1
1 Khái niệm
• Các đặc tính hệ thống hay sản phẩm khách hàng - người sử dụng phần mềm - nêu Xác định phần mềm đáp ứng yêu
cầu mong muốn khách hàng - người sử dụng phần mềm
Lĩnh vực ứng dụng hệ thống/sản phẩm Nhu cầu ràng buộc người có quyền lợi nghĩa vụ liên quan đến hệ thống /sản phẩm
Bài toán khách hàng cần giải
Ngữ cảnh nghiệp vụ: tương tác hệ thông/sản phẩm đóng góp mặc nghiệp vụ hệ thống
(2)Tại cần phải đặt yêu cầu phần mềm ?
• Khách hàng có ý tưởng cịn mơ hồ phần mềm cần phải xây dựng để phục vụ công việc họ, phải sẵn sàng, kiên trì theo đuổi để từ ý tưởng mơ hồ đến “Phần mềm có đầy đủ tính cần thiết”
• Khách hàng hay thay đổi địi hỏi mình, nắm bắt thay đổi sửa đổi mơ tả cách hợp lý
3
2 Phân loại
• Theo thành phần phần mềm:
– Các yêu cầu phần mềm (Software) – Các yêu cầu phần cứng (Hardware) – Các yêu cầu liệu (Data)
– Các yêu cầu người (People, Users) • Theo cách đặc tả phần mềm
– Các yêu cầu chức – Các yêu cầu chức – Các ràng buộc khác
(3)II Quy trình xác định yêu cầu PM • Phát yêu cầu phần mềm (Requirements
elicitation)
• Phân tích u cầu phần mềm thương
lượng với khách hàng (Requirements analysis and negotiation)
• Đặc tả 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ý yêu cầu phần mềm (Requirements validation)
• Quản trị yêu cầu phần mềm (Requirements management)
5
Ví dụ: Quy trình xác định u cầu phần mềm hướng đối tượng
Application Domain
Objects
SubSystems
class class class
Implementat ion Domain
Objects
Source
Code CasesTest
?
Expressed in
Terms Of Structured By
Implemented By
Realized By Verified By
System
Design DesignObject Implemen-tation Testing
class ?
Requirements Elicitation
Use Case Model
Requirements Analysis
Or textual requirements
(4)1 Phát yêu cầu phần mềm • Đánh giá tính khả thi kỹ thuật nghiệp vụ
của phần mềm định phát triển
• Tìm kiếm nhân (chuyên gia, người sử dụng) có hiểu biết sâu sắc nhất, chi tiết hệ thống giúp xác định yêu cầu phần mềm
• Xác định mơi trường kỹ thuật triển khai phần mềm
• Xác định ràng buộc lĩnh vực ứng dụng phần mềm (giới hạn chức năng/hiệu phần mềm)
7
1 Phát yêu cầu phần mềm • Xác định phương pháp sử dụng để phát
các yêu cầu phần mềm: vấn, làm việc nhóm, buổi họp, gặp gỡ đối tác, v.v
• Thu hút tham gia nhiều chuyên gia, khách hàng để có quan điểm xem xét phần mềm khác từ phía khách hàng
• Xác định u cầu cịn nhập nhằng để làm mẫu thử
• Thiết kế kịch sử dụng phần mềm để giúp khách hàng định rõ yêu cầu
(5)Đầu bước phát yêu cầu phần mềm
• Bảng kê (statement) địi hỏi chức khả thi phần mềm
• Bảng kê phạm vi ứng dụng phần mềm
• Mơ tả mơi trường kỹ thuật phần mềm
• Bảng kê tập hợp kịch sử dụng phần mềm
• Các nguyên mẫu xây dựng, phát triển hay sử dụng phần mềm (nếu có)
• Danh sách nhân tham gia vào trình phát yêu cầu phần mềm - kể nhân từ phía cơng ty- khách hàng
9
2 Phân tích yêu cầu PM và thương lượng với khách hàng
Softw
a
re
Eng
in
e
e
ring
G
roup Cus
tom
e
r
G
roup
(6)2 Phân tích yêu cầu PM và thương lượng với khách hàng
• Phân loại yêu cầu phần mềm xếp chúng theo nhóm liên quan
• Khảo sát tỉ mỉ yêu cầu phần mềm mối quan hệ với yêu cầu phần mềm khác
• Thẩm định yêu cầu phần mềm theo tính chất: phù hợp, đầy đủ, rõ ràng, khơng trùng lặp
• Phân cấp yêu cầu phần mềm theo dựa nhu cầu đòi hỏi khách hàng / người sử dụng
• Thẩm định yêu cầu phầm mềm để xác định chúng có khả thực môi trường kỹ thuật hay không, có khả kiểm định yêu cầu phần mềm hay khơng
11
2 Phân tích u cầu PM và thương lượng với khách hàng
• Thẩm định rủi ro xảy với u cầu phần mềm
• Đánh giá thơ (tương đối) giá thành thời gian thực yêu cầu phần mềm giá thành sản phẩm phần mềm thời gian thực phần mềm
• Giải tất bất đồng yêu cầu phần mềm với khách hàng / người sử dụng sở thảo luận thương lượng yêu cầu đề
(7)3 Đặc tả yêu cầu phần mềm
• Đặc tả yêu cầu phần mềm: xây dựng tài liệu đặc tả, sử dụng tới cơng cụ như: mơ hình hóa, mơ hình tốn học hình thức (a formal mathematical model), tập hợp kịch sử dụng, nguyên mẫu tổ hợp cơng cụ nói
• Phương pháp đặc tả:
– Đặc tả phi hình thức (Informal specifications): viết ngôn ngữ
tự nhiên
– Đặc tả hình thức (Formal specifications):viết tập ký
pháp có quy định cú pháp (syntax) ngữ nghĩa (sematic) chặt chẽ, thí dụ ký pháp đồ họa dùng lưu đồ
• Tiêu chí đánh giá chất lượng hồ sơ đặc tả:
– Tính rõ ràng, xác
– Tính phù hợp
– Tính đầy đủ, hồn thiện
13
Ví dụ: Các yêu cầu hồ sơ đặc tả • Đặc tả hành vi bên ngồi HT
• Đặc tả ràng buộc cài đặt
• Dễ thay đổi
• Dùng cơng cụ tham khảo cho bảo trì
• Sự ghi chép cẩn thận vòng đời HT, nghĩa dự đốn thay đổi
• Các đáp ứng với cố không mong đợi
(8)3.1 Các thành phần hồ sơ đặc tả • Đặc tả vận hành hay đặc tả chức (Operational
specifications) mô tả hoạt động hệ thống phần mềm xây dựng:
– Các dịch vụ mà hệ thống phải cung cấp,
– Hệ thống phản ứng với đầu vào cụ thể sao, – Hành vi hệ thống tình đặc biệt
• Đặc tả mơ tả hay đặc tả phi chức (Descriptive specifications): đặc tả đặc tính, đặc trưng phần mềm:
– Các ràng buộc dịch vụ hay chức hệ thống cung cấp thời gian, ràng buộc q trình phát triển, chuẩn,…
• Ngồi cịn có u cầu lĩnh vực, bắt nguồn từ lĩnh vực ứng dụng hệ thống đặc trưng lĩnh vực
15
Đặc tả chức năng
• Miêu tả chức hệ thống, phụ thuộc vào kiểu phần mềm mong đợi người dùng
– Tương tác phần mềm môi trường, độc lập với việc cài đặt
– Ví dụ: The watch system must display the time based on its location
• Các công cụ đặc tả tiêu biểu:
– Biểu đồ luồng liệu (Data Flow Diagrams)
– Máy trạng thái hữu hạn (Finite State Machines)
– Mạng Petri (Petri nets),…
– Tuy nhiên không bắt buộc dùng ngơn ngữ tự nhiên
(9)Đặc tả phi chức ràng buộc
• u cầu phi chức năng: Định nghĩa khía cạnh sử dụng phần mềm, không liên quan trực tiếp tới hành vi chức năng:
– Các tính chất hệ thống độ tin cậy, thời gian trả lời, dung lượng nhớ, …
• The response time must be less than second
• Ràng buộc: khách hàng hay môi trường thực thi phần mềm đặt
– Các yêu cầu tổ chức qui định qui định chuẩn trình tiến hành, chuẩn tài liệu, …
• The implementation language must be COBOL – Các yêu cầu từ bên ngồi
• Must interface to the dispatcher system written in 1956
• Thường sử dụng cơng cụ
– Biểu đồ thực thể liên kết (Entity-Relationship Diagrams)
– Đặc tả Logic (Logic Specifications)
– Đặc tả đại số (Algebraic Specifications)
Khó phát biểu xác, Rất khó kiểm tra
17
3.2 Tài liệu yêu cầu
• Tài liệu yêu cầu phát biểu thức yêu cầu nhà phát triển HT
• Nó bao gồm phần: định nghĩa đặc tả u cầu
• Nó khơng phải tài liệu thiết kế Tốt tập mà HT phải làm HT phải làm (PT TK)
(10)Nội dung cần có tài liệu yêu cầu
Use the requirements to develop validation tests for the system
Use the requirements document to plan a bid for the system and to plan the system development process Use the requirements to understand what system is to be developed
System test engineers
Managers
System engineers
Specify the requirements and read them to check that they meet their needs They specify changes to the requirements
System customers
Use the requirements to help understand the system and the relationships between its parts
System maintenance
engineers 19
III Phương pháp công cụ đặc tả yêu cầu phần mềm
• Biểu đồ phân cấp chức - WBS (work break down structure)
• Biểu đồ luồng liệu – DFD (data flow diagram)
• Máy trạng thái – FSM (Finite state machine)
• Sơ đồ thực thể liên kết – ERD (entity relation diagram)