Bài giảng Thu nhận yêu cầu: Chương 1

1 1

TỔNG QUAN VỀ KỸ THUẬT YÊU CẦU REQUIREMENT ENGINEERING

Giảng viên: Trần Thị Kim Chi

Nội dung

2 2

 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

Khái Quát Về Phần Mềm

3 3

 Software = Program  Software product = Program + Document

+ Support

 Loại sản phẩm phần mềm

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.

Khái Quát Về Phần Mềm

4 4

Các đặc tính quan trọng của sản phẩm phần mềm  Maintainability: phần mềm có thể thay đổi thuận tiện

 Dependability: tính ổn định, bảo mật và an toàn của phần mềm. Không gây tổn hại về vật chất hay kinh tế cho hệ thống.

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

theo yêu cầu của người dùng

 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

cho công việc

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

5 5

 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

mềm

 Thực tế việc sản xuất phần mềm không đáp ứng kịp yêu

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

cầu của người sử dụng:  Không đủ về số lượng  Thiếu về chất lượng  Không kịp về thời gian

Nguyên nhân khách quan

6 6

 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

Nguyên nhân khách quan

7 7

 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

Nguyên nhân chủ quan

8 8

 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

 Cứ 6 đề án triển khai thì có 2 bị huỷ bỏ  Trung bình thời gian thực hiện thực tế bị kéo dài 50 % (cá biệt

200-300%)

 Các đề án lớn dễ thất bại  3/4 các hệ thống lớn có lỗi khi thực thi

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

18 % phát hiện được

 Quá trình thiết kế (25 % công sức): để lại 30 % lỗi, có 10 %

phát hiện được

 Quá trình mã hoá, kiểm tra và bảo trì: để lại 15 % lỗi, có 72 %

phát hiện được

Nguyên nhân chủ quan

9 9

 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ừ 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.

60% tổng lỗi trong một dự án phần mềm.

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

 "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."

10 A story…

 "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.

11 A story…

 "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 the new performance this capability. evaluation system. I think I have some other change requests for the employee system here, too." [sound of rustling paper]

I'm busy on

12 A story…

 "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."

13 A story…

 "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?"

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

15 15

 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

 Cần có sự tham gia của các chuyên gia trong việc thu

một vai trò vô cùng quan trọng

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ì?

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

16 16

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

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

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

17 17

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

18 18

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

19 19

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.

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

20 20

Lý do 3:  Gia công phần mềm đã làm thay đổi nhanh chóng chu

 Đặc tả sản phẩm để thực thi hay sản xuất bởi nhiều bộ phận khác nhau nên bị nhiều hạn chế và không có 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

kỳ phát triển phần mềm

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.

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

21 21

Lý do 4:  Việc phát triển phần mềm thường liên kết chặt chẽ với

 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

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ụ.

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

22 22

Nguyên nhân thất bại của dự án (RE-62%)  Những yêu cầu không đầy đủ - Incomplete

 Lack of user involvement – không cuốn hút người

requirements (13.1%)

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

dùng(12.4%)

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

23 23

Yêu cầu (requirement)

25 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

 Yêu cũng có là các ràng buộc trong quá trình

 Requirements described the “what” of a system, not the

phát triển hệ thống.

 Yêu cầu có thể được ràng buộc bởi hợp đồng hay văn

“how”

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

bản

không nhận biết (forgotten, unspoken…)

Yêu cầu (requirement)

26 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?”

Software Requirements (SR)?

u m n :

Theo IEEE 1990, yê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.

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

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

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

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

29 Stated Requirements

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

đầu phát triển hệ thống.

 Các dạng yêu cầu:

 Yêu cầu về thông tin  Dự toán  Bảng báo giá  Phát biểu công việc (statement of work – SOW)

30 Real Requirements

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

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

yêu cầu thực.

31 Requirements Engineering

 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

engineering:  Analysis  Modeling

32 Requirements Engineering

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

33 Phân

i yêu

u

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)

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

 Yêu cầu chức năng (Functional requirements):

chức năng dịch vụ hệ thống cung cấp.

 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à behavioral requirements.  Ví dụ: “The system shall e-mail a reservation

confrimation the user”

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

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

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

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…

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

 Yêu phi cầu năng chức

 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.

(Non-functional requirements): Không tập trung vào các chức năng của hệ thống mà chỉ tập trung vào các ràng buộc của hệ thố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.

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

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

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

ngữ lập trình…

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…

39 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

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

khách hàng (tên, số tham chiếu…)

• 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

41 Phân

i yêu

u

42 Đặc trưng của 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

43 c

c yêu

u

m 3 c phân t:

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

Software Requirement bao  Yêu cầu nghiệp vụ (Business requirements)

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

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

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

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

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

thể làm đối với hệ thống.

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

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

47 System requirements

yêu n m, a c

m hay bao

m n

i o. n n n n ng như ng, y c

vai

thể a ng m ng. c a con c cao u  Mô ng con (subsystem) ng t  ng con c  Con ng i năng

48 i liên hê

a

c

c yêu

u

srse 49

i liên hê

a

c

c yêu

u

srse 50

i

u

yêu

u

Phân

51 Các loại 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

52 Case study

c giao

m m,



t ng o

ng c sung thêm n y c ng y tinh c a t

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

nh (beaker)

53 p yêu

t thu

u Requirements Engineering

 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

54 p yêu

t thu

u Requirements Engineering



p yêu chu a

u liên quan : i

t thu t nh yêu ch yêu



yêu



u u suy ng, n thêm c yêu u



 Phân c c m tra xem yêu i u

a c p i nhu

u ng không

55 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

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.

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

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

• Mô tả chính xác để nắm bắt đúng vấn đề • Việc lập tài liệu này được thực hiện song song cùng với

• Lỗi trong định nghĩa yêu cầu cần được xem xét kỹ

một số các thiết kế cấp cao khác.

lưỡng.

• Nó phải được sửa chữa theo đúng vấn đề này.

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

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

điều này thường làm phát sinh mâu thuẫn

• Các quan điểm khác nhau có các yêu cầu khác nhau và

61 c

nh

n

a

requirement engineering

62 i

t

n

Ranh

a yêu

n

u

63

Kỹ thuật yêu

u

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

65 65

 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

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

66 66

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

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

67 67

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

u

khi

c

nh yêu

u sai

do c nh yêu u không ng i rework 

i ) —doing over something that you thought was

( already done.

u m

– t

 Rework n i do yêu t u % i ng chi – m % chi n m i.

68 a sai

i

a yêu

So

u

nh chi i i

i

m

c nhau

t???

69 SDLC

70 Khi không

i rework

 Imagine how different your life would be if you could cut the rework effort in half! You could build products faster, build more and better products in the same amount of time, and perhaps even go home occasionally.

71 n

c

nh yêu

Nguyên nhân u không

n nh công

 Insufficient User Involvement – thiếu sự tham gia

người dùng

 Creeping User Requirements – Yêu cầu người dùng

 Ambiguous Requirements – yêu cầu mơ hồ, không rõ

phình ra

 Gold Plating - Yêu cầu mạ vàng (Gold Plating): khi

ràng

người phát triển cộng thêm chức năng không có trong đặc tả

72

 Minimal Specification – Yêu cầu tối thiểu  Overlooked User Classes – Bỏ qua lớp người dùng  Inaccurate Planning – Hoạch định không chính xác

 assignment a m: m m 10

(srse)

Ví dụ

 Yêu cầu Nhập nhằng

73 Ví dụ

74 Ví dụ

75 Ví dụ

76 t

m sai

m

Requirements

quan Engineering

 Misconception 1: Any Subject Matter Expert Can

Become a Requirements Engineer after a Week or Two of Training

 Misconception 2: Nonfunctional and Functional

 Misconception 3: Processes That Work for a Small

Requirements can Be Elicited Using Separate Teams and Processes

 Assignment:

m 9

Number of Requirements Will Scale

77 c

u tiên

t

a ng requirements engineering

ch thông tin u

c yêu

suy

a phi

ng, stakeholder, n nhu c năng

ng c năng. nh c yêu

u p

c t ng u a y c yêu i n n nh c c  Phân  

u p yêu

79 ch

ng

ai?

nhân hay

ch mong ng (customer) c n t c c n



ch ng n   Hai

management level)

 End user

m. i ch m (Software customer) : (Customer at n

80 ch

p

n

ng (management level)



i ch i n n m. 

nh yêu

(business

ng c n hay u

requirement)  Mô c tiêu



ch n n

nh cho

p n

c stakeholders nh c p ch n ng, công ty hay nh. n

c nh u c i p ng theo

yêu .

chi

t p u

p i xây

không ng

t i

t  c yêu  Nhưng c u c yêu t n t

81 ch

ng

end user

c ng n m

m c ng ai n

p. m

t p hay mô n  Bao  Users

n m t ng mong i c thi n i m

82 c

nh

a

ch

ng

hai y

ch yêu

i m

ng i gian đến c ch c phân ng i ch

i ng n không n u không tin phân nh dung ra n o i c ng

  Đôi i nhau.

83 c

nh

a

ch

ng

t n a yêu

ng xung p t (conflict) yêu

nh n p a

u n nh

u n i

nh như “con

y i i c 

ng. c c ng không ng ng tương lai không

ng t” t a

 u  Yêu c n i, như ..

84 c

nh

a

ch

ng

p c a

ng u đi c tiêu c căng ng c c a

ng.

ch (analyst) nên m c c i n

c giao n i phân a nh i ng (key user representative) c  

c xung

i a

85 a

ch

ng

t

i quan n

a i quan

ng. t

t ng cao c quan giao

u u ng customers hay nên i

ng t i ng

n i a ng (adversarial) c yêu m

cung

 Yêu p   Managers p u do a

86 i

ch ch

m ng

n

n m



ng tuyên ngôn

nh cho

ch (Requirements Bill of Rights for Software Customers)

t kê n khi

u mong c

Assignment 5

87 i

ch ch

m ng

n

n m

n nh cho ng m (Requirements Bill of Responsibilities for

t kê



Software Customers) c ng a p yêu

thu

i u

ch t n trong phân ch. Assignment 21

88 Stakeholder

• Customers • Users • Requirements analysts • Developers • Testers • Documentation writers • Project managers • Legal staff – quyền hợp pháp • Manufacturing people – người sản xuất • Sales, marketing, field support, help desk, …

Assignment 1

89 Exercise

 You are a product manager for a machine tool company. The directors have asked you to develop a new cutting machine to cut cloth for fashionable dresses of all sizes and patterns. The machine will be sold to clothing makers around the world:

a. Who are your key stakeholders? b. How will you analyse and validate your stakeholder list?

90 Nhà phân tích yêu cầu - Requirements analyst



 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)Systems analyst

91 Vai

a analyst

 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

92 Requirements analyst

 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

93 Requirements analyst

94 m

a Requirements

c tiêu a i ng,

c tiên nh

c năng, cho c

i i c yêu m n nh, c developers

analyst  Analyst sau

c n , xây

t ng m u u c nh n m.

95 m

a Requirements

analyst

 Xác định yêu cầu nghiệp vụ - Define business

requirements.

 Xác định các stakeholder và các lớp người dùng-dentify

project stakeholders and user classes.  Rút ra những yêu cầu - Elicit requirements  Viết đặc tả yêu cầu-Write requirements specifications  Mô hình hóa yêu cầu-Model the requirements  Điều hành việc đánh giá yêu cầu-Lead requirements

 Phân loại ưu tiên các yêu cầu- Facilitate requirements

validation

 Quản lý yêu cầu - Manage requirements

prioritization

Assignment ??

96 năng

a

phân

ch

 Kỹ năng lắng nghe - Listening skill  Kỹ năng phỏng vấn - Interviewing and questioning skill  Kỹ năng phân tích - Analytical skill,  Kỹ năng điều khiển - Facilitation skills.  Kỹ năng quan sát - Observational skills.  Kỹ năng viết - Writing skills  Kỹ năng tổ chức - Organizational skills  Kỹ năng mô hình hóa - Modeling skills  Kỹ năng giao tiếp - Interpersonal skills  Tính sáng tạo - Creativity

 Assignment ??