Đang tải... (xem toàn văn)
Chủ Đề: Ngân hàng đề thi + giáo trình môn Chuyên đề 2Read
Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa Đề cương ôn tập Chuyên đề 2: Phân tích và quản lý yêu cầu phần mềm. A. LÝ THUYẾT Câu 1: Nêu tầm quan trọng và mục tiêu of hoạt động phân tích và quản lý yêu cầu phần mềm ? • Tầm quan trọng: Quản lý yêu cầu (RM) là một trong các thành phần quan trọng nhất của dự án phát triển phần mềm: o Chắt lọc, o Tổ chức, o Tư liệu hóa, o Lưu vết các yêu cầu hệ thống. => giúp thẩm tra, thẩm định hệ thống, quản lý thay đổi và phân tích các trạng thái của dự án. Như vậy có thể quản lý được mọi thay đổi của yêu cầu dự án. Chi phí sửa lỗi do hiểu sai, bỏ sót yêu cầu là rất lớn nếu bỏ sót hay hiểu sai các yêu cầu phần mềm có thể dẫn đến sai lầm nghiêm trọng ( Cái này nên đưa vào một số con số). Tuy nhiên hoạt động phần tích và quản lý yêu cầu phần mềm thường bị coi nhẹ. o Mục tiêu:- Chém gió thôi chưa tìm được tài liệu nào o Phân tích các yêu cầu của người sử dụng (Yêu cầu thô thường là ngôn ngữ tự nhiên) thành các feature làm đầu vào để sinh các Use Case phục vụ cho các pha sau trong tiến trình phát triển phần mềm. o Sinh các test case phục vụ cho việc kiểm thử o Tạo ra các tài liệu đặc tả phục cho phần mềm hay người sử dụng, phát triển và bảo trì phần mềm. Câu 2: Định nghĩa StackHolder và Actor của hệ thống ? Xác định các StackHolder và Actor cho dự án phần mềm cụ thể. - Đinh nghĩa StackHolder và Actor của hệ thống: o StackHolder: StackHolder được định nghĩa là 1 người hoặc 1 nhóm người bị tác động bởi kết quả của dự án phát triều hệ thống hoặc có thể tác động đến các hoạt 1 Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa động hoặc đầu ra của dự án (Có thể xem StackHolder là bất kỳ người nào có thể có yêu cầu với hệ thống). Các StackHolder có thể là: Các khách hàng; Người dùng cuối Người phát triển Nhà sản xuất Người kiểm thử Đảm bảo chất lượng Người quả trị Cơ sở dữ liệu Người quản lý cấu hình Nhà cung cấp Nhà tiếp thị Người bảo trì Người quản lý Các cơ quan quy định tính an toàn/ không nguy hiềm. o Actor Một tác nhân là một người hoặc một vật tương tác với hệ thống. Nó có thể là một người nhưng nó cũng có thể là một hệ thống khác. - Ví dụ về website của công ty du lịch: o StackHolder có thể là : Khách hàng: là người chủ of Website ; Người dùng cuối là những người sử dụng Website qua Internet; Người tham gia vào hoạt động phát triển hệ thống Người cung cấp tri thức cho hệ thống Người quản lý hệ thống Người bảo trì và hỗ trợ hệ thống. o Actor của hệ thống: User: Người trực tiếp sử dụng hệ thống. Travel Agency Owner: Có thể là một tác nhân nếu anh ta ban hành một số UC cụ thể cho anh ấy. Phụ thuộc vào liệu anh ấy có quyền hạn cụ thể gì và liệu có chức năng hệ thống nào là chỉ sẵn dùng cho anh ấy. Nếu anh ấy truy cập đến các chức năng tương tự như quản trị viên, thì không cần tạo tác nhân riêng cho Travel Agency Owner vì tác nhân quản trị viên bao trùm nó. Content Manager là một tác nhân, người cung cấp nội dung qua giao diện. Hotel Provider, Car Rental Agent, và Airline Representative có thể xem như 3 tác nhân riêng rẽ, hoặc xem như một tác nhân được gọi là Service Provider. Phụ thuộc vào việc họ thực hiện các UC khác nhau như thế nào. Quyết định này có thể được tạo trong tiến trình sau hơn. 2 Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa Câu 3: Trình bày phương pháp suy luận yêu cầu. Ưu và nhược điểm của từng phương pháp? ST T Phương pháp Mô tả Ưu điểm Nhược điểm 1 Phỏng vấn Phương pháp phỏng vấn 1 nhóm Stackholder đã được lựa chọn. - Tính tự nhiên trong giao tiếp. - Là cách tốt nhất cho việc thu thập các yêu cầu về khả năng sử dụng, độ tin cậy hiệu năng và khả năng hỗ trợ củ hệ thống. - Mất nhiều thời gian, căng thẳng, phụ thuộc nhiều vào điều kiện của người được hỏi . 2 Bản câu hỏi thăm dò. Bản câu hỏi thăm dò là hữu ích nhất nếu chúng ta có thể hỏi nhiều stackholder các câu hỏi tương tự và chúng ta không mong đợi sinh them các câu hỏi. - Nhanh và rẻ hơn phỏng vấn. - Dễ tổng kết - Đào tạo người điều tra ít tốn kém hơn cả về thời gian và chi phí Kết quả có độ chính xác thấp và được đánh giá bằng con số trung bình thống kê 3 Hội thảo Nhóm stackeholder được lựa chọn gặp gỡ nhóm dự án. Họ thảo luận tập trung trong một khoảng thời gian. - Có thể áp dụng các kỹ thuật suy luận yêu cầu khác nhau. - Có thể thu thập các yêu cầu mới xét duyệt, phân loại và đánh thứu tự ưu tiên cho các yêu cầu đang tồn tại - Mất thời gian nếu hội thảo về 1 vấn đề quá lâu. - Thiếu dữ liệu về stackeholder có thể khiến cho buổi hội thảo thất bại. - Những phát biểu tiêu cực, không có tính xây dựng có thể làm thất bại buổi hội thảo hay kéo dài thời gian. 4 Thẻ sự kiện -Sử dụng công cụ đồ họa, trực quan để mô tả hành vi hệ thống. - Bộ tiện ích chỉ ra thẻ sự kiện ban đầu cho nhóm. - Sau đó, dựa trên các lời bình từ những người tham gia, thẻ sự kiện được thay đổi - Nhanh và chính xác cho mỗi thẻ sự kiện. - Thuận tiện cho các quá trình lặp (nếu muốn lấy lại ý kiên ). - Trực quan , dễ tưởng tượng. - Phải design lại nếu các yêu cầu có sự thay đổi. - Việc cập nhật thẻ sự kiện là 1 tiến trình lặp hay thẻ sự kiện sẽ thay đổi để mô phỏng hệ thống ngày một chính xác theo yêu cầu của stackeholder. 3 Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa và được biểu diễn lại. 5 Phân vai Các thành viên trong nhóm được gán cho vai trò liên quan đến hệ thống được xây dựng.Thông thường nhất, các vài trò thường là người sử dụng hệ thống hoặc các tác nhân khác tương tác với hệ thống - Mô tả tương đối chính xác các yêu cầu của stackeholder. - Có thể thiếu sót đi yêu cầu do chưa mới khảo sát trên phương diện của một stackeholder. - Tốn thời gian và mất chi phí đào tạo. 6 Các phiên làm việc tập trung. Những người tham gia tập hợp lại trong thời gian ngắn. Khi bắt đầu, người chỉ đạo thông báo mục đích của phiên. Các yêu cầu mới có thể sinh ra liên quan đến một số phần của hệ thống hoặc liên quan đến việc giải quyết vấn đề. Mỗi người tham gia cung cấp 1 số ý kiến và các ý kiến không được phép bình phẩm. Sau khi mọi ý kiến đã được viết, chọn ngẫu nhiên hoặc tạo sự kết hợp các ý kiến này. - Phương pháp này đặc biệt hữu ích khi một vấn đề cần được giải quyết – hoặc là một phần đáng kể của yêu cầu bị bỏ sót, hoặc yêu cầu là xung độtrr - Tốn thời gian và chi phí. - Thời gian cho 1 phiên rất lâu nếu các yêu cầu được sinh ra càng nhiều. - Không thích hợp cho các biểu đồ quan hệ vì nó chỉ sinh ra một số lượng nhỏ các ý kiến. 7 Sử dụng các biểu đổ quan hệ Gồm 4 bước: B1: Tạo các thẻ. B2.Sắp xếp các thẻ B3.Thảo luận mô hình B4. Tạo các tiêu đề. B5. Cấu trúc mô hình. Phương pháp này đặc biệt hữu ích khi: - Có một số lớn các ý kiến. - Mối quan hệ giữa các mục không rõ rang. - Các vấn đề là phức tạp - Sự nhất trí nhóm là cần thiết. Phương pháp này không thích hợp trong trường hợp chỉ có một số lượng nhỏ các ý kiến. 8 Mẫu thử Mẫu thử là một - Đem lại những ý kiến - Chi phí lớn do phải 4 Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa phương pháp tiềm lực để có được các phản hồi từ người dùng và khách hàng. đầy đủ về hệ thống khi đưa ra mẫu thử để chính khách hàng kiểm thử. phát hành một phiên bản mới của hệ thống là tón chi phí. - Nhiều chức năng của hệ thống thường được hóa cứng , nên mẫu thử như bản sự kiên phức tạp. 9 Các ca sử dụng (UC) Các UC là một kiểu yêu cầu trong kim tự tháp. Chúng ta cũng là khuôn dạng để các stackeholder phát biểu các nhu cầu của họ. - Mô tả chính xác hệ thống từ các stackeholder. 10 Phân tích các tài liệu Trích rút thông tin từ các tài liệu word, các email và các ghi chú - Tiết kiệm chi phí (Do chỉ phải tìm tài liệu và trích rút). - Chưa đầy đủ nếu thiếu tài liệu. - Cần người có kinh nghiệm để parse dữ liệu. 11 Quan sát và mô phỏng nhiệm vụ. Quan sát người dùng thực thi những nhiệm vụ cụ thể. - Người dùng có thể mô phỏng nhiệm vụ, trong khi người phân tích ghi chú và tạo các quan sát. - Tốn chi phí do cần người mô phỏng và người quan sát. 12 Phân tích các hệ thống đang tồn tại - Thu thập các yêu cầu từ hệ thống bị thay thế hoặc từ các hệ thống cạnh tranh đã được xây dựng. - Nếu chúng ta đang phát triển 1 hệ thống tương tự 1 hệ thống đã tồn tại và chúng ta có quyền truy cập đến sản phẩm cuối cùng, rất đáng giá cho việc phân tích công việc của các hệ thống này để học hỏi rút ra kinh nghiệm từ các thành công cũng như các lỗi của chúng. - Không thích hợp cho những hệ thống mới. - Có thể mất sự sang tạo nếu quá phụ thuộc vào các hệ thống cũ (I thinks so ^_^) Kết luận: Tùy thuộc vào từng dự án đang phát triển chúng ta có thể lựa chọn một phương án hay kết hợp lại nhằm đưa ra 1 kết quả tốt nhất nhé !!!! 5 Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa Câu 4: Trình bày ngắn gọn tiến trình phân tích và quản lý yêu cầu phần mềm. 1. Thiết lập kế hoạch quản lý các yêu cầu Một trong các nhiệm vụ đầu tiên trong dự án là phát triển kế hoạch quản lý các yêu cầu (Requirements Management Plan - RPM). RPM mô tả cách tiếp cận tổng quan để quản lý các yêu cầu trong dự án. Sau đây là một số câu hỏi có thể được trả lời trong RPM: Công cụ RM gì sẽ được sử dụng? Các kiểu yêu cầu gì sẽ được lưu dấu vết trong dự án? Các thuộc tính của các yêu cầu này là gì? Các yêu cầu sẽ được tạo ở đâu – chỉ trong CSDL hay trong các tài liệu? Giữa các yêu cầu nào chúng ta cần triển khai dấu vết? Các tài liệu gì được yêu cầu? Những yêu cầu và những tài liệu gì sẽ được sử dụng như là bản hợp đồng với khách hàng? Nếu một phần của dự án được đặt mua, các yêu cầu và các tài liệu gì sẽ được sử dụng như là bản hợp đồng với nhà cung cấp? Chúng ta tuân theo phương pháp luận RUP hay phương pháp luận khác? Khách hàng có cần tài liệu gì để tuân theo tiến trình phát triển của họ? Quản lý thay đổi sẽ được triển khai như thế nào? Giả sử rằng RequisitePro được sử dụng, toàn bộ hệ thống sẽ được lưu trữ trong một dự án RequisitePro hay lưu trữ ở nhiều dự án? Tiến trình nào sẽ đảm bảo rằng mọi yêu cầu đã được cài đặt và đã được kiểm thử? Các yêu cầu và các khung nhìn nào mà chúng ta cần để sinh ra các báo cáo? 2. Suy luận các yêu cầu 6 Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa - Suy luận các yêu cầu, còn được gọi là thu thập các yêu cầu, là một bước rất quan trọng. Bỏ sót hoặc hiểu sai một yêu cầu ở trạng thái này sẽ lan truyền vấn đề xuyên qua suốt vòng đời của phát triển phần mềm. - Sau đây là một số kỹ thuật được sử dụng để thu thập các yêu cầu từ các Stakebolder: Phỏng vấn. Bảng các câu hỏi. Hội thảo. Bảng tường thuật. Đóng vai. Các phiên làm việc tập thể (Brainstorming sesions). Các biểu đồ quan hệ. Mẫu thử. Phân tích các tài liệu. Các trường hợp sử dụng (Use case). Phân tích hệ thống đang tồn tại. 3. Phát triển tài liệu trực quan Trong khi phát triển tài liệu trực quan, một trong các mục đích chính của phân tích nghiệp vụ là sinh ra các đặc trưng từ các nhu cầu Stakeholder . Tài liệu trực quan phải chứa thông tin bản chất về hệ thống sẽ được phát triển. Bên cạnh việc liệt kê mọi đặc trưng, nó lên chứa một mô tả tổng quan về sản phẩm, mô tả người dùng và tóm lược các khả năng của hệ thống, và các thông tin khác để có thể hiểu mục tiêu của hệ thống. Nó cũng liệt kê mọi nhu cầu Stakeholder trong trường hợp chúng không được nắm bắt trong các tài liệu riêng lẻ. 4. Tạo các Use case 7 Hình 1.5 Các đặc trung được sinh ra từ các nhu cầu Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa Một use case là một mô tả về hệ thống theo một chuỗi các hành động. Nó nên sinh ra kết quả có thể quan sát hoặc trả về giá trị cho tác nhân (tác nhân là một người hoặc một thứ mà tương tác với hệ thống). Các use case: Được khởi tạo bởi một tác nhân. Một hình hóa một sự tương tác giữa tác nhân và hệ thống. Mô tả một chuỗi các hành động. Nắm bắt các yêu cầu chức năng. Nên cung cấp một số giá trị cho tác nhân. Trình bày luồng sự kiện đầy đủ và có ý nghĩa đầy đủ. 5. Đặc tả bổ sung Đặc tả bổ sung nắm bắt các yêu cầu phi chức năng (khả năng sử dụng, độ tin cậy, sự thực thi, khả năng hỗ trợ, ) và một số yêu cầu chức năng mà xuyên xuốt hệ thống, vì nó không được nắm bắt cứng nhắc trong các use case. 6. Tạo các Test Case từ các Use Case Các Test Case sẽ chỉ cho người kiểm thử các bước nên thực hiện để kiểm tra mọi yêu cầu. Trong bước này, chúng ta sẽ tập trung tạo các Test Case từ các Use Case. Nếu chúng ta chưa tạo các kịch bản trong khi sinh ra các Use Case, chúng ta cần định nghĩa chúng bây giờ. 7. Tạo các Test Case từ Đặc tả bổ sung Cách tiếp cận được sử dụng trong bước trước không áp dụng để kiểm thử các yêu cầu bổ sung. Vì các yêu cầu này không được phát biểu như một chuỗi các hành động, khái niệm về các kịch bản không áp dụng cho chúng. Một cách tiếp cận riêng nên được áp dụng cho mỗi yêu cầu bổ sung, vì các kỹ thuật được sử dụng để kiểm tra các yêu cầu thực thi là khác so với kỹ thuật được sử dụng để kiểm tra các yêu cầu về khả năng sử dụng. Trong bước này chúng ta cũng thiết kế các vấn đề liên quan đến cơ sở hạ tầng và nền tảng/môi trường vận hành hệ thống. 8. Thiết kế hệ thống 8 Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa Các yêu cầu là nền tảng cho thiết kế hệ thống, mà thường được tạo thuận lợi bởi việc sử dụng ngôn ngữ mô hình hóa thống nhất (UML – Unified Modeling Language) [BOO98]. Nhiều công cụ như Rational Rose, Rational Software Architect, Rational Data Architect, và Rational Software Modeler, có thể tạo thuận lợi đáng kế trong việc tạo mọi biểu đồ được yêu cầu. Câu 5: Trình bày mối quan hệ giữa yêu cầu trong kim tự tháp yêu cầu. Tại sao phải quản lý dấu vế các kiểu yêu cầu. Tại sao đối với các dự án phần mềm lớn và phức tạp phải quản lý các yêu cầu phần mềm theo mô hình kim tự tháp. 1. Mối quan hệ giữa yêu cầu trong kim tự tháp yêu cầu. - Các kiểu yêu cầu thường được sử dụng trong các dự án: Stakeholder need (nhu cầu Stakeholder): Một yêu cầu được để xuất bởi Stakeholder Feature (đặc trưng): Một dịch vụ được cung cấp bởi hệ thống, thường được hình thành bởi hoạt động phân tích nghiệp vụ; mục tiêu của một đặc trưng là để thỏa mãn một nhu cầu Stakeholder. Use case (ca sử dụng): Một mô tả về hành vi của hệ thống theo các thuật ngữ về một chuỗi các hành động. Supplementary requirement (yêu cầu bổ sung): yêu cầu khác (thường là yêu cầu phi chức năng) và không thể được thể hiện trong các use cases Test case (ca kiểm thử): một đặc tả về các đầu vào kiểm thử, các điều kiện thực thi, và các kết quả mong đợi. Scenario (kịch bản): Một chuỗi hành động cụ thể; một đường cụ thể qua một use case. Các yêu cầu này có thể được biểu diễn theo hình của một kim tự tháp . 9 Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa Ở mức đỉnh của nó là các nhu cầu Stackeholder, ở các mức thấp hơn là các đặc trưng, các ca sử dụng, các yêu cầu bổ sung. Thông thường ở các mức yêu cầu khác nhau, các mức độ chi tiết cũng khác nhau. Càng ở mức thấp, mức độ chi tiết càng cao. Từ một yêu cầu mức trên, có thể ánh xạ thành nhiều yêu cầu mức dưới. 2. Phải quản lý dấu vết các yêu cầu là vì: - Dấu vết – Traceability: o Là kỹ thuật cung cấp mối quan hệ giữa hai mức độ yêu cầu o Giúp xác định nguồn gốc của một yêu cầu bất kỳ. o Mỗi nhu cầu thương được ánh xạ từ một số đặc trưng. - Vai trò của kỹ thuật Traceability: o Thẩm tra rằng bản cài đặt là thỏa mãn đầy đủ mọi yêu cầu: Mọi thứ mà khách hàng yêu cầu đã được cài đặt. o Thẩm tra rằng ứng dụng chỉ đáp ứng những gì được yêu cầu: Không cài đặt những thứ mà khách hàng không yêu cầu. 10 Hình 1.2 – Kim tự tháp các yêu cầu [...]... o Phân tích ảnh hưởng: Những phần tử gì sẽ bị tác động khi thêm một yêu cầu mới hoặc thay đổi một yêu cầu đang tồn tại? o Giúp quản lý thay đổi: Khi một số yêu cầu thay đổi, chúng ta muốn biết những test case nào nên được thực hiện lại để kiểm tra sự thay đổi này Đó chính là lý do tại sao phải quản lý dấu vết các yêu cầu 3 Đối với các dự án phần mềm lớn và phức tạp phải quản lý các yêu cầu phần - mềm. .. án lớn luôn có nhưng yêu cầu thay đổi và càng cần được quản lý, mô hình kim tự tháp tỏ ra là 1 mô hình rất dễ dùng để quản lý Mọi các yêu cầu của hệ thông đều được ánh xạ từ các yêu cầu ở mức trên Nếu có sự thay đổi thì sẽ bổ sung trên đỉnh kim tự tháp đồng thời sẽ được bổ sung ở mức sau Với những dự án lớn thường nhiều người cùng xây dựng mô hình kim tự tháp dễ dàng cho việc phân công công việc theo... sự hấp dẫn của nơi du lịch o Tính cần thiết: Một yêu cầu không cần thiết khi: Không Stackeholder nào cần yêu cầu o 12 Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa o o o o 13 Xóa yêu cầu sẽ không ảnh hưởng đến hệ thống Ví dụ: REQ: Mọi yêu cầu đã xác định trong tài liệu trực quan phải được cài đặt và được kiểm thử Đây là một yêu cầu không cần thiết vì nó không cung cấp bất kỳ một... buộc đang tồn tại như thời gian, tiền bạc, và các nguồn tài nguyên có thể Ví dụ: REQ: Hệ thống sẽ có giao diện bằng ngôn ngữ tự nhiên và sẽ hiện các mệnh lệnh bằng ngôn ngữ tiếng anh Yêu cầu này là không khả thi trong 1 khoảng thời gian phát triển ngắn o Tính độc lập: Tính độc lập của yêu cầu thỏa mãn khi, để hiểu yêu cầu đó, ta sẽ không cần phải biết bất kỳ yêu cầu nào khác Ví dụ: REQ: Danh sách các chuyến... chuyến bay, thời gian cất cánh, thời gian đến của mọi chặng đường o Nguyên tử: Yêu cầu nên chứa một phần tử đơn có thể theo dõi qua dấu vết Ví dụ: Xét các yêu cầu sau: REQ: Hệ thống sẽ cung cấp cơ hội đặt phòng trước và cung cấp thông tin về sự hấp dẫn của nơi du lịch Yêu cầu này chưa nguyên thủy nên tách ra thành 2 yêu cầu riêng biệt; REQ1: Hệ thống sẽ cung cấp cơ hội đặt phòng trước REQ2: Hệ thống... cùng xây dựng mô hình kim tự tháp dễ dàng cho việc phân công công việc theo từng mức kết quả mức này là đầu vào cho mức khác sử dụng Câu 6: Nêu các đặc trưng của yêu cầu tốt ? Cho ví dụ minh họa?: - 11 Đặc trưng của yêu cầu tốt và ví dụ minh họa cho từng yêu cầu đó: o Tính không mập mờ: Yêu cầu chỉ nên được thông dịch theo 1 nghĩa duy nhất ví dụ: REQ: Hệ thống sẽ được cài đặt sử dụng ASP câu hỏi được... định sân bay hoặc là đưa vào mã sân bay, hoặc dựa vào tên thành phố o Tính đúng đắn: Nếu một yêu cầu chứa các sự kiện này phải đúng Ví dụ: REQ: Các thuế giá thuê xe ô tô phải hiển thị mọi thứ thuế (gồm 6 % thuế quốc gia) o Khả năng hiểu: Các yêu cầu phải đúng ngữ pháp và được viết một cách nhất quán Ví dụ: từ “shall” được sử dụng thay cho từ “will”, “must” Tính khả thi: Yêu cầu phải có thể thực hiện... từ người dùng Mỹ và REQ2 được gửi đi từ người dùng Việt Nam thì sẽ nảy sinh xung đột định dạng thời gian Giải quyết: REQ3: Các ngày tháng sẽ được hiển thị dựa vào định dạng được xác định trong trình duyệt web của người dùng Không dư thừa: Mỗi yêu cầu nên được phát biểu một lần duy nhất và không được phủ lên yêu cầu khác Ví dụ: REQ1: Một lịch biểu sẽ sẵn sang để trợ giúp việc nhập vào ngày bay REQ2:... cài đặt( trừu tượng) Các yêu cầu không nên chứa thông tin cài đặt và thông tin thiết kế không cần thiết Ví dụ: REQ: Thông tin nội dung các chuyến bay sẽ được lưu trức trong 1 file văn bản Cách thông tin được lưu trưc là trong suốt đối với người dùng và nên là quyết định của kiến trúc sư hoặc người thiết kế Thống nhất( Khớp nhau): KHông nên có bất kỳ sự xung đột nào giữa các yêu cầu Các xung đột trực tiếp... Tính đầy đủ: Yêu cầu nên được phát biểu một lần duy nhất và không được phủ lên yêu cầu khác Ví dụ: REQ1: Không cần thiết hiện thị đất nước bay đến với những chuyến bay trong phạm vi nước Việt Nam REQ2: Với những chuyến bay vượt qua đại dương, hệ thống sẽ hiển thị đất nước bay đến Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa Câu hỏi đặt ra: “ Vậy với chuyến bay đến Lào và Thái Lan . Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai Hoa Đề cương ôn tập Chuyên đề 2: Phân tích và quản lý yêu cầu phần mềm. A. LÝ. cơ hội cung cấp thông tin về sự hấp dẫn của nơi du lịch. o Tính cần thiết: Một yêu cầu không cần thiết khi: - Không Stackeholder nào cần yêu cầu 12 Đề cương môn chuyên đề 2 – Chúc các bạn thi. dụng chỉ đáp ứng những gì được yêu cầu: Không cài đặt những thứ mà khách hàng không yêu cầu. 10 Hình 1 .2 – Kim tự tháp các yêu cầu Đề cương môn chuyên đề 2 – Chúc các bạn thi tốt – Nguyễn Thị Mai