Hế lô anh em!!! Tiếp nối bài tuần trước thì bài này mình sẽ share chi tiết với anh em cách mình làm FS nhé.

Bài này mình sẽ chia làm 2 phần:

• Viết FS theo kiểu truyền thống
• Và viết FS theo kiểu Agile

VIẾT FS KIỂU TRUYỀN THỐNG

Để làm FS kiểu này thì anh em chỉ cần follow theo đúng các mục sau:

1. Overview
   
2. User Requirement
3. Functional Requirement
4. Non-Functional Requirement
5. Transition Requirement
6. Và sau cùng là Supporting Information

1. Overview

Overview thì anh em cứ mô tả súc tích & ngắn gọn về: Purpose, Business Objectives, và Scope. Cụ thể:

• Purpose: nôm na FS này mô tả cái gì, dành cho ai đọc?
• Business Objectives: anh em mô tả background & context mà dự án này ra đời nhé
• Scope thì thường sẽ đi theo:
  • Organization Scope: giải pháp này áp dụng ở Business Unit nào, hay áp dụng cho toàn tổ chức?
  • User Scope: giải pháp này dành cho toàn bộ đối tượng nhân viên, hay chỉ áp dụng cho một vài bộ phận nào đó?
  • Functional Scope: giải pháp này bao gồm những Use Case nào (chỉ việc gom nhóm lại thôi nhé, chứ không cần detail ở đây)
  • Integration Scope: list ra những integration point với các system khác.
  • Out of scope: note rõ những thứ mà giải pháp này không làm và không cover trong tài liệu FS này nhé.

Để viết phần này cho chuẩn thì anh em cứ đặt mình vào vị thế của người đọc. Mình viết, rồi thử đọc lại, xem chính mình có hiểu không, có súc tích, ngắn gọn không?

Ngoài ra, phần này anh em có thể đặt các Assumption (các giả định) & Dependencies (các yếu tố phụ thuộc) vào để làm rõ các khía cạnh của giải pháp.

Thực tế thì anh em linh hoạt theo từng tình huống mà quyết định xem có cần mô tả về Assumption hay Dependencies hay không nhé. Thường mình cũng không focus vào phần này lắm, nên theo mình là optional nếu dự án không yêu cầu phải làm.

2. User Requirement

Cụ thể nó sẽ là Business Requirement & Stakeholder Requirement như mình đề cập ở bài trước nhé anh em. Anh em chỉ việc kẻ 1 cái bảng, list những item UR và mô tả chi tiết của từng item đó.

Đây là điểm anh em nên làm kỹ. Vì việc mình có gãi có đúng chỗ ngứa của business hay không, là nằm ở đây.

Nên phần này (một lần nữa) phải cực kỳ súc tích và cô đọng nhé anh em. Không ghi thì thôi, nhưng đã ghi thì phải đúng, và vừa đủ từng chữ một. Không thừa, mà cũng không thiếu.

Để có nội dung viết vào đây thì rõ ràng anh em phải thật sự hiểu pain-points của khách hàng.

Và để hiểu được các pain-points này, thì anh em cần phải có trải nghiệm. Và đã phải làm đủ các nghiệp vụ khảo sát & phân tích trước đó thì mới có thể ghi được đúng và đủ vào trong này được.

@Tree Swing Cartoon – Poor Communication, Wikipedia

Ô kê anh em, hai phần trên là 2 món tráng miệng mở đầu. Từ chỗ này trở xuống sẽ là món chính – nội dung chính yếu mà FS cần thể hiện nhé.

3. Functional Requirement

Đây sẽ là nội dung chính cho cả FS. Nên anh em cần đầu tư nhiều vào phần này khi viết.

Mỗi công ty, mỗi dự án sẽ có một kiểu mô tả khác nhau. Nhưng nhìn chung mình thấy kiểu phổ biến, hiệu quả và khoa học nhất thường sẽ bao gồm các items sau:

1. BPMN
2. Use Case
3. Business Rules
4. Wireframe
5. ERD (optional)

Ô kê giờ mình sẽ đi vào chi tiết giải thích từng phần cho anh em.

Tuy nhiên để cho dễ hình dung thì mình sẽ tiếp cận theo hướng: 1. ĐỂ LÀM GÌ? và 2. RÁP CÁI “ĐỂ LÀM GÌ” ĐÓ LẠI. Mục đích là để anh em hiểu được bản chất vấn đề. Và từ đó lần lên được hình ảnh tổng thể của một bức tranh FS nhé.

Trước khi đọc tiếp ✋✋✋

5 phần trên là 5 phần quan trọng trong bất kỳ FS nào để mô tả một giải pháp phần mềm.
Anh em nào chưa xem thì nhớ bấm vào xem trước khi đọc tiếp phần dưới nhé 😎

3.1. BPMN

Đầu tiên là BPMN. Anh em cần cho người đọc 1 cái nhìn tổng quát từ trên xuống.

Một yếu tố tâm lý rất quan trọng mà anh em cần khai thác, đó là: chúng ta rất sợ bị lạc.

“Lạc” nghĩa là không định vị được mình đang ở đâu. Trước mình là gì, sau mình là gì. Mình nhích tiếp 1 bước nữa sẽ gặp gì, lùi lại 1 bước nữa sẽ gặp gì? Và khi đó, quan trọng hơn hết là mình không-thấy-đường đi đến điểm cần đến.

Việc thể hiện ý tưởng cũng vậy. VIẾT tài liệu là 1 cách thể hiện ý tưởng dễ khiến người đọc bị rối nhất.

Trong 1 mớ tài liệu cả trăm trang, nếu anh em không có chỉ dẫn rõ ràng cho người đọc: cần đọc từ đâu, chỗ này nói gì, chỗ kia nói gì, sau đó là gì, trước đó là gì, hay đọc hết cái này để làm gì? Thì vô hình dung anh em đã làm cho người đọc LẠC trong mớ tài liệu của mình rồi.

Từ đó sẽ dắt dây theo một loạt cảm xúc: bối rối >> khó hiểu >> mệt mỏi >> ức chế >> bực dọc >> móa >> dcm >> vkl >> viết như cục sh*t >> béép béép béép.

CÁCH KHẮC PHỤC? => chính là BPMN.

Anh em có thể vẽ tổng quát quy trình của hệ thống/ sản phẩm mà anh em làm. Có thể là end-to-end process. Hoặc tách nhỏ ra thành vài process theo các phân hệ chính yếu.

“Tuyến đường dây” của FS có rõ hay không, phụ thuộc nhiều vào cách anh em nhìn, và phân tách quy trình ra sao cho hợp lý.

Lưu ý là CÓ VẼ, thì nhớ PHẢI MÔ TẢ cái mình vẽ. Mô tả như thế nào?

Anh em cứ việc làm 1 cái bảng gồm các cột: ID, Steps, PIC, Description. Và nhớ các task trên BPMN PHẢI ĐÁNH SỐ ID nhé anh em.

Mỗi task này làm gì, làm bởi ai, mô tả chi tiết hay có note gì lưu ý không, anh em cứ gom hết vô cái bảng đặc tả BPMN này. Nhớ, ngắn gọn và súc tích nhé anh em.

(Cách thể hiện chi tiết mình sẽ để ở bài cuối series).

3.2. Use Case

Nếu BPMN là khung xương nối các phần của FS, thì Use Case chính là mô tả chi tiết các phần đó.

Bây giờ để hình dung rõ mục đích chính của Use Case, anh em thử giúp mình mô tả cách nấu 1 tô canh gà lá giang thử xem 🙂

Nhớ tự suy nghĩ rồi thử trả lời nhé anh em.

.

.

.

Lúc này sẽ có nhiều câu trả lời rất nhanh chóng bật ra như: “Mình sẽ nấu nước sôi >> luộc gà >> rồi tao chút hành tỏi >> thêm nước lọc vào >> nêm nếm gia vị vừa phải >> cho gà vào nấu chín >> rồi sau cùng bỏ lá giang vào >> xonggg”.

Anh em thấy câu trả lời trên rất chi tiết. Nhưng có vẻ như cách trả lời này hơi bị “bản năng” và các bước được kể khá lung tung.

Đâu đó người nghe vẫn chưa hình dung rõ được: bước nào làm trước, bước nào làm sau, bước này hông làm có được hông. Hay thịt gà có yêu cầu gì hông, lá giang có cần làm trước cái gì hông?

Với cách mô tả trên, để anh em nhìn vào mà nấu được nồi canh gà lá giang ra cho ra hồn, thì sẽ còn rất nhiều thứ mông lung cần làm rõ.

Vậy đâu đó mình cần 1 cách mô tả nó bài bản & chiên nghiệp hơn. Sẽ không quá phức tạp, nhưng đủ để cover được các khía cạnh của một quy trình nào đó.

USE CASE sẽ là câu trả lời!

Với Use Case, anh em sẽ thể hiện rõ được:

• Các công đoạn nấu canh gà lá giang: làm gà, làm lá giang, nấu canh gà (break ra thành 3 use cases nhỏ)
• Với mỗi công đoạn này, cần làm các bước gì, theo thứ tự gì (Main Flows)
• Với mỗi công đoạn này, có cách nào khác để làm không, nếu mình không có đủ dụng cụ để làm theo cách chính (Alternative Flows)
• Hay nên lưu ý điều gì để bước này không bị fail (Exceptional Flows)
• Gà để nấu món này thì yêu cầu như thế nào, hay lá giang trước khi nấu có cần vo nhẹ, hoặc làm gì không (pre-conditions)
• Nồi canh gà lá giang nấu ra màu sắc, mùi vị như thế nào là chuẩn (post-conditions)
• Và còn nhiều thông tin quan trọng khác mà anh em có thể khai thác được dựa trên Use Case.

Quay lại với FS của mình, sẽ rất rối và đặc biệt là rất dễ để viết thừa thứ không cần và viết thiếu thứ phải có, nếu anh em mô tả một tính năng nào đó theo bản năng mà không có phương pháp.

Do đó, nên dùng Use Case triệt để để tối ưu FS nhé anh em.

3.3. Business Rule

Nếu Use Case giúp anh em mô tả chi tiết từng phần trong FS, thì Business Rules góp phần làm sáng tỏ nội dung được mô tả trong Use Case.

• Business là nghiệp vụ
• Rules là những quy định được đưa ra

Business Rules nôm na là những quy định liên quan tới mặt nghiệp vụ mà hệ thống phải-tuân-theo.

Business Rules có thể là những quy định được đưa ra bởi các stakeholder. Như yêu cầu về mặt Legal/ Compliance, về Marketing, hay về định hướng phát triển sản phẩm…, mà hệ thống phải đảm bảo.

Rộng ra hơn một chút. Business Rules còn có thể là những thứ được đưa ra bởi team dự án, mà PIC chính là BA. Vì sao? Vì không ai hiểu rõ hệ thống hơn BA, hay rộng hơn là team dự án.

Nắm được Requirement từ phía Business, kết hợp với những gì mình biết ở hệ thống hiện tại, anh em hoàn toàn có thể đề xuất ra những rules giúp “hiện thực hóa” requirement từ phía Business một cách: phù hợp và hiệu quả.

Đây mới là điểm ăn tiền của người làm công việc Business Analysis.

Đặc biệt nếu anh em làm FS cho một tính năng nào đó, mà đòi hỏi phải connect với rất nhiều hệ thống khác. Thì việc hiểu rõ cách vận hành và rules của các hệ thống khác là một điểm tối quan trọng.

Chỉ khi đó, anh em mới có thể đưa ra được business rules cho tính năng mới này, một cách: hợp lý, hợp logic với hệ sinh thái hiện tại. Mà vẫn đảm bảo giải quyết được Business Requirement một cách hiệu quả nhất.

Nhưng anh em lưu ý là: mình không để Business Requirement vào thẳng mục Business Rules trong FS này nhé. Từ Business Requirement và những gì phân tích được, anh em sẽ suggest ra Business Rules. Chứ Business Requirement và Business Rules là 2 khái niệm hoàn toàn khác nhau.

• Business Requirement có thể là 1 statement rất CHUNG CHUNG.
• Còn Business Rules thì rất RÕ RÀNG và TƯỜNG MINH.

Còn về mặt tương quan thì Business Rules là những thứ chi tiết xung quanh, giúp làm sáng tỏ Use Cases. Và đảm bảo Business Requirement có thể trở thành hiện thực.

Ví dụ cho anh em dễ hiểu:

Anh em nên nhớ là phần làm Business Rules này rất quan trọng. BA có sâu sắc hay không thể hiện ở phần này. Do đó, khi làm anh em cứ dựa trên 2 ý sau để xuy sét:

• Technical Constraint
• Business Viability

Nếu có bất kỳ rủi ro nào phát sinh từ tính năng này mà impact đến 2 mục trên => tuyệt nhiên anh em phải suy xét kỹ và phải đưa ra được các Business Rules cover các rủi ro này.

Về mặt thể hiện thì đơn thuần anh em chỉ cần vẽ 1 cái bảng với các cột: ID, Business Rules.

ID thì nên định danh riêng cho từng mục Use Case, để sau này cần thì refer lại cho tiện. Ví dụ:

• Business Rules số 1 của Use Case 1 thì là BR-UC1-1
• Business Rules số 2 của Use Case 1 thì là BR-UC1-2
• Business Rules số 7 của Use Case 3 thì là BR-UC3-7
• …

Ô kê phần này tạm kết ở đây nhé anh em.

Vậy là mình đã đi được về: Overview, User Requirement, Functional Requirement (BPMN, Use Case và Business Rules). Bài tiếp theo mình sẽ note tiếp về các mục còn lại.

Baiiii anh em!!!