Liên kết trong chuỗi yêu cầu

“Chúng tôi vừa biết rằng hợp đồng công đoàn mới đang thay đổi cách tính lương
làm thêm giờ và tiền thưởng theo ca,” Justin báo cáo tại cuộc họp nhóm hàng tuần.
“Nó cũng đang thay đổi cách các quy tắc thâm niên ảnh hưởng đến mức độ ưu tiên
đối với lịch trình nghỉ phép và sở thích thay đổi ca. Chúng tôi phải cập nhật bảng
lương và hệ thống lập lịch trình nhân viên để xử lý tất cả những thay đổi này ngay
lập tức. Anh nghĩ sẽ mất bao lâu để hoàn thành việc này, Chris?”

“Trời ạ, sẽ có rất nhiều việc đấy,” Chris nói. “Logic cho các quy tắc thâm niên
được rải khắp hệ thống lập lịch trình. Tôi chưa thể cung cấp cho bạn một ước tính
hợp lý. Sẽ mất hàng giờ chỉ để quét mã và cố gắng tìm tất cả những nơi mà các quy
tắc đó hiển thị.”

Những thay đổi phần mềm có vẻ đơn giản thường có tác động sâu rộng, đòi hỏi
phải sửa đổi nhiều phần của hệ thống. Thật khó để tìm thấy tất cả các yếu tố hệ
thống có thể bị ảnh hưởng bởi một yêu cầu thay đổi. Chương 28, “Thay đổi xảy
ra,” đã thảo luận về tầm quan trọng của việc thực hiện phân tích tác động để đảm
bảo nhóm biết họ đang làm gì trước khi cam kết thực hiện thay đổi được đề xuất.
Việc phân tích tác động của thay đổi sẽ dễ dàng hơn nếu bạn có một lộ trình chỉ ra
nơi từng yêu cầu hoặc quy tắc kinh doanh được triển khai trong phần mềm.

Chương này đề cập đến chủ đề theo dõi yêu cầu (hoặc truy xuất nguồn gốc). Thông
tin theo dõi yêu cầu ghi lại sự phụ thuộc và liên kết logic giữa các yêu cầu riêng lẻ
và các phần tử hệ thống khác. Các yếu tố này bao gồm các yêu cầu khác thuộc
nhiều loại khác nhau, quy tắc kinh doanh, kiến trúc và các thành phần thiết kế
khác, mô-đun mã nguồn, kiểm tra và tệp trợ giúp. Thông tin theo dõi tạo điều kiện
thuận lợi cho việc phân tích tác động bằng cách giúp bạn xác định tất cả các sản
phẩm công việc mà bạn có thể phải sửa đổi để thực hiện thay đổi yêu cầu được đề
xuất.

Yêu cầu truy tìm

Liên kết theo dõi cho phép bạn theo dõi vòng đời của một yêu cầu cả về phía trước
và phía sau, từ nguồn gốc cho đến khi thực hiện. Chương 11, “Viết các yêu cầu
xuất sắc,” đã xác định truy xuất nguồn gốc là một trong những đặc điểm của các
yêu cầu xuất sắc. (Lưu ý rằng có thể theo dõi—có các thuộc tính để hỗ trợ theo dõi
—không giống như được theo dõi—thực sự có các liên kết logic giữa các yêu cầu
và các yếu tố khác được ghi lại.) Để các yêu cầu có thể theo dõi được, mỗi yêu cầu
phải được gắn nhãn duy nhất và liên tục để bạn có thể đề cập đến nó một cách rõ
ràng trong suốt dự án.

Viết các yêu cầu một cách chi tiết, thay vì tạo các đoạn văn lớn chứa nhiều yêu cầu
chức năng riêng lẻ mà người đọc phải phân tích. Hình 29-1 minh họa bốn loại liên
kết theo dõi yêu cầu (Jarke 1998). Nhu cầu của khách hàng được truy nguyên từ
yêu cầu, vì vậy bạn có thể biết yêu cầu nào sẽ bị ảnh hưởng nếu những nhu cầu đó
thay đổi trong hoặc sau quá trình phát triển. Nhu cầu của khách hàng có thể được
trình bày rõ ràng dưới dạng mục tiêu kinh doanh, nhu cầu thị trường và/hoặc yêu
cầu của người dùng. Một tập hợp đầy đủ các dấu vết chuyển tiếp cũng giúp bạn tin
tưởng rằng các yêu cầu đã đặt ra đã giải quyết tất cả các nhu cầu đã nêu của khách
hàng. Ngược lại, bạn có thể theo dõi ngược từ yêu cầu đến nhu cầu của khách hàng
để xác định nguồn gốc của từng yêu cầu phần mềm. Nếu bạn chọn thể hiện nhu cầu
của khách hàng dưới dạng các trường hợp sử dụng, thì nửa trên của Hình 29-1
minh họa việc theo dõi giữa các trường hợp sử dụng và các yêu cầu chức năng.

Nửa dưới của Hình 29-1 chỉ ra rằng, khi các yêu cầu chảy vào các sản phẩm phân
phối xuôi dòng trong quá trình phát triển, bạn có thể theo dõi từ các yêu cầu bằng
cách xác định các liên kết giữa các yêu cầu chức năng và phi chức năng riêng lẻ và
các thành phần hệ thống cụ thể. Loại liên kết này cho phép bạn xác định rằng bạn
đã đáp ứng mọi yêu cầu vì bạn biết thành phần thiết kế và thành phần mã nào giải
quyết từng yêu cầu. Loại liên kết thứ tư theo dõi các phần tử cụ thể của sản phẩm
ngược với các yêu cầu để bạn biết tại sao mỗi phần tử được tạo. Hầu hết các ứng
dụng bao gồm một số giàn giáo hoặc mã kích hoạt, chẳng hạn như để thử nghiệm,
không liên quan trực tiếp đến các yêu cầu do người dùng chỉ định, nhưng bạn nên
biết lý do tại sao mỗi dòng mã được viết.

Giả sử một người thử nghiệm gặp chức năng không mong muốn mà không có yêu
cầu bằng văn bản tương ứng. Mã này có thể chỉ ra rằng nhà phát triển đã triển khai
một yêu cầu được truyền đạt bằng lời nói hoặc ngụ ý hợp pháp mà nhà phân tích
nghiệp vụ hiện có thể thêm vào bộ yêu cầu. Ngoài ra, đó có thể là “mã mồ côi”,
một trường hợp mạ vàng không có trong sản phẩm. Các liên kết theo dõi có thể
giúp bạn sắp xếp các loại tình huống này và xây dựng một bức tranh hoàn chỉnh
hơn về cách các phần trong hệ thống của bạn khớp với nhau như thế nào. Ngược
lại, các thử nghiệm bắt nguồn từ—và được truy ngược trở lại—các yêu cầu riêng lẻ
cung cấp một cơ chế để phát hiện các yêu cầu chưa được thực hiện, bởi vì chức
năng dự kiến sẽ bị thiếu trong hệ thống đang được thử nghiệm. Liên kết theo dõi
cũng giúp bạn theo dõi nguồn gốc, kết nối và phụ thuộc giữa các yêu cầu riêng lẻ.
Thông tin này tiết lộ sự lan truyền của thay đổi có thể xảy ra khi một yêu cầu cụ
thể bị xóa hoặc sửa đổi.

Hình 29-2 minh họa nhiều loại mối quan hệ xác định nguồn gốc có thể được xác
định trong một dự án. Tất nhiên, bạn không cần xác định và quản lý tất cả các loại
liên kết theo dõi này. Trong nhiều dự án, bạn có thể đạt được hầu hết các lợi ích
truy xuất nguồn gốc mà bạn muốn chỉ với một phần nỗ lực tiềm năng. Có thể bạn
chỉ cần theo dõi các bài kiểm tra hệ thống trở lại các yêu cầu chức năng hoặc yêu
cầu của người dùng. Thực hiện phân tích lợi ích chi phí để quyết định liên kết nào
sẽ đóng góp vào sự thành công của dự án của bạn, cả về nỗ lực phát triển và bảo trì
dài hạn. Đừng yêu cầu các thành viên trong nhóm dành thời gian ghi lại thông tin
trừ khi bạn biết cách họ có thể sử dụng thông tin đó.

Động lực cho các yêu cầu theo dõi

Tôi đã có trải nghiệm đáng xấu hổ khi viết một chương trình và sau đó nhận ra
rằng mình đã vô tình bỏ qua một yêu cầu. Nó nằm trong SRS—tôi chỉ đơn giản là
bỏ lỡ nó. Tôi phải quay lại và viết mã bổ sung sau khi tôi nghĩ mình đã lập trình
xong. Việc bỏ qua một yêu cầu không chỉ là một sự bối rối nếu điều đó có nghĩa là
khách hàng không hài lòng hoặc sản phẩm thiếu một chức năng quan trọng. Theo
dõi yêu cầu cung cấp một cách để chứng minh sự tuân thủ với đặc điểm kỹ thuật,
hợp đồng hoặc quy định. Ở cấp độ tổ chức, việc triển khai theo dõi yêu cầu có thể
cải thiện chất lượng sản phẩm của bạn, giảm chi phí bảo trì và tạo điều kiện tái sử
dụng.

Giữ thông tin liên kết hiện tại khi hệ thống trải qua quá trình phát triển và bảo trì
cần có kỷ luật và thời gian. Nếu thông tin theo dõi trở nên lỗi thời, có thể bạn sẽ
không bao giờ tái tạo lại được. Dữ liệu theo dõi lỗi thời hoặc không chính xác gây
lãng phí thời gian bằng cách đưa các nhà phát triển và người bảo trì đi sai đường,
phá hủy mọi niềm tin mà các nhà phát triển có thể có trong thông tin. Vì những
thực tế này, bạn nên áp dụng theo dõi yêu cầu vì những lý do đúng đắn (Ramesh et
al. 1995). Sau đây là một số lợi ích tiềm năng của việc triển khai theo dõi yêu cầu:

-Tìm các yêu cầu còn thiếu Hãy tìm các yêu cầu kinh doanh không theo dõi bất kỳ
yêu cầu người dùng nào và các yêu cầu người dùng không theo dõi bất kỳ yêu cầu
chức năng nào

-Tìm kiếm các yêu cầu không cần thiết Tìm kiếm bất kỳ yêu cầu chức năng nào
không theo dõi Tôi đã có trải nghiệm đáng xấu hổ khi viết một chương trình và sau
đó nhận ra rằng mình đã vô tình bỏ qua một yêu cầu. Nó nằm trong SRS—tôi chỉ
đơn giản là bỏ lỡ nó. Tôi phải quay lại và viết mã bổ sung sau khi tôi nghĩ mình đã
lập trình xong. Việc bỏ qua một yêu cầu không chỉ là một sự bối rối nếu điều đó có
nghĩa là khách hàng không hài lòng hoặc sản phẩm thiếu một chức năng quan
trọng. Theo dõi yêu cầu cung cấp một cách để chứng minh sự tuân thủ với đặc
điểm kỹ thuật, hợp đồng hoặc quy định. Ở cấp độ tổ chức, việc triển khai theo dõi
yêu cầu có thể cải thiện chất lượng sản phẩm của bạn, giảm chi phí bảo trì và tạo
điều kiện tái sử dụng. trở lại các yêu cầu của người dùng hoặc doanh nghiệp và do
đó có thể không cần thiết.

-Chứng nhận và tuân thủ Bạn có thể sử dụng thông tin theo dõi khi chứng nhận
một sản phẩm quan trọng về an toàn, để chứng minh rằng tất cả các yêu cầu đã
được triển khai—mặc dù điều đó không xác nhận rằng chúng đã được triển khai
chính xác! Thông tin theo dõi chứng minh rằng các yêu cầu bắt buộc đối với việc
tuân thủ quy định đã được đưa vào và giải quyết, như thường cần thiết cho các ứng
dụng cho các công ty dịch vụ tài chính và chăm sóc sức khỏe.

-Phân tích tác động thay đổi Nếu không có thông tin dấu vết, rất có thể bạn sẽ bỏ
qua một thành phần hệ thống sẽ bị ảnh hưởng nếu bạn thêm, xóa hoặc sửa đổi một
yêu cầu cụ thể.

-Bảo trì Thông tin theo dõi đáng tin cậy giúp bạn có khả năng thực hiện các thay
đổi một cách chính xác và đầy đủ trong quá trình bảo trì. Khi chính sách của công
ty hoặc quy định của chính phủ thay đổi, hệ thống phần mềm thường phải được
cập nhật. Một bảng cho biết vị trí của từng quy tắc kinh doanh hiện hành được giải
quyết trong các yêu cầu chức năng, thiết kế và mã giúp dễ dàng thực hiện các thay
đổi cần thiết một cách chính xác.

-Theo dõi dự án Nếu bạn ghi lại dữ liệu theo dõi trong quá trình phát triển, bạn sẽ
có một bản ghi chính xác về tình trạng triển khai của chức năng đã lên kế hoạch.
Các liên kết vắng mặt cho biết các sản phẩm công việc chưa được tạo.

-Tái cấu trúc Bạn có thể liệt kê các chức năng trong một hệ thống hiện có mà bạn
đang thay thế và theo dõi chúng đến nơi chúng được giải quyết trong các yêu cầu
và thành phần phần mềm của hệ thống mới

-Tái sử dụng Thông tin theo dõi tạo điều kiện thuận lợi cho việc tái sử dụng các
thành phần sản phẩm bằng cách xác định các gói yêu cầu, thiết kế, mã và thử
nghiệm liên quan.
-Thử nghiệm Khi một thử nghiệm thất bại, các liên kết giữa các thử nghiệm, yêu
cầu và các nhà phát triển mã hướng tới các khu vực có khả năng kiểm tra lỗi

Nhiều trong số này là những lợi ích lâu dài, giảm chi phí vòng đời sản phẩm tổng
thể nhưng làm tăng chi phí phát triển do nỗ lực bỏ ra để tích lũy và quản lý thông
tin theo dõi.
Xem việc theo dõi yêu cầu như một khoản đầu tư giúp bạn tăng cơ hội cung cấp
một sản phẩm có thể bảo trì, đáp ứng tất cả các yêu cầu đã nêu của khách hàng.
Khoản đầu tư này sẽ trả cổ tức bất cứ lúc nào bạn phải sửa đổi, mở rộng hoặc thay
thế sản phẩm. Việc thiết lập dấu vết sẽ không tốn nhiều công sức nếu bạn thu thập
thông tin khi quá trình phát triển được tiến hành, nhưng việc thực hiện trên một hệ
thống hoàn chỉnh sẽ rất tẻ nhạt và tốn kém.

Ma trận truy xuất nguồn gốc yêu cầu

Cách phổ biến nhất để biểu diễn các liên kết giữa các yêu cầu và các thành phần hệ
thống khác là trong ma trận truy xuất nguồn gốc yêu cầu, còn được gọi là ma trận
theo dõi yêu cầu hoặc bảng truy xuất nguồn gốc.
Joy Beatty và Anthony Chen (2012) mô tả một công cụ tương tự được gọi là ma
trận ánh xạ yêu cầu cho thấy mối quan hệ giữa nhiều loại đối tượng. Bảng 29-1
minh họa một phần của ma trận truy xuất nguồn gốc các yêu cầu, được rút ra từ Hệ
thống Theo dõi Hóa chất. Trước đây, khi tôi thiết lập các ma trận như vậy, tôi đã
bắt đầu với một bản sao của SRS cơ sở và xóa mọi thứ ngoại trừ các nhãn cho các
yêu cầu chức năng. Sau đó, tôi thiết lập một bảng được trình bày giống như Bảng
29-1 chỉ có cột “Yêu cầu chức năng” được điền. Khi các thành viên trong nhóm và
tôi làm việc trong dự án, chúng tôi dần dần điền vào các ô trống trong ma trận.

Bảng 29-1 cho thấy cách mỗi yêu cầu chức năng được liên kết ngược với một
trường hợp sử dụng cụ thể và chuyển tiếp tới một hoặc nhiều yếu tố thiết kế, mã và
kiểm tra. Một yếu tố thiết kế có thể là một cái gì đó giống như một thành phần kiến
trúc, một bảng trong mô hình dữ liệu quan hệ hoặc một lớp đối tượng. Tham chiếu
mã có thể là phương thức lớp, thủ tục được lưu trữ, tên tệp mã nguồn hoặc mô-đun
trong tệp nguồn. Bao gồm nhiều chi tiết dấu vết hơn sẽ tốn nhiều công sức hơn,
nhưng nó cung cấp cho bạn vị trí chính xác của các thành phần phần mềm liên
quan.

Điền thông tin khi công việc được hoàn thành, không phải khi nó được lên kế
hoạch. Nghĩa là, chỉ nhập CatalogSort() vào cột “Phần tử mã” của hàng đầu tiên
trong Bảng 29-1 khi mã trong hàm đó đã được viết. Bằng cách đó, người đọc biết
rằng các ô được điền trong ma trận truy xuất nguồn gốc yêu cầu cho biết công việc
đã được hoàn thành

Một cách khác để biểu diễn thông tin theo dõi là thông qua một tập hợp các ma
trận xác định các liên kết giữa cặp yếu tố hệ thống, chẳng hạn như:

-Một loại yêu cầu đối với các yêu cầu khác cùng loại

-Một loại yêu cầu đối với các yêu cầu thuộc loại khác

-Một loại yêu cầu để kiểm tra

Bạn có thể sử dụng các ma trận này để xác định các mối quan hệ khác nhau có thể
có giữa các cặp yêu cầu, chẳng hạn như “chỉ định/được chỉ định bởi”, “phụ thuộc
vào”, “là cha mẹ của” và “ràng buộc/bị ràng buộc bởi” (Sommerville và Sawyer
1997).

Bảng 29-2 minh họa ma trận truy xuất nguồn gốc hai chiều. Hầu hết các ô trong
ma trận đều trống. Mỗi ô tại giao điểm của hai thành phần được liên kết chứa một
biểu tượng để chỉ ra kết nối. Bảng 29-2 sử dụng một mũi tên để chỉ ra rằng một
yêu cầu chức năng nhất định được bắt nguồn từ một trường hợp sử dụng cụ thể.
Chẳng hạn, FR-2 được truy tìm từ UC-1 và FR-5 được truy tìm từ cả UC-2 và UC-
4. Điều này chỉ ra rằng yêu cầu chức năng FR-5 được sử dụng lại trong hai trường
hợp sử dụng, UC-2 và UC-4.

Liên kết theo dõi có thể xác định mối quan hệ một-một, một-nhiều hoặc nhiều-
nhiều giữa hệ thống phần tử. Định dạng trong Bảng 29-1 đáp ứng các yếu tố chính
này bằng cách cho phép bạn nhập một số mục trong mỗi ô của bảng. Dưới đây là
một số ví dụ về các yếu tố liên kết có thể có:

-Một-một Một yếu tố thiết kế được triển khai trong một mô-đun mã.

-Yêu cầu chức năng một-nhiều Một yêu cầu chức năng được xác minh bằng nhiều
thử nghiệm.

-Nhiều-nhiều Mỗi trường hợp sử dụng dẫn đến nhiều yêu cầu chức năng và một số
yêu cầu chức năng là phổ biến cho một số trường hợp sử dụng. Tương tự, một yếu
tố thiết kế được chia sẻ hoặc lặp lại có thể đáp ứng một số yêu cầu chức năng. Lý
tưởng nhất là bạn sẽ nắm bắt được tất cả các kết nối này, nhưng trên thực tế, các
mối quan hệ theo dõi nhiều-nhiều trở nên phức tạp và khó quản lý.
Các yêu cầu phi chức năng như thuộc tính chất lượng thường không theo dõi trực
tiếp vào mã. Yêu cầu về thời gian phản hồi có thể quy định việc sử dụng phần
cứng, thuật toán, cấu trúc cơ sở dữ liệu và phương pháp tiếp cận kiến trúc nhất
định. Yêu cầu về tính di động có thể hạn chế các tính năng ngôn ngữ mà lập trình
viên sử dụng nhưng có thể không dẫn đến các đoạn mã cụ thể cho phép tính di
động. Các thuộc tính chất lượng khác thực sự được triển khai trong mã. Các yêu
cầu bảo mật đối với xác thực người dùng dẫn đến các yêu cầu chức năng bắt nguồn
có thể được triển khai thông qua mật khẩu hoặc chức năng sinh trắc học. Trong
những trường hợp đó, bạn có thể theo dõi ngược các yêu cầu chức năng tương ứng
với yêu cầu phi chức năng gốc của chúng và chuyển tiếp vào các sản phẩm phân
phối xuôi dòng như bình thường. Liên kết theo dõi nên được xác định bởi bất kỳ ai
có sẵn thông tin thích hợp. Bảng 29-3 xác định một số nguồn tri thức điển hình về
các liên kết giữa các loại đối tượng nguồn và đối tượng đích. Xác định vai trò và cá
nhân sẽ cung cấp từng loại thông tin theo dõi cho dự án của bạn. Mong đợi một số
phản hồi từ những người bận rộn mà nhà phân tích hoặc người quản lý dự án yêu
cầu Hình 29-3 minh họa chuỗi truy xuất nguồn gốc có thể có liên quan đến các yêu
cầu phi chức năng.

Liên kết theo dõi nên được xác định bởi bất kỳ ai có sẵn thông tin thích hợp. Bảng
29-3 xác định một số nguồn tri thức điển hình về các liên kết giữa các loại đối
tượng nguồn và đối tượng đích. Xác định vai trò và cá nhân sẽ cung cấp từng loại
thông tin theo dõi cho dự án của bạn. Mong đợi một số phản hồi từ những người
bận rộn mà nhà phân tích hoặc người quản lý dự án yêu cầu để cung cấp dữ liệu
này. Những người hành nghề đó có quyền được giải thích về việc theo dõi yêu cầu,
tại sao nó mang lại giá trị và tại sao họ được yêu cầu đóng góp cho quy trình. Chỉ
ra rằng chi phí gia tăng để nắm bắt thông tin dấu vết tại thời điểm hoàn thành công
việc là nhỏ; chủ yếu là vấn đề về thói quen, kỷ luật và thiết lập cơ chế lưu trữ.

Công cụ theo dõi yêu cầu

Như Chương 30, “Các công cụ dành cho kỹ thuật yêu cầu,” mô tả, các công cụ
quản lý yêu cầu thương mại thường có khả năng theo dõi yêu cầu mạnh mẽ. Bạn có
thể lưu trữ các yêu cầu và thông tin khác trong cơ sở dữ liệu của công cụ và xác
định các liên kết giữa các loại đối tượng được lưu trữ khác nhau, bao gồm các liên
kết ngang hàng giữa hai yêu cầu cùng loại. Một số công cụ cho phép bạn phân biệt
các mối quan hệ theo dõi đến và theo dõi từ, tự động xác định các liên kết bổ sung.
Nghĩa là, nếu bạn chỉ ra rằng yêu cầu R được truy tìm từ thử nghiệm T, thì công cụ
này cũng sẽ hiển thị mối quan hệ đối xứng trong đó T được truy tìm từ R.
Một số công cụ tự động gắn cờ một liên kết theo dõi là đáng ngờ bất cứ khi nào đối
tượng ở một trong hai đầu của liên kết đã được sửa đổi. Liên kết đáng ngờ hiển thị
một chỉ báo trực quan (chẳng hạn như dấu chấm hỏi màu đỏ hoặc đường chéo màu
đỏ) trong ô tương ứng trong ma trận truy xuất nguồn gốc yêu cầu. Ví dụ: nếu bạn
đã thay đổi Trường hợp sử dụng 3, ma trận truy xuất nguồn gốc yêu cầu trong
Bảng 29-2 có thể trông giống như Bảng 29-4 vào lần tiếp theo bạn xem. Các chỉ
báo liên kết đáng ngờ (trong trường hợp này là dấu chấm hỏi) yêu cầu bạn kiểm tra
xem có cần thay đổi các yêu cầu chức năng 3, 4 và 6 để duy trì nhất quán với UC-3
đã sửa đổi hay không. Sau khi thực hiện bất kỳ thay đổi cần thiết nào, bạn xóa các
chỉ số liên kết đáng ngờ theo cách thủ công. Quá trình này giúp đảm bảo rằng bạn
đã tính đến các hiệu ứng gợn sóng đã biết của một thay đổi.

Các công cụ quản lý yêu cầu cũng cho phép bạn xác định các liên kết giữa các dự
án hoặc hệ thống con chéo. Tôi biết một sản phẩm phần mềm lớn có 20 hệ thống
con chính, với một số yêu cầu hệ thống cấp cao nhất định được phân bổ cho nhiều
hệ thống con. Trong một số trường hợp, một yêu cầu được phân bổ cho một hệ
thống con đã thực sự được thực hiện thông qua một dịch vụ mà một hệ thống con
khác cung cấp. Dự án này đã sử dụng một công cụ quản lý yêu cầu để theo dõi
thành công các mối quan hệ theo dõi phức tạp này.

Không thể thực hiện theo dõi yêu cầu theo cách thủ công cho bất kỳ ứng dụng nào
ngoại trừ các ứng dụng rất nhỏ. Bạn có thể sử dụng bảng tính để duy trì dữ liệu
theo dõi cho tối đa vài trăm yêu cầu, nhưng các hệ thống lớn hơn yêu cầu một giải
pháp mạnh mẽ hơn. Theo dõi yêu cầu không thể hoàn toàn tự động vì kiến thức về
các liên kết bắt nguồn từ tâm trí của các thành viên nhóm phát triển. Tuy nhiên, sau
khi bạn đã xác định được các liên kết, các công cụ có thể giúp bạn quản lý số
lượng lớn thông tin theo dõi.

Một số thủ tục theo dõi yêu cầu

Cân nhắc thực hiện theo trình tự các bước này khi bạn bắt đầu triển khai theo dõi
yêu cầu trên một dự án cụ thể:

1. Giáo dục nhóm và ban quản lý của bạn về các khái niệm và tầm quan trọng
của việc theo dõi yêu cầu, mục tiêu của bạn cho hoạt động này, nơi lưu trữ
dữ liệu theo dõi và các kỹ thuật để xác
định các liên kết. Yêu cầu tất cả những người tham gia cam kết thực hiện
trách nhiệm của mình.
 2. Chọn các mối quan hệ liên kết mà bạn muốn xác định từ các khả năng được
hiển thị trong Hình 29-2. Đừng cố gắng làm tất cả những điều này cùng một
lúc! Bạn sẽ bị choáng ngợp.
3. Chọn loại ma trận truy xuất nguồn gốc mà bạn muốn sử dụng: kiểu ma trận
đơn thể hiện trong Bảng 29-1 hoặc một số ma trận giống như ma trận được
minh họa trong Bảng 29-2. Chọn một cơ chế cho lưu trữ dữ liệu: một bảng
trong tài liệu văn bản, bảng tính hoặc (tốt hơn nhiều) một công cụ quản lý
yêu cầu.
4. Xác định các bộ phận của sản phẩm mà bạn muốn duy trì thông tin truy xuất
nguồn gốc. Bắt đầu với các chức năng cốt lõi quan trọng, các phần có rủi ro
cao hoặc các phần mà bạn mong đợi sẽ trải qua quá trình bảo trì và phát triển
nhiều nhất trong vòng đời của sản phẩm.
5. Xác định những cá nhân sẽ cung cấp từng loại thông tin liên kết và người
(rất có thể là một BA) sẽ điều phối các hoạt động truy tìm và quản lý dữ liệu
6. Sửa đổi quy trình phát triển của bạn để nhắc nhở các nhà phát triển cập nhật
các liên kết sau thực hiện một yêu cầu hoặc một thay đổi đã được phê duyệt.
Dữ liệu theo dõi sẽ được cập nhật ngay sau khi ai đó hoàn thành nhiệm vụ
tạo hoặc thay đổi liên kết trong chuỗi yêu cầu.
7. Xác định các quy ước ghi nhãn mà bạn sẽ sử dụng để cung cấp cho mỗi
phần tử hệ thống một mã định danh duy nhất để các phần tử có thể được liên
kết với nhau. Chương 10, “Lập tài liệu các yêu cầu,” đã mô tả một số cách
để dán nhãn các yêu cầu
8. Khi tiến hành phát triển, yêu cầu mỗi người tham gia cung cấp thông tin theo
dõi được yêu cầu khi họ hoàn thành các phần công việc nhỏ. Nhấn mạnh lợi
thế của việc tích lũy liên tục dữ liệu theo dõi so với việc tập hợp nó tại một
mốc quan trọng hoặc khi kết thúc dự án.
9. Kiểm tra thông tin theo dõi định kỳ để đảm bảo thông tin được cập nhật.
Nếu một yêu cầu được báo cáo là đã được triển khai và xác minh, nhưng dữ
liệu theo dõi của nó không đầy đủ hoặc không chính xác, thì quy trình theo
dõi yêu cầu của bạn không hoạt động như dự định.

Tôi đã mô tả quy trình này như thể bạn đang bắt đầu thu thập thông tin dấu vết khi
bắt đầu một dự án mới. Nếu bạn đang bảo trì một hệ thống hiện có, có thể bạn
không có sẵn dữ liệu theo dõi. Không có thời gian như hiện tại để bắt đầu tích lũy
thông tin này. Lần tới khi bạn thêm phần nâng cao hoặc thực hiện sửa đổi, hãy viết
ra những gì bạn khám phá được về mối liên hệ giữa mã, thử nghiệm, thiết kế và
yêu cầu. Bạn sẽ không bao giờ xây dựng lại một ma trận truy xuất nguồn gốc yêu
cầu hoàn chỉnh, nhưng lượng nỗ lực nhỏ này có thể giúp dễ dàng hơn vào lần tới
khi ai đó cần làm việc trên cùng phần đó của hệ thống.
Theo dõi yêu cầu có khả thi không? Có cần
thiết không?
Bạn có thể kết luận rằng việc tích lũy thông tin theo dõi yêu cầu đắt hơn giá trị của
nó hoặc nó không khả thi cho dự án của bạn. Điều đó hoàn toàn có thể xảy ra. Để
có được một công cụ với các khả năng cần thiết, thiết lập nó, nhập dữ liệu và cập
nhật nó rất tốn kém và mất thời gian. Bạn có thể không cần xây dựng bộ nhớ nhóm
như thế này nếu các thành viên trong nhóm của bạn có kiến thức cần thiết và chia
sẻ nó với những người khác khi cần. Chỉ nhóm của bạn mới có thể quyết định xem
việc theo dõi yêu cầu—có thể chỉ là yêu cầu để kiểm tra hay thứ gì đó phức tạp
hơn—làm tăng giá trị cho dự án của bạn so với chi phí.

Tuy nhiên, hãy xem xét ví dụ sau. Một người tham dự hội nghị làm việc tại một
nhà sản xuất máy bay nói với tôi rằng SRS cho bộ phận máy bay phản lực mới
nhất của công ty là một chồng giấy dày sáu feet. Họ đã có một ma trận truy xuất
nguồn gốc yêu cầu hoàn chỉnh. Tôi đã bay trên chính mẫu máy bay đó và tôi rất
vui khi biết rằng các nhà phát triển đã quản lý các yêu cầu phần mềm của họ rất
cẩn thận. Quản lý dấu vết trên một sản phẩm khổng lồ với nhiều hệ thống con liên
quan với nhau là rất nhiều công việc. Nhà sản xuất máy bay này biết điều đó là cần
thiết. Cục Hàng không Liên bang Hoa Kỳ đồng ý: truy xuất nguồn gốc từ yêu cầu
đến thiết kế là cần thiết để chứng nhận phần mềm hàng không.

Tương tự, Cục Quản lý Thực phẩm và Dược phẩm Hoa Kỳ ủng hộ việc các nhà
sản xuất thiết bị y tế chứng minh khả năng truy xuất nguồn gốc các yêu cầu của sản
phẩm đối với các sản phẩm phân phối xuôi dòng như một phần của quy trình xác
nhận thiết bị. Ngay cả khi sản phẩm của bạn không gây thiệt hại về người hoặc mất
chi nếu chúng bị hỏng, bạn vẫn nên thực hiện các yêu cầu truy tìm nghiêm túc. Ở
mức tối thiểu, hãy xem xét truy tìm giữa các yêu cầu kinh doanh và yêu cầu người
dùng để tìm kiếm sự liên kết, thiếu sót và các yêu cầu không cần thiết. Giám đốc
điều hành của một tập đoàn lớn có mặt khi tôi mô tả việc theo dõi yêu cầu tại một
cuộc hội thảo đã hỏi: “Tại sao bạn không làm điều này cho các hệ thống kinh
doanh chiến lược của mình?” Đó là một câu hỏi tuyệt vời. Bạn nên quyết định sử
dụng bất kỳ thực hành kỹ thuật yêu cầu cải tiến nào dựa trên cả chi phí áp dụng kỹ
thuật và rủi ro khi không sử dụng nó. Như với tất cả các quy trình phần mềm, hãy
đưa ra quyết định kinh tế để đầu tư thời gian quý báu của bạn vào nơi bạn mong
đợi được hoàn vốn nhiều nhất.