1 / 48

Chapter 7 Requirements Management

Chapter 7 Requirements Management. Quản lý yêu cầu. Nội dung. Requirement baseline Requirement Management (RM) Traceability Công cụ. Requirements baseline Ranh giới yêu cầu.

hope
Download Presentation

Chapter 7 Requirements Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Chapter 7Requirements Management Quản lý yêu cầu Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  2. Nội dung • Requirement baseline • Requirement Management (RM) • Traceability • Công cụ Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  3. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  4. Requirements baselineRanh giới yêu cầu Là tập hợp các yêu cầu chức năng và phi chức năng mà đội phát triển đã cam kết để thực thi trong hệ thống. Xác định baseline giúp stakeholders hiểu được khả năng và đặc trưng mà họ có thể mong thấy được trong phần mềm sẽ phát hành. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  5. Requirements baseline Quản lý yêu cầu nhấn mạnh: Kiểm soát thay đổi đối với requirement baseline. Giữ các kế hoạch dự án phù hợp với tình trạng yêu cầu hiện tại. Kiểm soát các phiên bản của từng yêu cầu riêng biệt và của các tài liệu yêu cầu. Quản lý mối quan hệ giữa yêu cầu, các liên kết hoặc phụ thuộc giữa các yêu cầu riêng biệt và các phần tử được chuyển giao của dự án. Giám sát trạng thái của yêu cầu trong baseline. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  6. Đối tượng quản lý/sử dụng baseline Requirements Manager/Project Manager: là người có nhiệm vụ quản lý các yêu cầu từ lúc trở thành baseline và tất cả các phiên bản chỉnh sửa có phê duyệt sau đó Mọi stakeholder đều có quyền sử dụng Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  7. Vai trò của người quản lý yêu cầu(Requirement manager) • Phải có 1 ai chịu trách nhiệm về các hoạt động quản lý yêu cầu. Người phân tích yêu cầu (requirement analyst) của dự án thường là người quản lý yêu cầu, có nhiệm vụ: • Xác lập cơ chế lưu trữ yêu cầu • Xác định các thuộc tính yêu cầu • Quản lý trạng thái yêu cầu và cập nhật dữ liệu theo dõi trạng thái • Phát sinh các báo cáo về hoạt động liên quan đến thay đổi Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  8. Quản lý yêu cầu(Requirement management – RM)) Requirements Baseline là cầu nối giữa phát triển yêu cầu (requirement development) và quản lý yêu cầu (Requirements management ) Quản lý yêu cầu bao gồm tất cả hoạt động nhằm duy trì tính bảo toàn (integrity), độ chính xác (accuracy) và tính hiện hành của baseline. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  9. Các hoạt động chính để quản lý yêu cầu Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  10. Change Control Các yêu cầu trong baseline phải được phân biệt với các yêu cầu đã được đề xuất nhưng không được chấp nhận. Tài liệu SRS đã được baseline chỉ nên chứa các yêu cầu đã được lên kế hoạch cho phiên bản cụ thể nào đó, nó khác với các phiên bản nháp trước đó khi chưa được phê duyệt. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  11. Các Thách thức khi yêu cầu thay đổi • Đội phát triển nếu chấp nhận các thay đổi yêu cầu vừa được đề xuất  có thể không hoàn thành lịch biều và các cam kết về chất lượng của dự án.  Người quản lý dự án phải thỏa thuận với khách hàng về những thay đổi so với cam kết ban đầu. • Dự án có thể đối phó lại các yêu cầu bị thay đổi theo các cách sau: • Trì hoãn lại các yêu cầu có độ ưu tiên mức thấp • Thêm nhân viên • Buộc làm thêm giờ, trả thêm tiền trong 1 khoảng thời gian ngắn • Kéo dài thời gian để thêm chức năng mới • Chất lượng bị đặt trước áp lực thời gian Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  12. Change Control Vì thay đổi là hiển nhiên nên cần phải lập kế hoạch thay đổi cho các yêu cầu trong quá trình phát triển dự án, ngay cả khi hệ thống đã bàn giao  cần xây dựng quy trình và tool để quản lý các yêu cầu bị thay đổi. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  13. Requirements Management Procedures Cần xác định các hoạt động mà đội dự án phải thực hiện để quản lý yêu cầu. Lưu trữ lại các hoạt động này và tập huấn các thành viên thực thi các hoạt động một cách thống nhất và hiệu quả. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  14. Requirements Management Procedures Trang 268 Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  15. CÔNG CỤ KIỂM SOÁT THAY ĐỔI (Tools) Các đặc tính trong một công cụ để hỗ trợ quy trình kiểmsoát thay đổi yêu cầu: Cho phép bạn định nghĩa các mục dữ liệu (data items) bạn muốn đưa vàomột đề xuất thay đổi. Cho phép bạn định nghĩa một sơđồ chuyểntrạng thái của chu trình đề xuấtthay đổi. Ràng buộc sơđồ chuyển trạng thái sao cho chỉ những người được cấpquyền mới được phép thay đổi trạng thái của đề xuất. Ghi lại ngày tháng của mỗi thay đổi trạng thái và định danh của người thựchiện thay đổi. Cho phép bạn nhận các ghi chú bằng email tự động khi một người đề xuất(Originator) đệ trình một đề xuất thay đổi mới hoặc khi một trạng thái của đềxuất được cập nhật. Cho phép bạn sinh ra các báo cáo tiêu chuẩn hoặc được tùy biến và các biểuđồ bạn cần. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  16. Thông tin cần quản lý Có thể đưa tất cả thông tin này vào 1 quy trình quản lý yêu cầu chung, hoặc có thể viết thành các quy trình riêng lẻ như change-control, impact-analysis, và status-tracking . Các thủ tục này nên áp dụng cho cả tổ chức vì chúng là các chức năng thông dụng mà mỗi đội dự án nên tuân theo. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  17. Thông tin cần quản lý Các công cụ, kỹ thuật và quy ước để kiểm soát các phiên bản khác nhau của tài liệu về yêu cầu. Làm thế nào để baseline yêu cầu Các trạng thái yêu cầu và ai có thể làm nó thay đổi Các thủ tục theo dõi trạng thái yêu cầu. Cách mà các yêu cầu và thay đổi mới được đề xuất, xử lý, thỏa thuận và được chuyển đến tất cả các stakeholder quan trọng. Làm thế nào để phân tích ảnh hưởng của thay đổi Làm thế nào để kế hoạch và cam kết của dự án phản ánh được các thay đổi của yêu cầu. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  18. Lập kế hoạch quản lý yêu cầu • Kế hoạch quản lý yêu cầu (Requirements Management Plan) là 1 phần trong kế hoạch quản lý dự án tổng thể. • Nội dung của kế hoạch RM bao gồm: • Giới thiệu về RM • Phạm vi của tài liệu • Các vấn đề làm ảnh hưởng đến việc thực thi kế hoạch. • Các tài liệu có thể áp dụng trong RE như các chính sách, tiều chuẩn • Các phương pháp và công cụ được dùng trong quá trình RM. • Quyền hạn và trách nhiệm của những người tham gia • Các chiến lược để hoàn thành chất lượng yêu cầu, bao gồm traceability và change control Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  19. Feature creep Feature creep dùng để chỉ hiện tượng nhiều thay đổi nhỏ được thông qua mà không cần đánh giá xét duyệt. Hậu quả: làm ảnh hưởng nghiêm trọng đến lợi nhuận và ngày hoàn thành sản phẩm. Cách khắc phục: mọi yêu cầu thay đổi cần được phê duyệt bởi CCB (Change Control Board). Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  20. CCB (Change Control Board)Ban kiểm soát thay đổi CCB có thể là một cá nhân hoặc là một nhóm, ra quyết định chấp thuận hay không về các thay đổi yêu cầu được đề xuất và các tínhnăng sản phẩm mới được gợi ý. CCB cũng ra quyết định về các khiếm khuyết(defect) đã phát hiện cần được sửa chữa và được phát hành bản sửa chữa ở phiênbản nào. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  21. CCB (Change Control Board)Ban kiểm soát thay đổi • CCB có thể bao gồm các lĩnh vực sau: • Cấp quản lý chương trình hoặc sản phẩm. • Cấp quản lý dự án. • Nhóm phát triển. • Kiểm thử hoặc đảm bảo chất lượng. • Marketing hoặc đại diện khách hàng. • Người làm tài liệu người dùng. • Người hỗ trợ kỹ thuật. • Nhóm hỗ trợ sản phẩm (help desk). • Nhóm quản lý cấu hình. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  22. QUY CHẾ HOẠT ĐỘNG CỦA CCB (CCB CHARTER) Ra quyết định Truyền thông trạng thái (Communicating Status) Tái đàm phán các cam kết (Renegotiating Commitments) Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  23. CCB (Change Control Board)Ban kiểm soát thay đổi CCB thực hiện rất nhiều phân tích khác nhau trong quá trình kiểm soát thay đổi Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  24. Impact analysis Liên quan đến việc phát hiện ra chức năng cơ bản hay hợp lý. Từ thiết kế hợp lý giúp dò tìm ngược về lại yêu cầu ban đầu và từ yêu cầu này dò tìm ra được yêu cầu của stakeholder  dẫn đến quyết định là có nên bổ sung yêu cầu này vào sản phẩm hay không? Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  25. Derivation analysis Mục tiêu: xác định tài chính, tài nguyên hay chi phí tạm thời phát sinh do yêu cầu bị thay đổi hay phát sinh tính chất mới. Thành viên của CCB phải xác định bất kỳ sửa đổi hay mở rộng nào sẽ ảnh hưởng đến hệ thống để suy ra chi phí và rủi ro của sửa đổi đó. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  26. Coverage Analysis Đo lường tỷ lệ giữa các tính năng của sản phẩm dự kiến và sản phẩm thực, để xác định xem yêu cầu có được thực thi trong sản phẩm hay không? Phân tích này được thực hiện bằng cách theo dõi từ các yêu cầu hệ thống lúc đầu đến các test case. Test là cách tốt nhất để đo lường mức độ tuân thủ theo thiết kế. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  27. Các hoạt động quản lý yêu cầu Identifying volatile requirements Establishing Policies for requirements processes and supporting them with workflow tools, guidelines, templates, and examples Prioritizing Requirements Establishing and updating the requirements baseline Documenting Decisions Planning releases and allocating requirement to releases Assignment 24?? Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  28. Traceability Một yêu cầu có thể được theo dõi nếu và chỉ nếu yêu cầu này ngay từ đầu được xác định rõ ràng, có cơ chế làm cho nó khả thi trong quá trình phát triền phần mềm Chiến lược theo dõi là dựa vào vai trò của thành viên dự án và nhu cầu của họ. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  29. REQUIREMENTS TRACEABILITY MATRIX(RTM) Mục đích của RTM là để bảo đảm các mục tiêu của yêu cầu phải phù hợp với yêu cầu bằng cách kết hợp mỗi yêu cầu với mục tiêu thông qua ma trận theo dõi. Requirements traceability is concerned with documenting the life of a requirement. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  30. REQUIREMENTS TRACEABILITY MATRIX(RTM) Forward trace: ma trận theo dõi được dùng để kiểm tra tất cả các yêu cầu có được đưa vào các thành phần của hệ thống hay các kết quả (deliverable) khác hay không Backward trace: ma trận được dùng để xác định các nguồn của yêu cầu. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  31. REQUIREMENTS TRACEABILITY MATRIX(RTM) Theo dõi yêu cầu cũng bao gồm việc theo dõi những việc khác nhằm để thỏa mãn yêu cầu như capabilities, design elements, manual operations, tests, …. Ma trận theo dõi cũng được dùng để bảo đảm tất cả yêu cầu khi thay đổi cũng vẫn được đưa vào các thành phần của hệ thống. Nhờ đó, ảnh hưởng của những yêu cầu bị thay đổi đến hệ thống có thể xác định được. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  32. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  33. Ví dụ1: Ma trận theo dõi Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  34. Ví dụ1: Ma trận theo dõi “U” chỉ yêu cầu người dùng “S” chỉ yêu cầu hệ thống. Theo dõi S12 khi trỏ đến nguồn của nó thì thấy rõ ràng yêu cầu này sai: phải loại bỏ, viết lại hay cần sửa lại việc theo dõi này. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  35. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  36. Requirements Version Control Version control là 1 trong các điểm chính của quản lý yêu cầu. Mỗi phiên bản (version) của tài liệu yêu cầu phải được xác định duy nhất. Mỗi thành viên của đội có thể truy xuất vào phiên bản hiện hành của yêu cầu và các thay đổi phải được lưu trữ lại 1 cách rõ ràng và được gửi đến mọi người có liên quan. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  37. Requirements Version Control Để giảm thiểu nhầm lần, mâu thuẫn và sai lệch thông tin, chỉ cho phép 1 vài cá nhân được quyền cập nhật yêu cầu và bảo đảm là mã phiên bản thay đổi khi yêu cầu thay đổi. Mỗi phiên bản hiện hành cũng nên chứa phần revision history: xác định đã có những thay đổi gì, ngày của mỗi thay đổi, ai đã gây ra thay đổi, lý do cho mỗi thay đổi, cộng thêm số phiên bản, thường số phiên bản sẽ tăng mỗi khi có yêu cầu thay đổi. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  38. Version control mechanism Cơ chế kiểm soát phiên bản đơn giản nhất là tự đặt tên mỗi lần duyệt SRS theo quy ước chuẩn. Ví dụ: phiên bản đầu tiên "Version 1.0 draft 1.“, phiên bản kế tiếp là "Version 1.0 draft 2” Số phiên bản sẽ tăng cho đến khi tài liệu được phê duyệt và baseline. Sau đó nhãn sẽ thay đổi thành "Version 1.0 approved.“, các phiên bản kế tiếp là "Version 1.1 draft 1" nếu sửa đổi nhỏ hay "Version 2.0 draft 1" nếu sửa đổi lớn. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  39. Các hạn chế khi quản lý yêu cầu bằng văn bản Khó giữ cho tài liệu đồng bộ khi có thay đổi Khó truyền đạt kịp thời thay đổi đến các đội thực hiện Khó khăn trong việc lưu trữ thông tin bổ sung về mỗi yêu cầu Khó xác định được link giữa yêu cầu chức năng với các phần tử khác của hệ thống. Khó khăn khi theo dõi trạng thái yêu cầu (requirements status) Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  40. Các hạn chế khi quản lý yêu cầu bằng văn bản Khó quản lý đồng thời các tập yêu cầu cho những phiên bản khác nhau hay sản phẩm có liên quan. Khi 1 yêu cầu tham chiều đến 1 phiên bản khác, analyst cần chuyển theo cả yêu cầu đó. Sử dụng lại yêu cầu có nghĩa là analyst phải tự sao chép văn bản từ SRS gốc đến SRS dùng cho hệ thống khác. Khó khăn khi có nhiều người cùng tham gia sửa đổi yêu cầu Không có chỗ thích hợp để lưu trữ lại các yêu cầu bị loại bỏ hay bị xóa khỏi baseline Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  41. Vai trò của công cụ quản lý yêu cầu(Requirement management tools) Công cụ sẽ giúp lưu trữ thông tin trong CSDL đa người dùng giúp giải quyết được các hạn chế khi quản lý yêu cầu bằng văn bản thông thường. Các dự án nhỏ có thể dùng bảng tính điện tử (spreadsheet) hay CSDL đơn giản để quản lý yêu cầu. Các dự án lớn nên dùng công cụ quản lý yêu cầu tự động. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  42. Chức năng của công cụ quản lý yêu cầu Create and view requirements as entities and properties directly in the model Collate the requirements in an external CSV file and then import them into your model Detail use cases and scenarios directly in the model Enter standard attributes (properties) for each requirement, such as difficulty, status and type, and define your own attributes (properties) Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  43. Chức năng của công cụ quản lý yêu cầu Trace requirements to Use Cases, business rules, test cases and analysis artifacts (using, for example, the Relationship Matrix) Trace and view the impact of changes on requirements (through, for example, the Traceability window) and review the changes themselves Create customer-quality MS Word and HTML reports on requirements. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  44. Một vài công cụ quản lý yêu cầu Rational DOORS của IBM Enterprise Architecture (www.sparxsystems.com) CaliberRM của Borland … Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  45. Assigment Lựa chọn các trạng thái mà bạn muốn sử dụng để mô tả vòng đời của cácyêu cầu chức năng trong dự án của bạn. Định nghĩa tình trạng hiện thời cho mỗi yêu cầu trong SRS và theo sát sự diễn biến của yêu cầu trong phần còn lại của dự án. Định nghĩa một sơđồ kiểm soát phiên bản để định danh tài liệu yêu cầucủa bạn. Tài liệu hóa sơđồ này nhưlà một phần của quy trình quản lý yêu cầu của bạn. Viết một mô tả quy trình về các bước mà tổ chức của bạn sẽ thực hiện để quản lý các yêu cầu của mỗi dự án. Khuyến khích các nhà phân tích soạn thảo, soát xét, làm dự án thử nghiệm, chấp thuận các hoạt động của quytrình và các sản phẩm được chuyển giao của quy trình. Hãy chắc chắn rằngcác bước của quy trình mà bạn lựa chọn là có tính thực hành và thực tế,chúng giúp bạn tăng thêm giá trị của dự án. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  46. Assigment Xác định những người ra quyết định trong dự án của bạn và tổ chức họnhưmột ban kiểm soát thay đổi. Yêu cầu CCB viết một quy chế hoạt độngđể chắc chắn mỗi người đều hiểu mục đích của ban, thành phần và quytrình ra quyết định. Định nghĩa một sơđồ state-transition đối với chu trình sống của các thayđổi yêu cầu được đề xuất trong dự án của bạn, bắt đầu với sơđồ trongHình 17-2. Viết một thủ tục mô tả nhóm của bạn sẽ xử lý các thay đổi yêucầu được đề xuất nhưthế nào. Sử dụng thủ tục bằng tay cho đến khi bạn tựnhận thấy thủ tục đã mang tính thực tế, hiệu quả, đơn giản hết mức có thể. Lựa chọn một công cụ giám sát thích hợp với môi trường làm việc của bạnvà tùy biến nó để hỗ trợ thủ tục kiểm soát thay đổi mà bạn đã phát triểntrước đó. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  47. Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

  48. Một vài công cụ quản lý yêu cầu Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

More Related