Giáo trình thu nhận yêu cầu

cầu Ma trận CRUD ™ Viết tắt của Create, Read, Update, Delete. ™ Ma trận CRUD cho sự tương quan giữa các hoạt động của hệ thống với các thực thể dữ liệu giúp t biết đượ mỗi m dữ liệ đượ t o đọ ậpa c ục u c ạ , c, c nhật, xóa ở đâu và như thế nào. 9 Thu nhận yêu cầu CRUD cho hệ thống theo dõi hóa chất Requester ??? 10 Thu nhận yêu cầu Kiểm tra ™ Có ký tự nào trong 5 ký tự CRUD không xuất hiện t 1 ột à đó khô ?rong c n o ng ƒ Một cột không có ký tự C Æ đối tượng được cập nhật mà không bao giờ được tạo ra? Nếu vậy chúng được tạo ra từ đâu? 11 Thu nhận yêu cầu Phân tích ™ Cột Requester không chứa D, không có use case à ó thể ó R t B khả ă ản o c x a eques er. a n ng x y ra: 1. Deleting a Requester is not an expected function of the Chemical Tracking System . 2. We are missing a use case that deletes a Requester. 3. The "Edit Requesters" use case is incorrect. 12 Thu nhận yêu cầu Khi nào thì kết thúc? ™ Nếu người dùng không thể nghĩ ra thêm 1 use à khácase n o c. ™ Nếu người dùng đề nghị các use case mới nhưng thự tế húng ó thể đượ diễn á e ec c c c suy c c us cas khác. ™ Nếu người dùng lặp lại các vấn đề đã được xét đến trong các lần thảo luận trước đó. ™ Nếu các tính chất yêu cầu người dùng yêu cầu , , chức năng mới được đề nghị nằm ngoài phạm vi dự án. 13 Thu nhận yêu cầu Khi nào thì kết thúc? ™ Nếu các yêu cầu mới được đề nghị có độ ưu tiên thấp. ™ Nếu người dùng đưa ra các khả năng có thể đôi khi xuất hiện trong sản phẩm. ™ Tạo một bảng kiểm (checklist) của các miền chức năng chung. ƒ Tạo checklist bao gồm error logging, backup and restore, access security, reporting, printing, preview capabilities, and configuring user preferences. ƒ So sánh định kỳ danh sách này với các chức năng đã xác định của hệ thống. Nếu không tìm thấy vấn đề ( ) à ó hĩ là hú t đã hâ tí hgap n o c ng a c ng a p n c xong. 14 Thu nhận yêu cầu Phát hiện và phân tích 15 Thu nhận yêu cầu 3. Phân loại và sắp xếp yêu cầu ™ Prioritization and Ranking of Requirements ™ Phân loại ưu tiên là gán mức độ quan trọng cho yêu cầu bắng cách dùng thẻ (tag) hay nhãn (l bel)a ™ Phân loại ưu tiên thường được xác định ngay khi bắt đầu dự án ™ 1 có nghĩa là quan trọng nhất và 5 là ít quan trọng nhất . ™ Sắp xếp là gán 1 thứ tự duy nhất cho mỗi yêu cầu trong 1 nhóm, sao cho không có 2 yêu cầu nào có cùng thứ tự 16 Thu nhận yêu cầu Khi nào dùng? ™ Sắp xếp xác định tính năng cần có trong sản hẩ ẽ hát hà hp m s p n ™ Phân loại ưu tiên thường được dùng khi xác định ph m i b n đầ ủ hệ thốngạ v a u c a . 17 Thu nhận yêu cầu Các lưu ý • Khi phân phối bảng câu hỏi hay phiếu điều tra cho khá h hà thườ l ô ó â hỏi là ê h độc ng ng u n c c u n n c ọn ưu tiên nào cho 1 tính năng nào đó của hệ thống More likely to buy the product no difference less• , , likely to buy the product. • Một vấn đề chung hay xảy ra khi để khách hàng đánh giá yêu cầu với 3 mức ưu tiên là cao, trung bình hay thấp thì một số khách hàng sẽ luôn gán độ ưu tiên là cao cho mọi yêu cầu. 18 Thu nhận yêu cầu Các kỹ thuật phân loại ưu tiên ™ Xử lý cấp bậc (Analytic Hierarchy Process – AHP h i i ki )ay pa rw se ran ng ™ Trò chơi lập kế hoạch (Planning Game - PG) 19 Thu nhận yêu cầu Xử lý cấp bậc ™ Để xếp loại yêu cầu, Stakeholder hay nhà phân tí h tì 2 ê ầ á h hú à đá h iác m y u c u, so s n c ng v n g chúng để tìm ra cái nào quan trọng hơn. Quy trình này sẽ lập lại cho đến khi tất cả yêu cầu được xếp loại. ™ Phương pháp này chỉ thích hợp cho những tập hợp yêu cầu không quá lớn. ™ Vì các stakeholder khác nhau có thể xếp loại yêu cầu rất khác nhau, nên tạo qui tắc để thống nhất nhất các tập yêu cầu được đánh giá khác nhau 20 Thu nhận yêu cầu Trò chơi lập kế hoạch ™ Các yêu cầu của stakeholder, các tính năng hay ê ầ ủ ả hẩ đượ hâ hi thà h 3y u c u c a s n p m c p n c a n tập hợp theo tiêu chuẩn Kano: ™“needed for the system to function” ™“add real value” ™“nice to have but not necessary” ™ Thực hiện 1 phân tích rủi ro không chính thức để xác định mức độ thực thi sau đó quyết định xem , nên chọn yêu cầu nào để thực thi. 21 Thu nhận yêu cầu Đặc tính của phân loại ™ “Phân loại không thực hiện trong chân không” ™ Việc xếp loại đánh giá phải dựa vào thực tế ƒ Chi phí và rủi ro luôn có liên quan với nhau. ™ Một số ngành công nghiệp, có 1 số yêu tố như mối nguy hiểm cho người dùng và công nghệ mới ầ hải đượ khả át ù hc n p c o s c ng n au. 22 Thu nhận yêu cầu Ví dụ • Kỹ thuật mới cho việc đóng mở cửa số của xe hơi dù ả biế á h á th ì dù ô tắng c m n n s ng ay v ng c ng c vật lý như trước đây có chi phí thấp được khách hàng đánh giá rất cao • Khi phân tích hiểm họa thì thấy rằng không bảo đảm an toàn có thể làm cho trẻ con bị thương khi , cửa sổ đột ngột mở ra 23 Thu nhận yêu cầu Khi nào thực hiện? ™ Phân loại ưu tiên: Việc xác định độ ưu tiên ban đầ h á ê ầ ủ t k h ld ê đượu c o c c y u c u c a s a e o er n n c thực hiện càng sớm càng tốt trong chu kỳ phát triển sản phẩm . ™ Sắp xếp: Việc xếp loại đánh giá được thực hiện ngay khi các yêu cầu đã thu thập khá đủ như về chi phí, tài nguyên … 24 Thu nhận yêu cầu 4. Triển khai chức năng chất lượng ™ QFD (Quality Function Deployment ) là một kỹ thuật quản lý chất lượng mà chuyển những nhu cầu của khách hàng thành những yêu cầu kỹ thuật cho phần mềm ™ QFD tậ t à iệ tối đ ự thỏ ã ủ khá h p rung v o v c a s a m n c a c hàng về qui trình kỹ nghệ phần mềm ™ QFD nhấn mạnh tới sự hiểu biết những gì là giá trị với khách hàng và triển khai những giá trị này qua qui trình kỹ nghệ ™ QFD dùng phỏng vấn, quan sát, nghiên cứu và kiểm tra các dữ liệu trong quá khứ. Áp dụng nhiều biện há đồ hì h hươ há đá h iá ( tp p, n , p ng p p n g … cus omer voice table) Thu nhận yêu cầu Ba loại yêu cầu ™ Yêu cầu thông thường (Normal Requirements) ™ Yêu cầu mong đợi (Expected Requirements): những yêu cầu cơ bản, ngầm định l f h / hi i iƒ For examp e: ease o uman mac ne nteract on, overall operational correctness and reliability, and ease of software installation ™ Yêu cầu kỳ thú (Exciting Requirements) ƒ For example, in word-processing software, a number of page layout capabilities that are quite pleasing and unexpected. 26 CNPM/NN Thu nhận yêu cầu Trình tự thực hiện 1. Tìm ra nhu cầu khách hàng từ những người dù nói ra hay không nói ra, từ những lời nói mập mờ không đầy đủ. 2. Phát hiện ra các đặc tính “tích cực” làm phấn chấn khách hàng. 3. Chuyển các đặc tính này thành các đặc tính thiết kế và hành động có thể chuyển giao . 4. Xây dựng và phân phối sản phẩm /dịch vụ có chất lượng bằng cách tập trung vào các chức năng nghiệp vụ hướng tới mục tiêu chung – thỏa mãn khách hàng. Thu nhận yêu cầu Six Sigma ™ Six Sigma là gì? ™ QFD is often part of a Six Sigma program Thu nhận yêu cầu 5. Kỹ thuật lập mô hình xử lý ™ Kỹ thuật lập mô hình xử lý (hướng mô hình - d l d i ) hù hợ h ả iệ hát hiệmo e r ven p p c o c v c p n (elicitation) và phân tích (analysis) Biểu đồ luồng dữ liệu (Data flow diagrams DFD)ƒ - ƒ Phân tích Use case (use case = business process) 29 Thu nhận yêu cầu DFD ™ Được sử dụng trong 1 thời gian dài ™ Tập trung vào dòng dữ liệu và cấu trúc dữ liệu hơn là vào dịch vụ (services). 30 31 Thu nhận yêu cầu Errors Thu nhận yêu cầu Thu nhận yêu cầu Phân tích Use case ™ Dùng để chỉ ra quy trình nghiệp vụ và mối quan hệ iữ hệ thố à thế iới bê ài g a ng v g n ngo . ™ Có thể dùng ngôn ngữ tự nhiên hay bảng biểu để mô tả e e us cas . 35 Thu nhận yêu cầu Thu nhận yêu cầu 37 Thu nhận yêu cầu Phương pháp use case ™ Mỗi use case mô tả một chuỗi các tương tác giữa hệ thố à ột t bê ài ng v m ac or n ngo . ™ Actor là con người, hệ thống phần mềm khác, hay thiết bị phần ứng tương tá ới hệ thống để hoàn c c v thành mục tiêu. ƒ Còn được gọi là vai trò người dùng (user role) Thu nhận yêu cầu Phương pháp use case ™ Use case là phương pháp nổi bật trong hướng OO, là tâ điể ủ i t ì h RUP m m c a qu r n . ™ Use case chuyển hướng việc phát triển yêu cầu thành iệ thảo l ận em người dùng ần hoàn v c u x c thành cái gì (what), ngược lại với phương pháp truyền thống hỏi người dùng muốn hệ thống làm cái gì. ™ Mục tiêu của phương pháp use case là mô tả tất cả các nhiệm vụ mà người dùng sẽ cần thực thi với hệ thống. 39 Thu nhận yêu cầu Hệ thống theo dõi hóa chất 40 Thu nhận yêu cầu Mô tả Use case và kịch bản ™ Use case là một tập hợp các kịch bản (scenario) thô thườ ó liê hng ng c n quan n au. ™ Kịch bản (scenario) là 1 thể hiện (instance) nào đó ủ e e c a us cas . ™ Khi khai thác các yêu cầu của người dùng, có thể bắt đầu bằng các use case trừu tượng và xây dựng các kịch bản thông dụng riêng rẽ, hay có thể khái quát hóa từ kịch bản riêng biệt thành 1 use case rộng hơn. 41 Thu nhận yêu cầu Use case • Một nhận dạng duy nhất Một tê ắ ói lê đ hiệ ời• n ng n gọn n n ược n m vụ ngu dùng và có dạng "verb + object,“ như "Place an Order" • Đoạn văn bản mô tả ngắn gọn viết bằng ngôn ngữ tự nhiên • Một danh sách các tiền điều kiện (precondition) và hậu điều kiện (Postcondition) • Danh sách có đánh số thứ tự các bước tuần tự giữa actor và hệ thống. Thu nhận yêu cầu Bảng sự kiện và đáp ứng ™ Sự kiện là 1 số thay đổi hay hoạt động xảy ra t ôi t ườ ười dù để kí h khởi ộtrong m r ng ng ng c m đáp ứng từ hệ thống phần mềm ™ Phương pháp dùng bảng ự kiện à đáp ứng để s v xác định các sự kiện bên ngoài mà hệ thống cần phải đáp ứng ™ Bảng sự kiện và đáp ứng liệt kê tất cả các sự kiện và hành vi mà hệ thống đáp ứng lại ứng với mỗi sự kiện 43 Thu nhận yêu cầu Các loại sự kiện và đáp ứng 44 Thu nhận yêu cầu Các loại sự kiện hệ thống ™ Hành động người dùng mở ra 1 hộp thoại trong hầ ề ũ iố hư khi ười dù bắtp n m m, c ng g ng n ng ng đầu 1 use case ™ Ch ỗi e ent e pon e tương đương ới á bướu v -r s s v c c c trong hộp thoại của 1 use case. ™ Bảng event response không mô tả mục tiêu người - dùng khi sử dụng hệ thống hay cho biết tại sao chuỗi event-response cung cấp giá trị gì cho người dùng. 45 Thu nhận yêu cầu Các loại sự kiện hệ thống ™ Hành động của con người ể™ Tín hiệu điều khi n hay ngắt từ thiết bị phần cứng bên ngoài ệ í ở ở ồ ồ á í™ Sự ki n k ch kh i b i đ ng h m y t nh 46 Thu nhận yêu cầu 6. Quy tắc nghiệp vụ từ khách hàng ™ Luật về nghiệp vụ (Business rules) là loại đặc biệt ủ ê ầ khá h hàc a y u c u c ng. ™ Khác với các nhu cầu cố định của khách hàng, các q tắ nghiệp dùng đểuy c vụ : ƒ 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. 47 Thu nhận yêu cầu 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ỏ á tắ hiệ à á tắ à ẽ c c quy c ng p vụ m c c quy c n y s chi phối và hướng dẫn tổ chức. ™ Chính á h nghiệp (b ine poli ) là ế tố s c vụ us ss cy y u 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ụ. 48 Thu nhận yêu cầu Chính sách hay quy tắc nghiệp vụ? ™ “Bank customers should not be able to make too b k ithd l i i l dmany an w rawa s n a s ng e ay 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.” 49 Thu nhận yêu cầu Tại sao nó quan trọng ™ 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. 50 Thu nhận yêu cầu Lưu ý ™ Chính quy tắc nghiệp vụ do khách hàng xác định dù để thự thi hí h á h ủ ô t hưng c c n s c c a c ng y, n 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. 51 Thu nhận yêu cầu Ví dụ ™ Policy: The hospital shall be able to define the diff b t d lt d hild ti t ference e ween a u an c pa en s or check-in and medical records purposes. 52 Thu nhận yêu cầu 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 th h it l’ b i li te osp a s us ness po cy, a paren 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. 53 Thu nhận yêu cầu Ví dụ ™ Requirement: A facility shall be provided with the t h th t th h it l h k i fsys em suc a e osp a c ec - n process or adults and children can be changed by hospital administrators without the need for system or software modifications. 54 Thu nhận yêu cầu Chính sách và luật nghiệp vụ 55 Thu nhận yêu cầu Quy tắc nghiệp vụ ™ Mỗi tổ chức nghiệp vụ đều phải tuân theo 1 tập á hí h á h l ật à tiê h ẩ đượ i làc c c n s c , u v u c u n c gọ business rule ™ Phần mềm ứng d ng b ộ phải t ân theo á q ụ u c u c c uy tắc nghiệp vụ này. ™ Trong một số trường hợp các quy tắc nghiệp vụ , không nằm trong phần mềm nhưng được kiểm soát thông qua việc người dùng phải tuân theo các chính sách và thủ tục. 56 Thu nhận yêu cầu Quy tắc nghiệp vụ ™ Hầu hết các quy tắc nghiệp vụ đều xuất phát từ bê ài ữ ả h ủ bất kỳ hầ ề àn ngo ng c n c a p n m m n o, nhưng các quy tắc này là nguồn yêu cầu chức năng chính của phần mềm vì nó đưa ra các khả năng mà hệ thống phải có để phù hợp với các quy luật. ™ Ví dụ: trong hệ thống theo dõi hóa chất cần phát ra các báo cáo phù hợp với các quy định của liên bang về việc lưu trữ hóa chất. 57 Thu nhận yêu cầu Quy tắc nghiệp vụ ™ Không phải mọi công ty đều xem các quy tắc hiệ hư tài ả ó iá t ị Có thể á thông p vụ n s n c g r . c c ng tin này không được ghi chép và quản lý, mà chỉ tồn tại trong đầu các cá nhân . ™ Các cá nhân khác nhau có thể hiểu khác nhau về các quy tắc dẫn đến các phần mềm tuân theo các , quy tắc nghiệp vụ chung sẽ không toàn vẹn 58 Thu nhận yêu cầu Quy tắc nghiệp vụ ™ "A business rule is a statement that defines or t i t f th b i It icons ra ns some aspec o e us ness. s intended to assert business structure or to control or influence the behavior of the business ” . 59 Thu nhận yêu cầu Phân loại quy tắc nghiệp vụ 60 Thu nhận yêu cầu Tạo tài liệu ™ Quy tắc nghiệp vụ có thể ảnh hưởng đến nhiều ứng dụng, nhiều tổ chức Æ các tổ chức nên quản ý á ắ ệ ở ứ ôl c c quy t c nghi p vụ m c kinh doanh kh ng phải ở mức dự án. ™ Dùng phân loại luật nghiệp vụ (business rules catalog) ™ Nếu tổ chức lớn nên xây dựng một CSDL luật nghiệp vụ ™ Khi xác định 1 quy luật mới trong lúc làm việc với ứng dụng, hãy thêm nó vào phân loại (catalog), đừng nhúng nó vào tài liệu của riêng ứng dụng hay chỉ viết code cho nó. ™ Các quy luật liên quan đến an toàn, an ninh và tài chánh có thể dẫn đến các rủi ro cao nhất nếu quản lý không đúng. 61 Thu nhận yêu cầu Ví dụ: phân loại 62 Thu nhận yêu cầu Luật nghiệp vụ 63 Thu nhận yêu cầu Lưu ý ™ Sau khi nhận dạng và xác định các quy tắc nghiệp ê á đị h tắ à ầ thự thivụ, n n x c n xem quy c n o c n c trong phần mềm. Một số quy tắc sẽ làm phát sinh các use case vì vậy sẽ ảnh hưởng đến yêu cầu , chức năng của use case đó. 64 Thu nhận yêu cầu Ví dụ `Rule #1 (action enabler) "If the expiration d t f h i l t i h b h da e or a c em ca con a ner as een reac e , 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." 65 Thu nhận yêu cầu Ví dụ ™ Ba quy tắc này dẫn đến use case "Notify Chemical O f E i ti “ Một ê ầ hứ ă hwner o xp ra on. y u c u c c n ng c o 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." 66 Thu nhận yêu cầu Quy tắc nghiệp vụ và yêu cầu chức năng ™ Đôi khi các quy tắc nghiệp vụ và yêu cầu chức ă tươ ứ ất iố h T hiê án ng ng ng r g ng n au. uy n n c c quy 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 quy 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. 67 Thu nhận yêu cầu Ví dụ ™ Xét hệ thống Quản lý hóa chất, có 1 một ràng b ộ ê ầ ười dù ó hồ ơ đà t ồi ớiu c y u c u ng ng c s o ạo r m có quyền được yêu cầu hóa chất độc hại (hazardous chemical) . ™ Nhà phân tích có thể suy diễn quy tắc này thành các yêu cầu chức năng khác nhau tùy thuộc vào điều kiện CSDL về hồ sơ đào tạo có trực tuyến hay không? 68 Thu nhận yêu cầu Ví dụ ™ Nếu có, hệ thống chỉ đơn giản tìm kiếm hồ sơ đào t à ết đị h hấ hậ h từ hối ê ầạo v quy n c p n n ay c y u c u. ™ Nếu không, hệ thống có thề lưu trữ tạm thời yêu ầ nà à gửi em il đến tổ hứ h ấn l ện đểc u y v a c c u uy 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 thay đổi tùy theo môi trường hệ thống. 69 Thu nhận yêu cầu Quy tắc nghiệp vụ và SRS ™ Để tránh dư thừa, không nên lặp lại các quy tắc từ phân loại luật nghiệp vụ vào SRS mà nên chỉ , ra nơi tham chiếu các quy tắc. ƒ Phòng tránh được việc phải thay đổi cùng lúc cả quy tắc nghiệp vụ và yêu cầu chức năng khi quy tắc thay đổi. ƒ Giữ cho SRS luôn phản ánh các quy tắc vừa thay đổi vì nó tham chiếu đến bản sao chính của quy tắc. ƒ Thuận lợi trong việc dùng lại cùng 1 quy tắc trong nhiều nơi khác nhau của SRS và cho nhiều dự án khác nhau mà vẫn giữ được sự nhất quán. 70 Thu nhận yêu cầu Quy tắc nghiệp vụ và SRS ™ Lý do khác để tách quy tắc nghiệp vụ và yêu cầu hứ ă tắ thườ đượ tá h 1 á hc c n ng: quy c ng c c ra c c riêng biệt, vì vậy có thể không nhạy bén khi xem xét thực tế có liên quan đến nhiều yêu cầu khác . ™ Không có 1 giải pháp nào là hoàn hảo và đơn giản để cho các quy tắc nghiệp vụ thực thi cùng nhau trong mọi hoàn cảnh. 71 CHƯƠNG V Tạo Mô hình Hệ thống Thu nhận yêu cầu TNYC 1 Thu nhận yêu cầu Nội dung 1. Mô hình hệ thống 2 Ph há MDRE (M d l D i. ương p p o e - r ven Requirements Engineering) 3 Mô hì h tiê (G l d li ). n mục u oa mo e ng 4. Mô hình UML 2 1. Mô hình hệ thống ™ Hệ thống: một tập hợp các thành phần liên kết với nhau, ở trong một phạm vi xác định, chúng tương tác với nhau nhằm đạt những mục đích xác định. Đầu vào Thành phần Ph iạm v 3 Đầu raGiao diện Liên hệ giữa các thành phần Hệ thống: các mục ™ Thành phần (component) ™ Ranh giới (boundary) ™ Mục đích (purpose) ™ Môi trường (environment) Đầu vào Thàn h phầnPhạm ™ Giao diện (interface) ƒ Người dùng vi ƒ Với hệ thống khác ƒ Giữa các thành phần ™ Đầu vào (input) ™ Đầu ra (output) ™ Ràng buộc (constraints) Đầu ra Giao diện Liên hệ giữa các thành phần 4 Hệ thống bán nước giải khát Môi trường: khách hàng, nhà cung cấp, ngân hàng,… Đầu vào: Nước giải khát, Kho Đầu ra: Nước giải khát, tiền mặt, lao động, tài sản, Phòng bán hàngVăn phòng tiền mặt, bảng giá, hóa đơn, Ranh giới …. … 5 Thu nhận yêu cầu Hệ thống bán nước giải khát Khách hàng (1) Phòng bán hàng Văn phòng (4)(5) Đơn vị(8) Kho cung ứng(5) 6 Thu nhận yêu cầu Hệ thống đặt phòng… 7 CNPM/NN Thu nhận yêu cầu Mô hình thu thập & phân tích ™ Cung cấp các hỗ trợ phân tích nhu cầu của người dùng . ™ Xác định một cách rõ ràng các quy trình và ngữ cảnh của khách hàng khi sử dụng sản phẩm đang được xây dựng. ™ Cung cấp tầm nhìn cho thấy sản phẩm sẽ được dùng như thế nào sau khi hoàn tất . ™ Hỗ trợ để xác định các rủi ro có thể xảy ra cho người dùng sản phẩm. ™ Xác định tất cả người dùng. Mỗi loại người dùng sẽ tương tác với hệ thống đang xây dựng hư thế àn n o. 8 Thu nhận yêu cầu Thu thập và phân tích ™ Hai hoạt động này hay dùng lẫn lộn vì có cùng công cụ và mô hình vật lý nhưng được dùng ở những thời điểm khác nhau trong chu kỳ phát triển hệ thống ™ Thu thập là hoạt động được hoàn thành cùng với stakeholders để xác định nhu cầu của họ là ìg ™ Ngay khi các tính năng của sản phẩm đã được xác định dựa vào mô hình nghiệp vụ mô hình , phân tích có thể được thực hiện để xác định chi tiết hơn sản phẩm sẽ được dùng như thế nào. 9 Thu nhận yêu cầu Mô hình phân tích ™ Ngay khi các tính năng của sản phẩm đã được xác đị h dự à ô hì h hiệ ô hì h hân a v o m n ng p vụ, m n p n tích có thể được thực hiện để xác định chi tiết hơn sản phẩm sẽ được dùng như thế nào . ™ Phương pháp MDRE (Model-Driven Requirements Engineering) bao gồm cả hai hoạt động mô hình hóa nghiệp vụ và phân tích. 10 Thu nhận yêu cầu 2. Phương pháp MDRE ™ Model-Driven Requirements Engineering 1 Các quy trình nghiệp vụ được mô hình hóa để hiểu. rõ hơn sản phẩm có thể hỗ trợ cho các hoạt động của khách hàng ƒ Output: mô hình nghiệp vụ (business model) 2. Từ mô hình nghiệp vụ, sản phẩm hay tập hợp các ễ ỗdịch vụ IT sẽ được suy di n để h trợ việc xác định tập các tính năng của sản phẩm. 3 Khi tậ á tí h ă đã đượ á đị h hú ầ. p c c n n ng c x c n , c ng c n được phân tích bằng cách triển khai tất cả các tính năng này để xem chúng được dùng như thế nào. ƒ Output: mô hình phân tích (analysis model) Thu nhận yêu cầu Phương pháp MDRE 4. Việc phân tích mỗi tính năng sẽ tạo ra mô hình Mỗi ẽ đượ hâ tí h à ôuse case. use case s c p n c v m tả cụ thể. 5 Tập hợp đầ đủ ó phân ấp á e e nà ẽ. y c c c c us cas y s là yêu cầu của sản phẩm. 12 13 Thu nhận yêu cầu Quy trình MDRE ™ Việc sử dụng quy trình MDRE đòi hỏi phải được lậ kế h h hâ iê ó kỹ ă à á bộp oạc , n n v n c n ng, v c c công cụ hiệu quả. ™ Q t ình MDRE ó thể t ải dài q ốt h kỳuy r c r ua su c u phát triển của cả sản phẩm từ lúc khởi tạo đến bảo trì Vì vậy phải xác định được mục tiêu của . quy trình, và các stakeholder mong đợi điều gì. 14 15 Thu nhận yêu cầu Quy trình MDRE ™ Các quy trình MDRE chỉ bao gồm các hoạt động th thậ ê ầ khô b ồ á h t độu p y u c u, ng ao g m c c oạ ng thiết kế. ™ Sử d ng UML như điểm khởi đầ do bộ ông ụ u c cụ của nó luôn sẵn có và chấp nhận được. ™ MDRE là tạo các mô hình có tính chuyển đổi phù hợp với những ứng dụng khác nhau 16 Thu nhận yêu cầu Các bước của quy trình MDRE ™ Những hiểu biết ban đầu ™ Hiểu biết ngữ cảnh và hiểu được sản phẩm sẽ được dùng như thế nào. hâ í h á í h ă ả hẩ à ô™ P n t c c c t n n ng s n p m v tạo m hình Use Case ™ Rút trích các yêu cầu từ mô hình ™ Phân tích yêu cầu từ MDRE ™ Quản lý các phiên thảo luận cho thu thập và phân tích ™ Điều hành các buổi họp kiểm tra mô hình 17 Thu nhận yêu cầu Thuận lợi của quy trình MDRE ™ MDRE không phải là phương pháp “all or thi ” à thườ đượ dù kè ới áno ng , m ng c ng m v c c phương pháp khác. Ví dụ, nếu 1 tổ chức muốn tập trung vào use case và các yêu cầu dạng văn bản , thì vẫn có thể dùng mô hình use case mức cao để hỗ trợ, việc chọn 1 biểu tượng use case sẽ kích khởi bộ soạn thảo để mô tả use case đó. 18 Thu nhận yêu cầu Thuận lợi của quy trình MDRE ™ Theo hướng phát triển nhanh, các mô hình chưa đầ đủ ẫ ó thể dù đượ để biể diễ tậy v n c ng c u n p hợp các câu chuyện người dùng. ™ Nhờ ử d ng mô hình mà hi tiết đượ bổ ng s ụ c c su dần sẽ không chỉ dành cho người phát triển mà cho cả người kiểm thử và người kiểm tra . 19 Thu nhận yêu cầu MDRE – Vấn đề ™ Thiếu các kỹ năng tạo mô hình ™ Công cụ không thích hợp ™ Tổ chức không sẵn sàng cho MDRE 20 Thu nhận yêu cầu 3. Mô hình mục tiêu (Goal modeling) ™ Là cách để đúc kết các ý tưởng, trình bày các mục tiê hợ hất t á h dễ hiể õ à á đị hu p n rong c c u r r ng, x c n và cân đối các chọn lựa khó 21 Thu nhận yêu cầu Ví dụ 1 22 Thu nhận yêu cầu Ví dụ 2 23 Thu nhận yêu cầu Hạn chế của mô hình mục tiêu ™ Nhiều yêu cầu mức cao không thể tính toán được ì hiề lý d hư ô hệ th đổi h hv n u o n c ng ng ay n an chóng, .. ™ Một ố m tiê ng đột không phát hiện đượ s ục u xu c cho đến khi phê duyệt yêu cầu. ™ Việc tinh chỉnh yêu cầu phi chức năng có thể làm xuất hiện nhiều vấn đề còn tiềm ẩn. 24 Thu nhận yêu cầu KAOS ™ KAOS, is a goal-oriented software requirements capturing approach in RE. ™ It is a specific Goal modeling method; another is i*. ™ It allows for requirements to be calculated from l digoa agrams. ™ Viết tắt của Knowledge Acquisition i