Ba loại tài liệu một BA trong domain IT cần tập trung

Viết tài liệu là một trong những công việc khá mệt mỏi và chiếm nhiều thời gian của một bạn BA làm việc trong domain IT. Trong lịch sử phát triển của BA trong domain IT, có rất nhiều loại tài liệu được sinh ra và cũng nhiều loại tài liệu được mất đi. Như thuyết tiến hóa của Charles Darwin, tài liệu của BA trong domain IT cũng dần dà có được sự chọn lọc tự nhiên và tinh gọn lại nhằm có thể gom, gộp nhiều loại tài liệu thành 01. Bên cạnh đó, còn giúp đảm bảo việc mô tả sản phẩm, dự án hoàn chỉnh. Cuối cùng, là để việc truyền lại cho đời sau dễ đọc, tìm hiểu v.v. Từ những điểm kể trên, có thể thấy làm tài liệu tuy mất nhiều thời gian và không ai ép buộc phải làm tài liệu cả, nhưng vì sự cần thiết của nó và một số môi trường cũng yêu cầu về tài liệu để thực hiện mà ta cần làm cho rõ ràng, chuẩn chỉnh. Hôm nay, mình trình bày cho các bạn 03 loại tài liệu chính yếu và quan trọng nhất mà 1 BA trong domain IT cần phải làm để đảm bảo sản phẩm, dự án được thực hiện hiệu quả, đó là BRD/URD, SRS và Testcase for UAT. Thông qua khoá học, mình đã được thầy giáo chia sẻ về 3 LOẠI TÀI LIỆU 1 BA TRONG DOMAIN IT CẦN TẬP TRUNG

• BRD/URD 

BRD/URD viết tắt từ Business Requirement Document và User Requirement Document, tạm dịch là Tài liệu đặc tả yêu cầu Nghiệp vụ/ Người dùng/ Sản phẩm. Trước đây thì đây là 02 tài liệu khác nhau nhưng bây giờ thì do chọn lọc tự nhiên, cũng gộp thành BRD cho dễ xử. 

Nội dung chính của BRD là mô tả yêu cầu nghiệp vụ, mô tả về yêu cầu, nhu cầu của sản phẩm. Thông thường thì BRD được sử dụng nhiều trong môi trường Product, lý do là vì ở Outsourcing, đây là môi trường Gia công sản phẩm nên thường họ sẽ căn cứ vào các tài liệu mô tả sản phẩm, tài liệu yêu cầu v.v, tức là BRD, để gia công ra sản phẩm. Ở môi trường Outsource, theo mình thấy chỉ khi nào thực sự khách hàng họ hoàn toàn không nắm gì về kỹ thuật, về yêu cầu phát triển v.v thì mới thực hiện làm BRD thôi, còn lại hầu như phía KH làm, mô tả BRD cho outsourcing gia công ra sản phẩm. Ngược lại, ở môi trường Product, thì việc này do các bạn BA product, các bạn product specialist, product manager v.v làm và chuyển sang cho các bạn BA bên phía IT để phân tích và gia công nên sản phẩm. Nội dung của BRD sẽ có các nội dung chính: mô tả hiện trạng/ mục đích/ nhu cầu, mô tả yêu cầu tổng quan về sản phẩm đầu ra, mô tả chi tiết về yêu cầu sản phẩm (yêu cầu chức năng – functional requirement), các yêu cầu phi chức năng (non-functional requirement). Ngoài ra, nếu như người BA product, hay khách hàng v.v nắm kỹ thuật thì có thể mô tả system vào trong này luôn. Các tool hay sử dụng trong BRD là BACCM, User Story, Business Process và nếu bạn nắm rõ system, hiểu về kỹ thuật thì cứ sử dụng các tool kỹ thuật để mô tả luôn, lúc này BA bên phía khối IT sẽ nhẹ nhàng. BRD đôi khi cũng được sử dụng để chốt hợp đồng xây dựng sản phẩm đối với outsource, là biên bản thống nhất sản phẩm/ giải pháp để xây dựng đối với môi trường product.

• SRS 

SRS là viết từ Software Requirement Specification, tạm dịch là tài liệu Đặc tả yêu cầu Hệ thống. Cái tên nói lên tất cả, tài liệu này dùng để mô tả chi tiết thiết kế của hệ thống, tức là sản phẩm phần mềm, sản phẩm hệ thống v.v. Tài liệu này theo hướng technical, với các nội dung liên quan đến cấu trúc hệ thống, các mô tả chi tiết về quy luật, kết hợp, liên kết, tích hợp hệ thống, các hàm lập trình được sử dụng, định dạng dữ liệu v.v và v.v tất tần tật chi tiết mô tả kỹ thuật để có thể xây dựng nên 1 system, tức là một app, web, information system nào đó. Tài liệu SRS là tài liệu thuần technical, do đó thường sẽ do các bạn BA bên phía Khối, team IT hoặc các bạn System Analyst thực hiện. Các tool sử dụng trong SRS khá đa dạng với các tool focus vào việc mô tả system như Use Case Diagram, Use Case Description, Activity Diagram, Flow Chart, State Machine Diagram, Sequence Diagram, Class Diagram, cho tới mô tả cơ sở dữ liệu với các công cụ như Object Diagram, Entity Relationship Diagram. Các mô tả về giao diện cũng được đề cập trong tài liệu này Đa dạng công cụ là thế, nhưng dùng gì thì cũng, quan trọng nhất là phải làm sao cho người đọc hiểu được sản phẩm làm ra là gì, như thế nào. Tài liệu SRS thường mình thấy là tài liệu sử dụng nội bộ trong IT side chứ phía product, nghiệp vụ, KH sẽ có người để ý người không.

• TESTCASE FOR UAT

 Test thì do QC, Tester làm chứ sao lại là BA nói chung làm nhỉ. Không các bạn ạ, nói tới technical test thì do QC chứ test theo góc độ người dùng, test đại diện cho KH thì là do các bạn BA nói chung làm, nhất là BA product thì hầu như phải xử lý phần này khá nhiều. Testcase là một tài liệu dùng để ghi lại nhật ký kiểm thử của một BA ở góc độ người dùng. Nội dung của test case có thể bao gồm một số điểm:

 – Số thứ tự

 – Tình huống test 

– Mô tả tình huống

– Tiền điều kiện (pre-condition): tức là điều kiện cần để thực hiện tình huống test 

– Kết quả mong đợi 

– Kết quả thực tế – Pass/Fail

– Ghi chú 

Đây là những nội dung trong 1 bảng test case mà các bạn cần phải có. Để làm test thì các bạn phải cụ thể, chi tiết, đi từng bước chứ đừng đi vắn tắt hay là test cho có vì chất lượng sản phẩm như thế nào, trải nghiệm người dùng có tốt hay không phụ thuộc khá nhiều vào cái Tâm làm test của BA. BA là đại diện cho người dùng nên các bạn hãy làm tròn nghĩa vụ của mình nhé. 

Tác giả: Trịnh Thị Hằng