Chương 4: Xác Định Yêu Cầu Nghiệp Vụ cho Phát Triển Hệ Thống

Khám phá chương 4: Xác định yêu cầu (requirements determination) trong k66k. Tìm hiểu quy trình, kỹ thuật thu thập thông tin và phân tích nhu cầu dự án hiệu quả.

Người đăng

Ẩn danh

Thể loại

Tài liệu học tập
55
2
0

Phí lưu trữ

30 Point

Mục lục chi tiết

4. CHƯƠNG 4: XÁC ĐỊNH YÊU CẦU

4.1. Giới thiệu

4.2. Xác định các yêu cầu

4.2.1. Định nghĩa một yêu cầu

4.2.2. Định nghĩa yêu cầu (Báo cáo định nghĩa yêu cầu)

4.3. Tạo ra một yêu cầu (Creating a Requirements Definition)

4.4. Chiến lược phân tích yêu cầu

4.4.1. Tự động hóa quy trình nghiệp vụ (BPA)

4.4.2. Cải tiến quy trình nghiệp vụ (BPI)

4.4.3. Tái cấu trúc quy trình nghiệp vụ (BPR)

4.5. Kỹ thuật thu thập yêu cầu

4.5.1. Phỏng vấn

4.5.2. Bảng câu hỏi

4.5.3. Quan sát

4.5.4. Phát triển ứng dụng chung (JAD)

4.5.5. Phân tích tài liệu

4.6. Tóm lược

Tóm tắt

I. Xác Định Yêu Cầu Nghiệp Vụ là gì Nền tảng thành công hệ thống mới

Trong kỷ nguyên số, việc phát triển một hệ thống mới hiệu quả là chìa khóa cho sự phát triển của mọi tổ chức. Tuy nhiên, để đạt được mục tiêu đó, một bước đi không thể thiếu và mang tính quyết định chính là xác định yêu cầu nghiệp vụ một cách chính xác. Hoạt động này đặt nền móng vững chắc cho toàn bộ chu trình phát triển phần mềm (SDLC), chuyển đổi từ những ý tưởng ban đầu thành một bản kế hoạch chi tiết, khả thi và đáp ứng đúng nhu cầu. Mục đích chính của việc phân tích yêu cầu nghiệp vụ là biến những mong muốn chung thành một danh sách các yêu cầu cụ thể, có thể sử dụng làm đầu vào cho các giai đoạn tiếp theo của dự án. Một yêu cầu, nói một cách đơn giản, là một tuyên bố về những gì hệ thống phải thực hiện hoặc những đặc điểm mà nó cần sở hữu. Chúng ta phân biệt rõ ràng giữa yêu cầu nghiệp vụ (business requirements), tập trung vào các ứng dụng của hệ thống từ góc nhìn người dùng, và yêu cầu hệ thống (system requirements), mô tả cách hệ thống sẽ được triển khai về mặt kỹ thuật. Sự rõ ràng trong định nghĩa này mang lại lợi ích xác định yêu cầu to lớn, giúp giảm thiểu rủi ro và tăng cường sự hài lòng của stakeholder.

1.1. Định nghĩa yêu cầu nghiệp vụ Chức năng và Phi chức năng

Yêu cầu nghiệp vụ là những tuyên bố cơ bản mô tả các nhu cầu và mong đợi từ góc độ người dùng hoặc tổ chức. Chúng được chia thành hai loại chính: yêu cầu chức năngyêu cầu phi chức năng. Yêu cầu chức năng liên quan trực tiếp đến các quy trình mà hệ thống phải thực hiện hoặc thông tin cần chứa. Ví dụ, một hệ thống cần có khả năng tìm kiếm hàng tồn kho hoặc báo cáo chi phí là các yêu cầu chức năng. Chúng định nghĩa các chức năng cốt lõi mà hệ thống phải sở hữu và trực tiếp chảy vào các mô hình chức năng sau này. Ngược lại, yêu cầu phi chức năng đề cập đến các thuộc tính hành vi của hệ thống, như hiệu suất, khả năng sử dụng, bảo mật, và các yếu tố văn hóa, chính trị. Khả năng truy cập hệ thống bằng trình duyệt Web là một ví dụ về yêu cầu phi chức năng. Những yêu cầu này không mô tả quy trình nghiệp vụ cụ thể nhưng lại cực kỳ quan trọng trong việc định hình trải nghiệm và khả năng hoạt động của hệ thống cuối cùng. Chúng ảnh hưởng lớn đến các quyết định thiết kế và có thể chịu tác động từ các tiêu chuẩn như Sarbanes-Oxley, COBIT hay ISO 9000 trong các hệ thống thông tin mới, đòi hỏi chuyên môn cao trong quá trình đặc tả yêu cầu phần mềm.

1.2. Tầm quan trọng của việc xác định yêu cầu nghiệp vụ chính xác

Bước xác định yêu cầu nghiệp vụ được coi là giai đoạn quan trọng nhất trong toàn bộ Chu trình Phát triển Hệ thống (SDLC). Ở giai đoạn này, hệ thống vẫn còn rất linh hoạt, dễ dàng thay đổi với chi phí thấp nhất. Khi dự án tiến triển sang các giai đoạn sau như thiết kế và triển khai, việc quay lại điều chỉnh các yêu cầu sẽ trở nên phức tạp và tốn kém hơn đáng kể, do đã có nhiều công sức và tài nguyên được đầu tư. Nhiều nghiên cứu đã chỉ ra rằng hơn một nửa số lỗi hệ thống phát sinh từ các vấn đề liên quan đến yêu cầu. Điều này nhấn mạnh tầm quan trọng của việc xác định yêu cầu nghiệp vụ một cách tỉ mỉ và chính xác ngay từ đầu. Một bản đặc tả yêu cầu phần mềm rõ ràng không chỉ cung cấp thông tin cần thiết cho các sản phẩm khác trong giai đoạn phân tích nghiệp vụ mà còn đóng vai trò then chốt trong việc định nghĩa phạm vi dự án, ngăn ngừa tình trạng "scope creep" (phạm vi dự án bị mở rộng không kiểm soát). Việc hiểu rõ lợi ích xác định yêu cầu chính xác giúp giảm thiểu rủi ro yêu cầu không rõ ràng, đảm bảo dự án đi đúng hướng và đạt được mục tiêu đề ra.

II. Những thách thức lớn khi xác định yêu cầu nghiệp vụ hệ thống

Mặc dù tầm quan trọng của việc xác định yêu cầu nghiệp vụ cho hệ thống mới là không thể phủ nhận, quá trình này lại ẩn chứa nhiều thách thức đáng kể. Một trong những khó khăn cơ bản là việc cân bằng giữa mong muốn của người dùng và khả năng kỹ thuật của hệ thống. Trong quá khứ, đã có sự thay đổi quan điểm từ việc để nhà phân tích hệ thống độc quyền định nghĩa hệ thống, sang việc nhận ra vai trò trung tâm của người dùng như những chuyên gia nghiệp vụ. Tuy nhiên, ngay cả khi người dùng tham gia tích cực, họ đôi khi chỉ đơn thuần tự động hóa một quy trình hiện có không hiệu quả, bỏ lỡ cơ hội tận dụng những khả năng mới mà công nghệ mang lại. Giống như việc xây một ngôi nhà, người dùng có thể biết mình muốn gì, nhưng lại thiếu kỹ năng thiết kế và kỹ thuật để biến mong muốn đó thành bản vẽ chi tiết. Nhà phân tích cũng không thể làm việc độc lập. Do đó, cách tiếp cận hiệu quả nhất đòi hỏi sự hợp tác chặt chẽ giữa các chuyên gia nghiệp vụ và nhà phân tích. Điều này đòi hỏi cả hai bên phải có khả năng phân tích nghiệp vụ sâu sắc và sẵn sàng khám phá, định hình lại các nhu cầu. Các rủi ro yêu cầu không rõ ràng có thể dẫn đến hậu quả nghiêm trọng, từ vượt quá ngân sách, chậm trễ lịch trình, đến việc sản phẩm cuối cùng không đáp ứng được mục tiêu kinh doanh ban đầu.

2.1. Rủi ro yêu cầu không rõ ràng Tác động đến dự án

Một trong những mối đe dọa lớn nhất đối với bất kỳ dự án phát triển hệ thống mới nào là rủi ro yêu cầu không rõ ràng. Tài liệu gốc đã minh họa một trường hợp khi việc bỏ qua các yêu cầu phi chức năng đã khiến một dự án vượt quá chi phí và thời gian dự kiến gấp nhiều lần. Khi các yêu cầu không được định nghĩa rõ ràng hoặc không được tài liệu hóa đầy đủ, chúng có thể dẫn đến sự hiểu lầm giữa các bên liên quan, phát sinh các tính năng không mong muốn hoặc thiếu sót các tính năng cần thiết. Điều này không chỉ gây lãng phí nguồn lực mà còn làm giảm chất lượng hệ thống và sự hài lòng của người dùng. Một dự án không có tài liệu đặc tả yêu cầu (BRD/SRS) rõ ràng sẽ rất khó để quản lý yêu cầu dự án hiệu quả, đặc biệt là khi cần xử lý quản lý thay đổi yêu cầu. Việc thiếu một bản định nghĩa yêu cầu chính xác cũng khiến việc đánh giá tiến độ và thành công của dự án trở nên mơ hồ, dẫn đến khả năng thất bại dự án cao hơn. Do đó, đầu tư thời gian và công sức vào giai đoạn xác định yêu cầu nghiệp vụ là một khoản đầu tư chiến lược giúp giảm thiểu rủi ro dài hạn.

2.2. Sự khác biệt giữa mong muốn người dùng và khả năng hệ thống

Thách thức thường gặp là sự khác biệt giữa những gì người dùng tin rằng họ cần và những gì hệ thống thực sự có thể cung cấp, hoặc tốt hơn, nên cung cấp. Người dùng, với vai trò là chuyên gia nghiệp vụ, hiểu rõ quy trình làm việc hiện tại và các vấn đề họ đang đối mặt. Tuy nhiên, họ có thể không nhận thức được toàn bộ tiềm năng của công nghệ mới để cải thiện hoặc tái cấu trúc quy trình. Mặt khác, các nhà phân tích, dù có kiến thức về công nghệ, lại thiếu kinh nghiệm sâu sắc về nghiệp vụ cụ thể. Sự thiếu kết nối này có thể dẫn đến việc phát triển một hệ thống chỉ đơn thuần sao chép quy trình hiện tại mà không tận dụng các cơ hội đổi mới. Để khắc phục, cần có sự hợp tác chặt chẽ giữa Business Analyst (BA)stakeholder. BA đóng vai trò quan trọng trong việc cầu nối, giúp người dùng khám phá nhu cầu thực sự của họ và dịch chúng thành các yêu cầu kỹ thuật khả thi. Việc này đòi hỏi kỹ năng tư duy phản biện mạnh mẽ để phân tích, đánh giá điểm mạnh, điểm yếu và định hình lại ý tưởng trong một hình thức cải tiến, đảm bảo hệ thống thông tin mới không chỉ hoạt động mà còn mang lại giá trị gia tăng.

III. Phương pháp phân tích yêu cầu nghiệp vụ Tối ưu hóa hệ thống mới

Để vượt qua các thách thức và đạt được sự rõ ràng trong xác định yêu cầu nghiệp vụ, các tổ chức áp dụng nhiều phương pháp phân tích yêu cầu nghiệp vụ khác nhau. Các chiến lược này giúp nhà phân tích dẫn dắt người dùng qua quá trình hiểu hệ thống hiện trạng, xác định các cải tiến, và phát triển yêu cầu cho hệ thống tương lai. Sự lựa chọn phương pháp phụ thuộc vào mức độ thay đổi mà hệ thống mới dự kiến mang lại cho tổ chức. Ba chiến lược chính đã trở nên phổ biến để hỗ trợ các nhà phân tích trong việc này: Tự động hóa quy trình nghiệp vụ (BPA), Cải thiện quy trình nghiệp vụ (BPI)Tái cấu trúc quy trình nghiệp vụ (BPR). Mỗi phương pháp có một phạm vi và mức độ tác động khác nhau, từ những cải tiến nhỏ về hiệu suất đến sự biến đổi toàn diện của cách thức hoạt động của doanh nghiệp. Việc sử dụng các kỹ thuật này yêu cầu Business Analyst (BA) phải có tư duy phản biện mạnh mẽ để thực sự hiểu vấn đề và phát triển các quy trình nghiệp vụ mới, từ đó tối ưu hóa hệ thống mới để đạt được các mục tiêu kinh doanh mong muốn. Các chiến lược phân tích yêu cầu này hoạt động song song với các kỹ thuật thu thập yêu cầu để đảm bảo thông tin được thu thập chính xác và đầy đủ, phục vụ cho việc đặc tả yêu cầu phần mềm sau này.

3.1. Tự động hóa quy trình nghiệp vụ BPA Nâng cao hiệu quả

Tự động hóa quy trình nghiệp vụ (BPA) là chiến lược phân tích yêu cầu nghiệp vụ tập trung vào việc cải thiện hiệu quả bằng cách sử dụng công nghệ máy tính để tự động hóa một số công việc, trong khi vẫn giữ nguyên cách thức hoạt động cơ bản của tổ chức. Đây là phương pháp tạo ra mức độ thay đổi nhỏ nhất, thường hướng tới việc làm cho các quy trình hiện có chạy mượt mà và nhanh hơn. Hai kỹ thuật BPA phổ biến là phân tích vấn đềphân tích nguyên nhân gốc rễ. Phân tích vấn đề liên quan đến việc hỏi người dùng và quản lý xác định các vấn đề với hệ thống hiện tại và đề xuất cách giải quyết chúng trong hệ thống tương lai. Những cải tiến thường nhỏ và tăng dần, như cung cấp thêm không gian cho địa chỉ khách hàng. Phân tích nguyên nhân gốc rễ đi sâu hơn, không chỉ tập trung vào các giải pháp mà còn tìm hiểu sâu về nguồn gốc của vấn đề. Thay vì chỉ xử lý triệu chứng, phân tích nguyên nhân gốc rễ giúp xác định nguyên nhân sâu xa để đưa ra giải pháp bền vững, tránh lãng phí tài nguyên vào những khắc phục tạm thời. BPA là một cách hiệu quả để nâng cao hiệu quả mà không cần thay đổi cấu trúc lớn.

3.2. Cải thiện quy trình nghiệp vụ BPI Tận dụng cơ hội công nghệ

Cải thiện quy trình nghiệp vụ (BPI) là chiến lược thực hiện các thay đổi vừa phải đối với cách tổ chức hoạt động, nhằm tận dụng cơ hội công nghệ mới hoặc sao chép các phương pháp thành công của đối thủ cạnh tranh. BPI không chỉ tìm cách làm mọi việc đúng cách (hiệu quả) mà còn làm những việc đúng (tăng hiệu suất). Ba hoạt động phổ biến của BPI bao gồm phân tích thời lượng, chi phí dựa trên hoạt động, và đo điểm chuẩn không chính thức. Phân tích thời lượng kiểm tra chi tiết thời gian cần thiết để thực hiện từng quy trình, giúp xác định các tắc nghẽn hoặc sự phân mảnh trong quy trình. Ví dụ, nếu một khoản thế chấp mất 30 ngày để phê duyệt nhưng tổng thời gian làm việc chỉ là 8 giờ, điều đó cho thấy có vấn đề nghiêm trọng về quy trình. Chi phí dựa trên hoạt động tương tự, nhưng tập trung vào chi phí liên quan đến mỗi bước trong quy trình, giúp xác định các hoạt động tốn kém nhất để tối ưu hóa. Đo điểm chuẩn không chính thức liên quan đến việc nghiên cứu cách các tổ chức khác thực hiện các quy trình tương tự để học hỏi và áp dụng các ý tưởng cải tiến. BPI giúp tổ chức tối ưu hóa hệ thống mới bằng cách tái cấu trúc các quy trình theo hướng hiệu quả và hiệu suất hơn, đặc biệt khi triển khai hệ thống thông tin mới.

3.3. Tái cấu trúc quy trình nghiệp vụ BPR Thay đổi đột phá

Tái cấu trúc quy trình nghiệp vụ (BPR) đại diện cho một cách tiếp cận cấp tiến, nhằm tạo ra sự thay đổi đột phá bằng cách định hình lại hoàn toàn cách thức tổ chức vận hành. Khác với BPA và BPI, BPR không chỉ cải thiện mà còn phá vỡ và xây dựng lại các quy trình kinh doanh cơ bản để tận dụng tối đa các ý tưởng và công nghệ mới. Các dự án BPR thường dành ít thời gian để hiểu hệ thống hiện tại, mà tập trung vào việc tạo ra một tầm nhìn mới cho doanh nghiệp. Ba hoạt động BPR phổ biến là phân tích kết quả, phân tích công nghệloại bỏ hoạt động. Phân tích kết quả tập trung vào việc hiểu các kết quả cốt lõi mang lại giá trị cho khách hàng, thay vì các bước quy trình truyền thống. Phân tích công nghệ bắt đầu bằng việc xác định các công nghệ mới và tiềm năng, sau đó tìm cách áp dụng chúng vào quy trình kinh doanh để tạo ra lợi ích. Loại bỏ hoạt động là việc loại bỏ hoàn toàn các hoạt động không cần thiết hoặc có thể được tối ưu hóa thông qua các phương tiện khác. BPR tiềm ẩn rủi ro cao vì mức độ thay đổi lớn, nhưng cũng mang lại tiềm năng lợi ích xác định yêu cầu và giá trị kinh doanh đột phá, thay đổi bản chất của doanh nghiệp và tạo ra hệ thống thông tin mới có tính cạnh tranh cao.

IV. Kỹ thuật thu thập yêu cầu hệ thống Từ phỏng vấn đến JAD hiệu quả

Sau khi xác định chiến lược phân tích yêu cầu nghiệp vụ, bước tiếp theo là áp dụng các kỹ thuật thu thập yêu cầu hệ thống để có được thông tin chi tiết từ người dùng và các bên liên quan. Giống như một thám tử, nhà phân tích cần thu thập các manh mối để khám phá giải pháp. Quá trình này không chỉ là về việc lấy thông tin mà còn về việc xây dựng sự tin tưởng và mối quan hệ với stakeholder, những người có thể ảnh hưởng hoặc bị ảnh hưởng bởi hệ thống. Việc bỏ qua một stakeholder quan trọng có thể dẫn đến các vấn đề nghiêm trọng trong giai đoạn triển khai. Không có một kỹ thuật nào là hoàn hảo cho mọi trường hợp; hầu hết các dự án đều sử dụng kết hợp nhiều kỹ thuật khác nhau, tận dụng điểm mạnh của từng loại. Năm kỹ thuật phổ biến nhất để thu thập yêu cầu hệ thống bao gồm phỏng vấn yêu cầu, phát triển ứng dụng chung (JAD), bảng câu hỏi, phân tích tài liệuquan sát. Mỗi kỹ thuật có ưu và nhược điểm riêng, và việc lựa chọn phù hợp sẽ giúp quy trình xác định yêu cầu diễn ra suôn sẻ, đảm bảo Business Analyst (BA) có được bức tranh toàn cảnh về nhu cầu của hệ thống mới.

4.1. Phỏng vấn yêu cầu Bí quyết để có thông tin chi tiết

Phỏng vấn yêu cầu là kỹ thuật thu thập yêu cầu hệ thống được sử dụng rộng rãi nhất. Quá trình này bao gồm các bước: lựa chọn người được phỏng vấn, thiết kế câu hỏi, chuẩn bị, thực hiện cuộc phỏng vấn và theo dõi sau phỏng vấn. Việc lựa chọn người được phỏng vấn cần dựa trên nhu cầu thông tin, đảm bảo có được cái nhìn từ nhiều cấp độ trong tổ chức, từ quản lý cấp cao đến nhân viên thực hiện. Các loại câu hỏi gồm: câu hỏi đóng (cần câu trả lời cụ thể), câu hỏi mở (khuyến khích người được phỏng vấn chia sẻ rộng rãi) và câu hỏi thăm dò (tìm hiểu sâu hơn, làm rõ thông tin). Một Business Analyst (BA) giỏi sẽ sử dụng kết hợp các loại câu hỏi và sắp xếp chúng theo một chuỗi logic (từ trên xuống hoặc từ dưới lên). Trong quá trình thực hiện, điều quan trọng là xây dựng mối quan hệ, ghi chép cẩn thận và liên tục tóm tắt để tránh hiểu lầm. Sau phỏng vấn, cần lập báo cáo phỏng vấn và gửi cho người được phỏng vấn để xác minh, đảm bảo thông tin chính xác. Đây là bí quyết để có được thông tin chi tiết và sâu sắc về yêu cầu nghiệp vụ.

4.2. Phát triển ứng dụng chung JAD Cộng tác tối ưu

Phát triển ứng dụng chung (JAD) là một kỹ thuật thu thập yêu cầu hệ thống mạnh mẽ, cho phép nhóm dự án, người dùng và quản lý làm việc cùng nhau để xác định yêu cầu cho hệ thống mới. IBM đã phát triển kỹ thuật này, và Capers Jones đã tuyên bố rằng JAD có thể giảm tình trạng "scope creep" (phạm vi dự án bị mở rộng) đến 50%. JAD là một quy trình có cấu trúc, nơi từ 10 đến 20 stakeholder họp lại dưới sự chỉ đạo của một người điều phối JAD có kỹ năng. Người điều phối chịu trách nhiệm điều hành cuộc thảo luận, duy trì tính trung lập và đảm bảo phiên họp đi đúng hướng, trong khi các người ghi chép (scribe) ghi lại thông tin. Workshop yêu cầu JAD thường diễn ra trong vài giờ đến vài tuần, tập trung vào việc tích hợp thông tin khi nó được thu thập. JAD điện tử (e-JAD) là một hình thức mới giúp khắc phục các vấn đề truyền thống của nhóm bằng cách cho phép người tham gia gửi ý kiến ẩn danh. Việc lựa chọn thành viên JAD cần đảm bảo sự đa dạng về cấp độ tổ chức và chuyên môn, đồng thời xây dựng sự hỗ trợ chính trị cho hệ thống mới. JAD là một phương pháp cộng tác tối ưu để đặc tả yêu cầu phần mềm.

4.3. Các kỹ thuật thu thập yêu cầu khác Quan sát Tài liệu Bảng hỏi

Ngoài phỏng vấn và JAD, còn có các kỹ thuật thu thập yêu cầu khác rất hữu ích. Bảng câu hỏi (questionnaires) là một bộ câu hỏi bằng văn bản, thường được sử dụng khi cần thu thập thông tin và ý kiến từ một số lượng lớn người, đặc biệt là với các hệ thống được sử dụng bởi khách hàng hoặc người dùng phân tán về mặt địa lý. Việc thiết kế câu hỏi rõ ràng và quản lý tốt tỷ lệ phản hồi là rất quan trọng. Phân tích tài liệu liên quan đến việc xem xét các tài liệu hiện có của tổ chức như báo cáo, ghi nhớ, hướng dẫn chính sách, tài liệu đào tạo và giao diện người dùng hệ thống hiện tại. Kỹ thuật này giúp hiểu hệ thống chính thức và không chính thức, đồng thời xác định những điểm cần cải thiện từ các sai lệch hoặc thiếu sót. Cuối cùng, quan sát là hành động theo dõi trực tiếp các quy trình đang được thực hiện. Nó cung cấp cái nhìn thực tế về cách mọi thứ diễn ra, giúp kiểm tra tính hợp lệ của thông tin thu thập được từ các nguồn khác. Mặc dù cần lưu ý rằng hành vi của người được quan sát có thể thay đổi khi có sự hiện diện của nhà phân tích, quan sát vẫn là một công cụ mạnh mẽ để hiểu rõ hệ thống hiện tạixác định yêu cầu nghiệp vụ.

V. Ứng dụng thực tiễn trong xác định yêu cầu và quản lý dự án

Việc xác định yêu cầu nghiệp vụ không chỉ dừng lại ở việc thu thập thông tin mà còn phải chuyển hóa chúng thành các sản phẩm cụ thể và khả thi, đồng thời quản lý yêu cầu dự án xuyên suốt vòng đời. Các thông tin thu thập được từ các kỹ thuật phân tích và thu thập yêu cầu sẽ được tổng hợp và tài liệu hóa một cách cẩn thận, tạo thành nền tảng cho giai đoạn thiết kế và triển khai. Một trong những sản phẩm quan trọng nhất từ giai đoạn này là tài liệu đặc tả yêu cầu (BRD/SRS), vốn định nghĩa phạm vi và các chức năng của hệ thống. Bên cạnh đó, việc quản lý chặt chẽ các thay đổi đối với yêu cầu là vô cùng cần thiết để tránh tình trạng "scope creep" – một trong những nguyên nhân hàng đầu gây ra sự chậm trễ và vượt ngân sách dự án. Quản lý thay đổi yêu cầu hiệu quả đòi hỏi một quy trình rõ ràng và sự tham gia tích cực của chủ sở hữu sản phẩm (product owner). Các công cụ và phần mềm quản lý yêu cầu cũng đóng vai trò quan trọng trong việc theo dõi, ưu tiên và kiểm soát các yêu cầu, đảm bảo chúng luôn được cập nhật và phù hợp với mục tiêu kinh doanh. Việc ứng dụng thực tiễn các nguyên tắc này giúp dự án không chỉ đạt được các mục tiêu kỹ thuật mà còn mang lại giá trị kinh doanh tối đa.

5.1. Xây dựng tài liệu đặc tả yêu cầu BRD SRS chuẩn chỉnh

Sau khi thu thập yêu cầu hệ thốngphân tích yêu cầu nghiệp vụ, các yêu cầu cần được tài liệu hóa một cách chính xác và chi tiết. Tài liệu đặc tả yêu cầu (BRD/SRS) là bản báo cáo văn bản liệt kê các yêu cầu chức năngyêu cầu phi chức năng trong một định dạng có cấu trúc. Mục đích chính của tài liệu này là cung cấp một sự hiểu biết đáng tin cậy về các yêu cầu nghiệp vụ, làm cơ sở cho các giai đoạn thiết kế và phát triển. Tài liệu này giúp đặc tả yêu cầu phần mềm một cách rõ ràng, tránh hiểu lầm giữa các bên liên quan. Các yêu cầu thường được phân loại theo chức năng và loại yêu cầu phi chức năng, sau đó được ưu tiên dựa trên tầm quan trọng. Theo tài liệu gốc, việc bỏ qua các yêu cầu phi chức năng trong BRD có thể dẫn đến những rủi ro lớn và chi phí phát sinh đáng kể sau này. Một BRD/SRS chuẩn chỉnh không chỉ là một danh sách yêu cầu mà còn là một công cụ quan trọng để định nghĩa phạm vi hệ thống, là điểm tham chiếu khi có bất kỳ sự khác biệt nào phát sinh trong quá trình triển khai.

5.2. Quản lý thay đổi yêu cầu và phạm vi dự án hiệu quả

Quản lý thay đổi yêu cầu là một khía cạnh cực kỳ khó khăn nhưng không thể thiếu trong quản lý yêu cầu dự án. Yêu cầu không phải là tĩnh; chúng phát triển theo thời gian khi dự án tiến triển và khi các yêu cầu mới được xác định. Nếu không được quản lý cẩn thận, việc liên tục bổ sung yêu cầu (còn gọi là "scope creep") có thể khiến hệ thống không bao giờ hoàn thành hoặc vượt quá ngân sách và thời gian nghiêm trọng. Nhóm dự án cần cẩn thận xác định những yêu cầu nào nằm trong phạm vi dự án hiện tại và những yêu cầu nào nên được ưu tiên thấp hoặc đưa vào các phiên bản tương lai. Ma trận truy vết yêu cầu là một công cụ hữu ích để theo dõi mối liên hệ giữa các yêu cầu, thiết kế và kiểm thử, giúp đảm bảo mọi thay đổi đều được kiểm soát. Vai trò của chủ sở hữu sản phẩm (product owner) trong các phương pháp Agile càng trở nên quan trọng, họ là người chịu trách nhiệm chính trong việc ưu tiên và chấp thuận các thay đổi yêu cầu, đảm bảo hệ thống mới vẫn đi đúng hướng và đáp ứng mục tiêu kinh doanh cốt lõi. Việc quản lý thay đổi yêu cầu hiệu quả giúp giảm thiểu rủi ro yêu cầu không rõ ràng và tối đa hóa giá trị của dự án.

VI. Kết luận Thành công bền vững khi xác định yêu cầu nghiệp vụ

Tổng kết lại, việc xác định yêu cầu nghiệp vụ cho hệ thống mới không chỉ là một bước khởi đầu mà còn là yếu tố quyết định đến thành công bền vững của toàn bộ dự án. Từ việc hiểu rõ định nghĩa, phân loại yêu cầu chức năngphi chức năng, đến việc đối mặt với các thách thức và áp dụng các phương pháp phân tích yêu cầu nghiệp vụ như BPA, BPI, BPR, cũng như các kỹ thuật thu thập yêu cầu hệ thống như phỏng vấn, JAD, bảng câu hỏi, phân tích tài liệu và quan sát—mỗi giai đoạn đều đóng góp vào việc hình thành một bức tranh rõ ràng về hệ thống cần xây dựng. Sự hợp tác chặt chẽ giữa các chuyên gia nghiệp vụ và nhà phân tích, cùng với việc quản lý thay đổi yêu cầuphạm vi dự án một cách hiệu quả, là yếu tố then chốt để biến những mong muốn thành hiện thực. Một bản đặc tả yêu cầu phần mềm chuẩn chỉnh không chỉ là tài liệu kỹ thuật mà còn là cam kết về giá trị mà hệ thống sẽ mang lại. Việc đầu tư vào giai đoạn này giúp tổ chức giảm thiểu rủi ro yêu cầu không rõ ràng, tối ưu hóa chi phí và tài nguyên, đồng thời đảm bảo rằng hệ thống thông tin mới sẽ thực sự phục vụ mục tiêu kinh doanh và mang lại lợi ích xác định yêu cầu rõ ràng. Khi các yêu cầu được định nghĩa và quản lý tốt, khả năng hệ thống đạt được các mục tiêu kinh doanh và làm hài lòng người dùng sẽ tăng lên đáng kể.

6.1. Lợi ích xác định yêu cầu rõ ràng cho hệ thống mới

Việc xác định yêu cầu nghiệp vụ rõ ràng mang lại hàng loạt lợi ích không chỉ cho dự án mà còn cho toàn bộ tổ chức. Thứ nhất, nó giảm thiểu đáng kể khả năng rủi ro yêu cầu không rõ ràng, vốn là nguyên nhân chính gây chậm trễ và vượt ngân sách. Thứ hai, một bộ yêu cầu được xác định tốt cho phép các nhóm phát triển và thiết kế có định hướng rõ ràng, dẫn đến việc xây dựng một hệ thống mới chất lượng cao hơn, đáp ứng chính xác nhu cầu của người dùng. Thứ ba, sự minh bạch trong yêu cầu tạo điều kiện cho việc quản lý yêu cầu dự án hiệu quả hơn, từ lập kế hoạch, phân bổ nguồn lực đến kiểm thử và triển khai. Cuối cùng, khi người dùng và các stakeholder tham gia tích cực vào quá trình thu thập yêu cầu hệ thống, họ sẽ có cảm giác sở hữu và chấp nhận hệ thống cao hơn, từ đó đảm bảo tỷ lệ sử dụng và thành công của hệ thống sau khi triển khai. Các lợi ích này góp phần vào việc tạo ra một môi trường làm việc hiệu quả và thành công bền vững cho tổ chức.

6.2. Tương lai của phân tích nghiệp vụ Thích ứng với công nghệ

Tương lai của phân tích nghiệp vụ hứa hẹn sự tiến hóa không ngừng, đòi hỏi các Business Analyst (BA) phải liên tục thích ứng với công nghệ mới và các phương pháp phát triển linh hoạt. Với sự phát triển của Trí tuệ nhân tạo, Học máy và Phân tích dữ liệu lớn, vai trò của BA sẽ ngày càng chuyển dịch từ việc chỉ thu thập yêu cầu sang việc trở thành người tư vấn chiến lược, giúp tổ chức khám phá các cơ hội đổi mới và định hình lại quy trình kinh doanh. Các phương pháp phát triển Agile và lặp lại sẽ tiếp tục được áp dụng rộng rãi, đòi hỏi BA phải có khả năng làm việc trong môi trường năng động, nhanh chóng ưu tiên và điều chỉnh các yêu cầu. Việc sử dụng phần mềm quản lý yêu cầu chuyên dụng, các công cụ mô hình hóa và tự động hóa sẽ trở thành tiêu chuẩn để nâng cao hiệu quả và độ chính xác của quá trình đặc tả yêu cầu phần mềm. Để duy trì sự phù hợp, BA cần không ngừng học hỏi, phát triển kỹ năng phân tích nghiệp vụ sâu sắc, khả năng giao tiếp xuất sắc và tư duy phản biện để dẫn dắt các dự án hệ thống thông tin mới đi đến thành công trong một thế giới kỹ thuật số luôn thay đổi.

30/09/2025

Trích đoạn nội dung tài liệu

Chương 1 và 2) hầu như chỉ tập trung vào các cải tiến và các yêu cầu hệ thống, và họ dành ít thời gian để điều tra hệ thống hiện tại. Ba chiến lược phân tích yêu cầu Tự động hóa quy trình kinh doanh, quy trình kinh doanh cải thiện và tái cấu trúc quy trình kinh doanh giúp các nhà phân tích dẫn dắt người dùng thông qua ba (hoặc hai) bước phân tích để có thể phát triển tầm nhìn của hệ thống. Yêu cầuc hiến lược phân tích và kỹ thuật thu thập yêu cầu đi đôi với nhau. Các nhà phân tích cần sử dụng các kỹ thuật thu thập yêu cầu để thu thập thông tin; phân tích yêu cầu các chiến lược thúc đẩy loại thông tin được thu thập và cách thức phân tích cuối cùng.Mặc dù bây giờ chúng ta tập trung vào các chiến lược phân tích và sau đó thảo luận về thu thập yêu cầu ở cuối chương, chúng xảy ra đồng thời và là hoạt động bổ trợ.

Việc lựa chọn kỹ thuật phân tích được sử dụng dựa trên lượng thay đổi của hệ thống có nghĩa là để tạo ra trong tổ chức. BPA dựa trên thay đổi nhỏ giúp cải thiện quy trình hiệu quả, BPI tạo ra các cải tiến quy trình dẫn đến hiệu quả tốt hơn và BPR sửa đổi cách mọi thứ hoạt động để tổ chức được chuyển đổi ở một mức độ nào đó.Để di chuyển người dùng từ đây đến kia, một nhà phân tích cần có kỹ năng tư duy phản biện mạnh mẽ.Tư duy phản biện là khả năng nhận ra điểm mạnh và điểm yếu và làm lại một ý tưởng trong một hình thức cải tiến, và kỹ năng tư duy phê phán là cần thiết để thực sự hiểu vấn đề và phát triển các quy trình nghiệp vụ mới. Những kỹ năng này cũng cần thiết để kiểm tra kỹ lưỡng kết quả thu thập các yêu cầu, để xác định các yêu cầu nghiệp vụ và để dịch các yêu cầu đó thành một khái niệm cho hệ thống mới Tự động hóa quy trình kinh doanh BPA rời khỏi cách cơ bản trong đó tổ chức hoạt động không thay đổi và sử dụng máy tính công nghệ để làm một số công việc. BPA có thể làm cho tổ chức hiệu quả hơn nhưng ít ảnh hưởng đến doanh nghiệp.

Các nhà hoạch định trong các dự án BPA dành một khoảng thời gian đáng kể giữ nguyên hệ thống hiện tại trước khi chuyển sang cải tiến và trở thành hệ thống yêu cầu. Phân tích vấn đề và phân tích nguyên nhân gốc là hai kỹ thuật BPA phổ biến. Phân tích vấn đề Đơn giản nhất (và có lẽ được sử dụng phổ biến nhất)yêu cầu kỹ thuật phân tích là phân tích vấn đề. Phân tích vấn đề có nghĩa là yêu cầu người dùng và người quản lý xác định sự cố với hệ thống tương tự và để mô tả cách giải quyết chúng trong hệ thống tương lai.

Hầu hết người dùng có một ý tưởng rất tốt về những thay đổi họ sẽ muốn xem, và hầu hết sẽ khá kín tiếng về việc đề xuất chúng. Nhiều thay đổi có xu hướng giải quyết vấn đề hơn là tận dụng các cơ hội, nhưng sau này cũng có thể. Các cải tiến từ phân tích vấn đề có xu hướng nhỏ và tăng dần (ví dụ: cung cấp nhiều không gian hơn trong việc gõ địa chỉ khách hàng của bạn; cung cấp một báo cáo mới hiện không tồn tại).Loại cải tiến này thường rất hiệu quả trong việc cải thiện hiệu quả của hệ thống hoặcdễ sử dụng. Tuy nhiên, nó thường chỉ cung cấp những cải tiến nhỏ về giá trị kinh doanh, hệ thống mới tốt hơn hệ thống cũ, nhưng có thể khó xác định tiền tệ quan trọng lợi ích từ hệ thống mới.

Phân tích nguyên nhân gốc rễ các ý tưởng được tạo ra bởi phân tích vấn đề có xu hướng là giải pháp cho các vấn đề. Tất cả các giải pháp đưa ra các giả định về bản chất của vấn đề, các giả định điều đó có thể hoặc không thể hợp lệ. Theo kinh nghiệm của chúng tôi, người dùng (và hầu hết mọi người nói chung) có xu hướng nhanh chóng nhảy vào giải pháp mà không xem xét đầy đủ bản chất của vấn đề. Đôi khi các giải pháp là phù hợp, nhưng nhiều lần chúng giải quyết một triệu chứng của vấn đề, không phải vấn đề thực sự hoặc nguyên nhân gốc rễ.Ví dụ, giả sử chúng ta nhận thấy rằng một bóng đèn bị đốt cháy phía trên cửa trước của chúng ta.Chúng tôi mua một bóng đèn mới, lấy ra một cái thang và thay thế bóng đèn.

Một tháng sau, chúng tôi thấy rằng cùng một bóng đèn bị đốt cháy, vì vậy chúng tôi mua một bóng đèn mới, lôi thang ra và thay thế nó một lần nữa.Điều này xảy ra nhiều lần. Tại thời điểm này, chúng tôi có hai lựa chọn. Chúng tôi có thể mua một gói lớn của bóng đèn và một bộ đổi bóng đèn lạ mắt trên một cây sào dài, vì vậy chúng tôi không cần phải chuyên chở thang ra mỗi lần (do đó tiết kiệm rất nhiều chuyến đi đến cửa hàng cho bóng đèn mới và rất nhiều nỗ lực khi làm việc với thang). Hoặc, chúng ta có thể kết hợp ánh sáng đang làm cho ánh sáng bị đốt cháy ở vị trí đầu tiên.

Mua bộ đổi bóng đèn đang điều trị triệu chứng (kiệt sức bóng đèn), trong khi việc lắp đặt đang điều trị nguyên nhân gốc rễ.Trong thế giới kinh doanh, thách thức nằm ở việc xác định nguyên nhân gốc rễ của vài vấn đề.đơn giản như vấn đề bóng đèn. Các giải pháp mà người dùng đề xuất (hoặc hệ thống các nhà phân tích nghĩ về) có thể giải quyết các triệu chứng hoặc nguyên nhân gốc rễ, nhưng không có phân tích cẩn thận,thật khó để nói cái nào được giải quyết. Và phát hiện ra rằng chúng ta vừa chi một triệuđô la trên một thay đổi bóng đèn mới là một cảm giác khủng khiếp! Phân tích nguyên nhân gốc rễ, do đó, tập trung vào các vấn đề, không phải giải pháp. Nhà phân tích bắt đầu bằng việc người dùng tạo ra một danh sách các vấn đề với hệ thống hiện tại và sau đó ưu tiên Các vấn đề theo thứ tự quan trọng.

Bắt đầu với điều quan trọng nhất, người dùng và / hoặc các nhà phân tích sau đó tạo ra tất cả các nguyên nhân gốc có thể cho các vấn đề. Mỗi gốc rễ có thể được điều tra nguyên nhân (bắt đầu với khả năng dễ kiểm tra nhất) cho đến khi nguyên nhân được xác định. Nếu có bất kỳ nguyên nhân gốc nào có thể được xác định cho một số vấn đề, thì đó là những nguyên nhân nên được điều tra đầu tiên, bởi vì rất có thể chúng là nguyên nhân gốc rễ thực sự trong việc giải quyết các vấn đề về triệu chứng. Trong ví dụ về bóng đèn của chúng tôi, có một số nguyên nhân gốc gây ra.

Một số cây quyết định đôi khi giúp phân tích. Như Hình 4-3 cho thấy, có nhiều nguyên nhân gốc có thể, vì vậy mua một cấu trúc mới có thể hoặc không thể giải quyết nguyên nhân gốc thực sự. Trong thực tế, mua một bóng đèn thay đổi thực sự có thể giải quyết nguyên nhân gốc. Điểm mấu chốt trong phân tích nguyên nhân gốc luôn là thách thức sự rõ ràng.

Cải thiện qua trình nghiệp vụ BPI thực hiện các thay đổi vừa phải đối với cách thức tổ chức hoạt động để tận dụng các cơ hội mới được cung cấp bởi công nghệ hoặc sao chép những gì đối thủ đang làm.BPI có thể cải thiện hiệu quả (nghĩa là, làm đúng) và nâng cao hiệu quả (nghĩa là, làm những điều đúng đắn). Các nhà hoạch định dự án BPI cũng dành thời gian để hiểu hệ thống tương tự,nhưng ít thời gian hơn nhiều so với các dự án BPA; trọng tâm chính của họ là cải thiện các quy trình nghiệp vụ, vì vậy thời gian chỉ để giúp phân tích cải tiến và để được yêu cầu hệ thống. Phân tích thời lượng, chi phí dựa trên hoạt động và băng ghế không chính thức đánh dấu là ba hoạt động phổ biến của BPI. Phân tích thời lƣợng Phân tích thời lượng yêu cầu kiểm tra chi tiết số lượng cần có thời gian để thực hiện từng quy trình trong hệ thống hiện tại.

Các nhà phân tích bắt đầu bởi trung bình xác định tổng thời gian cần thiết để thực hiện một bộ kinh doanh các quy trình cho một đầu vào điển hình. Sau đó, họ tính thời gian cho từng bước riêng lẻ (hoặc quy trình phụ) trong quy trình kinh doanh. Tổng thời gian để hoàn thành các bước cơ bản được tính tổng và so với tổng số quá trình tổng thể. Một sự khác biệt đáng kể giữa hai qua trình và theo kinh nghiệm của chúng tôi, tổng thời gian thường có thể dài hơn 10 hoặc thậm chí 100 lần so với tổng của các phần mà chỉ ra rằng phần này của quá trình rất cần một chuyên ngành để nghiên cứu.

Ví dụ: giả sử rằng các nhà phân tích đang làm việc trên một hệ thống thế chấp nhà và khám phá ra rằng trung bình, phải mất ba mươi ngày để ngân hàng phê duyệt thế chấp. Họ sau đó xem xét từng bước cơ bản trong quy trình (ví dụ: nhập dữ liệu, kiểm tra tín dụng, tìm kiếm tiêu đề,thẩm định, v.) và thứ năm rằng tổng số thời gian thực sự dành cho mỗi khoản thế chấp là khoảng tám giờ. Đây là một dấu hiệu mạnh mẽ cho thấy quá trình tổng thể bị phá vỡ nghiêm trọng,bởi vì phải mất ba mươi ngày để thực hiện một ngày làm việc. Những vấn đề này có thể xảy ra do quá trình bị phân mảnh kém.

Nhiều người khác nhau phải thực hiện các hoạt động khác nhau trước khi quá trình kết thúc. VD Trong thế chấp, ứng dụng có thể nằm trên bàn của nhiều người trong thời gian dài trước khi nó được xử lý.Các quy trình trong đó nhiều người khác nhau làm việc trên các phần nhỏ của đầu vào là ứng cử viên chính cho quá trình tích hợp hoặc song song hóa. Quá trình tích hợp có nghĩa là thay đổi quy trình cơ bản để ít người làm việc hơn với đầu vào, thường là yêu cầu thay đổi các quy trình và đào tạo lại nhân viên để thực hiện một loạt các nhiệm vụ.Song song hóa quá trình có nghĩa là thay đổi quy trình sao cho tất cả các bước riêng lẻ thực hiện cùng một lúc. Ví dụ, trong trường hợp ứng dụng thế chấp, có có lẽ không có lý do nào mà việc kiểm tra tín dụng không thể được thực hiện cùng lúc với thẩm định và kiểm tra tiêu đề.

Nội dung được bảo vệ bản quyền — Tải xuống đầy đủ