luận văn cử nhân tin học và quản lý yêu cầu đề án

Quản lý yêu cầu đề án
TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN
KHOA CÔNG NGHỆ THÔNG TIN
BỘ MÔN CÔNG NGHỆ PHẦN MỀM
DƯƠNG NGỌC LONG NAM
VŨ KIM OANH
QUẢN LÝ YÊU CẦU ĐỀ ÁN
LUẬN VĂN CỬ NHÂN TIN HỌC
TP. HCM, NĂM 2004
1
Quản lý yêu cầu đề án
TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN
KHOA CÔNG NGHỆ THÔNG TIN
BỘ MÔN CÔNG NGHỆ PHẦN MỀM
DƯƠNG NGỌC LONG NAM - 01HC294
VŨ KIM OANH - 01HC308
QUẢN LÝ YÊU CẦU ĐỀ ÁN
LUẬN VĂN CỬ NHÂN TIN HỌC
GIÁO VIÊN HƯỚNG DẪN
Th.S NGUYỄN THỊ BÍCH
NIÊN KHÓA 2001 - 2004
2
Quản lý yêu cầu đề án
Lời cám ơn
Chúng em xin chân thành cảm ơn Khoa Công Nghệ Thông Tin, trường Đại Học
Khoa Học Tư Nhiên, TpHCM đã tạo điều kiện cho em thực hiện đề tài tốt nghiệp này.
Chúng em xin chân thành cảm ơn Cô Nguyễn Thị Bích, đã tận tình hướng dẫn,
chỉ bảo chúng em trong suốt thời gian thực hiện đề tài. Nhờ sự định hướng chính xác
và sự chỉ bảo cặn kẽ, nhiệt tình của Cô Nguyễn Thị Bích, chúng em đã tiếp thu được
nhiều kiến thức rất quí báu.
Chúng em cũng xin chân thành cảm ơn quý Thầy Cô trong Khoa CNTT đã tận

tình giảng dạy, trang bị cho chúng em những kiến thức cần thiết trong suốt quá trình
học tập tại Khoa, và cũng xin gửi lòng biết ơn sâu sắc của chúng em đến Thầy Trần
Đức Duẩn, Thầy Trần Minh Triết, Thầy Trần Lê Hồng Dũ những người đã giúp đỡ
cung cấp tài liệu… cho chúng em rất nhiều trong lúc thực hiện đề tài này.
Chúng con luôn ghi nhớ công ơn sinh thành, dưỡng dục của Ba, Mẹ. Ba mẹ
luôn đem lại nguồn động viên to lớn giúp đỡ chúng con vượt qua những khó khăn
trong cuộc sống.
Mặc dù đã cố gắng hoàn thành luận văn với tất cả sự nổ lực của bản thân, nhưng
luận văn chắc chắn không tránh khỏi những thiếu sót, kính mong quý Thầy Cô tha thứ
và tận tình chỉ bảo.
Một lần nữa, xin chân thành cảm ơn và kính chúc Quí Thầy Cô luôn có sức khỏe thật
tốt.
Tp. Hồ Chí Minh, 09/2004
Nhóm sinh viên thực hiện
Dương Ngọc Long Nam _ Vũ Kim Oanh
3
Quản lý yêu cầu đề án
LỜI MỞ ĐẦU
Ngày nay công nghệ thông tin đã được ứng dụng vào tất cả các lĩnh vực của đời
sống xã hội. Nó đã tạo ra một diện mạo mới cho xã hội và nhờ nó mà nền văn minh của
nhân loại đã được đưa lên một tầm cao mới. Nói đến công nghệ thông tin là nói đến
công nghệ phần mềm, một phần không thể tách rời của công nghệ thông tin. Hiện nay
ngành công nghệ phần mềm trên thế giới đang phát triển như vũ bão. Những tiến bộ
vượt bậc của khoa học kỹ thuật phần cứng đã tạo điều kiện thuận lợi cho ngành công
nghệ phần mềm ngày càng phát triển không ngừng.
Trong các công ty phần mềm, không chỉ ở Việt Nam mà trên toàn thế giới luôn luôn
phải đối diện với nguy cơ chi phí trang trải cao hơn mức dự kiến và bị trễ hạn đề án
trong đó 76% nguyên nhân là do yêu cầu thay đổi. Đây là nguyên nhân chính dẫn tới sự
thất bại của nhiều công ty phần mềm. Nó là nỗi ám ảnh thường trực đối với những
người phát triển đề án và đặc biệt là các nhà quản lý. Vì vậy người quản lý đề án cần

phải tổ chức kế hoạch, theo dõi tất cả các yêu cầu và các mối quan hệ giữa chúng, và
phải biết ngay những gì cần phải làm để đáp ứng khắc phục khi có yêu cầu thay đổi sao
cho hiệu quả nhất để đề án được hoàn thành theo đúng thời gian qui định, giảm thiểu
rủi ro và chi phí thực hiện. Xuất phát từ nhu cầu này, chúng em đã chọn đề tài “Quản
lý yêu cầu đề án “ làm luận văn tốt nghiệp.
4
Quản lý yêu cầu đề án
Mục lục
Danh mục các ký hiệu, các chữ viết tắt: 6
Danh mục các bảng: 6
Danh mục các hình vẽ : 7
1 Chương 1 : Tổng quan về quản lý yêu cầu 8
1.1 Các khái niệm : 8
1.2 Xác định phạm vi dự án : 12
1.3 Tại sao phải quản lý yêu cầu : 14
1.4 Các khái niệm quan trọng trong quản lý yêu cầu: 18
1.5 Xác định và viết các yêu cầu tốt : 22
1.6 Ai sẽ thu được lợi từ quản lý yêu cầu : 31
1.7 Vài điều cần thực hiện khi quản lý yêu cầu: 31
1.8 Quản lý các yêu cầu hình thức như thế nào? 32
1.9 Các giải pháp cho vấn đề quản lý yêu cầu mà ảnh hưởng đến sự phát triển: 33
1.10 Cách giúp tăng cường khả năng quản lý yêu cầu trong tổ chức: 40
1.11 Tự động tiến trình quản lý các yêu cầu : 44
1.12 Các kỹ năng cần có trong quản lý yêu cầu : 45
1.13 Đưa quản lý yêu cầu vào công việc 53
2 Chương 2 : Những công cụ quản lý yêu cầu hiện nay : 54
2.1 Giới thiệu : 54
2.2 Định nghĩa các công cụ quản lý yêu cầu : 55
2.3 Các loại công cụ : 56
2.4 Tại sao phải sử dụng các loại công cụ quản lý yêu cầu : 56

2.5 Kiến trúc chức năng : 57
2.6 So sánh với các phần mềm có chức năng tương tự : 59
2.7 Đánh giá các công cụ quản lý yêu cầu : 60
3 Chương 3 : Xây dựng “ Phần mềm quản lý yêu cầu đề án “ 61
3.1 Mục tiêu của ứng dụng : 61
3.2 Đặc tả yêu cầu của ứng dụng: 61
3.3 Các khái niệm được dùng trong phần mềm : 62
3.4 Nguyên tắc công việc : 65
3.5 Các kỹ thuật được tìm hiểu và ứng dụng trong phần mềm: 71
3.6 Các giải thuật được cài đặt trong phần mềm: 80
3.7 Cấu trúc lưu trữ của chương trình: 82
3.8 Hệ thống giúp đỡ trực tiếp 83
3.9 Thiết kế và cài đặt ứng dụng : 85
Use case : Đăng nhập 86
Use case: Đổi mật khẩu 86
Use case: Tài liệu 87
Use case: Yêu cầu 89
Use case: View 91
Use case: Tạo mối quan hệ 92
Use case: Gói công việc 94
Use case: Thảo luận 95
Use case: Báo biểu 97
Use case: Tạo đề án 98
5
Quản lý yêu cầu đề án
Use case: Đặt bảo mật 99
Use case: Nhóm 100
Use case: Người dùng (User) 101
Use case: Loại yêu cầu 103
Use case: Loại tài liệu 104

Danh sách các bảng : 74
3.10 Công cụ và môi trường phát triển hệ thống : 157
3.11 Triển khai vận hành thử nghiệm : 157
3.12 Đánh giá : 157
4 Chương 4 : Kết luận 160
4.1 Kết quả đạt được : 160
4.2 Hướng phát triển của đề tài : 160
5 Tài liệu tham khảo : 161
Tiếng Anh : 161
Tiếng Việt : 161
6 Phụ lục : 162
Danh mục các ký hiệu, các chữ viết tắt:
DS Danh sách
CSDL Cơ sở dữ liệu
QFD ( Quanlity function deployment) là kỹ thuật quản lý chất
lượng
CCB (Change Control Board) Ban kiểm soát sự thay đổi
JAD
Joint Application Development
Danh mục các bảng:
Bảng 2-1 : Danh sách bảng dữ liệu 76
Bảng 2-2 : Bảng Discussion 77
Bảng 2-3 : Bảng DiscussionGroups 77
Bảng 2-4 : Bảng DiscussionRequirements 78
Bảng 2-5 : Bảng DiscussionRead 78
Bảng 2-6 : Bảng DiscussionUsers 78
Bảng 2-7 : Bảng Documents 79
Bảng 2-8: Bảng DocumentHistory 79
Bảng 2-9 : Bảng DocumentTypes 80
Bảng 2-10 : Bảng DocumentTypeUsers 80

Bảng 2-11 : Bảng ExternalProjects 81
Bảng 2-12 : Bảng Keys 81
Bảng 2-13 : Bảng OverflowHistory 81
Bảng 2-14 : Bảng OverflowText 82
Bảng 2-15 : Bảng OverflowValues 82
Bảng 2-16 : Bảng PackageElements 82
Bảng 2-17 : Bảng Packages 82
Bảng 2-18 : Bảng ProjectDiscussions 83
6
Quản lý yêu cầu đề án
Bảng 2-19 : Bảng ProjectDocuments 83
Bảng 2-20 : Bảng ProjectDocumentTypes 83
Bảng 2-21 : Bảng ProjectExternalProjects 83
Bảng 2-22 : Bảng ProjectHistory 84
Bảng 2-23 : Bảng ProjectRequirements 84
Bảng 2-24 : Bảng ProjectRequirementTypes 84
Bảng 2-25 : Bảng Projects 85
Bảng 2-26 : Bảng ProjectGroups 85
Bảng 2-27 : Bảng QueryDefinitions 86
Bảng 2-28 : Bảng RequirementHistory 86
Bảng 2-29 : Bảng Requirements 87
Bảng 2-30 : Bảng RequirementTypeFields 88
Bảng 2-31 : Bảng RequirementTypeFields 88
Bảng 2-32 : Bảng RequirementTypeStyles 89
Bảng 2-33 : Bảng RequirementTypeUsers 89
Bảng 2-34 : Bảng Relationships 90
Bảng 2-35 : Bảng UserDefinedFields 91
Bảng 2-36 : Bảng UserDefinedFieldUsers 91
Bảng 2-37 : Bảng UserDefinedFieldValues 91
Bảng 2-38 : Bảng UserDefinedListItems 92

Bảng 2-39 : Bảng UserDefinedListItemUsers 92
Bảng 2-40 : Bảng UserDefinedListValues 92
Bảng 2-41 : Bảng Groups 93
Bảng 2-42 : Bảng Users 93
Bảng 2-43 : Bảng Views 94
Danh mục các hình vẽ :
Hình 2.1 : Truy vết các yêu cầu 20
Hình 2.2 :Khái quát về cấu trúc quản lý yêu cầu 53
Hình 2.3 : Sơ đồ Use-case 85
Hình 2.4 : Sơ đồ toàn bộ của đề án 74
Hình 3.5 : Mô hình Client/Server 94
Hình 3.6 : Kiến trúc 3 lớp 95
7
Quản lý yêu cầu đề án
1 Chương 1 : Tổng quan về quản lý yêu cầu
1.1 Các khái niệm :
1.1.1 Yêu cầu là gì ?
Yêu cầu là một điều kiện hoặc khả năng mà hệ thống phải tuân theo (Rational).
1.1.2 Yêu cầu phần mềm là gì ?
Một yêu cầu phần mềm là (theo Merlin Dorfman và Richard H. Thayer):
• Một khả năng phần mềm được yêu cầu bởi người dùng để giải quyết một vấn đề
hoặc để đạt một mục tiêu nào đó.
Hay
• Một khả năng phần mềm phải được đáp ứng hay cần phải có trong một hệ thống
(hay một thành phần của hệ thống) để thỏa mãn một hợp đồng, một bản chi tiết
kĩ thuật, một tiêu chuẩn hay một tài liệu bắt buộc chính thức khác.
1.1.3 Phân loại yêu cầu:
QFD ( Quanlity function deployment) là kỹ thuật quản lý chất lượng có thể
chuyển các nhu cầu người dùng thành các yêu cầu kỹ thuật do phần mềm. QFD
được phát triển ở Nhật và đầu tiên được dùng ở Kobe Shipyard của khu công

nghiệp nặng Mitsubisi vào đầu những năm 70. QFD tập trung vào sự tối đa hoá sự
hài lòng của khách hàng. Để hoàn thiện điều này, QFD nhấn mạnh sự hiểu biết về
các giá trị cho người dùng và kế đó triển khai các giá trị này thông qua tiến trình kỹ
thuật.
QFD xác định 3 loại yêu cầu:
1. Yêu cầu bình thường : Các mục tiêu được đưa ra cho sản phẩm hay hệ
thống trong suốt buổi gặp mặt với khách hàng. Nếu các yêu cầu này được đưa ra thì
khách hàng sẽ hài lòng.
8
Quản lý yêu cầu đề án
Ví dụ: Các yêu cầu về chức năng hiển thị đồ hoạ, chức năng hệ thống đặc biệt và
mức độ công suất phần mềm thực thi được xác định.
2. Yêu cầu mong muốn : Các yêu cầu loại này là tuyệt đối nên có đối với sản
phẩm hay hệ thống và nó quá cơ bản đến nổi khách hàng không nói ra. Thiếu các
yêu cầu này là nguyên nhân dẫn đến sự không hài lòng nghiêm trọng của khách
hàng.
Ví dụ: Sự dễ dàng tương tác giữa người và máy, hoạt động chính xác và
đáng tin cậy, sự dễ dàng trong việc lắp đặt phần mềm.
3. Các yêu cầu thú vị : Các chức năng vượt quá sự mong muốn của khách
hàng và được chứng minh là khi các yêu cầu loại này xuất hiện sẽ rất làm hài lòng
cho khách hàng.
Ví dụ: Phần mềm đánh văn bản được yêu cầu với nét đặc trưng chuẩn. Các
sản phẩm được phân phối chứa các khả năng phân trang làm hài lòng mà khách
hàng đã không nghĩ đến.
1.1.4 Quản lý yêu cầu là gì ?
Quản lý yêu cầu là tiến trình đang diễn ra trong việc xác định các nhu cầu
của người dùng cuối, cân bằng chúng với thời gian và ngân sách của dự án, dẫn đến
hệ thống thoả mãn các nhu cầu của người dùng cuối.
• Quản lý yêu cầu đang diễn ra là gì?
Quản lý yêu cầu thì sẽ không ngừng cho đến khi bắt đầu cài đặt hay thậm chí

đến khi giao sản phẩm. Các yêu cầu thay đổi theo thời gian và sẽ thay đổi sâu sắc
trong bất kỳ chu trình sống nào của dự án. Quản lý yêu cầu tiếp tục thông qua đời
sống của sản phẩm phần mềm, và thường qua nhiều thế hệ sản phẩm thành công.
Ví dụ : chương trình dựa trên DOS xây dựng được 7 năm sẽ được yêu cầu
chuyển sang dựa trên Window?
9
Quản lý yêu cầu đề án
Duy trì được các yêu cầu ban đầu thông qua chu kỳ sống sẽ cực kỳ hữu
dụng. Thật quan trọng để nhớ rằng “quản lý yêu cầu là không từ chối thay đổi mà
nó quản lý các thay đổi.”
• Quản lý yêu cầu là sự xác nhận các nhu cầu của người
dùng cuối là gì:
Người dùng có một chút khó khăn trong việc thu thập và xác định các nhu
cầu khi đối mặt với một kỹ thuật mới, thậm chí thường người dùng sẽ không biết họ
cần cái gì. Điều này có thể tạo ra một tình huống mà ở đó yêu cầu mơ hồ và không
thể giải quyết. Nếu điều này xảy ra, nó là nguyên nhân làm cho dự án thất bại. Các
yêu cầu không thể bỏ đi sự mơ hồ. Nó sẽ được hiểu và được kích hoạt trong trường
hợp hiểu rõ hoặc nó nên được trì hoãn đến dự án sau đó, khi đã hiểu hơn.
Chú ý rằng các yêu cầu này có thể rơi vào nhiều loại, ví dụ: một yêu cầu về
thị trường có thể là “Nó được xác nhận với logo Windows XP” hay một yêu cầu về
hiệu năng như “tìm kiếm một mảng thông tin nào đó phải ít hơn 1 giây”,…
Chắn chắn một điều là trong khi làm việc với các dự án, các yêu cầu sẽ có
nhiều thay đổi, và các giải pháp mới sẽ được đề xuất. Việc giải quyết các vấn đề
này là một khía cạnh khác của quản lý các yêu cầu mà nó có tên là “Quản lý các yêu
cầu” hay “Điều khiển tiến trình thay đổi”. Nó tăng số lượng các yêu cầu đang tồn
tại phải được xếp độ ưu tiên lại, đưa ra các ước tính sẽ ảnh hưởng đến sự thành
công của dự án, và rất có thể thay đổi luôn cả thời gian biểu của dự án.
Các thay đổi do sự hiểu lầm của người dùng, các thay đổi do yêu cầu nghiệp
vụ hay thậm chí đơn giản là do một phần nào đó bị quên cho đến khi dự án đã hoàn
tất làm cho phần mềm không được thoả đáng.

Khi có yêu cầu mới ngoài khả năng nên hủy bỏ nó vì khi chấp nhận sẽ dẫn
đến dự án thất bại.
* Quản lý các yêu cầu là sự cân bằng đối với thời gian và ngân sách của dự
án:
10
Quản lý yêu cầu đề án
Mỗi dự án có một thời gian và ngân sách riêng. Nếu không có các yếu tố này
thì nó sẽ không còn là một dự án mà chỉ là một bài học bảo trì kéo dài. Mâu thuẫn
lớn nhất là các yêu cầu nào được sẽ hoàn tất khi phân chia thời gian biểu đối với
ngân sách và thời gian của dự án. Cung cấp một ước lượng hợp lý về thời gian và
ngân sách được yêu cầu là nên dựa trên sự hiểu biết chắn chắn các yêu cầu của dự
án, nếu không thì nó đơn giản chỉ là sự đoán mò.
Nêu ra các giới hạn của thời gian biểu cho dự án và ngân sách sẵn có liên
quan đến các yêu cầu làm cho việc phân phối các ước tính tốt hơn cho các
stakeholder, và là một nền tảng vững chắc cho các ước tính ảnh hưởng đến các thay
đổi được yêu cầu.
* Dự án đang tồn tại thoả mãn người dùng cuối:
Một đặc tả yêu cầu sẽ không nên xem như là một tập các mô tả xác thực
không thể thay đổi. Như được đề cập ở trên, các thay đổi là trường hợp không thể
tránh khỏi trong việc thực thi dự án. Cuối cùng, nguời dùng cuối sẽ là người quyết
định dự án thành công hay không và dự án sẽ được chi trả hay không.
Việc cho phép người dùng tham gia trong suốt tiến trình thực thi dự án là cực
kỳ có giá trị và có thể bảo đảm rằng dự án có thể hoàn tất thành công. Một phần của
việc này là có thể thiết lập các yêu cầu một cách hoàn thiện và chắc chắn rằng họ
hiểu và một phần là có thể quản lý các mong muốn của người dùng.
Không nên cố gắng đáp ứng các mong muốn không thực tế của người dùng
cuối, nếu không chắc chắn dự án sẽ thất bại.
Ví dụ: nếu họ muốn dự án hoàn tất trong 2 tháng trong khi đội phần mềm
cần 6 tháng thì không nên chấp nhận mong muốn này.
Xếp độ ưu tiên cho các yêu cầu người dùng cuối thì cực kỳ quan trọng ở đây,

khi nó xác định phần nào sẽ được cắt bỏ và để lại trong phiên bản tương lai hay bỏ
đi tất cả.
Quản lý các mong muốn người dùng một cách rõ ràng trong quá trình thực
hiện dự án, đội sẽ bảo đảm rằng việc giao sản phẩm cuối cùng sẽ là cái mà người
dùng cần và họ được thoả mãn nó khi mà được giao.
11
Quản lý yêu cầu đề án
1.2 Xác định phạm vi dự án :
Mục này sẽ mô tả thông tin phải được xác định và chuyển hoá thành tài liệu
để giới hạn phạm vi của một dự án.
Tại sao giới hạn của một dự án là yếu tố cần thiết?
Tất cả những cá nhân tham gia viết, xem lại yêu cầu hay tạo các bảng thiết
kế sẽ tạo ra những cách xác định giới hạn dự án khác nhau nếu bạn không cung cấp
cho họ một cách làm xác định.
Những cách xác định mà họ tạo ra có thể không đồng nhất với nhau về kiểu
mẫu, phương thức trong việc quản lý dự án và chắc chắn sẽ khác nhau giữa từng
người một.
Kết quả là các yêu cầu họ viết sẽ khác nhau rất nhiều về mục đích, mục tiêu,
sự ràng buộc, các giả định, các khái niệm hoạt động và hệ thống.
1.2.1 Phạm vi dự án:
Phạm vi dự án được định nghĩa gồm những yếu tố sau:
• Yêu cầu của hệ thống
• Mục đích, mục tiêu những ràng buộc
• Nhiệm vụ, khái niệm hoạt động.
• Các giả định
• Giao diện ngoài của hệ thống
• Những phần chính của hệ thống
• Ngân qũy
• Lịch trình
• Quyền hạn và trách nhiệm quản lý.

1. Yêu cầu : là yếu tố đầu tiên cần được xác định, nó thường là những báo cáo,
trình bày rất ngắn gọn.
Ví dụ như: “Xây dựng phần mềm quản lý yêu cầu trên win và web mà có thể
quản lý được sự thay đổi của các yêu cầu, tài liệu,các thành viên tham gia…của dự
án trong vòng 1 năm” là một yêu cầu được trình bày ngắn gọn. Tất cả những phần
12
Quản lý yêu cầu đề án
khác sẽ đưa ra thời gian thực hiện và sẽ có các ý kiến được trình bày, thử nghiệm,
hiệu chỉnh hay loại ra… Cuối cùng điều cần thiết là xác định được thời gian của quá
trình sẽ là 1 năm.
Những yếu tố kế tiếp như : mục đích, mục tiêu, những ràng buộc, nhiệm vụ,
khái niệm hoạt động, các giả định sẽ được trình bày theo thứ tự nhưng thực tế
chúng được phát triển lặp lại nhiều lần trong suốt tiến trình.
Những mục đích, mục tiêu và những ràng buộc có thể liên quan đến việc xác
định hệ thống (những gì hệ thống sẽ làm) hay quản lý dự án (sẽ được làm như thế
nào).
2. Mục đích : có thể có một hay nhiều mục đích. Mục đích nói lên những gì bạn
muốn làm.
3. Mục tiêu : thường là những hướng mở rộng của mục đích.
4. Ràng buộc : là những hạn chế, giới hạn bắt buộc phải có trong việc phát triển
hệ thống hay quản lý dự án của bạn.
5. Nhiệm vụ : mô tả hệ thống sẽ được dùng như thế nào.
6. Các khái niệm : sẽ được xác định để cung cấp một cơ sở cho nghiên cứu và
thương mại. Có thể có nhiều khái niệm khi cân nhắc, nghiên cứu một dự án
từ rất sớm.
7. Các giả định : Trong toàn bộ tiến trình, một lượng lớn các giả định sẽ được
tạo ra. Những giả định này phải được chuyển thành tài liệu để nghiên cứu.
8. Giao diện ngoài của hệ thống : cần được xem xét, cân nhắc. Chúng thường
dẫn đến một ràng buộc. Để xác định thông tin này, cần phải quản lý, điều
khiển một lượng lớn các nghiên cứu thương mại và phân tích các tùy chọn có

thể, các ràng buộc và những rủi ro trong phát triển. Việc này đòi hỏi sức
người và thời gian để hoàn tất. Kích thước của dự án, số lượng các giao diện
và những rủi ro, sẽ giúp cho biết cái gì được yêu cầu.
9. Những phần chính của hệ thống : khi các khái niệm đã được chọn lọc,
nghiên cứu nên các thành phần của hệ thống sẽ được suy ra từ từ.
13
Quản lý yêu cầu đề án
10.Ngân qũy, lịch trình và công tác quản lý : phải được xác định. Ngân qũy và
lịch trình phải được ràng buộc với nhau và xác định bởi những tài nguyên
bên ngoài… Điều khiển, quản lý phải được xác định để tất cả những người
tham gia có thể nắm bắt được toàn bộ mệnh lệnh.
Bước đầu để xây dựng thông tin này là bắt đầu với biện pháp phân tích sơ bộ
nếu đã có những hoạt động trong giai đoạn trước khi phân tích.
Giai đoạn phân tích sơ bộ sẽ tạo ra một kế hoạch, chương trình dưới dạng tài
liệu chứa đựng các thông tin để bắt đầu bước xác định và thiết kế công việc.
*Lí do mà những thay đổi cần thực hiện bao gồm:
1. Không có khả năng đạt được các mục đích hay mục tiêu.
2. Mục tiêu mới từ những nguồn tài liệu bên ngoài.
3. Thiếu hụt ngân qũy để hoàn thành các mục đích.
4. Công nghệ mới mở ra những khả năng, triển vọng mới.
5. Việc mong đợi các công nghệ mới có thể không có trong lịch trình.
Tất cả những thay đổi phải được chuyển thành tài liệu và làm cho phù hợp
với nhân viên thực hiện dự án. Mỗi người cần phải làm việc theo cùng một đường
lối trong suốt quá trình phát triển của hệ thống. Để đảm bảo điều này, bạn phải tài
liệu hoá và phân phối các thông tin.
1.2.2 Cung cấp tư liệu cho phạm vi dự án:
Mục đích là để đảm bảo rằng những người tham gia dự án phải làm cùng một
công việc như nhau. Không chỉ đưa ra tài liệu mà còn phải làm cho nó hợp lý. Việc
này luôn được giám sát mà nhiều người đang làm việc trong dự án lại không bao
giờ thấy, thậm chí không biết. Do vậy có ít người biết cách sử dụng đúng đắn. Ngay

khi bạn quản lý một dự án nhỏ, bạn cũng nên cung cấp các tài liệu về phạm vi dự án
đó để đảm bảo thành công.
1.3 Tại sao phải quản lý yêu cầu :
Mức độ tổn thất do các giai đoạn đem lại: càng về sau thì mức độ tổn thất
càng cao, nếu ta có thể quản lý tốt các yêu cầu ngay từ đầu thì sự tổn thất rất ít xảy
14
Quản lý yêu cầu đề án
ra có thể là không, nhưng để đến giai đoạn bảo trì thì tổn thất sẽ cực kỳ lớn có thể
dẫn đến dự án thất bại và phí tổn về con người, thời gian, ngân sách có thể sẽ rất
lớn.
1.3.1 Các thất bại trong phát triển phần mềm :
Chất lượng phát triển phần mềm trong công nghiệp ngày nay thì thấp đến
mức phải chú ý. Việc nghiên cứu được tham khảo nhiều từ nhóm Standish đã tiến
hành sự khảo sát các dự án phát triển phần mềm năm 1995. Và kết quả mà họ tìm
thấy như sau:
• 31% trong tổng số tất cả các dự án phát triển phần mềm bị huỷ do chưa hoàn tất.
• 53% trong tổng số tất cả các dự án phát triển phần mềm vượt quá ngân sách là
50%.
• 16% hoàn tất đúng thời hạn và đúng ngân sách.
Cũng xem xét các kết quả sau được giới thiệu bởi Barry Boehm của USC:
• Có đến 40% hay 50% trong tất cả các dự án đều phải thiết kế lại.
• Cần ghi nhớ ở đây rằng hầu như một nửa ngân sách dự án được dùng cho việc
thiết kế lại. Đó là, công việc được làm một lần, nhưng không chính xác, và phải
làm lại.
• Chúng ta hãy kiểm tra xem các lỗi này đến từ đâu.
• Các nghiên cứu này, hoạt động độc lập bởi TRW, IBM, GTE, nghiên cứu mối
quan hệ của các lỗi đối với giá trị của chúng để sửa chữa. Mỗi nghiên cứu đã
đưa ra các kết luận tương tự, không bao gồm lẫn nhau. Các nghiên cứu này cho
thấy giá trị của chúng đối với việc tìm kiếm và sửa chữa các lỗi trong khi viết
mã.

• Các giá trị được tìm thấy dẫn đến kết quả chi phí phải trả sau ( đơn vị là đô la)
o Các yêu cầu : 1 – 2
o Thiết kế : 5
o Cài đặt : 1
15
Quản lý yêu cầu đề án
o Kiểm nghiệm đơn vị : 5
o Bảo trì : 20
Các giá trị này cho thấy cái giá phồng lên của việc sửa chữa phần mềm trễ trong
khi phát triển chúng. Cùng một lỗi nếu phát hiện trong lúc cài đặt thì mất 10 đô la
để sửa lỗi nhưng lại mất đến 20 đô la nếu phát hiện trong lúc bảo trì. Ngược lại, xác
định và sửa các lỗi này trong lúc xác định yêu cầu sẽ mất 1 đến 2 đô la.
Theo như Tom DeMacro ( tác giả của Peopleware) ước tính ban đầu 56% tổng
lỗi trong các dự án phần mềm xảy ra ở giai đoạn yêu cầu. Việc nghiên cứu dự án
USAF bởi Frederick Sheldon đưa ra các thống kê lỗi sau và nơi chúng xảy ra:
STT Loại lỗi Thường xuyên
1 Các yêu cầu 41%
2 Logic chương trình 28%
3 Giao diện 6%
4 Dữ liệu 6%
5 Môi trường 5%
6 Con người 5%
7 Tài liệu 2%
8 Khác 7%
41% lỗi xảy ra trong giai đoạn yêu cầu của các dự án. Nếu chúng ta không ngăn
chặn chúng từ đầu thì các lỗi này có thể dẫn đến chi phí mất 10000% đến 20000%,
một khối lượng công việc thiết kế lại cho các lỗi trong giai đoạn yêu cầu ban đầu là
80%.
1.3.2 Con đường dẫn đến thành công bắt đầu với các yêu cầu và phân tích :
Xác định được giải pháp đúng trong nhiều giải pháp các yêu cầu và phân tích sẽ

giúp bạn hiểu được không gian vấn đề, nắm bắt và quản lý sự tiến hoá các yêu cầu,
lên mô hình các tương tác người dùng, định nghĩa kiến trúc cơ sở dữ liệu, và phối
hợp các phản hồi stakeholder xuyên suốt chu kỳ sống của dự án. Nếu là một quản lý
dự án, nhà phân tích, nhà phát triển hay nhà kiểm nghiệm, các yêu cầu và phân tích
sẽ gắn chặt với công việc. Phân tích các yêu cầu tốt giúp bỏ đi các rủi ro của dự án,
16
Quản lý yêu cầu đề án
thực hiện trôi chảy cho đến khi sản phẩm cuối cùng được giao một cách thành công
cho khách hàng.
1.3.3 Tại sao các nhà phát triển lại quan tâm quản lý các yêu cầu :
Quản lý các yêu cầu quan trọng như thế nào đối với các nhà phát triển được
phản ánh trong mục đích của quản lý các yêu cầu: cần thiết lập sự thông hiểu nhau
giữa khách hàng với đội ngũ phát triển phần mềm. Sự thông hiểu đó là nền tảng cho
việc lên kế hoạch và quản lý dự án. Nếu không có sự quản lý các yêu cầu hiệu quả,
đội sẽ bị hạn chế khả năng trong việc thiết lập một kế hoạch dự án chính xác, điều
khiển phạm vi dự án, giao sản phẩm, hay ngừng phát triển và kiểm tra các phí phạm
trong các việc thực hiện sai mục đích.
Các nhà phát triển đóng vai trò rất quan trọng trong việc đảm bảo rằng đội
đang làm việc với các yêu cầu đã được diễn đạt một cách rõ ràng. Các nhà phát
triển nên tập trung vào các đặc tả yêu cầu và tiếp tục làm rõ ràng và lọc các yêu cầu
khi các yêu cầu này tiến hoá, thông qua chu kỳ sống của sự phát triển được lặp đi
lặp lại.
Các nhà phát triển chịu trách nhiệm chuyển các khái niệm thành hiện thực, vì
vậy họ giữ vai trò chủ động trong xử lý các yêu cầu càng sớm thì khả năng các yêu
cầu có thể được chuyển một cách chính xác sang hệ thống có khả năng làm việc
càng lớn bấy nhiêu – trong lượng thời gian ngắn nhất. Các nghiên cứu cũng như các
báo cáo của nhóm Standish Group cho thấy các yêu cầu mà tốn nhiều chi phí thì
phải chi trả càng nhiều cho việc sửa lỗi.
Bắt đầu với những yêu cầu mà dẫn bạn theo một hướng sai hay thay đổi
hướng đi giữa chu kỳ sống của sự phát triển có thể làm cho việc thiết kế của bạn vô

giá trị và dẫn đến kết quả là phải làm lại các công việc về thiết kế sẽ gây tốn chi phí
và thời gian cho các cuộc kiểm nghiệm giá trị, tài liệu người dùng không chính
xác, Bạn sẽ tốn thêm nhiều thời gian để sửa chữa các vấn đề mà bạn có thể dễ
dàng tránh được ở giai đoạn đầu tiên.
17
Quản lý yêu cầu đề án
Quản lý các yêu cầu tốt cũng có thể làm đơn giản cuộc sống của một nhà
phát triển.
Cuối cùng quản lý các yêu cầu tốt hơn dẫn đến các phần mềm chất lượng tốt
hơn và làm cho các nhà phát triển có khả năng tập trung các mở rộng về phía trước.
1.4 Các khái niệm quan trọng trong quản lý yêu cầu:
1.4.1 Stakeholders:
Các yêu cầu có từ rất nhiều nguồn. Chúng có thể xuất phát từ bất kỳ ai quan
tâm đến đầu ra của đề án. Khách hàng, đối tác, người dùng cuối, chuyên gia lĩnh
vực là một vài nguồn. Các nhà quản lý, các thành viên của đội dự án, chính sách
nghiệp vụ, và các bộ phận điều chỉnh có thể là những nguồn khác.
Thật quan trọng để biết cách xác định nguồn sẽ là ai, truy cập vào những
nguồn này như thế nào, và làm như thế nào để lấy thông tin từ họ. Những cá nhân
phục vụ như những nguồn chính cho thông tin này, được xem như những
“stakeholder” trong đề án.
Bao gồm:
• Khách hàng
• Nhà phân tích yêu cầu
• Các kiến trúc sư phần mềm hay các nhà thiết kế phần mềm.
• Các nhà kiểm nghiệm hay các nhà phát triển phần mềm.
• SQA (Software Quality Assurance: bảo đảm chất lượng phần mềm);
• SCM (Software Configure Management: quản lý cấu hình phần
mềm).
1.4.2 Loại yêu cầu ( Requirement Type):
Là một lớp các yêu cầu. Hệ thống càng lớn và phức tạp thì càng có nhiều các

yêu cầu xuất hiện. Nhờ xác định các kiểu yêu cầu, các đội có thể tổ chức nhiều yêu
cầu thành những nhóm có ý nghĩa và dễ quản lý hơn. Thiết lập các kiểu yêu cầu
18
Quản lý yêu cầu đề án
khác nhau trong một dự án giúp các thành viên trong đội phân loại các yêu cầu để
dễ thay đổi và truyền đạt rõ ràng hơn.
Thường thường, một kiểu yêu cầu có thể bị phân nhỏ, hay bị phân tích thành
các kiểu khác nhau. Các nguyên tắc công việc và các phát biểu mang tính tầm nhìn
chiến lược (Vision) có thể là những kiểu yêu cầu ở cấp độ cao, mà từ đó các đội có
thể nhận được nhu cầu của người dùng, đặc điểm về các kiểu yêu cầu của sản phẩm.
Use case và các dạng mô hình hoá khiến cho các yêu cầu thiết kế có thể bị
phân tích thành các yêu cầu phần mềm, được thể hiện trong các mô hình thiết kế và
phân tích. Các yêu cầu kiểm tra được lấy từ các yêu cầu phần mềm và phân tích
thành các thủ tục kiểm tra đặc trưng.
Khi có hàng trăm, hàng ngàn hoặc hàng chục ngàn các thể hiện yêu cầu khác
nhau trong một dự án, việc phân loại các yêu cầu thành các kiểu khác nhau làm cho
dự án dễ dàng quản lý hơn.
1.4.3 Các nhóm làm việc xuyên chức năng (Cross-Funtional Teams):
Không như các qui trình khác, chẳng hạn qui trình kiểm tra và mô hình hoá
ứng dụng, có thể được quản lý trong phạm vi của một nhóm công tác đơn lẻ. Việc
quản lý các yêu cầu nên tận dụng những người mà có thể đóng góp những chuyên
môn của họ vào qui trình phát triển. Nó cũng nên bao gồm các cá nhân đại diện cho
khách hàng và các bên mong đợi khác. Các nhà quản lý phát triển, các nhà quản trị
sản phẩm, các nhà phân tích, các kĩ sư hệ thống, và ngay cả những khách hàng cũng
nên tham gia vào nhóm. Các nhóm nên bao gồm luôn những người đề xướng giải
pháp hệ thống-các kĩ sư, các kiến trúc sư, các thiết kế viên, các lập trình viên,
chuyên viên bảo hành sản phẩm, các tác giả kĩ thuật, và những nhà phân phối kĩ
thuật khác.
Thường thường, trách nhiệm tạo lập và bảo quản một kiểu yêu cầu có thể
được phân công dựa vào phạm vi chức năng, phân phối trong quản lý dự án. Bản

chất cross-functional của việc quản lý các yêu cầu là một trong nhiều khía cạnh thử
thách của sự làm việc theo kỷ luật.
19
Quản lý u cầu đề án
Nhà phân
tích
Các yêu cầu
Nhà phát triển
& nhà thiết kế
Quản lý
phối hợp
Bảo đảm chất lượng
& kiểm nghiệm
Quản lý phát triển
và quản lý dự án
Người viết kỹ
thuật & tài liệu
1.4.4 Khả truy (Traceability)
Thiết lập các đường truy vết:
Hình 2.1 : Truy vết các u cầu
Giữa các u cầu có sự liên quan lẫn nhau và liên quan đến đặc trưng của sản
phẩm. Kiểm tra, thể hiện và lưu trữ các quan hệ này giúp nhóm xác định được tác
động của các thay đổi và tự tin rằng hệ thống đáp ứng được các mong đợi.
Theo ngụ ý của việc mơ tả các loại u cầu, khơng có một u cầu nào đứng
đơn lẻ cả. Các u cầu của stakeholder thì liên quan đến các đặc trưng sản phẩm
được đề nghị để đáp ứng cho họ. Các đặc trưng sản phẩm thì liên quan đến các u
cầu cá nhân, mà những u cầu cá nhân này xác định các đặc trưng dưới dạng hành
vi chức năng hay phi chức năng. Các trường hợp kiểm tra được liên kết với những
u cầu cần xác thực và cơng nhận. Các u cầu có thể phụ thuộc hay tương hổ với
các u cầu khác.

20
Quản lý yêu cầu đề án
Để các nhóm xác định được tác động của các thay đổi và cảm thấy tự tin
rằng hệ thống đáp ứng các mong đợi, thì phải hiểu, thể hiện bằng văn bản và lưu trữ
những quan hệ khả truy này. Khả truy là một trong những khái niệm khó nhất khi
thực hiện việc quản lý các yêu cầu, nhưng nó lại rất thiết thực trong việc dàn xếp
các thay đổi. Thiết lập các kiểu yêu cầu rõ ràng và hợp tác với các nhóm xuyên
chức năng có thể giúp dễ triển khai và duy trì tính năng khả truy.
1.4.5 Thuộc tính đa chiều (Multidimentional Attributes):
Mỗi loại yêu cầu có các thuộc tính và mỗi yêu cầu riêng lẻ có các giá trị
thuộc tính khác nhau. Ví dụ: các yêu cầu có thể được chỉ định độ ưu tiên xác định
bởi nguồn và các nguyên nhân cơ bản, đại diện cho các nhóm nhỏ (sub-team) trong
các khu vực chức năng cho một sự định rõ mức độ khó, hay với một vòng lặp cụ thể
của hệ thống.
1.4.6 Lịch sử thay đổi :
Các yêu cầu luôn tiến hóa. Việc lưu giữ lại các phiên bản của các yêu cầu giúp
lãnh đạo đội nắm được lý do thay đổi của dự án, yêu cầu nào thay đổi, tại sao, khi nào
và ai cho phép.
Cả yêu cầu riêng và tập hợp các yêu cầu đều có lịch sử của chúng sẽ trở nên có
nghĩa qua thời gian. Thay đổi là điều tất yết và chính đáng để theo kịp với việc thay đổi
môi trường và sự bùng nổ công nghệ. Lưu giữ các phiên bản của các yêu cầu dự án cho
phép lãnh đạo đội nắm bắt được lí do thay đổi của dự án, chẳng hạn ra đời một hệ
thống mới. Hiểu được một tập hợp các yêu cầu có thể liên kết với một phiên bản phần
mềm nào đó cho phép bạn quản lý thay đổi một cách nhanh chóng, giảm nguy cơ và cải
thiện khả năng gặp sự cố. Vì các yêu cầu riêng luôn tiến hóa nên việc hiểu được lịch sử
của chúng là rất quan trọng: cái gì thay đổi, tại sao, khi nào, và thậm chí là ai cho phép.
Ví dụ:
Phiên bản Mã yêu cầu Nguyên nhân thay đổi
1.0000 A Tạo yêu cầu
1.0001 A Thay đổi tên yêu cầu [yêu cầu 1]->[yêu cầu 2]

1.0002 A Thay đổi nội dung yêu cầu [aaaaaa]->[bbbbbb]
Nguyên nhân [cccccc]
1.0003 A Thay đổi thuộc tính:
1. Độ khó [Thấp] -> [Cao]
21
Quản lý yêu cầu đề án
2. Độ ổn định [Cao]-> [Thấp]
3. Giá trị [1 triệu] -> [2 triệu]
…
1.5 Xác định và viết các yêu cầu tốt :
1.5.1 Khái niệm yêu cầu tốt :
• Là những yêu cầu phải có đủ các tính chất sau: cần thiết, có thể xác định
được và có thể thực hiện được.
• Nếu yêu cầu đó có thể xác định được và có thể đạt được mà nó không cần thiết
thì yêu cầu đó không phải là một yêu cầu tốt.
• Tính cần thiết: khi nghi ngờ rằng yêu cầu đó có thật sự cần thiết không hãy đặt
câu hỏi: ”điều xấu nhất xảy ra nếu bỏ qua yêu cầu này là gì ?“ Khi không tìm
được câu trả lời hay một hậu quả nào đó do thiếu yêu cầu đó thì có thể hiểu rằng
không cần yêu cầu đó nữa.
• Khả năng xác minh: khi viết một yêu cầu, hãy tự hỏi bạn sẽ xác định nó như thế
nào? Nên xác định các tiêu chuẩn cho việc chấp nhận yêu cầu này. Điều này sẽ
giúp bạn chắc chắn rằng yêu cầu của mình có thể xác định được.
• Khả năng thực hiện: yêu cầu có thể đạt được khi nó có thể thực hiện được một
cách khoa học có kỹ thuật và phù hợp với ngân qũy, thời gian biểu và những
ràng buộc khác của yêu cầu. Nếu bạn không chắc chắn được yêu cầu đó có thể
thực hiện bằng kỹ thuật, bạn phải tham khảo các nghiên cứu hay phải nghiên
cứu để xác định khả năng thực hiện của yêu cầu. Nếu vẫn không chắc chắn
được yêu cầu sẽ được thực hiện thì bạn nên hiểu rằng cái mà bạn muốn là một
mục đích chứ không phải yêu cầu. Thậm chí khi một yêu cầu có thể thực
hiện được bằng kỹ thuật, nó vẫn có thể không làm được do hạn chế về ngân

qũy, lịch trình , ràng buộc….
• Yêu cầu nên viết đơn giản và súc tích tránh không mơ hồ, phải rõ ràng. Quan
trọng nhất là không được hiểu sai yêu cầu.
22
Quản lý yêu cầu đề án
1.5.2 Những khó khăn chung :
Đây là danh sách các khó khăn thường gặp khi viết một yêu cầu, những khó
khăn này sẽ được trình bày chi tiết phía dưới.
• Tạo ra những giả định sai lầm.
• Mô tả quá trình thực hiện thay vì viết những yêu cầu.
• Sử dụng những thuật ngữ sai.
• Sử dụng các câu sai cấu trúc hay có ngữ pháp kém.
• Quên sót một số yêu cầu.
• Vỡ kế hoạch.
• Giả định sai lầm :
Gây ra do người dùng cung cấp yêu cầu đó không hiểu rõ mình cần gì, không
có đủ quyền hạn để cung cấp thông tin hoặc thông tin đó không tồn tại. Bạn có thể
tránh khỏi những sai lầm này bằng cách tạo ra một kế hoạch chương trình và làm
cho kế hoạch này phù hợp với tất cả những người đưa ra yêu cầu. Bạn có thể tạo ra
và duy trì một danh sách các tài liệu thích hợp và làm cho chúng có thể truy cập
được bởi từng người đưa ra yêu cầu. Nếu bạn có một tiến trình tự động, bạn có thể
cung cấp tài liệu của bạn trên mạng để ai cũng có thể lọc ra những thông tin có
trong tài liệu, do đó những người đưa ra các yêu cầu sẽ có thể lấy được một bản sao
tài liệu họ cần.
Trong trường hợp thứ hai (không tồn tại thông tin), người đưa ra yêu cầu
phải tổng hợp các giả định xung quanh yêu cầu đó thành dạng tài liệu. Khi các yêu
cầu được duyệt lại thì những giả định cũng được duyệt lại và những khó khăn
nhanh chóng được nhận ra. Ngay cả khi người đưa ra yêu cầu chính xác thì cũng rất
hữu ích khi bạn tổng hợp các giả định thành dạng tài liệu. Bạn không thể chắc rằng
tất cả những người đưa ra tài liệu đã đọc và hiểu đúng hết các thông tin. Nếu họ

chuyển các giả định của họ thành dạng tài liệu thì bạn sẽ không phải vất vả sau này.
• Quá trình thực hiện :
23
Quản lý yêu cầu đề án
Xét một yêu cầu đầu tiên trong dự án: “cung cấp một cơ sở dữ liệu”. Câu
yêu cầu này là một phần quan trọng trong quá trình hoạt động, nó không cần thiết
và rất dễ tìm ra những yêu cầu phổ biến này trong bản báo cáo các yêu cầu. Bản báo
cáo chỉ nên báo cáo cái gì cần cung cấp không nên ghi nó được cung cấp như thế
nào. Do đó, đây là một lỗi thông thường khi viết các yêu cầu. Đa số những người
đưa ra yêu cầu không có ý định báo cáo phần hoạt động mà đơn giản là họ không
biết báo cáo cái gì cần cho chính xác.
Để tránh mắc sai lầm khi phát sinh một yêu cầu, bạn nên tự hỏi chính bạn là
Tại sao bạn cần yêu cầu đó và cố gắng tạo một cơ sở dữ liệu các yêu cầu chặt chẽ.
Bằng cách này người đưa ra các yêu cầu sẽ nhận biết được những gì cần cho hệ
thống và sau đó sẽ báo cáo các yêu cầu thực sự cần thiết như:
• Cung cấp khả năng cho việc theo dõi các bước giữa các yêu cầu.
• Cung cấp khả năng cho việc thêm vào các thuộc tính của yêu cầu.
• Cung cấp khả năng để sắp xếp các yêu cầu.
Có hai dạng nguy hiểm trong việc báo cáo quá trình hoạt động:
Loại thứ nhất:
Là khi chưa có ý định hoạt động mà buộc phải thiết kế. Nếu tất cả các yêu
cầu có thể nối kết với nhau mà không cần một cơ sở dữ liệu cho các yêu cầu thì tại
sao lại nói là cần một cơ sở dữ liệu. Nếu đưa ra yêu cầu mà không nói được yêu cầu
đó được thực hiện như thế nào và yêu cầu đó cần những gì hoặc chỉ nói được một
trong hai yếu tố trên thì khi thực hiện dự án sẽ gặp khó khăn. Vì nếu có nhiều yêu
cầu như thế sẽ không kết nối chúng được với nhau khi thực hiện, do đó nên có một
cơ sở dữ liệu cho các yêu cầu. Khi một dự án không có một cơ sở dữ liệu các yêu
cầu hoàn chỉnh thì việc thực hiện dự án đó sẽ rất nguy hiểm.
Loại thứ hai:
Rất mơ hồ và tiềm ẩn rất khó phát hiện. Đó là sau khi nộp báo cáo quá trình

hoạt động, những người đưa ra yêu cầu bị ru ngủ : tất cả các yêu cầu cần thiết đã
được bao hàm đầy đủ. Thực tế, có một số yêu cầu rất quan trọng đã bị bỏ sót và
24
Quản lý yêu cầu đề án
không thể phân phối được hết những yêu cầu (đã được hỏi nhưng chưa có trong bản
báo cáo) đến đội làm việc.
• Cách dùng các thuật ngữ:
Trong bản mô tả kỹ thuật có một số thuật ngữ tránh dùng và một số thuật ngữ phải
được dùng. Bạn phải hiểu rõ cách dùng các thuật ngữ. Một số thuật ngữ tránh dùng
trong yêu cầu vì chúng làm đảo lộn, rối rắm các vấn đề và có thể làm hao tốn chi
phí như:
• Hỗ trợ (support)
• Vân vân (etc.)
• And / or (và / hay)
• Nhưng không có giới hạn ( but not limit to…)
Thuật ngữ “hỗ trợ (support)” thường được dùng sai trong các yêu cầu. Thuật
ngữ này đúng khi bạn nói : “Tôi muốn một kiến trúc hỗ trợ được sức nặng 50kg “
nhưng lại sai khi bạn đang phát biểu “hệ thống sẽ hỗ trợ các hoạt động chắc chắn”.
Thuật ngữ “nhưng không giới hạn” hay “vân vân” làm người viết các yêu
cầu nghi ngờ rằng sẽ còn nhiều hơn những yêu cầu chưa được ghi ngoài những yêu
cầu đã có trong danh sách, như vậy sẽ không thể thực hiện được hết những yêu cầu
mong muốn và có thể đem lai kết quả trái với mong muốn.
Những thuật ngữ này được dùng để che đậy những phần chưa biết. Người
điều phối sẽ không tăng chi phí trong kế hoạch bởi vì bạn đã thêm vào những thuật
ngữ này. Cách duy nhất để giải quyết là làm một tác vụ phân tích trong giai đoạn
báo cáo công việc để xác định xem có thêm mục nào cần thêm vào danh sách hay
không. Trong giai đoạn này, bạn có thể quản lý để người điều phối nỗ lực tối đa xác
định các mục chưa biết cần thêm vào. Nếu có thêm các mục cần thêm vào thì bạn
nên gia tăng phạm vi hợp đồng để có đủ hết tất cả các điều khoản, điều kiện làm
việc. Tệ hơn nữa, nếu người điều phối lợi dụng lý do bạn đã ghi các thuật ngữ “vân

vân” hay “không giới hạn trong lĩnh vực này…” để làm những công việc mà bạn
không cần, dĩ nhiên, sau đó bạn phải trả tiền cho sai sót này.
25