Em cám ơn anh nhiều ạ <3

Hi Kiều, về bản chất thì nó cũng chỉ mô tả giải pháp này làm được gì, giải quyết vấn đề gì thôi em. Còn nội dung, cách tổ chức, phương pháp mô tả… thì có thể khác nhau đôi chút, tùy vào dự án, vào khách hàng, hoặc vào giai đoạn mà dự án mình đang chạy.
Ví dụ thường trong các dự án triển khai SaaS thì team dự án thường dùng FRD (Functional Req Doc), vì đơn thuần là mình chỉ cần tập trung mô tả vào function mà SaaS này đáp ứng được với yêu cầu của KH. Theo đó có thể là FIT/GAP analysis & cái nào configure/ customize thì mình cũng note rõ luôn.
Còn SRS (Software Req Specs) thường dùng trong các dự án build mới phần mềm, hoặc làm mới, mà không dùng một platform sẵn có. Thì khi đó ae BA cần focus nhiều hơn vào tính tổng thể, rồi rã xuống mô tả chi tiết từng chức năng hoạt động ra sao.

Như a nói trong bài viết thì FS ~ “một từ dùng chung để chỉ tài liệu đặc tả phần mềm”, là rất linh hoạt & đa dạng em nhé. Không FS nào giống FS nào. Mình nên nhìn nhận như vầy, để có cách tiếp cận phù hợp & làm ra được cái FS “dùng được” chứ ko phải chỉ là cái template với 1 đống chữ cưỡi ngựa xem hoa em nhé.

Thanks Hoa nhé. Coi như rút kinh nghiệm cho việc lựa chọn các trung tâm để học vậy. Mình có note 1 bài về vấn đề này, Hoa đọc qua xem thử có góp ý gì thêm không nhé: https://thinhnotes.com/chuyen-nghe-ba/co-nen-di-hoc-khoa-hoc-ba/

Cảm ơn e nhé 🙂 dạo gần đây anh cũng bắt đầu viết lại mà cũng hơi lười haha, nếu có gì cần trao đổi cứ cmt anh biết nhé!

Dạ em cảm ơn anh ạ ❤

Hi Khôi, BA cũng có công việc part-time đó em. Em đọc thêm bài này nhé, a có note vài ý liên quan đến việc làm thêm của BA: https://thinhnotes.com/chuyen-nghe-ba/moi-ra-truong-khong-kinh-nghiem-sao-lam-ba/