Hế lôôôô anh em!

Bài này mình sẽ note tiếp tập 2 của chuỗi series về viết FS nhé. Ở tập trước mình đã đi được các mục sau:

VIẾT FS KIỂU TRUYỀN THỐNG
1. Overview
2. User Requirement
3. Functional Requirement
     3.1. BPMN
     3.2. Use Case
     3.3. Business Rule

Tập này mình sẽ tiếp tục với anh em các phần dưới đây nhé.

viet_fs_thinhnotes

3.4. Wireframe

Vì mình làm digital product, nên rõ ràng là không thể thiếu mô tả User Interface đúng không anh em. Nhưng mình sẽ không vẽ UI ở đây, mà mình chỉ cần làm Wireframe thôi.

Ở các phần trước đó, mình đã cho người đọc:

  • Nắm rõ tổng quan và tuyến đường dây của FS bằng BPMN.
  • Cũng đã đi chi tiết vào từng tính năng bằng Use Case.
  • Và cũng đã dùng Business Rules để làm sáng tỏ các tính năng đó.

Tổng quan đã có, chi tiết đã có. Giờ chúng ta cung cấp cho người đọc cái nhìn CỤ THỂ nhé anh em.

Nghĩa là mình đã có 1 nùi chi tiết bên trên rồi, người đọc cần hình dung rõ hơn: với những tính năng này, thì user sẽ được-tương-tác-với-hệ thống như thế nào.

Wireframe sẽ giúp chúng ta thể hiện điều này. Wireframe thì anh em vẽ kiểu nào cũng được, nhưng phải đảm bảo thể hiện được đầy đủ 2 mục sau:

  • Luồng đi cơ bản của user (User Flows)
  • Và cấu trúc nhóm các thông tin (Layout).

Lưu ý khi vẽ Wireframe thì anh em cũng phải MÔ TẢ nó nhé. Trên Wireframe, có bao nhiêu component thì anh em đánh số thứ tự tương ứng vào. Rồi mình làm 1 cái bảng mô tả gồm các thông tin sau:

  • ID: số thứ tự tương ứng trên wireframe
  • Component: tên của component đó
  • Type: là drop down list, hay là text, hay là label, button….
  • Validation: mô tả các lớp validate trên front-end nếu có
  • Editable: có chỉnh sửa được hay không
  • Required: có required không
  • Description: ghi chú các thứ khác, như diễn giải thêm ý nghĩa, default value là gì, hay tooltips nếu có…

Làm xong phần này, anh em nên tự hỏi mình: “Vầy đã ổn chưa?”

Hãy làm bộ như mình là các thành viên khác của team, như: UI Designer, Dev Front-End, hay QC. Và đang nhìn vào FS này, rồi tự vấn lại: để làm và test màn hình này, thì như vầy đã đủ thông tin để anh em triển hay chưa?

Nếu còn gì lấn cấn thì rõ ràng là chưa được. Hãy tinh chỉnh lại đến khi nào anh em cảm thấy hợp lý và đầy đủ thông tin nhất có thể nhé.

ba-viet-fs-nhu-nao-thinhnotes

 

3.5. ERD

Nội dung cuối cùng anh em có thể đưa vào mục Functional Requirement đó là ERD. Phần là optional, nên có cũng được mà không có cũng không sao nhé anh em.

Nếu có yêu cầu rõ ràng từ khách hàng về việc: Data Structure cần được thiết kế như thế nào thì việc anh em vẽ ERD và đưa vào FS là vô cùng hợp lý. (Thường những dự án có cấu trúc DB phức tạp, thì mới cần đưa hẳn ERD vào FS).

Nhưng nếu dự án không có yêu cầu gì đặc biệt về mặt Data Structure, thì mình khuyên anh em nên để ERD ở riêng tài liệu Technical Specs. Vì: FS tốt nhất là hãy cứ đưa ra bài toán, còn cách làm cụ thể sẽ tùy vào nhiều yếu tố mà quyết định.

Ví dụ cùng là 1 yêu cầu, nhưng có nhiều cách làm Data Structure khác nhau. Nếu dự án đang không nhiều budget, hoặc team đang bị overload, hoặc timeline đang quá gấp – không thể sửa data cũ…, thì mỗi tình huống lại có một cách tiếp cận và cách làm khác nhau.

Nên hãy để mở khoản này, để sau còn linh hoạt nhé anh em.


 

Ô kê vậy coi như mình đã đi qua phần 2 phần cốt lõi quan trọng nhất trong bất kỳ FS nào:

  • User Requirement
  • Functional Requirement

Xong 2 phần này, mình đã mô tả được đâu đó 80% những tính năng mà sản phẩm cần có rồi. Các phần dưới đây sẽ chủ yếu tô điểm cho FS thêm rõ ràng và hoàn chỉnh nhé anh em.

ba-viet-fs-nhu-nao-thinhnotes

 

4. Non-Functional Requirement (NFR)

Nói về NFR thì mình đã có 2 bài note về nó rồi. Anh em xem thêm ở đây nhé:

Với những kiến thức và trải nghiệm mình có được về NFR, hãy chỉ lượm lặt những thứ THẬT SỰ CẦN THIẾT để đưa vào FS thôi nhé.

Tránh đưa hầm bà lằng các thứ không ăn nhậu gì với nhau vào. Hoặc nếu anh em nghĩ mình đã cover đủ ở Business Rules rồi, thì NFR mục này không cần nữa. Nhớ nhé, FS phải rất súc tích & ngắn gọn. Cái gì đưa vào thì phải đưa cho đáng đồng tiền bát gạo 😀

Thường NFR sẽ dành cho:

  • Những dự án có ràng buộc các tiêu chuẩn rõ ràng (như các dự án ERP, các dự án y tế, hoặc dự án vận hành nhà máy…)
  • Hoặc những dự án cần migrate toàn bộ system cũ lên system mới xịn hơn, ổn áp hơn
  • Hoặc khi khách hàng có những yêu cầu rất cụ thể về các yếu tố Non-Functional này.

Phần NFR này anh em cũng làm từng mục riêng theo từng nhóm NFR nhé. Từng mục này thể hiện bảng mô tả , bao gồm các cột: ID và mô tả NFR.

 

Ví dụ FS của mình có 2 NFRs rất cụ thể sau.

1. Performance Requirement

ID NFR
NFR1-1 Đối với màn hình input: tối đa 30 trường dữ liệu, không tính toán dữ liệu phức tạp, không tương tác với hệ thống ngoài, và không lưu trữ các tệp nội dung lớn như: hình ảnh, video, tệp tin quá 3MB.
NFR1-2 Đối với màn hình output: dữ liệu được query trực tiếp từ DB, hạn chế những query phức tạp, những query từ hệ thống ngoài.
Hiển thị tối đa 50 dòng dữ liệu, mỗi dòng tối đa 10 cột, và mỗi dữ liệu có độ dài nhỏ hơn 100 ký tự. 
NFR1-3 Điều kiện tải bình thường: 30 CCU khi không dùng cân bằng tải.
NFR1-4 Điều kiện server tối thiểu: Intel Core i5, 4GB RAM, 500GB hard disk.

 

2. Supportability Requirement

ID NFR
NFR2-1 Có thể hoạt động trên platform: iOS và Android
NFR2-2 Tương thích với hệ điều hành:

  • iOS: từ 8.1 trở lên
  • Android: 4.4, 5.0, 6.0, 7.0**
NFR2-3 Có thể hoạt động trên thiết bị tối thiểu 1GB RAM (hệ điều hành iOS) và 1GB RAM (hệ điều hành Android)

 

5. Transition Requirement

Ô kê anh em, phần cuối cùng liên quan đến Requirement sẽ là: TRANSITION.

Ở bài 4 loại Requirement mình cũng đã note với anh em: Như thế nào là Transition Requirement? Phần này mình sẽ tập trung nói đến: vai trò của Transition Requirement trong FS là như thế nào.

Anh em có thể hình dung: việc build phần mềm là 1 chuyện, việc đưa nó vào sử dụng thực tế lại là chuyện hoàn toàn khác. Đây sẽ là chỗ để anh em tập hợp các yêu cầu để phục vụ cho việc chuyển giao này.

Ví dụ có lần mình làm 1 dự án, mà trong đó có 1 tính năng chạy rất nhiều batch-job vào 2g00 sáng mỗi ngày. Mục đích là để đổ data lên Cloud cho các hệ thống khác sử dụng.

Chỉ cần tạch 1 hôm, là ngày hôm sau các apps vệ tinh khác không get được data về là toang ngay.

Sau vài tháng sấp mặt thì cơ bản team cũng đã xong được 90% core features của hệ thống. Nhưng anh em cũng biết là thực tế thường không êm xui trót lọt như mình tính. Thường thì sẽ có chuyện, không ít thì nhiều. Vì rõ ràng môi trường production là thứ mà không ai lường trước được gì.

Nên team IT và team business mới thống nhất làm 1 function nhỏ cho anh Admin, để ảnh có thể can thiệp: manually điều chỉnh hoặc refresh job transfer data vào 2g00 sáng mỗi ngày.

Nếu không thông luồng, mọi thứ sẽ bị tắt nghẽn cổ chai vào sáng hôm sau. Nên, nếu có sự can thiệp của con người vào đoạn giữa này, mọi thứ sẽ được đảm bảo hơn.

Và tính năng này được thống nhất là chỉ kéo dài trong 5 ngày sau kể từ ngày release phiên bản đầu tiên. Sau đó mọi thứ phải chạy tự động để tránh sai sót dữ liệu. (Và cũng không ai muốn tốn thêm 1 headcount chỉ để làm chuyện “automa-tay” này).

Do đó, Transition Requirement là chỗ để anh em mô tả những tính năng kiểu kiểu như vầy.

Sẽ có bạn dõng dạc hỏi: “Ụa anh eiii, sao mình không gom luôn zô phần Functional Requirement bên trên zậy anh, đưa xuống đây chi cho nó dài quá xá?”

Câu trả lời là: Vì tính năng này không trực tiếp giải quyết cho bất kỳ Business Requirement nào. Nó chỉ đơn thuần phục vụ cho việc: go-live, và chuyển giao hệ thống cũ sang hệ thống mới một cách trơn tru, an toàn hơn mà thôi. Mục đích khác nhau, nên cần tách rời để dễ handle.

Về cách mô tả thì cũng làm tương tự như Functional Requirement nhé anh em. Cứ đi theo phương pháp đó, cả phía Business cũng dễ hiểu, mà phía Tech cũng đủ hình dung để biến nó thành thực tế.

ba-viet-fs-nhu-nao-thinhnotes

 

6. Supporting Information

Ô kê cuối cùng sẽ là phần lẩu thập cẩm. Anh em có thể gom tất cả những materials support cho các ý bên trên vào đây. Đó có thể là:

  • Bảng mô tả thuật ngữ.
  • Bảng liệt kê Business Rules theo Use Cases.
  • Các Meeting Minutes quan trọng (mục đích là để đảm bảo tính nguyên bản của original problems, tránh bị tam sao thất bản qua mô tả của FS, hoặc để sau này cần thì refer lại).
  • Các diagram mô tả thêm cho 1 vài đối tượng nào đó (như Sequence Diagram, Data Flow Diagram,…).
  • Hoặc anh em có thể để ERD vào đây.

Sau cùng thì các phần trong Supporting Information mục đích cũng chỉ để “easier for reader to understand FS”.
(câu này nhấn mạnh bằng tiếng Anh nghe cho soang, nó sát nghĩa, với thêm phần nguy hiểm nha anh em).

 


Ô keeeee vậy hườm hườm là mình đã hình dung được cách viết FS cơ bản nhất trong 1 dự án phần mềm nhé anh em. Tiếp sau đây mình sẽ triển luôn cách viết FS trong các dự án Agile cho trọn bộ phun HD nhé.

Lẹt sờ gâuuuuuuu!

 

VIẾT FS KIỂU AGILE

Về cơ bản thì FS kiểu Agile cũng phải show được các ý như khi anh em làm FS truyền thống. Nhưng nó thể hiện theo một cách khác.

Vì tính chất của các dự án Agile là rất linh hoạt. Thường Requirement sẽ bị thay đổi hoặc làm mới rất nhiều. Hoặc dự án cần phải roll-out rất nhanh để đáp ứng cho cả ti tỉ thứ: business changes, get user feedback, đạt KPI khỉ khô nào đó, hoặc đơn thuần là đi theo một campaign đâu đó từ trên trển rơi xuống…

Do đó, cách anh em BA mình làm FS trong các dự án mô hình kiểu này cần phải khác đi đôi chút. Nhưng mục tiêu sau cùng là vẫn đảm bảo FS được súc tích & cô động. Nhưng có thể linh hoạt điều chỉnh bất cứ khi nào.

Nếu FS truyền thống tiếp cận theo hướng Use Case, focus nhiều vào việc: tương tác của các Actor lên hệ thống như thế nào. Thì FS kiểu agile tiếp cận theo góc nhìn User Story, tập trung hoàn toàn vào đối tượng End-Users.

ba-viet-fs-nhu-nao-thinhnotes

Gốc rễ của cách làm này đều bắt nguồn từ End-Users. Như nào? End-users sẽ kể ra nhu cầu mà họ cần được giải quyết. Từ đó, anh em tập trung khai thác & phân tích vấn đề dựa trên đề bài này.

Mình sẽ đối chiếu cách viết FS kiểu Agile với kiểu truyền thống cho anh em dễ hình dung. Tạm gọi:

  • T là FS kiểu Truyền thống
  • A là FS kiểu Agile

Nếu Overview có trong T, thì thường phần Overview này sẽ không có trong A.
Nó sẽ được cover ở 1 loại document khác (có thể là Business Case, Proposal,…)

Nếu User Requirement có trong T, thì ở A nó lại tồn tại dưới dạng User Story.

Nếu Use Cases & Business Rules có trong T, thì ở A nó thể hiện dưới dạng Acceptance Criteria

Nếu BPMN & Wireframe có trong T, thì ở A vẫn là BPMN & Wireframe.


Oops, bài này tới đây cũng dài rồi nên mình sẽ ngắt ra bài sau để anh em đọc cho liền mạch nhé. Nếu anh em có thắc mắc hay cần trao đổi gì thì cứ để lại comment bên dưới cho mình nhé.

Hẹn gặp anh em ở tập sau!!!