- Email devpro.edu.vn@gmail.com
- Hotline0985.95.08.95
PHÂN TÍCH REQUIREMENT VÀ LỢI ÍCH [GIAI ĐOẠN 1 CỦA DỰ ÁN] Trong quy trình phát triển phần mềm, giai đoạn đầu tiên vô cùng quan trọng cần làm là phân tích tài liệu đặc tả. Đây cũng là giai đoạn chúng ta sẽ đưa ra rất nhiều câu hỏi với khách hàng nhằm đảm bảo việc hiểu rõ tài liệu đặc tả. Vậy làm thế nào để phân tích được requirement một cách hiệu quả?
Trước tiên chúng ta cần hiểu software requirement là gì? Hiểu một cách đơn giản software requirement là tài liệu miêu tả những yêu cầu của khách hàng về sản phẩm phần mềm, những hành vi của đối tượng trong sản phẩm đó, đó là những yêu cầu về chức năng hoặc phi chức năng mà sản phẩm phần mềm cần đáp ứng được.
- Tài liệu SRS (Software requirement specification): Là tài liệu đặc tả những yêu cầu của phần mềm, bao gồm những yêu cầu về chức năng và phi chức năng.
- UI/UX: Là những thiết kế về giao diện người dùng và trải nghiệm người dùng.
Use case diagram: Là sơ đồ thể hiện các hành động, sự tương tác của user cho từng chức năng trên hệ thống phần mềm.
- Business rule diagram/Data flow diagram: Là sơ đồ thể hiện các logic nghiệp vụ, các luồng dữ liệu của hệ thống phần mềm.
- Data dictionary and Glossary: Khi phát triển phần mềm liên quan đến những lĩnh vực mới, có rất nhiều ngôn ngữ chuyên ngành khó hiểu. Do đó tài liệu đặc tả thường đình kèm Data dictionary and Glossary – văn bản liệt kê các từ ngữ chuyên ngành sử dụng trong tài liệu đặc tả nhằm giúp thành viên trong dự án hiểu rõ hơn.
- User stories: Yêu cầu của khách hàng có khi không phải là một văn bản mà còn có thể được viết trên các công cụ quản lý dự án như Jira, Redmine,…Thường được viết dưới dạng ngôn ngữ Gherkin rất dễ hiểu.
Phân tích requirement sơ sài dẫn tới việc sản phẩm cuối cùng không đáp ứng được yêu cầu khách hàng, số tiền phải trả cho việc phát triển dự án là rất lớn. Do đó, khi phân tích requirement cần phân tích một cách cẩn thận, rõ ràng và chi tiết.
Lợi ích của việc phân tích requirement cẩn thận
- Phát hiện và tránh được các lỗi trong tài liệu đặc tả.
- Đưa ra những gợi ý để nâng cao chất lượng sản phẩm.
- Phân tích requirement kỹ càng giúp QA đưa ra được tập hợp test case có độ bao phủ tốt nhất, tránh trường hợp thiếu các quan điểm test.
- Giúp lập trình viên hiểu yêu cầu và bao phủ được các luồng nghiệp vụ trong code.
- Ngăn chặn lỗi từ giai đoạn sớm.
- Tiết kiệm thời gian và tiền bạc trong phát triển phần mềm.
Khi bắt đầu tham gia một dự án, trước hết cần có cái nhìn khái quát về dự án như khách hàng là ai? sản phẩm phần mềm làm về lĩnh vực gì? ngữ cảnh? nghiệp vụ chung.
Các thành viên trong dự án cần tìm hiểu và phân tích các yêu cầu về chức năng của phần mềm:
- Trước tiên, mỗi người nên dành thời gian tự nghiên cứu tài liệu trước, tập trung nghiên cứu các logic về nghiệp vụ.
- Sau đó, nên có một buổi họp tóm tắt ngắn gọn các yêu cầu để chắc chắn cả đội dự án hiểu rõ, đúng và đủ về tài liệu yêu cầu.
- Tập trung phân tích các màn hình, phân tích các luồng hoạt động của sản phẩm phần mềm, các biểu đồ (nếu có)…
- Nghiên cứu các use case, các luồng dữ liệu,…
Bên cạnh các yêu cầu về chức năng, thành viên trong dự án cũng cần tìm hiểu về các yêu cầu liên quan đến giao diện, cơ sở dữ liệu, các yêu cầu phi chức năng ...
[Giai đoạn 2 mình sẽ gửi các bạn ở bài tiếp theo]
Nguồn tham khảo: techtalk via Viblo
