Phân tích kinh doanh là gì?

Phân tích kinh doanh là tập hợp các nhiệm vụ, kiến ​​thức và kỹ thuật cần thiết để xác định nhu cầu kinh doanh và xác định giải pháp cho các vấn đề kinh doanh của doanh nghiệp. Mặc dù, định nghĩa chung là tương tự nhau, các thực hành và thủ tục có thể khác nhau trong các ngành khác nhau.

Trong ngành Công nghệ thông tin, các giải pháp thường bao gồm thành phần phát triển hệ thống, nhưng cũng có thể bao gồm cải tiến quy trình hoặc thay đổi tổ chức.

Phân tích hoạt động kinh doanh cũng có thể được thực hiện để hiểu tình trạng hiện tại của một tổ chức hoặc để làm cơ sở cho việc xác định các nhu cầu kinh doanh. Tuy nhiên, trong hầu hết các trường hợp, phân tích kinh doanh được thực hiện để xác định và xác nhận các giải pháp đáp ứng nhu cầu, mục tiêu hoặc mục tiêu kinh doanh.

Nhà phân tích kinh doanh là ai?

Nhà phân tích kinh doanh là người phân tích một tổ chức hoặc lĩnh vực kinh doanh (thực tế hoặc giả định) và ghi lại hoạt động kinh doanh, quy trình hoặc hệ thống của nó, đánh giá mô hình kinh doanh hoặc sự tích hợp của nó với công nghệ. Tuy nhiên, các chức danh của tổ chức khác nhau như nhà phân tích, nhà phân tích kinh doanh, nhà phân tích hệ thống kinh doanh hoặc có thể là nhà phân tích hệ thống.

Tại sao lại là một nhà phân tích kinh doanh?

Các tổ chức sử dụng phân tích kinh doanh vì những lý do sau:

• Để hiểu cấu trúc và động lực của tổ chức trong đó một hệ thống sẽ được triển khai.

• Để hiểu các vấn đề hiện tại trong tổ chức mục tiêu và xác định các tiềm năng cải tiến.

• Để đảm bảo rằng khách hàng, người dùng cuối và nhà phát triển có hiểu biết chung về tổ chức mục tiêu.

Trong giai đoạn đầu của một dự án, khi các yêu cầu đang được giải thích bởi nhóm giải pháp và thiết kế, vai trò của Nhà phân tích kinh doanh là xem xét các tài liệu giải pháp, làm việc chặt chẽ với các nhà thiết kế giải pháp (nhóm CNTT) và người quản lý dự án để đảm bảo rằng yêu cầu rõ ràng.

Trong một tổ chức CNTT quy mô lớn điển hình, đặc biệt là trong môi trường phát triển, bạn có thể tìm thấy các nhóm giao hàng Tại chỗ cũng như nước ngoài có các vai trò nêu trên. Bạn có thể tìm thấy một “Nhà phân tích kinh doanh”, người đóng vai trò là người chủ chốt liên kết cả hai nhóm.

Đôi khi, anh ấy tương tác với người dùng Doanh nghiệp, đôi khi là người dùng kỹ thuật và cuối cùng với tất cả các bên liên quan trong các dự án để nhận được sự chấp thuận và cái gật đầu cuối cùng trước khi tiếp tục với tài liệu.

Do đó, vai trò của BA là rất quan trọng trong bước khởi đầu hiệu quả và thành công cho bất kỳ dự án nào.

Vai trò của một nhà phân tích kinh doanh CNTT

Vai trò của một Nhà phân tích kinh doanh bắt đầu từ việc xác định và xác định phạm vi các lĩnh vực kinh doanh của tổ chức, sau đó đưa ra các yêu cầu, phân tích và ghi lại các yêu cầu, truyền đạt những yêu cầu này cho các bên liên quan thích hợp, xác định giải pháp phù hợp và sau đó xác nhận giải pháp để tìm xem yêu cầu đáp ứng các tiêu chuẩn mong đợi.

Nó khác với các Nghề khác như thế nào?

Phân tích kinh doanh khác biệt với phân tích tài chính, quản lý dự án, đảm bảo chất lượng, phát triển tổ chức, kiểm tra, đào tạo và phát triển tài liệu. Tuy nhiên, tùy thuộc vào tổ chức, Chuyên viên phân tích kinh doanh có thể thực hiện một số hoặc tất cả các chức năng liên quan này.

Các nhà phân tích kinh doanh chỉ làm việc về phát triển hệ thống phần mềm có thể được gọi là nhà phân tích kinh doanh CNTT, nhà phân tích kinh doanh kỹ thuật, nhà phân tích kinh doanh trực tuyến, nhà phân tích hệ thống kinh doanh hoặc nhà phân tích hệ thống.

Phân tích kinh doanh cũng bao gồm công việc liên lạc giữa các bên liên quan, nhóm phát triển, nhóm kiểm tra, v.v.

Chu trình phát triển phần mềm

Vòng đời phát triển phần mềm (SDLC) là một quá trình theo sau trong một dự án phần mềm, trong một tổ chức phần mềm. Nó bao gồm một kế hoạch chi tiết mô tả cách phát triển, bảo trì, thay thế và thay đổi hoặc nâng cao phần mềm cụ thể. Nó xác định một phương pháp luận để cải thiện chất lượng của phần mềm và quá trình phát triển tổng thể.

• SDLC là một quá trình được sử dụng bởi các nhà phân tích CNTT để phát triển hoặc thiết kế lại hệ thống phần mềm chất lượng cao, đáp ứng cả yêu cầu của khách hàng và thế giới thực.

• Cần xem xét tất cả các khía cạnh liên quan của kiểm thử phần mềm, phân tích và bảo trì sau quy trình.

Các giai đoạn quan trọng của SDLC được mô tả trong hình minh họa sau:

Giai đoạn lập kế hoạch

Mọi hoạt động đều phải bắt đầu bằng một kế hoạch. Không lập kế hoạch là lập kế hoạch thất bại. Mức độ lập kế hoạch khác nhau giữa các mô hình này với mô hình khác, nhưng điều rất quan trọng là phải hiểu rõ những gì chúng ta sẽ xây dựng bằng cách tạo ra các thông số kỹ thuật của hệ thống.

Giai đoạn xác định

Trong giai đoạn này, chúng tôi phân tích và xác định cấu trúc của hệ thống. Chúng tôi xác định kiến ​​trúc, các thành phần và cách các thành phần này kết hợp với nhau để tạo ra một hệ thống hoạt động.

Giai đoạn thiết kế

Trong thiết kế hệ thống, các chức năng và hoạt động thiết kế được mô tả chi tiết, bao gồm bố cục màn hình, quy tắc nghiệp vụ, sơ đồ quy trình và các tài liệu khác. Đầu ra của giai đoạn này sẽ mô tả hệ thống mới như một tập hợp các mô-đun hoặc hệ thống con.

Giai đoạn xây dựng

Đây là giai đoạn phát triển. Chúng tôi bắt đầu tạo mã dựa trên thiết kế của hệ thống bằng cách sử dụng trình biên dịch, trình thông dịch, trình gỡ lỗi để đưa hệ thống vào hoạt động.

Thực hiện

Thực hiện là một phần của Giai đoạn Xây dựng. Trong giai đoạn này, chúng tôi bắt đầu tạo mã dựa trên thiết kế của hệ thống bằng cách sử dụng trình biên dịch, trình thông dịch, trình gỡ lỗi để đưa hệ thống vào hoạt động.

Giai đoạn thử nghiệm

Khi các phần khác nhau của hệ thống được hoàn thành; chúng được trải qua một loạt các bài kiểm tra. nó được kiểm tra dựa trên các yêu cầu để đảm bảo rằng sản phẩm đang thực sự giải quyết các nhu cầu được giải quyết trong giai đoạn yêu cầu.

• Các kế hoạch kiểm thử và các trường hợp kiểm thử được sử dụng để xác định lỗi và đảm bảo rằng hệ thống đang hoạt động theo các thông số kỹ thuật.

• Trong giai đoạn này, các loại kiểm thử khác nhau như kiểm thử đơn vị, kiểm thử thủ công, kiểm thử chấp nhận và kiểm thử hệ thống được thực hiện.

Theo dõi khiếm khuyết trong thử nghiệm

Báo cáo kiểm tra phần mềm được sử dụng để truyền đạt kết quả của các kế hoạch kiểm tra đã thực thi. Trong trường hợp này, một báo cáo phải chứa tất cả thông tin kiểm tra liên quan đến hệ thống hiện tại đang được kiểm tra. Tính đầy đủ của các báo cáo sẽ được xác minh trong các phiên hướng dẫn.

Thử nghiệm cho một dự án nhằm đạt được hai mục tiêu chính:

• Phát hiện các hư hỏng và khiếm khuyết trong hệ thống.

• Phát hiện sự không nhất quán giữa yêu cầu và việc thực hiện.

Lưu đồ sau đây mô tả Defect Tracking Process -

Để đạt được các mục tiêu chính, chiến lược thử nghiệm cho hệ thống được đề xuất thường sẽ bao gồm bốn cấp độ thử nghiệm.

Đây là kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử chấp nhận và kiểm thử hồi quy. Các phần phụ sau đây phác thảo các cấp độ kiểm tra này, vai trò của nhóm phát triển nào chịu trách nhiệm phát triển và thực hiện chúng cũng như các tiêu chí để xác định mức độ hoàn chỉnh của chúng.

Triển khai

Sau khi giai đoạn thử nghiệm kết thúc, hệ thống được giải phóng và đi vào môi trường sản xuất. Sau khi sản phẩm được kiểm tra và sẵn sàng triển khai, nó sẽ được phát hành chính thức trên thị trường thích hợp. Đôi khi, việc triển khai sản phẩm diễn ra theo từng giai đoạn theo chiến lược kinh doanh của tổ chức.

Trước tiên, sản phẩm có thể được phát hành trong một phân khúc hạn chế và được thử nghiệm trong môi trường kinh doanh thực tế (UAT- Thử nghiệm chấp nhận của người dùng). Sau đó, dựa trên phản hồi, sản phẩm có thể được phát hành như hiện tại hoặc với các cải tiến được đề xuất trong phân khúc thị trường mục tiêu.

Đăng quy trình SDLC

Sau khi sản phẩm được phát hành trên thị trường, việc bảo trì sản phẩm được thực hiện cho cơ sở khách hàng hiện tại.

Khi ở trong môi trường sản xuất, hệ thống sẽ phải chịu các sửa đổi vì các lỗi không được phát hiện hoặc các sự kiện không mong muốn khác. Hệ thống được đánh giá và chu kỳ được lặp lại để duy trì hệ thống.

Vai trò của nhà phân tích kinh doanh trong quá trình SDLC

Như chúng ta có thể thấy sơ đồ dưới đây, BA tham gia vào việc thúc đẩy yêu cầu kinh doanh và chuyển đổi chúng thành các yêu cầu giải pháp.

Ông tham gia vào việc dịch các tính năng của giải pháp thành các yêu cầu phần mềm. Sau đó dẫn đầu trong giai đoạn phân tích và thiết kế, ra lệnh trong phát triển mã, sau đó theo giai đoạn thử nghiệm trong quá trình sửa lỗi với tư cách là tác nhân thay đổi trong nhóm dự án và cuối cùng đáp ứng các yêu cầu của khách hàng.

Phân tích kinh doanh - Vai trò

Vai trò của một nhà phân tích kinh doanh trong một Dự án CNTT có thể nhiều lần. Các thành viên trong nhóm dự án có thể có nhiều vai trò và trách nhiệm. Trong một số dự án, BA có thể đảm nhận các vai trò của Nhà phân tích tình báo kinh doanh, Nhà thiết kế cơ sở dữ liệu, Chuyên gia đảm bảo chất lượng phần mềm, Người kiểm tra và / hoặc Nhà đào tạo khi có sẵn nguồn lực hạn chế.

Điều phối viên dự án, Trưởng nhóm phát triển ứng dụng hoặc Nhà phát triển cũng có thể đảm nhận vai trò của Nhà phân tích kinh doanh trong các dự án cụ thể.

Phân tích kinh doanh chồng chéo nhiều với phân tích các yêu cầu của doanh nghiệp để hoạt động như bình thường và để tối ưu hóa cách chúng hoạt động. Một số ví dụ về Phân tích kinh doanh là -

• Tạo kiến ​​trúc kinh doanh
• Chuẩn bị một tình huống kinh doanh
• Thực hiện đánh giá rủi ro
• Yêu cầu kích thích
• Phân tích quy trình kinh doanh
• Tài liệu về Yêu cầu

Các vai trò chính của BA

Vai trò quan trọng của hầu hết các nhà phân tích kinh doanh là liên lạc giữa doanh nghiệp và các nhà phát triển kỹ thuật. Các nhà phân tích kinh doanh được làm việc cùng với các khách hàng doanh nghiệp để thu thập / xác định các yêu cầu của hệ thống hoặc quy trình nhằm cải thiện năng suất trong khi đồng thời làm việc với các nhóm kỹ thuật để thiết kế và triển khai hệ thống / quy trình.

Là một cộng tác viên

Trách nhiệm chính của BA là đóng góp vào sự phát triển của Người dùng doanh nghiệp / người dùng chính trong việc xác định các vấn đề kinh doanh, nhu cầu và chức năng, hiểu mối quan tâm và yêu cầu của các bên liên quan để xác định các cơ hội cải tiến và đóng góp đầu vào kinh doanh để phát triển trường hợp kinh doanh cho CNTT dự án phát triển hệ thống.

Với tư cách là người hỗ trợ

Một Nhà phân tích kinh doanh cũng phải tạo điều kiện / phối hợp trong việc khơi gợi và phân tích các yêu cầu, cộng tác và giao tiếp với các bên liên quan cũng như quản lý các kỳ vọng và nhu cầu của họ, đồng thời đảm bảo các yêu cầu hoàn chỉnh, rõ ràng và ánh xạ chúng theo nhu cầu kinh doanh theo thời gian thực của một tổ chức.

Là một nhà phân tích

Một vai trò quan trọng khác sẽ là đánh giá sự sẵn sàng của hệ thống và tổ chức được đề xuất để triển khai hệ thống và cung cấp hỗ trợ cho người dùng và phối hợp với nhân viên CNTT.

Để giúp xem xét và cung cấp đầu vào cho việc thiết kế hệ thống CNTT được đề xuất từ ​​góc độ kinh doanh, giải quyết các vấn đề / xung đột giữa các bên liên quan, giúp tổ chức UAT toàn diện và chất lượng thông qua hỗ trợ người dùng trong việc phát triển các trường hợp thử nghiệm và giúp tổ chức đào tạo với mục đích đảm bảo đã triển khai hệ thống CNTT có khả năng đáp ứng nhu cầu và yêu cầu của doanh nghiệp cũng như hiện thực hóa các lợi ích mong đợi.

Lập kế hoạch và giám sát các hoạt động Phân tích kinh doanh để phát triển phạm vi, lịch trình và cách tiếp cận để thực hiện các hoạt động liên quan đến phân tích kinh doanh cho dự án phát triển hệ thống CNTT, theo dõi tiến độ, phối hợp với Giám đốc dự án nội bộ và báo cáo về doanh thu, lợi nhuận, rủi ro và các vấn đề ở bất cứ đâu thích hợp.

Các trách nhiệm chính của một nhà phân tích kinh doanh

Bộ trách nhiệm của một nhà phân tích kinh doanh sẽ yêu cầu anh ta hoàn thành các nhiệm vụ khác nhau trong các giai đoạn khác nhau của dự án và chúng được giải thích dưới đây:

Giai đoạn bắt đầu

Giai đoạn này sẽ đánh dấu sự khởi đầu của một dự án mới và một nhà phân tích kinh doanh sẽ thực hiện các trách nhiệm sau:

• Hỗ trợ thực hiện phân tích chi phí - lợi ích của dự án.
• Hiểu trường hợp kinh doanh.
• Xác định tính khả thi của giải pháp / dự án / sản phẩm.
• Giúp đỡ trong việc tạo điều lệ dự án.
• Xác định các bên liên quan trong dự án.

Giai đoạn lập kế hoạch

Giai đoạn này sẽ liên quan đến việc thu thập các yêu cầu và lập kế hoạch, dự án sẽ được thực hiện và quản lý như thế nào. Trách nhiệm của anh ta sẽ bao gồm các chức năng dưới đây:

• Đưa ra các yêu cầu
• Phân tích, sắp xếp và lập hồ sơ các yêu cầu.
• Quản lý các yêu cầu bằng cách tạo Ca sử dụng, RTM, BRD, SRS, v.v.
• Đánh giá các giải pháp đề xuất.
• Liên lạc và tăng cường giao tiếp với các bên liên quan.
• Hỗ trợ xây dựng kế hoạch quản lý dự án.
• Giúp tìm ra phạm vi, các ràng buộc, giả định và rủi ro của dự án.
• Hỗ trợ thiết kế trải nghiệm người dùng của giải pháp.

Giai đoạn thực hiện

Giai đoạn này đánh dấu sự phát triển của giải pháp theo các yêu cầu đã thu thập được. Các trách nhiệm bao gồm -

• Giải thích các yêu cầu cho nhóm CNTT / phát triển.

• Làm rõ những nghi ngờ, băn khoăn liên quan đến giải pháp đề xuất được phát triển.

• Thảo luận và ưu tiên các thay đổi trong phạm vi dự án và đạt được thỏa thuận.

• Tạo tập lệnh thử nghiệm beta để thử nghiệm ban đầu.

• Chia sẻ các mô-đun đang phát triển với các bên liên quan và thu hút phản hồi của họ.

• Tuân theo thời hạn và quản lý kỳ vọng của các bên liên quan.

• Giải quyết xung đột và quản lý thông tin liên lạc với nhóm dự án.

Giai đoạn Giám sát và Kiểm soát

Trong giai đoạn này, dự án được đo lường và kiểm soát mọi sai lệch so với kế hoạch ban đầu. Giai đoạn này chạy đồng thời với giai đoạn thực hiện.

• Phát triển các kịch bản thử nghiệm và tiến hành thử nghiệm mô-đun và tích hợp toàn diện.

• Tiến hành UAT (sử dụng thử nghiệm chấp nhận) và tạo báo cáo thử nghiệm.

• Đạt được sự chấp nhận / phê duyệt các sản phẩm được giao từ khách hàng.

• Giải thích các yêu cầu thay đổi cho nhóm phát triển.

• Theo dõi sự phát triển của các yêu cầu thay đổi và xác minh việc thực hiện chúng theo mục tiêu của dự án.

Giai đoạn kết thúc

Giai đoạn này đánh dấu sự kết thúc của dự án. Các trách nhiệm là -

• Trình bày dự án đã hoàn thành cho khách hàng và được họ chấp nhận.

• Tạo sổ tay hướng dẫn đào tạo người dùng, bất kỳ tài liệu chức năng nào và các hướng dẫn giảng dạy khác.

• Tiến hành thử nghiệm tích hợp phức tạp trong môi trường sản xuất.

• Tạo tài liệu sản phẩm cuối cùng, tài liệu các bài học kinh nghiệm của dự án.

Những gì một BA được mong đợi để cung cấp?

Chuyên viên phân tích kinh doanh đóng vai trò là cầu nối giữa người dùng doanh nghiệp và nhân viên kỹ thuật CNTT. Sự hiện diện của họ sẽ góp phần đáng kể vào sự thành công của các dự án CNTT. Có rất nhiều lợi ích khi có một nhà phân tích kinh doanh chuyên dụng. Một nhà phân tích kinh doanh chuyên dụng có thể -

• Cung cấp một phạm vi dự án rõ ràng từ quan điểm kinh doanh.

• Phát triển các trường hợp kinh doanh hợp lý và ước tính thực tế hơn về các nguồn lực và lợi ích kinh doanh.

• Chuẩn bị các báo cáo tốt hơn về phạm vi dự án, lập kế hoạch và quản lý về chi phí và tiến độ, đặc biệt là đối với các dự án CNTT quy mô lớn.

• Đưa ra các yêu cầu rõ ràng và ngắn gọn, do đó, giúp cung cấp các yêu cầu rõ ràng và chính xác hơn, nếu dự án CNTT được thuê ngoài.

• Khơi gợi nhu cầu kinh doanh thực sự từ người dùng và quản lý hiệu quả các kỳ vọng của người dùng.

• Cải thiện chất lượng thiết kế cho hệ thống CNTT được đề xuất để nó đáp ứng các yêu cầu của người dùng.

• Đảm bảo chất lượng của hệ thống được phát triển trước khi chuyển cho người dùng cuối để xem xét và chấp nhận.

• Sắp xếp kiểm tra chất lượng toàn diện trên các hệ thống được giao và cung cấp phản hồi cho nhân viên kỹ thuật CNTT.

Phân tích kinh doanh - Công cụ và kỹ thuật

Một Nhà phân tích Kinh doanh nên làm quen với các công cụ phân tích khác nhau và các công nghệ liên quan khi bạn đang đội chiếc mũ BA. Ý tôi là, nếu bạn đang giữ vị trí này.

Như chúng ta đã tìm hiểu trước đó, phân tích kinh doanh là một quá trình mà bạn đang cố gắng hiểu một doanh nghiệp kinh doanh và xác định các cơ hội, lĩnh vực vấn đề, vấn đề và gặp gỡ nhiều người có nhiều vai trò và trách nhiệm như CEO, VP, Director và hiểu yêu cầu kinh doanh của họ.

Về cơ bản, có 3 loại phân tích Kinh doanh mà chúng tôi có thể phân loại thành:

• Strategic Analysis- Phân tích chiến lược kinh doanh giải quyết công việc trước dự án. Đây là phương pháp hoặc quy trình xác định các vấn đề kinh doanh, đề ra các chiến lược, mục tiêu và mục tiêu kinh doanh giúp ban lãnh đạo cao nhất. Nó cung cấp báo cáo thông tin quản lý cho quá trình ra quyết định hiệu quả.

• Tactical Analysis - Nó liên quan đến kiến ​​thức về các kỹ thuật phân tích kinh doanh cụ thể để áp dụng vào đúng thời điểm trong dự án thích hợp.

• Operational Analysis- Trong loại phân tích Kinh doanh này, chúng tôi tập trung vào khía cạnh kinh doanh bằng cách tận dụng công nghệ thông tin. Đây cũng là một quá trình nghiên cứu các hệ thống hoạt động với mục đích xác định các cơ hội cải tiến hoạt động kinh doanh.

Đối với mỗi loại phân tích, có một bộ công cụ có sẵn trên thị trường và dựa trên nhu cầu và yêu cầu của tổ chức, chúng sẽ được sử dụng.

Tuy nhiên, để hiện thực hóa các yêu cầu kinh doanh thành thông tin dễ hiểu, một BA giỏi sẽ tận dụng các kỹ thuật Tìm kiếm sự thật, Phỏng vấn, Đánh giá Tài liệu, Bảng câu hỏi, Lấy mẫu và Nghiên cứu trong các hoạt động hàng ngày của họ.

Yêu cầu chức năng và phi chức năng

Chúng ta có thể chia một yêu cầu thành hai loại chính như yêu cầu Chức năng và Không chức năng.

Đối với tất cả các dự án công nghệ, các yêu cầu chức năng và phi chức năng phải được tách biệt và phân tích riêng biệt.

Để xác định công cụ thích hợp và một kỹ thuật thích hợp có thể là một thách thức khó khăn. Cho dù bạn đang làm một ứng dụng hoàn toàn mới hay thay đổi một ứng dụng hiện có. Tự nó xem xét kỹ thuật phù hợp cho quá trình chức năng là một nghệ thuật.

Tổng quan về các kỹ thuật phân tích kinh doanh được sử dụng rộng rãi hiện nay trên thị trường -

Quy trình	Kỹ thuật	Quá trình phân phối (Kết quả)
Để xác định các yêu cầu chức năng và phi chức năng	Phiên JAD Kịch bản và Ca sử dụng Mô hình tổ chức Mô hình phạm vi Suy giảm chức năng Interviews Quan sát (Đánh bóng công việc) Nhóm tiêu điểm Chấp nhận và đánh giá Sơ đồ trình tự Câu chuyện của người dùng Brainstorming Storyboarding Prototyping Đi bộ có cấu trúc Phân tích sự kiện Phân tích Quy tắc Kinh doanh Hội thảo yêu cầu Phân tích rủi ro Phân tích nguyên nhân gốc rễ	Business Requirements Documents - Yêu cầu kinh doanh và chức năng Những yêu cầu phi lý Quy tắc kinh doanh Yêu cầu Ma trận xác định nguồn gốc Common Template - Tài liệu Yêu cầu Kinh doanh

Khả năng áp dụng của các công cụ và quy trình

Mặc dù có nhiều công cụ và thủ tục khác nhau dành cho các nhà phân tích kinh doanh, nhưng tất cả đều phụ thuộc vào thực tiễn hiện tại của tổ chức và cách họ muốn sử dụng nó.

Ví dụ, root-cause analysis được sử dụng khi có yêu cầu đi sâu hơn vào một lĩnh vực hoặc chức năng quan trọng nào đó.

Tuy nhiên, tài liệu yêu cầu nghiệp vụ là cách phổ biến nhất và được chấp nhận để đưa các yêu cầu vào định dạng tài liệu.

Trong các chương tiếp theo, chúng ta sẽ thảo luận sâu hơn về một số kỹ thuật trên.

Phân tích kinh doanh - Phiên JAD

Phát triển Ứng dụng Chung (JAD) là một quy trình được sử dụng để thu thập các yêu cầu nghiệp vụ trong khi phát triển các hệ thống thông tin mới cho một công ty. Quy trình JAD cũng có thể bao gồm các cách tiếp cận để tăng cường sự tham gia của người dùng, thúc đẩy quá trình phát triển và cải thiện chất lượng của các thông số kỹ thuật. Mục đích của một phiên JAD là tập hợp các chuyên gia chủ đề / Nhà phân tích kinh doanh hoặc chuyên gia CNTT để đưa ra các giải pháp.

Nhà phân tích kinh doanh là người tương tác với toàn bộ nhóm và thu thập thông tin, phân tích nó và đưa ra một tài liệu. Anh ấy đóng một vai trò rất quan trọng trong phiên JAD.

Sử dụng một phiên JAD

Các phiên JAD là các hội thảo có cấu trúc cao, được tạo điều kiện để tập hợp các nhà ra quyết định của khách hàng và nhân viên CNTT để tạo ra các sản phẩm chất lượng cao trong thời gian ngắn.

Nói cách khác, Phiên JAD cho phép khách hàng và nhà phát triển nhanh chóng đi đến thỏa thuận về phạm vi, mục tiêu và thông số kỹ thuật cơ bản của một dự án hoặc trong trường hợp không đi đến thỏa thuận có nghĩa là dự án cần được đánh giá lại.

Nói một cách đơn giản, các phiên JAD có thể

• Simplify - Nó hợp nhất hàng tháng các cuộc họp và các cuộc điện thoại thành một hội thảo có cấu trúc.

• Identify - Vấn đề và người tham gia

• Quantify - Thông tin và nhu cầu xử lý

• Clarify - Kết tinh và làm rõ tất cả các yêu cầu đã thống nhất trong phiên họp.

• Unify - Đầu ra của một giai đoạn phát triển là đầu vào cho giai đoạn tiếp theo.

• Satisfy- Khách hàng xác định hệ thống; do đó, nó là hệ thống của họ. Sự tham gia chung mang lại một phần trong kết quả; họ trở nên cam kết với sự thành công của hệ thống.

Những người tham gia một phiên JAD

Những người tham gia vào một phiên JAD như sau:

Nhà tài trợ điều hành

Nhà tài trợ điều hành là người điều khiển dự án ─ chủ sở hữu hệ thống. Họ thường ở những vị trí cao hơn và có thể đưa ra quyết định và đưa ra chiến lược, kế hoạch và hướng đi cần thiết.

Chuyên gia về vấn đề

Đây là những người dùng doanh nghiệp và các chuyên gia bên ngoài, những người cần thiết cho một hội thảo thành công. Các chuyên gia về chủ đề là xương sống của phiên họp JAD. Họ sẽ thúc đẩy những thay đổi.

Người hướng dẫn

Ông chủ trì cuộc họp; anh ta xác định các vấn đề có thể được giải quyết như một phần của cuộc họp. Người điều hành không đóng góp thông tin cho cuộc họp.

Người dùng chính

Người dùng chính hay còn được gọi là người dùng siêu cấp trong một số trường hợp đã được sử dụng thay thế cho nhau và khác nhau giữa các công ty. Người dùng chính thường là người dùng doanh nghiệp gắn bó chặt chẽ hơn với dự án CNTT và chịu trách nhiệm về cấu hình hồ sơ của các thành viên trong nhóm của họ trong suốt quá trình dự án.

Ví dụ: Giả sử John là người dùng chính và Nancy, Evan là người dùng của hệ thống SAP. Trong trường hợp này, Nancy và Evan không có quyền truy cập để thay đổi chức năng và hồ sơ trong khi John là Người dùng chính có quyền chỉnh sửa hồ sơ với nhiều quyền hơn.

Cách tiếp cận JAD, so với cách làm truyền thống hơn, được cho là dẫn đến thời gian phát triển nhanh hơn và sự hài lòng của khách hàng cao hơn, vì khách hàng tham gia trong suốt quá trình phát triển. Trong khi so sánh, trong cách tiếp cận truyền thống để phát triển hệ thống, nhà phát triển điều tra các yêu cầu hệ thống và phát triển một ứng dụng, với đầu vào của khách hàng bao gồm một loạt các cuộc phỏng vấn.

Kỹ thuật thu thập yêu cầu

Các kỹ thuật mô tả cách các nhiệm vụ được thực hiện trong các trường hợp cụ thể. Một nhiệm vụ có thể không có hoặc một hoặc nhiều kỹ thuật liên quan. Một kỹ thuật nên liên quan đến ít nhất một nhiệm vụ.

Sau đây là một số kỹ thuật thu thập yêu cầu nổi tiếng -

Động não

Động não được sử dụng trong việc thu thập yêu cầu để có được càng nhiều ý tưởng càng tốt từ nhóm người. Thường được sử dụng để xác định các giải pháp khả thi cho các vấn đề và làm rõ chi tiết các cơ hội.

Phân tích tài liệu

Việc xem xét tài liệu của một hệ thống hiện có có thể hữu ích khi tạo tài liệu quy trình AS – IS, cũng như thúc đẩy phân tích lỗ hổng để xác định phạm vi các dự án di chuyển. Trong một thế giới lý tưởng, chúng tôi thậm chí sẽ xem xét các yêu cầu thúc đẩy việc tạo ra hệ thống hiện có - một điểm khởi đầu để ghi lại các yêu cầu hiện tại. Nuggets thông tin thường bị chôn vùi trong các tài liệu hiện có giúp chúng tôi đặt câu hỏi như một phần của việc xác thực tính đầy đủ của yêu cầu.

Nhóm tiêu điểm

Nhóm tập trung là tập hợp những người đại diện cho người dùng hoặc khách hàng của sản phẩm để nhận phản hồi. Phản hồi có thể được thu thập về các nhu cầu / cơ hội / vấn đề để xác định các yêu cầu, hoặc có thể được thu thập để xác nhận và tinh chỉnh các yêu cầu đã được gợi ý. Hình thức nghiên cứu thị trường này khác với động não ở chỗ nó là một quá trình được quản lý với những người tham gia cụ thể.

Phân tích giao diện

Các giao diện cho một sản phẩm phần mềm có thể là con người hoặc máy móc. Tích hợp với các hệ thống và thiết bị bên ngoài chỉ là một giao diện khác. Phương pháp thiết kế lấy người dùng làm trung tâm rất hiệu quả trong việc đảm bảo rằng chúng tôi tạo ra phần mềm có thể sử dụng được. Phân tích giao diện - xem xét các điểm tiếp xúc với các hệ thống bên ngoài khác là điều quan trọng để đảm bảo rằng chúng tôi không bỏ qua các yêu cầu không hiển thị ngay cho người dùng.

Phỏng vấn

Phỏng vấn các bên liên quan và người dùng là rất quan trọng để tạo ra phần mềm tuyệt vời. Nếu không hiểu mục tiêu và mong đợi của người dùng và các bên liên quan, chúng tôi rất khó có thể đáp ứng được họ. Chúng tôi cũng phải nhìn nhận quan điểm của từng người được phỏng vấn để có thể cân nhắc và giải quyết các đầu vào của họ một cách hợp lý. Lắng nghe là kỹ năng giúp một nhà phân tích giỏi nhận được nhiều giá trị từ một cuộc phỏng vấn hơn một nhà phân tích bình thường.

Quan sát

Bằng cách quan sát người dùng, nhà phân tích có thể xác định quy trình, các bước, điểm khó khăn và cơ hội cải tiến. Quan sát có thể thụ động hoặc chủ động (đặt câu hỏi trong khi quan sát). Quan sát thụ động tốt hơn để nhận phản hồi về mẫu thử nghiệm (để tinh chỉnh các yêu cầu), trong đó quan sát tích cực sẽ hiệu quả hơn trong việc hiểu quy trình kinh doanh hiện có. Có thể sử dụng một trong hai cách tiếp cận.

Tạo mẫu

Tạo mẫu là một kỹ thuật tương đối hiện đại để thu thập các yêu cầu. Trong cách tiếp cận này, bạn thu thập các yêu cầu sơ bộ mà bạn sử dụng để xây dựng phiên bản ban đầu của giải pháp - một nguyên mẫu. Bạn hiển thị điều này cho khách hàng, sau đó họ sẽ cung cấp cho bạn các yêu cầu bổ sung. Bạn thay đổi ứng dụng và quay vòng với máy khách một lần nữa. Quá trình lặp đi lặp lại này tiếp tục cho đến khi sản phẩm đáp ứng được khối lượng quan trọng của nhu cầu kinh doanh hoặc cho một số lần lặp lại đã thỏa thuận.

Hội thảo yêu cầu

Các hội thảo có thể rất hiệu quả để thu thập các yêu cầu. Có cấu trúc hơn một phiên động não, các bên liên quan cộng tác để thực hiện các yêu cầu về tài liệu. Một cách để nắm bắt sự hợp tác là tạo ra các tạo tác mô hình miền (như sơ đồ tĩnh, sơ đồ hoạt động). Một hội thảo sẽ hiệu quả hơn với hai nhà phân tích hơn là với một.

Kỹ thuật đảo ngược

Khi một dự án di chuyển không có quyền truy cập vào tài liệu đầy đủ của hệ thống hiện có, kỹ thuật đảo ngược sẽ xác định những gì hệ thống làm. Nó sẽ không xác định hệ thống phải làm gì, và sẽ không xác định khi nào hệ thống làm sai.

Khảo sát / Bảng câu hỏi

Khi thu thập thông tin từ nhiều người - quá nhiều người để phỏng vấn với hạn chế về ngân sách và thời gian - có thể sử dụng bảng khảo sát hoặc bảng câu hỏi. Cuộc khảo sát có thể buộc người dùng chọn từ các lựa chọn, xếp hạng điều gì đó (“Đồng ý hoàn toàn, đồng ý…”) hoặc có các câu hỏi mở cho phép trả lời dạng tự do. Thiết kế khảo sát rất khó - các câu hỏi có thể làm sai lệch người trả lời.

Tài liệu Yêu cầu Chức năng

Tài liệu Yêu cầu Chức năng (FRD) là một tuyên bố chính thức về các yêu cầu chức năng của ứng dụng. Nó phục vụ cùng một mục đích như một hợp đồng. Ở đây, các nhà phát triển đồng ý cung cấp các khả năng được chỉ định. Khách hàng đồng ý nhận thấy sản phẩm đạt yêu cầu nếu nó cung cấp các khả năng được quy định trong FRD.

Các yêu cầu chức năng nắm bắt hành vi dự kiến ​​của hệ thống. Hành vi này có thể được thể hiện dưới dạng các dịch vụ, nhiệm vụ hoặc chức năng mà hệ thống được yêu cầu thực hiện. Tài liệu phải được điều chỉnh để phù hợp với nhu cầu của một dự án cụ thể. Chúng xác định những thứ như tính toán hệ thống, thao tác và xử lý dữ liệu, giao diện người dùng và tương tác với ứng dụng.

Tài liệu Yêu cầu Chức năng (FRD) có các đặc điểm sau:

• Nó chứng tỏ rằng ứng dụng cung cấp giá trị về các mục tiêu kinh doanh và quy trình kinh doanh trong vài năm tới.

• Nó chứa một tập hợp đầy đủ các yêu cầu cho ứng dụng. Nó không có chỗ cho bất kỳ ai giả định bất cứ điều gì không được nêu trong FRD.

• Nó là giải pháp độc lập. ERD là một tuyên bố về những gì ứng dụng phải làm - không phải về cách nó hoạt động. FRD không cam kết các nhà phát triển thiết kế. Vì lý do đó, bất kỳ tham chiếu nào đến việc sử dụng một công nghệ cụ thể là hoàn toàn không phù hợp trong FRD.

Yêu cầu chức năng phải bao gồm những điều sau:

• Mô tả của data được nhập vào hệ thống

• Mô tả của operations thực hiện bởi mỗi màn hình

• Mô tả của work-flows thực hiện bởi hệ thống

• Mô tả của system reports hoặc các đầu ra khác

• Ai có thể vào data vào hệ thống?

• Cách hệ thống đáp ứng được regulatory requirements?

Đặc tả chức năng được thiết kế để khán giả nói chung có thể đọc được. Người đọc nên hiểu hệ thống, nhưng không cần kiến ​​thức kỹ thuật để hiểu tài liệu này.

Yêu cầu chức năng Cung cấp

Tài liệu Yêu cầu Kinh doanh (BRD) bao gồm:

• Functional Requirements- Một tài liệu chứa các yêu cầu chi tiết cho hệ thống đang được phát triển. Các yêu cầu này xác định các tính năng chức năng và khả năng mà một hệ thống phải có. Đảm bảo rằng mọi giả định và ràng buộc được xác định trong Trường hợp kinh doanh vẫn chính xác và cập nhật.

• Business Process Model - Một mô hình về trạng thái hiện tại của quy trình (mô hình "nguyên trạng") hoặc một khái niệm về quy trình sẽ trở thành (mô hình "hiện thực")

• System Context Diagram - Sơ đồ ngữ cảnh hiển thị ranh giới hệ thống, các thực thể bên ngoài và bên trong tương tác với hệ thống và các luồng dữ liệu liên quan giữa các thực thể bên ngoài và bên trong này.

• Flow Diagrams (as-is or to-be)- Sơ đồ mô tả bằng đồ thị trình tự hoạt động hoặc sự di chuyển của dữ liệu cho một quy trình kinh doanh. Một hoặc nhiều sơ đồ luồng được đưa vào tùy thuộc vào độ phức tạp của mô hình.

• Business Rules and Data Requirements - Các quy tắc nghiệp vụ xác định hoặc ràng buộc một số khía cạnh của nghiệp vụ và được sử dụng để xác định các ràng buộc dữ liệu, giá trị mặc định, phạm vi giá trị, số lượng, kiểu dữ liệu, tính toán, ngoại lệ, các yếu tố bắt buộc và tính toàn vẹn quan hệ của dữ liệu.

• Data Models - Sơ đồ mối quan hệ thực thể, Mô tả thực thể, Sơ đồ lớp

• Conceptual Model - Hiển thị mức độ cao của các thực thể khác nhau cho một chức năng kinh doanh và cách chúng liên quan với nhau.

• Logical Model - Minh họa các thực thể, thuộc tính và mối quan hệ cụ thể liên quan đến một chức năng kinh doanh và thể hiện tất cả các định nghĩa, đặc điểm và mối quan hệ của dữ liệu trong môi trường kinh doanh, kỹ thuật hoặc khái niệm.

• Data Dictionary and Glossary - Tập hợp thông tin chi tiết về các phần tử dữ liệu, trường, bảng và các thực thể khác bao gồm mô hình dữ liệu nền tảng cơ sở dữ liệu hoặc hệ thống quản lý dữ liệu tương tự.

• Stakeholder Map- Xác định tất cả các bên liên quan bị ảnh hưởng bởi thay đổi được đề xuất và mức độ ảnh hưởng / quyền hạn của họ đối với các yêu cầu. Tài liệu này được phát triển trong giai đoạn khởi đầu của Phương pháp Quản lý Dự án (PMM) và thuộc sở hữu của Người Quản lý Dự án nhưng cần được nhóm dự án cập nhật vì các Bên liên quan mới / thay đổi được xác định trong suốt quá trình.

• Requirements Traceability Matrix - Một bảng minh họa các liên kết hợp lý giữa các yêu cầu chức năng riêng lẻ và các kiểu tạo tác hệ thống khác, bao gồm các Yêu cầu chức năng khác, Ca sử dụng / Câu chuyện người dùng, Kiến trúc và các yếu tố thiết kế, Mô-đun mã, Trường hợp thử nghiệm và Quy tắc kinh doanh.

Phần mềm Yêu cầu kỹ thuật

Đặc tả Yêu cầu Phần mềm (SRS) là một tài liệu, được sử dụng như một phương tiện giao tiếp giữa các khách hàng. Đặc tả yêu cầu phần mềm ở dạng cơ bản nhất của nó là một tài liệu chính thức được sử dụng để giao tiếp các yêu cầu phần mềm giữa khách hàng và nhà phát triển.

Một tài liệu SRS tập trung vào WHAT cần phải được thực hiện và cẩn thận tránh giải pháp (how to do). Nó phục vụ như một hợp đồng giữa nhóm phát triển và khách hàng. Các yêu cầu ở giai đoạn này được viết bằng thuật ngữ người dùng cuối. Nếu cần thiết, sau này một đặc tả yêu cầu chính thức sẽ được phát triển từ nó.

SRS là một mô tả đầy đủ về hoạt động của một hệ thống được phát triển và có thể bao gồm một tập hợp các trường hợp sử dụng mô tả các tương tác mà người dùng sẽ có với phần mềm.

Mục đích của SRS

SRS là công cụ giao tiếp giữa Khách hàng / Khách hàng, Nhà phân tích kinh doanh, Nhà phát triển hệ thống, Nhóm bảo trì. Nó cũng có thể là hợp đồng giữa người mua và nhà cung cấp.

• Nó sẽ tạo nền tảng vững chắc cho giai đoạn thiết kế
• Hỗ trợ quản lý và kiểm soát dự án
• Giúp kiểm soát và phát triển hệ thống

Đặc tả Yêu cầu phần mềm phải Hoàn chỉnh, Nhất quán, Có thể theo dõi, Rõ ràng và Có thể xác minh.

Những điều sau đây cần được giải quyết trong đặc tả hệ thống:

• Xác định chức năng của hệ thống
• Xác định phân vùng chức năng phần cứng / phần mềm
• Xác định đặc điểm kỹ thuật hiệu suất
• Xác định Phân vùng Hiệu suất Phần cứng / Phần mềm
• Xác định Yêu cầu An toàn
• Xác định Giao diện Người dùng (hướng dẫn sử dụng)
• Cung cấp Bản vẽ / Hướng dẫn Lắp đặt
• Mẫu đặc tả yêu cầu phần mềm

Lịch sử sửa đổi

Ngày	Sự miêu tả	Tác giả	Bình luận
<ngày>	<Phiên bản 1>	<Tên của bạn>	<Bản sửa đổi đầu tiên>

Phê duyệt tài liệu

Đặc tả yêu cầu phần mềm sau đây đã được chấp nhận và chấp thuận bởi những người sau:

Chữ ký	Tên in	Tiêu đề	Ngày
	<Tên của bạn>	Phần mềm dẫn đầu Eng.
	David	Người hướng dẫn

Phân tích kinh doanh - Trường hợp sử dụng

Một trong chín sơ đồ của UML là Sơ đồ ca sử dụng. Đây không chỉ là yêu cầu quan trọng mà còn cần thiết cho các dự án phần mềm. Về cơ bản, nó được sử dụng trong vòng đời Phần mềm. Như chúng ta biết có nhiều giai đoạn khác nhau trong chu kỳ phát triển và giai đoạn được sử dụng nhiều nhất cho các Ca sử dụng sẽ là trong giai đoạn thu thập yêu cầu.

Use-Case là gì?

Ca sử dụng mô tả một chuỗi các hành động, được thực hiện bởi một hệ thống cung cấp giá trị cho một tác nhân. Trường hợp sử dụng mô tả hành vi của hệ thống trong các điều kiện khác nhau khi nó phản hồi yêu cầu từ một trong các bên liên quan, được gọi làprimary actor.

Tác nhân là Ai của hệ thống, nói cách khác anh ta là người dùng cuối.

Trong kỹ thuật phần mềm và hệ thống, ca sử dụng là danh sách các bước, thường xác định các tương tác giữa một vai trò (trong UML được gọi là "tác nhân") và hệ thống, để đạt được mục tiêu. Tác nhân có thể là một con người hoặc một hệ thống bên ngoài.

Một ca sử dụng chỉ định luồng sự kiện trong hệ thống. Nó quan tâm nhiều hơn đến những gì được thực hiện bởi hệ thống để thực hiện chuỗi các hành động.

Lợi ích của Ca sử dụng

Trường hợp sử dụng cung cấp các lợi ích sau:

• Nó là một phương tiện dễ dàng để nắm bắt yêu cầu chức năng với trọng tâm là giá trị gia tăng cho người dùng.

• Các ca sử dụng tương đối dễ viết và dễ đọc so với các phương pháp yêu cầu truyền thống.

• Các ca sử dụng buộc các nhà phát triển phải suy nghĩ từ góc độ người dùng cuối.

• Ca sử dụng thu hút người dùng vào quy trình yêu cầu.

Giải phẫu của một ca sử dụng

Tên : Tên mô tả minh họa mục đích của ca sử dụng.

Mô tả : Mô tả những gì use-case thực hiện trong một vài câu.

Tác nhân : Liệt kê bất kỳ tác nhân nào tham gia vào ca sử dụng.

Pre-condition : Các điều kiện phải được đáp ứng trước khi bắt đầu use-case.

Luồng sự kiện : Mô tả sự tương tác giữa hệ thống và tác nhân.

Điều kiện đăng : Mô tả trạng thái của hệ thống sau khi một ca sử dụng đã chạy quá trình của nó.

Hướng dẫn về Mẫu Use-Case

Ghi lại từng trường hợp sử dụng bằng cách sử dụng mẫu được đưa ra ở cuối chương này. Phần này cung cấp mô tả về từng phần trong mẫu ca sử dụng.

Nhận dạng ca sử dụng

• Use-Case ID- Cung cấp cho mỗi ca sử dụng một định danh số duy nhất, ở dạng phân cấp: XY Các ca sử dụng liên quan có thể được nhóm lại trong hệ thống phân cấp. Các yêu cầu chức năng có thể được truy ngược trở lại một ca sử dụng được dán nhãn.

• Use-Case Name- Nêu một tên ngắn gọn, hướng đến kết quả cho ca sử dụng. Những điều này phản ánh các nhiệm vụ mà người dùng cần để có thể hoàn thành bằng cách sử dụng hệ thống. Bao gồm một động từ hành động và một danh từ. Một số ví dụ -

  • Xem thông tin số bộ phận.

  • Đánh dấu nguồn siêu văn bản theo cách thủ công và thiết lập liên kết tới đích.

  • Đặt hàng đĩa CD có phiên bản phần mềm cập nhật.

Lịch sử ca sử dụng

Ở đây, chúng tôi đề cập đến tên của những người là bên liên quan của tài liệu Usecase.

• Created By - Cung cấp tên của người ban đầu ghi lại usecase này.

• Date Created - Nhập ngày ghi ban đầu ca sử dụng.

• Last Updated By - Cung cấp tên của người đã thực hiện cập nhật gần đây nhất cho mô tả ca sử dụng.

• Date Last Updated - Nhập ngày mà ca sử dụng được cập nhật gần đây nhất.

Định nghĩa ca sử dụng

Sau đây là các định nghĩa về các khái niệm chính của Use-Case -

Diễn viên

Tác nhân là một người hoặc thực thể khác bên ngoài hệ thống phần mềm được chỉ định, người tương tác với hệ thống và thực hiện các ca sử dụng để hoàn thành nhiệm vụ. Các tác nhân khác nhau thường tương ứng với các lớp người dùng hoặc vai trò khác nhau, được xác định từ cộng đồng khách hàng sẽ sử dụng sản phẩm. Đặt tên cho (các) diễn viên sẽ thực hiện usecase này.

Sự miêu tả

Cung cấp mô tả ngắn gọn về lý do và kết quả của ca sử dụng này hoặc mô tả cấp cao về chuỗi hành động và kết quả của việc thực hiện ca sử dụng.

Điều kiện tiên quyết

Liệt kê bất kỳ hoạt động nào phải diễn ra hoặc bất kỳ điều kiện nào phải đúng, trước khi ca sử dụng có thể được bắt đầu. Đánh số từng điều kiện tiên quyết.

Examples

• Danh tính của người dùng đã được xác thực.
• Máy tính của người dùng có đủ bộ nhớ trống để khởi chạy tác vụ.

Điều kiện đăng bài

Mô tả trạng thái của hệ thống khi kết thúc thực thi ca sử dụng. Đánh số điều kiện từng bài.

Examples

• Tài liệu chỉ chứa các thẻ SGML hợp lệ.
• Giá của mặt hàng trong cơ sở dữ liệu đã được cập nhật với giá trị mới.

Sự ưu tiên

Cho biết mức độ ưu tiên tương đối của việc triển khai chức năng cần thiết để cho phép thực thi usecase này. Sơ đồ ưu tiên được sử dụng phải giống với sơ đồ được sử dụng trong đặc tả yêu cầu phần mềm.

Tần suất sử dụng

Ước tính số lần ca sử dụng này sẽ được các tác nhân thực hiện trên một số đơn vị thời gian thích hợp.

Diễn biến sự kiện bình thường

Cung cấp mô tả chi tiết về các hành động của người dùng và phản hồi của hệ thống sẽ diễn ra trong quá trình thực hiện ca sử dụng trong điều kiện bình thường, dự kiến. Chuỗi hội thoại này cuối cùng sẽ dẫn đến việc hoàn thành mục tiêu được nêu trong tên và mô tả ca sử dụng. Mô tả này có thể được viết như một câu trả lời cho câu hỏi giả định, "Làm thế nào để tôi <hoàn thành nhiệm vụ được nêu trong tên ca sử dụng>?" Điều này được thực hiện tốt nhất dưới dạng danh sách đánh số các hành động do tác nhân thực hiện, xen kẽ với các phản hồi do hệ thống cung cấp.

Các khóa học thay thế

Ghi lại các tình huống sử dụng hợp pháp, khác có thể diễn ra trong trường hợp sử dụng này một cách riêng biệt trong phần này. Nêu quy trình thay thế và mô tả bất kỳ sự khác biệt nào trong trình tự các bước diễn ra. Đánh số mỗi khóa học thay thế bằng cách sử dụng ID ca sử dụng làm tiền tố, theo sau là “AC” để biểu thị “Khóa học thay thế”. Ví dụ: XYAC.1.

Ngoại lệ

Mô tả bất kỳ điều kiện lỗi dự đoán nào có thể xảy ra trong quá trình thực thi usecase và xác định cách hệ thống đáp ứng với các điều kiện đó. Ngoài ra, mô tả cách hệ thống phản hồi nếu việc thực thi ca sử dụng không thành công vì một số lý do không lường trước được. Đánh số từng ngoại lệ bằng cách sử dụng Use-case ID làm tiền tố, theo sau là “EX” để chỉ ra “Exception”. Ví dụ: XYEX.1.

Bao gồm

Liệt kê bất kỳ trường hợp sử dụng nào khác được bao gồm (“được gọi”) bởi trường hợp sử dụng này. Chức năng chung xuất hiện trong nhiều trường hợp sử dụng có thể được chia thành một trường hợp sử dụng riêng biệt được bao gồm bởi những chức năng cần chức năng chung đó.

Yêu cầu đặc biệt

Xác định bất kỳ yêu cầu bổ sung nào, chẳng hạn như các yêu cầu phi chức năng, đối với usecase có thể cần được giải quyết trong quá trình thiết kế hoặc thực hiện. Chúng có thể bao gồm các yêu cầu về hiệu suất hoặc các thuộc tính chất lượng khác.

Giả định

Liệt kê bất kỳ giả định nào được đưa ra trong phân tích dẫn đến việc chấp nhận trường hợp sử dụng này vào mô tả sản phẩm và viết mô tả trường hợp sử dụng.

Ghi chú và Vấn đề

Liệt kê bất kỳ nhận xét bổ sung nào về ca sử dụng này hoặc bất kỳ vấn đề còn mở nào hoặc TBD (Cần Xác định) cần được giải quyết. Xác định ai sẽ giải quyết từng vấn đề, ngày đến hạn và giải pháp cuối cùng là gì.

Quản lý thay đổi và kiểm soát phiên bản

Kiểm soát phiên bản là quản lý các thay đổi đối với tài liệu, trang web lớn và các bộ sưu tập thông tin khác. Các thay đổi thường được xác định bằng mã số hoặc mã chữ cái, được gọi là số sửa đổi hoặc cấp sửa đổi. Mỗi bản sửa đổi được liên kết với một dấu thời gian và người thực hiện thay đổi.

Sơ đồ ca sử dụng

Một phần quan trọng của Ngôn ngữ tạo mô hình hợp nhất (UML) là các phương tiện để vẽ biểu đồ usecase. Các ca sử dụng được sử dụng trong giai đoạn phân tích của một dự án để xác định và phân vùng chức năng hệ thống. Chúng tách hệ thống thành các tác nhân và các ca sử dụng. Các tác nhân đại diện cho các vai trò có thể được thực hiện bởi những người sử dụng hệ thống.

Những người dùng đó có thể là con người, máy tính khác, phần cứng hoặc thậm chí hệ thống phần mềm khác. Tiêu chí duy nhất là chúng phải nằm ngoài phần của hệ thống được phân chia thành các ca sử dụng. Họ phải cung cấp các kích thích cho phần đó của hệ thống, và phải nhận các đầu ra từ nó.

Ca sử dụng đại diện cho các hoạt động mà các tác nhân thực hiện với sự trợ giúp của hệ thống của bạn để theo đuổi mục tiêu. Chúng ta cần xác định những người dùng (tác nhân) đó cần gì từ hệ thống. Ca sử dụng phải phản ánh nhu cầu và mục tiêu của người dùng và phải do một tác nhân khởi xướng. Doanh nghiệp, các tác nhân, Khách hàng tham gia ca sử dụng kinh doanh phải được kết nối với ca sử dụng theo hiệp hội.

Vẽ biểu đồ ca sử dụng

Hình bên dưới cho thấy một ca sử dụng có thể trông giống như dạng giản đồ UML. Bản thân usecase trông giống như một hình bầu dục. Các diễn viên được vẽ như những con số nhỏ. Các tác nhân được kết nối với use-case bằng các dòng.

Use-case 1 - Nhân viên bán hàng kiểm tra một mặt hàng

• Khách hàng đặt hàng trên quầy.
• «Sử dụng» Vuốt UPC Reader.
• Hệ thống tra cứu mã UPC trong cơ sở dữ liệu mô tả mặt hàng và giá mua sắm
• Hệ thống phát ra tiếng bíp.
• Hệ thống thông báo mô tả mặt hàng và giá cả qua đầu ra bằng giọng nói.
• Hệ thống thêm giá và loại mặt hàng vào hóa đơn hiện tại.
• Hệ thống thêm giá để sửa tổng phụ thuế

Vì vậy, mối quan hệ «using» rất giống một lệnh gọi hàm hoặc một chương trình con.

Ca sử dụng đang được sử dụng theo kiểu này được gọi là ca sử dụng trừu tượng vì nó không thể tự tồn tại mà phải được sử dụng bởi các ca sử dụng khác.

Ví dụ ─ Trường hợp sử dụng rút tiền

Mục tiêu của khách hàng liên quan đến máy bán tiền tự động (ATM) của chúng tôi là rút tiền. Vì vậy, chúng tôi đang thêmWithdrawalca sử dụng. Rút tiền từ máy bán hàng tự động có thể liên quan đến ngân hàng để thực hiện các giao dịch. Vì vậy, chúng tôi cũng đang thêm một diễn viên khác -Bank. Cả hai tác nhân tham gia ca sử dụng phải được kết nối với ca sử dụng theo liên kết.

Máy bán tiền tự động cung cấp trường hợp sử dụng Rút tiền cho khách hàng và các nhân viên Ngân hàng.

Mối quan hệ giữa Tác nhân và Ca sử dụng

Các ca sử dụng có thể được tổ chức bằng cách sử dụng các mối quan hệ sau:

• Generalization
• Association
• Extend
• Include

Tổng quát hóa giữa các ca sử dụng

Có thể có các trường hợp mà các tác nhân được liên kết với các trường hợp sử dụng tương tự. Trong trường hợp đó, một ca sử dụng Con kế thừa các thuộc tính và hành vi của sử dụng mẹ. Do đó chúng ta cần tổng quát tác nhân để chỉ ra sự kế thừa của các chức năng. Chúng được thể hiện bằng một đường liền nét với đầu mũi tên hình tam giác rỗng lớn.

Liên kết giữa các trường hợp sử dụng

Mối liên kết giữa các tác nhân và các ca sử dụng được biểu thị trong biểu đồ ca sử dụng bằng các đường liền nét. Một liên kết tồn tại bất cứ khi nào một tác nhân tham gia vào một tương tác được mô tả bởi ca sử dụng.

Mở rộng

Có một số chức năng được kích hoạt tùy chọn. Trong những trường hợp như vậy, mối quan hệ mở rộng được sử dụng và quy tắc mở rộng được đính kèm với nó. Điều cần nhớ là use-case cơ sở phải có thể tự thực hiện một chức năng ngay cả khi usecase mở rộng không được gọi.

Mối quan hệ mở rộng được hiển thị dưới dạng một đường đứt nét với đầu mũi tên mở hướng từ trường hợp sử dụng mở rộng đến trường hợp sử dụng mở rộng (cơ sở). Mũi tên được gắn nhãn với từ khóa «mở rộng».

Bao gồm

Nó được sử dụng để trích xuất các đoạn use-case được sao chép trong nhiều use-case. Nó cũng được sử dụng để đơn giản hóa use-case lớn bằng cách chia nó thành nhiều use-case và trích xuất các phần chung của các hành vi của hai hoặc nhiều use-case.

Bao gồm mối quan hệ giữa các ca sử dụng được hiển thị bằng mũi tên đứt nét với đầu mũi tên mở từ ca sử dụng cơ sở đến ca sử dụng được bao gồm. Mũi tên được gắn nhãn với từ khóa «bao gồm».

Các ca sử dụng chỉ giải quyết các yêu cầu chức năng cho một hệ thống. Các yêu cầu khác như quy tắc kinh doanh, yêu cầu chất lượng dịch vụ và các ràng buộc thực hiện phải được trình bày riêng biệt.

Sơ đồ dưới đây là một ví dụ về một sơ đồ ca sử dụng đơn giản với tất cả các phần tử được đánh dấu.

Nguyên tắc cơ bản để áp dụng thành công ca sử dụng

• Hãy đơn giản bằng cách kể chuyện
• Làm việc hiệu quả mà không cần sự hoàn hảo
• Hiểu bức tranh lớn
• Xác định cơ hội sử dụng lại cho các ca sử dụng
• Tập trung vào giá trị
• Xây dựng hệ thống theo từng lát
• Cung cấp hệ thống theo từng bước
• Thích ứng để đáp ứng nhu cầu của nhóm

Mẫu Use-Case

Ở đây, chúng tôi đã hiển thị một mẫu ví dụ về Use-Case mà Nhà phân tích kinh doanh có thể điền để thông tin có thể hữu ích cho nhóm kỹ thuật để xác định thông tin về dự án.

ID ca sử dụng:
Tên ca sử dụng:
Được tạo bởi:		Cập nhật lần cuối bởi
Ngày tạo:		Ngày cập nhật lần cuối
Diễn viên:
Sự miêu tả:
Điều kiện tiên quyết:
Điều kiện đăng bài:
Sự ưu tiên:
Tần suất sử dụng:
Quá trình bình thường của sự kiện:
Các khóa học thay thế:
Các trường hợp ngoại lệ:
Bao gồm:
Yêu cầu đặc biệt:
Các giả định:
Ghi chú và Vấn đề:

Phân tích kinh doanh - Yêu cầu Mngmt

Thu thập các yêu cầu phần mềm là nền tảng của toàn bộ dự án phát triển phần mềm. Thu thập và thu thập các yêu cầu kinh doanh là bước đầu tiên quan trọng cho mọi dự án. Để thu hẹp khoảng cách giữa các yêu cầu kinh doanh và kỹ thuật, các nhà phân tích kinh doanh phải hiểu đầy đủ các nhu cầu kinh doanh trong bối cảnh nhất định, điều chỉnh các nhu cầu này với các mục tiêu kinh doanh và truyền đạt đúng nhu cầu cho cả các bên liên quan và nhóm phát triển.

Các bên liên quan chính mong muốn ai đó có thể giải thích các yêu cầu của khách hàng / khách hàng bằng tiếng Anh đơn giản. Điều này có mang lại lợi ích cho họ khi hiểu giá trị ở cấp độ cao không? Đây sẽ là lĩnh vực trọng tâm chính, vì họ sẽ cố gắng lập bản đồ tài liệu với các yêu cầu và cách BA có thể giao tiếp theo cách tốt nhất có thể.

Tại sao dự án thất bại

Có nhiều lý do tại sao các dự án thất bại nhưng một số lĩnh vực phổ biến bao gồm:

• Thị trường và Chiến lược thất bại
• Tổ chức và lập kế hoạch thất bại
• Chất lượng không đạt
• Thất bại trong lãnh đạo và quản trị
• Kỹ năng, kiến ​​thức và thất bại về năng lực
• Tương tác, làm việc nhóm và thất bại trong giao tiếp

Cốt lõi của vấn đề là các dự án ngày càng phức tạp, thay đổi xảy ra và giao tiếp là thách thức.

Tại sao các nhóm thành công thực hiện Quản lý yêu cầu

Quản lý yêu cầu là giữ cho nhóm của bạn in-sync và cung cấp visibility về những gì đang diễn ra trong một dự án.

Điều quan trọng đối với sự thành công của các dự án của bạn là toàn bộ nhóm của bạn phải hiểu những gì bạn đang xây dựng và lý do - đó là cách chúng tôi xác định quản lý yêu cầu. “Tại sao” rất quan trọng vì nó cung cấp bối cảnh cho các mục tiêu, phản hồi và quyết định được đưa ra về các yêu cầu.

Điều này làm tăng khả năng dự đoán về thành công trong tương lai và các vấn đề tiềm ẩn, cho phép nhóm của bạn nhanh chóng khắc phục mọi vấn đề và hoàn thành thành công dự án của bạn đúng thời hạn và trong phạm vi ngân sách. Như một điểm khởi đầu, điều có giá trị đối với tất cả những người tham gia là có hiểu biết cơ bản về các yêu cầu là gì và cách quản lý chúng.

Hãy bắt đầu với những điều cơ bản

Yêu cầu là một điều kiện hoặc khả năng cần thiết của một bên liên quan để giải quyết một vấn đề hoặc đạt được một mục tiêu. Một điều kiện hoặc khả năng phải được đáp ứng hoặc sở hữu bởi một hệ thống hoặc hệ thống. Thành phần để đáp ứng hợp đồng, tiêu chuẩn, đặc điểm kỹ thuật hoặc các tài liệu được áp đặt chính thức khác.

Một yêu cầu có thể được thể hiện bằng văn bản, bản phác thảo, mô hình hoặc mô hình chi tiết, bất kỳ thông tin nào truyền đạt tốt nhất cho kỹ sư những gì cần xây dựng và cho người quản lý QA những gì cần kiểm tra. Tùy thuộc vào quá trình phát triển của bạn, bạn có thể sử dụng các thuật ngữ khác nhau để nắm bắt các yêu cầu.

Yêu cầu cấp cao đôi khi được gọi đơn giản là needs hoặc là goals. Trong thực tiễn phát triển phần mềm, các yêu cầu có thể được gọi là “ca sử dụng”, “tính năng” hoặc “yêu cầu chức năng”. Đặc biệt hơn nữa trong các phương pháp luận phát triển nhanh, các yêu cầu thường được nắm bắt nhưepics và stories.

Bất kể nhóm của bạn gọi họ là gì hoặc bạn sử dụng quy trình nào; yêu cầu cần thiết cho sự phát triển của tất cả các sản phẩm. Nếu không xác định rõ các yêu cầu, bạn có thể tạo ra một sản phẩm không hoàn chỉnh hoặc bị lỗi. Trong suốt quá trình, có thể có nhiều người tham gia vào việc xác định các yêu cầu.

Một bên liên quan có thể yêu cầu một tính năng mô tả cách sản phẩm sẽ cung cấp giá trị trong việc giải quyết một vấn đề. Một nhà thiết kế có thể xác định một yêu cầu dựa trên cách sản phẩm cuối cùng trông hoặc hoạt động như thế nào từ quan điểm về khả năng sử dụng hoặc giao diện người dùng.

Một nhà phân tích kinh doanh có thể tạo ra một yêu cầu hệ thống tuân theo các ràng buộc kỹ thuật hoặc tổ chức cụ thể. Đối với các sản phẩm và ứng dụng phần mềm phức tạp ngày nay đang được xây dựng, thường cần hàng trăm hoặc hàng nghìn yêu cầu để xác định đủ phạm vi của một dự án hoặc một bản phát hành. Do đó, nhóm bắt buộc phải có khả năng truy cập, cộng tác, cập nhật và kiểm tra từng yêu cầu cho đến khi hoàn thành, vì các yêu cầu tự nhiên thay đổi và phát triển theo thời gian trong quá trình phát triển.

Bây giờ chúng ta đã xác định được giá trị của việc quản lý yêu cầu ở cấp cao, hãy đi sâu hơn vào bốn nguyên tắc cơ bản mà mọi thành viên trong nhóm và các bên liên quan có thể hưởng lợi từ sự hiểu biết -

• Lập kế hoạch yêu cầu tốt: "Chúng ta đang xây dựng cái quái gì vậy?"
• Hợp tác và mua vào: “Chỉ cần phê duyệt thông số kỹ thuật!”
• Truy xuất nguồn gốc và quản lý thay đổi: “Chờ đã, các nhà phát triển có biết điều đó đã thay đổi không?”
• Đảm bảo chất lượng: "Xin chào, có ai thử nghiệm điều này không?"

Mọi người có biết những gì chúng tôi đang xây dựng và tại sao không? Đó là giá trị của quản lý yêu cầu.

Hợp tác và Mua hàng từ các bên liên quan

Có phải tất cả mọi người trong vòng lặp? Chúng tôi có chấp thuận về các yêu cầu để tiếp tục không? Những câu hỏi này xuất hiện trong các chu kỳ phát triển. Sẽ thật tuyệt nếu mọi người có thể đồng ý về các yêu cầu, nhưng đối với các dự án lớn với nhiều bên liên quan, điều này thường không xảy ra. Cố gắng để mọi người đồng ý có thể khiến các quyết định bị trì hoãn, hoặc tệ hơn là không thực hiện được. Đạt được sự đồng thuận trong mọi quyết định không phải lúc nào cũng dễ dàng.

Trên thực tế, bạn không nhất thiết phải muốn có “sự đồng thuận”, mà bạn muốn “mua vào” từ nhóm và sự chấp thuận từ những người kiểm soát để bạn có thể tiến hành dự án. Với sự đồng thuận, bạn đang cố gắng để mọi người thỏa hiệp và đồng ý về quyết định. Với mua vào, bạn đang cố gắng kêu gọi mọi người ủng hộ giải pháp tốt nhất, đưa ra quyết định thông minh và làm những gì cần thiết để tiến về phía trước.

Bạn không cần mọi người đồng ý rằng quyết định đó là tốt nhất. Bạn cần mọi người ủng hộ quyết định. Hợp tác nhóm có thể giúp nhận được sự hỗ trợ về các quyết định và lập kế hoạch các yêu cầu tốt.

Các nhóm cộng tác làm việc chăm chỉ để đảm bảo mọi người đều có cổ phần trong các dự án và cung cấp phản hồi. Các nhóm cộng tác liên tục chia sẻ ý tưởng, thường có giao tiếp tốt hơn và có xu hướng ủng hộ các quyết định được đưa ra vì có chung cảm giác cam kết và hiểu biết về các mục tiêu của dự án.

Đó là khi các nhà phát triển, người kiểm tra hoặc các bên liên quan khác cảm thấy “lạc lõng” thì các vấn đề giao tiếp phát sinh, mọi người cảm thấy thất vọng và các dự án bị trì hoãn. Một khi mọi người đã tham gia vào phạm vi công việc, thì bắt buộc các yêu cầu phải rõ ràng và được ghi chép đầy đủ. Theo dõi tất cả các yêu cầu là nơi mọi thứ trở nên phức tạp.

Hãy tưởng tượng có một danh sách việc cần làm dài hàng dặm bao gồm việc cộng tác với nhiều người để hoàn thành. Làm thế nào bạn sẽ giữ cho tất cả các mục đó thẳng hàng? Bạn sẽ theo dõi cách một thay đổi đối với một mục sẽ ảnh hưởng đến phần còn lại của dự án như thế nào? Đây là nơi mà việc truy xuất nguồn gốc và quản lý thay đổi gia tăng giá trị.

Lập kế hoạch Yêu cầu Tốt

Vậy, điều gì tạo nên một yêu cầu tốt? Một yêu cầu tốt phải có giá trị và có thể hành động được; nó phải xác định nhu cầu cũng như cung cấp một con đường dẫn đến một giải pháp. Mọi người trong đội nên hiểu ý nghĩa của nó. Các yêu cầu khác nhau về mức độ phức tạp.

• Một Tài liệu Yêu cầu tốt có thể là một phần của một nhóm với các yêu cầu cấp cao được chia thành các yêu cầu phụ.

• Chúng cũng có thể bao gồm các thông số kỹ thuật rất chi tiết bao gồm một tập hợp các yêu cầu chức năng mô tả hành vi hoặc các thành phần của sản phẩm cuối.

• Yêu cầu tốt cần ngắn gọn và cụ thể, đồng thời phải trả lời được câu hỏi “chúng ta cần gì?” Thay vào đó, "làm cách nào để đáp ứng nhu cầu?"

• Các yêu cầu tốt đảm bảo rằng tất cả các bên liên quan hiểu rõ phần kế hoạch của họ; nếu các bộ phận không rõ ràng hoặc bị hiểu sai, sản phẩm cuối cùng có thể bị lỗi hoặc hỏng.

Có thể hỗ trợ ngăn ngừa thất bại hoặc hiểu sai các yêu cầu bằng cách nhận phản hồi từ nhóm liên tục trong suốt quá trình khi các yêu cầu phát triển. Cộng tác liên tục và tham gia với mọi người là chìa khóa thành công.

Thu thập và phân tích yêu cầu

Yêu cầu là một điều kiện hoặc khả năng cần thiết của một bên liên quan để giải quyết một vấn đề hoặc đạt được một mục tiêu của tổ chức; một điều kiện hoặc khả năng mà một hệ thống phải đáp ứng hoặc sở hữu.

Phân tích yêu cầu trong kỹ thuật phần mềm bao gồm những nhiệm vụ đi vào việc xác định nhu cầu hoặc điều kiện để đáp ứng cho một sản phẩm mới hoặc đã thay đổi có tính đến các yêu cầu xung đột có thể có của các bên liên quan khác nhau, phân tích, lập tài liệu, xác nhận và quản lý các yêu cầu phần mềm hoặc hệ thống.

Các yêu cầu phải là -

• Documented
• Actionable
• Measurable
• Testable
• Traceable

Các yêu cầu phải liên quan đến nhu cầu hoặc cơ hội kinh doanh đã xác định và được xác định ở mức độ chi tiết đủ để thiết kế hệ thống.

Một nhà phân tích Kinh doanh thu thập thông tin thông qua việc quan sát các hệ thống hiện có, nghiên cứu các quy trình hiện có, thảo luận với khách hàng và người dùng cuối. Nhà phân tích cũng phải có kỹ năng tưởng tượng và sáng tạo nếu không có Hệ thống hoạt động. Phân tích yêu cầu đã tập hợp để tìm ra các liên kết còn thiếu là phân tích yêu cầu.

Khuyến khích phương pháp tiếp cận

Để gợi ra các mục tiêu, hãy hỏi chuyên gia kinh doanh, giám đốc phát triển và nhà tài trợ dự án những câu hỏi sau:

• Dự án này sẽ giúp đạt được những mục tiêu kinh doanh nào của công ty?

• Tại sao chúng tôi thực hiện dự án này bây giờ?

• Điều gì sẽ xảy ra nếu chúng ta làm điều đó sau này?

• Điều gì sẽ xảy ra nếu chúng ta không làm điều đó?

• Ai sẽ được hưởng lợi từ dự án này?

• Những người sẽ được hưởng lợi từ nó có coi đây là cải tiến quan trọng nhất có thể được thực hiện vào lúc này không?

• Thay vào đó, chúng ta có nên thực hiện một dự án khác không?

Các mục tiêu khả thi có thể là giảm chi phí, cải thiện dịch vụ khách hàng, đơn giản hóa quy trình làm việc, thay thế công nghệ lỗi thời, thử nghiệm một công nghệ mới và nhiều công nghệ khác. Ngoài ra, hãy đảm bảo rằng bạn hiểu chính xác cách dự án được đề xuất sẽ giúp hoàn thành mục tiêu đã nêu.

Các loại yêu cầu khác nhau

Các loại yêu cầu phổ biến nhất mà Nhà phân tích kinh doanh quan tâm sẽ là:

Yêu cầu kinh doanh

Yêu cầu kinh doanh là các hoạt động quan trọng của một doanh nghiệp phải được thực hiện để đáp ứng các mục tiêu của tổ chức trong khi vẫn giữ được giải pháp độc lập. Tài liệu yêu cầu kinh doanh (BRD) nêu chi tiết giải pháp kinh doanh cho một dự án bao gồm tài liệu về nhu cầu và mong đợi của khách hàng.

Yêu cầu người sử dụng

Yêu cầu của người dùng nên chỉ rõ các yêu cầu cụ thể mà người dùng mong đợi / muốn từ phần mềm được xây dựng từ dự án phần mềm. Yêu cầu của người dùng phải có thể xác minh, rõ ràng và ngắn gọn, hoàn chỉnh, nhất quán, có thể theo dõi, khả thi.

Tài liệu yêu cầu người dùng (URD) ​​hoặc đặc tả yêu cầu người dùng là một tài liệu thường được sử dụng trong kỹ thuật phần mềm chỉ định những gì người dùng mong đợi phần mềm có thể thực hiện.

yêu cầu hệ thống

Yêu cầu hệ thống liên quan đến việc xác định các yêu cầu tài nguyên phần mềm và các điều kiện tiên quyết cần được cài đặt trên máy tính để cung cấp chức năng tối ưu của ứng dụng.

Yêu cầu chức năng

Các yêu cầu chức năng nắm bắt và xác định hành vi dự kiến ​​cụ thể của hệ thống đang được phát triển. Chúng xác định những thứ như tính toán hệ thống, thao tác và xử lý dữ liệu, giao diện người dùng và tương tác với ứng dụng cũng như các chức năng cụ thể khác cho thấy yêu cầu của người dùng được thỏa mãn như thế nào. Chỉ định một số ID duy nhất cho mỗi yêu cầu.

Những yêu cầu phi lý

Yêu cầu phi chức năng là yêu cầu xác định các tiêu chí có thể được sử dụng để đánh giá hoạt động của một hệ thống hơn là các hành vi cụ thể. Kiến trúc hệ thống nói lên kế hoạch thực hiện các yêu cầu phi chức năng.

Các yêu cầu phi chức năng nói lên cách hệ thống phải như thế nào hoặc nó có thể được đề cập như "hệ thống sẽ như thế nào". Các yêu cầu phi chức năng được gọi là phẩm chất của hệ thống.

Yêu cầu chuyển đổi

Yêu cầu Chuyển đổi mô tả các khả năng mà giải pháp phải đáp ứng để tạo điều kiện chuyển đổi từ trạng thái hiện tại của doanh nghiệp sang trạng thái mong muốn trong tương lai, nhưng điều đó sẽ không cần thiết khi quá trình chuyển đổi đó hoàn tất.

Chúng được phân biệt với các loại yêu cầu khác, vì chúng luôn có bản chất tạm thời và vì chúng không thể được phát triển cho đến khi cả giải pháp hiện tại và giải pháp mới được xác định. Chúng thường bao gồm việc chuyển đổi dữ liệu từ các hệ thống hiện có, các lỗ hổng kỹ năng cần được giải quyết và các thay đổi liên quan khác để đạt được trạng thái mong muốn trong tương lai. Chúng được phát triển và xác định thông qua đánh giá và xác nhận giải pháp.

Quản lý truy xuất nguồn gốc và thay đổi

Truy xuất nguồn gốc yêu cầu là một cách để tổ chức, lập tài liệu và theo dõi tất cả các yêu cầu của bạn từ khi hình thành ý tưởng ban đầu cho đến giai đoạn thử nghiệm.

Ma trận khả năng theo dõi các yêu cầu (RTM) cung cấp một phương pháp để theo dõi các yêu cầu chức năng và việc thực hiện chúng thông qua quá trình phát triển. Mỗi yêu cầu được đưa vào ma trận cùng với số phần liên quan của nó.

Khi dự án tiến triển, RIM được cập nhật để phản ánh trạng thái của từng yêu cầu. Khi sản phẩm đã sẵn sàng để kiểm tra hệ thống, ma trận liệt kê từng yêu cầu, thành phần sản phẩm giải quyết nó và kiểm tra nào xác minh rằng nó được thực hiện đúng

Bao gồm các cột cho từng điều sau đây trong RTM -

• Mô tả yêu cầu
• Tham chiếu yêu cầu trong FRD
• Phương thức xác minh
• Tham chiếu yêu cầu trong Kế hoạch thử nghiệm

Example- Kết nối các dấu chấm để xác định mối quan hệ giữa các hạng mục trong dự án của bạn. Nó là một đầu nối của dòng chảy hạ lưu chung.

Yêu cầu ý tưởng Thiết kế thử nghiệm Mục tiêu kinh doanh

Bạn sẽ có thể theo dõi từng yêu cầu của mình trở lại mục tiêu kinh doanh ban đầu của nó.

Bằng cách theo dõi các yêu cầu, bạn có thể xác định những thay đổi của hiệu ứng gợn sóng, xem liệu một yêu cầu đã được hoàn thành chưa và liệu nó có đang được kiểm tra đúng cách hay không. Khả năng truy xuất nguồn gốc và quản lý thay đổi cung cấp cho các nhà quản lý sự an tâm và khả năng hiển thị cần thiết để dự đoán các vấn đề và đảm bảo chất lượng liên tục.

Đảm bảo chất lượng

Việc đáp ứng các yêu cầu ngay lần đầu tiên có thể có nghĩa là chất lượng tốt hơn, chu kỳ phát triển nhanh hơn và sự hài lòng của khách hàng cao hơn đối với sản phẩm. Quản lý yêu cầu không chỉ giúp bạn thực hiện đúng mà còn giúp nhóm của bạn tiết kiệm tiền và nhiều vấn đề đau đầu trong suốt quá trình phát triển.

Các yêu cầu cụ thể, ngắn gọn có thể giúp bạn phát hiện và khắc phục sự cố sớm, thay vì để muộn hơn khi sửa chữa tốn kém hơn nhiều. Ngoài ra, nó có thể có giá lên đến100 times nhiều hơn để sửa chữa một khiếm khuyết sau này trong quá trình phát triển sau khi nó được mã hóa, hơn là sửa sớm khi có yêu cầu.

Bằng cách tích hợp quản lý yêu cầu vào quy trình đảm bảo chất lượng, bạn có thể giúp nhóm của mình tăng hiệu quả và loại bỏ công việc làm lại. Hơn nữa, làm lại là nơi mà hầu hết các vấn đề chi phí xảy ra.

Nói cách khác, các nhóm phát triển đang lãng phí phần lớn ngân sách của họ cho những nỗ lực không được thực hiện chính xác trong lần đầu tiên. Ví dụ: một nhà phát triển mã hóa một tính năng dựa trên một tài liệu đặc tả cũ, chỉ để tìm hiểu sau, rằng các yêu cầu cho tính năng đó đã thay đổi. Các loại vấn đề này có thể tránh được bằng các phương pháp hay nhất về quản lý yêu cầu hiệu quả.

Tóm lại, quản lý yêu cầu nghe có vẻ giống một kỷ luật phức tạp, nhưng khi bạn rút ngắn nó thành một khái niệm đơn giản - đó là việc giúp các nhóm trả lời câu hỏi, "Mọi người có hiểu những gì chúng tôi đang xây dựng và tại sao không?" Từ các nhà phân tích kinh doanh, giám đốc sản phẩm và lãnh đạo dự án đến các nhà phát triển, quản lý QA và người kiểm tra, cùng với các bên liên quan và khách hàng liên quan - vì vậy nguyên nhân gốc rễ của sự thất bại của dự án thường là do hiểu sai về phạm vi của dự án.

Khi mọi người đang cộng tác và có đầy đủ bối cảnh và khả năng hiển thị các cuộc thảo luận, quyết định và thay đổi liên quan đến các yêu cầu trong suốt vòng đời của dự án, đó là khi thành công xảy ra một cách nhất quán và bạn duy trì chất lượng liên tục. Ngoài ra, quá trình này diễn ra suôn sẻ hơn với ít xích mích và thất vọng hơn cho tất cả mọi người tham gia.

Note- Nghiên cứu đã chỉ ra rằng các nhóm dự án có thể loại bỏ 50-80% các khiếm khuyết của dự án bằng cách quản lý hiệu quả các yêu cầu. Theo viện kỹ thuật phần mềm Carnegie Mellon, “60-80 phần trăm chi phí phát triển phần mềm là làm lại.”

Đạt yêu cầu Ký hiệu

Các yêu cầu ký kết chính thức hóa sự đồng ý của các bên liên quan trong dự án rằng nội dung và cách trình bày của các yêu cầu, như được lập thành văn bản, là chính xác và đầy đủ. Thỏa thuận chính thức làm giảm rủi ro mà trong hoặc sau khi thực hiện, một bên liên quan sẽ đưa ra một yêu cầu mới (trước đây chưa đạt được).

Việc đạt được các yêu cầu ký kết thường bao gồm việc xem xét trực tiếp lần cuối các yêu cầu, như đã được lập thành văn bản, với từng bên liên quan của dự án. Vào cuối mỗi lần đánh giá, bên liên quan được yêu cầu chính thức phê duyệt tài liệu yêu cầu đã được xem xét. Sự chấp thuận này có thể được ghi lại dưới dạng vật lý hoặc điện tử.

Thu thập các yêu cầu ký kết thường là nhiệm vụ cuối cùng trong Truyền thông Yêu cầu. Nhà phân tích kinh doanh sẽ yêu cầu kết quả đầu ra từ (các) Đánh giá Yêu cầu Chính thức, bao gồm cả việc lưu giữ bất kỳ nhận xét hoặc phản đối nào được nêu ra trong quá trình xem xét.

Phân tích kinh doanh - Mô hình hóa

Mô hình Kinh doanh có thể được định nghĩa là một đại diện của một doanh nghiệp hoặc giải pháp thường bao gồm một thành phần đồ họa cùng với văn bản hỗ trợ và các mối quan hệ với các thành phần khác. Ví dụ, nếu chúng ta phải hiểu mô hình kinh doanh của một công ty, thì chúng ta muốn nghiên cứu những lĩnh vực sau như:

• Giá trị cốt lõi của công ty
• Nó phục vụ những gì?
• Những gì được đặt ngoài?
• Các nguồn lực chính của nó
• Các mối quan hệ chính
• Các kênh phân phối của nó

Với sự trợ giúp của các kỹ thuật mô hình hóa, chúng tôi có thể tạo ra một bản mô tả đầy đủ về cấu trúc tổ chức, quy trình và thông tin hiện có và được đề xuất mà doanh nghiệp sử dụng.

Mô hình Kinh doanh là một mô hình có cấu trúc, giống như một bản thiết kế để phát triển sản phẩm cuối cùng. Nó cung cấp cấu trúc và động lực cho việc lập kế hoạch. Nó cũng cung cấp nền tảng cho sản phẩm cuối cùng.

Mục đích của Mô hình Kinh doanh

Mô hình kinh doanh được sử dụng để thiết kế trạng thái hiện tại và tương lai của một doanh nghiệp. Mô hình này được Nhà phân tích kinh doanh và các bên liên quan sử dụng để đảm bảo rằng họ có hiểu biết chính xác về mô hình “Như hiện tại” của doanh nghiệp.

Nó được sử dụng để xác minh xem, các bên liên quan có hiểu biết chung về “Tính hiện hữu của giải pháp được đề xuất hay không.

Phân tích yêu cầu là một phần của quy trình lập mô hình kinh doanh và nó tạo thành lĩnh vực trọng tâm cốt lõi. Các Yêu cầu Chức năng được thu thập trong "Trạng thái hiện tại". Các yêu cầu này do các bên liên quan cung cấp liên quan đến quy trình kinh doanh, dữ liệu và quy tắc kinh doanh mô tả chức năng mong muốn sẽ được thiết kế ở Trạng thái tương lai.

Thực hiện phân tích GAP

Sau khi xác định nhu cầu kinh doanh, trạng thái hiện tại (ví dụ: quy trình kinh doanh hiện tại, chức năng kinh doanh, tính năng của hệ thống hiện tại và dịch vụ / sản phẩm được cung cấp và các sự kiện mà hệ thống phải đáp ứng) phải được xác định để hiểu cách con người, quy trình và công nghệ, cấu trúc và kiến ​​trúc đang hỗ trợ doanh nghiệp bằng cách tìm kiếm ý kiến ​​đóng góp từ nhân viên CNTT và các bên liên quan khác bao gồm chủ doanh nghiệp.

Sau đó, phân tích khoảng cách được thực hiện để đánh giá, nếu có bất kỳ khoảng cách nào cản trở việc đạt được nhu cầu kinh doanh bằng cách so sánh trạng thái hiện tại đã xác định với các kết quả mong muốn.

Nếu không có khoảng cách (nghĩa là trạng thái hiện tại đủ đáp ứng nhu cầu kinh doanh và kết quả mong muốn), có lẽ sẽ không cần thiết phải khởi động dự án CNTT. Nếu không, các vấn đề / vấn đề cần giải quyết để thu hẹp khoảng cách cần được xác định.

Có thể sử dụng các kỹ thuật như SWOT (Điểm mạnh, Điểm yếu, Cơ hội và Đe doạ) Phân tích và phân tích tài liệu.

Đánh giá hệ thống đề xuất

BA cần hỗ trợ nhóm dự án CNTT trong việc đánh giá hệ thống CNTT được đề xuất để đảm bảo rằng nó đáp ứng các nhu cầu kinh doanh và tối đa hóa các giá trị được cung cấp cho các bên liên quan. BA cũng nên xem xét sự sẵn sàng của tổ chức trong việc hỗ trợ chuyển đổi sang hệ thống CNTT được đề xuất để đảm bảo việc Triển khai Hệ thống diễn ra suôn sẻ.

BA phải giúp nhóm dự án CNTT xác định xem liệu tùy chọn hệ thống được đề xuất và thiết kế hệ thống cấp cao có thể đáp ứng nhu cầu kinh doanh và mang lại đủ giá trị kinh doanh để biện minh cho khoản đầu tư hay không. Nếu có nhiều hơn một tùy chọn hệ thống, BA nên làm việc với nhân viên CNTT để giúp xác định ưu và nhược điểm của từng tùy chọn và chọn tùy chọn mang lại giá trị kinh doanh lớn nhất.

Các Nguyên tắc Hướng dẫn cho Mô hình Kinh doanh

Vai trò chính của mô hình kinh doanh chủ yếu là trong giai đoạn khởi động và giai đoạn hoàn thiện của dự án và nó mất dần trong giai đoạn xây dựng và chuyển đổi. Nó chủ yếu liên quan đến các khía cạnh phân tích của kinh doanh kết hợp với lập bản đồ kỹ thuật của ứng dụng hoặc giải pháp phần mềm.

• Domain and User variation- Việc phát triển một mô hình kinh doanh sẽ thường xuyên bộc lộ những lĩnh vực bất đồng hoặc nhầm lẫn giữa các bên liên quan. Nhà phân tích kinh doanh sẽ cần ghi lại các biến thể sau trong mô hình hiện tại.

• Multiple work units perform the same function- Ghi lại các phương sai trong mô hình AS-IS. Đây có thể là các bộ phận hoặc khu vực địa lý khác nhau.

• Multiples users perform the same work- Các bên liên quan khác nhau có thể làm công việc tương tự theo cách khác nhau. Sự khác biệt có thể là kết quả của các bộ kỹ năng và cách tiếp cận khác nhau của các đơn vị kinh doanh khác nhau hoặc kết quả của các nhu cầu khác nhau của các bên liên quan bên ngoài được doanh nghiệp phục vụ. Ghi lại các phương sai trong mô hình AS-IS.

• Resolution Mechanism- Nhà phân tích kinh doanh nên ghi lại liệu giải pháp ToBe có phù hợp với những mâu thuẫn trong mô hình kinh doanh hiện tại hay không hoặc liệu giải pháp có yêu cầu tiêu chuẩn hóa hay không. Các bên liên quan cần xác định cách tiếp cận nào để tuân theo. Mô hình To-Be sẽ phản ánh quyết định của họ.

Ví dụ về vai trò BA trong Mô hình hóa Hệ thống ERP

Một nhà phân tích kinh doanh phải xác định một quy trình kinh doanh tiêu chuẩn và thiết lập thành một hệ thống ERP có tầm quan trọng chính để triển khai hiệu quả. BA cũng có nhiệm vụ xác định ngôn ngữ của các nhà phát triển bằng ngôn ngữ dễ hiểu trước khi triển khai và sau đó, sử dụng các phương pháp hay nhất và lập bản đồ dựa trên khả năng của hệ thống.

Một yêu cầu đối với hệ thống là phân tích phù hợp GAAP, phải cân bằng giữa -

• Sự cần thiết của những thay đổi kỹ thuật, đó là những cải tiến để đạt được sự đồng nhất với thực tiễn hiện có.

• Các thay đổi hiệu quả, liên quan đến việc tái thiết kế các quy trình kinh doanh hiện có để cho phép thực hiện chức năng tiêu chuẩn và áp dụng các mô hình quy trình.

Nhà phân tích kinh doanh chức năng

Kiến thức chuyên môn về miền thường có được trong một khoảng thời gian bằng cách tham gia vào "công việc kinh doanh" của công việc. Ví dụ,

• A banking associate có được kiến ​​thức về các loại tài khoản khác nhau mà một khách hàng (cá nhân và doanh nghiệp) có thể vận hành cùng với quy trình kinh doanh chi tiết.

• An insurance sales representative có thể hiểu các giai đoạn khác nhau liên quan đến việc mua một hợp đồng Bảo hiểm.

• A marketing analyst có nhiều cơ hội hơn để hiểu các bên liên quan chính và các quy trình kinh doanh liên quan đến hệ thống Quản lý quan hệ khách hàng.

• Một nhà phân tích kinh doanh tham gia vào capital marketsdự án phải có chuyên môn về chủ đề và kiến ​​thức vững chắc về Cổ phiếu, Thu nhập cố định và Phái sinh. Ngoài ra, ông được cho là sẽ xử lý các công việc hậu cần, văn phòng trước, tiếp xúc thực tế trong việc áp dụng các mô hình quản lý rủi ro.

• A Healthcare Business Analyst bắt buộc phải có hiểu biết cơ bản về các chỉ số Sử dụng và Tài chính trong Chăm sóc sức khỏe Hoa Kỳ, Kinh nghiệm kỹ thuật và hiểu biết về EDI 837/835/834, hướng dẫn HIPAA, mã hóa ICD - 9/10 và mã CPT, LOINC, kiến ​​thức SNOMED.

Một số nhà phân tích kinh doanh có được kiến ​​thức miền bằng cách thử nghiệm các ứng dụng kinh doanh và làm việc với người dùng doanh nghiệp. Họ tạo ra một môi trường học tập thuận lợi thông qua các kỹ năng phân tích và giao tiếp giữa các cá nhân. Trong một số trường hợp, họ bổ sung kiến ​​thức miền của mình bằng một số chứng chỉ miền do AICPCU / ​​IIA và LOMA cung cấp trong lĩnh vực Bảo hiểm và dịch vụ tài chính. Có những học viện khác cung cấp chứng chỉ trong các lĩnh vực khác.

Các hoạt động chính khác

Sau khi kiểm tra kỹ lưỡng các quy trình kinh doanh hiện tại, bạn có thể cung cấp hỗ trợ chuyên môn cao trong việc xác định cách tiếp cận tối ưu của mô hình hóa hệ thống.

• Tổ chức việc chuẩn bị một bản mô tả chính thức và thống nhất về các quy trình kinh doanh theo cách thức đảm bảo tự động hóa hiệu quả trong hệ thống.

• Hỗ trợ các nhóm của bạn trong việc điền các bảng câu hỏi tiêu chuẩn cho hệ thống liên quan mà các nhà phát triển có thể cung cấp.

• Việc tham gia vào các cuộc họp làm việc yêu cầu đối với các nhà phát triển được xác định.

• Kiểm tra và kiểm soát xem các yêu cầu do bạn đặt ra có được “tái tạo” đúng cách và được ghi lại trong các tài liệu mô tả mô hình tương lai trong hệ thống (Bản thiết kế) hay không.

• Chuẩn bị dữ liệu và hỗ trợ tạo mẫu hệ thống.

• Hỗ trợ chuẩn bị dữ liệu để di chuyển danh sách và số dư theo định dạng mà hệ thống yêu cầu.

• Xem xét nguyên mẫu thiết lập để tuân thủ các yêu cầu do chủ sở hữu quy trình kinh doanh xác định.

• Đóng vai trò là nguồn hỗ trợ cho nhóm CNTT của bạn trong việc chuẩn bị dữ liệu và hiệu suất thực tế của các bài kiểm tra chức năng và tích hợp trong hệ thống.

Trong phần tiếp theo, chúng ta sẽ thảo luận ngắn gọn về một số Công cụ tạo mô hình kinh doanh phổ biến được các tổ chức lớn sử dụng trong môi trường CNTT.

Công cụ 1: Microsoft Visio

MS-Visio là một phần mềm vẽ và sơ đồ giúp chuyển đổi các khái niệm thành một biểu diễn trực quan. Visio cung cấp cho bạn các hình dạng, biểu tượng, hình nền và đường viền được xác định trước. Chỉ cần kéo và thả các phần tử vào sơ đồ của bạn để tạo một công cụ giao tiếp chuyên nghiệp.

Step 1 - Để mở một bản vẽ Visio mới, hãy chuyển đến Menu Bắt đầu và chọn Chương trình → Visio.

Step 2 - Di chuyển con trỏ của bạn qua “Quy trình nghiệp vụ” và chọn “Lưu đồ cơ bản”.

Ảnh chụp màn hình sau đây cho thấy các phần chính của ứng dụng MS-Visio.

Bây giờ chúng ta hãy thảo luận về tiện ích cơ bản của từng thành phần -

A- các thanh công cụ trên đầu màn hình giống như các chương trình Microsoft khác như Word và PowerPoint. Nếu bạn đã sử dụng các chương trình này trước đây, bạn có thể nhận thấy một vài chức năng khác nhau, chúng ta sẽ khám phá sau.

Chọn Thư viện sơ đồ trợ giúp là một cách tốt để làm quen với các loại bản vẽ và sơ đồ có thể được tạo trong Visio.

B- Phía bên trái của màn hình hiển thị các menu cụ thể cho loại sơ đồ bạn đang tạo. Trong trường hợp này, chúng ta thấy -

• Hình mũi tên
• Backgrounds
• Hình dạng lưu đồ cơ bản
• Biên giới và Tiêu đề

C - Chính giữa màn hình hiển thị không gian làm việc sơ đồ, bao gồm trang sơ đồ thực tế cũng như một số không gian trống bên cạnh trang.

D- Bên phải màn hình hiển thị một số chức năng trợ giúp. Một số người có thể chọn đóng cửa sổ này để tăng diện tích cho không gian làm việc sơ đồ, và mở lại các chức năng trợ giúp khi cần thiết.

Công cụ 2: Kiến trúc sư doanh nghiệp

Kiến trúc sư doanh nghiệp là một công cụ thiết kế và mô hình hóa trực quan dựa trên UML. Nền tảng hỗ trợ thiết kế và xây dựng hệ thống phần mềm, mô hình hóa quy trình kinh doanh và mô hình hóa các lĩnh vực dựa trên ngành. Nó được sử dụng bởi các doanh nghiệp và tổ chức không chỉ để mô hình hóa kiến ​​trúc của hệ thống của họ. Nhưng để xử lý việc triển khai các mô hình này trong toàn bộ vòng đời phát triển ứng dụng.

Mục đích của kiến ​​trúc sư doanh nghiệp là xác định cách một tổ chức có thể đạt được các mục tiêu hiện tại và tương lai một cách hiệu quả nhất.

Kiến trúc sư doanh nghiệp có bốn quan điểm như sau:

• Business perspective - Quan điểm Kinh doanh xác định các quy trình và tiêu chuẩn mà doanh nghiệp hoạt động hàng ngày.

• Application Perspective - Quan điểm ứng dụng xác định mối tương tác giữa các quá trình và tiêu chuẩn được tổ chức sử dụng.

• Information Perspective - Điều này xác định và phân loại dữ liệu thô như tệp tài liệu, cơ sở dữ liệu, hình ảnh, bản trình bày và bảng tính mà tổ chức yêu cầu để hoạt động hiệu quả.

• Technology Prospective - Phần này xác định phần cứng, hệ điều hành, giải pháp lập trình và mạng được tổ chức sử dụng.

Công cụ 3: Rational Refining Pro

Quy trình lập hồ sơ, tổ chức theo dõi và thay đổi Yêu cầu và truyền đạt thông tin này giữa các nhóm dự án để đảm bảo rằng các thay đổi lặp đi lặp lại và không lường trước được duy trì trong suốt vòng đời dự án.

Theo dõi trạng thái và kiểm soát các thay đổi đối với đường cơ sở yêu cầu. Các yếu tố chính là Kiểm soát thay đổi và Truy xuất nguồn gốc.

Requisite Pro được sử dụng cho các hoạt động trên và mục đích quản trị dự án, công cụ này được sử dụng để truy vấn và tìm kiếm, Xem thảo luận là một phần của yêu cầu.

Trong Re essence Pro, người dùng có thể làm việc trên tài liệu yêu cầu. Tài liệu là một tệp MS-Word được tạo trong ứng dụng Reqpro và được tích hợp với cơ sở dữ liệu của dự án. Các yêu cầu được tạo bên ngoài Requisite pro có thể được nhập hoặc sao chép vào tài liệu.

Trong Re essence Pro, chúng ta cũng có thể làm việc với khả năng truy xuất nguồn gốc, ở đây nó là mối quan hệ phụ thuộc giữa hai yêu cầu. Truy xuất nguồn gốc là một cách tiếp cận có phương pháp để quản lý sự thay đổi bằng cách liên kết các yêu cầu có liên quan với nhau.

Requisite Pro giúp dễ dàng theo dõi các thay đổi đối với một yêu cầu trong suốt chu kỳ phát triển, vì vậy không cần phải xem xét tất cả các tài liệu của bạn một cách riêng lẻ để xác định yếu tố nào cần cập nhật. Bạn có thể xem và quản lý các mối quan hệ đáng ngờ bằng cách sử dụng Ma trận xác định nguồn gốc hoặc chế độ xem Cây xác định nguồn gốc.

Các dự án Re essence Pro cho phép chúng tôi tạo một khuôn khổ dự án trong đó các tạo tác của dự án được tổ chức và quản lý. Trong mỗi dự án, những điều sau đây được bao gồm.

• Thông tin chung về dự án
• Packages
• Thông tin tài liệu chung
• Các loại tài liệu
• Các loại yêu cầu
• Thuộc tính yêu cầu
• Giá trị thuộc tính
• Truy xuất nguồn gốc giữa các dự án

Re essence Pro cho phép nhiều người dùng truy cập đồng thời vào cùng một tài liệu dự án và cơ sở dữ liệu, do đó khía cạnh bảo mật của dự án là rất quan trọng. Bảo mật ngăn chặn việc sử dụng hệ thống, nguy cơ tiềm ẩn hoặc mất mát dữ liệu do người dùng trái phép truy cập vào tài liệu dự án.

Chúng tôi khuyến nghị rằng bảo mật được bật cho tất cả các dự án Re essencePro. Làm như vậy đảm bảo rằng tất cả các thay đổi đối với dự án được liên kết với tên người dùng thích hợp của Cá nhân đã thực hiện thay đổi, do đó đảm bảo rằng bạn có một lộ trình kiểm tra hoàn chỉnh cho tất cả các thay đổi.