1. Mục đích thu thập yêu cầu
2. Khó khăn khi thu thập yêu cầu người dùng
3. Các bước thu thập yêu cầu
4. Phân loại yêu cầu
5. Các phương pháp thu thập yêu cầu
MỤC ĐÍCH THU THẬP YÊU CẦU
• Xây dựng và duy trì sự thỏa thuận với khách hàng và các
stakeholder khác trên hệ thống đang xây dựng
• Giúp các nhà phát triển hệ thống hiểu tốt rõ hơn các yêu cầu
của hệ thống.
• Xác định phạm vi hệ thống
• Cung cấp cơ sở để lên kế hoạch cho các lần lặp tiếp theo.
• Cung cấp cơ sở để ước tính chi phí và thời gian để phát triển
hệ thống.
• Xác định giao diện người dùng của hệ thống
81 trang |
Chia sẻ: candy98 | Lượt xem: 963 | Lượt tải: 1
Bạn đang xem trước 20 trang tài liệu Bài giảng Phân tích và thiết kế hệ thống - Chương 3: Thu thập yêu cầu - Trần Thị Kim Chi, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP.HCM
KHOA CÔNG NGHỆ THÔNG TIN
Chương III
Trần Thị Kim Chi 1
NỘI DUNG
1. Mục đích thu thập yêu cầu
2. Khó khăn khi thu thập yêu cầu người dùng
3. Các bước thu thập yêu cầu
4. Phân loại yêu cầu
5. Các phương pháp thu thập yêu cầu
Trần Thị Kim Chi 2
MỤC ĐÍCH THU THẬP YÊU CẦU
What is requirement?
Requirements described the “what” of a system, not the
“how”
• A statement of a
service the system
must do OR
• A statement of a
constraint the system
must satisfy
Trần Thị Kim Chi 3
MỤC ĐÍCH THU THẬP YÊU CẦU
• Why do we need requirement definition?
Trần Thị Kim Chi 4
MỤC ĐÍCH THU THẬP YÊU CẦU
• Xây dựng và duy trì sự thỏa thuận với khách hàng và các
stakeholder khác trên hệ thống đang xây dựng
• Giúp các nhà phát triển hệ thống hiểu tốt rõ hơn các yêu cầu
của hệ thống.
• Xác định phạm vi hệ thống
• Cung cấp cơ sở để lên kế hoạch cho các lần lặp tiếp theo.
• Cung cấp cơ sở để ước tính chi phí và thời gian để phát triển
hệ thống.
• Xác định giao diện người dùng của hệ thống.
Trần Thị Kim Chi 5
KHÓ KHĂN KHI THU THẬP YÊU CẦU NGƯỜI DÙNG
• Nhiều khách hàng không biết họ thực sự cần gì
• Không đánh giá được những gì đang xảy ra trong tổ
chức của họ
• Khó khăn khi trình bày các ý kiến của họ với nhà
phát triển phần mềm
• Thường không biết nhiều về công nghệ thông tin
Trần Thị Kim Chi 6
MỘT VÀI THỰC TẾ
• Khách hàng đang quản lý 1 chuỗi các cửa hàng bán lẻ
không thu nhiều lợi nhuận và cần 1 SW về tài chính.
• Khách hàng cần thay đổi nghiệp vụ bán hàng.
• SW không thể cải thiện được tình trạng
Trần Thị Kim Chi 7
CÁC BƯỚC CỦA THU THẬP YÊU CẦU
Các bước thực hiện:
• Bước 1: Thu thập thông tin bằng các phương pháp khác nhau
• Bước 2: Củng cố, bổ sung và hoàn thiện kết quả khảo sát
• Bước 3: Tổng hợp kết quả khảo sát
• Bước 4: Hợp thức hoá kết quả khảo sát
Kết quả:
• Hiểu miền nghiệp vụ của hệ thống
– Banking, automobile manufacturing, ...
• Xây dựng mô hình nghiệp vụ của khách hàng
• Xác định yêu cầu của khách hàng đối với hệ thống
Trần Thị Kim Chi 8
PHÂN LOẠI YÊU CẦU
Trần Thị Kim Chi 9
YÊU CẦU NGHIỆP VỤ (BUSINESS REQUIREMENTS)
• Biễu diễn các mục tiêu của tổ chức hay khách hàng
yêu cầu hệ thống phải có
• Yêu cầu nghiệp vụ thường do người tài trợ cho dự án,
khách mua phần mềm, người quản lý các người dùng,
bộ phận tiếp thị (maketing)cung cấp
• Thường được ghi nhận trong phần đặc tả (vision) và
phạm vi (scope) của tài liệu, đôi khi còn được gọi là
tuyên bố dự án (project charter) hay tài liệu yêu cầu
thị trường (market requirements document)
Trần Thị Kim Chi 10
YÊU CẦU NGƯỜI DÙNG (USER REQUIREMENTS)
• Mô tả mục tiêu (goal) hay tác vụ (task) của người
dùng đối với hệ thống.
• Các cách để biểu diễn yêu cầu người dùng:
– Use cases, scenario
– Bảng event-response.
• Yêu cầu người dùng mô tả cái (what) mà người dùng
có thể làm đối với hệ thống.
• Ví dụ: use case "Make a Reservation" dùng trong các
website của hàng không, thuê xe, hay khách sạn.
Trần Thị Kim Chi 11
YÊU CẦU HỆ THỐNG (SYSTEM REQUIREMENTS )
• Mô tả yêu cầu mức cao đối với 1 sản phẩm, nó chứa
các hệ thống con (subsystem) nào.
• Một hệ thống có thể là toàn bộ phần mềm hay bao
gồm các hệ thống con của phần mềm cũng như phần
cứng.
• Con người cũng là 1 phần hệ thống, vì vậy các chức
năng hệ thống cũng có thể chỉ định cả vai trò của con
người
• Gồm 2 loại:
– Yêu cầu chức năng (Functional requirement)
– Yêu cầu phi chức năng (Non-functional requirement)
Trần Thị Kim Chi 12
YÊU CẦU HỆ THỐNG (SYSTEM REQUIREMENTS )
Xác định chức năng của phần mềm mà các nhà phát
triển phải xây dựng để giúp người dùng hoàn thành
nhiệm vụ của họ, thỏa mãn được yêu cầu nghiệp vụ.
Đôi khi còn được gọi là behavioral requirements.
Ví dụ: “The system shall e-mail a reservation
confrimation the user”
Trần Thị Kim Chi 13
YÊU CẦU HỆ THỐNG (SYSTEM REQUIREMENTS )
Yêu cầu chức năng (Functional requirements): Yêu cầu
chức năng chỉ ra những gì hệ thống làm, chúng thường quan
hệ các use-case hay những qui tắc nghiệp vụ (business rule)
• Một số yêu cầu chức năng
• Chức năng tính toán
• Chức năng lưu trữ
• Chức năng tìm kiếm
• Chức năng kết xuất
• Chức năng backup, restore
• Chức năng đa người dùng
• Chức năng đa phương tiện
Trần Thị Kim Chi 14
YÊU CẦU HỆ THỐNG (SYSTEM REQUIREMENTS )
Yêu cầu phi chức năng (Non-functional requirements):
Không tập trung vào các chức năng của hệ thống mà chỉ tập
trung vào các ràng buộc của hệ thống. Những ràng buộc về
tiêu chuẩn, thời gian, qui trình phát triển, chủ yếu là những
yêu cầu về chất lượng.
Sáu loại chính của yêu cầu phi chức năng: security, privacy,
usability, reliability, availability, and performance.
Ràng buộc: phản ảnh những đặc trưng của miền ứng dụng.
Chúng có thể là những yêu cầu chức năng hay yêu cầu phi
chức năng.
Trần Thị Kim Chi 15
YÊU CẦU HỆ THỐNG (SYSTEM REQUIREMENTS )
Một số yêu cầu phi chức năng
• Độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ
• Các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ
lập trình
• Yêu cầu của người sử dụng: dễ sử dụng, thân thiện
• Ràng buộc về ngân sách
• Phù hợp với các chính sách của tổ chức sử dụng hệ
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
Trần Thị Kim Chi 16
SO SÁNH YÊU CẦU CHỨC NĂNG VÀ PHI CHỨC NĂNG
• Yêu cầu chức năng được xử lý ngay trong giai đoạn phân tìch
hệ thống
• Yêu cầu phi chức năng sẽ được xét đến khi chuyển qua giai
đoạn thiết kế.
Trần Thị Kim Chi 17
ĐẶC TRƯNG CỦA YÊU CẦU
• Khả thi - Feasible
• Có giá trị - Valid
• Không nhập nhằng - Unambiguous
• Dễ kiểm chứng - Verifiable
• Dễ biến đổi - Modifiable
• Toàn vẹn - Consistent
• Đầy đủ - Complete
• Lần vết được - Traceable
Trần Thị Kim Chi 18
ĐẶC TRƯNG CỦA YÊU CẦU
Yêu cầu Nhập nhằng
Trần Thị Kim Chi 19
ĐẶC TRƯNG CỦA YÊU CẦU
Yêu cầu Nhập nhằng
Trần Thị Kim Chi 20
ĐẶC TRƯNG CỦA YÊU CẦU
Trần Thị Kim Chi 21
CÁC PHƯƠNG PHÁP THU THẬP YÊU CẦU
• Interactive methods:
– Interview
– JAD
– Questionaire
• Unobtrusive methods:
– Sampling
– Investigation
– Observing
• Prototyping
Trần Thị Kim Chi 22
PHỎNG VẤN (INTERVIEWS)
Phần lớn sử dụng các kỹ thuật thông thường
• Rất tự nhiên
– Nếu bạn cần biết một số điều, bạn hỏi một vài người
• Có 5 bước cơ bản để phỏng vấn:
– Selecting interviewees - Chọn người được phỏng vấn
– Designing interview questions - Thiết kế câu hỏi phỏng vấn
– Preparing for the interview - Chuẩn bị cho phỏng vấn
– Conducting the interview - Hướng dẫn phỏng vấn
– Post-interview follow-up - Thực hiện phỏng vấn tiếp
Trần Thị Kim Chi 23
CHỌN NGƯỜI ĐƯỢC PHỎNG VẤN (INTERVIEWS)
• Cần một kế hoạch phỏng vấn
– Danh sách tất cả những người để phỏng vấn
– Khi nào mỗi người sẽ được phỏng vấn
• Mục đích gì ở họ sẽ được phỏng vấn
• Danh sách có thể là không chính thức hoặc nó có
thể là một phần của 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 cảnh khác nhau
– Người quản lý (Managers)
– Người dùng (Users)
• Chọn những người cho các lý do chung
• Phỏng vấn được lặp đi lặp lại
Trần Thị Kim Chi 24
CHỌN NGƯỜI ĐƯỢC PHỎNG VẤN (INTERVIEWS)
Trần Thị Kim Chi 25
THIẾT KẾ CÂU HỎI PHỎNG VẤN
• Đừng hỏi thông tin mà có thể đạt được tại nơi khác
• Muốn chỉ 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.
• Không có kiểu câu hỏi nào là tốt nhất
• Khởi đầu sử dụng phỏng vấn không có cấu trúc để xác
định hệ thống như thế nào (câu hỏi mở)
• Khi người phân tích thu được sự hiểu biết, phỏng vấn có
cấu trúc được sử dụng (câu hỏi đóng)
• Phỏng vấn không cấu trúc
– Rộng, thông tin xác định đại thể
• Phỏng vấn có cấu trúc
– Thông tin cụ thể hơn Trần Thị Kim Chi 26
CÂU HỎI MỞ (OPEN-ENDED QUESTIONS)
– Mục tiêu là thu thập thông tin và dữ liệu cốt lõi và những đặc
trưng then chốt của hệ thống. Câu hỏi mở yêu cầu câu trả
không trực tiếp hay cụ thể.
– Dạng câu trả lời mở : người bị phỏng vấn trả lời tự do theo ý
mình.
– Ví dụ:
• What are the most frequent problems you experience with the existing data
analysis reports?
• Phần lớn những vấn đề từng gặp trong những mẫu báo cáo phân tích dữ liệu
đang tồn tại là gì?
• Name your three top priorities for improving the customer relationship
management system.
• Tên ba quyền ưu tiên để hoàn thiện mối quan hệ giữa khách hàng và người
quản lý hệ thống
Trần Thị Kim Chi 27
CÁC CÂU HỎI ĐÓNG
( CLOSED-RESPONSE BASED QUESTIONNAIRES )
• Mục tiêu là tập hợp thông tin thật của hệ thống. Nó đưa ra sự
hiểu biết sâu sắc trong việc làm thế nào mọi người tương tác
với hệ thống và những thuận lợi mà họ hiểu biết nó như thế
nào.
• Người bị phỏng vấn bị giới hạn, câu trả lời theo một qui định
lựa chọn đã có.
• 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 . Trần Thị Kim Chi 28
CÁC CÂU HỎI ĐÓNG
( CLOSED-RESPONSE BASED QUESTIONNAIRES )
Ví dụ:
• Có bao nhiêu khách hàng quan tâm đến sản phẩm này?
• Which one of the following is the best thing about the system you
currently use?
1. Having easy access to all of the data
2. The system's response time
3. The ability to access the system from remote locations
• Which of the following functions do you use most often in the
existing mail system?
1. Spell checker
2. Address book
3. Auto-forwarding
4. Grammar checker
Trần Thị Kim Chi 29
CÁC CÂU HỎI TÌM KIẾM
• Tiếp tục câu hỏi
• Có gạn lọc
• Khuyến khích mở rộng câu trả lời
• Chỉ ra những gì bạn nghe và quan tâm đến
Trần Thị Kim Chi 30
THIẾT KẾ CÂU HỎI PHỎNG VẤN
Continue question.
Expand questions
Explain what do you like?
* 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ếm
Tiếp tục câu hỏi
Có gạn lọc
Khuyến khích mở rộng câu trả lời
Chỉ 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?
Trần Thị Kim Chi 31
CÁC CHIẾN LƯỢC HỎI
High Level
Very General
Medium-Level
Moderately
Specific
Low-Level
Very Specific
TOP DOWN
BOTTOM UP
EXAMPLES?
Mức cao
rất chung
Mức trung gian
Xác định ở mức
độ vừa phải
Mức thấp
rất chi tiết
Trần Thị Kim Chi 32
CHUẨN BỊ PHỎNG VẤN
• Chuẩn bị để phỏng vấn theo cách bạn muốn biểu diễn
giống nhau
• Chuẩn bị kế hoạch phỏng vấn chung
– Danh sách câu hỏi
– Các câu trả lời biết trước và tiếp tục
– Tập hợp giữa các chủ đề liên quan
• Xác nhận lĩnh vực hiểu biết của người phỏng vấn
– Đừng hỏi những câu hỏi mà không thể trả lời
Trần Thị Kim Chi 33
CHUẨN BỊ PHỎNG VẤN
• Đặt thứ tự ưu tiên trong trường hợp thời gian
có hạn
• Phỏng vấn có cấu trúc với các câu hỏi đóng
• Đừng cố gắng thực hiện nhanh quá
– Sẽ cần tiếp tục phỏng vấn
– Người sử dụng không muốn bạn lãng phí thời gian
của họ
Trần Thị Kim Chi 34
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 cả thông tin
• Kiểm tra tổ chức cách giải quyết theo băng thu âm
• Đảm bảo bạn hiểu tất cả các kết quả 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
• Đảm bảo để cảm ơn người được phỏng vấn
• Kết thúc thời gian
Trần Thị Kim Chi 35
HƯỚNG DẪN PHỎNG VẤN
• Đừng lo lắng, sẽ may mắn
• Tập trung
• Tóm tắt những điểm chính
• Cần ngắn gọn
• Cần trung thực
• Theo dõi hình ảnh thể hiện
Trần Thị Kim Chi 36
TIẾP TỤC PHỎNG VẤN TIẾP
• Chuẩn bị ghi chép phỏng vấn
• Chuẩn bị báo cáo phỏng vấn trong khoảng 48 giờ
• Tạo sự dự trữ từ những người được phỏng vấn
• Tìm kiếm khoảng trống và những câu hỏi mới
• Nên tránh
– Những câu hỏi giữ ý kiến của bạn.
– Những câu hỏi lệch hướng (tìm một câu trả lới cụ thể).
– Những câu hỏi gây ấn tượng mạnh mẽ (giả sử trả lời trong câu hỏi)
Trần Thị Kim Chi 37
TÀI LIỆU PHỎNG VẤN
Trần Thị Kim Chi 38
TÀI LIỆU PHỎNG VẤN
Trần Thị Kim Chi 39
BÀI TẬP PHỎNG VẤN
• Find a partner for this exercise
• Think back to your ITM352 assignment #5 (e-commerce system). You
will now serve as “customer” for that project and your partner will act
as “project lead” (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
Trần Thị Kim Chi 40
BÀI TẬP PHỎNG VẤN
• Get with the same “customer” you had previously and:
• Create a questionnaire to help solicit requirements from your
customer. You must have a minimum of 4 questions, including at
least one of each of the following:
– Multiple-choice question
– Rating question
– Ranking question
• Discuss which information solicitation approach (interview,
questionnaire, or both) is more appropriate for your project (use the
table on the previous slide) and explain (briefly).
– Example: “Questionnaire fits best because we have little time,
low budget, fairly simple and unambiguous information needs,
and a large number of stakeholders to survey.”
• Switch roles and repeat
Trần Thị Kim Chi 41
BẢNG CÂU HỎI
- CÁC BƯỚC LẬP BẢNG CÂU HỎI
• Chọn người tham dự
– Sử dụng các mẫu phổ biến
• Thiết kế bảng câu hỏi
– Quan trọng hơn các câu hỏi phỏng vấn
– Ưu tiên câu hỏi cho sự chú ý
– Phân biệt giữa
• Câu hỏi hướng sự việc (câu hỏi xác định)
• Câu hỏi quan điểm (đồng ý – không đồng ý)
• Kiểm tra bảng câu hỏi trên các đồng nghiệp
Trần Thị Kim Chi 42
BẢNG CÂU HỎI
- CÁC BƯỚC LẬP BẢNG CÂU HỎI
• Thực thi bảng câu hỏi
– Cần thiết thu được tỷ lệ câu trả lời tốt
– Giải thích tầm quan trọng và nó sẽ được sử dụng như thế nào
– Đưa ra ngày trả lời mong đợi
– Đưa ra cho mọi người
– Có thể quay lại sau
– Có thể tiếp tục giám sát
– Hứa hẹn đưa ra các báo cáo kết quả
• Bảng câu hỏi tiếp tục
– Gửi kết quả cho các thành viên tham dự
Trần Thị Kim Chi 43
THIẾT KẾ BẢNG CÂU HỎI TỐT
Thiết kế bảng câu hỏi cần lưu ý các nguyên tắc sau:
1)Bắt đầu bằng câu hỏi quan trọng, nội dung hấp dẫn
2) Tránh những câu hỏi mang ý “hăm dọa”
3) Nhóm những câu hỏi cùng chủ đề một cách logic.
4) Đừng trình bày quá nhiều trong một trang
5) Tránh những câu hỏi mang tính gợi ý
6) Tránh viết tắt, tránh dùng những cụm từ/ câu hỏi
không rõ nghĩa
7) Thường không yêu cầu người trả lời ghi họ tên
8) Ghi rõ mục đích của bảng câu hỏi
Trần Thị Kim Chi 44
THIẾT KẾ BẢNG CÂU HỎI TỐT
Trần Thị Kim Chi 45
QUAN SÁT(OBSERVATION)
• Quan sát trực tiếp tại nơi làm việc, hiện trường nhằm
thu thập chính xác cách thức và qui trình làm việc
thực tế của hệ thống.
• Ưu điểm:
– Đảm bảo tính trung thực của thông tin.
– Thu thập tốt về thông tin mô tả tổng quan của hệ thống
• Hạn chế:
– Thời gian kéo dài
– Làm cho người sử dụng khó chịu
Trần Thị Kim Chi 46
QUAN SÁT(OBSERVATION)
Lưu ý khi thực hiện quan sát:
• Quan sát phải kín đáo để đảm bảo khách quan.
• Có thể quan sát định kỳ nhiều lần, đổi về thời điểm
quan sát. Các lần quan sát phải có mục đích rõ ràng.
• Thường được kết hợp với các kỹ thuật khác
Trần Thị Kim Chi 47
QUAN SÁT(OBSERVATION)
Trần Thị Kim Chi 48
BÀI TẬP QUAN SÁT
• No need to get with your partner this time! Get together with your
project team.
• In soliciting requirements for your project:
– Think of something that would be useful to observe:
a. Describe what you would observe
b. Explain why it would it be active or passive
c. Discuss what could go wrong or how it the act of observing
might bias the results (be specific here!)
– Think of what documents or systems would be useful to study for
soliciting requirements for your system
a. Describe what documents or systems you might study
b. What kinds of requirements (project, capability, etc.) would
you expect to gather from the above?
c. Discuss why it would be better to study the systems or
documents in (a) above over using observation, interview, or a
questionnaire Trần Thị Kim Chi 49
PHÂN TÍCH TÀI LIỆU
(DOCUMENTATION ANALYSIS)
• PP phân tích tài liệu và thủ tục:
– quan sát gián tiếp giúp xác định chi tiết về hệ thống hiện
hành.
– thường được sử dụng bởi những đội ngũ dự án am hiểu về
hệ thống hiện tại.
• Các loại tài liệu:
– tài liệu mô tả nhiệm vụ, các kế hoạch kinh doanh, cấu trúc
tổ chức, các tra cứu về chính sách, bản mô tả công việc, các
thư tín bên trong và bên ngoài, các báo cáo nghiên cứu,
• Thông thường phương pháp này được kết hợp với
phương pháp phỏng vấn ở mức thấp.
Trần Thị Kim Chi 50
PHÂN TÍCH TÀI LIỆU
(DOCUMENTATION ANALYSIS)
Trần Thị Kim Chi 51
PHÂN TÍCH TÀI LIỆU
(DOCUMENTATION ANALYSIS)
Phân tích tài liệu sẽ mang lại các thông tin sau:
• Các vấn đề tồn tại trong hệ thống
• Các cơ hội để hệ thống đáp ứng nhu cầu mới
• Phương hướng tổ chức có thể tác động đến các yêu cầu của
HTTT
• Lý do tồn tại của hệ thống hiện hành, những chi tiết không
được quản lý bởi hệ thống hiện hành nhưng cần thiết và khả
thi trong hệ thống mới.
• Tìm ra tên và vị trí của những cá nhân có liên quan đến hệ
thống.
• Các trường hợp xử lý thông tin đặc biệt không thường xuyên
• Dữ liệu cấu trúc, qui tắc xử lý dữ liệu, các nguyên lý hoạt
động được thực hiện bởi HTTT.
Trần Thị Kim Chi 52
PHÂN TÍCH TÀI LIỆU
(DOCUMENTATION ANALYSIS)
Nhược điểm của phân tích tài liệu:
• Các thủ tục cũng là nguồn thông tin không đúng,
trùng lắp
• Thiếu tài liệu
• Tài liệu hết hạn: dẫn đến việc phân tích tài liệu cho
một kết quả không đúng với kết quả khi phỏng vấn
Trần Thị Kim Chi 53
PHÂN TÍCH TÀI LIỆU
(DOCUMENTATION ANALYSIS)
Trần Thị Kim Chi 54
THIẾT KẾ KẾT NỐI ỨNG DỤNG
(JOINT APPLICATION DEVELOPMENT JAD)
JAD là gì?
• Đội dự án, người sử dụng, ban quản lý cùng làm việc với nhau
để xác định yêu cầu cho hệ thống.
• Do IBM đưa ra vào cuối những năm 1970
• Làm việc tập thể, từ 8-12 người, gồm:
– chuyên viên HTTT
– những người sử dụng tương lai
– những người có quyền yêu cầu và quyết định về chức năng của HTTT.
Trần Thị Kim Chi 55
THIẾT KẾ KẾT NỐI ỨNG DỤNG
(JOINT APPLICATION DEVELOPMENT JAD)
Các thành viên của JAD team
• Session leader coordinator – Người lãnh đạo
• User information