Bài giảng Kỹ thuật phần mềm - Phần 3: Phương pháp xác định yêu cầu người dùng

• 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]

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

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

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

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

Đầ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

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 đề

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

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

Đặ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)

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)