Áp dụng các yêu cầu theo công ty cũ do trước đây đã triển khai thành công

Tham khảo các thành công của công ty cũ và đưa ra đề xuất, có hiệu chỉnh phù hợp với công ty hiện tại

Tìm hiểu hiện trạng của công ty mới, nắm được vision của sản phẩm và tham khảo các yêu cầu ở công ty cũ để đưa ra đề xuất triển khai phù hợp với công ty hiện tại

1.Business requirement

2.Functional requirement

3.Non-Functional requirement

4.Stakeholder requiement

1.Business requirement

2.Stakeholder requiement

3.Solution requirement

1.Solution requirement

2.Business requirement

3.Stakeholder requiement

1.Business requirement

2.Stakeholder requiement

4.transition requirement

Vì đội code có thể code sai nên cần tính các trường hợp code sai sẽ phải xử lý như thế nào

Vì hệ thống luôn xảy ra các lỗi tiềm ẩn, nên phải tính các tình huống ngoại lệ để xử lý hết các tình huống đó

Vì trong quá trình vận hành, việc sai sót/thay đổi của con người là hoàn toàn có thể xảy ra

Tần suất xảy ra tình huống đó

Độ ảnh hưởng, rủi ro khi xảy ra tình huống đó

Độ phức tạp để xử lý tình huống đó trên hệ thống

Mức độ đánh đổi giữa rủi ro và nguồn lực

Trao đổi với KH nhu cầu ngắn hạn để đưa ra sản phẩm nhanh nhất

Trao đổi nhu cầu ngắn hạn, trung hạn, dài hạn của KH để phân tích và tìm cách đưa ra sản phẩm nhanh nhất theo mong muốn của KH và vẫn đảm bảo cho yêu cầu trung hạn, dài hạn

Nắm bắt yêu cầu của KH và trao đổi với code các yêu cầu theo từng sprint (2 tuần) để code hoàn thành theo đúng mong muốn của mình

Phân tích tổng quan nhu cầu của KH, tranfer yêu cầu cho đội code về mong muốn trong các thời kỳ của KH, và sau đó sẽ làm chi tiết yêu cầu theo từng sprint

Không cần viết tài liệu, chỉ cần tập trung trao đổi thông tin với nhau trong team

Có tư tưởng đưa ra sản phẩm nhanh nhất nên không cần dự tính các thay đổi có thể có của KH, vì agile là cho phép thay đổi thoải mái

Dành thời gian phân tích tổng quan để hiểu overview dự án, Xác định được danh sách yêu cầu của dự án (product Backlog) và đánh giá độ ưu tiên. Nắm rõ product vision, product strategy để thiết kế sản phẩm ít bị thay đổi nhất trong tương lai

1.Product vision

2.Product strategy

3.Product roadmap

4.product backlog

1.Product vision

2.Product roadmap

3.Product strategy

4.product backlog

1.Product roadmap

2.Product strategy

3.product backlog

1.Product roadmap

2.product backlog

Lưu thông tin của các hoạt động vận hành bên ngoài của stakeholder để quản lý 1 cách minh bạch và realtime

hỗ trợ tự động xử lý tính toán, tối ưu thay con người

Giúp trao đổi thông tin giữa con người thông qua hệ thống thay vì trao đổi trực tiếp

Khi có hệ thống thì con người sẽ không cần làm các việc bên ngoài hệ thống nữa

Tìm hiểu thuật ngữ, khái niệm, từ viết tắt trong chứng khoán

Tìm hiểu các quy định (tài liệu pháp lý) liên quan tới chứng khoán hoặc tham khảo các quy định trong các tài liệu mà KH cung cấp

Tìm hiểu các quy trình mua bán chứng khoán, đăng ký mở tài khoản của các bên hoặc theo quy định của pháp lý

Chờ sang gặp KH, KH cung cấp thông tin, thông tin nào không hiểu thì về tìm hiểu sau, vì nhiều thông tin quá, không biết nên tìm hiểu cái nào

Tìm hiểu và sử dụng sản phẩm tương tự trên thị trường (nếu có thể)

Tìm các tài liệu, video hướng dẫn sử dụng các sản phẩm tương tự

Gặp gỡ, trao đổi với những người có kinh nghiệm trong sản phẩm tương tự

Cứ tham gia dự án dần, dựa theo KH cung cấp rồi trao đổi, tìm hiểu thêm

Không ảnh hưởng gì, vì sàn đã đưa ra quy định này public nên KH sẽ tự biết để không giao dịch

Khi nắm được quy định này, hệ thống sẽ cần xây dựng để off thời gian giao dịch trong khung thời gian như trên. KH vào giao dịch sẽ bị báo lỗi

Hệ thống sẽ cần có tính năng để cấu hình ngày nghỉ lễ, giờ được giao dịch hoặc có tính năng cho con người vào start/stop giao dịch

Cần quan tâm mục đích, nhu cầu ở sản phẩm mới

Cần quan tâm hiện trạng sản phẩm cũ, các vấn đề bất cập, ưu điểm mà nó có

Không cần quan tâm sản phẩm cũ vì nó đã không phù hợp

Cần hiểu về dữ liệu của hệ thống cũ để migrate sang hệ thống mới sau khi hoàn thành

Kênh đặt hàng

Ngày GD

Trạng thái đơn hàng

Tất cả các đáp án

Giúp cho bạn biết Hệ thống cần hỗ trợ xây dựng chức năng tạo ra các set món ăn (gồm tên set, giá set, và Danh sách món ăn trong set, ảnh đại diện của set món ăn

Hệ thống cần có chức năng hiển thị danh sách các set món ăn, món ăn mà nhà hàng cung cấp

Vì BA cần phải nắm hết tất cả các yêu cầu của dự án để truyền đạt yêu cầu cho đội code hết ngay từ đầu

Vì dựa vào báo cáo có thể hiểu được nhu cầu của user liên quan đến các dữ liệu cần thể hiện trên báo cáo, từ đó BA biết thông tin nào cần lưu trữ để phục vụ yêu cầu đó, tránh việc lưu thiếu thông tin, ảnh hưởng tới việc thay đổi sau này

Tìm kiếm

Danh sách

Usecase: Nhập thông tin liên hệ

Usecase: Nhập thông tin số lượng phòng

Booking phòng (với hình thức thanh toán online)

Thanh toán online

Không, ở đây mình nên xem nó là phần nhỏ trên Usecase Login khi mô tả màn hình, bổ sung phần mô tả click vào link reset thì báo như trên

Có, vì cứ click vào 1 link hay 1 button thì coi là 1 UC

Có, vì nó vẫn đạt được mục đích của actor

Usecase luôn có actor là End user

Usecase có thể có actor là Hệ thống khác

Usecase có thể có actor là Chính hệ thống đó

Là usecase có actor chính là hệ thống hiện tại

Là usecase chạy theo tần suất được quy định được (Ví dụ 1 ngày/1 lần, 5 phút/lần)

Là usecase chạy theo tần suất và quét dữ liệu để xử lý theo rule quy định

Ai sẽ được phép sửa

Điều kiện sửa như thế nào

Luôn cho sửa ở bất cứ trường hợp nào nên không cần quan tâm

Báo cáo

Tìm kiếm

Create

Xem chi tiết

1.Chức năng đáp ứng quy trình vận hành trong giai đoạn hiện tại

2.Chức năng bổ trợ cho quy trình dạng (CRUD, tìm kiếm/Danh sách)

1.Chức năng phục vụ tình huống ngoại lệ

2.Chức năng Danh mục đầu vào

3.Chức năng Báo cáo thống kê

Chức năng hỗ trợ tăng trải nghiệm/hỗ trợ công việc người dùng tốt hơn

Chức năng quản lý user, phân quyền

Thứ tự hiển thị đơn hàng trong danh sách

Format hiển thị ngày tháng mua hàng h

Tên header của Danh sách

Thông tin mã đơn hàng: Click vào link thì ra màn hình chi tiết đơn hàng

Giá trị mặc định của Họ và tên

Giá trị mặc định của Tỉnh/tp, Quận/huyện, Phường/Xã

Giá trị mặc định của Loại địa chỉ

Label Tạo địa chỉ

Điều kiện để lấy thông tin hiển thị Trong combobox

Thứ tự hiển thị

Thông tin hiển thị (Tên tỉnh/Thành phố hoặc Mã tỉnh - Tên Tỉnh/TP)

Cho phép chọn nhiều

Tên Zalo của thành viên được add vào: Màn hình hiển thị của thành viên là bạn của thành viên được thêm

Tên Zalo của thành viên được add vào: màn hình hiển thị của thành viên không phải là bạn của thành viên được thêm

Label Bạn trong câu "Được bạn thêm vào nhóm"

Avatar của thành viên được add

Không bất hợp lý

Thiếu thông tin để biết đang ở màn hình nào

Không có nút back

Có

Không

1.Tên chủ căn hộ

2.Điện thoại liên lạc

3.Số CMND

Thông tin phương tiện: Loại phương tiện, Loại xe, Biển kiểm soát, màu sơn, Số lượng chỗ ngồi

Thông tin người sử dụng phương tiện: Nhập các thông tin như trong ảnh

Thông tin người sử dụng phương tiện: Chọn thông tin cư dân trong căn hộ

Radiobox/Combobox chọn loại phương tiện xe oto, xe máy, xe đạp

Combobox: Loại xe (Danh sách hãng xe)

Combobox : Màu sơn

Textbox : Biển kiểm soát , SL chỗ ngồi

Chỉ hiển thị Biển số khi Loại phương tiện là xe máy, xe oto và hiển thị nhập SL chỗ ngồi khi loại phương tiện là Xe oto

Textbox : Biển kiểm soát , SL chỗ ngồi

từ các template của Stakeholder cung cấp

Qua interview stakeholder

Tự suggest các thông tin phù hợp để giúp người dùng sử dụng và quản lý thông tin thuận lợi hơn

Lấy nguyên từ các ứng dụng tương tự

Activity diagram tập trung vào xử lý các luồng rẽ nhanh

Sequence diagram tập trung vào xử lý các luồng rẽ nhanh

Validate format dữ liệu

Xử lý kết quả trả về từ server để hiển thị thông báo lỗi hoặc điều hướng màn hình phù hợp

Xử lý logic nghiệp vụ như cập nhật dữ liệu, trừ tiền tk (với nghiệp vụ bank)

Hiển thị thông báo lỗi

Validate dữ liệu từ client gửi lên

Xử lý logic nghiệp vụ như sinh OTP, trừ tiền TK, cập nhật, insert dữ liệu

format dữ liệu đầu vào

Validate các thông tin mà server nắm giữ

Validate toàn bộ thông tin gửi lên

Không, vì client đã gửi lên và server đã validate trước đó okie rồi

Có vì có thể bước 1 okie nhưng ở bước 2 dữ liệu A đã bị thay đổi và không còn hợp lệ nữa

Chỉ cần mô tả: "Lấy phí GD tương ứng"

Cần mô tả cách tính phí Gd như thế nào

Không cần mô tả gì vì nội bộ trong team đã rõ hết yêu cầu

tư duy Client gửi lên server những thông tin gì

Thông tin từ client gửi lên server có những thông tin nào sẽ bị thay đổi thông tin trong lúc actor đang thực hiện

Thông tin nào liên quan tới quy định về logic nghiệp vụ

Thông tin nào client đã validate, thông tin nào client chưa validate

thực hiện ghi nhận với đơn hàng là 30.000đ

Thực hiện thông báo lỗi với KH là đơn hàng đã thay đổi giá trị. Yêu cầu KH đặt lại

Không bao giờ có trường hợp này nên không cần xử lý

Trường hợp này rất hy hữu nên không cần phải xử lý hoặc xử lý ngoài

Đúng

Sai

Hợp lý

Không hợp lý

request Data

response Data

Danh sách mã lỗi đi kèm

Tìm hiểu ý nghĩa từng API

Vẽ lại luồng tích hợp giữa 2 hệ thống và mapping API tương ứng với các bước trao đổi thông tin

Việc này là của đội code, BA chỉ cần báo là cần tích hợp luồng nào với bên đối tác

Tìm hiểu chi tiết request data, response data, bảng mã lỗi của các API liên quan tích hợp

Đúng

Sai

Thành công

Thất bại

timeout

Thất bại

timeout

Thành công

Mô tả chung (Mục đích, actor, precondition, post condition)

Màn hình và mô tả màn hình

Business Rule

Luồng và mô tả luồng

Rule về điều kiện tìm kiếm: thỏa mãn tất cả các điều kiện hay chỉ cần thỏa mãn 1 trong các điều kiện

Rule về tiêu chí sắp xếp dữ liệu đầu ra

Rule về tìm kiếm chính xác, tương đối hay >, <

Mô tả chung

Màn hình và mô tả màn hình

Business Rule

Luồng và mô tả luồng

Mô tả chung

Màn hình và mô tả màn hình

sequence diagram

Activity diagarm và mô tả luồng

Business Rule

Danh sách tham số đầu vào của API (Tên, ý nghĩa, Các ràng buộc về maxlength, giá trị...)

Danh sách tham số đầu ra (tên tham số, ý nghĩa )

Danh sách các lỗi có thể xảy ra khi trả về cho đối tác

Activity diagram và mô tả luồng

Hệ thống khác

End user

Hệ thống hiện tại

Tần suất chạy tiến trình

Điều kiện quét dữ liệu

Biểu đồ trạng thái nếu tiến trình đi qua >=3 trạng thái

Thực thể có thuộc tính có giá trị có thể thay đổi trong cả vòng đời của nó

Thực thể có thuộc tính có giá trị thay đổi trong tập giá trị hữu hạn được xác định trước (tập giá trị này áp dụng cho tất cả các thể hiện của thực thể đó), và có sự chuyển đổi giữa các giá trị đó khi có 1 tác động trên hệ thống (loại trừ TH chỉnh sửa thông tin)

Thực thể có thuộc tính có giá trị thay đổi trong phạm vi quy định

Xem xét mục đích của thay đổi đó, tại sao stakeholder lại cần thay đổi đó, nếu không thay đổi thì có sao không

Nếu trong trường hợp buộc phải thay đổi, bạn xác định phạm vi ảnh hưởng: Các chức năng hiện tại ảnh hưởng, chức năng cần bổ sung

Phạm vi thay đổi có nằm trong scope của giai đoạn hiện tại không

Nếu thay đổi sẽ thay đổi đúng theo yêu cầu của stakeholder

Nếu thay đổi, có thể đưa ra giải pháp là thay đổi từng phần, phù hợp với hiện trạng và vẫn đáp ứng được nhu cầu của stakeholder

Có

Không

Đưa ra quy định chung về xử lý giao diện (các ràng buộc chung, các xử lý chung đối với các dạng control)

Trong mỗi chức năng đưa ra quy định xử lý chung

Không tập trung mô tả giao diện, thay vào đó sẽ tập trung trao đổi trong nhóm

Là 1 luồng thực hiện khác với luồng basic flow mà vẫn đạt được mục đích của usecase.

Là luồng không đạt được kết quả mong muốn của usecase tương ứng, sẽ dẫn tới kết quả bị fail

Là luồng thể hiện các exception về hệ thống như mất kết nối giao tiếp giữa client và server