Rất nhiều dự án CNTT thất bại vì một lý do quen thuộc: sản phẩm làm ra không giải quyết đúng vấn đề hay cơ hội kinh doanh ban đầu. Nguyên nhân thường nằm ở yêu cầu phần mềm (software requirements). Hoặc chúng quá chung chung nên đội kỹ thuật không biết phải xây gì. Hoặc chúng tách rời khỏi nhu cầu và kết quả mong muốn của doanh nghiệp, khiến cả đội giải quyết nhầm bài toán. Hãy cùng BAC khám phá qua bài viết dưới đây.
 
 
1. Software requirements là gì?
Software requirements mô tả những khả năng mà giải pháp phải có và thông tin mà giải pháp sẽ quản lý. Đây là điểm giao nhau giữa business và công nghệ. Vì vậy chúng phải được viết sao cho:
  • Người dùng nghiệp vụ đọc là hiểu.
  • Đội kỹ thuật dựa vào đó để xây đúng thứ doanh nghiệp cần.

Làm tốt phần yêu cầu không chỉ là viết câu chữ cho hay. Yêu cầu phải khả thi để triển khai, và phải tạo ra giá trị thực cho doanh nghiệp. Sự cộng tác, việc kiểm chứng (validation), sự đồng thuận của các bên, cùng thứ ngôn ngữ ai cũng hiểu, quan trọng ngang với cú pháp và định dạng.

Theo truyền thống, trong mô hình waterfall, yêu cầu phần mềm được ghi thành các danh sách dài, phân nhóm, trong tài liệu FRS (Functional Requirements Specification) hoặc SRS (Software Requirements Specification). Chúng cũng thường là một phần đáng kể của BRD (Business Requirements Document).

 
2. Các "khuôn chứa" yêu cầu bạn có thể dùng

Ngày nay, yêu cầu phần mềm thường được ghi dưới dạng user story và quản lý trong product backlog. Đôi khi chúng được phân tích bằng use case. Nhiều đội còn nhúng backlog vào BRD, hoàn thiện từ đầu rồi quản lý backlog theo kiểu agile trong suốt quá trình triển khai.

FRS, SRS, BRD, backlog, user story hay use case thực chất chỉ là những cái khuôn khác nhau để chứa cùng một thứ: yêu cầu phần mềm. Chọn khuôn nào thường tùy vào thông lệ của tổ chức hoặc đội nhóm.

Còn tư duy hệ thống và kỹ năng cộng tác để khám phá, phân tích, kiểm chứng yêu cầu thì dùng được với mọi loại khuôn. Đây cũng là trọng tâm mà Bridging the Gap giảng dạy.
 
3. Ví dụ minh họa

Cùng một yêu cầu, mỗi cách thể hiện sẽ khác nhau.

Câu lệnh "system shall" (thường dùng trong FRS, SRS, BRD):

  • Hệ thống phải phát trực tiếp (stream) một buổi học âm thanh.

User story (trong product backlog) bổ sung thêm ngữ cảnh:

  • Là một học viên, tôi muốn nghe trực tiếp một buổi học âm thanh để có thể nghe bài giảng khi đang di chuyển.

Use case trình bày yêu cầu thành chuỗi hành động của người dùng và các bước phản hồi của hệ thống:

  • Học viên chọn nghe bài thuyết trình âm thanh.
  • Hệ thống phân phối khóa học hiển thị tệp âm thanh trong phiên web của học viên.
  • Mô hình giao diện người dùng (UI model), ví dụ wireframe, là bản mô tả trực quan về việc phần mềm sẽ trông thế nào khi người dùng cuối nhìn thấy.
 
4. Ưu và nhược điểm của từng cách
Mỗi cách đều có điểm mạnh, điểm yếu, và cách nào cũng có thể thành công.
Ưu và nhược điểm của từng cách

Câu lệnh "system shall": danh sách yêu cầu chức năng rõ ràng, dễ đọc, dễ sắp xếp, rất hữu ích cho việc đánh giá và truy vết (traceability). Nhược điểm là thường thiếu ngữ cảnh và độ cụ thể.

  • User story: gắn mục tiêu kinh doanh vào yêu cầu, giúp đội hiểu không chỉ hệ thống cần làm gì mà còn vì sao tính năng đó quan trọng. Đây cũng là công cụ lập kế hoạch tốt, cho phép ưu tiên công việc ở mức chi tiết nhỏ và ứng phó thay đổi hiệu quả hơn. Tuy nhiên, khi backlog lớn, rất dễ mất bức tranh tổng thể, và bản thân user story không hỗ trợ tư duy phân tích của bạn.
  • Use case: công cụ phân tích mạnh, khuyến khích tư duy hệ thống và hỗ trợ cộng tác giữa business và kỹ thuật. Nhưng use case dễ phình to, thêm phức tạp và lấn scope, và quãng đường từ use case đến triển khai khó quản lý.
  • Mô hình giao diện: dễ hiểu, gợi ra nhiều phản hồi giá trị và giúp cả đội nhanh chóng thống nhất về yêu cầu. Rất hợp để bổ trợ cho các cách trên. Nếu đứng riêng, nó có thể thiếu độ cụ thể và dẫn đến những giả định sai.

Học cách tư duy theo use case giúp bạn giải thích phần mềm cần làm gì bằng ngôn ngữ người dùng nghiệp vụ hiểu được, và thường ít bỏ sót yêu cầu hơn. Đồng thời, các bên liên quan nhìn thấy đầy đủ tiềm năng của giải pháp và đưa ra phản hồi làm rõ hiệu quả hơn.

 
5. Một lưu ý quan trọng
Dù bạn chọn khuôn nào, hãy nhớ: yêu cầu chức năng không phải là thiết kế kỹ thuật. Bạn không cần biết lập trình để viết yêu cầu phần mềm. Ngược lại, những người có nền tảng kỹ thuật cần học cách viết yêu cầu bằng ngôn ngữ rõ ràng mà người dùng nghiệp vụ hiểu được, và kiềm chế ý muốn chèn mã giả (pseudocode) hay chi tiết kỹ thuật vào.
 
6. Kết luận: Muốn đi sâu hơn?
Tác giả Laura Brandenburg giảng dạy các nội dung này chi tiết trong chương trình đào tạo The Business Analyst Blueprint, nơi học viên cùng trao đổi về việc đang giải quyết vấn đề gì, cách linh hoạt vận dụng kỹ năng với từng loại đội nhóm, và cách tận dụng AI trong quy trình. Bài gốc cũng có các video hướng dẫn về user story, use case và wireframe, cùng một mẫu use case miễn phí trong bộ BA Deliverables Collection. Hãy theo dõi BAC's Blog để cập nhật thêm nhiều thông tin hữu ích nhé!

Nhu cầu đào tạo doanh nghiệp

BAC là đơn vị đào tạo BA đầu tiên tại Việt Nam. Đối tác chính thức của IIBA quốc tế. Ngoài các khóa học public, BAC còn có các khóa học in house dành riêng cho từng doanh nghiệp. Chương trình được thiết kế riêng theo yêu cầu của doanh nghiệp, giúp doanh nghiệp giải quyết những khó khăn và tư vấn phát triển.
 

CÁC KHOÁ HỌC BUSINESS ANALYST BACs.VN DÀNH CHO BẠN

Khoá học Online:

Khoá học Offline:

Tại Tp.HCM:

Tại Hà Nội:

Tham khảo lịch khai giảng TẤT CẢ các khóa học mới nhất

Ban biên tập nội dung - BAC