ÔN TẬP GIỮA KỲ

ÔN TẬP GIỮA KỲ

NỘI DUNG

1. Phát biểu vấn đề2. Tầm nhìn và Phạm vi (Vision and Scope)3. Xác định mục tiêu4. Xác định yêu cầu5. Xác định StackHolder, lớp người dùng6. Các kỹ thuật thu nhận yêu cầu7. Các kỹ thuật phân tích yêu cầu 8. Bài tập

Product Vision và Project Scope

Vision (hay mission) mô ta thưc chất san phâm se là cái gì.

Project scope xác định môt phần cua mục đích lâu dài (long-term product vision) cua san phâm mà dư án hiên hành đang thưc thi.

Vision dùng để chi đên ca hê thông phần mềm, no phan ánh mục tiêu nghiêp vụ (business objectives) cua hê thông, con scope chi liên quan đên tưng dư án riêng le hay môt lần lăp trong quá trình phát triển tăng tiên các chưc năng cua hê thông.

BM HTTT - Khoa CNTT - HUI 3

Product Vision và Project Scope

Vision thay đổi tương đôi chậm, scope thay đổi linh đông theo mỗi dư án tùy thuôc vào các ràng buôc về thời gian (schedule), ngân sách (budget), tài nguyên (resource) và chất lượng (quality) cua dư án.

Các tài liêu nên co cua mỗi dư án mới Vision and scope document Software Requirement Specification (SRS)


Product vision và project scope


Vision và Scope Document

Tài liêu bao gồm môt mô ta về cơ hôi kinh doanh cua san phâm, tầm nhìn và các mục tiêu cua san phâm, báo cáo phạm vi và các giới hạn cua san phâm, mô ta đăc tính cua khách hàng (characterization of customers), các ưu tiên cua dư án, mô ta các tiêu chuân đánh giá sư thành công cua dư án.

Tài liêu cần tương đôi ngắn, chi nên tư 3 tới 8 trang, phụ thuôc chu yêu vào ban chất và kích thước cua dư án.


Vision và Scope Document

Các vấn đề thuôc tầm nhìn và phạm vi (vision and scope) cua dư án cần được phân giai rõ trước khi các yêu cầu chưc năng (functional requirements) chi tiêt được đăc ta đầy đu.

Môt tài liêu tầm nhìn và phạm vi (vision and scope) tôt se cung cấp các tham chiêu cần thiêt cho viêc thêm, xoá bỏ, chinh sửa các yêu cầu trong tiên trình phát triển cua dư án.


Tài liêu vê vision và scope

Chu nhân cua tài liêu vision and scope là:Người tài trợ chính (executive sponsor) cua

dư ánNgười chi tiền (funding authority)

Người phân tích yêu cầu (requirements analyst) co thể làm viêc với owner để viêt tài liêu vision and scope.


Tài liêu vê vision và scope

Yêu cầu nghiêp vụ nên thu thập tư nhưng ai hiểu rõ vì sao ho quan tâm đên dư án. Ho là: Customer Senior management Project visionary Product manager Subject matter expert Members of the marketing

department.


Khách hàngNgười co trách nhiêm trong

bô phận quan lýNgười hình dung cua dư ánQuan lý san phâmCác chuyên gia lãnh vụcThành viên cua bô phận

marketing

Scope of a project

Cần phai xác định scope (=boundary) cua phần mềm.

Môt trong các rui ro lớn nhất cua hê thông là để cho scope “phình ra” (‘creep’), không ai biêt chính xác hê thông bao gồm nhưng gì, mất bao lâu và chi phí bao nhiêu để hoàn tất.


Scope of a project


Scope of a project


Xác định những người liên quan

Stakeholder:Bao gồm nhưng người, tổ chưc mà là môt

phần cua môi trường hê thông. Hê thông cung cấp cho ho nhưng lợi ích và ho co tầm quan trong trong hê thông


• Customers

• Users

• Requirements analysts

• Developers

• Testers

• Documentation writers

• Project managers

• Legal staff – nhom người làm viêc hợp pháp

• Manufacturing people – người san xuất

• Sales, marketing, field support, help desk, …

Stakeholder

14

Stakeholder của hê thống ATM

Khách hàng cua ngân hàng Đại diên cua các ngân hàng khác Người quan lý ngân hàng Nhân viên thu tiền Người quan trị CSDL Người quan lý bao mật Kỹ sư bao trì phần cưng và phần mềm Nhưng người điều phôi ngân hàng…


Stakeholder Stakeholder không rõ nhưng gì ho thật sư muôn Stakeholder diễn đạt yêu cầu theo nhưng thuật ngư

riêng cua ho Nhưng stakeholder co thể co nhưng yêu cầu tranh

chấp Nhân tô quyền lưc và tổ chưc anh hưởng tới yêu cầu

hê thông Nhưng yêu cầu co thể thay đổi trong quá trình phân

tích, co thể xuất hiên nhưng nhân tô mới, nhưng thay đổi về môi trường nghiêp vụ


Thực hành

Bạn là người quan lý san phâm cho môt công ty công cụ máy. Giám đôc yêu cầu bạn phát triển môt máy cắt mới quần áo để may váy thời trang theo các kích cỡ và mẫu. Máy được bán cho nhưng người làm quần áo khắp thê giới

1. Các stakeholder?

2. Phân tích và đánh giá các stakeholder?


Answer #1

Key stakeholders are: Giám đôc và các cổ đông trong công ty Nhân viên bán hàng và tiêp thị cua công ty Khách hàng (nhưng người vận hành máy cắt và chu

cua ho) Quan chưc chính quyền phụ trách về sưc khỏe và an

toàn trong mỗi quôc gia mà ta dư định bán máy cho ho.

Các đôi thu cạnh tranh (negative stakeholders). Nêu công ty co ý định đam nhận thêm khâu bao trì

máy moc thì đôi bao hành cung là stakeholder chính.

Answer #1

How will you analyse and validate your stakeholder list?Kiểm tra (check) và cập nhật (update) danh

sách môt cách thường xuyên; duyêt lại (review) và theo dõi (follow) thông qua các cuôc tiêp xuc găp gỡ với stakeholder chính

Trang 34

Phân loại người dùng

Dưa vào các yêu tô sau:Mưc đô thường xuyên người dùng sử dụng

san phâmKinh nghiêm về miền ưng dụng cua ho, sư

thành thạo về hê thông máy tínhCác tính năng mà người dùng sử dụngCác tác vụ để hỗ trợ xử lý nghiêp vụQuyền truy xuất và cấp đô bao mật


Phân cấp người dùng


Kinh nghiêm phân loại người dùng

Nên phân loại người dùng sớm để co thể thu thập yêu cầu tư đại diên cua mỗi lớp người dùng.

Không nên e ngại nêu luc đầu co quá nhiều lớp người dùng

Không nên bỏ qua bất kỳ lớp người dùng nào vì sau này co thể se phai rework

Ghép chung các lớp người dùng nào co yêu cầu tương tư nhau. Nên giam xuông sao cho không quá 15 lớp người dùng khác nhau.

BM HTTT Khoa CNTT - HUI 22

Tài liêu người dùng

Ghi chép các lớp người dùng, tính cách, trách nhiêm, và địa điểm làm viêc vào tài liêu SRS

Giup đôi phát triển xêp loại đô ưu tiên các yêu cầu

Giup các tester xây dưng cách sử dụng hê thông (usage profile for the system) và co thể lập kê hoạch cho viêc kiểm thử


Tìm đại diên người dùng

Mỗi loại dư án đều cần co đại diên người dùng thích hợp để cung cấp tiêng noi chung cho nhom người dùng đo.

Người đại diên không chi tham gia trong giai đoạn thu thập yêu cầu mà trong suôt chu kỳ phát triển dư án


Đại diên lớp người dùng(user representatives) Đôi với ưng dụng cua công ty: dễ dàng xác định

người dùng thưc sư cho mỗi lớp người dùng. Ví dụ: chon Fred là kỹ sư hoa cho lớp chelmistt

Đôi với phần mềm thương mại (commericial software): chi co thể co được người dùng thưc sư sau khi phát hành phiên ban chạy thử (beta-testing) hay đầu tiên Nên thiêt lập nhom người tình nguyên (focus group) tư

nhưng người dùng phần mềm cua mình hay phần mềm cua đôi thu


Người dùng tiêu biểu PC

PC (Product champion) dùng để chi nhưng thành viên chính trong công đồng người dùng cung cấp cho dư án các yêu cầu.

Cs (Champions) là các người dùng thưc sư, không phai là người đại diên như nhà tài trợ, nhân viên tiêp thị, người quan lý …


Vai trò của Product Champiom

PC (Product champion) thu thập yêu cầu tư các thành viên khác thuôc lớp người dùng mà ho đại diên và hợp nhất lại yêu cầu không giông nhau.

Phát triển yêu cầu là trách nhiêm chung cua nhà phân tích và khách hàng đã được chon, măc dù nhà phân tích se là người viêt yêu cầu.


Một PC tốt

Co cái nhìn rõ ràng về hê thông mới và ung hô hê thông vì ho thấy được lợi ích dành cho ho tư hê thông mới này.

Là người cởi mở và được đồng nghiêp tín nhiêm.

Là người hiểu biêt thấu đáo về nghiêp vụ và môi trường hoạt đông cua hê thông.

Nhận thưc được tầm quan trong cua ho đôi với sư thành công cua dư án.


PC bên ngoài

Khi phát triển phần mềm thương mại, rất kho tìm PC tư bên ngoài.

Nêu co quan hê công viêc gần gui với 1 sô công ty, môt sô người thể sẵn long tham gia vào quá trình thu thập yêu cầu.

Nên khích lê bằng kinh tê cho các PC bên ngoài như giam giá san phâm hay tra tiền theo giờ khi ho tham gia công viêc


Quyên hạn của product champion

Phương pháp dùng PC chi tôt khi mỗi champion co quyền đưa ra các quyêt định đại diên cho lớp cua minh

Nêu quyêt định cua champion luôn bị gạt bỏ bởi managers hay SW group thì thời gian và thiên chí cua ho se bị lãng phí.

Nhưng champion cung nên nhớ rằng ho không phai là khách hàng duy nhất


Hạn chế tử PC

Làm thê nào để tránh chi nghe yêu cầu tư CP mà bỏ qua các nhu cầu tư các khách hàng khác.

Nêu khách hàng đa dạng thì trước tiên cần nhận biêt yêu cầu cơ ban chung cho moi khách hàng, sau đo xác định các yêu cầu khác tư các loại người dùng khác, tư bô phận tiêp thị, tư khách hàng riêng le,…


Goal và requirement

Goals là cái mà stakeholders muôn thưc thi. Goals co thể co nhiều mưc đô khác nhau:

Mưc cao nhất (highest level): phát biểu về nhiêm vụ và mục tiêu, chính là mission statements and objectives.

(Co thể dùng Mission = vision = objective)

Mục tiêu lâu dài thì được goi là policies.Mưc thấp nhất (lowest level): goi là chưc năng

cơ ban riêng biêt (individual functions)


Goal và requirement

Mục tiêu chi tiêt se trở thành requirement khi:Co thể kiểm chưng được (fully verifiable)Được xêp loại ưu tiên trong 1 dư án cụ thể


Question 2

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. What are the major goals for this project?

b. Using the list of stakeholders for this project, identify the likely sources of tension (possible conflict) between stakeholders’ goals.

Answer #2

Major goals: - Đưa máy cắt ra thị trường đung luc và trong ngân sách

dư tính- Phát triển 1 dong san phâm mới.- Đạt được chưng nhận an toàn (safety certificate) ở tất

ca các quôc gia dư định bán máy. - Hiểu được yêu cầu trong tưng quôc gia mà ta dư định

bán máy,- Chuân bị tài liêu cho người dùng và người bán hàng

bằng nhiều thư tiêng tương ưng với các quôc gia mà ta dư định bán máy.

- Bao đam là bô phận bao hành phai sẵn sàng- Bao đam là bô phận phân phôi tiêp thị đã sẵn sàng- Hiểu rõ các đôi thu cạnh tranh và co chiên lược đôi pho

36

36 Môt yêu cầu là môt đăc trưng cua hê thông, hay là sư

mô ta nhưng viêc, mà hê thông co kha năng thưc hiên để hoàn thành mục tiêu cua hê thông

Yêu câù cung co thê � là các ràng buôc trong quá trình phát triển hê thông.

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

Co nhưng yêu cầu ngầm định (implicit) Môt yêu cầu co thể được nhận biêt (known, spoken)/

không nhận biêt (forgotten, unspoken…) Requirements described the “what” of a system, not the

“how”

Yêu cầu (requirement)

Yêu cầu quan trong vì no cung cấp các cơ sở cho tất ca công viêc phát triển hê thông sau đo.

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 tro cua yêu cầu

37

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

38

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 tinDư toánBang báo giáPhát biểu công viêc (statement of work –

SOW)

Stated Requirements

39

Là các yêu cầu phan ánh nhu cầu xác thưc cua 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 chinh các nhu cầu thưc sư cua khách hàng.

Real Requirements

40

Là hê thông các phương thưc co liên quan với nhau chi đị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:AnalysisModeling

Requirements Engineering

41

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

42

Phân loại yêu cầu trong quá trình phân tích yêu cầu

43

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

44

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 cua phần mềm mà các nhà phát

triển phai xây dưng để giup người dùng hoàn thành

nhiêm vụ cua ho, thỏa mãn được yêu cầu nghiêp vụ. Đôi khi con được goi là behavioral requirements. Ví dụ: “The system shall e-mail a reservation

confrimation the user”


45

Yêu cầu chức năng (Functional requirements): Yêu cầu chưc năng chi ra nhưng gì hê thông làm, chung 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…


46

Thí dụ: Trong hê thông quan lý thư viên•Người dùng co 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 để co 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

47

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 cua hê thông mà chi

tập trung vào các ràng buôc cua hê thông. Nhưng ràng

buôc về tiêu chuân, thời gian, qui trình phát triển…, chu yêu

là nhưng yêu cầu về chất lượng. Sáu loại chính cua yêu cầu phi chưc năng: security,

privacy, usability, reliability, availability, and performance. Ràng buộc: phan anh nhưng đăc trưng cua miền ưng

dụng. Chung co thể là nhưng yêu cầu chưc năng hay yêu

cầu phi chưc năng.


48

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


49

Ví dụ

Trong hê thống quản lý thư viên•Yêu cầu san 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 phai 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 cua

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

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

50

Kha thi - Feasible Co 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 đu - Complete Lần vêt được - Traceable

Đăc trưng cua yêu cầu

51

Software Requirement bao gôm 3 mức phân biê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)

Các mưc yêu cầu

52

Biễu diễn các mục tiêu cua tổ chưc hay khách hàng yêu cầu hê thông phai co

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 quan 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 ta (vision) và phạm vi (scope) cua tài liêu, đôi khi con được goi 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)

53

Mô ta mục tiêu (goal) hay tác vụ (task) cua 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 Bang event-response.

Yêu cầu người dùng mô ta cái (what) mà người dùng co thể làm đôi với hê thông.

Ví dụ: use case "Make a Reservation" dùng trong các website cua hàng không, thuê xe, hay khách sạn.

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

54

Xác định chưc năng cua phần mềm mà các

nhà phát triển phai xây dưng để giup người

dùng hoàn thành nhiêm vụ cua ho, thỏa mãn

được yêu cầu nghiêp vụ.

Đôi khi con được goi là yêu cầu về hành vi

(behavioral requirements)

Ví dụ: Hê thông se gởi môt xác nhận giư chỗ

cho khách hàng…


55

Các kỹ thuật thu nhận yêu cầu

Document SamplingInterviewingSurvey and observationQuestionairesWorkshop and BrainstormingJAD (Joint Application Development)

sessions

Document Sampling

Document SamplingInterviewingSurvey and observationQuestionairesWorkshop and BrainstormingJAD (Joint Application Development)

sessions

Interviewing

• Là kỹ thuật trưc tiêp và đơn gian • Nêu bạn cần biêt môt sô điều, bạn hỏi

môt vài ngườiCo 5 bước cơ ban để phỏng vấn

Chon người được phỏng vấnThiêt kê câu hỏi phỏng vấnChuân bị cho phỏng vấnHướng dẫn phỏng vấnThưc hiên phỏng vấn tiêp

Interviewing

Chon người phỏng vấn Cần môt kê hoạch phỏng vấn

Danh sách tất ca nhưng người để phỏng vấn Khi nào mỗi người se được phỏng vấn Mục đích gì ở ho se được phỏng vấn

Danh sách co thể là không chính thưc … hoăc no co thể là môt phần cua phân tích dự án

Danh sách được dưa vào thông tin cần Tôt để tạo ra các phôi canh khác nhau

Người quan lý (Managers) Người dùng (Users)

Chon nhưng người cho các lý do chung Phỏng vấn được lăp đi lăp lại

Interviewing

Thiêt kê câu hỏi Đưng hỏi thông tin mà co thể đạt được tại nơi khác Muôn chi ra khía cạnh người phỏng vấn Mong muồn tạo nên thông tin tôt hơn.

Interviewing

* Có bao nhiêu cuộc điện thoại được nhận trên một ngày?* Có bao nhiêu loại khách hàng?* Bạn muốn hệ thống mới cung cấp thông tin gì?

Câu hỏi đóng• Yêu cầu câu trả lời cụ thể• Có nhiều lựa chọn.• Có bao nhiêu yêu cầu• Người phân tích sẽ điều khiển• Thông tin rõ ràng

Câu hỏi mở• Không yêu cầu câu trả lời cụ thể• Để thu thập thông tin và dữ liệu• Người phân tích có thể sửa đổi• Tạo một hệ thống hiệu quả

* Bạn nghĩ gì về hệ thống hiện tại?* Những vấn đề cơ bản nào bạn đối mặt hàng ngày?* Bạn quyết định chiến dịch quảng cáo thực hiện như thế nào?

Câu hỏi tìm kiếmTiếp tục câu hỏiCó gạn lọcKhuyến khích mở rộng câu trả lờiChỉ ra những gì bạn nghe và thích thú

* Tại sao?

* Bạn có thể đưa cho tôi một số ví dụ?

* Bạn có thể giải thích chi tiết hơn?

Interviewing

Thiêt kê câu hỏi Đưng hỏi thông tin mà co thể đạt được tại nơi khác Muôn chi ra khía cạnh người phỏng vấn Mong muồn tạo nên thông tin tôt hơn.

Interviewing

Chiên lược phỏng vấn

High LevelVery General

Medium-LevelModerately

Specific

Low-LevelVery Specific

TOP DOWN

BOTTOM UP

EXAMPLES?

Mức caorất chung

Mức trung gianXác định ở mức

độ vừa phải

Mức thấprất chi tiết

Interviewing

Hướng dẫn phỏng vấn Trình diễn chuyên nghiêp và không thiên vị Xây dưng quan hê (và trung thưc) với người được phỏng vấn Ghi chép tất ca thông tin Kiểm tra tổ chưc cách giai quyêt theo băng thu âm Đam bao bạn hiểu tất ca các kêt qua và ngôn ngư Chia ra các sư kiên tư các quan điểm Đưa ra cho người được phỏng vấn thời gian để hỏi câu hỏi Đam bao để cam ơn người được phỏng vấn Kêt thuc thời gian

Interviews

Interviews

Exercise - Part 1

Find a partner for this exercise Think e-commerce system (hệ thống thương mại). You will now serve as

“customer” for that project and your partner will act as “project lead – cố vấn” (of requirements consultant) for you.

Create an interview outline (be sure to include your name, customer name, system name) that addresses at least 2 high-priority or high-risk items.

Conduct the interview Translate the responses into possible requirements. For each possible

requirement, answer the following:

a. What kind of requirement is it?

b. How does it (can it) meet the necessary condition for a requirement? Switch roles, you become the project lead and you partner the customer for

their project. Repeat the above with the new roles and project

Questionnaires

Được sử dụng thêm vào trong quá trình phỏng vấn. Mục tiêu là chứa đựng thông tin từ bộ phận tiêu biểu của nhiều khách hàng.

Bản câu hỏi hữu dụng khi người phân tích cần thu thập thông tin từ nhiều người. Nếu có ít thời gian thì bản câu hỏi rất hữu dụng.

Bản câu hỏi có thể không cho kết quả như ý từ những câu trả lời vì họ rất bận rộn và họ có thể cho rằng nó không quan trọng.

Có thể bao gồm những câu hỏi đóng và câu hỏi mở.

Questionnaires

Có những loại câu hỏi đóng sau:

1. Fill-in-the-blanks – Điền vào khoảng trống.

2. Dichotomous(Yes or No type) – Loại Yes hay No.

3. Ranking scale questions – Câu hỏi xếp loại.

4. Multiple-choice questions – Câu hỏi nhiều lựa chọn.

5. Rating scale questions are an extension of the multiple-choice questions – Câu hỏi phân loại là mở rộng của câu hỏi nhiều lựa chọn .

Workshop and Brainstorming

Co thể là kỹ thuật năng đông nhất để thu thập yêu cầu.

Tập hợp tất ca các stakeholder chính cùng với nhau trong 1 giai đoạn tuy ngắn nhưng rất tập trung.

Sử dụng facilitator co kinh nghiêm tư bên ngoài trong quan lý yêu cầu co thể bao đam cho sư thành công cua workshop.

Brainstorming là phần quan trong nhất cua workshop.

Brainstorming

Ý tưởng then chốt JAD

Cho phép người quan lý dư án, người dùng và người phát triển làm viêc với nhau

Co thể giam phạm vi đên 50% Tránh đoi hỏi quá chi tiêt hoăc quá mơ hồ JAD được như 1 kỹ thuật để phát triển yêu

cầu cua 1 hê thông và trong các giai đoạn đầu cua dư án phần mềm.

Mục đích: tập hợp MIS và người dùng cuôi trong cơ chê cua 1 workshop, để cùng thông nhất (consensus) với nhau các yêu cầu cua hê thông.

Quản lý các vấn đê trong phiên JAD

Giam sư thông trị Khuyên khích viêc không liên quan cua người

đong gop Bên ngoài cuôc thao luận Chương trình nghị sư môt chiều Sư đồng ý mạnh me Xung đôt không được giai quyêt Xung đôt đung Sử dụng sư hài hước

JAD Team Members

Session leader coordinator – Người lãnh đạo User information source – Thông tin người dùng Manager information source – Thông tin người quản lý Sponsor champion – Người bảo trợ System analyst listener – Nhà phân tích hệ thống Scribe recorder – Máy ghi âm, người ghi chép IS staff listener – Người nghe

Viêc dùng bang co thể giup nắm bắt được yêu cầu cua stakeholder rõ ràng và chăt che hơn.Bang quyêt định

Condition Stub Condition Entry

1 2 3 4 5 6

Customer is individual ? Y Y . . . .

Customer shopkeeper or retailer ? . . Y Y Y Y

Order-size 85 copies or more ? . . Y . . .

Order-size 49-84 sarees ? . . . Y . .

Order-size 13-48 copies ? . . . . Y .

Order-size 12 or more ? . Y . . . .

Order-size less than 12? Y . . . . Y

Allow 50% discount . X X . .

Allow 40% discount . . . X . .

Allow 30% discount X . . . X .

Allow 15% discount . . . . . X

Bang quyêt định (Decision Tables)

Example: Consider the recruitment policy of ABC Software Ltd.• It the applicant is a BE then recruit otherwise not. • If the person is from Computer Science, put him/her in the

software development department and if the person is from non-computer science background put him/her in HR department.

• If the Person is from Computer Science and having experience equal to or greater than three years, take him/her as Team leader and if the experience is less than that then take the person as Team member.

• If the person recruited is from non Computer Science background, having experience less than three years, make him/her Management Trainee otherwise Manager

Bang quyêt định (Decision Tables)

Định nghĩa phân tích yêu cầu

Là quá trình suy luận các yêu cầu hê thông thông

qua quan sát hê thông hiên tại, thao luận với các

người sử dụng, phân tích công viêc.

Viêc này co thể liên quan với viêc tạo môt hay

nhiều mô hình khác nhau. No giup các phân tích

viên hiểu biêt hê thông.

Các mẫu hê thông cung co thể được phát triển để

mô ta các yêu cầu.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

79

HƯỚNG DẪN SUY LUẬN YÊU CẦU (REQUIREMENTS ELICITATION GUIDELINES)

QUY TRÌNH PHÁT TRIỂN YÊU CẦU GỢI Ý

1.Định nghĩa tầm nhìn và phạm vi cua dư án

2.Xác định các lớp người dùng

3.Xác định các đại diên thích hợp cua mỗi lớp người dùng

4.Xác định người ra quyêt định về yêu cầu và quy trình ra quyêt định cua ho

5.Chon các kỹ thuật suy luận mà bạn se dùng

6.Ứng dụng các kỹ thuật suy luận để phát triển các use cases và xêp thư tư ưu tiên các use cases đo cho tưng phần cua hê thông


HƯỚNG DẪN SUY LUẬN YÊU CẦU(REQUIREMENTS ELICITATION GUIDELINES)


7.Thu thập thông tin về các thuôc tính chất lượng và các yêu cầu phi chưc năng khác tư người dùng.

8.Phác thao các use cases tư các yêu cầu chưc năng cần thiêt

9.Rà xét các mô ta use-case và các yêu cầu chưc năng

10.Phát triển các mô hình phân tích, nêu cần thiêt, để làm sáng tỏ hiểu biêt cua nhưng người tham gia suy luận về các phần cua yêu cầu

81

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

HƯỚNG DẪN SUY LUẬN YÊU CẦU (REQUIREMENTS ELICITATION GUIDELINES)


11.Phát triển và đánh giá các nguyên mẫu giao diên người dùng nhằm trưc quan hoá các yêu cầu chưa được hiểu kỹ

12.Phát triển các test cases dưới dạng ý tưởng tư các use cases

13.Sử dụng các test cases để kiểm tra các use cases, các yêu cầu chưc năng, các mô hình phân tích, các nguyên mẫu

14.Lăp lại các bước tư 6 đên 13 trước khi thưc hiên thiêt kê và xây dưng tưng phần cua hê thông


Ma trận CRUD

Là 1 cách để tìm yêu cầu bị thiêu. Viêt tăt cua Create, Read, Update, and Delete. Ma trận CRUD cho sư tương quan giưa các

action cua hê thông với các thưc thể dư liêu giup ta biêt được mỗi data item được tạo, đoc, cập nhật, xoa ở đâu và như thê nào.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

83

Ma trận CRUDL cho hê thông theo dõi hoa chất

Bô Môn HTTT - Khoa CNTT - HUI84

CRUDL (Create, Read, Update, Delete, List)Co thể rut ra các suy luận gì tư ma trận trên khi noi đên thưc thể Requester ???

Process Modeling Technique

Kỹ thuật mô hình hoa quy trình (model driven) phù hợp cho ca elicitation và analysis. Data flow diagrams (DFDs) Use case analysis (use case = business

process)

Data flow diagrams (DFDs)

Được sử dụng trong 1 thời gian dàiTập trung vào dong dư liêu và cấu truc

dư liêu hơn là vào dịch vụ (services).DFD chi ra luồng dữ liệu của hệ thống thông

tin, mối qua hệ giữa những luồng dữ liệu và làm thế nào dữ liệu được lưu trữ tại vị trí cụ thể


Elements of Data Flow Diagrams(Những thành phần của DFD) The External Entity - Tác nhân ngoài: nằm bên ngoài

hệ thống, mô tả dữ liệu nguồn và dữ liệu đích của hệ thống

The Data Flow - Luồng dữ liệu: mô tả sự di chuyển của dữ liệu.

The Data Store - Kho lưu trữ: mô tả dữ liệu mà nó không di chuyển.

The Process - Quá trình: mô tả một hoạt động mà thay đổi hay duy trì dữ liệu.


Process

Data flow

Data store

Externalentity

Sơ đồ ngư canh

Mức ngữ cảnh mô tả toàn bộ hệ thống ở mức tổng quá và hoạt động môi trường bên ngoài của nó và chỉ toàn bộ hệ thống như một quá trình. Diễn ta toàn bô hê thông bằng môt ô xử lý DFD ngư canh là sơ đồ ở mưc tổng quát nhất DFD ngư canh xác định phạm vi cua hê thông DFD ngư canh không co kho dư liêu

Khách hàng

0

Phaân heä quaûn lyù ñôn haøng

Boä phaän quaûn lyù

Thông tin về măt hàng mới

Thông tin vềKhách hàng

Thông tin vềmăt hàng mua

báo cáo theo chi tiêu

Đơn hàng

Chi tiêu báo cáo

SƠ ĐỒ MÔI TRƯỜNG CỦA PHÂN HỆ QUẢN LÝ ĐƠN HÀNG

Sơ đồ ngư canh

Ve môt chưc năng biểu diễn thưc thể hê thông (process 0)

Xem hê thông như là môt hôp đen Nhận dạng ranh giới hê thông Ranh giới giưa hê thông đích và môi trường bên

ngoài Tìm tất ca danh sách các đầu vào và đầu ra tại đinh

đên hoăc đi tư thưc thể ngoài, ve như các luồng dư liêu

Ve các thưc thể ngoài như nguồn hoăc đích cua các luồng dư liêu

Sơ đồ ngư canh

Hê thông được mong đợi tư đông hoá hoạt đông cua thư viên Hai người dùng bên ngoài (terminators) 3 mục dư liêu vào 1 mục dư liêu ra

Môt chưc năng mưc đinh (transform) -- Issue library item

Đôc gia Thư viênNhân viên

thư viên

The thư viên

Yêu cầu

Kêt qua

Đưa ra ngày

Example: Student result management system (Hệ thống quản lý điểm cho sinh viên)

Student result Management

System

Administrator

Subject

Student

Marks

Student information Reports generated

Marksheet generated

Student performance reports generated

The context diagram

Sơ đồ ngư canh

Example: Student result management system (Hệ thống quản lý điểm cho sinh viên)

0

Student result Management

System

Student information Reports generated

Marksheet generated

Student performance reports generated

0 – Level DFD of result management system

AdministratorUser account maintenance

Subject Subject info entry

StudentStudent info

entry

Marks Marksentry

Sơ đồ ngư canh

Sơ đồ DFD mưc 0

D1 Maët haøng

Sôđơn hàng

1.4.1

Tìm mô ta, đvt, đơn giá cua măt hàng

Khách hàng

Sô lượngMã hànghay enter

D4 Doøng ñôn haøng

1.4.2

Tính stt, thành tiền,tổng công

Mã hàng+đơn giá

Đơn hàng

1.4.3

Tạo đơnhàng

Sôđơn hàng

enter

D3 Ñôn haøng

D2 Khaùch haøng

Sơ đồ ngư canh

Exercise : Railway Reservation SystemRailway caters to the need of passenger. Tickets can be booked for different classes. Some concessions are available for categories like students, old people, etc. there is a special category for reserving tickets for handicapped people, military, MPs. There is a certain surcharge levied for special trains. Fare computation depends on the class, category, train, and distance. The passenger is issued a confirmed ticket if seat is available. She/he gets a waitlisted/RAC ticket if she/he so desires.Ve sơ đồ ngư canh

Phương pháp Use Case

Use Case: Mô tả những chức năng của hệ thống từ hướng nhìn của người sử dụng.

Use case diagram: Là một mô hình trong UML (Unified Modeling

Language)Mô tả các chức năng mà hệ thống cung cấpCho biết người dùng nào có thể tương tác với

chức năng nào


Use Case: chức năng Actor: Tác Nhân Association: mối kết hợp

Actor Use Case

System

Relationship


Actor (Tác Nhân): là một người hoặc một vật nào đó tương tác với hệ thống, sử dụng hệ thống. Một tác nhân sẽ có một tên, và cái tên này cần phải phản ánh lại vai trò của tác nhân. Một tác nhân giao tiếp với hệ thống bằng cách gửi hoặc là nhận thông điệp

GiangVien

Sinhvien

Hê thông thanh toán Hê thông

Bao mật

Xác định tác nhân

Ai sử dụng chưc năng chính cua hê thông?Ai se duy trì, quan lý và giư cho hê thông

làm viêc?Nhưng phần mềm/hê thông khác mà hê

thông cần tương tác? Nhưng hê thông máy tính khác Nhưng ưng dụng khác chạy trên cùng môt máy

tính (i.e. X client/server) Chu ý: tránh nhầm lẫn giưa sư tương tác

(interaction) với đầu vào (input)

99Use Case Modeling

Xác định tác nhân

Là ai Sử dụng hê thông? Cài đăt hê thông? Khởi đông hê thông? Duy trì hê thông? Thoát hê thông? Thu thập thông tin tư hê thông? Cung cấp thông tin cho hê thông?

Chuyên gì xay ra tại môt thời điểm định trước?

100Use Case Modeling

Thời gian?

Xem thời gian như là môt tác nhânTác nhân thời gian co thể kích hoạt môt

Use Case



Use Case (chức năng): Use Case là sự mô hình hoá những chức năng của hệ thống từ hướng nhìn của người sử dụng

Mỗi Use Case là một tập hợp của các hành động được thực hiện bởi một tác nhân tác động vào hệ thống để tạo ra một kết quả có thể quan sát được, tức là một giá trị đến với một tác nhân cụ thể.

Đăng ký học phần

Xem điểm Nhậpđiểm

Đăc tính cua use case

Phai luôn được bắt đầu bởi môt actor. Use case cung cấp giá trị cho môt actor. Giá trị này

không đoi hỏi phai luôn luôn nổi bật nhưng no phai co thể nhận thấy được.

Use case phai là môt đơn vị đầy đu. Thường hay sai lầm chia use case thành các use case nhỏ hơn và khi thưc thi 1 use case này thì cần dùng đên các use case khác. Môt use case se không đầy đu nêu không tạo ra được giá trị cuôi dù cho để co giá trị cuôi này phai xay ra nhiều giao tiêp.

PTTKHT bang UML - BM HTTT103

Tìm kiêm Use Case

Với mỗi tác nhân, ta xác định: Nhưng dịch vụ nào tác nhân yêu cầu tư hê

thông? Hê thông co lưu trư thông tin không?

Đoc, tạo, huy, hiêu chinh, lưu trư thông tin Liêu tác nhân cần được thông báo về các sư

kiên trong hê thông, hay tác nhân cần thông báo cho hê thông về viêc gì đo không?

Công viêc thường ngày cua tác nhân co đơn gian không?

Không nên chi tập trung vào hê thông hiên tại


Môi quan hê giưa các Use Case

Association (mối kết hợp): Là sự kết hợp giữa những Actor và Use case.

Type of relationship Uses Relationship – Quan hệ sử dụng Extends Use Case Relationship – Quan hệ mở rộng Generalization relationship – Quan hệ tạo nhóm

Relationship

Khi một nhóm các Use Case cùng chung một hành vi nào đó thì hành vi này có thể được tách riêng ra thành một Use Case riêng biệt và nó có thể được sử dụng bởi các Use Case kia.

Quan hê sử dụng giữa các Use Case

OpenIncident

AllocateResources

HelpDispatcher«include»

«include»

Generalization

<<include>> & <<extend>>

Là 2 môi quan hê giưa 2 use case với nhau Include: Nếu trong quá trình thực hiện use case A

Người dùng luôn luôn/hầu như đều phải thực hiện use case B. A <<include >>B

A Binclude

<<include>> & <<extend>>

Extend: nêu trong quá trình thưc hiên use case A người dùng co thể /lâu lâu phai thưc hiên use case B

B<<extend>>A

A Bextend

Example: Using <<include>>

Lược đồ UC cua hê thông đăt chỗ trước


Credit System

Cancel Reservation

Purchase Ticket

Customer Service Representative

Change Reservation

Check Credit

<<include>>

<<extend>>

Reserve Hotel Room

Customer

Reserve Rental Car

Đong goi UC


Exercise

Start by listing a sequence of steps a user might take in order to complete an action. For example a user placing an order with a sales company might follow these steps. Browse catalog and select items. Call sales representative. Supply shipping information. Supply payment information. Receive conformation number from salesperson.

Exercise

USE CASES VÀ KỊCH BẢN SỬ DỤNG (USE CASES AND USAGE SCENARIOS)

Use case là môt tập hợp các kịch ban (scenario) thông thường co liên quan nhau.

Môt kịch ban được goi là môt tiên trình chuẩn (normal course) cua các sư kiên nôi tiêp nhau tạo nên use case, no cung được goi là tiên trình chính (main course), tiên trình cơ sở (basic course), luồng chuân (normal flow), hay là “đường yên lành” (happy path). Tiên trình chuân được mô ta bằng cách liêt kê

môt dãy đôi thoại (dialogue elements) hoăc dãy tương tác giưa actor và hê thông.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

115

Mẫu mô ta UC Tên (Name)

Tên cua UC, co nghĩa gần với mục đích người sử dụng

Các tác nhân (Actors) Mục đích (Goals) Các yêu cầu (Requirements) (tùy chon)

Cung cấp kha năng lần vêt Điêu kiên tiên quyết (Pre-Conditions)

Các điều kiên cần thiêt cần phai co trước khi thưc hiên mô UC

Co thể là môt UC khác (không giông với quan hê <<include>>)


Biểu mẫu mô ta UC

Mô tả (Description) Mô ta các tiên trình cơ ban hoăc bình thường cua hê thông nêu hê

thông hoạt đông như dư định (moi thư điều đung) Điêu kiên sau (Post-conditions)

Trạng thái cua hê thông sau khi UC được thưc thi Các giá trị đưa ra cho các tác nhân Phân biêt giưa biên thể và các ngoại lê

Các biến thể (Variations) Các điều kiên dẫn tới viêc phân nhánh Mô ta các tiên trình thay thê hoăc là tên mở rông cua UC

Các ngoại lê (Exceptions) Nhưng điều kiên không mong đợi dẫn tới viêc phân nhánh (xung đôt

với điều kiên sau) Mô ta các tiên trình thay thê Ví dụ


Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

118

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

119

Use case cua hê thông theo dõi hoa chất

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

120

Mô ta Use case “request a chemical”

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

121


Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

122


Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

123


Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

124

Bài tập

Phát biểu vấn đềDẫn nhập (Background)Xác định mục tiêuXác định yêu cầuXác định StackHolderCác kỹ thuật thu nhận yêu cầuCác kỹ thuật phân tích yêu cầuBài tập

Documents

ÔN TẬP GIỮA KỲ