Phân tích kinh doanh - Yêu cầu Mngmt

Thu thập các yêu cầu phần mềm là nền tảng của toàn bộ dự án phát triển phần mềm. Thu thập và thu thập các yêu cầu kinh doanh là bước đầu tiên quan trọng cho mọi dự án. Để thu hẹp khoảng cách giữa các yêu cầu kinh doanh và kỹ thuật, các nhà phân tích kinh doanh phải hiểu đầy đủ các nhu cầu kinh doanh trong bối cảnh nhất định, điều chỉnh các nhu cầu này với các mục tiêu kinh doanh và truyền đạt đúng nhu cầu cho cả các bên liên quan và nhóm phát triển.

Các bên liên quan chính mong muốn ai đó có thể giải thích các yêu cầu của khách hàng / khách hàng bằng tiếng Anh đơn giản. Điều này có mang lại lợi ích cho họ khi hiểu giá trị ở cấp độ cao không? Đây sẽ là lĩnh vực trọng tâm chính, vì họ sẽ cố gắng lập bản đồ tài liệu với các yêu cầu và cách BA có thể giao tiếp theo cách tốt nhất có thể.

Tại sao dự án thất bại

Có nhiều lý do tại sao các dự án thất bại nhưng một số lĩnh vực phổ biến bao gồm:

• Thị trường và Chiến lược thất bại
• Tổ chức và lập kế hoạch thất bại
• Chất lượng không đạt
• Thất bại trong lãnh đạo và quản trị
• Kỹ năng, kiến ​​thức và không đạt năng lực
• Tương tác, làm việc nhóm và thất bại trong giao tiếp

Cốt lõi của vấn đề là các dự án ngày càng phức tạp, thay đổi xảy ra và giao tiếp là thách thức.

Tại sao các nhóm thành công thực hiện Quản lý yêu cầu

Quản lý yêu cầu là giữ cho nhóm của bạn in-sync và cung cấp visibility về những gì đang diễn ra trong một dự án.

Điều quan trọng đối với sự thành công của các dự án của bạn là toàn bộ nhóm của bạn phải hiểu những gì bạn đang xây dựng và tại sao - đó là cách chúng tôi xác định quản lý yêu cầu. “Tại sao” quan trọng vì nó cung cấp bối cảnh cho các mục tiêu, phản hồi và quyết định được đưa ra về các yêu cầu.

Điều này làm tăng khả năng dự đoán về thành công trong tương lai và các vấn đề tiềm ẩn, cho phép nhóm của bạn nhanh chóng khắc phục mọi vấn đề và hoàn thành thành công dự án của bạn đúng thời hạn và trong phạm vi ngân sách. Như một điểm khởi đầu, điều có giá trị đối với tất cả những người tham gia là có hiểu biết cơ bản về các yêu cầu là gì và cách quản lý chúng.

Hãy bắt đầu với những điều cơ bản

Yêu cầu là một điều kiện hoặc khả năng cần thiết của một bên liên quan để giải quyết một vấn đề hoặc đạt được một mục tiêu. Một điều kiện hoặc khả năng phải được đáp ứng hoặc sở hữu bởi một hệ thống hoặc hệ thống. Thành phần để đáp ứng hợp đồng, tiêu chuẩn, đặc điểm kỹ thuật hoặc các tài liệu áp đặt chính thức khác.

Một yêu cầu có thể được thể hiện bằng văn bản, bản phác thảo, mô hình hoặc mô hình chi tiết, bất kỳ thông tin nào truyền đạt tốt nhất cho kỹ sư những gì cần xây dựng và cho người quản lý QA những gì cần kiểm tra. Tùy thuộc vào quá trình phát triển của bạn, bạn có thể sử dụng các thuật ngữ khác nhau để nắm bắt các yêu cầu.

Các yêu cầu cấp cao đôi khi được gọi đơn giản là needs hoặc là goals. Trong thực tiễn phát triển phần mềm, các yêu cầu có thể được gọi là “ca sử dụng”, “tính năng” hoặc “yêu cầu chức năng”. Thậm chí cụ thể hơn trong các phương pháp luận phát triển nhanh, các yêu cầu thường được nắm bắt nhưepics và stories.

Bất kể nhóm của bạn gọi họ là gì hoặc bạn sử dụng quy trình nào; các yêu cầu cần thiết cho sự phát triển của tất cả các sản phẩm. Nếu không xác định rõ các yêu cầu, bạn có thể tạo ra một sản phẩm không hoàn chỉnh hoặc bị lỗi. Trong suốt quá trình, có thể có nhiều người tham gia vào việc xác định các yêu cầu.

Một bên liên quan có thể yêu cầu một tính năng mô tả cách sản phẩm sẽ cung cấp giá trị trong việc giải quyết một vấn đề. Một nhà thiết kế có thể xác định một yêu cầu dựa trên cách sản phẩm cuối cùng trông hoặc hoạt động như thế nào từ quan điểm về khả năng sử dụng hoặc giao diện người dùng.

Một nhà phân tích kinh doanh có thể tạo ra một yêu cầu hệ thống tuân theo các ràng buộc kỹ thuật hoặc tổ chức cụ thể. Đối với các sản phẩm và ứng dụng phần mềm phức tạp ngày nay đang được xây dựng, thường cần hàng trăm hoặc hàng nghìn yêu cầu để xác định đủ phạm vi của một dự án hoặc một bản phát hành. Do đó, nhóm bắt buộc phải có khả năng truy cập, cộng tác, cập nhật và kiểm tra từng yêu cầu cho đến khi hoàn thành, vì các yêu cầu tự nhiên thay đổi và phát triển theo thời gian trong quá trình phát triển.

Bây giờ chúng ta đã xác định giá trị của việc quản lý yêu cầu ở cấp cao, hãy đi sâu hơn vào bốn nguyên tắc cơ bản mà mọi thành viên trong nhóm và các bên liên quan có thể hưởng lợi từ sự hiểu biết -

• Lập kế hoạch yêu cầu tốt: "Chúng ta đang xây dựng cái quái gì vậy?"
• Hợp tác và mua vào: “Chỉ cần phê duyệt thông số kỹ thuật!”
• Truy xuất nguồn gốc và quản lý thay đổi: “Chờ đã, các nhà phát triển có biết điều đó đã thay đổi không?”
• Đảm bảo chất lượng: "Xin chào, có ai thử nghiệm điều này không?"

Mọi người có biết chúng tôi đang xây dựng cái gì không và tại sao không? Đó là giá trị của quản lý yêu cầu.

Hợp tác và Mua hàng từ các Bên liên quan

Mọi người có ở trong vòng lặp không? Chúng tôi có chấp thuận về các yêu cầu để tiếp tục không? Những câu hỏi này xuất hiện trong các chu kỳ phát triển. Sẽ thật tuyệt nếu mọi người có thể đồng ý về các yêu cầu, nhưng đối với các dự án lớn với nhiều bên liên quan, điều này thường không xảy ra. Cố gắng để mọi người đồng ý có thể khiến các quyết định bị trì hoãn, hoặc tệ hơn là không thực hiện được. Đạt được sự đồng thuận trong mọi quyết định không phải lúc nào cũng dễ dàng.

Trên thực tế, bạn không nhất thiết phải muốn có “sự đồng thuận”, mà bạn muốn “mua vào” từ nhóm và sự chấp thuận từ những người kiểm soát để bạn có thể tiến hành dự án. Với sự đồng thuận, bạn đang cố gắng để mọi người thỏa hiệp và đồng ý về quyết định. Với mua vào, bạn đang cố gắng kêu gọi mọi người hỗ trợ giải pháp tốt nhất, đưa ra quyết định thông minh và làm những gì cần thiết để tiến về phía trước.

Bạn không cần mọi người đồng ý rằng quyết định đó là tốt nhất. Bạn cần mọi người ủng hộ quyết định. Hợp tác nhóm có thể giúp nhận được sự hỗ trợ về các quyết định và lập kế hoạch các yêu cầu tốt.

Các nhóm cộng tác làm việc chăm chỉ để đảm bảo mọi người đều có cổ phần trong các dự án và cung cấp phản hồi. Các nhóm cộng tác liên tục chia sẻ ý tưởng, thường có giao tiếp tốt hơn và có xu hướng ủng hộ các quyết định được đưa ra vì có chung cảm giác cam kết và hiểu biết về các mục tiêu của dự án.

Đó là khi các nhà phát triển, người kiểm tra hoặc các bên liên quan khác cảm thấy “lạc lõng” thì các vấn đề giao tiếp phát sinh, mọi người cảm thấy thất vọng và các dự án bị trì hoãn. Một khi mọi người đã tham gia vào phạm vi công việc, thì bắt buộc các yêu cầu phải rõ ràng và được ghi chép đầy đủ. Theo dõi tất cả các yêu cầu là nơi mọi thứ trở nên phức tạp.

Hãy tưởng tượng có một danh sách việc cần làm dài hàng dặm bao gồm việc cộng tác với nhiều người để hoàn thành. Làm thế nào bạn sẽ giữ cho tất cả các mục đó thẳng hàng? Bạn sẽ theo dõi cách một thay đổi đối với một mục sẽ ảnh hưởng đến phần còn lại của dự án như thế nào? Đây là nơi mà việc truy xuất nguồn gốc và quản lý thay đổi gia tăng giá trị.