Tổng quan về phân tích và quản lý yêu cầu phần mềm

Tổng quan về phân tích và quản lý yêu cầu phần mềm

PHÂN TÍCH VÀ QUẢN LÝ CÁC YÊU CẦU

PHẦN MỀM (Requirements Analysis and Management)

Chuyên đề:

Giảng viên: Phạm Thị Thương

Bộ môn: CNPM

Số điện thoại: 0912838646 Email: ptthuong@ictu.edu.vn

Tổng quan về phân tích và quản lý yêu cầu phần

mềm

Chương 1

Mục tiêu

 Làm quen với các khái niệm cơ bản

 Tổng quan về tiến trình quản lý yêu cầu theo cách tiếp cận hướng đối tượng

Nội dung

Định nghĩa về yêu cầu và Stakeholder

Các kiểu yêu cầu & mối quan hệ

Dấu vết giữa các yêu cầu

Các đặc trưng của một yêu cầu tốt

Tổng quan về tiến trình phân tích và quản lý yêu cầu Thảo luận

1 Định nghĩa về yêu cầu & Stakeholder

a Định nghĩa yêu cầu

◦ điều kiện ràng buộc hệ thống hoặc

◦ năng lực hệ thống phải có.

b Định nghĩa Stakeholder

 Người/nhóm người

◦ Bị tác động bởi kết quả của dự án phát triển hệ thống

◦ => Có thể xem Stakeholder là bất kỳ người nào đưa ra yêu cầu đối với hệ thống

1 Định nghĩa về yêu cầu & Stakeholder

◦ Những bộ phận cung cấp các luật và các quy tắc

1 Định nghĩa về yêu cầu & Stakeholder

⇒Phân biệt giữa hai loại Stakeholder này là quan trọng.

⇒Các yêu cầu giữa họ có thể xung đột.

1 Định nghĩa về yêu cầu & Stakeholder

 Ví dụ: Xét p/m Online Travel Agency:

1 Định nghĩa về yêu cầu & Stakeholder

Ví dụ: Xét p/m Online Travel Agency:

◦ Nhà cung cấp tri thức cho hệ thống:

=> Các chuyên gia miền, tác giả của các tài liệu được sử dụng để suy luận các yêu cầu, các chủ sở hữu Website

cung cấp các link cho Website này).

Xác định Stakeholder

◦ Nhà tiếp thị: => Không có

◦ Người bảo trì và hỗ trợ hệ thống:

⇒Công ty cung cấp Website hosting,

• Người quản lý;

=> Lãnh đạo công ty du lịch, Giám đốc phòng Công nghệ thông tin của công ty thiết kế và phát triển Web.

◦ Những bộ phận cung cấp các luật và các quy tắc

=>Engine tìm kiếm: Các luật đối với nội dung website, các luật chính phủ, các luật về thuế quốc gia.

1 Định nghĩa về yêu cầu & Stakeholder

2 Kim tự tháp các yêu cầu

◦ Stakeholder need (nhu cầu Stakeholder):

 Là yêu cầu được đề xuất bởi Stakeholder

◦ Feature (đặc trưng):

 Là dịch vụ được cung cấp bởi hệ thống, thường được hình thành bởi hoạt động phân tích nghiệp vụ;

 Mục tiêu của đặc trưng là đáp ứng nhu cầu Stakeholder

◦ Use case (ca sử dụng):

 Mô tả về hành vi của hệ thống bằng một chuỗi các hành động

2 Kim tự tháp các yêu cầu

 Supplementary requirement (yêu cầu bổ sung):

◦ Yêu cầu khác (thường là yêu cầu phi chức năng, hoặc các yêu cầu chức năng không được thể hiện qua UC)

 Test case (ca kiểm thử):

◦ Đặc tả về các đầu vào kiểm thử, các điều kiện thực thi, và các kết quả mong đợi

◦ => nhằm kiểm tra xem liệu các use case và các yêu cầu bổ sung đã được cài đặt một cách đúng đắn chưa

 Scenario (kịch bản):

◦ Chuỗi hành động cụ thể; một đường cụ thể qua một use case

2 Kim tự tháp các yêu cầu

 Càng ở mức dưới, mức độ trừu tượng của y/c càng thấp Ví dụ:

◦ Need: “dữ liệu nên được lưu trữ lâu dài”

◦ Feature: “hệ thống nên sử dụng cơ sở dữ liệu quan hệ”

◦ Specification: “Hệ thống nên sử dụng CSDL Oracle 9i”.

 Từ một yêu cầu mức trên, có thể ánh xạ thành nhiều yêu cầu mức dưới

◦ Tài liệu vision: 12 trang, tài liệu chi tiết: 200 trang

2 Kim tự tháp các yêu cầu

3 Dấu vết các yêu cầu

 Dấu vết – Traceability:

◦ Là kỹ thuật cung cấp mối quan hệ giữa hai mức độ yêu cầu

◦ Giúp xác định nguồn gốc của một yêu cầu bất kỳ

 Ánh xạ giữa các kiểu yêu cầu trong kim tự tháp:

 Use case -> scenario

 Scenario-> test case

 Supplement-> test case

4 Các đặc trưng của một yêu cầu tốt

 [HUL05][LEF03][LUD05][YOU01]- Các yêu cầu tốt nên có những đặc tính sau:

◦ Không mập mờ (Unambigious)

◦ Có thể kiểm thử (Testable, verifiable)

◦ Rõ ràng (clear: ngắn gọn - concise, súc tích-terse, đơn giản-simple, chính xác- precise)

 Ba tiêu chuẩn sau áp dụng cho một tập các yêu cầu:

 Xét Website Công ty du lịch trực tuyến:

REQ1 The system shall be implemented using ASP

⇒ ASP có nghĩa là Active Server Pages hay Application Service Provider?

⇒Correct: Viết tên đầy đủ và cung cấp từ viết tắt trong ngoặc:

REQ1 The system shall be implemented using Active Server Pages (ASP).

4 Các đặc trưng của một yêu cầu tốt

a Unambigious

Ví dụ 2:

REQ2 The system shall not accept passwords longer than 15 characters.

• not let the user enter more than 15 characters.

• truncate the entered string to 15 characters.

• display an error message if the user enters more than 15 characters.

⇒ Correct:

REQ2 The system shall not accept passwords longer than 15 characters If the user enters

more than 15 characters while choosing the password, an error message shall ask the user to correct it

4 Các đặc trưng của một yêu cầu tốt

a Unambigious

Ví dụ 3:

• REQ3 On the “Stored Flight” screen, the user can only view one record.

⇒only view:

not delete or update,

view only one record, not two or three?

=> Correct:

 REQ1 On the “Stored Flight” screen, the system shall display only one flight.

4 Các đặc trưng của một yêu cầu tốt

b Testable, verifiable

 Là yêu cầu có thể thẩm định liệu nó đã được cài đặt một cách đúng đắn chưa

◦ Để có thể kiểm thử, các yêu cầu phải rõ ràng, chính xác và không mập mờ

4 Các đặc trưng của một yêu cầu tốt

=> Correct: Liệt kê rõ ràng các tiêu chí.

4 Các đặc trưng của một yêu cầu tốt

 Chủ thể của câu nhận hành động của động từ hay tạo hành động.

4 Các đặc trưng của một yêu cầu tốt

b Testable, verifiable

Ví dụ: Xét các yêu cầu sau:

 REQ1 The airport code shall be entered by the user.

 REQ2 The airport code shall be entered.

 => REQ1 là ví dụ cổ điển của thể bị động, ở thể chủ động nó có thể được hiểu “người dùng sẽ nhập vào

mã sân bay”

 => Nhưng ở REQ2 là cách sử dụng khác của thể bị động và tác nhân thực hiện hành động bị lờ đi Điều

này sẽ nảy sinh câu hỏi “ai sẽ nhập vào mã này – Hệ thống hay người dùng?”

4 Các đặc trưng của một yêu cầu tốt

b Testable, verifiable

◦ Các vấn đề khác có thể gây ra bởi những từ hoặc cụm từ mập mờ:

 Các đại từ không xác định:

một vài, nhiều, hầu hết, bất kỳ, bất kỳ người nào, bất kỳ thứ gì, một số, một số người,

 Ví dụ: Xét yêu cầu sau:

REQ1 The system shall resist concurrent usage by many users

=> nẩy sinh câu hỏi hệ thống sẽ chịu đựng được “nhiều” cụ thể là con số bao nhiêu – 10, 100,

hay 1000?

=> Correct: sửa thành con số cụ thể

4 Các đặc trưng của một yêu cầu tốt

c Clear

◦ Không chứa các từ hoặc những thông tin không cần thiết

◦ Chúng nên được phát biểu rõ ràng và đơn giản

 Ví dụ:

REQ1 Sometimes the user will enter Airport Code, which the system will understand, but sometimes the

closest city may replace it, so the user does not need to know what the airport code is, and it will still be understood by the system.

=> Correct bởi yc đơn giản hơn;

REQ1 The system shall identify the airport based on either an Airport Code or a City Name.

4 Các đặc trưng của một yêu cầu tốt

d Correct

◦ Nếu một yêu cầu chứa các sự kiện, các sự kiện này phải đúng

◦ Ví dụ, xét yêu cầu sau:

REQ1 Car rental prices shall show all applicable taxes (including 6% state tax)

=> Thuế phụ thuộc vào từng quốc gia, do đó con số 6% đã cung cấp là không đúng

4 Các đặc trưng của một yêu cầu tốt

e Understandable

◦ Các yêu cầu phải đúng ngữ pháp và được viết một cách nhất quán

 Các quy ước chuẩn nên được sử dụng:

 Ví dụ từ “shall” được sử dụng để thay thế các từ “will”, “must” hoặc “may”

4 Các đặc trưng của một yêu cầu tốt

f Feasible (Realistic, Possible)

◦ Yêu cầu phải có thể thực hiện giới hạn trong các ràng buộc hiện có:

 Thời gian, tiền bạc, và các nguồn tài nguyên có thể

REQ1 The system shall have a natural language interface that will understand com-mands

given in English language.

=> Yêu cầu này là không khả thi trong một thời gian phát triển ngắn

4 Các đặc trưng của một yêu cầu tốt

g Independent

◦ Tính độc lập của yêu cầu thỏa mãn khi, để hiểu yêu cầu đó, ta sẽ không cần phải biết bất kỳ yêu cầu nào khác

◦ Ví dụ, xét các yêu cầu sau:

 REQ1 The list of available flights shall include flight numbers, departure time, and arrival

time for every leg of a flight.

 REQ2 It should be sorted by price.

=> Từ “it” trong câu thứ 2 tham chiến đến yêu cầu trước đó Tuy nhiên, nếu thứ tự của yêu cầu thay đổi, yêu cầu này sẽ không thể hiểu.

4 Các đặc trưng của một yêu cầu tốt

g Necessary

◦ Một yêu cầu là không cần thiết khi:

 Không Stakeholder nào cần yêu cầu

 Những yêu cầu được thêm vào bởi những nhà phát triển và những nhà thiết kế vì họ giả định rằng người dùng hoặc khách hàng muốn có nó

 Ví dụ: Người phát triển nghĩ rằng người dùng thích đặc trưng hiển thị bản đồ các sân bay và anh ấy biết cách thức cài đặt, đó không là lý do hợp lý để thêm yêu cầu này.

 Xóa yêu cầu sẽ không ảnh hưởng đến hệ thống.

 Những yêu cầu có thể được xóa vì nó không cung cấp bất kỳ thông tin mới nào.

 Ví dụ: REQ1 All requirements specified in the Vision document shall be implemented and tested.

4 Các đặc trưng của một yêu cầu tốt

h Implementation-free (Abstract)

◦ không nên chứa thông tin cài đặt và thông tin thiết kế không cần thiết

 Ví dụ, xét yêu cầu sau:

◦ REQ1 Content information shall be stored in a text file.

=> Cách thức thông tin được lưu trữ là trong suốt đối với người dùng và nên là quyết định của

kiến trúc sư hoặc người thiết kế

4 Các đặc trưng của một yêu cầu tốt

1 Consistent

◦ Không nên có bất kỳ sự xung đột nào giữa các yêu cầu

 Các xung đột có thể trực tiếp hoặc gián tiếp

 Các xung đột trực tiếp xảy ra khi, trong tình huống tượng tự, hành vi khác nhau xảy ra,

◦ Ví dụ 1: Xung đột trực tiếp

 REQ1 Dates shall be displayed in the mm/dd/yyyy format.

 REQ2 Dates shall be displayed in the dd/mm/yyyy format.

=> Đôi khi có thể giải quyết sự xung đột bằng cách phân tích các điều kiện mà yêu cầu diễn

ra

Các tiêu chuẩn áp dụng cho tập yêu cầu

1 Consistent

◦ => nếu REQ 1 được gửi đến bởi một người dùng ở Mỹ và REQ 2 được gửi đến bởi một người dùng ở Pháp, các yêu cầu này có thể được viết lại như sau:

 REQ1 For users in the U.S., dates shall be displayed in the mm/dd/yyyy format.

 REQ2 For users in France, dates shall be displayed in the dd/mm/yyyy format.

=> Vấn đề này thậm chí có thể dẫn đến yêu cầu sau:

 REQ3 Dates shall be displayed based on the format defined in the user’s web browser.

Các tiêu chuẩn áp dụng cho tập yêu cầu

1 Consistent

◦ Ví dụ 2: xung đột trực tiếp:

 REQ1 Payment by PayPal shall be available.

 REQ2 Only credit card payments shall be accepted.

=> correct: Một trong các yêu cầu sẽ được thay đổi hoặc loại bỏ.

◦ Ví dụ 3: Xung đột gián tiếp (không thể thỏa mãn đồng thời)

 REQ1 System should have a natural language interface.

 REQ2 System shall be developed in three months.

=> correct: bỏ hoặc sửa một trong chúng

Các tiêu chuẩn áp dụng cho tập yêu cầu

1 Consistent

Ví dụ 4: xung đột gián tiếp (sử dụng thuật ngữ không khớp nhau)

 REQ1 For outbound and inbound flights , the user shall be able to compare flight prices from other, nearby airports.

 REQ2 The outbound and return flights shall be sorted by the smallest number of stops.

=> Để mô tả cùng một khái niệm, REQ1 sử dụng thuật ngữ “ inbound flights ” và

REQ2 sử dụng thuật ngữ “ return flights ”

=>Correct: cần sử dụng các thuật ngữ thống nhất với nhau.

Các tiêu chuẩn áp dụng cho tập yêu cầu

2 Nonredundant

◦ Mỗi yêu cầu nên được phát biểu một lần duy nhất và không được phủ lên yêu cầu khác.

◦ Ví dụ, xét các yêu cầu sau:

 REQ1 A calendar shall be available to help with entering the flight date.

 REQ2 The system shall display a pop-up calendar when entering any date

⇒REQ1 (chỉ liên quan đến ngày bay) là tập con của REQ2 (liên quan đến ngày được nhập bởi người dùng) Do đó REQ 2 phủ lên REQ1

=> Correct: Nên bỏ REQ1.

Các tiêu chuẩn áp dụng cho tập yêu cầu

3 Complete

◦ Yêu cầu nên xác định mọi điều kiện có thể xảy ra

◦ Ví dụ, xét 2 yêu cầu sau:

 REQ1 A destination country does not need to be displayed for flights within the U.S.

 REQ2 For overseas flights, the system shall display a destination country.

=> Một câu hỏi có thể đặt ra:

“Vậy với các chuyến bay đến Canada và Mexico thì sao? Chúng không trong phạm vi nước

Mỹ mà cũng không vượt đại dương ?”

=> Correct: Liệt kê mọi điều kiện, có thể thay overseas bởi without the U.S

Các tiêu chuẩn áp dụng cho tập yêu cầu

 Mọi yêu cầu nên được đặc tả

◦ Đặc tả là đặc tính chắc chắn nhất sẽ được kiểm tra

vì một tuần trước ngày sản xuất một trong các Stakeholder không nói “Tôi đã quên không đề cập rằng tôi cần một đặc trưng thêm vào cho ứng dụng.”

◦ => sử dụng cách tiếp cận lặp lại

Lưu ý:

 Thông thường một yêu cầu tốt có thể có nhiều các tiêu chuẩn đã thảo luận.

◦ Khả năng sửa đổi : Nếu yêu cầu là nguyên tử và không dư thừa, nó có khả năng sửa đổi.

◦ Khả năng lưu vết : Nếu nó là nguyên tử và có định danh duy nhất, nó có thể lưu vết.

Tóm lại

5 Tổng quan về tiến trình phân tích

và quản lý yêu cầu

1. Lập kế hoạch quản lý yêu cầu.

2. Suy luận các yêu cầu.

3. Phát triển tài liệu trực quan.

4. Tạo các use case.

5. Đặc tả bổ sung.

6. Tạo các test case từ các use case.

7. Tạo các test case từ đặc tả bổ sung.

Lưu ý: Quản lý yêu cầu

 Là tiến trình lặp nhiều lần, mỗi lần lặp:

◦ Đi qua toàn bộ kim tự tháp yc

◦ Bổ sung, hoàn thiện các thành phần ở các giai đoạn trước đó

◦ Cần cập nhật mọi yêu cầu bị tác động sau mỗi lần chỉnh sửa, bổ sung => duy trì tính toàn vẹn

 Lần lặp kế sau nên đặt trọng tâm vào các tầng sâu hơn

Bài tập thảo luận – làm việc nhóm

 Cho tập các yêu cầu ở dạng feature của phần mềm quản lý khách sạn

 => Hãy kiểm tra xem chúng đã thõa mãn các đặc trưng của một yêu cầu tốt chưa? Nếu chưa hãy sửa chữa chúng.

1 Các yêu cầu về chức năng

a.Các yêu cầu về lưu trữ

b Yêu cầu về nghiệp vụ

c Yêu cầu về báo biểu

1 Các yêu cầu về chức năng

◦ Giao diện hệ thống phải dễ sử dụng, trực quan, thân thiện với mọi người dùng.

dụng một cách dễ dàng nhờ vào sự trợ giúp của hệ thống.

2 Các yêu cầu phi chức năng