Requirements là gì

     

Trước tiên thì các bạn thử đề cập lại cùng nhau xem nhu cầu dự án (requirement) là gì đã. Theo IIBA bao gồm định nghĩa tại BABOK V3.0 (để dò la IIBA là gì and BABOK thì các thử tìm kiếm google với mọi keywords kia nhé) bao gồm dẫn ra rằng:

“A requirement is a usable representation of a need. Requirements focus on understanding what kind of value could be delivered if a requirement is fulfilled.”

(lược dịch) Một yêu cầu là một đại diện thay mặt khả dụng của một có nhu cầu người mua. Yêu cầu tập trung vào việc hiểu chi tiêu mà nhu cầu đó đưa về sau khi được tán thành.”


*

*

*

Trong BABOK cũng có nhắc tới hồ hết loại nhu cầu tuỳ vào đối tượng người áp dụng đống ý: nhu yếu người mua, yêu cầu C.ty, hay yêu cầu giải pháp…Trong những mảng việc dự án công trình mình từng tham dự thì nhu yếu giải pháp (solution requirements) là đc phân tích và quản trị thẳng trực tiếp bởi vì những bố trực chiến dự án. Bởi ở đó triệu tập những nhu yếu chi tiết để đội phát triển hoàn toàn có thể tiến hành việc thành lập giải pháp, kể cả nhu yếu công dụng (functional requirements) and yêu cầu phi chức năng (non-functional requirements). Đây cũng chính là loại nhu yếu phổ cập duy nhất bởi phần nhiều dự án cải cách và phát triển mặt hàng. Vậy chính vậy những tía thẳng trực tiếp làm việc với team chiến thuật hay team development thì khi được nhu yếu viết tài liệu các bạn nên viết gì? and viết bởi thế nào đây?…

Bài Viết: Requirements là gì

Hãy test với nhau đặt vướng mắc and vấn đáp bao vây vấn đề này coi sao chúng ta nhé

Thứ nhất, nguyên nhân mình lại nói là “đc yêu cầu viết tài liệu”

Có rất nhiều dự án họ có nhu cầu tối giản hoá tài liệu & dùng những bộ công cụ nhằm quy mô hoá nhu cầu thay thế bởi dùng word, excel, powerpoint nhằm viết and lưu trữ theo cách thức cổ điển. Ví dụ: Promap được dùng để vừa quy mô hoá & quản trị quy trình chuyên môn, quản ngại trị workflow bên cạnh đó có công suất để phân tích và lý giải thêm những tình huống hay ràng buộc… Invision, Miro đc dùng để chế tạo ra prototype and flow màn hình, dòng làm việc người mua…Việc của ba sẽ là bám sát đít những team tham gia từ SME cho tới UX, PO, Delivery Manager, development team(s) để liên kết thông tin, đảm bảo bình yên thông tin đc đồng duy nhất and quy trình go-live của các nhu yếu đc mượt mà, phù hợp với hàng hóa roadmap của PO. Vậy thì document chỉ rất cần thiết khi tất cả những ra quyết định mấu chốt giải quyết những vấn đề phát sinh, phân tích liên quan của chỉnh sửa khi có xảy ra (điều ấy thì luôn luôn luôn xẩy ra rồi)…And khi cần phải có update thì các bên ảnh hưởng với nhau update trên phần đa tool sẵn bao gồm đã dùng…


Tuy vậy những dự án thế này lại không nhiều. BA chúng ta luôn được nhu yếu ớt “viết tài liệu dự án” trong job description khi tuyển dụng and luôn có lợi ích của việc viết documents mà chưa hẳn BA như thế nào cũng gật đầu ngay, nhất là những dự án công trình migration nhưng mà những bạn cần phải tiến hành reverse engineering để viết ra nhu yếu cho phương án mới, hay những dự án chúng ta take over từ 1 vendor khác & vendor lại “lười” viết documents…and cũng không phải development team nào thì cũng hào hứng cùng chúng ta “đọc code thằng khác”

Thứ hai, viết gì?

Cá nhân mình cảm nhận để dẫn ra đc một câu vấn đáp thoả mãn hết họ sẽ rất khó. Từng dự án, từng doanh nghiệp, người sử dụng sẽ có những nhu yếu khác nhau cho việc viết tài liệu. Đặc điểm là mỗi development team sẽ có phương thức đọc khác nhau, nhu yếu khác nhau…Nhưng dù gì thì tài liệu này nên vấn đáp được thắc mắc của development team: nhu yếu này tác động người tải nào?, họ đang đạt được gì từ nhu cầu này? & làm cố kỉnh nào nhằm nhu yếu đc tán thành?

Để biết cha nên viết gì, bọn họ thử suy nghĩ tới một vài gạch ốp đầu dòng bởi vậy này nhé:

Tạo một buổi họp để trao đổi phương thức viết, những ví dụ cần phải gồm trong specs (tài liệu ví dụ của nhu yếu). Hãy coi development team như một khách hàng của BA, hãy đưa cho họ một tập sticky notes & vài cây viết and chúng ta thực hành requirements elicitation với họ. Bảo đảm sẽ ra đc những nhu cầu với vấn đề viết tài liệu của BA. Mình đã từng cần sử dụng & vẫn liên tiếp tìm thời cơ tái diễn việc này mỗi khi có thời dịp (thường là sau mỗi dự án) nhằm team and bản thân cùng tiến bộ

Challenge templates nếu có. Những dự án công trình đã có nhiều sẵn template thì tốt nhất có thể quá rồi, tía cứ theo đó mà viết thôi. Phần nào đi sâu technical hoàn toàn có thể quay sang trọng Tech Lead nhằm hỏi tốt mời call hợp tác hoàn thành xong requirements. Tuy nhiên mình khuyến khích chúng ta BA bản thân từng thao tác chung xuất xắc từng lead là hãy challenge thiết yếu cái template mình sử dụng, nếu cảm giác quá cồng kềnh, tuyệt phần nào đó là không cần thiết cho dự án mình đang có tác dụng thì cứ mạnh dạn speak up.

Bạn đang xem: Requirements là gì


Tạo cuộc họp để phân tích và lý giải requirements cho đông đảo bên tác động thay thế bởi vì chỉ gửi documents & hỏi “let me know if any comments”. Bao gồm khi họ làm dự án outsource and giờ bạn có thể họp là giờ người sử dụng đang…ngủ. Hãy thử khuyến nghị thời hạn họp phù hợp nhất như đi làm việc việc sớm rộng 1-2 tiếng tốt ở lại trễ rộng 1-2 tiếng. Mình tin điều đó không xảy ra từng ngày, and mình cũng tin vào việc khi bạn bộc lộ đc commitment của bạn dạng thân thì tinh thần để được tạo nên dựng, không chỉ có với team mà còn với quý khách.

Nếu bọn họ thử google về phương thức viết tài liệu công dụng thì quả thực đọc mải mê không hết nhưng tựu chung sẽ có những chuẩn mực thông thường với yêu cầu như 5C, INVEST… Ở phía trên mình ko bàn tới điều ấy mà mình đang có nhu cầu muốn lược lại những kinh nghiệm tay nghề của tôi vậy nên này

Hãy cố gắng nỗ lực sử dụng hình hình ảnh thay cho chữ viết

Một wireframe mặc dù vẽ tay cũng dễ tưởng tượng hơn những là bạn lý giải dù cụ thể tới bao nhiêu.

Nếu yêu cầu là biên tập xảy ra trên một tốt nhiều màn hình của phần mềm có sẵn, hãy chụp màn hình and take lưu ý ngay trên hình chụp screen đó.


*

Nếu yêu cầu là một biên tập hình ảnh hưởng tới các màn hình, nhiều cách tiến hành người tiêu dùng hãy sinh sản một luồng screen bằng phương thức dễ chơi nhất chúng ta có thể (paint, excel, tuyệt miro…) để đưa vào tài liệu.

Xem thêm: Nồi Chiên Không Dầu Sharp 8.5 Lít Ks, Nồi Chiên Không Dầu Sharp 8

Nếu là change thì khôn cùng nên tất cả 2 phần: Giờ trên đây (Current tuyệt As-Is) and có nhu cầu (Expected xuất xắc Lớn-Be). Việc này nhằm cứu bạn đọc tưởng tượng cấp tốc nhất chỉnh sửa là gì and xảy ra nơi nào.

Thay việc viết Use Case bởi swimlane flow chart. Những bạn có thể cảm nhận qua phương thức mình viết bài bác là bản thân đang nỗ lực cố gắng dùng giờ Việt càng các càng tốt nhất có thể nhưng kỹ năng dịch thuật không mạnh bạo nên mình đảm bảo an ninh có những chỗ bọn họ đọc mà thiếu hiểu biết “bả đang hy vọng nói thứ gì”…Mình viết document biết rõ điểm yếu kém này buộc phải tối đa dùng hình vẽ, mặc dù là vẽ tay loằng ngoàng


Cuối thuộc là viết bởi thế nào?

Thực tiễn thì bạn dạng thân mình cũng tương đối nhiều lần trải nghiệm nhức thương từ những việc bị người sử dụng phàn nàn, team development phàn nàn về thủ tục viết requirements quá dài có tác dụng họ xấu hổ đọc, qúa nhiều ví dụ không tập trung…nên bản thân rất cảm thông sâu sắc với chúng ta bị càm ràm từ bằng lòng tới không đồng ý về tài liệu mình viết. Một số kinh nghiệm rút ra của tớ xin đc giải bày như sau:

Đừng ôm tư liệu ngồi viết rồi khi nào xong mới gửi bình chọn, hãy biến đổi nó thành một các bước như chúng ta development thao tác trong team là các bạn cũng setup những buổi elaboration để bạn phân tích và lý giải requirement và team cùng luận bàn.

Hãy đánh giá live với quý khách hàng ngay khi bao gồm thời cơ. & cũng biết nó thành một practice thường xuyên. Giả sử tất cả ngày nào tự nhiên ta hết chuyện về requirements hãy tranh thủ “tâm sự” cũng là 1 trong những phương thức ra đời mỗi quan tiền hệ cực kỳ tốt. Dùng phần lớn tool như webex, teams bọn họ đều hoàn toàn có thể có e-meeting với tài liệu mở trước mặt nhằm cùng bình chọn and confirm các điểm thiết yếu.

Đối chiếu hay keep track requirements mapping hay xuyên. Đó chính là điểm mình bị thừa nhận xét “khó tính & ôm đồm” lúc mình luôn hỏi hàng hóa roadmap, con kiến trúc dự án công trình and delivery plan. Những bạn cũng có thể bỏ lỡ bước đó tuy vậy với requirement mapping thì cần làm, tự có tác dụng một cảnh báo riêng cho khách hàng rất được vì phương thức này có thể cứu bạn nắm rõ mối quan lại hệ giữa những requirements (dependency) and tương tác (integration) nhằm đảm bảo an toàn khi bao gồm change xẩy ra thì impact và để được phân tích đầy đủ, né rủi ro của việc nợ thông tin.

Xem thêm: Vàng Sjc Là Gì ? Tại Sao Vàng Miếng 24K Của Sjc Luôn Đắt Hơn Vàng Các Hãng Khác

Hãy mạnh dạn hẹn một senior bố hơn vào cty hay đơn vị cứu mình khi đề xuất một lời khuyên.

Thể Loại: Share kiến thức Cộng Đồng
Bài Viết: Requirements Là Gì – qua quýt Về Requirement

Thể Loại: LÀ GÌ

Nguồn Blog là gì: https://vachngannamlong.com Requirements Là Gì – sơ sài Về Requirement