Software Requirements. First Edition – MS Press. Chương 2: Yêu cầu từ góc nhìn của khách hàng

Tác giả: Karl E. Wiegers

Người dịch: Hoàng Xuân Thịnh

Lời người dịch
Mở đầu chương bằng một tình huống trao đổi điển hình giữa khách hàng và nhà phát triển phần mềm, tác giả chỉ ra sự nhầm lẫn của khách hàng về các mức yêu cầu: yêu cầu kinh doanh (business requirements), yêu cầu người dùng (user requirements), yêu cầu chức năng và phi chức năng (functional and non-functional requirements) của sản phẩm phần mềm cần được xây dựng.

Từ các mức khác nhau của yêu cầu, tác giả dẫn ra các lớp khách hàng khác nhau: khách hàng là người trả tiền mua phần mềmkhách hàng là người lách cách gõ phím sử dụng phần mềm hàng ngày. Mỗi khách hàng lại đặt ra các mức yêu cầu khác nhau. Tác giả nhận định rằng phần mềm chất lượng cao là do có được yêu cầu tuyệt hảo (excellent requirements) ngay từ đầu, mà yêu cầu tuyệt hảo là kết quả của sự cộng tác tốt giữa hai nhân vật: khách hàngnhà phát triển.

Mọi sự cộng tác giữa các bên đều giống như một cuộc chơi, nghĩa là đều phải có các quy tắc ràng buộc, kiểm soát cuộc chơi. Tác giả đã đề xuất các quy tắc ràng buộc cuộc chơi và theo đúng phong cách của người Mỹ – mọi thứ đều phải có luật phân xử, ông gọi vui các quy tắc đó là Dự luật, chúng cần phải được khách hàng và nhà phát triển cùng thông qua thành Luật trước khi bắt đầu dự án xây dựng phần mềm. Đó là Dự luật yêu cầu về quyền của khách hàng phần mềmDự luật yêu cầu về trách nhiệm của khách hàng phần mềm.

Cuối cùng tác giả chỉ ra khi nào thì cần kết thúc quá trình phát triển yêu cầu để bắt tay vào các công việc tiếp theo. Kết quả của quá trình phát triển yêu cầu là bản đặc tả yêu cầu phần mềm SRS.

Gerhard là một nhà quản lý cấp cao của Consoto Pharmaceuticals, anh có một cuộc gặp làm việc với Cynthia, nhà quản lý mới của nhóm phát triển hệ thống thông tin của Contoso. “Chúng ta cần xây dựng một hệ thống thông tin giám sát hoá chất (chemical-tracking information system, CTIS) cho Contoso,” Gerhard bắt đầu. “Hệ thống phải cho phép giám sát tất cả các chai hóa chất mà chúng ta có trong kho hoặc trong các phòng thí nghiệm. Như vậy, các nhà hoá học có thể biết hoá chất họ muốn dùng còn không và còn ở đâu thay vì khi nhu cầu xuất hiện thì lại đi mua chai mới. Văn phòng Sức khoẻ và An toàn cũng phải thực hiện các báo cáo về việc sử dụng hoá chất để gửi chính phủ liên bang. Nhóm của cô có thể giúp chúng tôi xây dựng phần mềm này trong 5 tháng chứ, nghĩa là phần mềm đã sẵn sàng hoạt động ngay khi chúng ta có cuộc kiểm toán tuân thủ đầu tiên?”

“Tôi nghĩ đó chính là lý do tại sao dự án này quan trọng, Gerhard,” Cynthia trả lời. “Nhưng trước khi tôi có thể cam kết một lịch biểu, tôi cần thu thập một số yêu cầu về hệ thống này đã.”

Gerhard lúng túng. “Cô nói sao? Tôi vừa chẳng nói yêu cầu với cô đó thôi.”

“Thật sự là anh chỉ vừa nói về một ý tưởng và một số mục tiêu của dự án này,” Cynthia giải thích. “Các yêu cầu kinh doanh mức cao đó (high-level business requirements) không giúp tôi hình dung đủ chi tiết về cái gì cần làm và ước tính  thời gian làm trong bao lâu. Tôi muốn có một nhóm kết hợp giữa các phân tích viên hệ thống và các nhà hoá học để hiểu rõ về nhu cầu đối với hệ thống này. Khi đó chúng tôi có thể phác ra chức năng nào là cần thiết nhằm đáp ứng cả mục tiêu kinh doanh và nhu cầu người dùng. Thậm chí anh có vẻ như không hề cần biết hệ thống này giúp anh như thế nào trong việc tiết kiệm được chi phí hoạt động.”

Gerhard không hề phải đối mặt với sự phản ứng như thế này từ người phát triển hệ thống trước đây. “Các nhà hoá học rất bận rộn,” anh ta phản đối, “họ không có thời gian để vẽ ra các chi tiết trước khi cô bắt đầu xây dựng hệ thống của mình. Người của cô không làm được việc này sao?”

Cynthia cố gắng giải thích lý lẽ của cô trong việc thu thập yêu cầu từ những người sẽ sử dụng hệ thống mới, “Nếu chúng tôi làm những gì mà chúng tôi cho rằng người dùng cần thì chúng tôi không thể làm ra một hệ thống tốt được. Chúng tôi là những nhà phát triển phần mềm, vì vậy chúng tôi không thật sự biết các nhà hoá học cần gì để làm ra hệ thống giám sát hoá chất cho họ được. Tôi đã học được rằng nếu chúng tôi không mất thời gian để tìm hiểu vấn đề trước khi viết mã nguồn thì sẽ không ai hài lòng về sản phẩm phần mềm làm ra.”

“Thôi nào, chúng ta không  có thời gian cho những việc ấy,” Gerhard khăng khăng ý kiến của mình, “Tôi vừa cho cô yêu cầu rồi. Nào bắt đầu xây dựng hệ thống của cô đi. Hãy nhớ tiến độ tôi yêu cầu đấy.”

Cuộc trao đổi trên là điển hình trong ngành sản công nghiệp mềm. Khách hàng đề nghị xây dựng một hệ thống thông tin mới nhưng thường không hiểu tầm quan trọng của việc có được đầu vào từ những người dùng tương lai của hệ thống. Không có gì có thể thay thế cho việc thu thập yêu cầu trực tiếp từ những người sẽ sử dụng hệ thống. Một nghiên cứu trên 8380 dự án đã chỉ ra rằng  hai nguyên cao nhất khiến dự án bị trục trặc là thiếu thông tin đầu vào từ người dùng và các yêu cầu, đặc tả không đầy đủ (Standish 1995).

Nguyên nhân của sự bối rối đối với đa số những người liên quan đến việc xây dựng một hệ thống thông tin là phân biệt sự khác nhau giữa các mức yêu cầu: kinh doanh, người dùng, chức năng (business, user, functional). Gerhard đã xác định một số yêu cầu kinh doanh, nhưng anh ta không thể mô tả được yêu cầu người dùng vì anh ta không phải là người sử dụng của hệ thống này. Những người dùng tiềm năng mới có thể mô tả các tác vụ mà họ cần phải làm với sự trợ giúp của hệ thống, nhưng họ lại không thể xác định tất cả các yêu cầu chức năng cụ thể cần phải được cài đặt để cho phép họ hoàn thành các tác vụ đó.

Chương này làm rõ mối quan hệ giữa khách hàng và nhà phát triển, quan hệ đóng vai trò then chốt trong sự thành công của một dự án phần mềm. Tôi đề xuất một Dự luật Yêu cầu về Quyền của Khách hàng Phần mềm (Requirements Bill of Rights for Software Customers) và một Dự luật Yêu cầu về Trách nhiệm của Khách hàng Phần mềm (Requirements Bill of Responsibilities for Software Customers) tương ứng nhằm nhấn mạnh tầm quan trọng của khách hàng (và người dùng nói riêng) trong quy trình phát triển yêu cầu.

I. AI LÀ KHÁCH HÀNG? (WHO IS THE CUSTOMER?)

Trong nghĩa rộng nhất của nó, một khách hàng là một cá nhân hoặc một tổ chức được hưởng trực tiếp hoặc gián tiếp lợi ích từ việc sử dụng một sản phẩm. Khách hàng phần mềm gồm tất cả những người liên quan đến dự án, đó là những người thanh toán tiền mua phần mềm, chọn lựa, đặc tả, sử dụng phần mềm, những người sử dụng thông tin đầu ra của phần mềm.

Gerhard đại diện cho kiểu khách hàng thanh toán, mua sắm hoặc tài trợ một dự án phần mềm. Các khách hàng mức cao như Gerhard chịu trách nhiệm đặc tả các yêu cầu kinh doanh (business requirements). Họ cung cấp các ý tưởng ở mức cao về sản phẩm và lý do, sự hợp lý để khởi động dự án sản xuất sản phẩm đó. (Theo kinh nghiệm của tôi, đây là loại khách hàng quan trọng nhất, họ quyết định lý do về mặt kinh doanh tại sao lại có dự án này và đó cũng là lý do tại sao lại phải tiêu tốn cho dự án này. Một thay đổi quyết định của họ sau này có thể làm ngưng lại cả một dự án đang tiến hành, dù tiền chưa được chuyển vào tài khoản của nhà sản xuất – ND).

Như thảo luận trong Chương 6, các yêu cầu kinh doanh (business requirements) mô tả mục tiêu (objectives) mà khách hàng, doanh nghiệp, hoặc những người liên quan khác mong muốn đạt được, hoặc các giá trị mà họ muốn nhận được từ hệ thống. Business requirements tạo ra định hướng cho dự án. Sau đó thì bất cứ cái gì được đặc tả như một yêu cầu đều cần nhất quán với các business requirements, cũng phải nhất quán như vậy đối với các tính năng của phần mềm. Tuy nhiên, business requirements không cung cấp các chi tiết đủ để các nhà phát triển biết cái họ cần làm là gì (what to build).

Mức yêu cầu tiếp theo – user requirements – cần được thu thập từ những người sẽ trực tiếp sử dụng hệ thống. Những người dùng đó (thường được gọi là người dùng cuối – end users) là một kiểu khách hàng khác của hệ thống. Họ có thể mô tả cả các tác vụ (tasks) mà họ cần để thực thi với sự giúp đỡ của hệ thống và các đặc tính phi chức năng quan trọng để hệ thống có thể được chấp nhận.

Trong số các kiểu khách hàng thì:

  • Các khách hàng là người trả tiền cung cấp các thông tin về lý do cần xây dựng hệ thống, hợp đồng, hoặc phát triển ứng dụng tuỳ biến (custom application), tức là các business requirements.
  • Các khách hàng là người ấn vào các phím máy tính hàng ngày để sử dụng hệ thống cung cấp các thông tin gọi là user requirements.

Không may là cả hai kiểu khách hàng đều cảm thấy họ không có đủ thời gian để làm việc với các nhà phân tích yêu cầu, những người thu thập, phân tích và tài liệu hoá các yêu cầu. Đôi khi khách hàng kỳ vọng các nhà phân tích hoặc các nhà phát triển phác ra cái người dùng cần mà không phải mất nhiều thời gian để thảo luận và tài liệu hoá. Nếu chỉ thế thôi thì dễ. Nếu doanh nghiệp của bạn phụ thuộc nhiều vào sự thành công của việc ứng dụng một phần mềm nào đó thì bạn phải chấp nhận mất nhiều thời gian để làm việc với các nhà phân tích hệ thống.

Tình trạng sẽ hơi khác đối với việc phát triển các phần mềm thương mại (các phần mềm đóng gói), khi đó khách hàng (customer) và người dùng (user) chỉ là một người. Các đại diện cho khách hàng, ví dụ bộ phận marketing của chính doanh nghiệp của bạn, sẽ phải cố gắng xác định cái gì khiến cho những người thanh toán tiền cảm thấy thích thú từ sản phẩm phần mềm doanh nghiệp bạn làm ra. Thậm chí đối với các phần mềm thương mại, chính bạn phải trở thành người dùng và Chương 7 sẽ nói chi tiết về việc này, nếu không thì bạn hãy chuẩn bị tinh thần đọc những đánh giá trên các tạp chí chuyên ngành về các hạn chế của phần mềm của bạn.

II. SỰ CỘNG TÁC KHÁCH HÀNG – NHÀ PHÁT TRIỂN (THE CUSTOMER – DEVELOPER PARTNERSHIP)

Các sản phẩm phần mềm chất lượng cao thường là kết quả của các thiết kế được thực thi tốt trên cơ sở các yêu cầu tuyệt hảo. Các yêu cầu như vậy là kết quả của việc cộng tác và truyền thông tốt giữa nhà phát triển và khách hàng.

Dự luật Yêu cầu về Quyền của Khách hàng Phần mềm (Requirements Bill of Rights for Software Customers) liệt kê ra 10 kỳ vọng của khách hàng đối với nhà phân tích và nhà phát triển trong các hoạt động của quy trình yêu cầu. Mỗi trong số các quyền đó ngụ ý một trách nhiệm tương ứng về phía nhà phát triển và nhà phân tích. Dự luật Yêu cầu về Trách nhiệm của Khách hàng Phần mềm (Requirements Bill of Responsibilities for Software Customers) liệt kê ra 10 trách nhiệm của khách hàng đối với nhà phát triển trong quy trình yêu cầu. Nếu bạn thích, bạn có thể gọi đó là dự luật về quyền của nhà phát triển.

DỰ LUẬT YÊU CẦU VỀ QUYỀN CỦA KHÁCH HÀNG PHẦN MỀM
Nếu bạn là Khách hàng Phần mềm thì bạn có quyền:
  1. Kỳ vọng nhà phân tích nói bằng ngôn ngữ của bạn.
  2. Kỳ vọng nhà phân tích nắm được nghiệp vụ kinh doanh và mục tiêu mà bạn đặt ra cho hệ thống.
  3. Kỳ vọng nhà phân tích cấu trúc hoá được thông tin mà bạn cung cấp thành một bản đặc tả yêu cầu phần mềm thành văn.
  4. Đề nghị nhà phát triển diễn giải cho bạn tất cả các bán thành phẩm được tạo ra trong quy trình yêu cầu.
  5. Kỳ vọng nhà phát triển có thái độ tôn trọng và duy trì sự hợp tác với bạn trong suốt quá trình làm việc chung.
  6. Đề nghị nhà phát triển cung cấp cho bạn tất cả các ý tưởng và các lựa chọn mà anh ta có thể có về yêu cầu và sự thi công hệ thống từ các yêu cầu đó.
  7. Mô tả các đặc tính của sản phẩm khiến cho nó dễ sử dụng và thân thiện hơn với người dùng.
  8. Có cơ hội điều chỉnh các yêu cầu nhằm có thể sử dụng lại các software components mà bạn đã có.
  9. Có được các ước lượng tương đối tốt về chi phí, ảnh hưởng và các đánh đổi (trade-offs) khi bạn đề nghị một thay đổi trong số các yêu cầu.
  10. Nhận được một hệ thống đáp ứng các nhu cầu của bạn về chức năng và chất lượng, đáp ứng sự mở rộng các nhu cầu đã được trao đổi và thoả thuận với nhà phát triển.

DỰ LUẬT YÊU CẦU VỀ TRÁCH NHIỆM CỦA KHÁCH HÀNG PHẦN MỀM
Nếu bạn là Khách hàng Phần mềm thì bạn có trách nhiệm:
  1. Giúp nhà phân tích hiểu về nghiệp vụ kinh doanh của bạn và định nghĩa các biệt ngữ nghiệp vụ (business jargon) cho họ hiểu.
  2. Sẵn sàng tiêu tốn thời gian để cung cấp yêu cầu, làm sáng tỏ chúng và bổ sung chúng thường xuyên.
  3. Cụ thể và chính xác khi cung cấp nguồn gốc của yêu cầu.
  4. Ra quyết định đúng lúc về các công việc liên quan đến yêu cầu khi có đề nghị.
  5. Tôn trọng sự đánh giá của nhà phát triển về chi phí và tính khả thi của yêu cầu.
  6. Thiết lập ưu tiên cho các yêu cầu riêng lẻ, các tính năng hệ thống hoặc các tình huống sử dụng (use cases).
  7. Soát xét các tài liệu yêu cầu và các nguyên mẫu (prototypes).
  8. Truyền thông cho các bên liên quan về các thay đổi của yêu cầu ngay khi bạn biết được các thay đổi đó.
  9. Tuân thủ quy trình đã được định nghĩa của công ty phát triển sản phẩm khi đề xuất các thay đổi yêu cầu.
  10. Tôn trọng các quy trình mà nhà phát triển sử dụng cho công nghệ yêu cầu.

Các quyền và trách nhiệm trên được áp dụng trực tiếp đối với khách hàng trong các hợp đồng làm phần mềm đặt hàng riêng, với các phần mềm loại này, công ty sản xuất phần mềm đã biết chính xác khách hàng là ai. Còn trường hợp phát triển các sản phẩm cho thị trường đại chúng (mass market) thì quyền và trách nhiệm được áp dụng cho các đại diện của khách hàng như bộ phận marketing chẳng hạn.

Khi lập kế hoạch dự án, khách hàng và nhà phát triển cần phải soát xét kỹ 2 danh sách này để định ra một quy tắc làm việc chung. Các khách hàng bận rộn có thể không thích bị cuốn vào quy trình công nghệ yêu cầu (như quy định của Trách nhiệm 2). Thiếu sự tham gia của khách hàng nhất định sẽ tăng nguy cơ sản xuất một sản phẩm sai. Hãy đảm bảo rằng tất cả những thành viên chính trong quy trình công nghệ yêu cầu đều hiểu và chấp nhận trách nhiệm của họ. Nếu phải đối mặt với một số điểm gây căng thẳng thì hãy đàm phán để đi đến hiểu biết chung. Sự hiểu biết chung này sẽ giảm các xích mích không đáng có khi một bên kỳ vọng vào một cái gì đó mà bên kia không mong muốn hoặc không thể đáp ứng.

Sau đây chúng ta sẽ xem xét kỹ hai dự luật trên.

1. DỰ LUẬT YÊU CẦU VỀ QUYỀN CỦA KHÁCH HÀNG PHẦN MỀM

Quyền 1: Kỳ vọng nhà phân tích nói bằng ngôn ngữ của bạn

Các thảo luận về yêu cầu cần tập trung vào các nghiệp vụ kinh doanh và các tác vụ của người dùng, trong khi thảo luận thì phải sử dụng từ vựng của chuyên ngành của bạn, bạn cần truyền đạt đến nhà phát triển đề nghị này. Bạn không cần phải hiểu về các biệt ngữ công nghệ thông tin khi trao đổi với nhà phân tích.

Quyền 2: Kỳ vọng nhà phân tích nắm được nghiệp vụ kinh doanh và mục tiêu mà bạn đặt ra cho hệ thống

Bằng cách tương tác, trao đổi với người dùng khi suy luận yêu cầu, nhà phân tích có thể hiểu tốt hơn nghiệp vụ của bạn và biết cách làm thế nào để làm ra sản phẩm thích hợp với bạn, đáp ứng tốt nhu cầu và sự kỳ vọng của bạn. Để giúp các nhà phát triển nắm vững nghiệp vụ của bạn, hãy mời họ đến quan sát những gì bạn và các đồng nghiệp của mình làm. Nếu hệ thống được xây dựng để thay thế ứng dụng đã có thì nhà phát triển phải sử dụng hệ thống hiện có như bạn đã sử dụng nó, điều đó giúp họ rút ra các kết luận bổ ích.

Quyền 3: Kỳ vọng nhà phân tích cấu trúc hoá được thông tin mà bạn cung cấp thành một bản đặc tả yêu cầu phần mềm thành văn

Nhà phân tích sẽ sắp xếp tất cả thông tin bạn và các khách hàng khác cung cấp nhằm phân loại nhu cầu người dùng thành các business requirements và các quy tắc (rules), các functional requirements, các mục tiêu chất lượng, các ý tưởng giải pháp và các thông tin khác. Sản phẩm cuối từ sự phân tích này là một đặc tả yêu cầu phần mềm (Software Requirement Specification, SRS). SRS cấu thành trên thoả thuận giữa nhà phát triển và khách hàng về nội dung của sản phẩm sẽ được xây dựng. SRS cần phải được cấu trúc và viết ra dưới dạng mà bạn có thể dễ dàng đọc và hiểu. Bạn có thể soát xét các đặc tả thành văn đó để đảm bảo chắc chắn rằng nó biểu diễn chính xác và đầy đủ các yêu cầu của bạn. Một SRS chất lượng cao thúc đẩy mạnh mẽ cơ hội xây dựng sản phẩm bạn thực sự muốn.

Quyền 4: Đề nghị nhà phát triển diễn giải cho bạn tất cả các bán thành phẩm được tạo ra trong quy trình yêu cầu

Nhà phân tích cần phải biểu diễn các yêu cầu bằng cách sử dụng nhiều sơ đồ khác nhau nhằm làm sáng tỏ hơn SRS. Các sơ đồ đó thật sự có giá trị trong việc biểu diễn một số hành vi của hệ thống, ví dụ các luồng công việc (workflows). Có thể bạn không quen thuộc lắm với các sơ đồ nhưng bạn cũng không khó khăn lắm để hiểu nó. Bạn có thể đề nghị nhà phân tích giải thích mục đích của mỗi sơ đồ hoặc các bán thành phẩm (work products) khác dẫn xuất từ yêu cầu, ý nghĩa của các ký hiệu (notation) và làm thế nào để kiểm tra các sơ đồ nhằm tìm kiếm và loại bỏ lỗi và sự thiếu nhất quán.

Quyền 5: Kỳ vọng nhà phát triển có thái độ tôn trọng và duy trì sự hợp tác với bạn trong suốt quá trình làm việc chung

Các thảo luận về yêu cầu có thể được làm tốt dần nếu người dùng và nhà phát triển chưa nắm bắt được các yêu cầu ngay từ đầu. Làm việc nhóm cùng nhau sẽ khiến cả khách hàng và nhà phát triển đều hiểu vấn đề sâu hơn.

Quyền 6: Đề nghị nhà phát triển cung cấp cho bạn tất cả các ý tưởng và các lựa chọn mà anh ta có thể có về yêu cầu và sự thi công hệ thống từ các yêu cầu đó

Thông thường khách hàng đề xuất các ý tưởng về “yêu cầu” (“requirements” ideas) là các giải pháp có thể thực thi (possible implementation solutuions). Các nhà phân tích sẽ cố gắng tìm hiểu đằng sau các giải pháp đó để hiểu được các vấn đề nghiệp vụ thực sự và nhu cầu cần được chỉ mặt, đặt tên (nghĩa là cố gắng tìm hiểu mục đích nào mà khách hàng muốn đạt được sau khi thực hiện giải pháp đó – ND). Các nhà phân tích cần duyệt qua tất cả những gì mà hệ thống hiện tại không đáp ứng được các quy trình kinh doanh hiện thời, nhằm đảm bảo rằng sản phẩm làm ra vượt qua được các nhược điểm đó. Nhà phân tích là người hiểu được lĩnh vực nghiệp vụ (business domain, thuật ngữ chỉ miền ứng dụng của sản phẩm phần mềm, ví dụ tài chính là một business domain – ND) và có thể đề xuất các cải tiến cần thiết, đồng thời anh ta cũng có thể thêm vào phần mềm mới các tính năng có giá trị mà người dùng cũng chưa mường tượng ra được.

Quyền 7: Mô tả các đặc tính của sản phẩm khiến cho nó dễ sử dụng và thân thiện hơn với người dùng

Bạn có thể kỳ vọng các nhà phân tích hỏi bạn các đặc tính mà phần mềm cần có để nó dễ sử dụng hơn. Các đặc tính đó, hoặc các thuộc tính chất lượng, khiến cho phần mềm thân thiện hơn và giúp bạn hoàn thành các tác vụ (tasks) của mình chính xác và hiệu quả hơn. Ví dụ, khách hàng đôi khi hay nói rằng sản phẩm phải “thân thiện người dùng” (user-friendly) hoặc “ổn định” (robust), “hiệu quả “ (efficient), nhưng những yêu cầu như vậy không giúp gì nhiều cho nhà phát triển vì chúng khá cảm tính. Thay vì vậy, nhà phân tích cần cụ thể hoá thế nào thì được gọi là  “thân thiện người dùng” hoặc “ổn định”, “hiệu quả “ đối với khách hàng (Chương 11).

Quyền 8: Có cơ hội điều chỉnh các yêu cầu nhằm có thể sử dụng lại các software components mà bạn đã có

Yêu cầu thường cần một mức độ mềm dẻo nào đó. Nhà phân tích cần nhận thức được rằng các software components đang có đã đáp ứng một số nhu cầu hiện tại của bạn. Trong trường hợp đó, nhà phân tích cần đề xuất lựa chọn sửa đổi yêu cầu của bạn sao cho có thể sử dụng lại các components đã có trong hệ thống mới. Nếu bạn có thể điều chỉnh yêu cầu của mình sao cho nhu cầu vẫn được đáp ứng và sử dụng lại được các components đã có thì bạn sẽ tiết kiệm được nhiều thời gian và tiền bạc hơn. Một số yêu cầu phải khá mềm dẻo để bạn có thể sử dụng được các COTS components (là software components được các công ty phần mềm sản xuất sẵn và được thương mại hóa, ví dụ đối với lĩnh vực xây dựng thì gạch lát nền nhà là một dạng tương tự COST component – ND).

Quyền 9: Có được các ước lượng tương đối tốt về chi phí, ảnh hưởng và các đánh đổi (trade-offs) khi bạn đề nghị một thay đổi trong số các yêu cầu

Đôi khi người ta thực hiện các lựa chọn khác nhau khi chi phí giữa các lựa chọn là khác nhau. Cần có ước lượng về ảnh hưởng và chi phí của mỗi thay đổi được đề xuất đối với các yêu cầu để ra quyết định kinh doanh về các thay đổi này, nghĩa là nên lựa chọn thay đổi nào. Bạn có quyền kỳ vọng nhà phát triển đưa ra các ước lượng về ảnh hưởng, chi phí, và đánh đổi cho mỗi thay đổi. Nhà phát triển không được thổi phồng các chi phí được ước tính của một thay đổi vì lý do họ không muốn thực hiện sự thay đổi đó.

Quyền 10: Nhận được một hệ thống đáp ứng các nhu cầu của bạn về chức năng và chất lượng, đáp ứng sự mở rộng các nhu cầu đã được trao đổi và thoả thuận với nhà phát triển

Bất cứ ai cũng mong muốn kết quả này cho dự án. Kết quả này chỉ có thể hiện thực nếu nhà phát triển được biết tất cả thông tin về các lựa chọn và ràng buộc cho phép họ làm ra sản phẩm đáp ứng tốt nhu cầu của bạn.

2. DỰ LUẬT YÊU CẦU VỀ TRÁCH NHIỆM CỦA KHÁCH HÀNG PHẦN MỀM

Trách nhiệm 1: Giúp nhà phân tích hiểu về nghiệp vụ kinh doanh của bạn và định nghĩa các biệt ngữ nghiệp vụ cho họ hiểu

Nhà phân tích kỳ vọng bạn đào tạo cho anh ta về nghiệp vụ kinh doanh và các thuật ngữ bạn dùng. Việc này không hề giúp anh ta trở thành chuyên gia trong lĩnh vực của bạn, nó chỉ giúp anh ta hiểu được những gì bạn nói, hiểu được mục tiêu của bạn. Đừng kỳ vọng nhà phân tích có thể nắm bắt sâu sắc các khía cạnh đa dạng trong nghiệp vụ của bạn.

Trách nhiệm 2: Sẵn sàng tiêu tốn thời gian để cung cấp yêu cầu, làm sáng tỏ chúng và bổ sung chúng thường xuyên

Khách hàng là những người bận rộn và thường những ai liên quan nhiều nhất đến quy trình yêu cầu lại là người bận rộn nhất. Bạn hãy cố gắng dành thời gian tham gia các hội thảo, các phiên họp tập kích não (brainstorming), các buổi phỏng vấn, các hoạt động khác liên quan đến yêu cầu. Đôi khi nhà phân tích cho rằng anh ta hiểu một điểm nào đó trong số các công việc của bạn nhưng chỉ khi triển khai sâu hơn công việc thì anh ta lại có nhu cầu làm sáng sủa vấn đề hơn. Hãy kiên nhẫn với cách tiếp cận lặp trong việc phát triển và định nghĩa yêu cầu, cũng vì bản chất của sự truyền thông là phức tạp và vì sự thành công của dự án là quan trọng nhất.

Trách nhiệm 3: Cụ thể và chính xác khi cung cấp nguồn gốc của yêu cầu

Trình bày rõ, chính xác các yêu cầu là việc khó khăn, vì vậy bất cứ lúc nào nhà phân tích cũng cần gặp ai đó trong số khách hàng để được giúp đỡ phân giải các yêu cầu nhập nhằng và thiếu chính xác. Sẽ rất tuyệt vời để tạm đánh dấu TBD (đã được xác định – to be determined) trên một yêu cầu nào đó trong bản đặc tả yêu cầu, nghĩa là ta đã xác định các thông tin phụ cần thiết, các phân tích đối với yêu cầu đó – yêu cầu đó đã được hiểu rõ tại thời điểm ấy. Đôi khi, TBD được sử dụng trên một yêu cầu nào đó vì yêu cầu đó đã được xác định là rất khó khăn để phân giải và không ai muốn tiếp tục xử lý nó nữa.

Trách nhiệm 4: Ra quyết định đúng lúc về các công việc liên quan đến yêu cầu khi có đề nghị

Khi nhà phân tích phân giải yêu cầu thì anh ta phải đối mặt với nhiều lựa chọn và quyết định (choices and decisions), anh ta chỉ được chọn một với một chi phí tương ứng. Mỗi quyết định bao gồm phân giải các đề nghị thiếu nhất quán từ nhiều người dùng, thực hiện các đánh đổi giữa các thuộc tính chất lượng xung đột nhau, đánh giá sự chính xác của thông tin. Khách hàng chính là người ra quyết định tại mỗi thời điểm cần sự lựa chọn đó. Nhà phân tích thường phải chờ đợi quyết định của bạn tại mỗi thời điểm như vậy, tiến độ của dự án phụ thuộc một phần vào việc ra quyết định của bạn.

Trách nhiệm 5: Tôn trọng sự đánh giá của các nhà phát triển về chi phí và tính khả thi của yêu cầu

Tất cả chức năng của phần mềm đều có giá (price) và nhà phát triển là người ước lượng tốt nhất chi phí xây dựng chức năng đó (mặc dầu nhiều nhà phát triển không phải là một người ước lượng có kỹ năng). Một số tính năng mà bạn muốn thêm vào sản phẩm nhưng việc đó không khả thi về mặt kỹ thuật hoặc quá đắt để thực thi việc đó. Một số yêu cầu là phi thực tế trong điều kiện hiện tạo của doanh nghiệp của bạn. Nhà phát triển có thể là kẻ đưa tin xấu về tính khả thi hoặc chi phí của một yêu cầu nào đó, nhưng bạn nên tôn trọng lời nói của anh ta.

Đôi khi bạn có thể viết lại các yêu cầu theo một cách khiến chúng khả thi hoặc rẻ hơn. Ví dụ, yêu cầu “hệ thống phản ứng ngay lập tức” không khả thi nhưng nếu bạn viết yêu cầu “hệ thống phản ứng trong vòng 50 mili giây” thì lại khả thi.

Trách nhiệm 6: Thiết lập ưu tiên cho các yêu cầu riêng lẻ, các tính năng hệ thống hoặc các tình huống sử dụng (use cases)

Phần lớn các dự án không có thời gian hoặc tài nguyên để thực thi tất cả các yêu cầu cùng một lúc. Hãy xác định tính năng nào là quan trọng, cơ bản để xác định thứ tự ưu tiên trong việc xây dựng hệ thống. Bạn chính là người đưa ra thứ tự ưu tiên này vì nhà phát triển không thể làm điều đó từ góc độ của anh ta được. Nhà phát triển sẽ cung cấp thông tin chi phí và rủi ro của mỗi yêu cầu nhằm giúp bạn định nghĩa thứ tự này. Khi bạn đã thiết lập thứ tự ưu tiên này, bạn đã đảm bảo nhà phát triển chuyển giao cho bạn sản phẩm với giá trị lớn nhất, chi phí thấp nhất và tại thời điểm hợp lý nhất.

Thứ tự ưu tiên này giúp bạn dễ co giãn được phạm vi dự án tại từng thời điểm nhất định căn cứ trên nhu cầu thực tế của doanh nghiệp, trên thời gian và ngân sách của doanh nghiệp.

Trách nhiệm 7: Soát xét các tài liệu yêu cầu và các nguyên mẫu (prototypes)

Như bạn sẽ thấy trong Chương 14, hoạt động soát xét (reviews) tài liệu yêu cầu là một trong số các hoạt động có giá trị nhất ảnh hưởng đến chất lượng phần mềm. Khách hàng cần tham gia vào hoạt động này vì đó là cách duy nhất để đánh giá liệu bản mô tả yêu cầu đã xác định các đặc tính của phần mềm một cách đầy đủ, đúng đắn và cần thiết hay chưa. Mỗi phiên soát xét sẽ là một cơ hội cho các đại diện của khách hàng phản hồi cho các nhà phân tích về công việc của họ, liệu họ đã đáp ứng đúng nhu cầu dự án chưa. Nếu bạn không tin tài liệu yêu cầu là chính xác, hãy nói với người có trách nhiệm càng sớm càng tốt và đưa ra các đề nghị cải tiến.

Rất khó khăn để có thể phác ra một bức tranh sống động về hoạt động của phần mềm chỉ bằng cách đọc một đặc tả yêu cầu. Để hiểu tốt hơn nhu cầu của bạn và đề xuất những cách tốt nhất để đáp ứng các nhu cầu đó, nhà phát triển thường xây dựng các nguyên mẫu (tương tự bây giờ khi bán căn hộ chung cư cho khách hàng, công ty xây dựng cho khách hàng xem căn hộ mẫu trước – ND) cho sản phẩm mong muốn. Phản hồi của bạn về nguyên mẫu sẽ cung cấp các thông tin rất giá trị cho nhà phát triển và giúp họ hiểu tốt hơn yêu cầu. Nguyên mẫu không phải là một sản phẩm thực sự và nhà phát triển cũng không biến đổi nguyên mẫu thành hệ thống đầy đủ được.

Trách nhiệm 8: Truyền thông cho các bên liên quan các thay đổi về yêu cầu ngay khi bạn biết được các thay đổi đó

Sự thay đổi liên tục của yêu cầu gây ra rủi ro nghiêm trọng đối với nhà phát triển trong việc chuyển giao một sản phẩm chất lượng cao cho khách hàng với một lịch biểu đã định. Thay đổi là không thể tránh khỏi, nhưng càng về cuối chu trình phát triển thì một thay đổi càng ảnh hưởng nhiều, chúng khiến nhiều công việc phải làm lại và chi phí phát sinh là rất lớn. Vậy hãy thông báo cho nhà phát triển ngay khi bạn thấy cần thay đổi yêu cầu, thông báo càng sớm càng tốt.

Trách nhiệm 9: Tuân thủ quy trình đã được định nghĩa của công ty phát triển sản phẩm khi đề xuất các thay đổi yêu cầu

Để tối thiểu hoá các ảnh hưởng tiêu cực của thay đổi, tất cả những người tham gia dự án đều phải tuân theo quy trình kiểm soát thay đổi đã được định nghĩa của dự án. Điều này đảm bảo các thay đổi đề xuất không bị mất tích, các ảnh hưởng của thay đổi được phân tích đầy đủ và được cân nhắc theo một cách nhất quán.  (Trong các dự án phần mềm, các thay đổi yêu cầu rất hay bị mất tích, tuần trước rõ ràng đã sửa chức năng đó theo yêu cầu được thay đổi rồi nhưng tuần sau cập nhật phiên bản mới lại thấy chức năng đó vẫn như cũ, chưa hề được sửa –ND).

Trách nhiệm 10: Tôn trọng các quy trình mà nhà phát triển sử dụng cho công nghệ yêu cầu

Thu thập yêu cầu và đảm bảo chúng đúng đắn là thách thức lớn nhất của phát triển phần mềm. Có một sự hợp lý ẩn đằng sau cách tiếp cận xây dựng yêu cầu của nhà phân tích. Mặc dù bạn vẫn có thể bổ sung và làm mịn các yêu cầu trong giai đoạn sau nhưng thời gian tiêu tốn cho giai đoạn phát triển yêu cầu thật sự là một khoản đầu tư hữu ích. Quy trình thu thập yêu cầu sẽ bớt chông gai hơn nếu bạn hiểu và tôn trọng các kỹ thuật nhà phân tích dùng để thu thập, tài liệu hoá và đảm bảo chất lượng yêu cầu. Hãy cứ đề nghị nhà phân tích diễn giải cặn kẽ cho bạn tất cả những gì bạn chưa rõ trong quy trình yêu cầu đó.

III. DẤU HIỆU DỪNG LẠI LÀ GÌ? (WHAT ABOUT SIGH-OFF?)

Đạt được thoả thuận về yêu cầu là một phần quan trọng trong sự cộng tác giữa khách hàng – nhà phát triển. Nhiều tổ chức sử dụng khái niệm “signing off” để chỉ việc khách hàng chấp nhận và thông qua văn bản yêu cầu. Điều quan trọng là tất cả những người tham gia quy trình chấp thuận yêu cầu (requirements approval process) phải biết chính xác sign-off nghĩa là gì.

Quá trình thu thập và phân tích yêu cầu tạm thời dừng lại khi nhà phát triển và khách hàng thống nhất được một ranh giới (baseline) của bản đặc tả yêu cầu. Khi ký xác nhận ranh giới đó thì bạn cần thêm vào SRS đoạn văn sau: “Tôi xác nhận rằng tài liệu mô tả yêu cầu này là hiểu biết tốt nhất của chúng tôi về các yêu cầu phần mềm cho dự án tính đến ngày hôm nay. Các thay đổi tương lai đối với ranh giới này sẽ được thực hiện thông qua quy trình thay đổi đã được định nghĩa của dự án. Tôi nhận thức rằng các thay đổi đã được chấp thuận này có thể vẫn khiến chúng tôi đàm phán lại các cam kết về chi phí, nguồn lực, lịch biểu của dự án.”

Các bước tiếp theo
  • Xác định các khách hàng cá nhân có trách nhiệm cung cấp business requirements và user requirements trong dự án của bạn. Mỗi mục nào trong trong Bill of Rights và Bill of Responsibilities đã được chấp thuận, được hiểu, được thực hiện bởi các khách hàng đó? Mục nào không?
  • Hãy thảo luận về Bill of Rights và Bill of Responsibilities với các khách hàng chính để đạt được sự thoả thuận trách nhiệm nào sẽ được chấp thuận và họ cảm thấy gì khi không nhận được một quyền nào đó. Dựa vào đó hãy đề ra các biện pháp cải thiện tốt hơn quan hệ cộng tác Khách hàng – Nhà phát triển.
  • Nếu bạn là một khách hàng tham gia vào một dự án phần mềm và bạn không cảm thấy các quyền của bạn được tôn trọng thì hãy thảo luận về Bill of Rights với các nhà phát triển. Hãy xác nhận trách nhiệm của mình trong Bill of Responsibilities để từ đó đề nghị họ thực hiện trách nhiệm của họ.

(Còn tiếp)

08/10/2009

Advertisements

6 phản hồi

Filed under Quản lý yêu cầu phần mềm, Tủ sách Công nghệ thông tin

6 responses to “Software Requirements. First Edition – MS Press. Chương 2: Yêu cầu từ góc nhìn của khách hàng

  1. ban_mai

    Anh dich hay lắm,hy vong anh có thể dịch hết cuốn sách này nhỉ

  2. sata2009blog

    Chào ban_mai, nghe tên bạn tôi lại nhớ đến truyện ngắn “Ban mai yên ả”. Cám ơn bạn đã động viên!

  3. nguyễn đức báu

    hiii,cái này rất rất bổ ích với em,do em đang học phân tích và quản lý yêu cầu phần mềm mà ko có tài liệu tiếng việt nào hay cả,cái này quá tuyệt vời,cảm ơn anh nhiều lắm

  4. sata2009blog

    Cám ơn em, nội dung yêu cầu phần mềm sẽ được đưa lên chi tiết nhất có thể. Satablog2 sau này sẽ đăng thêm những nội dung khác thiết thực liên quan đến công nghệ phần mềm, cả lý thuyết và kinh nghiệm thực tế, ví dụ đo lường phần mềm, quản trị dự án IT chẳng hạn.

  5. Diệp Lan Quỳnh

    Em đọc và thấy rất bổ ích,cảm ơn anh vì sự chia sẻ này ,nhưng em chỉ thấy mới chương 5 thôi còn những chương sau em ko thấy đâu cả! Hi vọng anh có thể dịch đầy đủ và up lên website này càng sớm càng tốt anh nhé!

  6. sata2009blog

    Bản dịch đầy đủ đã được đưa lên satablog2, bạn có thể tải về. Cám ơn bạn nhé.

Trả lời

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Log Out / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Log Out / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Log Out / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Log Out / Thay đổi )

Connecting to %s