Software Requirements. First Edition – MS Press. Chương 1: Cơ bản về yêu cầu phần mềm

Tác giả: Karl E. Wiegers

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

Lời người dịch
Chương này mở đầu bằng một tình huống mà bất cứ ai làm các dự án phần mềm cũng có thể đã gặp, tác giả dẫn dắt ra những hệ lụy khi phát triển phần mềm mà không có được đầy đủ, chính xác yêu cầu đầu vào. Tác giả đặt vấn đề như vậy nghĩa là sẽ chỉ cho độc giả một lối ra – lối ra đó là quy trình yêu cầu hay còn được gọi là công nghệ yêu cầu, tức là một dãy các bước cần thực hiện để làm ra cái được gọi là “yêu cầu phần mềm”.

Trước hết là một định nghĩa về khái niệm “yêu cầu” của IEEE – trong đó yêu cầu được nhìn từ cả hai phía: khách hàng và người phát triển hệ thống. Tác giả nhấn mạnh rằng yêu cầu thật sự chỉ nằm trong tâm trí khách hàng, những lời thể hiện yêu cầu, đặc tả yêu cầu chỉ là sự thể hiện ra bên ngoài của yêu cầu mà thôi, vì vậy sự thể hiện này có thể đúng, gần đúng hoặc sai so với những gì khách hàng thật sự mong muốn. Tiếp theo tác giả diễn giải 3 mức từ trừu tượng đến cụ thể hơn của yêu cầu: từ yêu cầu kinh doanh dẫn tới yêu cầu người dùng, từ yêu cầu người dùng dẫn tới yêu cầu chức năng và phi chức năng. Tiếp nữa tác giả trình bày các đặc tính của yêu cầu tuyệt vời (excellent requirements) thông qua lời thể hiện yêu cầu (requirement statement) – là yêu cầu trực tiếp từ khách hàng và người dùng được thể hiện bằng ngôn ngữ viết tự nhiên, đặc tả yêu cầu (requirement specification) – là lời thể hiện yêu cầu được viết lại bằng một ngôn ngữ đã được chuẩn hóa theo cách nào đó, theo khuôn mẫu nào đó.

Cuối chương, tác giả phân biệt sự khác nhau giữa 2 giai đoạn trong quy trình yêu cầu là phát triển yêu cầu (trình bày trong phần II cuốn sách) và quản lý yêu cầu (trình bày trong phần III cuốn sách). Sự phân biệt này rất quan trọng trong thực tế hoạt động của các dự án phần mềm.

“Xin chào, Phill? Tôi là Maria ở Bộ phận Nguồn nhân lực. Chúng tôi đang có vấn đề về hệ thống nhân lực mà anh đã lập trình cho chúng tôi. Một nhân viên vừa mới thay đổi tên của cô ta thành Sparkle Starlight và chúng tôi không thể khiến cho hệ thống chấp nhận tên thay đổi này. Giúp tôi được không?”

“Cô ta vừa cưới một gã tên là Starlight à?”

“Không, cô ta không cưới chồng, chỉ thay đổi tên thôi,”, Maria đáp. “Đó mới là vấn đề. Hệ thống chỉ chấp nhận ai đó thay đổi tên nếu họ thay đổi tình trạng hôn nhân của mình.”

“Ồ, tôi chưa bao giờ nghĩ rằng có ai đó lại thay đổi tên của mình. Tôi không thấy chị nói với tôi về việc này khi chúng ta trao đổi với nhau về hệ thống trước đây. Đó là lý do chị không thể nhấn vào hộp thoại Change Name nếu trước đó không nhấn vào hộp thoại Change Marital Status,” Phill nói.

Maria nói, “Tôi nghĩ anh biết mọi người đều có thể thay đổi tên của mình một cách hợp pháp bất cứ lúc nào nếu họ thích. Thêm nữa, chúng tôi phải khoá sổ vào thứ 6 tới nhưng Sparkle không thể thanh toán được hoá đơn của cô ấy. Có thể giúp tôi sửa lỗi (bug) này không?”

“Đó không phải là lỗi! Tôi không hề biết là chị cần tính năng này. Tôi bận vào vụ hệ thống đánh giá hiệu suất mới rồi. Tôi nghĩ tôi có một số đề nghị thay đổi khác cho hệ thống nhân lực đây,” [tiếng giấy sột soạt], “Đây rồi. Tôi có thể cố định chức năng khoá sổ vào cuối tháng chứ không phải cuối tuần. Xin lỗi nhé. Lần tới, hãy nói những thứ đó cho tôi sớm hơn và làm ơn ghi ra giấy.”

“Vậy tôi có thể giúp gì cho Sparkle đây”, Maria vặn hỏi, “Cô ấy không thể thực hiện công việc được nếu không thanh toán được hoá đơn.”

“Ồ, Maria, đó không phải lỗi của tôi.” Phill nói. “Nếu cô nói trước với tôi cái vụ thay đổi tên đó thì mọi việc đã xuôi chèo mát mái. Cô không thể xử lý tôi vì tôi không đọc được ý nghĩ của cô.”

Giận dữ Maria nặng lời, “Ồ, thế cơ đấy, đây chính là lý do làm tôi ghét máy tính. Hãy gọi lại tôi càng sớm càng tốt để sửa cái này.”

Nếu bạn đã từng trao đổi với khách hàng như trên thì bạn biết khách hàng sẽ rắc rối như thế nào nếu phải sử dụng các phần mềm không thể thực hiện được các tác vụ cơ bản. Còn về phía bạn, bạn đã thấy mọi việc rối tinh ra sao nếu nhận được mong muốn của khách hàng đối với hệ thống sau khi hệ thống đã được cài đặt. Cũng thật bực bội nếu bạn phải sửa hệ thống ngay trong khi bạn đang xây dựng hệ thống đúng như những gì bạn đã được nghe từ lúc đầu.

Nhiều vấn đề nảy sinh trong khi phát triển phần mềm có thể có nguồn gốc từ quy trình và từ sự thực hiện các quy trình đó trong việc thu thập, tài liệu hoá, thoả thuận và lựa chọn các yêu cầu phần mềm. Như câu truyện trên, miền thông tin thu thập có thể gồm cả những gì không được nói ra, không được ghi nhận, không được thoả thuận.

Khi xây dựng một ngôi nhà, phần lớn trong số chúng ta đều trao đổi với nhà thầu về nhu cầu và mong muốn của chúng ta từ đó ước tính chi phí. Tuy vậy, phần lớn trong số đó lại không làm như vậy khi đặt hàng một sản phẩm phần mềm. Khoảng từ 40% đến 60% các lỗi xuất hiện là do không tìm hiểu kỹ bài toán trong khâu yêu cầu (Leffingwell 1997). Nhiều tổ chức vẫn ứng dụng các phương pháp theo kiểu thuận tiện, có sao thì làm vậy (ad hoc) để làm yêu cầu. Kết quả đạt được là một sự vênh nhau giữa cái khách hàng nghĩ là chúng ta sẽ xây dựng cho họ và cái mà chúng ta nghĩ chúng ta đang làm cho khách hàng.

Do yêu cầu là đầu vào của quy trình sản xuất phần mềm và mọi hoạt động quản lý dự án, nên tất cả những người liên quan cần phải đồng thuận trong một quy trình làm yêu cầu (còn gọi là công nghệ yêu cầu – ND) hiệu quả. Chương này giúp bạn:

  • Hiểu một số khái niệm chính trong việc phát triển yêu cầu phần mềm.
  • Có hiểu biết về một số vấn đề liên quan đến yêu cầu có thể nảy sinh trong một dự án phần mềm.
  • Tìm hiểu về một số đặc tính mà một yêu cầu tuyệt vời hoặc một đặc tả yêu cầu cần phải có.
  • Nhận biết sự khác nhau giữa phát triển yêu cầu và quản lý yêu cầu.

I. ĐỊNH NGHĨA YÊU CẦU PHẦN MỀM (SOFTWARE REQUIREMENTS DEFINED)

Một khó khăn đối với ngành công nghiệp phần mềm là thiếu các định nghĩa chung về các khái niệm mà chúng ta sử dụng để mô tả các công việc, một trong số đó là định nghĩa khái niệm “requirement”. Định nghĩa này cần đáp ứng cho nhiều đối tượng liên quan khác nhau như: developers, customers, others (người phát triển, khách hàng, người khác – Một số thuật ngữ sẽ được để nguyên tiếng Anh – ND).

The IEEE Standard Glossary of Software Engineering Technology (1997) định nghĩa một yêu cầu là:
(1)   Một điều kiện (condition) hoặc một công năng (capability) của sản phẩm phần mềm cần thiết cho người dùng để giải quyết một vấn đề hoặc để đạt được một mục tiêu.

(2)   Một điều kiện hoặc một công năng cần phải thỏa mãn hoặc cần phải có của một hệ thống hoặc một thành phần hệ thống (system component) nhằm đáp ứng một hợp đồng, một tiêu chuẩn, một đặc tả hoặc một tài liệu bắt buộc khác.

(3)   Một sự diễn giải (representation) được ghi thành tài liệu của một điều kiện hoặc một công năng theo 1 hoặc 2.

1. MỘT SỐ DIỄN GIẢI VỀ “YÊU CẦU” (SOME INTERPRETATIONS OF “REQUIREMENTS”)

Định nghĩa của IEEE bao hàm cả 2 quan điểm về yêu cầu từ người dùng (quan sát hành vi của hệ thống từ bên ngoài) và từ người phát triển (quan sát hệ thống từ bên trong).

Một trong các yếu tố quan trọng của requirements là cần được tài liệu hoá. Tôi đã làm việc trong một dự án mà tại đó developers bị quay như chong chóng. Khách hàng chính phát hoảng khi người phân tích yêu cầu mới đến và nói: “Chúng tôi cần trao đổi về yêu cầu của anh.” Khách hàng phản ứng lại: “Tôi đã đưa cho người tiền nhiệm của anh yêu cầu rồi.” Thực tế thì không có yêu cầu nào được tài liệu hoá, vì vậy mỗi người phân tích mới đã phải bắt đầu từ một đống lộn xộn.

Thường thì bạn đã có “yêu cầu” rồi nếu bạn có được các emails, voice-mails, các ghi chú, các cuộc gặp gỡ ngắn, các tập hợp giấy tờ linh tinh từ các cuộc họp với người dùng.

Một định nghĩa khác gợi ý rằng yêu cầu là “các phát biểu về nhu cầu (need) của người dùng làm điểm xuất phát cho sự phát triển một chương trình hoặc một hệ thống” (Jones 1994). Chuyên gia về yêu cầu Alan Davis (1993) đã mở rộng khái niệm này thành “một nhu cầu của người dùng hoặc một đặc tính, một chức năng, một thuộc tính cần thiết của một hệ thống có thể được hiểu từ một vị trí bên ngoài hệ thống đó”. Các định nghĩa này nhấn mạnh cái mà sản phẩm phải cung cấp thay vì sản phẩm sẽ được làm như thế nào từ góc nhìn của người thiết kế và thi công.

Định nghĩa sau đi xa hơn: từ nhu cầu người dùng tới các đặc tính (characteristic) của hệ thống (Sommerville and Sawyer 1997):

Yêu cầu là… một đặc tả về cái phải được thi công. Chúng là các mô tả về hành vi của hệ thống phải như thế nào, hoặc về một thuộc tính của hệ thống phải như thế nào. Yêu cầu có thể là một ràng buộc về quy trình phát triển của hệ thống.

Các định nghĩa đa dạng trên chỉ ra rằng không có cách hiểu sáng sủa, không nhập nhằng về khái niệm “yêu cầu”. Yêu cầu thật sự thường tồn tại trong tâm trí con người. Bất cứ hình thức tài liệu hoá nào về yêu cầu (ví dụ đặc tả yêu cầu) cũng chỉ là một mô hình, một sự trình bày ra bên ngoài về yêu cầu mà thôi (Lawrence 1998). Chúng ta cần đảm bảo rằng tất cả những người liên quan của dự án đều có một cách hiểu chung về các khái niệm được dùng để mô tả các yêu cầu.

2. CÁC MỨC CỦA YÊU CẦU (LEVELS OF REQUIREMENTS)

Các định nghĩa sau mà tôi sẽ sử dụng đối với một số khái niệm chung, bạn sẽ thường gặp chúng trong lĩnh vực công nghệ yêu cầu.

Yêu cầu phần mềm gồm 3 mức phân biệt – yêu cầu kinh doanh (business requirements, BR), yêu cầu người dùng (user requirements, UR), yêu cầu chức năng (functional requirements, FR) hoặc yêu cầu phi chức năng (NFR).

  • BR biểu diễn các mục tiêu ở mức cao của tổ chức hoặc của khách hàng đối với hệ thống. Chúng được trích ra (capture) từ một tài liệu mô tả tầm nhìn (vision) và phạm vi (scope) của dự án.
  • UR mô tả các tác vụ (task) mà người dùng phải hoàn thành bằng cách sử dụng hệ thống như một công cụ làm việc. Chúng được trính ra trong các mô tả tình huống sử dụng (use case) hoặc kịch bản sử dụng.
  • FR định nghĩa chức năng của phần mềm mà người phát triển cần phải đưa vào sản phẩm để người dùng hoàn thành tác vụ của họ, do đó mà đáp ứng các yêu cầu kinh doanh (BR). Một tính năng (feature) là một tập hợp logic các yêu cầu chức năng có liên quan lẫn nhau nhằm cung cấp cho người dùng khả năng (capability) đáp ứng một yêu cầu kinh doanh. Xem Hình 1-1 về mối quan hệ giữa các mức của yêu cầu. FR được tài liệu hoá trong một đặc tả yêu cầu phần mềm (Software requirements specification, SRS), tài liệu này mô tả đầy đủ ở mức có thể hành vi mong muốn đối với hệ thống bằng một cái nhìn từ bên ngoài. SRS được sử dụng trong phát triển, kiểm thử, đảm bảo chất lượng, quản lý dự án và các công việc liên quan khác của dự án. Đối với các sản phẩm phức tạp, yêu cầu chức năng có thể là tập con của yêu cầu hệ thống, nếu một phần của yêu cầu chức năng đã được định vị thành các software components. Ngoài các FR, SRS còn chứa các yêu cầu phi chức năng. Đó là các tiêu chuẩn, quy định, khế ước mà sản phẩm phải tuân thủ; các mô tả của giao diện ngoài (external interface, nói thêm, giao diện trong là giao diện giữa các hệ thống với nhau); các yêu cầu hiệu suất (performance requirements); các ràng buộc về thiết kế và thi công; các thuộc tính chất lượng. Các ràng buộc (constraints) là các giới hạn được định ra trong miền chọn lựa khả năng của người phát triển khi thiết kế và thi công hệ thống. Các thuộc tính chất lượng là các mô tả về các thuộc tính của sản phẩm theo nhiều khía cạnh quan trọng với người dùng hoặc với người phát triển.
Fig 1-1
HÌNH 1-1. Quan hệ giữa một số thành phần của yêu cầu phần mềm.

Chúng ta lấy một chương trình xử lý từ làm ví dụ về các kiểu yêu cầu khác nhau. Một BR có thể viết: “Người dùng có thể sửa các lỗi chính tả (spelling errors) trong tài liệu một cách hiệu quả”. Như vậy, trong tài liệu hướng dẫn sử dụng sản phẩm cần ghi rằng một spelling checker được đưa vào sản phẩm – đó là tính năng đáp ứng BR này. Các UR tương ứng có thể mô tả (use case): “Tìm kiếm các spelling errors trong tài liệu và quyết định liệu có nên thay thế mỗi mispelled word bằng một từ đúng lựa ra từ một danh sách các từ được gợi ý”. Spelling checker có nhiều yêu cầu chức năng cụ thể như tìm kiếm và làm sáng (highlight) một misspelled word, hiển thị một dialog box với các từ thay thế được gợi ý…

Các nhà quản lý hoặc tiếp thị có thể định nghĩa các yêu cầu kinh doanh cho phần mềm, điều đó giúp công ty của họ hoạt động hiệu quả hơn (đối với các hệ thống thông tin) hoặc thành công trên thị trường (đối với các sản phẩm phần mềm thương mại). Tất cả các yêu cầu người dùng cần phải sóng đôi với các yêu cầu kinh doanh. Các yêu cầu người dùng giúp người phân tích cài đặt một phần chức năng (the bits of functionality) mong muốn trong sản phẩm nhằm giúp người dùng thực hiện tác vụ của họ. Người phát triển (developers) sử dụng các yêu cầu chức năng để thiết kế các giải pháp thực thi chức năng cần thiết.

Chú ý rằng yêu cầu, theo định nghĩa, không bao hàm các chi tiết thiết kế, các chi tiết thi công, thông tin lập kế hoạch dự án, hoặc thông tin kiểm thử. Hãy tách các thông tin đó ra khỏi yêu cầu sao cho yêu cầu chỉ chứa các thông tin hệ thống cần phải làm cái gì. Dự án cũng có thể có các kiểu yêu cầu khác nhau như yêu cầu về môi trường phát triển, yêu cầu về phát hành sản phẩm và thích ứng nó với môi trường hỗ trợ. Các kiểu yêu cầu đó có thể ảnh hưởng nghiêm trọng đến sự thành công của dự án nhưng trong cuốn sách này ta không xét đến chúng.

II. MỖI DỰ ÁN ĐỀU CÓ YÊU CẦU (EVERY PROJECT HAS REQUIREMENTS)

Fredrick Brooks xác định vai trò đặc biệt quan trọng của quy trình yêu cầu đối với các dự án phần mềm trong bài luận kinh điển năm 1987 của ông, “No Silver Bullet: Essence and Accidents of Software Engineering”:

Việc duy nhất khó khăn khi làm một hệ thống phần mềm là quyết định chính xác cái cần phải xây dựng. Không có công việc nào là khó khăn như thiết lập các yêu cầu kỹ thuật chi tiết, gồm tất cả giao diện với người dùng, giao diện với máy móc (machines) và với các hệ thống phần mềm khác. Không có công việc nào ảnh hưởng xấu đến hệ thống bằng công việc này nếu nó bị thực hiện sai. Không có công việc nào là khó khăn hơn công việc này nếu phải chỉnh sửa lại sau.

Mỗi hệ thống phần mềm có người dùng của riêng nó. Thời gian để tìm hiểu nhu cầu của họ là một khoản đầu tư then chốt khiến dự án thành công. Nhận định này là hiển nhiên đối với các ứng dụng đầu cuối thương mại, các hệ thống thông tin doanh nghiệp, các sản phẩm chứa các phần mềm nhúng. Nếu chúng ta, với tư cách là những người phát triển, không viết ra các yêu cầu để khách hàng có thể thảo luận về nó, thì làm sao chúng ta biết khi nào thì dự án thực hiện xong. Chúng ta có thể đáp ứng như thế nào cho khách hàng nếu không biết cái gì quan trọng đối với họ. Thậm chí đối với ngay cả các phần mềm phi thương mại thì các yêu cầu cũng cần phải được hiểu cho rõ. Ví dụ các thư viện phần mềm, các components, các tools được tạo ra cho các nhóm phát triển sử dụng.

III. KHI CÁC YÊU CẦU XẤU XẢY RA VỚI CON NGƯỜI TỐT (WHEN BAD REQUIREMENTS HAPPEN TO NICE PEOPLE)

Khi các nhóm dự án không quan tâm đến các quy trình yêu cầu thì họ sẽ khiến dự án lâm vào tình thế nguy hiểm, sự thành công của dự án là khó đảm bảo. Nếu “thành công” được hiểu là chuyển giao một sản phẩm đáp ứng các mong đợi của người dùng về chức năng, về chất lượng ở mức chi phí đã thoả thuận và trong một thời gian giới hạn. Một số rủi ro về yêu cầu sẽ được thảo luận dưới đây. Chương 5 sẽ thảo luận việc bạn có thể làm gì để tránh các rủi ro yêu cầu.

MỘT SỐ RỦI RO TỪ SỰ KHÔNG ĐẦY ĐỦ CỦA QUY TRÌNH YÊU CẦU (SOME RISKS FROM INADEQUATE REQUIREMENTS PROCESS)

  • Nếu các kiểu người dùng không được tính đến đầy đủ trong khi làm yêu cầu thì hệ thống có thể sẽ không được chấp nhận.
  • Việc phát sinh các yêu cầu không chính thức (creeping user requirements) góp phần làm hỏng và giảm chất lượng sản phẩm.
  • Các yêu cầu nhập nhằng dẫn tới tiêu phí nhiều thời gian để làm lại.
  • “Sự mạ vàng” (gold – plating) của người phát triển và người dùng sẽ thêm vào hệ thống các tính năng (features) không cần thiết.
  • Các đặc tả tối thiếu dẫn tới các yêu cầu chính bị thiếu hụt (missing key requirements).
  • Bỏ qua nhu cầu của một số kiểu người dùng nào đó sẽ dẫn tới sự không hài lòng của khách hàng.
  • Các yêu cầu được định nghĩa không đầy đủ khiến đòi hỏi lập kế hoạch dự án chính xác và giám sát là không thể.

Các kiểu người dùng không được tính đến đầy đủ (Insufficient user involvement)

Khách hàng thường không hiểu tại sao việc thu thập yêu cầu và đảm bảo chất lượng yêu cầu lại khó khăn đến thế. Người phát triển không thể nhấn mạnh đến sự tham gia của người dùng (user involvement), hoặc cũng có thể là làm việc với người dùng thì không vui như viết code, hoặc cũng có thể họ nghĩ họ đã biết cái người dùng cần. Trong một số trường hợp, trao đối trực tiếp với những người sẽ sử dụng sản phẩm không phải là điều dễ dàng, trong khi đó những người đại diện của khách hàng không phải bao giờ cũng hiểu được chính xác cái mà người dùng thật sự cần. Không có sự thay thế nào cho sự tham gia của các đại diện người dùng một cách trực tiếp trong nhóm dự án ngay từ sớm và kết hợp với họ liên tục trong suốt quy trình phát triển.

Việc phát sinh các yêu cầu không chính thức (Creeping user requirements)

Do các yêu cầu liên tục tiến hoá khi phát triển dự án, nên dự án luôn có thể vượt khỏi các lịch biểu và ngân sách đã định. Các dự án như vậy không phải luôn dựa trên sự hiểu biết thực tế về kích thước và độ phức tạp của các yêu cầu, các rủi ro, năng suất làm việc của dự án, việc sinh ra các yêu cầu không chính thức có thể gây ra các vấn đề to lớn. Vấn đề có thể phụ thuộc một phần vào đề nghị thay đổi yêu cầu của người dùng, phụ thuộc một phần vào cách những người phát triển đáp ứng các yêu cầu và chỉnh sửa mới.

Để quản lý việc sinh ra các yêu cầu không chính thức, chúng ta cần làm sáng sủa các báo cáo về tầm nhìn, phạm vi, mục tiêu, giới hạn và các tiêu chuẩn thành công của dự án. Báo cáo này sẽ được sử dụng như một khung tham chiếu mỗi khi một tính năng mới được đề nghị, hoặc các thay đổi yêu cầu được đề xuất. Một quy trình kiểm soát thay đổi được thiết kế tốt bao gồm việc phân tích ảnh hưởng của mỗi thay đổi được đề xuất, việc này sẽ giúp các người liên quan đề ra quyết định liệu thay đổi đó có được chấp nhận hay không trong sự cân bằng các chi phí, thời hạn, nguồn lực hoặc các tính năng khác.

Do các thay đổi có thể lan truyền trên toàn bộ sản phẩm đang được phát triển nên kiến trúc của hệ thống có thể bị phá vỡ dần dần. Các miếng vá sẽ khiến chương trình khó khăn hơn để hiểu và bảo trì. Sự liên quan lẫn nhau của các mã thêm vào (insertion of additional code) có thể gây ra các vấn đề đối với nguyên tắc thiết kế hệ thống bền vững. Nếu bạn có thể xác định sớm các tính năng có khả năng sẽ thay đổi theo thời gian thì bạn có thể thiết lập một kiến trúc bền vững cho hệ thống, do vậy mà kiểm soát được tốt hơn sự thay đổi. Các thay đổi yêu cầu nếu được thực hiện thông qua thay đổi thiết kế, thay vì phát hành các bản vá lỗi, thì sẽ giúp kiểm soát tốt hơn chất lượng sản phẩm.

Các yêu cầu nhập nhằng (Ambigous Requirements)

Sự nhập nhằng là khó khăn to lớn đối với việc đặc tả yêu cầu (Lawrence 1996). Sự nhập nhằng khiến cho những người đọc các báo cáo mô tả yêu cầu đi đến những cách hiểu khác nhau về cái mà phần mềm phải làm. Một dấu hiệu khác nữa của sự nhập nhằng là ngay cả một người đọc cũng có thể diễn giải một yêu cầu theo nhiều cách khác nhau.

Sự nhập nhằng dẫn tới các kỳ vọng (expectation) khác nhau từ người liên quan, một số trong họ sẽ ngạc nhiên về những gì được chuyển giao. Các yêu cầu nhập nhằng dẫn tới lãng phí thời gian khi các nhà phát triển cài đặt một giải pháp cho một vấn đề sai, khi các nhà kiểm thử kỳ vọng sản phẩm có những hành vi khác với những gì mà các nhà phát triển đã xây dựng. Trước đây, một nhà kiểm thử hệ thống đã nói với tôi rằng nhóm kiểm thử của cô thường diễn giải sai các yêu cầu, vì vậy đã phải viết lại nhiều test cases và lặp đi, lặp lại nhiều kiểm thử.

Kết quả không thể tránh được của sự nhập nhằng là phải làm lại công việc đã làm. Các công việc làm lại có thể tiêu tốn 40% tổng chi phí phát triển, 70% – 80% việc sửa lại được quy cho các lỗi yêu cầu (Leffingwell 1997).

Một cách để truy tìm sự nhập nhằng là có một nhóm đại diện cho nhiều quan điểm khác nhau thanh tra (inspect) các yêu cầu. Nếu mỗi người trong nhóm đó diễn giải một yêu cầu theo nhiều cách khác nhau thì đã có sự nhập nhằng trong báo cáo yêu cầu. Các kỹ thuật khác nhau để phát hiện sự nhập nhằng được mô tả bởi Gause và Weinberg (1989) trong phần sau của chương này.

Các tính năng không cần thiết (Unnecessary Features)

Mạ vàng (gold – plating) được hiểu là khuynh hướng một số nhà phát triển thêm một chức năng mới không có trong đặc tả yêu cầu nhưng họ lý giải rằng “người dùng sẽ thích nó”. Thường thì người dùng không tìm kiếm chức năng này và nguồn lực tiêu tốn để cài đặt nó đã bị lãng phí. Một cách làm mà những người phát triển thích hơn so với chỉ đơn giản thêm các tính năng mới là họ giới thiệu với khách hàng các ý tưởng, các lựa chọn và các cách tiếp cận sáng tạo nhằm giải quyết vấn đề của khách hàng. Quyết định về chức năng nào được thêm vào sẽ được tính toán cân bằng giữa điều khách hàng muốn và sự xem xét, cân nhắc về tính khả thi kỹ thuật, khung thời gian.

Để tối thiểu hoá nguy cơ mạ vàng, bạn cần giám sát tất cả các tính năng được thêm vào, mỗi tính năng cần phải có lý do chính đáng để được chấp nhận.

Đặc tả tối thiểu (Minimal Specification)

Đôi khi, khách hàng và các bên khác nhau (marketing, quản lý) không hiểu được taị sao phải nhấn mạnh các yêu cầu là quan trọng. Để tạo ra một đặc tả tối thiểu, có lẽ không gì hơn là vạch ra các ý tưởng về sản phẩm trên một tờ giấy mỏng và yêu cầu các nhà phát triển làm mịn, bổ sung nó khi dự án tiến triển trên thực tế. Một dấu hiệu xấu cuả việc này là các nhà phát triển viết các yêu cầu sau khi hoàn tất xây dựng sản phẩm. Cách làm này có thể thích hợp với các sản phẩm có tính cách thăm dò cao, hoặc khi mà các yêu cầu phải thật sự mềm dẻo (McConnell 1996). Trong phần lớn các trường hợp, cách làm này khiến các nhà phát triển thất bại (người có thể phải làm việc dưới các giả thiết sai và trong một định hướng hạn chế) và khách hàng thấy mình bị làm phiền (người nhận sản phẩm như họ đã mường tượng).

Bỏ qua nhu cầu của một số kiểu người dùng (Overlooked User Classes)

Phần lớn các sản phẩm được sử dụng bởi các nhóm người khác nhau, họ có thể sử dụng các tập con tính năng khác nhau, có tần suất sử dụng khác nhau, có kinh nghiệm và trình độ khác nhau. Nếu bạn không xác định tất cả các kiểu người dùng chính – các lớp người dùng (user classes) – của sản phẩm ngay từ sớm thì sẽ có ai đó trong số khách hàng không hài lòng khi sản phẩm được chuyển giao. Ví dụ, các xử lý sử dụng menu là không hiệu quả đối với những người dùng chuyên nghiệp, trong khi các câu lệnh và các phím tắt lại làm những người sử dụng không thường xuyên cảm thấy bối rối.

Lập kế hoạch không chính xác (Inaccurate Planning)

“Đây là ý tưởng của tôi về một sản phẩm mới; bạn có thể cho tôi xem ý tưởng về sân bóng chày khi nào bạn thực hiện nó?”. Nhiều nhà phát triển phải đối mặt với vấn đề khó khăn này. Sự thiếu hiểu biết về yêu cầu sẽ dẫn tới các ước lượng quá lạc quan về dự án. Năm nguyên nhân hàng đầu đã được tổng kết về các ước lượng chi phí phần mềm xa thực tế liên quan đến yêu cầu là: thay đổi yêu cầu thường xuyên, thiếu yêu cầu, truyền thông không đầy đủ về yêu cầu cho người dùng, đặc tả sơ sài về yêu cầu, phân tích yêu cầu không đầy đủ (Davis 1995).

IV. LỢI ÍCH TỪ MỘT QUY TRÌNH YÊU CẦU CHẤT LƯỢNG CAO (BENEFITS FROM A HIGH – QUALITY REQUIREMENTS PROCESS)

Các tổ chức sử dụng các quy trình công nghệ yêu cầu hiệu quả có thể vui lòng với nhiều lợi ích thu được. Có lẽ phần thưởng lớn nhất là giảm được các công việc phải làm lại trong giai đoạn phát triển và giai đoạn bảo trì dài. Boehm (1981) phát hiện ra rằng việc sửa một lỗi yêu cầu sau khi sản phẩm đã được phát hành tốn kém gấp 68 lần so với sửa yêu cầu đó ngay trong giai đoạn yêu cầu. Các nghiên cứu gần đây cho biết yếu tố khuếch đại chi phí này có thể là 200 lần. Hiệu quả của việc làm các yêu cầu chất lượng cao ngay từ đầu không phải là rõ ràng với nhiều người, họ chỉ đơn giản cho rằng thời gian tiêu phí cho giai đoạn yêu cầu sẽ làm chậm thời điểm bàn giao sản phẩm cho khách hàng.

Quy trình yêu cầu hiệu quả nhấn mạnh cách tiếp cận hợp tác khi xây dựng sản phẩm, quy trình này liên quan đến nhiều người liên quan khác nhau của dự án. Tập hợp các yêu cầu cho phép nhóm dự án hiểu tốt hơn thị trường của sản phẩm, một yếu tố thành công then chốt của bất cứ dự án nào. Cuối cùng, các yêu cầu được tài liệu hoá và không nhập nhằng làm thuận tiện tối đa đối với việc kiểm thử hệ thống và tăng cơ hội chuyển giao một sản phẩm chất lượng cao đáp ứng mong đợi của tất cả những người liên quan.

V. ĐẶC TÍNH CỦA CÁC YÊU CẦU TUYỆT VỜI (CHARACTERISTICS OF EXCELLENT REQUIREMENTS)

Các đặc tính mà một báo cáo yêu cầu tốt cần tuân theo sẽ được thảo luận ở đây (Davis 1993; IEEE 1998). Việc xem xét cẩn thận SRS bởi những người liên quan đại diện cho những góc nhìn khác nhau là cách tốt nhất để xác định liệu các yêu cầu có đầy đủ các đặc tính cần thiết hay không. Nếu bạn lưu giữ các đặc tính đó trong tâm trí khi viết và soát xét các yêu cầu thì bạn sẽ có một thiết kế yêu cầu tốt hơn (mặc dù chả bao giờ hoàn hảo cả). Trong chương 9, bạn sẽ sử dụng các đặc tính này để tìm kiếm các vấn đề với một số báo cáo yêu cầu sao cho bạn có thể cải tiến chúng.

1. CÁC ĐẶC TÍNH CỦA LỜI THỂ HIỆN YÊU CẦU (REQUIREMENT STATEMENT CHARACTERISTICS)

Đầy đủ (Complete)

Mỗi yêu cầu cần mô tả đầy đủ chức năng được chuyển giao. Nó phải chứa tất cả các thông tin cần thiết để nhà phát triển thiết kế và thi công chức năng này.

Đúng đắn (Correct)

Mỗi yêu cầu cần mô tả chính xác chức năng được xây dựng. Sự đảm bảo cho tính đúng đắn đó là tham chiếu đến nguồn của yêu cầu, đó có thể là khách hàng hoặc một đặc tả yêu cầu hệ thống mức cao hơn. Một yêu cầu phần mềm mà xung đột với một yêu cầu hệ thống tương ứng thì là không đúng đắn. Chỉ sự trình bày của người dùng mới có thể xác định tính đúng đắn của yêu cầu người dùng, điều đó cho biết tại sao khi soát xét yêu cầu ta cần sự có mặt của chính người dùng hoặc người đại diện của họ. Soát xét yêu cầu mà không có mặt người dùng có thể khiến những người soát xét nói: “Điều này không có ý nghĩa. Đó có thể là suy diễn.”

Khả thi (Feasible)

Khả thi có nghĩa là thực thi mỗi yêu cầu trong các khả năng và giới hạn đã biết của hệ thống và môi trường hoạt động của hệ thống. Để tránh các yêu cầu không khả thi, cần một thành viên của nhóm dự án làm việc với các nhà marketing hoặc các nhà phân tích yêu cầu trong quá trình xử lý yêu cầu (elicitation process). Người này sẽ đánh giá về tính khả thi của các yêu cầu về mặt kỹ thuật hoặc các yêu cầu có thể thực thi nhưng với một chi phí lớn.

Cần thiết (Necessary)

Mỗi yêu cầu cần phải tài liệu hoá một cái gì đó mà khách hàng thật sự cần hoặc một hệ thống khác bên ngoài cần. Một cách khác để xác nhận “tính cần thiết” là yêu cầu đó được đề xuất từ một bên mà bạn biết rất rõ rằng anh ta có thầm quyền đề ra yêu cầu.

Được xếp thứ tự ưu tiên (Prioritized)

Gán một thứ tự ưu tiên cho mỗi yêu cầu, tính năng (feature), hoặc use-case để có thể hình dung lịch trình phát hành các phiên bản của sản phẩm. Nếu tất cả các yêu cầu được coi là quan trọng như nhau thì quản trị dự án sẽ không xác định được cách thức thi công khi một yêu cầu mới phát sinh ngay trong quá trình thi công của dự án, anh ta sẽ không kiểm soát được ngân sách, lịch biểu và nhân lực của dự án. Chương 13 sẽ thảo luận về thứ tự ưu tiên chi tiết.

Không nhập nhằng (Unambigous)

Tất cả những ai khi đọc bản báo cáo yêu cầu đều có cùng một cách hiểu, một cách diễn giải nhất quán về nội dung của các yêu cầu. Do ngôn ngữ tự nhiên là có tính nhập nhằng cao nên viết một yêu cầu rõ ràng, cụ thể, đơn nghĩa không phải là dễ. Cách hiệu quả để loại bỏ tính nhập nhằng là mô tả các báo cáo yêu cầu bằng các ngôn ngữ hình thức như use-case chẳng hạn, qua các kịch bản sử dụng cụ thể.

Có thể kiểm tra (Verifiable)

Hãy kiểm tra mỗi yêu cầu để xem liệu bạn có thể nghĩ ra một số lượng nhỏ các phép tests hoặc sử dụng một cách tiếp cận kiểm tra khác như thanh tra (inspection) hoặc chứng minh (demonstration) để biết liệu yêu cầu đó đã được cài đặt hợp lệ trong sản phẩm hay không. Nếu một yêu cầu không thể kiểm tra thì xác định liệu nó có được cài đặt đúng đắn hay không sẽ trở thành vấn đề gây tranh cãi. Các yêu cầu không nhất quán, không khả thi hoặc nhập nhằng thì cũng không thể kiểm tra được.

2. CÁC ĐẶC TÍNH CỦA ĐẶC TẢ YÊU CẦU (REQUIREMENT SPECIFICATION CHARACTERISTICS)

Đầy đủ (Complete)

Không yêu cầu hoặc thông tin cần thiết nào bị mất. Các yêu cầu bị mất rất khó phát hiện do sự “vô hình” (invisible) của chúng. Tập trung vào các tác vụ của người dùng thay vì tập trung vào các chức năng hệ thống sẽ giúp bạn tránh được sự không đầy đủ đó. Nếu bạn biết bạn thiếu một thông tin nào đó, hãy sử dụng TBD (“to be determined”) như là một dấu hiệu tiêu chuẩn (standard flag) để đánh dấu các “nếp gẫy” (gaps) đó. Hãy phân giải (resolve) tất cả các TBDs trước khi tiến hành xây dựng.

Nhất quán (Consistent)

Các yêu cầu nhất quán không xung đột với các yêu cầu phần mềm khác hoặc các yêu cầu cấp cao hơn (hệ thống hoặc kinh doanh). Tất cả các mâu thuẫn trong yêu cầu cần phải được phân giải trước khi quá trình phát triển diễn ra. Bạn có thể không biết một yêu cầu đơn nhất (single requirement) nào đó là đúng đắn cho đến tận khi bạn tiến hành một số nghiên cứu nào đó về yêu cầu này.

Có thể sửa chữa (Modifiable)

Bạn cần nghiên cứu lại SRS khi cần thiết và duy trì thông tin diễn biến thay đổi của mỗi yêu cầu. Điều này đòi hỏi mỗi yêu cầu được dán nhãn duy nhất và được diễn giải riêng rẽ với các yêu cầu khác sao cho mỗi yêu cầu đều được tham chiếu chính xác. Mỗi yêu cầu chỉ được xuất hiện duy nhất 1 lần trong SRS để tránh sự không nhất quán giữa các thể hiện (instance) của cùng 1 yêu cầu tại những nơi khác nhau. Một bảng nội dung (table of contents), một index, một danh sách tham chiếu chéo (cross – reference listing) sẽ làm SRS dễ sửa chữa hơn.

Có thể theo vết (Traceable)

Bạn cần phải liên kết các yêu cầu tới nguồn phát sinh của nó, tới các bản thiết kế, mã nguồn, các test cases thực thi và kiểm tra sự đúng đắn trong việc thi công các yêu cầu. Các yêu cầu có thể theo vết được gán nhãn duy nhất và được viết theo một cách có cấu trúc, chi tiết và được thuyết minh đầy đủ. Chương 18 sẽ tập trung trình bày nội dung này.

VI. PHÁT TRIỂN VÀ QUẢN LÝ YÊU CẦU (REQUIREMENTS DEVELOPMENT AND MANAGEMENT)

Sự tối nghĩa của thuật ngữ yêu cầu khiến cho có nhiều cách hiểu khác nhau và cách làm khác nhau đối với việc thu thập và xử lý yêu cầu. Một số tác giả gọi toàn bộ quy trình yêu cầu là “công nghệ yêu cầu” (requirement engineering), một số khác lại gọi là “quản lý yêu cầu” (requirement management). Thường thì người ta chia nhỏ toàn bộ quy trình này ra thành phát triển yêu cầu (requirements management) (trình bày trong Phần II) và quản lý yêu cầu (requirements management) (trình bày trong Phần III), như thể hiện ở Hình 1-2.

Fig 1-2
HÌNH 1-2. Phân cấp công nghệ yêu cầu.

Phát triển yêu cầu cũng có thể được chia nhỏ thành suy luận, phân tích, đặc tả, kiểm tra (elicitation, analysis, specification, verification) (Thayer and Dorfman 1997). Tất cả các nhánh công việc con đó bao trọn toàn bộ các hoạt động thu thập, đánh giá, tài liệu hoá yêu cầu của một phần mềm. Các hoạt động phát triển yêu cầu gồm:

  • Xác định các lớp người dùng được kỳ vọng (expected user classes) của sản phẩm.
  • Suy luận nhu cầu (needs) từ các cá nhân đại diện cho mỗi lớp người dùng đó.
  • Tìm hiểu tác vụ của người dùng hiện tại, các mục tiêu và nhu cầu kinh doanh được các tác vụ đó trợ giúp.
  • Phân tích thông tin nhận được từ người dùng để phân loại các nhu cầu tác vụ của họ với các yêu cầu chức năng, các quy tắc nghiệp vụ (business rules), các thuộc tính chất lượng, các giải pháp được đề nghị, thông tin xa lạ khác.
  • Phân chia (partitioning) các yêu cầu mức hệ thống thành các hệ thống con cơ bản (major subsystems) và phân bổ (allocating) một số yêu cầu thành các software components.
  • Tìm hiểu về tầm quan trọng tương đối của các thuộc tính chất lượng.
  • Đàm phán về các ưu tiên trong thi công hệ thống.
  • Biến đổi (translate) các nhu cầu người dùng đã tập hợp được thành các đặc tả và mô hình (specifications and models).
  • Soát xét các đặc tả yêu cầu để đảm bảo một cách hiểu chung về các yêu cầu đã được định vị (stated requirements) và sửa chữa bất cứ vấn đề gì trước khi nhóm phát triển chấp nhận chúng.

Quản lý yêu cầu được hiểu là “thiết lập và duy trì một thoả thuận với khách hàng về các yêu cầu của dự án phần mềm” (CMU/SEI 1995). Tuy nhiên sự chấp nhận của khách hàng cũng mới chỉ chiếm một nửa điều kiện của thông qua yêu cầu. Các nhà phát triển cũng phải thoả thuận để chấp nhận chúng và xây dựng sản phẩm tương ứng. Thông thường các hoạt động quản lý yêu cầu bao gồm:

  • Định nghĩa ranh giới (baseline) của hoạt động xử lý yêu cầu (ranh giới giữa phát triển và quản lý yêu cầu).
  • Soát xét các thay đổi yêu cầu được đề nghị và đánh giá các ảnh hưởng của mỗi thay đổi đó trước khi quyết định có chấp nhận sự thay đổi đó hay không.
  • Kết hợp các thay đổi yêu cầu đã được chấp nhận đó vào dự án theo một cách được kiểm soát.
  • Bám sát kế hoạch dự án với sự thay đổi của các yêu cầu.
  • Đàm phán về các cam kết mới căn cứ vào các ảnh hưởng được ước lượng của các yêu cầu thay đổi.
  • Lần vết mỗi yêu cầu bị thay đổi đến các thiết kế tương ứng, mã nguồn, kịch bản kiểm thử.
  • Hiệu chỉnh (tracking) trạng thái của các yêu cầu và các hoạt động thay đổi trên toàn bộ dự án.

Hình 1-3 thể hiện sự khác nhau giữa phát triển yêu cầu và quản lý yêu cầu (Xem hình này hiểu kỹ hơn khái niệm requirements baseline).

Fig 1-3
HÌNH 1-3. Biên phân chia giữa phát triển yêu cầu và quản lý yêu cầu.
Các bước tiếp theo
  • Viết ra bất cứ vấn đề gì liên quan đến yêu cầu mà bạn đang phải đối mặt trong các dự án hiện tại và trước đây của bạn. Hãy chỉ ra vấn đề đó thuộc loại phát triển hay quản lý yêu cầu. Hãy xác định các ảnh hưởng gây ủa bởi mỗi vấn đề và nguyên nhân gốc của mỗi vấn đề.
  • Hãy tổ chức một cuộc thảo luận với các thành viên trong nhóm của bạn và những người liên quan khác (khách hàng, marketing, các nhà quản trị dự án) về các vấn đề liên quan đến yêu cầu từ các dự án hiện tại và trước đây của bạn, về các ảnh hưởng và nguyên nhân gốc của chúng. Hãy giải thích với những người tham gia rằng họ phải đối mặt với các khó khăn nếu họ muốn nắm bắt chúng. Họ sẵn sàng chứ?
  • Hãy sắp xếp một lớp học trong 1 ngày về yêu cầu cho nhóm của bạn. Nhóm đó gồm khách hàng chính, nhân viên marketing, các nhà quản lý, hãy làm bất cứ cái gì cần thiết để họ ngồi lại cùng nhau và học lớp này. Lớp học sẽ cung cấp cho họ một danh sách từ vựng chung, một cách hiểu chung về các vấn đề của việc phát triển và quản lý yêu cầu, nhờ vậy họ có thể chỉ mặt, đặt tên các thách thức mà họ cần vượt qua.

(Còn tiếp)

30/09/2009

10 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

10 responses to “Software Requirements. First Edition – MS Press. Chương 1: Cơ bản về yêu cầu phần mềm

  1. nguyễn đức báu

    bài dịch rất hay,thanks

  2. laptrinhc

    anh dich hay lam,thanks

  3. sata2009blog

    Cam on laptrinhc nhieu!

  4. Manh Thao

    Rat bo ich, thanks ban

  5. Thật tuyệt vời, đúng cái tui cần, bài dịch tuyệt vời lắm pro ơi!

  6. Viên

    Cảm ơn anh! Bài dịch rất hay.

  7. Lê Trần Đạt

    Bài dịch tốt quá, nhưng có chỗ này viết bị nhầm chỗ requirements management với development, “Thường thì người ta chia nhỏ toàn bộ quy trình này ra thành phát triển yêu cầu (requirements management)”.

  8. sata2009blog

    Cám ơn bạn rất nhiều, tôi đã sửa chỗ sai đó.

  9. I am number four

    hay quá thanks bạn

  10. Duy

    Bài viết rất hay và bổ ích, cám ơn bạn rất nhiều.
    Tài liệu tiếng anh có đoạn mình đọc hoài ko hiểu, nhờ bài viết này mà mình đã thông suốt hơn 🙂

Gửi phản hồ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