CHƯƠNG I

YÊU CẦU PHẦN MỀM

Thu nhận yêu cầu

TNYC

1
Nội dung
Thu nhận yêu cầu

1. Tầm quan trọng của xác định yêu cầu

2. Yêu cầu phần mềm (software requirement) là gì?
3. Phân loại yêu cầu
4. Kỹ thuật yêu cầu (Requirements Engineering - RE) là gì?
5. Lợi ích từ quy trình xác định yêu cầu chất lượng cao
6. Vai trò của người phân tích yêu cầu

2
1. Tầm quan trọng trong XĐ yêu cầu?
Thu nhận yêu cầu

™ Công nghệ và xã hội không ngừng thay đổi một

cách nhanh chóng, và ảnh hưởng to lớn của hệ
thống thông tin trong một môi trường vô cùng phức
tạp
ƒ Kỹ thuật yêu cầu (requirements engineering - RE)
đóng một vai trò vô cùng quan trọng
ƒ Cần có sự tham gia của các chuyên gia trong việc thu
nhận và quản lý yêu cầu

Hệ thống nghiệp vụ - Hệ thống thông tin – Phần mềm

3
Một số đặc trưng
Thu nhận yêu cầu

™ Sản phẩm phát triển với tốc độ chóng mặt. Ngày

nay khách hàng thường đòi hỏi phiên bản mới của
sản phẩm trong khoảng thời gian dưới 1 năm
ƒ Ví dụ: theo Siemens thì 20 năm trước, 55% hàng
bán là từ sản phẩm tuổi <5. Ngày nay, 75% hàng
bán được là từ sản phẩmcó tuổi <5.

4
5
Một số đặc trưng
Thu nhận yêu cầu

™ Thay đổi không ngừng của công nghệ

ƒ Các kỹ sư không thể sống cả đời với nghề nghiệp
của mình trong 1 công ty nào đó

6
Một số đặc trưng
Thu nhận yêu cầu

™ Gia công phần mềm đóng một vai trò vô cùng

quan trọng có tính toàn cầu
ƒ Vai trò quan trọng của đặc tả. VD: Đặc tả cho máy
giặt cho đội ngũ xây dựng nó chưa từng nhìn thấy
máy giặt lần nào

7
Một số đặc trưng
Thu nhận yêu cầu

™ Việc phát triển phần mềm thường liên kết chặt

chẽ với nghiệp vụ mà nghiệp vụ thì biến đổi
không ngừng nên các phiên bản mới của sản
phẩm thường được tạo bằng cách thay đổi
phần mềm nhằm hạ thấp chi phí biến đổi

8
Tại sao yêu cầu là quan trọng?
Thu nhận yêu cầu

™ Nguyên nhân thất bại của dự án (RE-62%)

ƒ 1. Những yêu cầu không đầy đủ - Incomplete
requirements (13.1%)
ƒ 2. Lack of user involvement (12.4%)
ƒ 3. Lack of resources (10.6%)
ƒ 4. Unrealistic expectations (9.9%)
ƒ 5. Lack of executive support (9.3%)
ƒ 6. Changing requirements and specifications
(8.7%)
ƒ 7. Lack of planning (8.1%)
ƒ 8. System no longer needed (7.5%)
Ai thành công ???
Thu nhận yêu cầu

™ For the first half of the 20th century, the Indian

and Harley Davidson motorcycle manufactures
were fierce competitors.
™ In WWII the U. S. Army asked for a 500 cc
motorcycle.
™ Indian made one for them.
™ Harley Davidson built a 750 cc motorcycle.
™ Have any of you heard of a Indian motorcycle?

10
2. Yêu cầu (requirement)
Thu nhận yêu cầu

™ Một yêu cầu là một đặc trưng của hệ thống, hay

là sự mô tả những việc, mà hệ thống có khả năng
thực hiện để hoàn thành mục tiêu của hệ thống

11
Theo IEEE 1990
Thu nhận yêu cầu

1. A condition or capability needed by a user to

solve a problem or achieve an objective.
2. A condition or capability that must be met or
possessed by a system or system component to
satisfy a contract, standard, specification, or other
formally imposed document.
3. A documented representation of a condition or
capability as in 1 or 2.

12
Yêu cầu?
Thu nhận yêu cầu

“Tôi không có thời gian

để viết yêu cầu!
Bạn không thấy tôi đang
bận gỡ lỗi?”

13
Yêu cầu
Thu nhận yêu cầu

™ Yêu cầu có thể được ràng buộc bởi hợp đồng hay
văn bản
™ Có những yêu cầu ngầm định (implicit)
™ Một yêu cầu có thể được nhận biết (known,
spoken)/ không nhận biết (forgotten, unspoken…)
Đặc trưng của yêu cầu
Thu nhận yêu cầu

™ Khả thi - Feasible

™ Có giá trị - Valid
™ Không nhập nhằng - Unambiguous
™ Dễ kiểm chứng - Verifiable
™ Dễ biến đổi - Modifiable
™ Toàn vẹn - Consistent
™ Đầy đủ - Complete
™ Lần vết được - Traceable

15
16
3. Phân loại yêu cầu
Thu nhận yêu cầu

…….

17
Yêu cầu hệ thống
Thu nhận yêu cầu

™ Yêu cầu chức năng: chức năng dịch vụ hệ thống

cung cấp
™ Yêu cầu phi chức năng: những ràng buộc về tiêu
chuẩn, thời gian, qui trình phát triển…, chủ yếu là
những yêu cầu về chất lượng
™ Ràng buộc: phản ảnh những đặc trưng của miền
ứng dụng. Chúng có thể là những yêu cầu chức
năng hay yêu cầu phi chức năng.

18
Yêu cầu chức năng
Thu nhận yêu cầu

™ Yêu cầu chức năng chỉ ra những gì hệ thống làm,

chúng thường quan hệ các use-case hay những
qui tắc nghiệp vụ (business rule)
™ Một số yêu cầu chức năng
ƒ Chức năng tính toán
ƒ Chức năng lưu trữ
ƒ Chức năng tìm kiếm
ƒ Chức năng kết xuất
ƒ Chức năng backup, restore
ƒ Chức năng đa người dùng
ƒ Chức năng đa phương tiện…
Ví dụ
Thu nhận yêu cầu

™ Trong hệ thống quản lý thư viện

ƒ Người dùng có thể tìm kiếm, download, in những bài
báo
ƒ Người dùng được cấp một vùng lưu trữ riêng để có
thể copy để lưu trữ tài liệu lâu dài…

20
Yêu cầu phi chức năng
Thu nhận yêu cầu

™ Một số yêu cầu phi chức năng

ƒ Độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ…
ƒ Các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ
lập trình…
ƒ Yêu cầu của người sử dụng: dễ sử dụng, thân thiện
ƒ Ràng buộc về ngân sách
ƒ Phù hợp với các chính sách của tổ chức sử dụng hệ
thống
ƒ Yêu cầu tương thích giữa phần cứng và phần mềm
ƒ Các yêu cầu từ các tác nhân ngoài khác…
Yêu cầu phi chức năng
Thu nhận yêu cầu

22 CNPM/NN
Ví dụ
Thu nhận yêu cầu

Trong hệ thống quản lý thư viện

™ Yêu cầu sản phẩm: giao diện người dùng không
chứa frame và applet java
™ Yêu cầu tổ chức: qui trình phát triển hệ thống và
tài liệu phân phối phải phù hợp theo tiêu chuẩn
“STAN-07” (sử dụng ngôn ngữ, phương pháp thiết
kế…)
™ Yêu cầu ngoài: hệ thống không được lộ thông tin
của khách hàng (tên, số tham chiếu…)

23
Các mức yêu cầu
Thu nhận yêu cầu

™ Yêu cầu nghiệp vụ (Business requirements)

™ Yêu cầu người dùng (User requirements)
™ Yêu cầu chức năng (Functional requirements)

24
Yêu cầu nghiệp vụ
Thu nhận yêu cầu

™ Biễu diễn các mục tiêu của tổ chức hay khách

hàng yêu cầu hệ thống phải có
™ Yêu cầu nghiệp vụ thường do người tài trợ cho dự
án, khách mua phần mềm, người quản lý các
người dùng, bộ phận tiếp thị (maketing)…
™ Thường được ghi nhận trong phần đặc tả (vision)
và phạm vi (scope) của tài liệu, đôi khi còn được
gọi là tuyên bố dự án (project charter) hay tài liệu
yêu cầu thị trường (market requirements
document)

25
Yêu cầu người dùng
Thu nhận yêu cầu

™ Mô tả mục tiêu (goal) hay tác vụ (task) của

người dùng đối với hệ thống.
™ Các cách để biểu diễn yêu cầu người dùng:
ƒ use cases, scenario
ƒ Bảng event-response.
™ Yêu cầu người dùng mô tả cái (what) mà người
dùng có thể làm đối với hệ thống.
ƒ Ví dụ: use case "Make a Reservation" dùng trong
các website của hàng không, thuê xe, hay khách
sạn.

26
Yêu cầu chức năng
Thu nhận yêu cầu

™ Xác định chức năng của phần mềm mà các nhà

phát triển phải xây dựng để giúp người dùng hoàn
thành nhiệm vụ của họ, thỏa mãn được yêu cầu
nghiệp vụ.
™ Đôi khi còn được gọi là yêu cầu về hành vi
(behavioral requirements)
™ Ví dụ: Hệ thống sẽ gởi một xác nhận giữ chỗ cho
khách hàng…

27
Mối liên hệ giữa các mức yêu cầu
Thu nhận yêu cầu
Các mức yêu cầu
Thu nhận yêu cầu

29
Các loại yêu cầu
Thu nhận yêu cầu

™ Môi trường vật lý

™ Giao tiếp
™ Người dùng và nhân tố con người
™ Chức năng
™ Lập tài liệu
™ Dữ liệu
™ Tài nguyên
™ An ninh
™ Bảo đảm chất lượng
4. Kỹ thuật yêu cầu (RE)
Thu nhận yêu cầu

™ Nhấn mạnh tới tính cộng tác và lặp lại

ƒ Tạo tài liệu cho những kết quả quan sát
ƒ Kiểm tra
™ Nó còn nhấn mạnh tới vai trò của kinh nghiệm và
tính xã hội

31
Quy trình phát triển yêu cầu
Thu nhận yêu cầu

32
Sơ đồ kỹ thuật yêu cầu
Thu nhận yêu cầu

33
Ranh giới yêu cầu
Thu nhận yêu cầu

34
Kỹ thuật yêu cầu
Thu nhận yêu cầu

35
5. Lợi ích khi thu thập yêu cầu hiệu quả
Thu nhận yêu cầu

Lợi ích của việc tạo yêu cầu có chất lượng thường
không dễ thấy nên nhiều người thường nhầm lẫn
là tiêu tốn thời gian khi bàn luận về yêu cầu sẽ
dẫn đến làm chậm trễ việc hoàn thành sản phẩm

™ Giảm việc phải làm lại

™ Thu thập yêu cầu cho phép đội phát triển hiểu rõ
về người dùng và thị trường, một nhân tố quan
trọng cho sự thành công của bất kỳ dự án nào

36
Lợi ích
Thu nhận yêu cầu

™ Khi người dùng cùng tham gia trong giai đoạn thu
thập yêu cầu sẽ xây dựng được niềm tin và lòng
trung thành của khách hàng
™ Đội phát triển có thể tránh viết những đoạn mã
thừa khi nắm vững nhiệm vụ của người dùng
™ Sự quan tâm của khách hàng giảm được khoảng
cách giữa cái người dùng cần và cái người phát
triển tạo ra.

37
Những lợi ích không định lượng
Thu nhận yêu cầu

1. Lỗi liên quan đến yêu cầu ít hơn

2. Giảm được việc phải làm lại trong bước phát triển
3. Ít hơn trong việc tạo tính năng không cần thiết
4. Giảm chi phí mở rộng
5. Quá trình phát triển hệ thống sẽ nhanh hơn
6. Giảm bớt các giao tiếp sai lầm với khách hàng
7. Hạn chế phạm vi hệ thống bị phình rộng
8. Hạn chế được những hỗn độn dự án
9. Các ước lượng về hệ thống chính xác hơn
10. Mức độ thỏa mãn khách hàng và thành viên của
đội sẽ cao hơn
38
6. Nhà phân tích yêu cầu
Thu nhận yêu cầu

™ Nhà phân tích yêu cầu (Requirements analyst)

™ Nhà phân tích hệ thống (Systems analyst)
™ Kỹ sư yêu cầu (Requirements engineer)
™ Nhà quản lý yêu cầu (Requirements manager)
™ Nhà phân tích (Analyst)

39
Vai trò của nhà phân tích
Thu nhận yêu cầu

™ Nhà phân tích là người chuyển các ý tưởng thành

những đặc tả yêu cầu.
™ Nhà phân tích là người có quan hệ truyền thông
với các stakeholder, giúp các stakeholder tìm thấy
sự khác nhau giữa cái họ muốn và cái họ thực sự
cần
™ Là người có nhiệm vụ cơ bản là thu thập, phân
tích, ghi chép và kiểm tra nhu cầu của các
stakeholder

40
Vai trò của nhà phân tích
Thu nhận yêu cầu

™ Họ như là một cầu nối giữa cộng đồng khách

hàng và đội phát triển phần mềm.
™ Nhà phân tích đóng vai trò trung tâm trong việc
thu thập và phổ biến thông tin, còn người quản lý
dự án (project manager) giữ vai trò lãnh đạo
trong việc truyền đạt thông tin dự án

41
Các mối quan hệ
Thu nhận yêu cầu

42
Nhiệm vụ tổng quát
Thu nhận yêu cầu

™ Nhà phân tích trước tiên phải hiểu mục tiêu của
người dùng, sau đó xác định các yêu cầu chức
năng; cho phép người quản lý dự án xây dựng các
ước lượng; người phát triển (developer) thiết kế,
xây dựng và kiểm định sản phẩm.

43
Nhiệm vụ
Thu nhận yêu cầu

™ Xác định yêu cầu nghiệp vụ.

™ Xác định các stakeholder và các lớp người dùng
™ Rút ra những yêu cầu (Elicit)
™ Viết đặc tả yêu cầu
™ Mô hình hóa yêu cầu
™ Điều hành việc đánh giá yêu cầu
™ Phân loại ưu tiên các yêu cầu
™ Quản lý yêu cầu

44
Kỹ năng của nhà phân tích
Thu nhận yêu cầu

™ Kỹ năng lắng nghe

™ Kỹ năng phỏng vấn
™ Kỹ năng phân tích
™ Kỹ năng điều khiển (họp)
™ Kỹ năng quan sát
™ Kỹ năng viết
™ Kỹ năng tổ chức
™ Kỹ năng mô hình hóa
™ Kỹ năng giao tiếp
™ Tính sáng tạo
Thu nhận yêu cầu

46
Nhập nhằng
Requirement:

Create a means to transport a single

individual from home to place of work.

Management IT User
Interpretation Interpretation Interpretation
Những rủi ro
Thu nhận yêu cầu

™ Không gồm người dùng không đầy đủ

™ Yêu cầu người dùng phình ra (Creeping UR)
Requirements
™ Yêu cầu nhập nhằng
™ Yêu cầu mạ vàng (Gold Plating): khi người phát
triển cộng thêm chức năng không có trong đặc tả
™ Yêu cầu tối tiểu
™ Bỏ qua lớp người dùng
™ Hoạch định không chính xác

48
 Dư thừa thông tin,
rối rắm cho người sử dụng.
Phù hợp yêu cầu người dùng
 Thu nhận yêu cầu

51 CNPM/NN
Thực hành
Thu nhận yêu cầu

™ Dưới vai trò của người phân tích hệ thống hãy

đưa một dự án CNTT và đưa ra các yêu cầu của
hệ thống, cách thức xác định các yêu cầu đó

52