Software Requirements. First Edition – MS Press. Chương 3: Good Practices cho công nghệ yêu cầu – Kỳ 2

Tác giả: Karl E. Wiegers

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

III. PHÂN TÍCH YÊU CẦU (REQUIREMENTS ANALYSIS)

Phân tích yêu cầu bao gồm việc làm mịn, phân tích ý tưởng và lời lẽ, nghiên cứu kỹ lưỡng các yêu cầu đã thu thập được để đảm bảo chắc chắn tất cả stakeholders (những người có liên quan) hiểu điều họ muốn nói, để tìm kiếm các lỗi, các thiếu sót và thiếu hụt khác. Công việc phân tích yêu cầu cũng đánh giá liệu các yêu cầu và SRS  (tài liệu đặc tả yêu cầu phần mềm) có đáp ứng đầy đủ các đặc tính về yêu cầu tuyệt vời được viết ở Chương 1 hay không. Mục đích của bạn là phát triển các yêu cầu chất lượng và chi tiết đủ để có thể xây dựng các ước lượng đầu vào cho dự án chuẩn bị tiến hành và để thực hiện việc thiết kế, xây dựng, kiểm thử sản phẩm.

Thường sẽ rất hữu ích nếu biểu diễn các yêu cầu dưới nhiều hình thức khác nhau, ví dụ mô tả bằng lời (textual form) và bằng hình ảnh (graphical form). Phân tích yêu cầu từ các góc nhìn khác nhau sẽ thấy lộ ra các vấn đề bên trong mà ta sẽ không thể thấy được nếu chỉ nhìn hệ thống từ một góc độ (Davis 1995). Phân tích cũng là việc tương tác với khách hàng để làm sáng tỏ các điểm còn chưa rõ và biết yêu cầu nào là quan trọng hơn yêu cầu nào. Mục đích cũng là đảm bảo các stakeholders sớm thống nhất được một cách hiểu chung – một tầm nhìn chung (shared vision) – về sản phẩm sẽ được sản xuất. Các chương sau sẽ thảo luận về phân tích yêu cầu:

  • Chương 6 – Vẽ một sơ đồ bối cảnh của hệ thống (Draw a context diagram of system)
  • Chương 9 – Tạo một từ điển dữ liệu (Create a data dictionary)
  • Chương 10 – Mô hình hoá yêu cầu (Model the requirements)
  • Chương 12 – Tạo các nguyên mẫu giao diện người dùng (Create user interface prototypes)
  • Chương 13 – Xếp thứ tự ưu tiên các yêu cầu (Prioritize the requirements)

Vẽ một sơ đồ bối cảnh của hệ thống (Draw a context diagram of system)

Sơ đồ bối cảnh là một mô hình đơn giản định nghĩa các đường biên và các giao diện giữa hệ thống đang được xây dựng với các thực thể bên ngoài tức môi trường của hệ thống. Nó cũng định nghĩa luồng thông tin và các đầu vào (materials) thông qua các giao diện.

Tạo các nguyên mẫu giao diện người dùng (Create user interface prototypes)

Khi các nhà phát triển và người dùng không chắc chắn được về yêu cầu thì có thể xây dựng một nguyên mẫu giao diện người dùng để làm cho các ý tưởng và các khả năng lựa chọn (concepts and possibilities) dễ hình dung hơn. Người dùng có thể đánh giá nguyên mẫu để giúp những người tham gia dự án có được một sự hiểu biết tốt hơn về bài toán cần giải quyết. Hãy cố tìm kiếm sự không nhất quán giữa các yêu cầu đã được viết ra và các nguyên mẫu.

Phân tích tính khả thi của yêu cầu (Analyze requirement feasibility)

Đánh giá về tính khả thi của việc cài đặt mỗi yêu cầu ở mức hiệu quả và chi phí có thể chấp nhận trong môi trường chuyển giao dự kiến (môi trường mà hệ thống dự định sẽ hoạt động – ND). Tìm hiểu các rủi ro liên quan tới việc cài đặt mỗi yêu cầu như xung đột giữa các yêu cầu, sự phụ thuộc của yêu cầu vào các yếu tố bên ngoài, các trở ngại kỹ thuật.

Xếp thứ tự ưu tiên các yêu cầu (Prioritize the requirements)

Căn cứ trên nhu cầu tất cả các stakeholders để xác định mức ưu tiên tương đối của các use cases, các tính năng sản phẩm, các yêu cầu cá nhân. Dựa trên mức ưu tiên đã xác lập, xác định phiên bản nào của sản phẩm sẽ chứa những tính năng nào hoặc chứa tập hợp các yêu cầu nào. Nếu các thay đổi của yêu cầu được chấp thuận, hãy phân bổ các thay đổi này vào một phiên bản tương lai cụ thể, xác định các thay đổi tương ứng trong việc lập kế hoạch phát hành các phiên bản.

Mô hình hoá các yêu cầu (Model the requirements)

Các mô hình phân tích bằng hình ảnh của yêu cầu có thể là hỗ trợ có giá trị cho SRS. Chúng thể hiện các thông tin và mối quan hệ khác nhau, chúng giúp tìm kiếm các yêu cầu không đúng đắn, không nhất quán, các yêu cầu còn thiếu. Các mô hình như vậy gồm DFDs, ERDs, state-transition diagrams, dialog maps, object class và interation diagrams.

Tạo một từ điển dữ liệu (Create a data dictionary)

Từ điển dữ liệu là một kho chứa trung tâm các định nghĩa của tất cả các mục dữ liệu (data items) và các cấu trúc được hệ thống sử dụng. Nó đảm bảo tất cả các nhà phát triển liên quan đến dự án đều hiểu nhất quán các định nghĩa dữ liệu. Ở mức yêu cầu, từ điển dữ liệu ít nhất phải định nghĩa các mục dữ liệu khách hàng (customer data items) sao cho khách hàng và nhóm phát triển sử dụng chung các định nghĩa và thuật ngữ. Các công cụ phân tích và thiết kế thường bao gồm một data dictionary component.

IV. ĐẶC TẢ YÊU CẦU (REQUIREMENTS SPECIFICATION)

Dù yêu cầu có thể đến từ bất cứ nguồn nào và bạn có thể thu thập chúng bằng bất cứ cách nào, thì bạn cũng phải tài liệu hoá chúng theo một cách nhất quán, dễ truy nhập và có thể soát xét (consistent, accessible, reviewable). Yêu cầu kinh doanh (business requirements) có thể được ghi nhận ở tài liệu tầm nhìn và phạm vi (vision and scope) của dự án. Yêu cầu người dùng (user requirements) được tài liệu hoá trong một use case template chuẩn. SRS chứa các yêu cầu chức năng (functional requirements) và phi chức năng. Bạn cũng phải thiết lập một quy ước chuẩn để định danh duy nhất mỗi yêu cầu. Bất cứ quy ước nào được sử dụng trong SRS cũng phải được định nghĩa để đảm bảo SRS được viết theo một phong cách nhất quán và độc giả biết được cách diễn giải nội dung trong đó như thế nào. Cụ thể về đặc tả yêu cầu được thảo luận trong các chương sau:

  • Chương 8 – Ghi nhận các quy tắc nghiệp vụ (Record business rules)
  • Chương 9 – Thông qua một SRS template; Gán nhãn mỗi yêu cầu (Adopt a SRS template; Label each requirement)
  • Chương 18 – Xác định nguồn của yêu cầu; Tạo một ma trận có thể lần vết yêu cầu (Identify the sources of requirements; Create a requirements traceability matrix)

Thông qua một SRS template; Gán nhãn mỗi yêu cầu (Adopt a SRS template; Label each requirement)

Hãy định nghĩa một template chuẩn để tài liệu hoá yêu cầu. Template tạo ra một cấu trúc nhất quán để ghi lại cả yêu cầu chức năng (functional requirements) và nhiều thông tin quan trọng khác liên quan đến yêu cầu. Thay vì tạo ra một template mới, hãy thích ứng (adapt) một mẫu đã có cho dự án của bạn. Nhiều tổ chức đã sử dụng SRS template được mô tả trong IEEE Standard 830-1998 (IEEE 1998).

Xác định nguồn của yêu cầu (Identify the sources of requirements)

Để đảm bảo tất cả các stakeholders đều biết tại sao mỗi yêu cầu chức năng (functional requirement) có mặt trong SRS, hãy ghi lại nguồn phát sinh yêu cầu đó. Nguồn đó có thể là một tình huống sử dụng (use case), hoặc một đầu vào của khách hàng, một yêu cầu hệ thống cấp cao hơn, một quy tắc kinh doanh (business rule), một quy định của chính phủ (government regulation), một tiêu chuẩn, hoặc một nguồn bên ngoài khác.

Gán nhãn mỗi yêu cầu (Label each requirement)

Đặt ra một quy ước (convention) để định danh riêng rẽ mỗi yêu cầu trong SRS bằng một nhãn (label or tag). Quy ước này phải đủ bao quát được tất cả các tình huống liên quan đến yêu cầu trong toàn bộ dự án như chỉnh sửa, xoá bỏ, thêm mới. Gán nhãn (labeling) yêu cầu là cho phép lần vết yêu cầu (requirements traceability). Mỗi khi thay đổi yêu cầu, cần ghi nhận lại nội dung trước và cả sau khi thay đổi, cần thiết lập các độ đo (metrics) xác định tình trạng yêu cầu (requirements status).

Ghi nhận các quy tắc kinh doanh (Record business rules)

Các quy tắc kinh doanh (business rule) là các nguyên tắc hoạt động của sản phẩm, như ai có thể thực hiện hành động gì và dưới hoàn cảnh (circumstance) nào. Tài liệu hoá các quy tắc này trong một phần đặc biệt (special section) của SRS hoặc trong một tài liệu quy tắc kinh doanh (business rule) riêng biệt. Một số quy tắc kinh doanh (business rule) dẫn tới các yêu cầu chức năng (functional requirements) cần thiết (để làm cho nó trở nên hiệu lực), các yêu cầu chức năng (functional requirements) này cần được lần vết quay ngược trở lại quy tắc kinh doanh (business rule) đã sinh ra nó.

Tạo một ma trận có thể lần vết yêu cầu (Create a requirements traceability matrix)

Tạo một ma trận kết nối tất cả các yêu cầu riêng biệt tới các phần tử thiết kế, mã nguồn và kiểm thử (design, code, test elements) yêu cầu này. Ma trận lần vết yêu cầu cũng kết nối các yêu cầu chức năng (functional requirements) tới các yêu cầu cấp cao hơn mà từ đó nó được sinh ra. Hãy làm ma trận này song song với quá trình phát triển dự án.

V. KIỂM TRA YÊU CẦU (REQUIREMENTS VERIFICATION)

Các hoạt động kiểm tra đảm bảo các lời thể hiện yêu cầu là chính xác, đầy đủ, và mô tả được các đặc tính chất lượng mong muốn. Các yêu cầu dường như tốt đẹp nếu chỉ đọc chúng từ các SRS, nhưng khi bạn thực sự làm việc với chúng thì có thể nảy sinh các vấn đề. Nếu bạn viết các test cases từ các yêu cầu, bạn có thể phát hiện các nhập nhằng và sự không chắc chắn trong một số yêu cầu. Những cái không rõ ràng này phải được loại bỏ nếu yêu cầu được coi như là một nền tảng tin cậy (reliable foundation) cho thiết kế và kiểm tra hệ thống cuối cùng. Sự tham gia của khách hàng là yếu tố cơ bản cần thiết cho hoạt động kiểm tra yêu cầu, chúng sẽ được mô tả trong Chương 14.

Thanh tra tài liệu yêu cầu (Inspect requirement documents)

Thanh tra chính thức (formal inspection) tài liệu yêu cầu là một trong những practices có khả năng mang lại giá trị cao nhất cho chất lượng phần mềm. Tập hợp một nhóm nhỏ các thanh tra viên (inspectors) đại diện cho nhiều quan điểm khác nhau (gồm phân tích viên, khách hàng, thiết kế viên, kiểm thử viên) kiểm tra cẩn thận SRS và các mô hình liên quan nhằm tìm kiếm các khiếm khuyết (defects). Các soát xét sơ bộ không chính thức (informal preliminary reviews) trong giai đoạn phát triển yêu cầu cũng rất có giá trị.

Viết các test cases từ các yêu cầu (Write test cases from requirements)

Chúng ta thu được các black-box test cases (functional test) từ các use cases tài liệu hoá hành vi được mong muốn của sản phẩm trong các điều kiện xác định (specified conditions). Duyệt qua (walk through) các test cases cùng khách hàng để đảm bảo chúng phản ánh đúng hành vi được mong đợi. Từ các test cases lần vết ngược lại các yêu cầu chức năng (functional requirements) để đảm bảo chắc chắn không yêu cầu nào bị bỏ qua (overlooked) và tất cả đều có các test cases tương ứng. Sử dụng các test cases để kiểm tra tính đúng đắn của mô hình yêu cầu như dialog maps, prototypes (nguyên mẫu).

Viết một sổ tay người dùng (Write a user manual)

Phác thảo sổ tay người dùng ngay từ sớm trong quy trình phát triển yêu cầu và dùng nó như là tài liệu đặc tả yêu cầu hoặc như một trợ giúp cho phân tích yêu cầu. Một tài liệu sổ tay người dùng tốt sẽ mô tả tất cả các chức năng mà người dùng thấy được (user – visible functionality) bằng một ngôn ngữ dễ hiểu. Các yêu cầu khác như các thuộc tính chất lượng, yêu cầu hiệu suất, chức năng không thấy được đối với người dùng (not visible to users) sẽ được tài liệu hoá trong SRS.

Định nghĩa tiêu chuẩn chấp nhận (Define acceptance criteria)

Đề nghị người dùng mô tả họ xác định một sản phẩm như thế nào thì đáp ứng nhu cầu sử dụng của họ và mô tả lại các tiêu chuẩn ấy (Hsia, Kung and Sell 1997).

VI. QUẢN LÝ YÊU CẦU (REQUIREMENTS MANAGEMENT)

Khi bạn đã có yêu cầu thì bạn cũng phải đối mặt với các thay đổi không thể tránh được của yêu cầu như là thể hiện của sự tiến hoá của dự án. Quản lý thay đổi hiệu quả đòi hỏi một quy trình đề xuất các thay đổi và đánh giá các chi phí và ảnh hưởng tiềm tàng của thay đổi trên toàn bộ dự án. Một ban kiểm soát thay đổi (change control board) phối hợp với các stakeholders quan trọng phải ra các quyết định chấp nhận hoặc từ chối các thay đổi này.

Các practices quản lý cấu hình là điều kiện tiên quyết để quản lý yêu cầu một cách hiệu quả. Nhiều tổ chức phát triển sử dụng cách kiểm soát phiên bản (version control) và các kỹ thuật quản lý cấu hình khác để kiểm soát code base, nhưng bạn cũng có thể sử dụng các practices đó để quản lý tài liệu yêu cầu. Cải tiến quy trình quản lý yêu cầu có thể là một cách để đưa các practices quản lý cấu hình mới (new conguration management practices) vào tổ chức của bạn. Cac kỹ thuật liên quan trong quản lý yêu cầu được mở rộng trong các chương sau:

  • Chương 16 – Thiết lập một ranh giới và kiểm soát các phiên bản của tài liệu yêu cầu (Establish a baseline and control versions of requirements documents).
  • Chương 17 – Định nghĩa một quy trình kiểm soát thay đổi yêu cầu; Thiết lập một ban kiểm soát thay đổi (Define a requirements change control process; Establish a change control board).
  • Chương 18 – Thực hiện phân tích ảnh hưởng thay đổi yêu cầu; Lần vết một thay đổi yêu cầu tới tất cả các bán thành phẩm liên quan (Perform a requirements change impact analysis; Trace a requirements change to all affected work products)
  • Chương 19 – Sử dụng một công cụ quản lý yêu cầu (Use a requirements management tool).

Định nghĩa một quy trình kiểm soát yêu cầu (Define a requirements change control process)

Thiết lập một quy trình đề xuất, phân tích và ra quyết định về các thay đổi yêu cầu. Tất cả các thay đổi được đề xuất phải tuân theo quy trình này.

Thành lập một ban kiểm soát thay đổi (Establish a change control board)

Một nhóm nhỏ các stakeholders được tập hợp lại như một ban kiểm soát thay đổi để tiếp nhận  các đề xuất thay đổi yêu cầu, xác định liệu các thay đổi đó còn trong phạm vi dự án, đánh giá và ra quyết định chấp nhận hoặc từ chối, nếu chấp nhận thì xác định thứ tự ưu tiên thi công đề xuất thay đổi này.

Thực hiện phân tích ảnh hưởng của thay đổi yêu cầu (Perform requirements change impact analysis)

Mỗi thay đổi được chấp nhận đều được đánh giá để xác định mức độ ảnh hưởng đến lịch biểu và các yêu cầu khác. Xác định các thay đổi tương ứng tới thiết kế và thi công các tác vụ liên quan, xác định nhân lực cần thiết để hoàn thành các thay đổi.

Lần vết một thay đổi yêu cầu tới tất cả các bán thành phẩm liên quan (Trace a requirements change to all affected work products)

Khi một đề xuất thay đổi trong một yêu cầu được chấp nhận, hãy tham chiếu ma trận lần vết yêu cầu để xác định các yêu cầu bị ảnh hưởng, các thiết kế của components, mã nguồn, các test cases.

Thiết lập một ranh giới và kiểm soát các phiên bản của tài liệu yêu cầu (Establish a baseline and control versions of requirements documents)

Định nghĩa một ranh giới yêu cầu, tại đó tất cả các thoả thuận về nội dung các yêu cầu đã được chấp thuận cho đến thời điểm đó. Sau khi ranh giới được thiết lập, các thay đổi chỉ được chấp nhận bởi ban kiểm soát thay đổi thông qua quy trình kiểm soát thay đổi đã định nghĩa. Mỗi phiên bản của tài liệu đặc tả yêu cầu được định danh duy nhất. Có thể quản lý các phiên bản này bằng các công cụ quản lý cấu hình thích hợp.

Duy trì một lịch sử thay đổi yêu cầu (Maintain a history of requirements changes)

Hãy ghi lại ngày tháng mà các thay đổi xảy ra và ngày tháng phát sinh các phiên bản, lý do mỗi thay đổi đó, các thay đổi đó được thực hiện như thế nào, ai cập nhật tài liệu, số hiệu mỗi phiên bản. Một công cụ kiểm soát phiên bản có thể tự động làm việc này.

Giám sát tình trạng mỗi yêu cầu (Track status of each requirement)

Thiết lập một CSDL mà mỗi bản ghi là một yêu cầu chức năng (functional requirements) riêng biệt. Lưu giữ các thuộc tính quan trọng của mỗi yêu cầu như tình trạng của yêu cầu (được đề xuất, được chấp thuận, được thực thi, được kiểm tra), sao cho số lượng mỗi loại yêu cầu theo từng trạng thái có thể được biết bất cứ lúc nào.

Đo lường độ ổn định của yêu cầu (Measure requirement stability)

Ghi lại số lượng các yêu cầu được đã được định ranh giới (baselined requirements) và số lượng các thay đổi được đề xuất và chấp thuận (proposed and approved changes) (hiệu chỉnh, sửa chữa, xoá bỏ) đối với các yêu cầu đó trong mỗi tuần hoặc mỗi tháng. Các thay đổi yêu cầu quá nhiều là một dấu hiệu chỉ ra rằng bài toán đã chưa được hiểu đúng, phạm vi dự án không được định nghĩa tốt, hoặc tình hình tổ chức không ổn định.

Sử dụng một công cụ quản lý yêu cầu (Use a requirements management tool)

Các công cụ quản lý yêu cầu thương mại cho phép bạn lưu trữ các yêu cầu riêng biệt theo từng loại khác nhau trong một CSDL, định nghĩa các thuộc tính cho mỗi yêu cầu, giám sát tình trạng mỗi yêu cầu, định nghĩa khả năng lần vết giữa yêu cầu và tất cả các bán thành phẩm liên quan.

VII. QUẢN LÝ DỰ ÁN (PROJECT MANAGEMENT)

Các cách tiếp cận quản lý dự án liên quan mật thiết tới các quy trình yêu cầu (requirements processes) của dự án. Các kế hoạch của dự án cần phải được thiết lập dựa trên chức năng cần xây dựng của sản phẩm phần mềm, các thay đổi yêu cầu sẽ ảnh hưởng đến các kế hoạch đó. Kế hoạch cần tiên liệu và điều chỉnh các thay đổi được chấp nhận trong phạm vi của dự án. Nếu các yêu cầu ban đầu không chắc chắn, bạn có thể chọn một cách phát triển phần mềm chấp nhận sự không chắc chắn đó và cho phép chỉ cài đặt các yêu cầu theo từng phần cùng với sự hiểu biết về yêu cầu tăng dần. Cách tiếp cận quản lý dự án căn cứ trên yêu cầu được thảo luận trong các chương sau:

  • Chương 5 – Tài liệu hoá và quản lý các rủi ro liên quan đến yêu cầu (Document and manage requirements – related risks).
  • Chương 15 – Thiết lập các kế hoạch dự án dựa trên yêu cầu (Base project plans on requirements).
  • Chương 16 – Giám sát nguồn nhân lực dành cho phát triển và quản lý yêu cầu (Track the effort you spend on requirements development and management)

Chọn lựa một vòng đời phát triển phần mềm thích hợp (Select an appropriate software development life cycle)

Cách phát triển phần mềm thác nước cổ điển có thể chỉ thành công nếu yêu cầu được định nghĩa đầy đủ ngay từ sớm. Doanh nghiệp của bạn cần phải định nghĩa một số cách thức phát triển thích hợp với các loại hình dự án khác nhau tùy các mức định nghĩa yêu cầu khác nhau (McConnell 1996). Nếu yêu cầu và/hoặc phạm vi yêu cầu được định nghĩa chưa rõ ngay từ đầu thì hãy lập kế hoạch phát triển theo từng bước tăng dần, bắt đầu với các yêu cầu đã được hiểu rõ bằng một kiến trúc vững chắc và có thể chỉnh sửa (robust and modifiable architecture).

Thiết lập các kế hoạch dự án dựa trên yêu cầu (Base project plans on requirements)

Thiết lập các kế hoạch và lịch biểu dự án bằng cách lặp theo sự mở rộng của phạm vi và các yêu cầu được làm chi tiết hơn. Bắt đầu bằng ước lượng nhân lực cần thiết để phát triển các yêu cầu chức năng (functional requirements) từ tài liệu tầm nhìn và phạm vi (vision and scope). Các ước lượng chi phí và lịch biểu ngay từ sớm dựa trên các yêu cầu được định nghĩa chưa rõ ràng sẽ có độ bất ổn cao, các ước lượng được cải tiến theo sự tốt dần hơn của yêu cầu.

Đám phán lại các cam kết của dự án khi các yêu cầu thay đổi (Renegotiate project commitments when requirements change)

Khi các yêu cầu mới được đưa vào dự án, hãy đánh giá liệu bạn có thể hoàn thành công việc như các cam kết về chất lượng và lịch biểu với mức tiêu thụ tài nguyên hiện có hay không. Nếu không, hãy thông báo cho cấp quản lý về hiện thực của dự án, hãy đàm phán lại về tính hiện thực của các cam kết (Humphrey 1997). Nếu các cam kết của bạn không thành, hãy thông báo cho các bên biết kết quả cập nhật rủi ro mới của dự án.

Tài liệu hoá và quản lý các rủi ro liên quan đến yêu cầu (Document and manage requirements – related risks)

Tập kích não (brainstorm) để tìm kiếm các rủi ro liên quan đến yêu cầu và ghi chúng vào kế hoạch quản lý rủi ro của dự án. Hãy suy nghĩ cách tiếp cận để giảm hoặc tránh rủi ro, thực hiện các hành động giảm rủi ro, giám sát diễn biến và hiệu quả của các công việc xử lý rủi ro.

Giám sát nguồn nhân lực dành cho phát triển và quản lý yêu cầu (Track the effort you spend on requirements development and management)

Ghi chép lại tình trạng nhân lực được dành cho các hoạt động phát triển và quản lý yêu cầu. Sử dụng dữ liệu này để đánh giá liệu các hoạt động yêu cầu đã được lập kế hoạch tốt hay chưa để rút kinh nghiệm nhằm điều chỉnh dự án hiện tại tốt hơn và rút kinh nghiệm cho các dự án tương lai.

Các bước tiếp theo
  • Hãy quay lại xem các vấn đề liên quan đến yêu cầu mà bạn đã xác định trong Các bước tiếp theo của Chương 1. Hãy xác định các good practices trong Chương này có thể giúp bạn giải quyết mỗi vấn đề đó như thế nào. Với mỗi practice bạn chọn, hãy xác định bất cứ rào cản nào về mặt tổ chức và văn hoá có thể gây khó khăn cho sự ứng dụng practice này.
  • Hãy tạo một danh sách tất cả các requirement good practices mà bạn đã định danh trong bước trước. Với mỗi practice, hãy xác định khả năng của nhân lực trong dự án của bạn: chuyên gia, người thành thạo, người chưa có kinh nghiệm, người chưa biết tí gì. Nếu nhóm của bạn không thành thạo ít nhất một practice, hãy yêu cầu ai đó học các practices này và chia sẻ với các thành viên còn lại.

(Hết Chương 3, còn tiếp)

22/10/2009

Advertisements

1 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

One response to “Software Requirements. First Edition – MS Press. Chương 3: Good Practices cho công nghệ yêu cầu – Kỳ 2

  1. Hien

    Hay quá, rất bổ ích, cảm ơn rất nhiều

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