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

Chapter 3: Thu thập yêu cầu Chapter 3: Thu thập yêu cầu

Requirements Elicitation Or Requirement gathering

BM HTTT Khoa CNTT - HUI 1

Nội dung Nội dung

Thu thập yêu cầu (Requirement

elicitation) là gì?

Các kỹ thuật thu thập yêu cầu Chọn lựa kỹ thuật thu thập yêu cầu Quy tắc nghiệp vụ và chính sách Quản lý mối quan hệ khách hàng

BM HTTT Khoa CNTT - HUI 2

A major aspect of

requirements engineering is

the elicitation of

requirements from the

customer.

It’s not just a simple matter of

writing down what the

customer says he wants !!!

BM HTTT Khoa CNTT - HUI 3

Requirement elicitation Requirement elicitation

Elicitation là quá trình xác định yêu cầu và làm giảm sự khác biệt giữa các nhóm có liên quan để rút ra các yêu cầu đáp ứng được nhu cầu của tổ chức hay dự án trong khi vẫn giữ được các ràng buộc.

Có rất nhiều kỹ thuâṭ elicitation khác

nhau

BM HTTT Khoa CNTT - HUI 4

Phân biệt giữa elicitation và Phân biệt giữa elicitation và analysis analysis Elicitation là sự tương tác với

stakeholders để nắm bắt được nhu cầu của họ.

Analysis là tinh chỉnh (refinement) nhu cầu của stakeholder thành các đặc tả sản phẩm chính thức.

BM HTTT Khoa CNTT - HUI 5

Tầm quan trọng Tầm quan trọng

Requirements elicitation is perhaps the most difficult, most critical, most error-prone, and most communication- intensive aspect of software development.

Elicitation chỉ có thể thành công thông

qua mối quan hệ hợp tác giữa customer và đội development .

BM HTTT Khoa CNTT - HUI 6

Mô hình song song của quy trình yêu Mô hình song song của quy trình yêu cầucầu

BM HTTT Khoa CNTT - HUI 7

Why is it difficult to elicit Why is it difficult to elicit requirements? requirements?

Customers and users often do not understand how software design and development works, and cannot specify their own software requirements in a way that works for developers.

Software developers often do not understand the problems and needs of customers and users well enough to specify the requirements on their behalf.

BM HTTT Khoa CNTT - HUI 8

Vấn đề về người dùng và khách hàng

Người dùng không hiểu họ muốn gì Người dùng không tuân theo một bộ yêu cầu

đã được tài liệu hóa

Người dùng nhất định đòi hỏi các yêu cầu

mới sau khi chi phí và kế hoạch phát triển đã được hoạch định xong.

Mức độ giao tiếp với người dùng là thấp Người dùng thường không tham gia các đợt

thẩm định hoặc không thể tham gia.

Người dùng không hiểu kỹ thuật Người dùng không hiểu quy trình phát triển.

BM HTTT Khoa CNTT - HUI 9

Các hoạt động của yêu cầu Các hoạt động của yêu cầu

BM HTTT Khoa CNTT - HUI 10

Trước khi thu thập yêu cầu Trước khi thu thập yêu cầu

 Đã viết “vision and scope”  Vẽ lược đồ ngữ cảnh (context diagram)  Xác định stakeholder  Xác định người dùng và đại diện người dùng

BM HTTT Khoa CNTT - HUI 11

Lược đồ ngữ cảnh Lược đồ ngữ cảnh

 Phạm vi (scope) dùng để xác định đường biên (boundary) và các mối nối kết giữa hệ thống đang phát triển và mọi thứ khác bên ngoài.

 Lược đồ ngữ cảnh được dùng để minh họa đường

biên này.

BM HTTT Khoa CNTT - HUI 12

Lược đồ ngữ cảnh Lược đồ ngữ cảnh

 Là mức 0 (top level) của lược đồ dòng dữ liệu (data flow diagram) theo cách phân tích hướng cấu trúc  Được dùng rộng rãi cho bất kỳ phương pháp phát

triển nào

 Có thể nằm trong tài liệu vision, trong phục vụ đặc

tả yêu cầu (SRS)

BM HTTT Khoa CNTT - HUI 13

Lược đồ ngữ cảnh Lược đồ ngữ cảnh

BM HTTT Khoa CNTT - HUI 14

Keeping Scope in Focus Keeping Scope in Focus

 Scope change isn’t a bad thing if it helps you steer the project toward satisfying evolving customer needs

 Khi có ai đó kiến nghị 1 yêu cầu mới thì RA phải làm

gì??

 Cần xem xét yêu cầu mới có nằm trong scope hay

không??

 Nếu yêu cầu kiến nghị nằm trong scope thì có thể hợp nhất yêu cầu mới vào dự án nếu có độ ưu tiên cao so với yêu cầu hiện cócó thể phải trì hoãn hay hủy bỏ các yêu cầu hiện tại

BM HTTT Khoa CNTT - HUI 15

Keeping Scope in Focus Keeping Scope in Focus

 Nếu yêu cầu kiến nghị nằm ngoài scope thì có thể

có 1 trong các phương án sau: ◦ Nên đưa vào phiên bản sau hay trong dự án khác. ◦ Scope của dự án có thể thay đổi để đáp ứng yêu cầu mới  cần có phản hồi từ phía người dùng và cần cập nhật lại tài liệu vision and scope (nếu đã phê duyệt thì cần giám sát mọi thay đổi)

◦ Khi phạm vi dự án tăng, thường phải thỏa thuận lại ngân sách(budget), tài nguyên (resource), thời gian (schedule)

BM HTTT Khoa CNTT - HUI 16

Xác định StakeHolder Xác định StakeHolder

 Identify the different classes of users for your

product

 Identify source of user requeriments  Select and work with individual who represent each

user class and other stakeholder groups

 Agree on who the requirements decision makers are

for you project

 It’s not enough simply to ask a few customers what they want and then start coding. If the developers build exactly what customers initially request, they’ll probably have to build it again because customers often don’t know what they really need.

BM HTTT Khoa CNTT - HUI 17

Xác định StakeHolder Xác định StakeHolder

 Những tính chất mà người dùng đưa ra lúc đầu thường không đủ để trở thành chức năng của hệ thống.

 Để có cái nhìn chính xác hơn nhu cầu người dùng, RA phải tập hợp các yêu cầu người dùng, phân tích và xác định chỉ nên xây dựng cái gì để người dùng làm tốt được công việc của họ.

BM HTTT Khoa CNTT - HUI 18

Phân loại StakeHolder Phân loại StakeHolder

1. Customers (người tài trợ dự án hay mua sản

phẩm)

2. Users (người tương tác trực tiếp hay gián tiếp sản

phẩm)

3. Requiremements analysts (người viết yêu cầu và

làm việc với đội phát triển phần mềm)

4. Developers (người thiết kế, thực thi và bảo trì sản

phẩm)

5. Testers (người kiểm tra xem sản phẩm có thực thi

như mong muốn)

BM HTTT Khoa CNTT - HUI 19

Phân loại StakeHolder Phân loại StakeHolder

1. Documentation writers (người tạo ra sổ tay người

dùng, hệ thống trợ giúp)

2. Project managers (người lập kế hoạch cho dự án,

quản lý đội phát triển phần mềm)

3. Legal staff (người bảo đảm sản phẩm phù hợp với

luật và quy chế)

4. Manaufacturing people (người phải xây dựng sản

phẩm có chứa phần mềm)

5. Sales, marketing, field support, help desk, và những người khác sẽ làm việc với sản phẩm và khách hàng.

BM HTTT Khoa CNTT - HUI 20

Các kỹ thuật thu thập yêu cầu Các kỹ thuật thu thập yêu cầu

Document Sampling Interviewing Survey and observation Questionaires Workshop and Brainstorming JAD (Joint Application Development)

sessions

Ba kỹ thuật phổ biến nhất là Document

sampling, interviewing và questionaires

BM HTTT Khoa CNTT - HUI 21

Các kỹ thuật thu thập yêu cầu Các kỹ thuật thu thập yêu cầu

BM HTTT Khoa CNTT - HUI 22

Các kỹ thuật thu thập yêu cầu Các kỹ thuật thu thập yêu cầu

Assignment 12: Document Sampling

◦Nhóm???

Assignment 13: Questionaires

BM HTTT Khoa CNTT - HUI 23

Interviewing Interviewing

 Là kỹ thuật trực tiếp và đơn giản  Phỏng vấn để thu nhận từ các cá thể thao tác và

các vấn đề trong hệ thống hiện hành, chính sách, nhu cầu mong muốn trong hệ thống mới.  Câu hỏi context-free có thể giúp hoàn thành các

phỏng vấn bias-free interviews

 Tập hợp lại 1 số nhu cầu chung sẽ tạo

“requirements repository”để dùng trong suốt dự án

 Questionnaire không thể thay thế cho interview.

BM HTTT Khoa CNTT - HUI 24

•

Interviews Interviews Interview cá nhân hay nhóm các người dùng là nguồn thu thập yêu cầu kiều truyến thống cho cả sản phẩm thương mại cũng như các hệ thống thông tin.

• Tìm hiểu cách nghĩ của người dùng khi họ trình bày các yêu cầu, rút ra các quyết định có tính logic của người dùng. Để mô tả quá trình đưa ra các quyết định logic có thể dùng flowchart và cây quyết định (decision tree) bảo đảm mọi người hiểu được tại sao hệ thống phải thực hiện các chức năng này.

• Đôi khi các yêu cầu của người dùng phản ánh các quy trình nghiệp vụ đã lỗi thời hay không hiệu quả nữa và không nên đưa vào hệ thống mới.

BM HTTT Khoa CNTT - HUI 25

Một số hướng dẫn để phỏng vấn Một số hướng dẫn để phỏng vấn thành công thành công

BM HTTT Khoa CNTT - HUI 26

Interview: Context free question Interview: Context free question

Là câu hỏi có thể dùng cho bất kỳ dự

án nào đang khảo sát.

Là các câu hỏi chung về bản chất của dự án và môi trường mà sản phẩm sẽ được dùng.

Được dùng trong mỗi giai đoạn khác

nhau của cuộc phỏng vấn.

BM HTTT Khoa CNTT - HUI 27

Các dạng câu hỏi context free Các dạng câu hỏi context free  Opening Questions: khi bắt đầu phỏng vấn, câu hỏi context free sẽ giúp khởi đầu cuộc phỏng vấn và vượt qua được các lúng túng ban đầu.

 Redirection: có thể được dùng để chuyển hướng phỏng vấn khi nội dung cuộc đối thoại ra ngoài chủ đề hay quá sâu không cần thiết, đưa cuộc đối thoại về lại vị trí trung lập để hướng đến chủ đề mong muốn.

 Closing: dùng để kết thúc cuộc phỏng vấn “Is there anything else you would like to tell me?”  cho người được phỏng vấn (interviewee) cơ hội được chủ động và chia xẻ̃ các thông tin khác.

BM HTTT Khoa CNTT - HUI 28

Các dạng câu hỏi Các dạng câu hỏi

BM HTTT Khoa CNTT - HUI 29

Làm thế nào đề thực hiện interview Làm thế nào đề thực hiện interview

 Phải chuẩn bị một danh sách các câu hỏi context free trước khi phỏng vấn. Có thể đặt cùng 1 hay 2 câu hỏi cho người được phỏng vấn (interviewee) để tìm ra điểm khác biệt.

 Thông qua câu hỏi context free để giúp người

tham gia phỏng vấn có hiểu biết chung

 Không bận tâm vào câu trả lời “right/wrong”. Nhiều câu hỏi dùng gây ấn tượng hơn là để thu nhận dữ liệu, dùng để thu thập chi tiết hơn yêu cầu đang khảo sát.

BM HTTT Khoa CNTT - HUI 30

Các chiến lược phỏng vấn Các chiến lược phỏng vấn

Top-down: bắt đầu bằng các câu hỏi tổng quát, tiếp đến là các câu hỏi cụ thể

Bottom-up: ngược lại

BM HTTT Khoa CNTT - HUI 31

Interview: Show time Interview: Show time

Nên dành thời gian để: Establish Customer or User Profile Assessing the Problem Understanding the User Environment Recap the Understanding Analyst’s Inputs on Customer’s

Problems

Assessing Your Solution (if

applicable)

BM HTTT Khoa CNTT - HUI 32

Questionaries Questionaries

Thường dùng khi cần thu thập thông tin

và ý kiến từ số đông.

BM HTTT Khoa CNTT - HUI 33

So sánh giữa Questionaries và So sánh giữa Questionaries và Interview Interview

BM HTTT Khoa CNTT - HUI 34

Chọn người tham gia phiếu điều Chọn người tham gia phiếu điều tratra  Chọn người đại diện cho mỗi nhóm  Không phải ai nhận phiếu điều tra cũng đều hoàn tất nó, trung bình chỉ thu lại được 30- 50% phiếu điều tra bằng giấy hay email, chỉ 5 – 30% phiếu điều tra qua Web

BM HTTT Khoa CNTT - HUI 35

Thiết kế phiếu điều tra Thiết kế phiếu điều tra

 Thường dùng câu hỏi dạng closed-ended  Câu hỏi phải được viết rõ ràng và không nên chừa quá nhiều khoảng trống dễ gây hiểu nhầm

BM HTTT Khoa CNTT - HUI 36

Thiết kế phiếu điều tra Thiết kế phiếu điều tra

 Hai dạng câu hỏi:

 Hướng ý kiến (opinion): thường yêu cầu người trả lời phải cho biết mức độ mà họ đồng tình hay phản đối.

 Hướng số liệu (fact – oriented): câu trả lời là

một giá trị cụ thể

BM HTTT Khoa CNTT - HUI 37

Thiết kế phiếu điều tra Thiết kế phiếu điều tra

 Phải hiểu rõ thông tin thu thập được từ nhiều điều tra sẽ được phân tích và dùng như thế nào, tránh tình trạng phân phối điều tra xong rồi mới phát hiện điều tra có vấn đề.

 Các câu hỏi phải tương đối đồng nhất về định dạng, người trả lời không cần đọc hướng dẫn mỗi câu hỏi trước khi trả lời

 Nên để các đồng nghiệp xem lại phiếu điều

tra và test lại trước khi phân phối

BM HTTT Khoa CNTT - HUI 38

Giám sát phiếu điều tra Giám sát phiếu điều tra

 Kỹ thuật chung để cải thiện tỷ lệ tham gia của

người trả lời:  Giải thích rõ ràng tại sao cần thực hiện phiếu điều tra

và tại sao người trả lời được chọn.

 Xác định ngày phiếu điều tra cần được thu hồi  Cho 1 khích lệ để người trả lời hoàn tất phiếu điều

tra.

 Một số kỹ thuật khác:

 Giao tận tay phiếu điều tra  Gặp riêng những ai không trả lại phiếu điều tra sau 1

hay 2 tuần

 Cử giám sát viên cho từng nhóm người trả lời

BM HTTT Khoa CNTT - HUI 39

Technique: Requirements Technique: Requirements Workshop Workshop

 Có thể là kỹ thuật năng động nhất để thu

thập yêu cầu.

 Tập hợp tất cả các stakeholder chính cùng với nhau trong 1 giai đoạn, tuy ngắn nhưng rất tập trung.

 Sử dụng người trợ giúp (facilitator) có kinh nghiệm từ bên ngoài trong quản lý yêu cầu có thể bảo đảm cho sự thành công của workshop.

 Brainstorming là phần quan trọng nhất của workshop.

BM HTTT Khoa CNTT - HUI 40

Preparing for the workshop Preparing for the workshop

Bảo đảm có sự tham gia của các

stakeholder phù hợp

Công tác hậu cần (Logistics) ◦Cố và tránh luật Murphy’s law ◦Bao gồm cả du lịch, giải trí và ăn nhẹ buổi

chiều (“afternoon sugar filled snacks.”) Tài liệu đầu buổi hội thảo (Warm-up

materials) ◦Thông tin của buổi hội thảo ◦Out-of-box thinking preparation

BM HTTT Khoa CNTT - HUI 41

Trong lúc Workshop Trong lúc Workshop • Để dễ dàng giao tiếp, nên sử dụng từ ngữ của miền ứng dụng thay vì bắt khách hàng hiểu các thuật ngữ máy tính. • Nên đưa các thuật ngữ nghiệp vụ vào danh sách các từ khó (glossary) để các thành viên cùng dùng chung các định nghĩa

• Customer nên hiểu là việc thảo luận về chức năng không hẳn là 1 nhiệm vụ phải có trong sản phẩm.

BM HTTT Khoa CNTT - HUI 42

Trong lúc workshop Trong lúc workshop

• Kỹ năng để dẫn dắt các cuộc thảo luận phân tích yêu cầu phải có được từ kinh nghiệm, tập huấn phỏng vấn, hỗ trợ nhóm, giải quyết xung đột, ..

• Người phân tích phải khảo sát cẩn thận (probe) nhu cầu thực sự của khách từ 1 loạt các yêu cầu mà khách hàng đề ra. – Hỏi "why" nhiều lần – Hỏi các câu hỏi mở (open-ended question) để giúp hiểu được quy trình nghiệp vụ hiện hành của người dùng và để thấy hệ thống mới có thễ cải thiện việc thực thi như thế nào.

– Điều tra tìm hiểu (Inquire) những thay đổi xảy ra cho người

dùng khi hệ thống mới được đưa vào sử dụng.

– Thử đóng vai trò người tập sự (apprentice) học hỏi từ người

dùng chính.

BM HTTT Khoa CNTT - HUI 43

Vai trò của requirement analyst Vai trò của requirement analyst

• Người phân tích yêu cầu (Requirements analyst) thường tham gia các hội thảo phân tích yêu cầu. • Facilitator đóng vai trò chính trong việc lên kế hoạch hội thảo, chọn người tham dự, dẫn dắt người tham dự để kết thúc thành công hội thảo. • Khi đội bắt đầu các phương pháp mới để phân tích yêu cầu nên có một facilitator ngoài đội hướng dẫn các workshop khởi đầu, nhờ đó các analyst có thể góp phần nhiều hơn vào các cuộc thảo luận.

BM HTTT Khoa CNTT - HUI 44

Facilitator Role of the Facilitator Role of the

 Xác lập 1 phong cách chuyên nghiệp và mục tiêu rõ

ràng cho cuộc họp

 Bắt đầu và kết thúc cuộc họp đúng giờ  Xác lập và nhấn mạnh các quy tắc của cuộc họp.  Giới thiệu mục tiêu và lịch trình của cuộc họp  Điếu hành cuộc họp và giữ cho mọi người luôn quan

tâm theo dõi

 Tạo điều kiện khi cần biểu quyết nhất trí nhưng tránh

tham gia vào.

 Bảo đảm mọi stakeholder đều có quyền phát biểu góp ý

trong cuộc họp

 Kiểm soát các hành vi gây rối và không phù hợp.

BM HTTT Khoa CNTT - HUI 45

Workshop Agenda Workshop Agenda

Xây dựng lịch trình (agenda) trước cho buổi hội thảo và công bố nó cùng với các tài liệu chuẩn bị trước của workshop.

Giữ ổn định cho buổi hội thảo rất quan trọng, cố gắng theo đúng lịch trình, nhưng cũng không nên tuân theo nó quá cứng nhắc, nhất là khi đang có thảo luận sôi nổi.

Đặt ăn trưa (light working lunch).

BM HTTT Khoa CNTT - HUI 46

Running the Workshop Running the Workshop

Cư xử lịch thiệp và vui vẻ

◦Không nên “attack” thành viên khác. ◦Không nên diễn thuyết nhiều quá. ◦Đừng quay lại muộn sau khi giải lao

Thẻ phạt (Workshop tickets)

◦Cấp cho mỗi stakeholder một trong 3 loại thẻ phạt sau: đi muộn, gian lận (“cheap shot”) , phát biểu dài dòng (“soap box”)

◦Facilitator cũng có thể bị nhận thẻ phạt. ◦

BM HTTT Khoa CNTT - HUI 47

Một số nguyên tắc cơ bản để Một số nguyên tắc cơ bản để workshop thành công workshop thành công Establish ground rules Stay in scope Use parking lots to capture items

for later consideration Timebox discussions Keep the team small and include

the right participants Keep everyone engaged

BM HTTT Khoa CNTT - HUI 48

Workshop Problems and Workshop Problems and Suggestions (đề nghị) Suggestions (đề nghị)

Problems

Suggestions

Quản lý thời gian

◦ Khó bắt đầu lại sau nghỉ giải lao và

Facilitator phải theo dõi thời gian nghỉ giải lao và phạt bất kỳ ai đến muộn,

ăn trưa.

◦ Stakeholders quan trọng thường

Mỗi người chỉ được 5 phút để phát biểu.

quay lại muộn.

Giành quyền phát biểu quá lâu,

Facilitator khuyến khích mọi người sử dụng 5 phút được phát biểu và ủng hộ các sáng kiến.

Thiều dữ liệu từ stakeholders

Dùng vé phạt (“Cheap Shot Tickets”) và buộc trả chi phí

Phát biểu tiêu cực, hành động nhỏ nhen, gây gỗ

Mệt mỏi thiếu sinh lực sau khi ăn trưa

Nên tổ chức ăn nhẹ buổi trưa, giải lao buổi chiều, sắp xếp lại chỗ ngồi BM HTTT Khoa CNTT - HUI

Product Position Statement Product Position Statement

For [target end user] Who wants/needs [compelling

reason to buy]

The [product name] is a [product

category]

That provides [key benefit]. Unlike [main competitor], The [product name] [key

differentiation]

BM HTTT Khoa CNTT - HUI 50

Brainstorming Sessions Brainstorming Sessions

• Thường được dùng để phân tích tìm các yêu cầu ban đầu của stakeholder đối với sản phẩm. Phương pháp này được thực hiện với nhiều stakeholders hay customers và các phiên giao tiếp này thường được dẫn dắt bởi 1 facilitators có kinh nghiệm, mỗi phiên (session) thường kéo dài tối đa 1 hay 2 ngày.

• Mục tiêu của brainstorming session là đưa ra các ý tưởng mới hay các tính năng của sản phẩm trong 1 thời gian rất ngắn.

BM HTTT Khoa CNTT - HUI 51

Brainstorming Sessions Brainstorming Sessions

Khi xác định ý tưởng, điều quan trọng

là phải tránh xung đột, e.g., một thành viên chê bài ý tưởng của người khác.

Nếu có thành viên lâu năm (senior) tham gia session thì điều quan trọng là giữ cho họ không được đe dọa các thành viên ít kinh nghiệm hơn họ.

BM HTTT Khoa CNTT - HUI 52

Vai trò của facilitator Vai trò của facilitator

Vai trò của facilitator rất quan trọng, quyết định session có thành công hay không?

BM HTTT Khoa CNTT - HUI 53

Brainstorming Brainstorming

Mục tiêu và thời gian của

brainstorming session cần phải được thỏa thuận trước bởi tất cả các thành viên, tốt nhất là ngay trước khi bắt đầu session.

Session nên bắt đầu với việc tự do

đưa ra các ý kiến, tạo thành 1 tập hợp các kiến nghị về sản phẩm. Nên dùng “sticky notes” và dán vào bảng.

BM HTTT Khoa CNTT - HUI 54

Các giai đoạn của Brainstorming Các giai đoạn của Brainstorming Session Session

BM HTTT Khoa CNTT - HUI 55

Tabular Elicitation Technique Tabular Elicitation Technique

• Việc dùng bảng có thể giúp nắm bắt

được yêu cầu của stakeholder rõ ràng và chặt chẽ hơn.

• Có 2 loại bảng hay được dùng:

– Decision table – State table

BM HTTT Khoa CNTT - HUI 56

Decision table Decision table

• Bảng quyết định (Decision table)

thông dụng nhất khi: – Tập các điều kiện là rời rạc, có thể được

xác định bằng “yes” hay “no,”

– Hành động sẽ thực hiện khi các điều kiện

thỏa mãn

– Tập các rule khi tập các điều kiên là duy nhất và tương ứng với mỗi rule là 1 hành động.

BM HTTT Khoa CNTT - HUI 57

Decision table Decision table

Mỗi hàng biều diễn một condition, mỗi cột biểu diễn 1 rule, i.e,. Một điều kiện và 1 tập các hành động tương ứng. Khi cần phân tích bản phác thảo các yêu cầu lúc đầu của stakeholder thì bảng quyết định được dùng rất hiệu quả để nắm bắt các quy tắc nghiệp vụ. (business rule)

BM HTTT Khoa CNTT - HUI 58

Ví dụ bảng quyết định Ví dụ bảng quyết định

BM HTTT Khoa CNTT - HUI 59

State tables State tables • Được dùng khi đối tượng đang khảo sát có thể có các trạng thái khác nhau ở các thời điểm khác nhau và các sự kiện đơn giản nhưng rõ ràng nào đó có thễ kích khởi việc đổi từ trạng thái này sang trạng thái khác.

• State machine: là 1 đối tượng mà việc chuyển đổi trạng thái chỉ dựa vào các sự kiện rời rạc và số trạng thái của đối tượng đã biết trước.

• Ví dụ: bảng người nộp thuế (taxpayer) không phải là bảng trạng thái vì chỉ có 1 trạng thái duy nhất là “about to pay taxes.”

BM HTTT Khoa CNTT - HUI 60

State table State table

State tables chỉ ra hành vi của state machine, thường có 1 trạng thái khởi đầu và một tập các trạng thái mà đối tượng sẽ trải qua và cuối cùng là trạng thái exit thành công hay 1 trong các trạng thái “error”. Mỗi lần thay đổi trạng thái đều có liên quan đến 1 hay nhiều sự kiện (event)

BM HTTT Khoa CNTT - HUI 61

Button

Ví dụ Ví dụ

BM HTTT Khoa CNTT - HUI 62

Phương pháp điều tra (survey)- Phương pháp điều tra (survey)- Ethnographic Techniques Ethnographic Techniques • Một số phương pháp điều tra được dùng rất nhiều để đánh giá các yêu cầu thị trường, mối quan tâm về sản phẩm.

• Khi số lượng khách hàng tương đồi lớn, có thể thực hiện thống kê trên kết quả điều tra đề đo lường mức độ quan tâm của khách hàng đối với các tính năng của sản phẩm.

• Một trong các phương pháp điều tra

thông dụng nhất để phân tích mối quan tâm của khách hàng là Kano modeling.

BM HTTT Khoa CNTT - HUI 63

Phương pháp Kano modeling Phương pháp Kano modeling Cung cấp ba biến để đo lường mối quan

tâm của khách hàng: • One-dimensional quality • Expected quality • Attractive quality.

BM HTTT Khoa CNTT - HUI 64

Phương pháp Kano modeling Phương pháp Kano modeling

One-dimensional (hay linear quality)

được áp dụng ở sản phẩm có giá trị tăng tuyến tính cùng với 1 số tính năng nào đó. Ví dụ tính tiết kiệm điện năng của tủ lạnh, nếu tính năng này càng hiệu quả thì khả năng khách hàng đặt mua càng nhiều.

BM HTTT Khoa CNTT - HUI 65

Phương pháp Kano modeling Phương pháp Kano modeling Expected quality là tính năng bắt buộc phải có đối với sản phẩm nào thành công trên thị trường.

Attractive quality là tính năng không được mong đợi nhưng bổ sung vào yếu tố tâm lý (emotional appeal) của sản phẩm. Ví dụ camera trong mobile là attractive quality trong nhiều năm trước nhưng bây giờ là expected quality trong hầu hết các thị trường.

BM HTTT Khoa CNTT - HUI 66

Phương pháp Kano modeling Phương pháp Kano modeling

Một đo lường khác là yêu tố văn hóa. Ví dụ, ở Mỹ hầu hết các khách hàng đều muốn mua xe ô tô có số tự động, trong khi đó ở châu Âu thích mua xe sang số tay.

Kano modeling được chấp nhận rộng

rãi;một số công cụ quản lý requirements engineering có sẵn chức năng Kano analysis.

BM HTTT Khoa CNTT - HUI 67

Kano model

BM HTTT Khoa CNTT - HUI 68

Joint Application Development Joint Application Development (JAD) (JAD)

BM HTTT Khoa CNTT - HUI 69

Joint Application Development Joint Application Development (JAD) (JAD)

JAD được như 1 kỹ thuật để phát triển yêu cầu của 1 hệ thống và trong các giai đoạn đầu của dự án phần mềm.

Mục đích: tập hợp MIS và người dùng cuối trong cơ chế của 1 workshop, để cùng thống nhất (consensus) với nhau các yêu cầu của hệ thống.



BM HTTT Khoa CNTT - HUI 70

JAD và phương pháp cũ JAD và phương pháp cũ

Bằng cách kết hợp workshop và nhấn (spirit of thần cộng

tác

tinh mạnh partnership)

Bằng cách kết hợp công nghệ và nhu cầu nghiệp vụ trong 1 quy trình thống nhất, lặp lại và hiệu quả

JAD giúp thu thập yêu cầu hệ thống nhanh hơn, chính xác hơn các phương pháp cổ điển.

giảm 1 cách đáng kể thời gian, chi phí và

lỗi cho dự án.

BM HTTT Khoa CNTT - HUI 71

Dự án nào nên dùng JAD Dự án nào nên dùng JAD

Liên quan đến nhiều nhóm người

dùng khác nhau

Rất quan trọng đến sự thành công

trong tương lai của tổ chức.

Là dự án mới của tổ chức Có trở ngại trong dự án cũ hay mối quan hệ giữa hệ thống và tổ chức

BM HTTT Khoa CNTT - HUI 72

Ai tham dự JAD? Ai tham dự JAD?

Executive Sponsor Facilitator User ( từ 3 – 5) IT Representative Scribe ( 1 hay 2) Observer ( 2 hay 3)

BM HTTT Khoa CNTT - HUI 73

BM HTTT Khoa CNTT - HUI 74

Executive Sponsor Executive Sponsor

Là người của tổ chức khách hàng và có quyền quyết định tối cao về dự án (CEO, người lãnh đạo dự án)

Facilitator làm việc với sponsor để khởi động dự án, nhưng sponsor mới là người quyết định chính, không phải là facilitator.

BM HTTT Khoa CNTT - HUI 75

Trách nhiệm của Executive sponsor Trách nhiệm của Executive sponsor

Nhận trách nhiệm cao nhất về các chức năng

của hệ thống.

Giải quyết các xung đột về chính sách bằng

cách đưa ra các quyết định cuối

Công bố kết quả của quy trình JAD. Xác lập vision cho dự án Bảo đảm cho đội dự án tiếp cận và làm việc

được với các chuyên gia nghiệp vụ.

Tạo ra sự hợp tác và hỗ trợ của khách hàng

đối với đội dự án

BM HTTT Khoa CNTT - HUI 76

Vai trò của executive sponsor Vai trò của executive sponsor Làm cho khách hàng tin tưởng vào quy

trình JAD

Trong lúc định hướng JAD, sponsor quan tâm đến cả đội, biểu lộ thái độ hợp tác và hỗ trợ.

Sponsor cũng tỏ ra tin cậy vào facilitator, giảm thiêu được sự đối kháng ban đầu của đại diện khách hàng.

Sponsor chỉ là thành viên của JAD và thường không tham dự vào các cuộc họp JAD, chỉ cần ghé qua để biểu lộ sự quan tâm hợp tác.

BM HTTT Khoa CNTT - HUI 77

Vai trò của các thành viên JAD Vai trò của các thành viên JAD

Vai trò của facilitator Vai trò của scribe Assignment??

BM HTTT Khoa CNTT - HUI 78

JAD Critical Success Factors JAD Critical Success Factors

Tránh phạm vi dự án bị phình ra

(creep).

Nhận biết sớm các vấn đề của tổ

chức hay những rắc rối chính trị.

Bảo đảm tất cả thành viên tham gia dự án và các nhà quản lý chính đều chấp nhận các kỹ thuật của JAD.

Chia các dự án lớn thành các phần có

thể quản lý được.

BM HTTT Khoa CNTT - HUI 79

Chọn lựa kỹ thuật thu thập yêu Chọn lựa kỹ thuật thu thập yêu cầucầu

BM HTTT Khoa CNTT - HUI 80

Chọn phương pháp/ kỹ thuật Chọn phương pháp/ kỹ thuật thu thập yêu cầu thu thập yêu cầu

Có nhiều phương pháp luận

(methodology) và kỹ thuật (method) để thu thập yêu cầu,

Một số nhà phân tích nghĩ rằng chỉ cần dùng 1 phương pháp hay 1 kỹ thuật là đủ để áp dụng cho mọi hoàn cảnh.

BM HTTT Khoa CNTT - HUI 81

Chọn phương pháp/ kỹ thuật Chọn phương pháp/ kỹ thuật thu thập yêu cầu thu thập yêu cầu

Nhà phân tích chọn 1 kỹ thuật thu thập nào đó là

do tổ hợp của 1 trong 4 lý do sau: 1. Vì nó là 1 kỹ thuật mà nhà phân tích biết 2. Vì nó là kỹ thuật ưa thích của nhà phân tích trong mọi

hoàn cảnh

3. Nhà phân tích tuân theo 1 phương pháp luận tường

minh nào đó mà phương pháp luận này đòi hỏi một kỹ thuật đặc biệt ở thời điểm hiện tại.

4. Nhà phân tích hiểu một cách trực giác rằng kỹ thuật này

là hiệu quả trong hoàn cảnh hiện hành.

BM HTTT Khoa CNTT - HUI 82

Chọn phương pháp/ kỹ thuật Chọn phương pháp/ kỹ thuật thu thập yêu cầu thu thập yêu cầu

Rõ ràng lý do thứ 4 mô tả “sự thành thạo” ("maturity“) của nhà phân tích, chính sự thành thạo làm cho khả năng hiểu nhu cầu stakeholder rõ ràng hơn, khả năng thành công cao hơn.

Tuy nhiên hầu hết các nhà phân tích thực hành không thể quyết định rõ ràng là nên chọn phương pháp nào và thường dựa vào ba lý do đầu tiên.

BM HTTT Khoa CNTT - HUI 83

Managing the Customer Relationship Managing the Customer Relationship

Quản lý mối quan hệ khách hàng là quan trọng trong suốt chu kỳ dự án, và là chủ yếu trong suốt quá trình phân tích.

Cả người tiêu dùng lẫn nhà cung cấp cần

phải hiểu biết về sản phẩm.

Cần tiếp tục tương tác với khách hàng để duy trì mối quan hệ; e.g., thông báo cho họ tin xấu sớm tốt hơn là báo muộn. Tốt hơn là nên giao tiếp thường xuyên với khách hàng có thể tránh được các rắc rối nghiêm trọng có thể xảy ra sau đó.

BM HTTT Khoa CNTT - HUI 84

Managing the Customer Managing the Customer Relationship Relationship

Cần phải bảo đảm được sự hợp tác của khách hàng để có thể thu nhận được chuyên môn nghiệp vụ (domain expertise). Ví dụ: nếu 1 dự án có lịch biểu cố định và mối quan hệ với khách hàng không được tốt, vì vậy việc tiếp nhận về chuyên môn bị hạn chế, dẫn đến kết thúc dự án bị quá hạn.  It

that constant

is our experience communication with the customer

BM HTTT Khoa CNTT - HUI 85

Các quy tắc nghiệp vụ do khách hàng xác Các quy tắc nghiệp vụ do khách hàng xác địnhđịnh Customer-Specific Business Rules Customer-Specific Business Rules Business rules là loại đặc biệt của yêu

cầu khách hàng.

Khác với các nhu cầu cố định của khách hàng, các quy tắc nghiệp vụ dùng để: ◦mô tả việc thực thi chính sách của khách

hàng

◦có thể bị thay đổi bởi chính khách hàng

sau khi sản phẩm được phân phối.

Quy tắc nghiệp vụ và chính sách Quy tắc nghiệp vụ và chính sách

 Một tổ chức có thể ban hành, chỉnh

sửa hay hủy bỏ các quy tắc nghiệp vụ mà các quy tắc này sẽ chi phối và hướng dẫn tổ chức.

Chính sách (business policy) là yếu tố quản lý, không trực tiếp được thi hành mà dùng để hướng dẫn tổ chức hoạt động. Chính sách không đòi hỏi phải diễn tả có cấu trúc (không cần thuật ngữ tiêu chuẩn) như là quy tắc nghiệp vụ.

Ví dụ Ví dụ

“Bank customers should not be

able to make too many bank withdrawals in a single day or withdraw more than a certain amount of money in a fixed period of time; the maximum amount being based on their total account value and history.”

Đây là chính sách hay quy tắc nghiệp

vụ????

Why Are Customer-Specific Why Are Customer-Specific Business Rules Important? Business Rules Important? Các quy tắc nghiệp vụ do người dùng xác định phải tách riêng khỏi các yêu cầu thông thường, vì chúng không thực sự là yêu cầu.

Yêu cầu khách hàng có thể được suy diễn từ quy tắc nghiệp vụ, các yêu cầu có thể khác với quy tắc mà chúng được suy diễn.

Why Are Customer-Specific Why Are Customer-Specific Business Rules Important? Business Rules Important? Chính quy tắc nghiệp vụ do khách

hàng xác định dùng để thực thi chính sách (policy) của công ty, nhưng quy tắc nghiệp vụ có thể thay đổi sau khi hệ thống đã được phân phối.

 Nên xây dựng hệ thống sao cho

khách hàng có khả năng thay đổi quy luật mà không làm cho hệ thống bị sửa đổi theo.

Ví dụ Ví dụ

Policy: The hospital shall be able to define the difference between adult and child patients for check-in and medical records purposes.

Ví dụ Ví dụ Rule: Any patient under the age of 14

checking in shall be considered a child. When a child checks into the hospital, depending on the hospital’s business policy, a parent or guardian may have to accompany the child and sign all the admission forms. Detailed rules explain under what circumstances (e.g., an accident, emergency, or life-threatening situation) a child may be checked in without a parent’s or guardian’s consent.

Ví dụ Ví dụ

Requirement: A facility shall be

provided with the system such that the hospital check-in process for adults and children can be changed by hospital administrators without the need for system or software modifications.

Mối quan hệ giữa policy và business Mối quan hệ giữa policy và business rulerule

Managing the Customer Relationship Managing the Customer Relationship

Quản lý mối quan hệ khách hàng là quan trọng trong suốt chu kỳ dự án, và là chủ yếu trong suốt quá trình phân tích.

Cả người tiêu dùng lẫn nhà cung cấp cần phải

hiểu biết về sản phẩm.

Managing the Customer Managing the Customer Relationship Relationship

Cần phải bảo đảm được sự hợp tác của khách hàng để có thể thu nhận được chuyên môn nghiệp vụ (domain expertise).

Ví dụ: nếu 1 dự án có lịch biểu cố định và mối quan hệ với khách hàng không được tốt, vì vậy việc tiếp nhận về chuyên môn bị hạn chế, dẫn đến kết thúc dự án bị quá hạn.

 It is our experience that constant communication with the customer

Các lớp người dùng Các lớp người dùng

Người dùng sản phẩm thường khác

nhau do:

Tần số sử dụng sản phẩm Mức độ thành thạo chuyên môn và kỹ

năng máy tính

Tính năng sử dụng Nhiệm vụ cần thực hiện Quyền truy xuất và cấp độ bảo mật

BM HTTT Khoa CNTT - HUI 97

Các lớp người dùng Các lớp người dùng

BM HTTT Khoa CNTT - HUI 98

Các lớp người dùng Các lớp người dùng

Mỗi loại người dùng có các yêu cầu của

riêng họ.

Người dùng ít kinh nghiệm luôn bận tâm làm sao có thể sử dụng hệ thống một cách dễ dàng. Họ thích menu, giao diện đồ họa, wizard,…

Người dùng thành thạo quan tâm đến việc làm sao sử dụng hiệu quả hệ thống. Họ cần phím tắt, macro, các tùy biến, toolbar, thậm chí giao diện dòng lệnh hơn,…

BM HTTT Khoa CNTT - HUI 99

Các lớp người dùng Các lớp người dùng

Có thề xem các ứng dụng khác hay thành phần phần cứng cũng là một loại người dùng (user class(.

Ví dụ: hệ

thống phun xăng

(fuel injection) trong phần mềm nhúng của bộ phần điều khiển xe mô tô là 1 lớp người dùng vì RA cần thu thập yêu cầu từ thiết bị này cho phần mềm nhúng.

BM HTTT Khoa CNTT - HUI 100

Business requirements Business requirements

 Là bất cứ việc gì mô tả tài chính, thị trường hay các lợi ích nghiệp vụ khác mà khách hàng hay tổ chức muốn đạt được từ sản phẩm.

 Được suy diễn từ mục tiêu nghiệp vụ (business

goals)  Ví dụ:

◦ “Increase market share by X%” ◦ “Save $Y per year on electricity now wasted by inefficient

units.”)

◦ “Save $Z per year in mainternance costs that are consumed

by legacy system W.”

BM HTTT - Khoa CNTT - HUI 101

Ví dụ Business requirements Ví dụ Business requirements

 Each person may be associated with several email

address records.

 Each individual class category may be used only

once for each person

 A subscription is cancelled if 3 successive “soft

bounces” results

 Each subcriber profile may be associated with

several memberships

BM HTTT - Khoa CNTT - HUI 102

Use cases và scenario Use cases và scenario

 Use case là các phát biểu chung về mục tiêu người dùng hay nhiệm vụ (business tasks) mà người dùng cần thực thi.

 Scenario mô tả các bước cần thực thi để hoàn thành

một use case

 A use who says, “I need to ” is

probably describing a use case.

BM HTTT - Khoa CNTT - HUI 103

Ví dụ Use cases và scenario Ví dụ Use cases và scenario

 “I need to print a mailing lable for a package”  “I need to manage a queue of chemical sample

waiting to be analyzed”

 “I need to calibrate the pump controller”

Print Lable

Calibrate pump controller

Manage chemical samples

BM HTTT - Khoa CNTT - HUI 104

Business rules Business rules

 Qui tắc nghiệp vụ chỉ ra điều kiện để có thể thực hiện

một hoạt động nghiệp vụ của khách hàng.

 Ví dụ: Các qui tắc nghiệp vụ trong hệ thống Chemical

Tracking System:

 “A chemist may order a chemical on the Level 1 hazard list only if his hazardous-chemical training is current.”

BM HTTT - Khoa CNTT - HUI 105

Business rules Business rules

 Mỗi tổ chức đều vận hành theo các chính sách, điều

lệ và tiêu chuẩn kỹ thuật.

 Những nguyên tắc để kiểm soát việc vận hành có theo tiêu chuẩn, điều luật hay không được gọi là bisiness rules.

 Ứng dụng SW thường phải tuân theo các qui tắc nghiệp vụ này. Nhưng nhiều qui tắc nghiệp vụ có thể nằm ngoài phạm vi của SW

BM HTTT - Khoa CNTT - HUI 106

Cách xác định qui tắc nghiệp vụ Cách xác định qui tắc nghiệp vụ

 Các mẫu câu mô tả qui tắc nghiệp vụ:  “Must comply with ”  “Must conform to ”  “If

true>,

then

happens>

 “Must be calculated according to ”

BM HTTT - Khoa CNTT - HUI 107

Phân loại Business rules Phân loại Business rules

BM HTTT - Khoa CNTT - HUI 108

Facts Facts

 Facts are simply statements that are true about the

business (invariants)

 Các quy tắc nghiệp vụ khác có thể tham chiếu đến facts, nhưng không nên chuyển fact thành yêu cầu chức năng SW

 Fact có thể xuất hiện trong mô hình dữ liệu

BM HTTT - Khoa CNTT - HUI 109

Các ví dụ về Facts Các ví dụ về Facts

 Each chemical container has a unique bar code

identifier

 Each order must have a shipping charge.  Each line item in an order represents a specific combination of chemical, grade, container size, and number of contaioners.

 Nonrefundable tickets incur a fee when the purchaser

changes the itinerary.

 Sales tax is not computed on shipping charges.

BM HTTT - Khoa CNTT - HUI 110

Constraints Constraints

 Constraints restrict the actions that the system or its

users may perporm

 Các từ hay dùng để mô tả ràng buộc là must, must

not, may not và only.

 Ràng buộc có nhiều dạng khác nhau  Ví dụ các ràng buộc về thiết kế và thực thi

◦ “Files submitted electronically may not exceed 10MB in size” ◦ “The browser must use 128-bit encryption for all secure

transactions.”

BM HTTT - Khoa CNTT - HUI 111

Một số ví dụ về Constraints Một số ví dụ về Constraints

 A borrower who is less than 18 years old must have a parent or a legal guardian as cosigner on the loan.  A user may request a chemical on the level 1 hazard list only if he has hazardous-chemical traing within the past 12 months.

 Alll software applications must comply with for useage by visually

regulations

government impaired persons.

 Commercial airline flight crew must receive ay least eight hours of continuous rest in every 24-hour period.

BM HTTT - Khoa CNTT - HUI 112

Các ràng buộc của dự án SW Các ràng buộc của dự án SW

 Dự án SW có rất nhiều loại ràng buộc  Các ràng buộc mức dự án về schedule, staff và budget nằm trong kế hoạch quản lý dự án (project manegement plan)

 Các ràng buộc về thiết kế và thực thi nằm trong SRS

BM HTTT - Khoa CNTT - HUI 113