luận văn cử nhân tin học và quản lý yêu cầu đề á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ả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

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

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

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/2004Nhóm sinh viên thực hiện Dương Ngọc Long Nam _ Vũ Kim Oanh

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

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

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

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

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?

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:

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

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

• 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,

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ừ

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

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

o Kiểm nghiệm đơn vị : 5

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,

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

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

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

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 yêu cầu

Giữa các yê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 yêu cầu, khơng cĩ một yêu cầu nào đứng đơn lẻ cả Các yê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 yêu cầu cá nhân, mà những yê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 yêu cầu cần xác thực và cơng nhận Các yêu cầu cĩ thể phụ thuộc hay tương hổ với

Để 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

Ví dụ:

Phiên bản Mã yêu cầu Nguyên nhân thay đổi

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 Độ khó [Thấp] -> [Cao]

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

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

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

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 đã

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.

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

Thuật ngữ “hay/hoặc” không thích hợp trong bản mô tả kĩ thuật Nếu bạn

sử dụng chúng sẽ gây ra nhầm lẫn Ví dụ, bạn muốn có mục 1 hay mục 2, người

điều phối có thể không hiểu được chính xác bạn muốn mục nào

Các yêu cầu nên được viết sao cho dễ đọc và dễ hiểu Mỗi yêu cầu thường được viết rõ ràng, độc lập theo các dạng sau:

• Hệ thống sẽ cung cấp…

• Hệ thống sẽ phù hợp với…

• Phân đoạn hệ thống thứ nhất sẽ cung cấp…

• Phân đoạn hệ thống thứ hai sẽ mô tả…

Lưu ý rằng bạn nên dùng các từ viết tắt để thay thế cho các tên của hệ thống hay tên các hệ thống con phức tạp, dài dòng trong bản mô tả kĩ thuật Nếu không bạn sẽ mất nhiều trang lãng phí trong bản mô tả kĩ thuật chỉ để ghi các tên phức tạp, dài dòng

Các yêu cầu đừng nên viết phức tạp, mơ hồ làm người đọc hiểu sai hoặc không hiểu hết nội dung của yêu cầu đó Để tránh sai sót, bạn nên tham khảo một số mẫu tiêu chuẩn các dạng câu yêu cầu

Ngữ pháp sai kém:

Sẽ làm người đọc hiểu sai những gì báo cáo Viết đúng ngữ pháp, bạn sẽ truyền đạt được nội dung của yêu cầu đến mọi người một cách chính xác, cho dù câu yêu cầu dài, phức tạp và có quá nhiều mệnh đề

Một cách giải quyết khác là viết các yêu cầu dưới dạng các biểu đồ hay đồ thị Các nhà viết yêu cầu thường có thói quen ghi rất nhiều yêu cầu chỉ trong một câu văn Biểu đồ sẽ giúp họ giải quyết được khuyết điểm này Từ biểu đồ chuẩn của các yêu cầu, họ có thể chuyển đổi thông tin sang câu văn để ghi trong bản mô tả kỹ thuật

Để tránh sai sót này, bạn nên sử dụng các đề cương tiêu chuẩn cho bản mô tả

kỹ thuật của bạn và mở rộng chúng đến chương trình của bạn

Nhiều yêu cầu bị quên do đội ngũ viết chúng chỉ tập trung vào một số phần quan trọng trong hệ thống Khi một yêu cầu trở nên cốt lõi, họ sẽ tập trung vào các chức năng và hiệu suất của yêu cầu đó, dĩ nhiên họ lờ đi những phần quan trọng khác – những yêu cầu còn lại

Dưới đây là bảng danh sách kiểm tra hướng dẫn cần tham khảo:

Bạn cần phát triển những đề cương chi tiết cho bảng mô tả kỹ thuật của bạn

về chức năng và hiệu suất của các yêu cầu và cả những phần khác

yêu cầu và tại sao nó cần thiết trước khi vạch cơ sở cho bản mô tả kỹ thuật thì kết quả thu được sẽ là một lượng lớn các yêu cầu không cần thiết.

Các yêu cầu khó khăn thái quá:

Hầu hết các yêu cầu thường là thái quá hoặc khó thực hiện một cách tình cờ Khó khăn phổ biến là những người soạn yêu cầu thường quy định một số liệu cụ thể cho yêu cầu đó mà không cân nhắc sức chịu đựng của nó khi thực hiện

Ví dụ, bạn viết: “hệ thống phải làm việc với hiệu suất 80KW” Nếu hệ

thống chỉ hoạt động đạt xấp xỉ thì xem như yêu cầu này không thực hiện được Do

đó bạn nên cho một độ chênh lệch thích hợp xung quanh số liệu muốn có, bạn sẽ

viết: “hệ thống phải làm việc với hiệu suất 80KW +/- 5KW”.

Tốt nhất là nên thảo luận về khả năng có thể của mỗi giá trị bất kỳ cho yêu cầu của bạn và qui định yêu cầu này trong khoảng các số liệu cho phép Chi phí thực hiện mỗi yêu cầu cũng phải được cân nhắc

1.5.3 Thu thập thông tin yêu cầu

1.1.1.1 Các kỹ thuật thực hiện:

• Phỏng vấn trực tiếp: theo 2 hình thức

o Hình thức thứ 1: theo nội dung định sẵn hay theo thứ tự định sẵn

o Hình thức thứ 2: theo dạng hỏi đáp linh hoạt

o Một số kinh nghiệm quí báu:

 Thiết lập cuộc hẹn sao cho thời gian và địa điểm phải thích hợp

 Tạo không khí thoải mái

• Thống nhất câu trả lời cho phạm vi bài toán.

• Tăng cường sự đóng góp của khách hang

• Nguyên tắc dòng chảy thông tin

• Tập trung vào nghiệp vụ của người dùng

• Nghiệp vụ nào sẽ được hỗ trợ trên máy tính

• Phương pháp Use case

• Định nghĩa các đặc tính về chất lượng làm cơ sở cho các yêu cầu phi chức năng

1.1.1.3 Quy trình đề nghị:

• Tìm hiểu tổng quan về thế giới thực

• Tìm hiểu cơ cấu tổ chức

o Nghiệp vụ thống kê tổng hợp

Tên Mô tả Thời gian

thực hiện Người thực hiện Điều kiện Vị trí Kết xuất Tần suấtVd:

Chức danh cần thiết hơn tên

Cần nghiệp

vụ nào thực hiện trước đó

Nếu

có nhiều đơn vị, chi nhánh khác nhau

Mẫu báo biểu nào

Đánh số rồi chỉ đến phần phụ lục mô tả chính xác báo biểu

Hằng ngày, hằng tháng thực hiện bao nhiêu lần

• Tìm hiểu về cơ sở tin học:

Tên Các phân hệ Nghiệp vụ phục vụ Nhận xét

1.5.4 Phân tích yêu cầu

Có những yêu cầu chức năng nào? Mức độ hổ trợ tin học đối với chúng như thế nào?

o Hổ trợ 1 phần

o Hổ trợ hoàn toàn

Có những yêu cầu phi chức năng nào? Phạm vi ảnh hưởng của chúng?

o Tốc độ

o Bảo mật

o Tính tương thích

o …

1.1.1.5 Xác định độ ưu tiên cho các yêu cầu

1.6 Ai sẽ thu được lợi từ quản lý yêu cầu :

Tất cả các đội ngũ phần mềm và các thành viên trong đội đều có lợi từ quản lý yêu cầu Các yêu cầu sẽ dẫn hướng cho phần mềm hay những hoạt động phát triển

hệ thống Chúng được dùng như sự diễn đạt các giải pháp mà toàn bộ đội ngũ phần mềm đang phân phối Thật quan trọng để truyền đạt các yêu cầu sao cho tất cả các thành viên trong đội có thể biết chúng Điều này đảm bảo dự án của bạn bắt đầu và kết thúc trên cùng một hướng

Một vài triệu chứng báo hiệu cho các đội ngũ có thể biết việc quản lý các yêu cầu không hiệu quả là việc thiếu các tài nguyên và phát sinh một khối lượng lớn các công việc phải làm lại

1.7 Vài điều cần thực hiện khi quản lý yêu cầu:

Các dự án thành công chia sẻ các đặc điểm sau: Các yêu cầu thực sự phản ánh các nhu cầu của khách hàng và các thành viên trong đội ngũ phải hiểu rõ ràng các yêu cầu, các mong muốn của khách hàng phải được quản lý một cách hiệu quả, việc thay đổi yêu cầu phải được quản lý và phải được biết đến bởi mọi thành viên trong đội ngũ

Một sự tiếp cận hệ thống đối với việc quản lý các yêu cầu được thực thi xuyên suốt cả đời sống của dự án, bảo đảm các yêu cầu được gợi mở, nắm bắt và truyền thông đến các thành viên trong đội dự án sớm; được ưu tiên hoá trước mỗi vòng lặp; và được quản lý khi chúng thay đổi Việc tiếp cận này làm trau dồi khả năng có thể phát triển các giải pháp chất lượng trên thời gian và ngân qũy

Chỉ có cách chủ động quản lý các yêu cầu mới có thể bảo đảm hệ thống mà bạn đang phát triển thực hiện những việc mà nó được yêu cầu làm thoả mãn các nhu cầu của stakeholder

Phụ thuộc vào các thách thức cụ thể mà đội của bạn đang đối mặt, bạn có thể quyết định giải quyết vấn đề theo những cách khác nhau Một vài nhóm đã cố gắng hiểu nhu cầu người dùng của họ bằng cách sưu liệu các yêu cầu một cách hiệu quả…

1.8 Quản lý các yêu cầu hình thức như thế nào?

Nói chung, tiến trình quản lý yêu cầu của bạn càng không hình thức thì giải pháp của bạn không thoả được nhu cầu khách hàng càng sớm Việc tranh cãi thông thường do nhận ra tiến trình quản lý các yêu cầu rời rạc nhau:

• Cho phép chúng ta phát triển nhanh hơn

• Cho chúng ta sự uyển chuyển để thích nghi với những thay đổi yêu cầu của thị trường

• Chúng ta không cần những tài liệu yêu cầu hình thức để biết mình được yêu cầu tạo ra cái gì

Không may mắn, đây chính xác là cuộc tranh cãi thường xảy đến cho nhiều đội dự án Trước khi nhận một công việc nào đó, đội cần phân tích một cách cẩn thận mức độ rõ ràng của việc quản lý yêu cầu để dự án thành công Cơ bản, các công việc quản lý yêu cầu của bạn cần đạt được:

• Các yêu cầu cần được mọi thành viên trong đội dự án hiểu rõ

• Sự truyền thông có hiệu quả giúp cho toàn bộ đội dự án ở cùng một mức độ.Chắc chắn trong vài trường hợp, việc gắn chặt với tiến trình quản lý yêu cầu hình thức sẽ trở nên dư thừa

Ví dụ: Đội chúng ta được phân công nhiệm vụ xây dựng một chương trình trò chơi video Bạn nghĩ rằng sự mở rộng hay thay đổi các yêu cầu có thể đổ dồn vào cùng một tỷ lệ về độ nhanh Theo tiến trình truyền thống kiểm tra sự thay đổi bao gồm việc đạt được sự chấp nhận từ CCB (Change Control Board) (Ban kiểm soát sự thay đổi) có thể kìm hãm sự sáng tạo của những nhà phát triển, ban này hoạt động như cổ chai (bottleneck) (là phần quan trọng nối lại giữa đầu chai_CCB và thân chai_giao phần mềm) đến việc giao phần mềm, và sau cùng làm tổn hại đến các cơ

thuật quản lý các yêu cầu có chọn lọc, như các bản chi tiết hay các nguyên mẫu, để làm cho trò chơi có giá trị trước khi phát triển và giao chúng.

Với một trường hợp khác là những yêu cầu sự cố đối với việc thực hiện quản

lý các yêu cầu Ví dụ, nếu đội dự án của bạn được phân công công việc: “phát

triển phần mềm quản lý một thiết bị y học mà tự động quản lý việc phát khối lượng thuốc chính xác cho bệnh nhân dưới những điều kiện biến đổi khác nhau”, kế đó đội của bạn sẽ nhận được một tiến trình quản lý các yêu cầu có cấu

trúc cao để bảo đảm sự chính xác toàn thể Làm lỗi với một yêu cầu nào đó trong tình huống này có thể làm cho bệnh nhân tử vong

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:

Phần này, chúng ta sẽ thấy vài vấn đề liên quan đến các yêu cầu mà nó sẽ ảnh hưởng đến những nhà phát triển và đề xuất ra các cách tiếp cận quản lý yêu cầu để tránh các vấn đề này

Các vấn đề yêu cầu phổ biến

1 Không thể tìm thấy thay đổi 71%

2 Khó viết 70%

3 Chậm nắm bắt thông tin 67%

4 Không được tổ chức tốt 54%

Danh sách các vấn đề bao gồm:

• Các yêu cầu không phải lúc nào cũng rõ ràng và có nhiều nguồn

• Các yêu cầu không luôn luôn diễn đạt rõ ràng bằng từ.

• Có nhiều loại yêu cầu khác nhau ở các mức độ chi tiết khác nhau

• Số yêu cầu có thể trở nên không thể kiểm soát được

• Các yêu cầu liên quan đến nhau và đến khả năng phân phối của tiến trình theo nhiều cách

• Các yêu cầu có các thuộc tính duy nhất hay giá trị thuộc tính

• Các yêu cầu thì quan trọng như nhau nhưng lại không dễ bị phát hiện như nhau

• Có nhiều nhóm có trách nhiệm và quan tâm, có nghĩa là các yêu cầu được quản lý bởi những nhóm người có chức năng ngang nhau

• Thay đổi các yêu cầu

• Các yêu cầu thay đổi dựa trên thời gian

Khi các vấn đề này gộp chung với việc thiếu kỹ năng về tiến trình và quản lý các yêu cầu và thiếu các công cụ dễ dùng, nhiều nhóm đã than phiền rằng họ sẽ không bao giờ có thể quản lý các yêu cầu tốt

Gồm 4 vấn đề cùng các biện pháp tránh:

1.9.1 Vấn đề 1 : Sự đặc tả các yêu cầu không hoàn thiện :

Trong các thách thức hàng đầu của việc quản lý các yêu cầu mà đội của bạn đang đối mặt là những nhập nhằng không thể tránh khỏi trong phiên bản đầu tiên của các yêu cầu Khi lần cuối bạn đọc phiên bản đầu tiên tài liệu quản lý yêu cầu và cảm thấy tin rằng bạn đã hiểu thấu đáo được cái bạn nghĩ sẽ xây dựng?

Phiên bản đầu tiên của các tài liệu về các yêu cầu thì hầu như luôn luôn không hoàn thiện và nhập nhằng đối với một vài phạm vi Đa số các tài liệu về yêu cầu không được xét duyệt lại từ bản phác thảo đầu tiên; điều này có nghĩa là chúng thiếu thông tin cho các nhà phát triển thiết kế thành phần hệ thống của họ, để chúng

“thông dịch” những điều mà người dùng muốn

Mặc dù các nhà phân tích đã cố gắng thử tập trung và sưu liệu các yêu cầu thông qua các phòng hội họp quản lý các yêu cầu, các phòng gắn kết các phiên phát triển ứng dụng (JAD – joint application development), các cuộc phỏng vấn, hay các nhóm tập trung Những nhà phát triển thường có nhiều câu hỏi sau lần xem xét lại

để đảm bảo các yêu cầu, dù các nhà phân tích có tinh thông vấn đề theo chủ quan như thế nào đi nữa Thường thì các nhà phát triển đơn giản cung cấp các viễn cảnh

mà nhà phân tích vừa không nhận thấy

Ví dụ: họ đưa ra những trường hợp ngoại lệ mà người dùng gặp phải nhưng nhà phân tích thất bại trong giải quyết chúng Do đó, bắt buộc các nhà phát triển và các nhà phân tích làm việc gần nhau để lọc ra các đặc tả các yêu cầu ban đầu trước khi bắt đầu thiết kế

*Giải pháp: Đặc tả các yêu cầu chi tiết và không nhập nhằng:

Việc thực hiện quản lý các yêu cầu có hiệu quả nhận ra rằng việc xem xét lại các đặc tả yêu cầu nên là tiêu chuẩn hơn là trường hợp ngoại lệ trong bất kỳ dự án nào Toàn bộ đội phát triển dự án nên xem xét lại phiên bản đầu tiên của đặc tả và các nhà phát triển nên có đủ thời gian để đưa ra câu hỏi Đến lượt nhà phân tích yêu cầu nên có đủ thời gian để trả lời các câu hỏi này và các công bố tài liệu thu được sau khi phân tích, trả lời các câu hỏi trên Cụ thể, nhà phân tích cần thời gian để kiểm tra trực tiếp với khách hàng để tập trung vào nhiều chi tiết hơn Thật cần thiết

để tất cả các tranh cãi của nhà phát triển được giải quyết trước khi thiết kế bắt đầu Ngược lại, các nhà phát triển có thể nêu lên những yếu tố không mong muốn đối với hệ thống sẽ xảy ra

Ngoài việc xem xét ra, các đội sẽ sử dụng các use case để diễn đạt các yêu cầu chức năng Các use case mô tả hệ thống có những hành vi như thế nào khi tương tác với thế giới bên ngoài bằng cách sưu liệu chức năng hệ thống như hộp thoại giữa người dùng và hệ thống chẳng hạn Việc này cung cấp cho các đội ngũ phát triển phần mềm và khách hàng của họ, với sự hiểu biết thông thường về hành

vi có thể biết được hệ thống, từ viễn cảnh của người dùng Các nhà phát triển đóng

vai trò chủ động trong việc chi tiết các use case này để làm tăng sự rõ ràng của các yêu cầu và vì vậy làm tối thiểu sự hiểu lầm

Các nhà phân tích thường che đậy các use case chính (các tình huống sử dụng) và kết luận rằng không có vấn đề nào chính nữa Tuy nhiên, khi nhà phát triển bắt đầu xem các chi tiết trở nên cốt yếu bằng cách xác định các luồng use case cho phép chọn lựa (các tình huống sử dụng sẽ dựa trên những điều sai lầm), khi đó các vấn đề tranh cãi thật sự sẽ xuất hiện Nếu nhà phát triển không làm công việc phức tạp này trước khi thiết kế thì việc thiết kế sẽ được làm lại nhiều lần để phối hợp tất cả các tình huống sử dụng của người dùng

Kết quả, khả năng của nhà phát triển và nhà phân tích thiết lập một mối quan

hệ kết hợp mạnh mẽ ở giai đoạn này thường quyết định sự thành công của sản phẩm cuối cùng

Tuy nhiên, ghi nhớ rằng không phải tất cả các yêu cầu có thể được diễn đạt trong các use case

Ví dụ: khả năng tin cậy và việc thực thi các yêu cầu được diễn đạt tốt hơn trong hình thức khai báo (ví dụ: “hệ thống sẽ…”) nhưng các use case cung cấp kỹ thuật để sưu tầm kinh nghiệm người dùng với hệ thống trong một cách toàn diện Bằng cách tập trung vào quan điểm người dùng, các use case cũng bỏ đi các yếu tố thiết kế không mong muốn trong các đặc tả yêu cầu và do đó những nhà thiết kế được giải phóng khỏi các ràng buộc thiết kế không được báo trước

1.9.2 Vấn đề 2: Các yêu cầu về việc thay đổi cố định :

Báo cáo về sự hỗn loạn các thái cực của nhóm Standish Group vào năm 2001 tuyên bố rằng: “Changing requirements are as certain as death and taxes” Đạt được

sự kiểm soát về việc thay đổi trên các yêu cầu là quan trọng với thành công của dự

án, và đó là công việc ảnh hưởng trực tiếp tới nhà phát triển

Hãy xem lại những dự án của bạn, bạn có cố gắng để thêm các yêu cầu bằng cách tăng giờ làm việc không? Những cản trở này có tác động tốt đến quá trình thực hiện của bạn, hay chúng làm khó tập trung hơn Nhưng quan trọng hơn là chúng có

mềm, thậm chí những thay đổi nhỏ nhất có thể gây ra tác động đến các thành viên trong đội và dự án

Ví dụ: nếu những nhà kiểm nghiệm không thông báo về những thay đổi, họ

sẽ không xây dựng được các kịch bản có giá trị cần thiết để kiểm tra nó, và kết quả

là ảnh hưởng tới quá trình kiểm tra chất lượng, công nghệ Điều này sẽ gây trì hoãn toàn bộ thời gian biểu của dự án Nói chung, những cản trở cố định này có thể làm cho các kế hoạch dự án bị mở rộng, dẫn đội đi sai hướng từ các yếu tố khách quan đầu tiên của nó, dẫn đến phần mềm không thoả được các mong muốn của khách hàng

*Giải pháp: kiểm soát các yêu cầu bằng cách truy cập vào các ảnh hưởng tiềm năng.

Giải pháp là một tập hợp các công việc được thực hiện trong thực tế

mà chúng ngăn cản các nhà phát triển làm những thay đổi ngẫu nhiên trước khi đội định giá trị cho những ảnh hưởng có thể của họ Các đặc tả yêu cầu nên thay đổi chỉ sau khi họ thông qua các tập tiêu chuẩn bởi ban quản lý các yêu cầu thay đổi, ít nhất

là khách hàng, đội phát triển và đội kiểm nghiệm Trách nhiệm của ban này là định giá trị cho các yêu cầu thay đổi từ 3 quan điểm: khách hàng, nhà phát triển và kiểm nghiệm sưu liệu (phụ thuộc vào loại ứng dụng, rèn luyện và hổ trợ đội ngũ nhân viên cần được bổ sung vào)

Đại diện nhà phát triển nên đánh giá tất cả các thiết kế mà yêu cầu thay đổi tác động vào, cũng như mức độ cố gắng được đòi hỏi cho cài đặt thay đổi Họ có thể yêu cầu nhà phát triển giúp đỡ phân tích những ảnh hưởng tiềm năng của những thay đổi được đề xuất

Đại diện quản lý chất lượng nên đánh giá tính khả thi và mức độ kiểm nghiệm liên quan đến những thay đổi tiềm năng Sự thay đổi được kết hợp trong mã nguồn rất khó kiểm tra, thậm chí không thể kiểm tra

Đại diện khách hàng cung cấp viễn cảnh nghiệp vụ và bảo đảm rằng những thay đổi của họ không làm dự án xao lãng việc theo đuổi những mục tiêu nghiệp vụ ban đầu Người này cũng nên cung cấp các thông tin chung về những thay đổi để ban quản lý các thay đổi hiểu được nhu cầu khách hàng

Mỗi thành viên trong ban quản lý các yêu cầu thay đổi nên chịu trách nhiệm tìm sự thay thế đầy đủ trong trường hợp có người vắng mặt để việc đánh giá các yêu cầu thay đổi không bị thiên vị Nếu tất cả các nhóm không có đại diện thì ban nên trì hoãn tiến trình định giá trị.

Dùng cách tiếp cận tuần tự cho việc phát triển hay hơn cách tiếp cận thác nước truyền thống cũng là một sự giúp đỡ lớn trong việc quản lý những thay đổi đối với các yêu cầu Cách tiếp cận truyền thống làm đóng băng các đặc tả yêu cầu lúc bắt đầu dự án và theo lý thuyết thì không cho phép những thay đổi cho đến sau khi phần mềm được xuất xưởng Cách tiếp cận đó đã khuyến khích người ta trực tiếp gặp nhà phát triển và hỏi họ về những thay đổi mã nguồn của họ dẫn đến các kết quả tiêu cực mà chúng ta đã bàn ở trên

Ngược lại, việc phát triển tuần tự cho phép các đội phần mềm chia công việc thành các vòng lặp với những yêu cầu ổn định nội bộ Lúc bắt đầu một vòng lặp mới, đội lấy cơ hội cập nhật các đặc tả yêu cầu và kết hợp bất kỳ những thay đổi nào được nộp và chấp nhận trong suốt vòng lặp trước đó Khi các đặc tả có thể thay đổi chỉ ở đầu mỗi vòng lặp, những nhà phát triển có thể tập trung vào một tập các yêu cầu chắc chắn trong suốt bản thân vòng lặp

1.9.3 Vấn đề 3: Không biết đến những thay đổi đã ảnh hưởng đến những công

việc của bạn:

Là nhà phát triển, khi các yêu cầu thay đổi, bạn được thông tin như thế nào? Thường thì những nhà phát triển làm việc trên những yêu cầu quá hạn bởi vì ai đó quên thông tin cho họ về những thay đổi ảnh hưởng đến công việc của họ Mặc dù nhà phân tích trong đội bạn có thể thảo luận về sự lựa chọn với một nhà phát triển

cụ thể để đánh giá sự ảnh hưởng của thay đổi trước khi chấp nhận chúng, những anh ta không nhận ra rằng sự tác động của nó đến công việc của những nhà phát triển khác trong đội Cũng vậy, thậm chí khi bạn nghe về những thay đổi trong các yêu cầu, miễn là ai đó trong đội của bạn tìm ra các mối quan hệ giữa các yêu cầu và thiết kế các yếu tố được tạo ra để thực hiện chúng, thật khó để đánh giá một cách

nhanh và chính xác sự ảnh hưởng mà những thay đổi gây ra trong công việc của bạn.

*Giải pháp: Thông báo các thay đổi yêu cầu

Nếu đội của bạn chỉ định ai đó truy vết các phụ thuộc giữa các yêu cầu và thiết kế các artifact, thì miễn là các yêu cầu thay đổi thì người đó có thể xác định chính xác thành phần thiết kế nào sẽ bị ảnh hưởng và thông tin cho tất cả những nhà phát triển làm việc trên đó biết

Các nhà phát triển sẽ biết họ có thể liên lạc với người đó để chắc chắn rằng

họ được cập nhật những yêu cầu mới nhất Bởi vì các yêu cầu đang di chuyển các mục đích, người truy vết này sẽ cần đến khả năng truy vết (traceability), khả năng truy vết các phụ thuộc giữa các yêu cầu để chắc chắn các yêu cầu nào sẽ được cài đặt thật sự

Có những mức độ truy vết khác nhau, nhưng theo cơ bản thì mục đích của chúng là cung cấp một sự bảo đảm nào đó mà chức năng bạn giao cho khách hàng của bạn sẽ thật sự được cài đặt và sẽ được xác định giá trị bởi nhà kiểm nghiệm Truy vết các yêu cầu để thiết kế các yếu tố là quan trọng để đảm bảo rằng các yêu cầu có hiệu lực và việc kiểm tra hiệu lực được cập nhật khi yêu cầu thay đổi, các yêu cầu cũng sẽ được truy vết để kiểm tra các aritfact, điển hình là kiểm tra các test case

Việc truy vết các yêu cầu đến mã nguồn nào? Mặc dù ý kiến này dường như gây chú ý đầu tiên (ví dụ: nếu tôi thay đổi một yêu cầu, thì tôi sẽ biết được đọan code nào phải được cập nhật), thật ra là khó khả thi, bởi vì code thì động hơn các yêu cầu Nếu bạn bắt đầu với một thiết kế và kế đến là tối ưu hóa nó thì thiết kế mới

sẽ làm cho code thay đổi nhưng vẫn tuân theo các yêu cầu Việc duy trì các liên kết khả năng truy vết phải mất thời gian mà các đội phát triển phần mềm không bao giờ

có đủ, vì vậy bạn nên dùng khả năng truy vết một cách đúng đắn Bạn chỉ cần báo cáo yêu cầu sản phẩm cuối cùng truy vết đến code và không có đọan code nào được xây dựng mà không thích hợp với một yêu cầu nào đó Nếu bạn cố gắng lấy

nhiều chi tiết hơn thì quản lý các liên kết khả năng truy vết giữa các yêu cầu và mã nguồn.

1.9.4 Vấn đề 4: Các đặc tả yêu cầu hết hạn:

Tài liệu đặc tả yêu cầu là phương tiện chính yếu mà nhà phân tích dùng để bảo đảm mọi người trong đội hiểu được hệ thống cần được phát triển những gì và những vấn đề gì khách hàng cần mà hệ thống nên ghi nhận Thật quan trọng để các nhà phát triển định vị được tài liệu này và cập nhật chúng Đây là những hướng dẫn

rõ ràng, đơn giản nhưng tiến trình thì có thể phức tạp Các đặc tả thường được xem xét lại trên nền tảng đặc biệt, vì vậy khi làm các quyết định và nêu lên các giả thuyết về các nhu cầu nên được cập nhật thường xuyên Cuối cùng khi chúng được cập nhật, các yêu cầu không phải luôn luôn được phân phối lại cho đội hay họ có thể sẽ đánh mất các nhóm thông tin trung gian qua email trong hộp inbox

*Giải pháp: Các đặc tả được cập nhật sẵn sàng

Kinh nghiệm cho thấy phải chỉ định rõ ràng kho chứa trung tâm cho tài liệu đặc tả các yêu cầu để mọi người luôn luôn có thể truy cập để có được phiên bản mới nhất Điều này đảm bảo cho các nhà phát triển không bị phí thời gian và tập trung

cố gắng cài đặt các yêu cầu quá hạn Nó cũng là ý kiến tốt để thông báo cho đội (qua email, điện thoại, hội họp ) khi đặc tả các yêu cầu vừa cập nhật

1.10 Cách giúp tăng cường khả năng quản lý yêu cầu trong tổ chức:

Bất kỳ yêu cầu nào thay đổi nên được xác nhận trước khi được chấp nhận Bước đầu tiên trong thiết lập một xử lý là xác định xem đội của bạn thu thập và quản lý các yêu cầu thay đổi như thế nào Cách đơn giản nhất là tạo ra một mẫu chuẩn mà mọi người có thể điền vào các yêu cầu và nộp thông qua email, fax, hay nộp trực tiếp Một phương pháp mạnh hơn là dùng công cụ hổ trợ quản lý thay đổi

Kế đến bạn quyết định sẽ lưu trữ các yêu cầu này như thế nào? Bạn sẽ dùng kẹp