Bài giảng Thu nhận yêu cầu: Chương 7

ả

ầ

Qu n lý yêu c u

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI

 Requirement baseline  Requirement Management (RM)

◦Traceability ◦Công cụ

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 2

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 3

 Là tập hợp các yêu cầu chức năng và phi chức năng mà đội phát triển đã cam kết để thực thi trong hệ thống.

 Xác định baseline giúp stakeholders hiểu được khả năng và đặc trưng mà họ có thể mong thấy được trong phần mềm sẽ phát hành.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 4

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.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 5

 Requirements Manager/Project Manager: là người có nhiệm vụ quản lý các yêu cầu từ lúc trở thành baseline và tất cả các phiên bản chỉnh sửa có phê duyệt sau đó

 Mọi stakeholder đều có quyền sử dụng

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 6

 Phải có 1 ai chịu trách nhiệm về các hoạt động quản lý yêu cầu. Người phân tích yêu cầu (requirement analyst) của dự án thường là người quản lý yêu cầu, có nhiệm vụ: ◦Xác lập cơ chế lưu trữ yêu cầu ◦Xác định các thuộc tính yêu cầu ◦Quản lý trạng thái yêu cầu và cập nhật dữ liệu theo dõi

trạng thái

◦Phát sinh các báo cáo về hoạt động liên quan đến thay

đổi

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 7

 Requirements Baseline là cầu nối giữa phát triển yêu cầu (requirement development) và quản lý yêu cầu (Requirements management )

 Quản lý yêu cầu bao gồm tất cả hoạt động nhằm duy trì tính bảo toàn (integrity), độ chính xác (accuracy) và tính hiện hành của baseline.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 8

ể Ki m soát thay đ i ổ (Change Control)

ế ầ L n v t yêu c uầ (Requirement Tracing)

ề

đ iổ

ị ạ

• Đ nh nghĩa ủ

• Đ xu t thay ấ • Phân tích nh ả

ngưở

tr ng thái c a yêu c uầ

ế ị

ể Ki m soát phiên b n ả (Version Control) • Xác đ nh ị phiên b n ả ệ ủ c a tài li u yêu c uầ • Xác đ nh

• Giám sát m i ỗ ầ yêu c u đã đ nhị nghĩa ạ tr ng thái

• Ra quy t đ nh • Truy n thông ề • Tích h pợ • Đo l ị

ộ ổ ườ ng đ n c uầ ủ đ nh c a yêu

ị phiên soát xét t ng ừ yêu c uầ

Giám sát tr ngạ thái yêu c uầ (Requirement Status Tracking) • Đ nh nghĩa ị các liên k t ế ớ v i các yêu ầ c u khác • Đ nh nghĩa ị các liên k t ế ầ ớ v i các ph n ử ệ ố h th ng t khác

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 9

 Các yêu cầu trong baseline phải được phân biệt với các yêu cầu đã được đề xuất nhưng không được chấp nhận.

 Tài liệu SRS đã được baseline chỉ nên chứa các yêu cầu đã được lên kế hoạch cho phiên bản cụ thể nào đó, nó khác với các phiên bản nháp trước đó khi chưa được phê duyệt.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 10

• Đội phát triển nếu chấp nhận các thay đổi yêu cầu vừa được đề xuất  có thể không hoàn thành lịch biều và các cam kết về chất lượng của dự án.

 Người quản lý dự án phải thỏa thuận với khách hàng

về những thay đổi so với cam kết ban đầu.

• Dự án có thể đối phó lại các yêu cầu bị thay đổi theo

các cách sau: – Trì hoãn lại các yêu cầu có độ ưu tiên mức thấp – Thêm nhân viên – Buộc làm thêm giờ, trả thêm tiền trong 1 khoảng thời gian

ngắn

– Kéo dài thời gian để thêm chức năng mới – Chất lượng bị đặt trước áp lực thời gian

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 11

 Vì thay đổi là hiển nhiên nên cần phải lập kế hoạch thay đổi cho các yêu cầu trong quá trình phát triển dự án, ngay cả khi hệ thống đã bàn giao  cần xây dựng quy trình và tool để quản lý các yêu cầu bị thay đổi.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 12

 Cần xác định các hoạt động mà đội dự án phải

thực hiện để quản lý yêu cầu.

 Lưu trữ lại các hoạt động này và tập huấn các thành viên thực thi các hoạt động một cách thống nhất và hiệu quả.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 13

Trang 268

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 14

Các đặc tính trong một công cụ để hỗ trợ quy trình kiểm soá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ào một đề xuất thay đổi. Cho phép bạn định nghĩa một sơ đồ chuyển trạng thái của chu trình đề xuất thay đổi. Ràng buộc sơ đồ chuyển trạng thái sao cho chỉ những người được cấp quyề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ực hiệ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.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 15

 Có thể đưa tất cả thông tin này vào 1 quy trình quản lý yêu cầu chung, hoặc có thể viết thành các quy trình riêng lẻ như change-control, impact- analysis, và status-tracking .

 Các thủ tục này nên áp dụng cho cả tổ chức vì chúng là các chức năng thông dụng mà mỗi đội dự án nên tuân theo.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 16

 Các công cụ, kỹ thuật và quy ước để kiểm soát các

phiên bản khác nhau của tài liệu về yêu cầu.

 Làm thế nào để baseline yêu cầu  Các trạng thái yêu cầu và ai có thể làm nó thay đổi  Các thủ tục theo dõi trạng thái yêu cầu.  Cách mà các yêu cầu và thay đổi mới được đề xuất, xử tất cả các thuận và được chuyển đến

thỏa

lý, stakeholder quan trọng.

 Làm thế nào để phân tích ảnh hưởng của thay đổi  Làm thế nào để kế hoạch và cam kết của dự án phản

ánh được các thay đổi của yêu cầu.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 17

 Kế hoạch quản lý yêu cầu (Requirements Management Plan) là 1 phần trong kế hoạch quản lý dự án tổng thể.

 Nội dung của kế hoạch RM bao gồm:

◦ Giới thiệu về RM ◦ Phạm vi của tài liệu ◦ Các vấn đề làm ảnh hưởng đến việc thực thi kế hoạch. ◦ Các tài liệu có thể áp dụng trong RE như các chính sách, tiều

chuẩn

◦ Các phương pháp và công cụ được dùng trong quá trình RM. ◦ Quyền hạn và trách nhiệm của những người tham gia ◦ Các chiến lược để hoàn thành chất lượng yêu cầu, bao gồm

traceability và change control

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 18

 Feature creep dùng để chỉ hiện tượng nhiều thay đổi nhỏ được thông qua mà không cần đánh giá xét duyệt.

 Hậu quả: làm ảnh hưởng nghiêm trọng đến lợi

nhuận và ngày hoàn thành sản phẩm.

 Cách khắc phục: mọi yêu cầu thay đổi cần được

phê duyệt bởi CCB (Change Control Board).

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 19

 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ính nă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ên bản nào.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 20

 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.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 21

1. Ra quyết định 2. Truyền thông trạng thái (Communicating

Status)

3. Tái đàm phán các cam kết (Renegotiating

Commitments)

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 22

 CCB thực hiện rất nhiều phân tích khác nhau

trong quá trình kiểm soát thay đổi

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 23

 Liên quan đến việc phát hiện ra chức năng cơ bản hay hợp lý. Từ thiết kế hợp lý giúp dò tìm ngược về lại yêu cầu ban đầu và từ yêu cầu này dò tìm ra được yêu cầu của stakeholder  dẫn đến quyết định là có nên bổ sung yêu cầu này vào sản phẩm hay không?

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 24

 Mục tiêu: xác định tài chính, tài nguyên hay chi phí tạm thời phát sinh do yêu cầu bị thay đổi hay phát sinh tính chất mới.

 Thành viên của CCB phải xác định bất kỳ sửa đổi hay mở rộng nào sẽ ảnh hưởng đến hệ thống để suy ra chi phí và rủi ro của sửa đổi đó.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 25

 Đo lường tỷ lệ giữa các tính năng của sản phẩm dự kiến và sản phẩm thực, để xác định xem yêu cầu có được thực thi trong sản phẩm hay không?  Phân tích này được thực hiện bằng cách theo dõi từ các yêu cầu hệ thống lúc đầu đến các test case.

 Test là cách tốt nhất để đo lường mức độ tuân thủ

theo thiết kế.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 26

 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??

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 27

 Một yêu cầu có thể được theo dõi nếu và chỉ nếu yêu cầu này ngay từ đầu được xác định rõ ràng, có cơ chế làm cho nó khả thi trong quá trình phát triền phần mềm

 Chiến lược theo dõi là dựa vào vai trò của thành

viên dự án và nhu cầu của họ.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 28

 Mục đích của RTM là để bảo đảm các mục tiêu của yêu cầu phải phù hợp với yêu cầu bằng cách kết hợp mỗi yêu cầu với mục tiêu thông qua ma trận theo dõi.

 Requirements

traceability

is concerned with

documenting the life of a requirement.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 29

 Forward trace: ma trận theo dõi được dùng để kiểm tra tất cả các yêu cầu có được đưa vào các thành phần của hệ thống hay các kết quả (deliverable) khác hay không

 Backward trace: ma trận được dùng để xác định

các nguồn của yêu cầu.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 30

 Theo dõi yêu cầu cũng bao gồm việc theo dõi những việc khác nhằm để thỏa mãn yêu cầu như capabilities, design elements, manual operations, tests, ….

 Ma trận theo dõi cũng được dùng để bảo đảm tất cả yêu cầu khi thay đổi cũng vẫn được đưa vào các thành phần của hệ thống. Nhờ đó, ảnh hưởng của những yêu cầu bị thay đổi đến hệ thống có thể xác định được.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 31

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 32

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 33

 “U” chỉ yêu cầu người dùng  “S” chỉ yêu cầu hệ thống.  Theo dõi S12 khi trỏ đến nguồn của nó thì thấy rõ ràng yêu cầu này sai: phải loại bỏ, viết lại hay cần sửa lại việc theo dõi này.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 34

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 35

 Version control là 1 trong các điểm chính của

quản lý yêu cầu.

 Mỗi phiên bản (version) của tài liệu yêu cầu phải được xác định duy nhất. Mỗi thành viên của đội có thể truy xuất vào phiên bản hiện hành của yêu cầu và các thay đổi phải được lưu trữ lại 1 cách rõ ràng và được gửi đến mọi người có liên quan.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 36

 Để giảm thiểu nhầm lần, mâu thuẫn và sai lệch thông tin, chỉ cho phép 1 vài cá nhân được quyền cập nhật yêu cầu và bảo đảm là mã phiên bản thay đổi khi yêu cầu thay đổi.

 Mỗi phiên bản hiện hành cũng nên chứa phần revision history: xác định đã có những thay đổi gì, ngày của mỗi thay đổi, ai đã gây ra thay đổi, lý do cho mỗi thay đổi, cộng thêm số phiên bản, thường số phiên bản sẽ tăng mỗi khi có yêu cầu thay đổi.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 37

 Cơ chế kiểm soát phiên bản đơn giản nhất là tự đặt tên mỗi lần duyệt SRS theo quy ước chuẩn.  Ví dụ: phiên bản đầu tiên "Version 1.0 draft 1.“, phiên bản kế tiếp là "Version 1.0 draft 2” Số phiên bản sẽ tăng cho đến khi tài liệu được phê duyệt và baseline. Sau đó nhãn sẽ thay đổi thành "Version 1.0 approved.“, các phiên bản kế tiếp là "Version 1.1 draft 1" nếu sửa đổi nhỏ hay "Version 2.0 draft 1" nếu sửa đổi lớn.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 38

1. Khó giữ cho tài liệu đồng bộ khi có thay đổi 2. Khó truyền đạt kịp thời thay đổi đến các đội

thực hiện

3. Khó khăn trong việc lưu trữ thông tin bổ sung

về mỗi yêu cầu

4. Khó xác định được link giữa yêu cầu chức năng với các phần tử khác của hệ thống. 5. Khó khăn khi theo dõi trạng thái yêu cầu

(requirements status)

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 39

6. Khó quản lý đồng thời các tập yêu cầu cho những phiên bản khác nhau hay sản phẩm có liên quan. Khi 1 yêu cầu tham chiều đến 1 phiên bản khác, analyst cần chuyển theo cả yêu cầu đó.

7. Sử dụng lại yêu cầu có nghĩa là analyst phải tự sao chép văn bản từ SRS gốc đến SRS dùng cho hệ thống khác.

8. Khó khăn khi có nhiều người cùng tham gia sửa

đổi yêu cầu Không có chỗ thích hợp để lưu trữ lại các yêu cầu bị loại bỏ hay bị xóa khỏi baseline

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 40

 Công cụ sẽ giúp lưu trữ thông tin trong CSDL đa người dùng giúp giải quyết được các hạn chế khi quản lý yêu cầu bằng văn bản thông thường.

 Các dự án nhỏ có thể dùng bảng tính điện tử (spreadsheet) hay CSDL đơn giản để quản lý yêu cầu.

 Các dự án lớn nên dùng công cụ quản lý yêu cầu

tự động.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 41

 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)

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 42

 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.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 43

 Rational DOORS của IBM  Enterprise Architecture (www.sparxsystems.com)  CaliberRM của Borland  …

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 44

 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ác yê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ầu củ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 quy trình và các sản phẩm được chuyển giao của quy trình. Hãy chắc chắn rằng cá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.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 45

 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à quy trì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ơđồ trong Hì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êu cầ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ạn và tùy biến nó để hỗ trợ thủ tục kiểm soát thay đổi mà bạn đã phát triển trước đó.

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 46

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 47

Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI 48