4 loại requirement Flashcards
các bước xử lý requirement trong business Analyst?
Tóm gọn, requirement trong Business Analyst sẽ có 2 trạng thái: chưa được phát biểu và đã được phát biểu.
Nhiệm vụ của người BA là phải thật cẩn thận trong việc MOI MÓC (ELICIT) thông tin. Để biến những requirement từ trạng thái chưa đươc phát biểu thành trạng thái đã được phát biểu. Requirement chính xác thì làm ra cái phần mềm mới chính xác, mới khớp với nhu cầu sử dụng của người ta. Không thì cũng banh chành.
Tiếp đến, BA cần PHÂN TÍCH (ANALYSIS) những requirement này. Ý là hệ thống, sắp xếp lại thôi.
Quy trình analysis cứ lặp đi lặp lại cho đến khi nào đã đầy đủ các loại requirement cần có trong dự án thì thôi.
(3) Organized: Sắp xếp và tổ chức lại dữ liệu một cách có cấu trúc.
Hình ra hình, file word ra file word, excel ra excel. Đoạn ghi âm cũng cần phải tài liệu hóa lại. Những phần nào là nháp thì note riêng ra. Những phần nào để chốt, quan trọng thì phải ghi nhận kỹ.
Thông tin sắp xếp theo chiều nào? Đi theo quy trình kinh doanh hay đi theo hành vi của người dùng? Bước Organized cần phải xác định rõ những điều này.
(4) Specified: Trả lời câu hỏi các dữ liệu này được xác định và phân loại dùng để làm gì, dùng như thế nào và dùng cho đối tượng nào?
Đối với end-user thì họ quan tâm cái gì? Họ liên quan đến thông tin nào, chức năng nào? Các stakeholders còn lại thì sao? PM bên khách hàng họ cần biết gì, theo dõi thông tin gì? Trả lời càng rõ ràng thì việc specify tài liệu sẽ dễ thở hơn. Sau này khi cần anh em cũng dễ lục lại.
(5) Verified: Bước này nhằm mục đích: đảm bảo các tài liệu mình hệ thống được đã ĐÚNG hay chưa.
Nhưng bước này là để verify với team nội bộ, chứ không phải khách hàng. Dữ liệu sẽ được internal team kiểm tra xem thử đã chính xác và đảm bảo đúng logic hay chưa. Ví dụ các tài liệu đặc tả đã viết đúng trình tự hay chưa? Các tài liệu trong SureStep đã thể hiện đầy đủ nội dung cần truyền tải hay chưa? Các sơ đồ có thiếu tính logic hay dùng sai sơ đồ gì hay không? Đảm bảo tất cả mọi thứ ok trước khi deliver cho khách hàng.
(6) Validated: Bước này thì lại nhằm mục đích: confirm các thông tin trao đổi với khách hàng đã chính xác, có sự ĐỒNG THUẬN giữa cả team phần mềm và phía khách hàng.
Dữ liệu sẽ được xác nhận với các stakeholder là đã đúng như yêu cầu của người ta hay chưa. Mỗi cái meeting đều cần 1 người chốt lại cái Minutes of Meeting, là cái biên bản họp. Thường thì vô họp chém ghê lắm, họp xong cái quên hết là chết bà luôn.
câu thần chú để phân biệt verify và validate^^
Verify = do the thing right (làm mọi việc đúng, một cách chính xác đi cái đã)
Validate = do the right thing (làm đúng việc mà khách hàng yêu cầu, đúng chức năng mà họ mong muốn).
Nói thêm về bước Specify, anh em BA cần phải làm tài liệu rất nhiều để gửi cho stakeholders. Mình note lại mấy điều sau nên chú ý:
Biết Stakeholder là ai để bàn giao tài liệu cho phù hợp. Mình chỉ nói cái người khác muốn nghe. Không ai đi gửi tài liệu kỹ thuật cho end-users xem cả. Giống như không ai đưa bản vẽ thiết kế đường ống nước cho thợ điện xem hết.
Anh em nên nắm vững ngôn ngữ của mình, đó là Modelling. Modelling vẫn là một phương thức truyền đạt thông tin vô cùng bá đạo. Nói bằng lời khó diễn tả quá thì mình vẽ ra, mô hình hóa nó lại rồi lưu lại thành tài liệu. Mai mốt bà con có ai hỏi thì có hàng mà show liền. Đỡ mắc công giải thích dài dòng, rườm rà.
CAse study:
Có một cô gái mới ra trường cần mua một cái túi xách tay để đi làm.
Cô này có 300.000đ tiền để dành để mua một cái túi LV. Cô đến 1 cửa hàng chuyên bán túi thời trang nữ.
Người bán hàng hỏi cô gái: “Chị có cần em tư vấn gì không ạ?”
Cô gái trả lời: “Dạ em đang muốn mua 1 cái túi xách tay để đi làm, em có xem mấy mẫu LV trên website của mình…”.
Giả sử cô gái là khách hàng còn người bán hàng là BA (vì người bán hàng đang đóng vai trò là người giải quyết vấn đề cho cô gái).
Vậy thì vấn đề của cô gái là gì? Hay nói cách khác, requirement của cô gái là gì?
Đó là cần mua một túi xách tay đi làm đúng không nào. Ngay lúc đầu, requirement này của cô gái có được nói ra, hay được phát biểu ra không?
Không, vì chỉ có mỗi cô gái mới hiểu được nhu cầu của cô mà thôi. Khi cô bước vào tiệm bán túi, người bán hàng hỏi thì cô mới trả lời là tôi cần mua một cái túi LV. Đó là khi requirement được phát biểu ra.
Và người BA (ở đây là người bán hàng) đã hỏi cô gái để có được thông tin: à, cô này đang cần 1 cái túi đi làm và cô muốn mua túi LV. Đây đúng là requirement của cô gái, do cô phát biểu ra. Nhưng thường thì nó đâu có dễ ăn như vậy :)) Với trường hợp này thì mọi thứ không dừng lại ở đó.
Anh em nghĩ 300.000đ có thể mua được một cái túi LV không. Mình không rành túi nhưng cũng biết chắc chắn là không rồi. Hàng đểu chắc cũng trên 300.
Với 300.000đ trong tay và đang cần 1 cái túi đi làm, nhu cầu thật sự của cô gái (requirement thật sự của cô gái) là: mua một cái túi xách tay hàng Việt Nam, bền chắc và chất lượng, với mức giá tối đa là 300.000đ.
Đó mới thật sự là requirement phù hợp nhất với cô gái!
Và requirement này không chỉ đơn giản là từ unstated, hỏi một cái, chuyển thành stated là thôi. Mà người BA (hay người bán hàng) cần phải tiếp tục elicit thêm thông tin. Như hỏi thêm: túi LV ở chỗ em có 3 mức giá, 850.000đ, trên 1.550.000đ và trên 4.200.000đ. Chị muốn xem mức giá nào. Lúc này, cô gái cảm thấy không đủ ngân sách thì sẽ chuyển hướng sang một mẫu túi xách khác. Rẻ và phù hợp với mình hơn.
Elicitation có đơn thuần chỉ là lấy thông tin từ khách hàng?
Elicitation không chỉ đơn thuần là lấy thông tin từ khách hàng mà còn phải khơi gợi và hướng khách hàng đi đúng hướng họ cần, gãi đúng chỗ họ ngứa. Và đó phải là hướng đi phù hợp với họ nhất trong thời điểm hiện tại. Đâu đó sẽ có thêm hàm lượng business consultant vào quá trình này nữa.
requirement là gì ae êiii :))
Requirement is a usable representation of a need
là sự diễn đạt cho một nhu cầu nào đó, nhưng sự diễn đạt này phải rõ ràng, để còn được sử dụng cho nhiều mục đích sau đó, như để làm document cho các stakeholders đọc hiểu,…
(thực tế những gì KH nói đều là requirement, đều thể hiện được 1 usable representation of a need”, các yêu cầu càng đưa dần xuống các bộ phận trực tiếp là việc càng được diễn đạt rõ ràng và chi tiết hơn)
chia theo vòng tròn công việc của BA, Requirement được chia làm mấy loại?
4 loại:
Business requirement, stakeholder requirement, solution requirement, and transition requirement
What is a business requirement?
is statements of goals, objectives, and outcomes that describe why a change has been initiated.
They can apply to the whole of an enterprise, a business area, or a specific initiative.
business requirement là gì zợ man??
là những YÊU CẦU RẤT HIGH-LEVEL từ phía khách hàng.
High level nghĩa là nó rất TỔNG QUÁT, và thể hiện được mục tiêu của tổ chức. 1 số dấu hiệ nhận biết đó là business requirements:
+thường là các MỤC TIÊU DÀI HẠN của tổ chức
+ được ÁP DỤNG CHO TOÀN TỔ CHỨC ĐÓ
+ thường được CÁC NHÂN VẬT CHỦ CHỐT PHÁT BIỂU: C-Level, Manager,…
b lấy vài ví dụ về business requirement được hông?
áp dụng thành công hệ thống loT cho nhà máy Bắc Ninh trước Q2/2022
+giảm 50% tỉ lệ sai sót trong qtr xử lý đơn hàng trước Q4/20220
+tăng 10% tỷ lệ khách quay lại mua hàng trong vòng 6 tháng áp dụng giải pháp CRM
what is the stakeholder requirement?
SR describes the NEEDS OF STAKEHOLDERS that must be met in order to achieve the business requirement
Stakeholders đưa ra các requirement là những thứ mà họ sẽ tương tác với hệ thống, DỰA TRÊN VAI TRÒ CỤ THỂ của họ trong tổ chức. Vậy nên cần chú ý đến các SME- subject matter expert, đặc biệt là các Domain SME. VD b làm hệ thống quản lý nội bộ cho Công ty du lịch lớn như Expedia, những Domain SME b có thể cần chú ý là?
Giám đốc nhân sự (HR Director), Giám đốc chăm sóc khách hàng (customer Service Director), Trưởng bộ phận điều phối tour (Tour Coordinator), IT Manager, sales director, etc.
mqh giữa business requirement vs stakeholder requirement?
Lấy ví dụ về business requirement và stakeholder requirement của Domain SME là Sales Team?
Business requirement chỉ đạt được khi stakeholder requirement đạt được.
VD: Business requirement là “tăng 10% tỷ lệ khách hàng quay lại mua hàng” thì Sales team phải:
+Biết được thông tin kH -> hệ thống phải quản lý được thông tin KH
+ theo dõi được các hđ tương tác với KH -> hệ thống phải lưu trữ được các hđ tương tác
+ phải đo lường được GIÁ TRỊ MÀ TỪNG KH ĐÓNG GÓP CHO CTY -> hthống phải tính toán được Customer Lifetime Value (CLV) cho từng KH,…
==> ko đạt được RS of domain SME là Sales team thì rất khó, hầu như là ko thể đạt được BR vì rõ ráng Sales team ko có ttin gì bám víu vào để ra các quyết định mua hàng giúp tăng !0% tỷ lệ KH quay lại mua hàng cả,
What is solution requirement?
solution requirements describe the capabilities and qualitites of a solution that meets the stakeholder requirements.
(là những yêu cầu về KHẢ NĂNG VÀ TIÊU CHUẨN mà giải pháp phải có để đạt được business requirement và stakeholder requirement.
Solution requirement chia làm mấy loại?
2 loại nè:
+nói về capability (khả năng) mà giải pháp có thể đạt được: Functional Requirement
+nói về quality( tiêu chuẩn): Non-Functional requirement
