Bài giảng Thu nhận yêu cầu: Chương 1 - Trần Thị Kim Chi

Bài giảng Thu nhận yêu cầu - Chương 1: Tổng quan về kỹ thuật yêu cầu trình bày các nội dung: Khái quát về phần mềm, tầm quan trọng của việc xác định cầu, kỹ thuật yêu cầu, yêu cầu theo quan điểm khách hàng, nhà phân tích yêu cầu. Mời các bạn cùng tham khảo.

2

Nội dung

 Tầm quan trọng của việc xác định cầu

 Kỹ thuật yêu cầu

 Yêu cầu theo quan điểm khách hàng

 Nhà phân tích yêu cầu

2

Generic Product: là sản phẩm đóng gói

và bán rộng rãi trên thị trường

Bespoke Product: là sản phẩm được

phát triển theo yêu cầu đặc thù của từng khách hàng

3

 Efficiency: Sử dụng hiệu quả tài nguyên của hệ thống cho công việc

 Usability: giao diện và phương thức phải phù hợp với người dùng đồng thời đáp ứng đúng yêu cầu của người dùng

4

Phần Mềm – Đủ hay Thiếu

 Phần mềm được viết ngay từ khi có những máy tính programable đầu tiên Được quan tâm và phát triền từ rất sớm

 Có rất nhiều phần mềm đã được viết Không thiếu phần

 Không kịp về thời gian

 Phần mềm không đáp ứng đủ cho người dùng

5

Nguyên nhân khách quan

 Số lượng phần mềm phải được hiểu là số đầu/loại phần mềm được sử dụng cho từng mục tiêu ứng dụng

 Nhu cầu sử dụng phần mềm là rất lớn

 Nhiều ngành nghề cần dùng phần mềm máy tính

 Mỗi ngành nghề cần nhiều loại phần mềm khác nhau

 Mội loại phần mềm cần nhiều cấp độ khác nhau theo trình

độ người dùng

6

Nguyên nhân khách quan

 Chất lượng phần mềm cũng chưa đáp ứng tốt hoàn toàn người sử dụng:

 Tính customize rất cao của sản phẩm phần mềm

 Trình độ sử dụng khác nhau và điều kiện hạ tầng ứng dụng khác nhau

 Nhu cầu phần mềm thường rất cấp bách

 Tầm nhìn và chiến lược chưa đầy đủ của người sử dụng

 Không có kế hoạch lâu dài

 Phải thay đổi theo từng đối tượng người dùng

7

Nguyên nhân chủ quan

 Tính chuyên nghiệp trong sản xuất phần mềm chưa cao

 Các dữ liệu quan sát được

200-300%)

 Quá trình phân tích yêu cầu (5 % công sức): để lại 55 % lỗi, có

Nguyên nhân chủ quan

 Nhiều vấn đề về phần mềm xuất hiện do thiếu sót trong lúc thu thập, thỏa thuận và chỉnh sửa yêu cầu

 Lỗi xảy ra trong giai đoạn thu thập yêu cầu chiếm từ 60% tổng lỗi trong một dự án phần mềm

40- Có sự khác biệt giữa cái mà người phát triển phần mềm (developer) nghĩ và xây dựng với cái mà khách hàng thật sự cần

9

 "Hello, Phil?” This is Maria in Human Resources

“We're having a problem with the employee system you programmed for us An employee just changed her name to Sparkle Starlight, and we can't get the system to accept the name change Can you help?"

 "She married some guy named Starlight?"

 "No, she didn't get married, just changed her name," Maria replied "That's the problem It looks like we can change a name only if someone's marital status changes."

Tại sao xác định yêu cầu là quan trọng

A story…

10

 "Well, yeah, I never thought someone might just change her name I don't remember you telling

me about this possibility when we talked about the system That's why you can get to the Change Name dialog box only from the Change Marital Status dialog box," Phil said

A story…

11

 "I assumed you knew that people could legally change their name anytime they like," responded Maria "We have to straighten this out by Friday or Sparkle won't be able to cash her paycheck Can you fix the bug by then?"

 "It's not a bug!" Phil retorted "I never knew you needed this capability I'm busy on the new performance evaluation system I think I have some other change requests for the employee system here, too." [sound of rustling paper]

A story…

12

 "Yeah, here's another one I can probably fix it by the end of the month, but not within a week Sorry about that Next time, tell me these things earlier and please write them down.“

 "What am I supposed to tell Sparkle?" demanded Maria

"She's really going to be ticked if she can't cash her check."

A story…

13

 "Hey, Maria, it's not my fault," Phil protested (phản kháng) "If you'd told me in the first place that you had to

be able to change someone's name at any time, this wouldn't have happened You can't blame me for not reading your mind."

 Angry and resigned, Maria snapped, "Yeah, well, this is the kind of thing that makes me hate computer systems Call me as soon as you get it fixed, will you?"

A story…

14

15

Tầm quan trọng trong XĐ 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 Vậy tầm quan trọng của thu nhận yêu cầu là gì?

15

Tầm quan trọng trong XĐ yêu cầu?

Lý do 1:

 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

16

Tầm quan trọng trong XĐ yêu cầu?

17

Tầm quan trọng trong XĐ yêu cầu?

18

Tầm quan trọng trong XĐ yêu cầu?

Lý do 2:

 Thay đổi không ngừng của công nghệ và chuyển giao

đã ảnh hưởng nhiều đến mức độ thành thạo của chuyên gia Vài năm trước, các kỹ sư có thể sống cả đời với

nghề nghiệp của mình trong một công ty nào đó, nhưng ngày nay việc thay đổi công việc rất thường xuyên

19

Tầm quan trọng trong XĐ yêu cầu?

chuyên môn nghiệp vụ

 Tương tự như phải tạo đặc tả cho máy giặt mà người thiết kế có thể chưa từng nhìn thấy máy giặt lần nào Để thành công, đặc tả cần phải chính xác

20

Tầm quan trọng trong XĐ yêu cầu?

Lý do 4:

 Việc phát triển phần mềm thường liên kết chặt chẽ với nghiệp vụ Ví dụ: phần mềm cellphone và phần mềm về hàng không thường được thiết kế xây dựng chặt chẽ phù hợp với nghiệp vụ

 Công nghiệp bắt đầu dùng phần mềm để tạo các phiên bản mới cho sản phẩm Các sáng kiến có thể thực hiện hiện dễ dàng bằng phần mềm hơn là phần cứng vì ít đầu tư kỹ thuật hơn và chi phí sửa đổi rẻ hơn

21

Tầm quan trọng trong XĐ yêu cầu?

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

 Những yêu cầu không đầy đủ - Incomplete

requirements (13.1%)

 Lack of user involvement – không cuốn hút người dùng(12.4%)

 Lack of resources – thiếu nguồn tài nguyên(10.6%)

 Unrealistic expectations – thiếu thực tế(9.9%)

 Lack of executive support (9.3%)

 Changing requirements and specifications (8.7%)

 Lack of planning (8.1%)

 System no longer needed (7.5%)

22

Tầm quan trọng trong XĐ yêu cầu?

23

24

25

 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

 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…)

Yêu cầu (requirement)

26

 “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?”

Yêu cầu (requirement)

Theo IEEE 1990, yêu u n m

:

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

Software Requirements (SR)?

27

 Yêu cầu quan trọng vì nó cung cấp các cơ sở cho tất cả công việc phát triển hệ thống sau đó

 Ngay khi yêu cầu được xác định, nhà phát triển khởi

đầu các công việc kỹ thuật khác như: thiết kế hệ thống, phát triển, kiểm thử, thực thi và vận hành

Vai trò của yêu cầu

28

 Yêu cầu được phát biểu (stated requirement)

 Yêu cầu thực (real requirement)

Phân loại yêu cầu

29

 Là các yêu cầu được cung cấp bởi khách hàng khi bắt

 Là các yêu cầu phản ánh nhu cầu xác thực của người

dùng

 Thường khác nhau rất lớn giữa yêu cầu phát biểu và

yêu cầu thực

 Việc phân tích các yêu cầu khách hàng (stated

requirements) được dùng để xác định và tinh chỉnh các nhu cầu thực sự của khách hàng

Real Requirements

31

 Là hệ thống các phương thức có liên quan với nhau chỉ định cái mà khách hàng muốn hệ thống làm gì

 There are two majors tasks in the requirements

 Analysis is the process of determining what the

customer wishes the system to do and formally creating

a list of requirements that the customer can understand and agree to do

 Modeling is a process of interpreting the customer

requirements into something that software engineers

can understand

Requirements Engineering

33

Phân i yêu u

34

Gồm hai loại chính:

• Yêu cầu chức năng (Function requirements)

• Yêu cầu phi chức năng (Non Functional Requirements)

Yêu cầu chức năng (Functional

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à behavioral requirements

 Ví dụ: “The system shall e-mail a reservation

confrimation the user”

Yêu cầu chức năng (Functional

requirements)

36

 Yêu cầu chức năng (Functional requirements): 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…

Yêu cầu chức năng (Functional

requirements)

37

Thí dụ: 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…

Yêu cầu phi chức năng (Non-functional requirements

 Sáu loại chính của yêu cầu phi chức năng: security, privacy, usability, reliability, availability, and performance

 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

Yêu cầu phi chức năng (Non-functional requirements

39

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

• 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 (Non-functional requirements

40

Yêu cầu phi chức năng (Non-functional requirements

41

Ví dụ

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…)

Phân i yêu u

42

Software Requirement bao m 3 c phân t:

 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)

44

 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)…cung cấp

 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)

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

requirements)

45

 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

Yêu cầu người dùng (User

requirements)

46

 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…

Yêu cầu chức năng (Functional

requirements)

47

i liên hê a c c yêu u

srse 49

i liên hê a c c yêu u

srse 50

Phân i i u yêu u

51

 Yêu cầu của phần mềm là gì?

Case study

53

 t thu p yêu u liên quan n t

Các bước trong Qui trình phát triển yêu cầu

56

Các bước trong Qui trình phát triển yêu cầu

57

Các bước trong Qui trình phát triển yêu cầu

58

Các bước trong Qui trình phát triển yêu cầu

59

Xác định yêu cầu:

• Là hoạt động chuyển thông tin phát sinh trong suốt

tiến trình phân tích thành tài liệu định nghĩa tập

hợp các yêu cầu

• Phản ánh chính xác điều mà người dùng muốn

• Tài liệu phải được viết để hệ thống sẽ được hiểu

bởi

• Người dùng cuối

• Những khách hàng của hệ thống

Các bước trong Qui trình phát triển yêu cầu

60

Đặc tả yêu cầu:

• Bản mô tả các yêu cầu hệ thống được thiết lập như cơ

sở của hợp đồng giữa khách hàng và nhà phát triển phần mềm

• Mô tả thật chi tiết về yêu cầu người dùng và yêu cầu hệ thống

• hữu ích cho thiết kế

Các bước trong Qui trình phát triển yêu cầu

61

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

• Quản lý yêu cầu là tiến trình quản lý sự thay đổi của yêu cầu trong suốt quy trình công nghệ yêu cầu và phát triển hệ thống

• Yêu cầu thì chắc hẳn là sẽ không hoàn thiện và không nhất quán

• Các yêu cầu mới thì liên tục phát sinh trong suốt tiến trình khi nhu cầu công việc thay đổi và có sự hiểu rõ hơn về hệ thống đang phát triển

• Các quan điểm khác nhau có các yêu cầu khác nhau và điều này thường làm phát sinh mâu thuẫn

c nh n a

requirement engineering

62

Ranh i a t n

63

Kỹ thuật yêu u

64

65

Lợi ích khi thu thập yêu cầu hiệu quả

 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

65

Lợi ích khi thu thập yêu cầu hiệu quả

 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 ngũ 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

66

Những lợi ích không định lượng

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

67