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) là gì?
Các kỹ thuật thu thập yêu cầu Chọn lựa kỹ thuật thu thập yêu cầu Quy tắc nghiệp vụ và chính sách Quản lý mối quan hệ khách hà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 là quá trình xác định yêu cầu và làm giảm sự khác biệt giữa các nhóm có liên quan để rút ra các yêu cầu đáp ứng được nhu cầu của tổ chức hay dự án trong khi vẫn giữ được các ràng buộc.
Có rất nhiều kỹ thuâṭ elicitation khác
nhau
BM HTTT Khoa CNTT - HUI 4
Phân biệt giữa elicitation và Phân biệt giữa elicitation và analysis analysis Elicitation là sự tương tác với
stakeholders để nắm bắt được nhu cầu của họ.
Analysis là tinh chỉnh (refinement) nhu cầu của stakeholder thành các đặc tả sản phẩm chính thức.
BM HTTT Khoa CNTT - HUI 5
Tầm quan trọng Tầm quan trọng
Requirements elicitation is perhaps the most difficult, most critical, most error-prone, and most communication- intensive aspect of software development.
Elicitation chỉ có thể thành công thông
qua mối quan hệ hợp tác giữa customer và đội development .
BM HTTT Khoa CNTT - HUI 6
Mô hình song song của quy trình yêu Mô hình song song của quy trì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
Các hoạt động của yêu cầu Các hoạt động củ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
Các kỹ thuật thu thập yêu cầu Các kỹ 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 kỹ thuật phổ biến nhất là Document
sampling, interviewing và questionaires
BM HTTT Khoa CNTT - HUI 21
Các kỹ thuật thu thập yêu cầu Các kỹ thuật thu thập yêu cầu
BM HTTT Khoa CNTT - HUI 22
Các kỹ thuật thu thập yêu cầu Các kỹ thuật thu thập yêu cầu
Assignment 12: Document Sampling
◦Nhóm???
Assignment 13: Questionaires
BM HTTT Khoa CNTT - HUI 23
Interviewing Interviewing
Là kỹ thuật trực tiếp và đơn giả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 hỏi context-free có thể giúp hoàn thành các
phỏng vấn bias-free interviews
Tập hợp lại 1 số nhu cầu chung sẽ tạo
“requirements repository”để dùng trong suốt dự án
Questionnaire không thể thay thế cho interview.
BM HTTT Khoa CNTT - HUI 24
•
Interviews Interviews Interview cá nhân hay nhóm các người dùng là nguồn thu thập yêu cầu kiều truyến thống cho cả sản phẩm thương mại cũng như các hệ thống thông tin.
• Tìm hiểu cách nghĩ của người dùng khi họ trình bày các yêu cầu, rút ra các quyết định có tính logic của người dùng. Để mô tả quá trình đưa ra các quyết định logic có thể dùng flowchart và cây quyết định (decision tree) bảo đảm mọi người hiểu được tại sao hệ thống phải thực hiện các chức năng này.
• Đôi khi các yêu cầu của người dùng phản ánh các quy trình nghiệp vụ đã lỗi thời hay không hiệu quả nữa và không nên đưa và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
Là câu hỏi có thể dùng cho bất kỳ dự
án nào đang khảo sát.
Là các câu hỏi chung về bản chất của dự án và môi trường mà sản phẩm sẽ được dùng.
Được dùng trong mỗi giai đoạn khác
nhau của cuộc phỏng vấn.
BM HTTT Khoa CNTT - HUI 27
Các dạng câu hỏi context free Các dạng câu hỏi context free Opening Questions: khi bắt đầu phỏng vấn, câu hỏi context free sẽ giúp khởi đầu cuộc phỏng vấn và vượt qua được các lúng túng ban đầu.
Redirection: có thể được dùng để chuyển hướng phỏng vấn khi nội dung cuộc đối thoại ra ngoài chủ đề hay quá sâu không cần thiết, đưa cuộc đối thoại về lại vị trí trung lập để hướng đến chủ đề mong muốn.
Closing: dùng để kết thúc cuộc phỏng vấn “Is there anything else you would like to tell me?” cho người được phỏng vấn (interviewee) cơ hội được chủ động và chia xẻ̃ các thông tin khá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
Làm thế nào đề thực hiện interview Làm thế nào đề thực hiện interview
Phải chuẩn bị một danh sách các câu hỏi context free trước khi phỏng vấn. Có thể đặt cùng 1 hay 2 câu hỏi cho người được phỏng vấn (interviewee) để tìm ra điểm khác biệt.
Thông qua câu hỏi context free để giúp người
tham gia phỏng vấn có hiểu biết chung
Không bận tâm vào câu trả lời “right/wrong”. Nhiều câu hỏi dùng gây ấn tượng hơn là để thu nhận dữ liệu, dùng để thu thập chi tiết hơn yêu cầu đang khảo sá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 dà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
Có thể là kỹ thuật năng động nhất để thu
thập yêu cầu.
Tập hợp tất cả 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 người trợ giúp (facilitator) có kinh nghiệm từ bên ngoài trong quản lý yêu cầu có thể bảo đảm cho sự thành công của workshop.
Brainstorming là phần quan trọng nhất của workshop.
BM HTTT Khoa CNTT - HUI 40
Preparing for the workshop Preparing for the workshop
Bảo đảm có sự tham gia của các
stakeholder phù hợp
Công tác hậu cần (Logistics) ◦Cố và tránh luật Murphy’s law ◦Bao gồm cả du lịch, giải trí và ăn nhẹ buổi
chiều (“afternoon sugar filled snacks.”) Tài liệu đầu buổi hội thảo (Warm-up
materials) ◦Thông tin của buổi hội thảo ◦Out-of-box thinking preparation
BM HTTT Khoa CNTT - HUI 41
Trong lúc Workshop Trong lúc Workshop • Để dễ dàng giao tiếp, nên sử dụng từ ngữ của miền ứng dụng thay vì bắt khách hàng hiểu các thuật ngữ máy tính. • Nên đưa các thuật ngữ nghiệp vụ vào danh sách các từ khó (glossary) để các thành viên cùng dùng chung các định nghĩa
• Customer nên hiểu là việc thảo luận về chức năng không hẳn là 1 nhiệm vụ phải có trong sản phẩm.
BM HTTT Khoa CNTT - HUI 42
Trong lúc workshop Trong lúc workshop
• Kỹ năng để dẫn dắt các cuộc thảo luận phân tích yêu cầu phải có được từ kinh nghiệm, tập huấn phỏng vấn, hỗ trợ nhóm, giải quyết xung đột, ..
• Người phân tích phải khảo sát cẩn thận (probe) nhu cầu thực sự của khách từ 1 loạt các yêu cầu mà khách hàng đề ra. – Hỏi "why" nhiều lần – Hỏi các câu hỏi mở (open-ended question) để giúp hiểu được quy trình nghiệp vụ hiện hành của người dùng và để thấy hệ thống mới có thễ cải thiện việc thực thi như thế nào.
– Điều tra tìm hiểu (Inquire) những thay đổi xảy ra cho người
dùng khi hệ thống mới được đưa vào sử dụng.
– Thử đóng vai trò người tập sự (apprentice) học hỏi từ người
dùng chính.
BM HTTT Khoa CNTT - HUI 43
Vai trò của requirement analyst Vai trò của requirement analyst
• Người phân tích yêu cầu (Requirements analyst) thường tham gia các hội thảo phân tích yêu cầu. • Facilitator đóng vai trò chính trong việc lên kế hoạch hội thảo, chọn người tham dự, dẫn dắt người tham dự để kết thúc thành công hội thảo. • Khi đội bắt đầu các phương pháp mới để phân tích yêu cầu nên có một facilitator ngoài đội hướng dẫn các workshop khởi đầu, nhờ đó các analyst có thể góp phần nhiều hơn vào các cuộc thảo luận.
BM HTTT Khoa CNTT - HUI 44
Facilitator Role of the Facilitator Role of the
Xác lập 1 phong cách chuyên nghiệp và mục tiêu rõ
ràng cho cuộc họp
Bắt đầu và kết thúc cuộc họp đúng giờ Xác lập và nhấn mạnh các quy tắc của cuộc họp. Giới thiệu mục tiêu và lịch trình của cuộc họp Điếu hành cuộc họp và giữ cho mọi người luôn quan
tâm theo dõi
Tạo điều kiện khi cần biểu quyết nhất trí nhưng tránh
tham gia vào.
Bảo đảm mọi stakeholder đều có quyền phát biểu góp ý
trong cuộc họp
Kiểm soát các hành vi gây rối và không phù hợp.
BM HTTT Khoa CNTT - HUI 45
Workshop Agenda Workshop Agenda
Xây dựng lịch trình (agenda) trước cho buổi hội thảo và công bố nó cùng với các tài liệu chuẩn bị trước của workshop.
Giữ ổn định cho buổi hội thảo rất quan trọng, cố gắng theo đúng lịch trình, nhưng cũng không nên tuân theo nó quá cứng nhắc, nhất là khi đang có thả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ử lịch thiệp và vui vẻ
◦Không nên “attack” thành viên khác. ◦Không nên diễn thuyết nhiều quá. ◦Đừng quay lại muộn sau khi giải lao
Thẻ phạt (Workshop tickets)
◦Cấp cho mỗi stakeholder một trong 3 loại thẻ phạt sau: đi muộn, gian lận (“cheap shot”) , phát biểu dài dòng (“soap box”)
◦Facilitator cũng có thể bị nhận thẻ phạt. ◦
BM HTTT Khoa CNTT - HUI 47
Một số nguyên tắc cơ bản để Một số nguyên tắc cơ bản để workshop thành công workshop thà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
Quản lý thời gian
◦ Khó bắt đầu lại sau nghỉ giải lao và
Facilitator phải theo dõi thời gian nghỉ giải lao và phạt bất kỳ ai đến muộn,
ăn trưa.
◦ Stakeholders quan trọng thường
Mỗi người chỉ được 5 phút để phát biểu.
quay lại muộn.
Giành quyền phát biểu quá lâu,
Facilitator khuyến khích mọi người sử dụng 5 phút được phát biểu và ủng hộ các sáng kiến.
Thiều dữ liệu từ stakeholders
Dùng vé phạt (“Cheap Shot Tickets”) và buộc trả chi phí
Phát biểu tiêu cực, hành động nhỏ nhen, gây gỗ
Mệt mỏi thiếu sinh lực sau khi ăn trưa
Nên tổ chức ăn nhẹ buổi trưa, giải lao buổi chiều, sắp xếp lại chỗ ngồi BM HTTT Khoa CNTT - HUI
49
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 dùng để phân tích tìm các yêu cầu ban đầu của stakeholder đối với sản phẩm. Phương pháp này được thực hiện với nhiều stakeholders hay customers và các phiên giao tiếp này thường được dẫn dắt bởi 1 facilitators có kinh nghiệm, mỗi phiên (session) thường kéo dài tối đa 1 hay 2 ngày.
• Mục tiêu của brainstorming session là đưa ra các ý tưởng mới hay các tính năng của sản phẩm trong 1 thời gian rất ngắn.
BM HTTT Khoa CNTT - HUI 51
Brainstorming Sessions Brainstorming Sessions
Khi xác định ý tưởng, điều quan trọng
là phải tránh xung đột, e.g., một thành viên chê bài ý tưởng của người khác.
Nếu có thành viên lâu năm (senior) tham gia session thì điều quan trọng là giữ cho họ không được đe dọa các thành viên ít kinh nghiệm hơn họ.
BM HTTT Khoa CNTT - HUI 52
Vai trò của facilitator Vai trò của facilitator
Vai trò của facilitator rất quan trọng, quyết định session có thành công hay không?
BM HTTT Khoa CNTT - HUI 53
Brainstorming Brainstorming
Mục tiêu và thời gian của
brainstorming session cần phải được thỏa thuận trước bởi tất cả các thành viên, tốt nhất là ngay trước khi bắt đầu session.
Session nên bắt đầu với việc tự do
đưa ra các ý kiến, tạo thành 1 tập hợp các kiến nghị về sản phẩm. Nên dùng “sticky notes” và dán vào bảng.
BM HTTT Khoa CNTT - HUI 54
Các giai đoạn của Brainstorming Các giai đoạn của Brainstorming Session Session
BM HTTT Khoa CNTT - HUI 55
Tabular Elicitation Technique Tabular Elicitation Technique
• Việc dùng bảng có thể giúp nắm bắt
được yêu cầu của stakeholder rõ ràng và chặt chẽ hơn.
• Có 2 loại bảng hay được dùng:
– Decision table – State table
BM HTTT Khoa CNTT - HUI 56
Decision table Decision table
• Bảng quyết định (Decision table)
thông dụng nhất khi: – Tập các điều kiện là rời rạc, có thể được
xác định bằng “yes” hay “no,”
– Hành động sẽ thực hiện khi các điều kiện
thỏa mãn
– Tập các rule khi tập các điều kiên là duy nhất và tương ứng với mỗi rule là 1 hành động.
BM HTTT Khoa CNTT - HUI 57
Decision table Decision table
Mỗi hà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 và 1 tập các hành động tương ứng. Khi cần phân tích bản phác thảo các yêu cầu lúc đầu của stakeholder thì bảng quyết định được dùng rất hiệu quả để nắm bắt các quy tắc nghiệp vụ. (business rule)
BM HTTT Khoa CNTT - HUI 58
Ví dụ bảng quyết định Ví dụ bảng quyết định
BM HTTT Khoa CNTT - HUI 59
State tables State tables • Được dùng khi đối tượng đang khảo sát có thể có các trạng thái khác nhau ở các thời điểm khác nhau và các sự kiện đơn giản nhưng rõ ràng nào đó có thễ kích khởi việc đổi từ trạng thái này sang trạng thái khác.
• State machine: là 1 đối tượng mà việc chuyển đổi trạng thái chỉ dựa vào các sự kiện rời rạc và số trạng thái của đối tượng đã biết trước.
• Ví dụ: bảng người nộp thuế (taxpayer) không phải là bảng trạng thái vì chỉ có 1 trạng thái duy nhất là “about to pay taxes.”
BM HTTT Khoa CNTT - HUI 60
State table State table
State tables chỉ ra hành vi của state machine, thường có 1 trạng thái khởi đầu và một tập các trạng thái mà đối tượng sẽ trải qua và cuối cùng là trạng thái exit thành công hay 1 trong các trạng thái “error”. Mỗi lần thay đổi trạng thái đều có liên quan đến 1 hay nhiều sự kiện (event)
BM HTTT Khoa CNTT - HUI 61
Button
Ví dụ Ví dụ
BM HTTT Khoa CNTT - HUI 62
Phương pháp điều tra (survey)- Phương pháp điều tra (survey)- Ethnographic Techniques Ethnographic Techniques • Một số phương pháp điều tra được dùng rất nhiều để đánh giá các yêu cầu thị trường, mối quan tâm về sản phẩm.
• Khi số lượng khách hàng tương đồi lớn, có thể thực hiện thống kê trên kết quả điều tra đề đo lường mức độ quan tâm của khách hàng đối với các tính năng của sản phẩm.
• Một trong các phương pháp điều tra
thông dụng nhất để phân tích mối quan tâm của khách hàng là Kano modeling.
BM HTTT Khoa CNTT - HUI 63
Phương pháp Kano modeling Phương pháp Kano modeling Cung cấp ba biến để đo lường mối quan
tâm của khách hàng: • One-dimensional quality • Expected quality • Attractive quality.
BM HTTT Khoa CNTT - HUI 64
Phương pháp Kano modeling Phương pháp Kano modeling
One-dimensional (hay linear quality)
được áp dụng ở sản phẩm có giá trị tăng tuyến tính cùng với 1 số tính năng nào đó. Ví dụ tính tiết kiệm điện năng của tủ lạnh, nếu tính năng này càng hiệu quả thì khả năng khách hàng đặt mua càng nhiều.
BM HTTT Khoa CNTT - HUI 65
Phương pháp Kano modeling Phương pháp Kano modeling Expected quality là tính năng bắt buộc phải có đối với sản phẩm nào thành công trên thị trường.
Attractive quality là tính năng không được mong đợi nhưng bổ sung vào yếu tố tâm lý (emotional appeal) của sản phẩm. Ví dụ camera trong mobile là attractive quality trong nhiều năm trước nhưng bây giờ là expected quality trong hầu hết các thị trường.
BM HTTT Khoa CNTT - HUI 66
Phương pháp Kano modeling Phương pháp Kano modeling
Một đo lường khác là yêu tố văn hóa. Ví dụ, ở Mỹ hầu hết các khách hàng đều muốn mua xe ô tô có số tự động, trong khi đó ở châu Âu thích mua xe sang số tay.
Kano modeling được chấp nhận rộng
rãi;một số công cụ quản lý requirements engineering có 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 kỹ thuật để phát triển yêu cầu của 1 hệ thống và trong các giai đoạn đầu của dự án phần mềm.
Mục đích: tập hợp MIS và người dùng cuối trong cơ chế của 1 workshop, để cùng thống nhất (consensus) với nhau các yêu cầu của hệ thống.
BM HTTT Khoa CNTT - HUI 70
JAD và phương pháp cũ JAD và phương pháp cũ
Bằng cách kết hợp workshop và nhấn (spirit of thần cộng
tác
tinh mạnh partnership)
Bằng cách kết hợp công nghệ và nhu cầu nghiệp vụ trong 1 quy trình thống nhất, lặp lại và hiệu quả
JAD giúp thu thập yêu cầu hệ thống nhanh hơn, chính xác hơn các phương pháp cổ điển.
giảm 1 cách đáng kể thời gian, chi phí và
lỗi cho dự án.
BM HTTT Khoa CNTT - HUI 71
Dự án nào nên dùng JAD Dự án nào nên dùng JAD
Liên quan đến nhiều nhóm người
dùng khác nhau
Rất quan trọng đến sự thành công
trong tương lai của tổ chức.
Là dự án mới của tổ chức Có trở ngại trong dự án cũ hay mối quan hệ giữa hệ thống và 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
Là người của tổ chức khách hàng và có quyền quyết định tối cao về dự án (CEO, người lãnh đạo dự án)
Facilitator làm việc với sponsor để khởi động dự án, nhưng sponsor mới là người quyết định chính, không phải là facilitator.
BM HTTT Khoa CNTT - HUI 75
Trách nhiệm của Executive sponsor Trách nhiệm của Executive sponsor
Nhận trách nhiệm cao nhất về các chức năng
của hệ thống.
Giải quyết các xung đột về chính sách bằng
cách đưa ra các quyết định cuối
Công bố kết quả của quy trình JAD. Xác lập vision cho dự án Bảo đảm cho đội dự án tiếp cận và làm việc
được với các chuyên gia nghiệp vụ.
Tạo ra sự hợp tác và hỗ trợ của khách hàng
đối với đội dự án
BM HTTT Khoa CNTT - HUI 76
Vai trò của executive sponsor Vai trò của executive sponsor Làm cho khách hàng tin tưởng vào quy
trình JAD
Trong lúc định hướng JAD, sponsor quan tâm đến cả đội, biểu lộ thái độ hợp tác và hỗ trợ.
Sponsor cũng tỏ ra tin cậy vào facilitator, giảm thiêu được sự đối kháng ban đầu của đại diện khách hàng.
Sponsor chỉ là thành viên của JAD và thường không tham dự vào các cuộc họp JAD, chỉ cần ghé qua để biểu lộ sự quan tâm hợp tác.
BM HTTT Khoa CNTT - HUI 77
Vai trò của các thành viên JAD Vai trò của các thành viên JAD
Vai trò của facilitator Vai trò của scribe Assignment??
BM HTTT Khoa CNTT - HUI 78
JAD Critical Success Factors JAD Critical Success Factors
Tránh phạm vi dự án bị phình ra
(creep).
Nhận biết sớm các vấn đề của tổ
chức hay những rắc rối chính trị.
Bảo đảm tất cả thành viên tham gia dự án và các nhà quản lý chính đều chấp nhận các kỹ thuật của JAD.
Chia các dự án lớn thành các phần có
thể quản lý được.
BM HTTT Khoa CNTT - HUI 79
Chọn lựa kỹ thuật thu thập yêu Chọn lựa kỹ thuật thu thập yêu cầucầu
BM HTTT Khoa CNTT - HUI 80
Chọn phương pháp/ kỹ thuật Chọn phương pháp/ kỹ thuật thu thập yêu cầu thu thập yêu cầu
Có nhiều phương pháp luận
(methodology) và kỹ thuật (method) để thu thập yêu cầu,
Một số nhà phân tích nghĩ rằng chỉ cần dùng 1 phương pháp hay 1 kỹ thuật là đủ để áp dụng cho mọi hoàn cảnh.
BM HTTT Khoa CNTT - HUI 81
Chọn phương pháp/ kỹ thuật Chọn phương pháp/ kỹ thuật thu thập yêu cầu thu thập yêu cầu
Nhà phân tích chọn 1 kỹ thuật thu thập nào đó là
do tổ hợp của 1 trong 4 lý do sau: 1. Vì nó là 1 kỹ thuật mà nhà phân tích biết 2. Vì nó là kỹ thuật ưa thích của nhà phân tích trong mọi
hoàn cảnh
3. Nhà phân tích tuân theo 1 phương pháp luận tường
minh nào đó mà phương pháp luận này đòi hỏi một kỹ thuật đặc biệt ở thời điểm hiện tại.
4. Nhà phân tích hiểu một cách trực giác rằng kỹ thuật này
là hiệu quả trong hoàn cảnh hiện hành.
BM HTTT Khoa CNTT - HUI 82
Chọn phương pháp/ kỹ thuật Chọn phương pháp/ kỹ thuật thu thập yêu cầu thu thập yêu cầu
Rõ ràng lý do thứ 4 mô tả “sự thành thạo” ("maturity“) của nhà phân tích, chính sự thành thạo làm cho khả năng hiểu nhu cầu stakeholder rõ ràng hơn, khả năng thành công cao hơn.
Tuy nhiên hầu hết các nhà phân tích thực hành không thể quyết định rõ ràng là nên chọn phương pháp nào và thường dựa vào ba lý do đầu tiên.
BM HTTT Khoa CNTT - HUI 83
Managing the Customer Relationship Managing the Customer Relationship
Quản lý mối quan hệ khách hàng là quan trọng trong suốt chu kỳ dự án, và là chủ yếu trong suốt quá trình phân tích.
Cả người tiêu dùng lẫn nhà cung cấp cần
phải hiểu biết về sản phẩm.
Cần tiếp tục tương tác với khách hàng để duy trì mối quan hệ; e.g., thông báo cho họ tin xấu sớm tốt hơn là báo muộn. Tốt hơn là nên giao tiếp thường xuyên với khách hàng có thể tránh được các rắc rối nghiêm trọng có thể xảy ra sau đó.
BM HTTT Khoa CNTT - HUI 84
Managing the Customer Managing the Customer Relationship Relationship
Cần phải bảo đảm được sự hợp tác của khách hàng để có thể thu nhận được chuyên môn nghiệp vụ (domain expertise). Ví dụ: nếu 1 dự án có lịch biểu cố định và mối quan hệ với khách hàng không được tốt, vì vậy việc tiếp nhận về chuyên môn bị hạn chế, dẫn đến kết thúc dự án bị quá hạn. It
that constant
is our experience communication with the customer
BM HTTT Khoa CNTT - HUI 85
Các quy tắc nghiệp vụ do khách hàng xác Các quy tắc nghiệp vụ do khách hàng xác địnhđịnh Customer-Specific Business Rules Customer-Specific Business Rules Business rules là loại đặc biệt của yêu
cầu khách hàng.
Khác với các nhu cầu cố định của khách hàng, các quy tắc nghiệp vụ dùng để: ◦mô tả việc thực thi chính sách của khách
hàng
◦có thể bị thay đổi bởi chính khách hàng
sau khi sản phẩm được phân phối.
Quy tắc nghiệp vụ và chính sách Quy tắc nghiệp vụ và chính sách
Một tổ chức có thể ban hành, chỉnh
sửa hay hủy bỏ các quy tắc nghiệp vụ mà các quy tắc này sẽ chi phối và hướng dẫn tổ chức.
Chính sách (business policy) là yếu tố quản lý, không trực tiếp được thi hành mà dùng để hướng dẫn tổ chức hoạt động. Chính sách không đòi hỏi phải diễn tả có cấu trúc (không cần thuật ngữ tiêu chuẩn) như là quy tắc nghiệp vụ.
Ví dụ Ví dụ
“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 là chính sách hay quy tắc nghiệp
vụ????
Why Are Customer-Specific Why Are Customer-Specific Business Rules Important? Business Rules Important? Các quy tắc nghiệp vụ do người dùng xác định phải tách riêng khỏi các yêu cầu thông thường, vì chúng không thực sự là yêu cầu.
Yêu cầu khách hàng có thể được suy diễn từ quy tắc nghiệp vụ, các yêu cầu có thể khác với quy tắc mà chúng được suy diễn.
Why Are Customer-Specific Why Are Customer-Specific Business Rules Important? Business Rules Important? Chính quy tắc nghiệp vụ do khách
hàng xác định dùng để thực thi chính sách (policy) của công ty, nhưng quy tắc nghiệp vụ có thể thay đổi sau khi hệ thống đã được phân phối.
Nên xây dựng hệ thống sao cho
khách hàng có khả năng thay đổi quy luật mà không làm cho hệ thống bị sửa đổi theo.
Ví dụ Ví dụ
Policy: The hospital shall be able to define the difference between adult and child patients for check-in and medical records purposes.
Ví dụ Ví dụ 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.
Ví dụ Ví dụ
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 và business Mối quan hệ giữa policy và business rulerule
Managing the Customer Relationship Managing the Customer Relationship
Quản lý mối quan hệ khách hàng là quan trọng trong suốt chu kỳ dự án, và là chủ yếu trong suốt quá trình phân tích.
Cả người tiêu dùng lẫn nhà cung cấp cần phải
hiểu biết về sản phẩm.
Cần tiếp tục tương tác với khách hàng để duy trì mối quan hệ; e.g., thông báo cho họ tin xấu sớm tốt hơn là báo muộn. Tốt hơn là nên giao tiếp thường xuyên với khách hàng có thể tránh được các rắc rối nghiêm trọng có thể xảy ra sau đó.
Managing the Customer Managing the Customer Relationship Relationship
Cần phải bảo đảm được sự hợp tác của khách hàng để có thể thu nhận được chuyên môn nghiệp vụ (domain expertise).
Ví dụ: nếu 1 dự án có lịch biểu cố định và mối quan hệ với khách hàng không được tốt, vì vậy việc tiếp nhận về chuyên môn bị hạn chế, dẫn đến kết thúc dự án bị quá hạ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
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 true>, is then happens> “Must be calculated according to BM HTTT - Khoa CNTT - HUI 107 BM HTTT - Khoa CNTT - HUI 108 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 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 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 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 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 Action enabler là 1 qui tắc mà nó khởi động(triggers) 1 số hoạt động nào đó trong 1 điều kiện xác định Điều kiện để dẫn đến hành động có thể là 1 tổ hợp giữa các giá trị true/false của nhiều điều kiện đơn Thường có dạng:”
“If BM HTTT - Khoa CNTT - HUI 114 BM HTTT - Khoa CNTT - HUI 115 Inference là quy tắc suy diễn ra một hiểu biết mới dựa vào tính xác thực của các điều kiện đó Thường có dạng “if/then” nhưng mệnh đề “then” ngầm chỉ 1 fact, không phải là một cation enabler. BM HTTT - Khoa CNTT - HUI 116 BM HTTT - Khoa CNTT - HUI 117 Các tính toán (computation) được thực hiện bằng cách sử dụng công thức toán học hay giải thuật. Trong khi action-enabler xác định các yêu cầu chức năng SW
phải tuân theo chúng, còn các qui tắc computation thì được
dùng như các yêu cầu SW. BM HTTT - Khoa CNTT - HUI 118 BM HTTT - Khoa CNTT - HUI 119 BM HTTT - Khoa CNTT - HUI 120 Các tổ chức nên quản lý các quy tắc nghiệp vụ như tài sản tổ chức Các dạng lưu trữ: ◦ Business rules catalog
◦ Database BM HTTT - Khoa CNTT - HUI 121 BM HTTT - Khoa CNTT - HUI 122 Trong quá trình thu thập yêu cầu, các câu hỏi:
“What are your bussiness rules”
“What do you want?”
Thường không hiệu quả
Nhiều qui tắc nghiệp vụ được phát hiện ra trong quá trình thảo luận về các yêu cầu BM HTTT - Khoa CNTT - HUI 123 BM HTTT - Khoa CNTT - HUI 124 Sau khi nhận dạng và xác định các qui tắc nghiệp vụ, nên xác
định xem qui tắc nào cần thực thi trong phần mềm. Một số qui
tắc sẽ làm phát sinh các use case (yêu cầu chức năng). BM HTTT - Khoa CNTT - HUI 125 Rule #1 (action enabler) "If the expiration date for a chemical container has been
reached, then notify the person who
currently possesses that container."
Rule #2 (inference) "A container of a chemical that can form explosive
decomposition products is considered
expired one year after its manufacture
date." Rule #3 (fact) "Ethers can spontaneously form explosive peroxides." Bộ Môn HTTT - Khoa CNTT
- HUI 126 Ba quy tắc này dẫn đến use case "Notify Chemical Owner of Expiration.“
Một yêu cầu chức năng cho use case
này là "The system shall e-mail a
notification to the current owner of a
chemical container on the date the
container expires." Bộ Môn HTTT - Khoa CNTT
- HUI 127 Đôi khi các qui tắc nghiệp vụ và yêu cầu chức năng tương ứng
rất giống nhau. Tuy nhiên các qui tắc là những phát biểu bên
ngoài cần phải đưa vào phần mềm thành các chức năng hệ
thống Mỗi nhà phân tích phải quyết định qui tắc nào phù hợp với ứng
dụng, cái nào nên đưa vào phần mềm, và đưa vào như thế nào. BM HTTT - Khoa CNTT - HUI 128 Xét hệ thống Chemical Tracking, có 1 constraint rule yêu cầu
người dùng phải có hồ sơ đào tạo (traing record) rồi mới có
quyền yêu cầu hóa chất độc ( hazardous chemical) Nhà phân tích có thể suy diễn qui tắc này thành các yếu tố
chức năng khác nhau tùy thuộc vào điều kiện CSDL về hồ sơ
đào tạo trực tuyến hay không? BM HTTT - Khoa CNTT - HUI 129 Nếu có, hệ thống chỉ đơn giản tìm kiếm hồ sơ đào tạo và quyết định chấp nhận hay từ chối yêu cầu. Nếu không, hệ thống có thể lưu trự tạm thời yêu cầu này và gửi
email đến training coordinator, người này có thể phê duyệt hay
từ chối yêu cầu Cùng 1 quy tắc nghiệp vụ cho cả 2 yêu cầu chức năng – Các yêu cầu chức năng thây đổi tùy theo môi trường hệ thống BM HTTT - Khoa CNTT - HUI 130 Yêu cầu chức năng mô tả các hành vi quan sát được của hệ
thống dưới điều kiện nào đó và các hành động mà hệ thống yêu
cầu người dùng thực hiện Yêu cầu chức năng được suy diễn từ yêu cầu hệ thống, yêu cầu người dùng, qui tắc nghiệp vụ. BM HTTT - Khoa CNTT - HUI 131 BM HTTT - Khoa CNTT - HUI 132 Là các phát biểu chỉ ra hệ thống thực thi tốt như thế nào?
Một số từ cùng mô tả các đặc tính của hệ thống như: fast, easy, intuitive, user-friendly, robust, reliable, secure, and efficient. BM HTTT - Khoa CNTT - HUI 133Phân loại Business rules
Phân loại Business rules
Facts
Facts
Các ví dụ về Facts
Các ví dụ về Facts
Constraints
Constraints
Một số ví dụ về Constraints
Một số ví dụ về Constraints
Các ràng buộc của dự án SW
Các ràng buộc của dự án SW
Action enabler
Action enabler
place>, then
Các ví dụ về Action enabler
Các ví dụ về Action enabler
Inference
Inference
Một số ví dụ về Inference
Một số ví dụ về Inference
Computations
Computations
Ví dụ Computations (dạng text)
Ví dụ Computations (dạng text)
Ví dụ Computations(dạng bảng)
Ví dụ Computations(dạng bảng)
Lưu trữ qui tắc nghiệp vụ
Lưu trữ qui tắc nghiệp vụ
Mẫu qui tắc nghiệp vụ
Mẫu qui tắc nghiệp vụ
Phát hiện qui tắc nghiệp vụ
Phát hiện qui tắc nghiệp vụ
Câu hỏi giúp tìm qui tắc nghiệp
Câu hỏi giúp tìm qui tắc nghiệp
vụvụ
Từ qui tắc nghiệp vụ đến yêu
Từ qui tắc nghiệp vụ đến yêu
cầu SW
cầu SW
Ví dụ
Ví dụ
Ví dụ
Ví dụ
Qui tắc nghiệp vụ và yêu cầu
Qui tắc nghiệp vụ và yêu cầu
chức năng
chức năng
Ví dụ Qui tắc nghiệp vụ và yêu
Ví dụ Qui tắc nghiệp vụ và yêu
cầu chức năng
cầu chức năng
Ví dụ Qui tắc nghiệp vụ và yêu
Ví dụ Qui tắc nghiệp vụ và yêu
cầu chức năng
cầu chức năng
Function requirements
Function requirements
Ví vụ về Function requirements
Ví vụ về Function requirements
Quality attributes
Quality attributes