Phân tích yêu cầu phần mềm
Lecture 4: Thu thập yêu cầu
(cid:31) Ranh giới (Boundaries) (cid:170) Phạm vi của vấn đề
(cid:31) Các đối tác (Stackholders)
(cid:170) Xác định những người làm chủ vấn đề
(cid:31) Mục tiêu (Goals)
(cid:170) Định nghĩa các tiêu chuẩn thành công
(cid:31) Kịch bản (Scenarios)
(cid:170) Sử dụng các ví dụ cụ thể để hiểu vấn đề
1
Phân tích yêu cầu phần mềm
Nhà phân tích yêu cầu là cầu nối giao tiếp giữa khách hàng và các đối tác của sự phát triển.
Chúng ta bắt đầu từ đâu ?
(cid:31) Xác định vấn đề
(cid:170) Mục tiêu của dự án là gì ? (cid:170) Sự nhìn nhận của người nêu ra nó ?
(cid:190) e.g., “Lập lịch họp hiện giờ thì quá tốn kém”
(cid:31) Phạm vi vấn đề
(cid:170) Cung cấp phạm vi bàn bạc vấn đề ?
(cid:190) e.g. “Xây dựng hệ thống lập lịch họp”, …hoặc… (cid:190) e.g. “Xây dựng hệ thống quản lý lịch làm việc của nhân viên”…hoặc…
(cid:31) Định nghĩa kịch bản cho giải pháp
(cid:170) Đặt vấn đề - tiến trình tương thích để giải quyết nó ?
(cid:190) e.g. “Một ai đó muốn lập lịch họp thì phải đến gặp thư ký, viết các chi tiết
vào sổ tay thư ký và để lại”, …hoặc… (cid:31) Phạm vi giải pháp
(cid:170) Nêu quá trình xử lý – phần nào sẽ phải được làm tự động và như thế nào ?
(cid:190) e.g. “Máy tính cần lập lịch một cách chi tiết, đầu ra là một giải
pháp”…hoặc…
(cid:190) e.g. “Giải pháp đạt đến bằng giao tiếp giữa thư ký và máy tính”…hoặc…
2
Phân tích yêu cầu phần mềm
Làm rõ các yêu cầu
(cid:31) Điểm bắt đầu
(cid:170) Một số ý kiến cho rằng có một “vấn đề” cần giải quyết
W6H Kỹ thuật của các nhà báo:
(cid:190) e.g. Không hài lòng với tình trạng công việc hiện tại (cid:190) e.g. Một cơ hội kinh doanh mới (cid:190) e.g. Một tiềm năng hứa hẹn sẽ tiết kiệm được về chi phí,
thời gian, tài nguyên sử dụng, etc.
(cid:31) Cần thu thập đủ thông tin để: (cid:170) Định nghĩa được “vấn đề” :
(cid:190) (Which) Vấn đề nào cần được giải quyết ? (Ranh giới - Boundaries) (cid:190) (Where) Vấn đề ở đâu ? (hiểu ngữ cảnh/ phạm vi vấn đề
What? Where? Who? Why? When? How? (Which?)
– Context/Problem Domain) (cid:190) (Whose) Vấn đề của ai? (Định nghĩa các Đối tác - Stakeholders) (cid:190) (Why) Tại sao cần giải quyết? (Định nghĩa Mục tiêu đối tác – ‘stakeholders’ Goals) (cid:190) (How) Hệ thống phần mềm sẽ hỗ trợ như thế nào? (Thu thập Kịch bản - Scenarios) (cid:190) (When) Khi nào cần phải giải quyết ? (Định nghĩa các ràng buộc phát triển
– Development Constraints)
(cid:190) (What) Điều gì ngăn chặn việc giải quyết chúng? (Định nghĩa tính khả thi và độ rủi ro
- Feasibility and Risk)
(cid:170) Là chuyên gia trong phạm vi của vấn đề
(cid:190) Nghiên cứu khoanh vùng bao quanh vấn đề mới một cách nhanh chóng (cid:190) Dùng sự ngơ ngác (ban đầu) của bạn như một lý do để đặt những câu hỏi (cid:190) Nhận biết lĩnh vực chuyên môn của người đang nói chuyện với bạn
3
Phân tích yêu cầu phần mềm
Nhận dạng vấn đề
(cid:31) Vấn đề còn mơ hồ bởi chính khách hàng:
(cid:170) E.g. Cửa hàng bán sách của Trường:
(cid:190) Người quản lý muốn tin học hóa việc điền vào một form yêu cầu mua sách thay vì nhận yêu cầu bằng lời nói;
(cid:170) E.g. Một công ty bảo hiểm lớn:
(cid:190) Người quản lý bồi thường muốn giảm thời gian trung bình của một hồ sơ bồi thường bảo hiểm từ 2 tháng xuống 2 tuần.
(cid:170) E.g. Một công ty viễn thông:
trữ khách hàng của một số chi nhánh thành một hệ thống duy nhất.
(cid:190) Một CIO (Chief of Information Officer) muốn tích hợp hệ thống hiện có với hệ thống lưu
(cid:170) E.g. Trạm không gian vũ trụ của chính phủ (Government Aerospace Agency)
(cid:31) Thường chỉ thấy ‘triệu chứng’ hơn là ‘nguyên nhân’:
(cid:190) Tổng thống muốn gửi một phái đoàn đến sao Hỏa (Mars) vào năm 2020
(cid:170) E.g. “Bệnh nhân ở Trung tâm ung bướu muốn chụp X-ray phải chờ hàng tháng” (cid:170) Thời gian chờ chỉ là biểu hiện, không phải vấn đề. Vấn đề phải là:
(cid:190) Thiếu máy X-ray; (cid:190) Thiếu đội ngũ chuyên môn; (cid:190) Thiếu bác sĩ xử lý dữ liệu (cid:190) Cách lập lịch hẹn không hiệu quả
4
Phân tích yêu cầu phần mềm
Các nguồn bổ sung yêu cầu
(cid:31) Mô hình tiến trình yêu cầu của Volere gợi ý một số nguồn bổ sung yêu cầu như sau :
5
Phân tích yêu cầu phần mềm
Các đối tác (Stackholders)
(cid:31) Xác định đối tác
(cid:170) Tất cả những người được hỏi ý kiến trong suốt quá trình thu nhận thông tin cho hệ thống.
(cid:31) Ví dụ về đối tác
(cid:170) Người dùng (Users) (cid:170) Nhà thiết kế (Designers) (cid:170) Nhà phân tích hệ thống (Systems analysts) (cid:170) Đội ngũ huấn luyện và hỗ trợ người dùng (Training and user support staff) (cid:170) Nhà phân tích kinh doanh (Business analysts) (cid:170) Các tác giả kỹ thuật (Technical authors) (cid:170) Người quản lý dự án (The project manager) (cid:170) ”Khách hàng” (“The customer”)
6
Phân tích yêu cầu phần mềm
Tìm kiếm đối tác : Biểu đồ Org
(cid:31) Sự tổ chức của biểu đồ chỉ ra
(cid:170) Vùng trách nhiệm (dồn theo hướng đi lên) (cid:170) Tuyến phân quyền (giao phó theo hướng đi xuống)
(cid:31) Đây là một công cụ nhằm chỉ rõ các đối tác ở đâu
(cid:170) …Nhưng cần nhớ rằng hầu hết các hoạt động đều phải bao gồm sự liên kết ngang qua biểu đồ org
7
Phân tích yêu cầu phần mềm
Các cấp độ phân quyền
(cid:31) Quản trị cấp cao (top) (cid:170) Thiết lập các mục tiêu (cid:170) Lập kế hoạch trên phạm vi rộng (cid:170) Xác định thị trường mới và sản phẩm
cần phát triển
(cid:170) Quyết định đối tượng liên doanh và kết
quả đạt được.
(cid:31) Quản trị trung gian (middle) (cid:170) Sắp đặt các mục tiêu (cid:170) Phân phối & kiểm soát tài nguyên (cid:170) Thực hiện kế hoạch (cid:170) Đo lường sự thực thi (cid:31) Quản trị cấp thấp (lower) (cid:170) Giám sát hoạt động hàng ngày (cid:170) Điều chỉnh các hành động khi cần
thiết.
(cid:31) Cấp vận hành (cid:170) Thực hiện các hoạt động hàng ngày
8
Phân tích yêu cầu phần mềm
Xác định mục tiêu các đối tác
Source: Adapted from Anton, 1996
(cid:31) Cách tiếp cận
(cid:170) Tập trung vào việc tại sao một hệ thống thì cần đến
(cid:170) Phát biểu ‘tại sao’ như là một tập mục tiêu của đối tác (cid:170) Dùng cách tinh chế mục tiêu để đạt được sự đặc tả cho các yêu cầu (cid:170) Phân tích mục tiêu (cid:170) Phát triển mục tiêu (cid:170) Phân cấp mục tiêu chỉ ra sự tinh chế (refinements) và sự chuyển đổi (alternatives) (cid:31) Thuận lợi (cid:170) Mang tính trực quan (cid:170) Việc khai báo rõ ràng các mục tiêu sẽ cung cấp một nền tảng hợp lý để giải quyết các mâu thuẫn (cid:31) Bất lợi (cid:170) Chỉ bắt được một hình ảnh tĩnh – liệu rằng mục tiêu sẽ có thay đổi theo thời gian? (cid:170) Có thể có xu hướng lên (hoặc xuống) mãi trên sự phân cấp mục tiêu
9
Phân tích yêu cầu phần mềm
Mô hình hóa mục tiêu
(cid:31) Mục tiêu cố định (Hardgoals)
(cid:31) Các tác nhân (agents):
(cid:170) Là người chủ của các mục tiêu (cid:170) Lựa chọn khi nào thì gán các mục tiêu vào tác nhân:
(cid:190) Xác định tác nhân trước, và tiếp đến
là mục tiêu của chúng
(cid:31) Mục tiêu linh hoạt (Softgoals): (cid:170) Không thể thực sự đáp ứng một cách đầy đủ. E.g. Tính chính xác, Độ thực thi, Tính bảo mật, …
(cid:31) Cũng có thể phân lớp một cách
(cid:170) Mô tả các chức năng cần phải thực hiện. (cid:190) Sự đáp ứng các mục tiêu (cid:190) Việc thông tin các mục tiêu
tạm thời:
(cid:190)Chạm tới một số trạng thái mong muốn sau cùng
(cid:170) Mục tiêu hoàn tất/ngừng
(cid:190)Giữ một số đặc tính không thay đổi
(cid:170) Mục tiêu duy trì/bỏ đi
(cid:31) Lời khuyên khi mô hình hóa: (cid:170) Các nguồn phức tạp thì tốt hơn cho mục tiêu (cid:170) Các đối tác liên đới với mỗi mục tiêu - (cid:170) Dùng kịch bản để khảo sát sự đáp ứng của các mục tiêu (cid:170) Xem xét kỹ lưỡng các trở ngại để giúp suy ra những ngoại lệ
(cid:190)Một tiêu chuẩn để chọn lựa hành vi
(cid:190) Xác định mục tiêu trước, và sau đó chỉ định chúng cho các tác nhân trong suốt quá trình hoạt động
(cid:170) Mục tiêu tối ưu
10
Phân tích yêu cầu phần mềm
Ví dụ : Cách phát sinh mục tiêu (Cây mục tiêu)
11
Phân tích yêu cầu phần mềm
Mô hình mục tiêu
(cid:31) Sự phát sinh mục tiêu
(cid:170) Câu hỏi “Tại sao? (Why)” khảo sát các mục tiêu cao hơn (ngữ cảnh) (cid:170) Câu hỏi “Như thế nào? (How)” khảo sát các mục tiêu thấp hơn (hoạt động) (cid:170) Câu hỏi “Cái khác thì thế nào ?(How else)” khảo sát các chọn lựa
(cid:31) Quan hệ giữa các mục tiêu:
(cid:170) Một mục tiêu hỗ trợ đạt đến cái khác (+) (cid:170) Một mục tiêu làm hại sự đạt đến cái khác (-) (cid:170) Một mục tiêu phát sinh cái khác (++)
(cid:170) Một mục tiêu ngăn chặn cái khác (--)
(cid:190) Đạt được mục tiêu A thì chắc chắn đạt được mục tiêu B
(cid:170) Thứ tự ưu tiên – khi các mục tiêu phải đạt đến theo một thứ tự cụ thể (cid:31) Phân tích trở ngại:
(cid:170) Mục tiêu này có thể bế tắc hay không, nếu vậy thì thế nào? (cid:170) Hậu quả của việc bế tắc này là gì ?
(cid:190) Đạt được mục tiêu A thì ngăn chặn đạt được mục tiêu B
12
Phân tích yêu cầu phần mềm
Mục tiêu linh hoạt (SoftGoals)
(cid:31) Một số mục tiêu có thể không bao giờ được đáp ứng một cách đầy đủ
(cid:170) Xem những mục tiêu này như mục tiêu linh hoạt (cid:190) E.g. “hệ thống dễ sử dụng”; “truy cập an toàn” (cid:190) Cũng được biết như là ‘các yêu cầu phi chức năng’; ‘các yêu cầu chất lượng’ (cid:170) Sẽ xem xét những thứ góp phần làm đáp ứng các mục tiêu linh hoạt (cid:170) E.g. Đối với một hệ thống xe lửa:
13
Phân tích yêu cầu phần mềm
Softgoals như các tiêu chuẩn lựa chọn
14
Phân tích yêu cầu phần mềm
Kịch bản (Scenarios)
Source: Adapted from Dardenne, 1993
(cid:31) Kịch bản (cid:170) Mô tả hệ thống sẽ được dùng như thế nào trong thực tế, là dòng đặc tả giao tiếp giữa người thực hiện và hệ thống. (cid:170) Rất hữu ích cho việc thu thập yêu cầu vì con người có thể quan hệ dễ dàng hơn là các câu lệnh trừu tượng khi họ yêu cầu từ hệ thống (cid:170) Có khuynh hướng ngắn gọn (e.g từ 3 đến 9 bước) (cid:170) Có thể là kịch bản động (yêu cầu có hành vi) hoặc tĩnh (không cần sự tương tác) (cid:170) Có thể trình diễn (mô tả hệ thống hiện tại) hoặc suy diễn (nó sẽ thực hiện thế nào) (cid:31) Thuận lợi (cid:170) Rất tự nhiên: các đối tác có khuynh hướng sử dụng chúng một cách tự động
tôi?”
(cid:190) E.g “giả sử tôi phải đi bệnh viện – chuyện gì xảy ra trong suốt thời gian nhập viện của
trình thẻ bảo hiểm y tế của bạn và nói rõ vì sao bạn đến bệnh viện. Sau đó, …” (cid:170) Các kịch bản ngắn thì rất tốt cho việc minh họa các giao tiếp cụ thể (cid:31) Bất lợi (cid:170) Thiếu cấu trúc
(cid:170) Khó để kiểm tra tính hoàn thiện
(cid:190) Câu trả lời thông thường: “Bạn, hoặc người đi cùng bạn đến bàn tiếp nhận. Bạn phải
15
Phân tích yêu cầu phần mềm
Ví dụ về kịch bản (1)
Chủ đề: Sắp xếp lịch họp thành công dùng tùy chọn gửi tin nhắn
Thành viên: Nam (người đề nghị, không tham dự); Bảo, Cang, Dung (tham dự)
Hành động
Mục tiêu cần thỏa
Trở ngại / Vấn đề
Yêu cầu họp;
Liệu khung thời gian đã chọn có thể không thực hiện được ?
b1: Nam yêu cầu cuộc họp, nêu thành viên, khung thời gian
Danh sách thành viên
Họ không có mặt ở đó ?
?
b2: Thư ký của Nam gủi tin nhắn đến các thành viên Bảo, Cang, Dung
b3: Bảo đọc tin nhắn
Cang đọc tin nhắn
Thông tin đến các thành viên
Không thể phát hiện được khi tin nhắn được đọc, điều gì xảy ra khi Bảo đọc nhưng không phản hồi?
Dung đọc tin nhắn
b4: Bảo phản hồi với lịch đề nghị
Liệu các lịch đề nghị có loại trừ lẫn nhau?
Cang phản hồi với lịch đề nghị
Nhận được lịch đề nghị của các thành viên
Dung phản hồi với lịch đề nghị
Chúng ta sẽ cho phép ai ưu tiên cao hơn?
Xác định phòng họp có thể;
b5: Thư ký của Nam lập lịch cuộc họp
Đăng ký phòng
Thông báo cuộc họp;
b6: Thư ký của Nam lưu ý Nam, Bảo, Cang, Dung về thời gian và địa điểm cuộc họp
Xác nhận lại với các thành viên (?)
Làm thế nào để biết chắc họ đã đọc được thông báo? Liệu lịch cuộc họp đã không còn thích hợp nữa cho ai đó trong số họ?
16
Ví dụ về kịch bản (2a)
Chủ đề: Phân tích giao dịch bán hàng trong siêu thị
Thành viên: Nhân viên bán hàng, Hệ thống
: Scenario thường (trường hợp không có lỗi) b1: Nhân viên bán hàng nhập vào username và password b2: Hệ thống kiểm tra username và password b3: Hệ thống đưa ra thông báo cho biết người dùng đã đăng nhập thành công b4: Hệ thống đưa ra chức năng tương ứng với quyền của nhân viên này. b5: Khi khách hàng mang hàng hóa đến, nhân viên tiến hành quét mã vạch của từng món hàng b6: Tính tiền cho khách hàng sau khi hệ thống quét hết mã vạch b7: Nhập vào số tiền mà khách hàng đưa b8: Nhấp vào nút “Tính” trên menu để hệ thống tính số tiền thừa trả lại cho khách hàng b9: Nhấp nút “In” để in ra hóa đơn.
17
Ví dụ về kịch bản (2b)
Chủ đề: Phân tích giao dịch bán hàng trong siêu thị
Thành viên: Nhân viên bán hàng, Hệ thống : Altenate Scenario (trường hợp có lỗi xảy ra) A1: Username và Password không đúng (chuỗi A1 bắt đầu từ b2) b3: Hệ thống báo lỗi không đăng nhập được b4: quay về b1 A2: Mã vạch không hợp lệ (chuỗi A2 bắt đầu từ b6) b7: Hệ thống đưa ra thông báo lỗi mã vạch cho nhân viên biết b8: quay lại b6 A3: Nhập vào số tiền không đúng (chuỗi A3 bắt đầu từ b7) b8: Hệ thống thông báo lỗi vì số tiền nhập vào không đúng b9: quay lại b7 A4: Số tiền nhập vào nhỏ hơn số tiền cần trả (chuỗi A4 bắt đầu từ b7) b8: Hệ thống thông báo lỗi vì không thể tính tiền b9: quay lại b7
18
Kết luận
(cid:31) Phạm vi thì rất quan trọng (cid:170) Phạm vi vấn đề bạn cần giải quyết là gì? (cid:170) Phạm vi của giải pháp mong muốn là gì?
(cid:31) Hỏi các câu hỏi Ai? (Who) và Tại sao? (Why) (cid:170) Ai là các đối tác chủ yếu ? (cid:170) Tại sao họ muốn vấn đề này được giải quyết? (cid:170) Phân tích mục tiêu của họ.
(cid:31) Hỏi các câu hỏi Như thế nào?(How) (cid:170) Phải đáp ứng mỗi mục tiêu như thế nào? (cid:170) Một hệ thống mới cần được cải tiến những điều gì?
(cid:170) Phát triển các kịch bản
.
