Chương 2: THU THẬP và MÔ HÌNH YÊU CẦU

1. Chương 2: THU THẬP và MÔ HÌNH YÊU CẦU THU THẬP YÊU CẦU (Requirement Capture)

2. Nội dung Mục đích của thu thập và mô hình yêu cầu Định nghĩa yêu cầu Phát hiện yêu cầu (Requirements Elicitation) Đàm phám và phê chuẩn yêu cầu (Requirements Negotiation and Validation)

3. Requirements in Context The purpose of Requirements is to: • Establish and maintain agreement with the customers and other stakeholders on what the system should do. • Give system developers a better understanding of the requirements of the system. • To define the boundaries of(delimit) the system. • Provide a basis for planning the technical contents of the iterations. • Provide a basis for estimating cost and time to develop the system. • Define a user interface of the system.

4. Định nghĩa yêu cầu "A requirement is a condition or capability to which a system must conform". Yêu cầu là các dịch vụ (services) được mong đợi của hệ thống và các ràng buộc (constraints) mà hệ thông phải tuân theo.

5. Phân loại yêu cầu Yêucầuchứcnăng (Function requirements): cáchànhđộnggìmàhệthốngcóthểthựchiệnmàkhôngxemxétcácràngbuộcvậtlý. Cácdịchvụhệthống (System services): cácchứcnăngmàhệthốngcungcấp Yêucầuvềdữliệu (Data requirements): cácdữliệumàhệthốngphảixửlý Yêucầu phi chứcnăng (Non-Function Requirements): cácràngbuộchệthống, cácthuộctínhvàmôitrườngcủahệthống. Yêucầuvềgiaodiện (Look and Feel), Yêucầuvềthựchiện (Performance), Yêucầuvềbảomật (Security), …

6. Các kỹ thuật • Requirements Elicitation: Phát hiện yêu cầu • Use Case Modelling: Lập mô hình usecase • Prototyping: Tạo mô hình phác thảo ban đầu cho các chức năng và giao diện người dùng của hệ thống

7. Phát hiện yêu cầu Mụcđích: Nhậndiệncáccánhânliênquan (stakeholders) tớidựán Tậphợpcácyêucầumàhệthôngphảithựchiện. Sắpthứtựưutiêncácyêucầu. Cácbướcthựchiện: Xácđịnhnguồncủacácyêucầu Thu thậpthông tin Hộithảođểpháthiệnyêucầu (Conduct Requirements Workshops) Prototyping Đánhgiákếtquả.

8. Xác định nguồn yêu cầu Stakeholder là các cá nhân có ảnh hưởng tới kết quả của dự án, và là các đối tượng chúng ta sẽ làm việc để thu thập thông tin. Một nguồn thông tin quan trọng khác là các tài liệu đang tồn tại của tổ chức mô tả hoạt động của hệ thống đang sử dụng Có thể là các mô hình nghiệp vụ (business models) Hoặc các biểu mẫu thương mại khác. Xác định và sắp thứ tự ưu tiên các nguồn thông tin yêu cầu.

9. Thu thập thông tin Mụcđích: Xácđịnhcáccâuhỏinàocầnđượctrảlời. Thu thậpvàviếttàiliệuchothông tin thuthậpđược. Phươngpháptruyềnthốngđểthuthậpthông tin Interviewing: Phỏngvấnkháchhàngvàchuyêngiavềlĩnhvựcliênquan. Questionnaires: Bảngcâuhỏi. Observation: Quansát. Background reading: Nghiêncứutàiliệutổchứcvàtàiliệuhệthốngphầnmềmđangtồntại.

10. Interviewing – Phỏng vấn • Phỏngvấnnhằmđạtđượchiểubiếtsâuvềmụctiêucủatổchức, vaitròvàyêucầungườidùng • Phỏngvấncấutrúc (Structured interview) • Cáccâuhỏixácđịnhtrướcvàcólịchphỏngvấnrõràng. • Phỏngvấnkhôngcấutrúc (Unstructured interview) • Gặpmặtkhôngchínhthức; câuhỏi, mụctiêukhôngđịnhtrước. • Cácloạicâuhỏinêntránh: • Opinionated: Ngườiđượcphỏngvấncho ý kiếncủamình. • Biased: Câuhỏiđịnhhướngđểtìmcâutrảlờicụthể • Imposing: Giảđịnhcâutrảlờichocâuhỏi.

11. Questionnaires - Bảng câu hỏi Nhằm đạt được thông tin từ nhiều người và kết quả có thể phân tích thống kê. Đặc điểm: Bảng câu hỏi có thể được gởi qua thư, email, hoặc dựa web Dùng thu thập ý kiến hoặc dữ kiện. Bảng câu hỏi phải được thiết kế tốt và dễ trả lời Các loại câu hỏi Câu hỏi mở: câu trả lời có thể không đoán trước được. Câu hỏi đóng: Câu trả lời được chọn từ danh sách cung cấp trước. Có thể dùng câu hỏi đóng và hạn chế câu hỏi mở Các câu hỏi đóng có thể: Multi-choice questions: Câu hỏi nhiều chọn lựa Rating questions: Câu hỏi đánh giá từ yếu tới mạnh Ranking questions: Câu hỏi xếp hạng. từ 1 – 10 hoặc tỉ lệ %

12. Observation - Quan sát Nhằm tìm kiếm điều thực sự xảy ra, không phải điều người ta nói. Bao gồm: Quan sát người ta thực hiện xử lý công việc như thế nào và điều gì xảy ra. Quan sát thụ động: Quan sát các hoạt động mà không bị dừng ngang hoặc không tham gia trực tiếp  dùng camera Quan sát chủ động: Tham gia trực tiếp vào các hoạt động xử lý thương mại. Đi theo một xử lý từ đầu đến cuối. Đạt được các dữ liệu định lượng để làm cơ sở cho các cải tiến được cung cấp bởi hệ thống mới.

13. Background reading Nhằm tìm hiểu về tổ chức và mục tiêu kinh doanh của nó. Bao gồm: Tài liệu của tổ chức Các biểu mẫu thương mại, các thủ tục làm việc, miêu tả công việc, các kế hoạch thương mại, các hướng dẫn (manuals), các biểu đồ tổ chức … Tài liệu của hệ thống đang tồn tại Các biểu mẫu (forms) và các báo cáo (reports), tài liệu người dùng, tài liệu phân tích và thiết kế hệ thống, … Các yêu cầu về tri thức của lĩnh vực liên quan Tạp chí thương mại, sách tham khảo

14. Các phương pháp hiện đại để phát hiện yêu cầu Được sử dụng khi rủi ro của dự án cao, các nhân tố rủi ro bao gồm: Mục tiêu không rõ ràng Các thủ tục làm việc không được tài liệu hóa Các yêu cầu không ổn định Người phát triển không có kinh nghiệm. Sư hợp tác củas người dùng không đầy đủ. Các phương pháp: Conduct Requirements Workshops Hội thảo phát hiện yêu cầu Prototyping Một GUI, mà mô phỏng ứng xử hệ thống

15. Hội thảo phát hiện yêu cầu Mục đích Tạo điều kiện cho nhóm dự án gặp các stakeholder của dự án Để thu thập các yêu cầu tinh tế hơn từ các stakeholder. Để sắp thứ tự các yêu cầu được tập hợp dựa trên các stakeholder tham dự hội thảo. Có thể sử dụng một số kỹ thuật phát hiện thông tin Brainstorming: Thảo luận tập thể Trong một thời gian ngắn, cho phép mọi người trình bày ý kiến, hay cảm nhận quan trọng của mình về dự án. Role playing: Đóng kịch Từng thành viên được phân một vai trò đáng quan tâm của dự án. Thảo luận và ghi nhận trách nhiệm của từng vaui trò Một kỷ thuật tổ hợp với Role playing là Class Responsibility Collaboration (CRC) cards

16. Prototyping – Tạo hệ thống phác thảo • Prototype là một hệ thống có tính trình diễn • Một mô hình làm việc “nhanh và thô” của giải pháp cho hệ thống, nhằm kiểm tra một số chức năng nào đó. • Có thể miêu tả GUI cho các ứng xử khác nhau của hệ thống. • Nột dung có thể mã cứng (hard-coded) hơn là truy cập động từ CSDL. • Không thể thiếu trong quy trình phát triển phần mềm • Tính khả thi và hữu dụng của hệ thống có thể ước lượng qua prototype trước khi thực sự được cài đặt. • Thường được dùng khi: • Hệ thống xây dựng cho các chức năng thương mại mới. • Dùng trong quá trình xây dựng kịch bản cho use case. • Các yêu cầu xung đột • Có vấn đề truyền thông giữa khách hàng và người phát triển

17. Các kiểu Prototyping “Throw-away” prototype Bỏ đi khi tiến trình tìm kiếm yêu cầu hoàn tất. Tập trung vào các yêu cầu ít hiểu biết nhất. Thường thực hiện ở bước xác định yêu cầu. Evolutionary prototype Được giữ lại sau khi tiến trình tìm kiếm yêu cầu hoàn tất Thường đưa ra cho sản phẩm cuối cùng. Hướng đến việc phát triển nhanh hệ thống bằng cách tập trung vào các yêu cầu đã hiểu biết nhất (là chung cho nhiều hệ thống)

18. Đàm phám và phê chuẩn yêu cầu Yêucầupháthiệntừkháchhàngthường: Chồngchéovàxungđột. Mơhồhoặckhôngthựctế. Mộtsốyêucầuchưađượckhámphá.  Cầnđàmphánvớikháchhàngđẩphêchuẩnyêucầutrướckhiviếttàiliệuyêucầu. Cáccôngviệcthườngphảithựchiện: Xácđịnhcácyêucầungoàiphạm vi (Out of scope requirements) Xácđịnhcácyêucầuchồngchéovàxungđột. Phântíchrủirovàsắpthựtựquyềnưutiêncácyêucầu.

19. Xác định các yêu cầu ngoài phạm vi Lànhiệmvụcủabướcphântíchyêucầunhằmxácđịnhbiênhệthống (system boudary) Cácyêucầuđượcphânloại ở ngoàiphạm vi do: Quyđịnhràngcuộccủatổchức. Giớihạncủangânquỹcủadựán. Quákhócàiđặtvàohệthốngmáytính. Cóquyềnưutiênthấpvàđượcloạirakhỏiphiênbảnđầutiêncủahệthống. Đượccàiđặttrongcácthiếtbịphầncứngkhác, nằmngoàiđiềukhiểncủahệthốngphầnmềm.

20. THU THẬP và MÔ HÌNH YÊU CẦU MÔ HÌNH YÊU CẦU HỆ THỐNG

21. Tài liệu kết quả của bước yêu cầu Use-Case Model Actors Các Use Case Các đặc tả bổ sung(Supplementary Specification) Bảng chú giải(Glossary) ... Các đặc tả Use Case(Use Case Specifications)

22. What Is a Use-Case Model? Làmôhìnhứngxửhệthống System behavior is the outwardly visible and testable activity of a system and is captured in use cases. A model that describes a system’s functional requirements in terms of use cases. A model of the system’s intended functions (use cases) and its environment (actors). Use cases describe the system, its environment, and the relationship (or interactions) between the system and its environment.

23. Lược đồ Use Case Communicationassociation Actor Use case Withdraw Client View Balance

24. Actor Actor làvaitròcủa con người, thiếtbị hay hệthốngkhác … màtươngtáctrựctiếpvớihệthống qua các use case. Ở bênngoàihệthốngvàcầncácdịchvụhệthống. Mộtvaitròkhôngphảilàmộtngườicụthể. Nhậndiệncác Actor: Ai cầnđếnmộtdịchvụnàođócungcấpbởihệthống? Hệthốngđượcdùng ở đâutrongtổchức? Ai cólợiíchtừviệcdùnghệthống? Ai sẽcungcấp, dùng, hủythông tin củahệthống? Ai hỗtrợvàbảotrìhệthống? Hệthốngcódùngcáctàinguyênbênngoài?

25. Use case Use case làmộtdãycáchànhđộngmàhệthốngthựchiệnnhằmđạtđượcmộtkếtquảvềgiátrịcóthểnhậnbiếtđượcchomột actor cụthể. Biểudiễnmộtđơnvịchứcnăngđầyđủ. Mộtđơnvịchứcnăngcóthểnhìnthấytừbênngoài Mỗi use case cóthểđượckíchhoạtbởimột actor Mộtkhikíchhoạt, nócóthểtươngtác hay cungcấpkếtquảcho actor khác. Pháthiệntừ Cácyêucầuchứcnăngđượcdiễndịchthànhcác use case Actor vàmụcđíchcủahọđốivớihệthống.

26. Quan hệ giữa actor và use case CommunicationAssociation: Biểu diễn sự truyền thông giữa actor và use case Hướng mũi tên biểu diễn ai kích hoạt việc truyền thông. Withdraw Client Bank System Client kích hoạt use case Withdraw Use case Withdraw truy cập thông tin tài khoản từ Bank System

27. Video Store case study Cho kháchhàngthuêbăngvàđĩa video Tấtcảcácbăngvàđĩađềuđượcmãvạch (bar-coded) vàdùngmộtthiếtbịquéttíchhợpvớihệthốngđểđọc. Thẻkháchhàngthànhviêncũngđượcmãvạch. Cáckháchhàngcóthẻthànhviêncóthểđặtthuêtrướccácbăng video nhận ở mộtngàycụthểnàođó. Trảlờicáccâuhỏicủakháchhàng, baogồmcảcáccâuhỏivềcácphimmàcửahàngkhôngcó 8/22/2014 27

28. Nhận diện actor Người dùng: Nhân viên (Employee) Thiết bị: Thiết bị quét (Scanning Device) 8/22/2014 28

29. Nhận diện Use Case Các chức năng kích hoạt gián tiếp bởi Employee thông qua Scanning Device: Rent Video Return Video Chức năng Employee: Reserve Video Answer Inquiry Maintain Customer Information Maintain Video Information 8/22/2014 29

30. Video Store - Use case diagram Reserve Video Rent Video Scanning Device <<depends on>> Employee Return Video Maintain Video Maintain Customer Answer Enquiry 8/22/2014 30

31. Ví dụ: Hệ thống đăng ký học phần Hệthốngmớichophépsinhviênđăngkýhọcphầnvàxemphiếuđiểmtừmộtmáytínhcánhânđượckếtnốivàomạngnộibộcủatrường. Cácgiáosưcũngcóthểtruycậphệthốngnàyđểđăngkýlớpdạyvànhậpđiểmchocácmônhọc. Trườngsẽgiữlạicơsởdữliệusẵncóvềdanhmụchọcphầnmàlưutrữtoànbộthông tin vềhọcphần. Hệthốngmớisẽđọccácthông tin họcphầntrong CSDL cũnhưngsẽkhôngcậpnhậtchúng. PhòngĐàotạosẽtiếptụcduytrìcácthông tin họcphầnthông qua mộthệthốngkhác. Đầumỗihọckỳ, sinhviêncóthểyêucầudanhsáchcáchọcphầnđượcmởtronghọckỳđó. Thông tin vềmỗihọcphần, nhưtêngiáosư, khoa, vàcáchọcphầnphầntiênquyếtsẽđượccungcấpđểgiúpsinhviênchọnlựa.

32. Sinhviênđượcchọnbốnhọcphầnđượcmởtronghọckỳtớivàcóthểchọnthêmhaimônhọcthaythếtrongtrườnghợpkhôngthểđăngkýtheonguyệnvọngchính. Cáchọcphầnđượcmởcótốiđalàlà 100 vàtốithiểulà 30 sinhviên. Cáchọcphầncóíthơn 30 sinhviênsẽbịhủy. Đầumỗihọckỳ, sinhviêncómộtkhoảngthờigianđểđăngkýcáchọcphầnmuốnhọc. Sinhviênchỉcóthểthêmhoặchủycáchọcphầnđãđăngkýtrongkhoảngthờigiannày. Khiquátrìnhđăngkýhòantất, hệthốngsẽgửithông tin đăngkýcủacácsinhviêntớihệthốngthanhtoán (billing system) đểcácsinhviêncóthểđónghọcphí. Nếumộtlớpbịhếtchỗtrongquátrìnhđăngký, sinhviênphảiđượcthôngbáovềsựthayđổitrướckhixácnhậnlịchcáchọcphầnđãđăngký. Ở cuốihọckỳ, sinhviêncóthểtruycậpvàohệthốngđểxemphiếuđiểm. Vìđiểmcủasinhviênlàthông tin nhạycảmcầnđượcgiữkín, nênhệthốngphảicócơchếbảomậtđểngănchặnnhữngtruycậpkhônghợplệ. Cácgiáosưcóthểtruycậpvàohệthốngđểđăngkýnhữnghọcphầnmàhọsẽdạy. Họcũngcóthểxemdanhsáchcácsinhviênđãđăngkývàolớpcủahọ, vàcũngcóthểnhậpđiểmsaumỗikhóahọc.

33. Nhận diện actor Người dùng: Sinh viên (Student) Giáo sư (Professor) Nhân viên giáo vụ (Registrar) Hệ thống khác: Danh mục học phần (Course Catalog) Hệ thống thanh toán học phí (Billing System)

34. Nhận diện Use Case Chức năng cho mọi actor: Đăng nhập hệ thống (Login) Các chức năng sử dụng bởi Student: Đăng ký học phần (Register for Course) Xem phiếu điểm (View Report Card) Các chức năng sử dụng bởi Professor: Đăng ký môn dạy (Select Courses to Teach) Nộp điểm (Submit Grades) Nhiệm vụ của Registrar: Kết thúc đăng ký (Close Registration) Cập nhật thông tin giáo sư (Maintain Professor Information) Cập nhật thông tin sinh viên (Maintain Student Information)

35. Login View Report Card Register for Courses Course Catalog Select Courses to Teach Student User Submit Grades Professor Maintain Professor Information Registrar Maintain Student Information Close Registration Billing System

36. Quan hệ phụ thuộc giữa các use case Quan hệ bao gồm (Include) Quan hệ mở rộng (Extend)

37. Quan hệ Include Một use case luôn luôn bao gồm dãy các ứng xử của một use case khác Được dùng để tách một dãy các ứng xử giống nhau mà được dùng bởi nhiều use case <<include>> Withdraw <<include>> List Account Client View Balance

38. Quan hệ Extend Một use case cung cấp thêm chức năng cho một use case khác Biểu diễn ứng xử tùy chọn, nhiều công việc khác nhau được thực hiện dựa vào việc chọn lựa của actor. Chỉ được kích hoạt dưới một điều kiện nào đó. Điểm mở rộng (extension points) trình bày điều kiện khi nào việc mở rộng xảy ra. <<extend>> Print Balance View Balance

39. Actor Generalization Một actor có thể tham gia vào tất cả các truyền thông với các use case mà "super actor" có, ngoài các use case khác của nó. Login User Register for Courses Student Select Courses to Teach Professor Close Registration Registrar

40. Use-Case Specifications Name Actors Brief description Flow of Events Relationships Activity diagrams Use-Case diagrams Special requirements Pre-conditions Post-conditions Other diagrams

41. Use-Case Specifications Brief description describes the role and purpose of the use case. Actors Flow of events are textual descriptions of what the system does with regard to the use case. There can be multiple flows of events — for example, a basic flow and alternative flows. Pre-conditions define a constraint on the system regarding when the use case may start. Post-conditions define a constraint on the system that applies after the use case has terminated.

42. Use-Case Specifications Relationships are communicates-associations. The use case includes and extends relationships that the use case participates in. Activity diagrams can be used to illustrate the structure of the flow of events. Use-case diagrams can be used to show the relationships involving the use case. Special requirements is a textual description that collects all use-case requirement Other diagrams can be used to illustrate the use case, like hand-drawn sketches or screen captures from an user-interface prototype.

43. Làdãycáchànhđộngmàhệthốngphảithựchiệnvàtươngtácvới actor đểthựchiện Use case Has one normal, basic flow (Main Flow or Happy Path) Several alternative flows Cácbiếnthểthườnggặp (Regular variants) Cáctrườnghợpbấtthường (Odd cases) Exceptional flows xửlýcáctìnhhuốnglỗi “Happy Path” Use-Case Flows of Events

44. Scenario là một thể hiện của use case, là một dòng sự kiện qua một use case Mỗi use case có thể có nhiều kịch bản thực hiện. Phải tìm ra một kịch bản tiêu biểu giải quyết chung cho hầu hết các trường hợp  Dòng sự kiện chính (Main Flow) Các trường hợp thay đổi khác sẽ xử lý riêng  Dòng lựa chọn hay dòng ngoại lệ (Alternative Flow) Scenarios là gì ?

45. Đặc tả use case: Rent Video Brief Description Use case nàychophépnhânviêncửahàngxửlýyêucầuthuêbănghoặcđĩa video củakháchhàng. Actors Nhânviên (Employee), Thiếtbịquét (Scanning Device) Preconditions Không Postconditions Videos đượcchokháchhàngthuêvàcơsởdữliệuđượccậpnhậttươngứng. 8/22/2014 45

46. Đặc tả use case: Rent Video (tt) Main Flow Use case bắt đầu khi khách hàng muốn thuê băng đĩa Nhân viêndùngthiếtbịquétthẻthànhviêncủakháchhàng. Hệthốngkiểmtrabăngđĩa video thuêquáhạnvàmứcđộđáng tin củakháchhàng. Nhânviênquétmãvạchcủacác video kháchhàngmuốnthuê. Sốlượngbăngđĩakháchhàngthuêtốiđalà 8. Nhânviênnhậpngàythuêvàhạntrảchotừngbảnghithuê video. Hệthốngtínhtoánvàhiểnthịlệphíthuê video. Saukhikháchhàngthanhtoán, nhânviên in biênnhậnthuê video vàchọnchứcnăng Save Hệthốngcậpnhậtcácbảnghithuê video. 8/22/2014 46

47. Đặc tả use case: Rent Video (tt) Alternative Flows Kháchhàngcó video quáhạnHệthốngsẽhiểnthịnhắcnhởvàghichú “quáhạn” tớikháchhàngvà use case kếtthúc. Nếu video khôngđượctrảtrongvòng 2 ngàykểtừhạntrả, mộtghichúkhácđượckhởitạovàkháchhàngbịghinhậnlà “đã vi phạm” (khôngđáng tin) Kháchhàngkhôngđáng tinKháchhàngsẽđượcyêucầuđóngtiềnthếchấpchotừng video thuê KháchhàngkhôngcóthẻthànhviênNhânviênsẽkíchhoạt use case Maintain Customerđểđăngkývàcấpthẻchokháchhàng. Nếunhiềuhơn 8 video đượcthuê, hệthốngsẽhiểnthịnhắcnhở. Thẻthànhviênhoặc video bịhư, máyquétkhôngthểnhậnđược, hệthốngsẽhiểnthịnhắcnhở. 8/22/2014 47

48. Viết kịch bản use case dạng 2 cột 8/22/2014 48

49. Đặc tả use case: Register for Courses • Tóm tắt • Use case này cho phép một sinh viên đăng ký các lớp học được mở trong học kỳ hiện tại. Sinh viên còn có thể cập nhật hoặc xóa các lớp học đã chọn nếu các thay đổi này diễn ra trong thời gian cho phép thay đổi đăng ký vào đầu học kỳ. • Actor • Student • Điều kiện tiên quyết • Student phải đăng nhập vào hệ thống trước khi use case bắt đầu. • Post-Conditions • Nếu use case thành công, các lớp mà sinh viên chọn học sẽ được cập nhật vào lịch học của sinh viên. Ngược lại, trạng thái của hệ thống vãn không đổi.

50. Đặc tả use case: Register for Courses Dòng sự kiện chính Use Case này bắt đầu khi một sinh viên muốn đăng ký học phần, hoặc thay đổi lịch học đã đăng ký. Hệ thống yêu cầu sinh viên chọn chức năng muốn thực hiện: Create a Schedule, Update a Schedule, Delete a Schedule. Nếu sinh viên chọn “Create a Schedule”, luồng phụ Create a Schedule được thực hiện.Nếu sinh viên chọn “Update a Schedule”, luồng phụ Update a Schedule được thực hiện.Nếu sinh viên chọn “Delete a Schedule”, luồng phụ Delete a Schedule được thực hiện.