Thu thậ̣p yêu cầu                 thâ        cầGV Phi Loan - BM HTTT - Khoa CNTT - HUI   1
Nội dung Stakeholder Các kỹ thuật thu thập yêu cầu   1. Interviewing   2. Questionaires   3. Document analysis...
A major aspect of requirements engineering is theelicitation of requirements from the customer.        GV Phi Loan - BM HT...
Stakeholder Stakeholders là những cá nhân hoặc tổ  chức tham gia vào dự án;họ là những  người có thể bị ảnh hưởng tích cự...
Phân loại stakeholder1. 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 h...
Phân loại stakeholder6. Documentation writers (người tạo ra ra sổ tay người   dùng, hệ thống trợ giúp)7. Pro...
Interview 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  ...
Một số hướng dẫn để phỏng vấn thành côngCác bước tiến hành           Các gợi ýLập kế hoạch phỏng vâ...
Phân loại câu hỏiLoại câu hỏi     Ví dụClosed-ended        How many telephone orders are received perquestions   ...
Interview: Context free question Là câu hỏi có thể dùng cho bất kz dự án nào  đang khảo sát. Là các câu ...
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 ...
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 p...
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  rồi tiến đến câu hỏi cụ t...
Questionaires Thường dùng khi cần thu thập thông tin và {  kiến từ số đông.             GV Phi Loan - BM HT...
So sánh questionaire và interviewĐặc tính                Questionaires                  InterviewsInformation richness...
Chọn người tham gia phiếu điều tra Chọn người đại diện cho mỗi nhóm Không phải ai nhận phiếu điều tr...
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...
Thiết kế phiếu điều tra Phải hiểu rõ là thông tin thu thập được từ phiếu điều  tra sẽ được phân tíc...
Good questionaire design Begin with nonthreatening and interesting questions Group items into logically coherent section...
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íc...
Document analysis Thường được các đội dự án sử dụng để tìm hiểu hệ  thống cũ. Hầu hết các hệ tho...
Document analysis Khi người dùng tự tạo biểu mẫu riêng để dùng hay bổ  sung thêm thông tin vào những bie...
Observation Được dùng để thu thập thông tin của hệ thống cũ Cho phép nhà phân tích thấy được hiện t...
Observation Quan sát thường hổ trợ thêm cho thông tin  phỏng vấn. Vị trí văn phòng, trang trí nội thất,...
Joint Application Design (JAD)         GV Phi Loan - BM HTTT - Khoa CNTT - HUI   25
Joint Application Design (JAD) JAD xuất hiện vào cuối những năm 1970, được  dùng như 1 kỹ thuật để phát t...
JAD và phương pháp cũ Bằng cách kết hợp workshop và nhấn mạnh  tinh thần cộng tác (spirit of partnership...
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ô...
Ai tham dự JAD? Executive Sponsor Facilitator User ( từ 3 – 5) IT Representative Scribe ( 1 hay 2) Observer ( 2 hay...
GV Phi Loan - BM HTTT - Khoa CNTT - HUI   30
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ươ...
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 qu...
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...
Đặc tính của JAD 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...
So sánh các kỹ thuật thu thập yêu cầu           GV Phi Loan - BM HTTT - Khoa CNTT - HUI   35
Prototype      GV Phi Loan - BM HTTT - Khoa CNTT - HUI   36
Prototype Là 1 quy trình lặp cho phép nhà phân tích và người dùng  cùng xây dựng 1 phiên bản “nháp” của h...
Khi nào nên dùng prototype Khi yêu cầu của người dùng không rõ ràng,  nhất là với những hệ thống mới...
Ưu - khuyết của Prototype Ưu điểm:    - Người sử dụng sớm hình dung ra chức năng và đặc điểm củahệ thống.    - Cải thiện...
Những rủi ro của prototype Mặc dù prototype làm giảm rủi ro của dự án phần mềm nhưng nó cũng có những rủi ro riêng của ...
Upcoming SlideShare
Loading in …5
×

Chapter 3 requirement gathering

705 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
705
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
19
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Chapter 3 requirement gathering

  1. 1. Thu thậ̣p yêu cầu thâ cầGV Phi Loan - BM HTTT - Khoa CNTT - HUI 1
  2. 2. Nội dung Stakeholder Các kỹ thuật thu thập yêu cầu 1. Interviewing 2. Questionaires 3. Document analysis 4. Observation 5. JAD (Joint Application Design) 6. Prototype GV Phi Loan - BM HTTT - Khoa CNTT - HUI 2
  3. 3. A major aspect of requirements engineering is theelicitation of requirements from the customer. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 3
  4. 4. Stakeholder Stakeholders là những cá nhân hoặc tổ chức tham gia vào dự án;họ là những người có thể bị ảnh hưởng tích cực hoặc tiêu cực bởi kết quả của dự án; họ cũng có thể là người ảnh hưởng trong toàn bộ dự án và kết quả của nó. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 4
  5. 5. Phân loại stakeholder1. 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. Requirements 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) GV Phi Loan - BM HTTT - Khoa CNTT - HUI 5
  6. 6. Phân loại stakeholder6. Documentation writers (người tạo ra ra sổ tay người dùng, hệ thống trợ giúp)7. Project managers (người lập kế hoạch cho dự án và quản l{ đội phát triển phần mềm)8. Legal staff ( người bảo đảm sản phẩm phù hợp với luật và quy chế)9. Manufacturing people (người phải xây dựng sản phẩm có chứa phần mềm)10. 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. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 6
  7. 7. Interview 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 và mong muốn trong hệ thống mới Questionnaire không thể thay thế cho interview. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 7
  8. 8. Một số hướng dẫn để phỏng vấn thành côngCác bước tiến hành Các gợi ýLập kế hoạch phỏng vấn - Lập lịch hẹn và giải thích mục địch phỏng vấn với người được phỏng vấn - Chuẩn bị agenda, các câu hỏi,..Giữ thái độ trung lập Tránh hỏi các câu hỏi gây ảnh hưởng đến(neutral) người được phỏng vấnLắng nghe và ghi tóm tắt Tập trung nghe người được phỏng vấn, ghilại chép lại hoặc ghi âm lại (nều được cho phép)Xem lại kết quả phỏng vấn Xem lại trong vòng 48 giờ, nếu phát hiện có câu hỏi cần thông tin phụ -> gặp gỡ lại người được phỏng vấnNên phỏng vấn nhiều loạingười khác nhau GV Phi Loan - BM HTTT - Khoa CNTT - HUI 8
  9. 9. Phân loại câu hỏiLoại câu hỏi Ví dụClosed-ended How many telephone orders are received perquestions day? How do customers place orders?Open-ended What do you think about the current system?questions What are some of the problems you face on a daily basis? How do you decide what types of marketing campaigns to run?Probing Why?questions Can you give me an example? Can you explain that in a bit moree detail? GV Phi Loan - BM HTTT - Khoa CNTT - HUI 9
  10. 10. Interview: Context free question Là câu hỏi có thể dùng cho bất kz 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. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 10
  11. 11. 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. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 11
  12. 12. 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. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 12
  13. 13. 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 rồi tiến đến câu hỏi cụ thể Bottom-up: ngược lại GV Phi Loan - BM HTTT - Khoa CNTT - HUI 13
  14. 14. Questionaires Thường dùng khi cần thu thập thông tin và { kiến từ số đông. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 14
  15. 15. So sánh questionaire và interviewĐặc tính Questionaires InterviewsInformation richness Medium to low HighTime require Low to moderate Can be extensiveExpensive Moderate Can be highChance for follow-up Good Limitedand probingConfidentiality Interviewee is known to Respondent can be interviewer unknownInvolvement of Interviewee is involved and Respondent is passive,subject committed no clear commitmentPotential audience Limited numbers Can be quite large GV Phi Loan - BM HTTT - Khoa CNTT - HUI 15
  16. 16. Chọn người tham gia phiếu điều tra 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. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 16
  17. 17. 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 Hai dạng câu hỏi:  Hướng { kiến (opinion): thường yêu cầu người trả lời (respondent) phải cho biết mức đô mà họ đồng tình hay phản đối với câu hỏi.  Vd: Network problems are common  Hướng số liệu (fact-oriented): câu trả lời là 1 giá trị cụ thể  Vd: How often does a network problem occur: once an hour, once a day, or once a week? GV Phi Loan - BM HTTT - Khoa CNTT - HUI 17
  18. 18. Thiết kế phiếu điều tra Phải hiểu rõ là thông tin thu thập được từ phiế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 phiếu điều tra xong rồi mới phát hiện phiếu đ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 phải đọ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 thử trước khi phân phối. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 18
  19. 19. Good questionaire design Begin with nonthreatening and interesting questions Group items into logically coherent sections Do not put important items at the very end of the questionaire Do not crows a page with too many items Avoid abbreviations Avoid biased or suggesstive items or terms Number questions to avoid confusion Pretest the questionaire to identify confusing questions GV Phi Loan - BM HTTT - Khoa CNTT - HUI 19
  20. 20. 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 lạ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 GV Phi Loan - BM HTTT - Khoa CNTT - HUI 20
  21. 21. Document analysis Thường được các đội dự án sử dụng để tìm hiểu hệ thống cũ. Hầu hết các hệ thống đều có tài liệu và mô hình kèm theo. Các tài liệu thường diễn tả hệ thống 1 cách chính quy (formal system) nhưng hệ thống thực (real system) lại khác xa  cung cấp những chỉ số cho biết cái gì cần được thay đổi trong hệ thống mới.  Ví dụ: những biểu mẫu nào mà hiện tại không dùng đến thì nên loại bỏ đi trong hệ thống mới GV Phi Loan - BM HTTT - Khoa CNTT - HUI 21
  22. 22. Document analysis Khi người dùng tự tạo biểu mẫu riêng để dùng hay bổ sung thêm thông tin vào những biểu mẫu có sẵn của tổ chức  hệ thống cũ cần phải thay đổi Khi người dùng phải truy xuất đến nhiều report khác nhau để có được thông tin họ cần dùng  thông tin cần được định dạng lại trong hệ thống mới GV Phi Loan - BM HTTT - Khoa CNTT - HUI 22
  23. 23. Observation Được dùng để thu thập thông tin của hệ thống cũ Cho phép nhà phân tích thấy được hiện thực hơn là chỉ nghe từ những người được phỏng vấn hay trả lời. Nhiều nghiên cứu cho thấy: nhà quản l{ thường không nhớ họ làm như thế nào và họ dùng thời gian ra sao. Nhà phân tích như anthropologist (nhân loại học) quan sát mọi hoạt động nghiệp vụ của tổ chức. Để có thể quan sát được công việc thông thường hàng ngày, không nên gây chú { hoặc cắt ngang công việc của mọi người. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 23
  24. 24. Observation Quan sát thường hổ trợ thêm cho thông tin phỏng vấn. Vị trí văn phòng, trang trí nội thất,.. sẽ cho manh mối về quyền lực, ảnh hưởng của 1 người đến tổ chức , có thể úng hộ hay bác bỏ thông tin có được từ phỏng vấn. Ví dụ: nhà phân tích có thể trở nên hoài nghi với 1 ai đó khi tuyên bố là thường xuyên sử dụng hệ thống cũ nhưng máy tính không bao giờ được bật mỗi lần nhà phân tích ghé thăm. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 24
  25. 25. Joint Application Design (JAD) GV Phi Loan - BM HTTT - Khoa CNTT - HUI 25
  26. 26. Joint Application Design (JAD) JAD xuất hiện vào cuối những năm 1970, được dùng 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 ban lãnh đạo dự án và người dùng cuối trong cơ chế của 1 hội thảo (workshop), để cùng thống nhất (consensus) với nhau các yêu cầu của hệ thống. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 26
  27. 27. JAD và phương pháp cũ Bằng cách kết hợp workshop và nhấn mạnh tinh thần cộng tác (spirit of 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. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 27
  28. 28. 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 GV Phi Loan - BM HTTT - Khoa CNTT - HUI 28
  29. 29. Ai tham dự JAD? Executive Sponsor Facilitator User ( từ 3 – 5) IT Representative Scribe ( 1 hay 2) Observer ( 2 hay 3) GV Phi Loan - BM HTTT - Khoa CNTT - HUI 29
  30. 30. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 30
  31. 31. 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. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 31
  32. 32. 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 GV Phi Loan - BM HTTT - Khoa CNTT - HUI 32
  33. 33. 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. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 33
  34. 34. Đặc tính của JAD 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. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 34
  35. 35. So sánh các kỹ thuật thu thập yêu cầu GV Phi Loan - BM HTTT - Khoa CNTT - HUI 35
  36. 36. Prototype GV Phi Loan - BM HTTT - Khoa CNTT - HUI 36
  37. 37. Prototype Là 1 quy trình lặp cho phép nhà phân tích và người dùng cùng xây dựng 1 phiên bản “nháp” của hệ thống thông tin dựa vào các phản hồi từ phía nguời dùng. Dựa vào những thông tin cơ bản thu thập được từ các kỹ thuật khác, nhà phân tích thiết kế nhanh 1 phiên bản ban đầu và để người dùng view and test, đưa ra các thông tin phản hồi (feedback): thay đổi yêu cầu trước đó hay bổ sung thêm các yêu cầu mới. Nhà phân tich thiết kế lại prototype và quy trình người dùng chạy thử  feedback cải tiến prototype lặp lại cho đến khi nhà phân tích nắm rõ yêu cầu của hệ thống GV Phi Loan - BM HTTT - Khoa CNTT - HUI 37
  38. 38. Khi nào nên dùng prototype Khi yêu cầu của người dùng không rõ ràng, nhất là với những hệ thống mới Các stakeholder và người dùng rất quan tâm đến hệ thống đang phát triển Yêu cầu về thiết kế quá phức tạp, các biểu mẫu chi tiết cần được xem xét Có sẵn các tool và data rất thuận tiện để xây dựng prototype. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 38
  39. 39. Ưu - khuyết của Prototype Ưu điểm: - Người sử dụng sớm hình dung ra chức năng và đặc điểm củahệ thống. - Cải thiện sự liên lạc giữa nhà phát triển và người sử dụng. Nhược điểm: - Khi prototype không chuyển tải hết các chức năng, đặc điểmcủa hệ thống phần mềm thì người sử dụng có thể thất vọng vàmất đi sự quan tâm đến hệ thống sẽ được phát triển. - Prototype thường được làm nhanh, thậm chí vội vàng, theokiểu "hiện thực - sửa" và có thể thiếu sự phân tích đánh giá mộtcách cẩn thận tất cả khía cạnh liên quan đến hệ thống cuối cùng. GV Phi Loan - BM HTTT - Khoa CNTT - HUI 39
  40. 40. Những rủi ro của prototype Mặc dù prototype làm giảm rủi ro của dự án phần mềm nhưng nó cũng có những rủi ro riêng của nó:  Người dùng quá quan tâm đến giao diện bên ngoài của hệ thống như thế nào, không tập trung vào các chức năng.  Người dùng sẽ suy luận ra việc thực thi của sản phẩm cuối cùng từ việc thực thi của prototype.  Chú { đến các hoạt động của prototype, nó có thể làm tốn nhiều sự nổ lực: đội phát triển làm thêm giờ, tập trung đưa ra các prototype GV Phi Loan - BM HTTT - Khoa CNTT - HUI 40

×