Quiz: SWR302_FA23_RE - Có đáp án và giải thích chi tiết

Hoạt động nào không thuộc quy trình kiểm thử? Quy trình kiểm thử bao gồm các hoạt động thiết kế kiểm thử sớm, có người dùng tạo ra các kiểm thử chấp nhận, theo dõi yêu cầu đến kiểm thử, cập nhật kế hoạch khi yêu cầu thay đổi. Tuy nhiên, hoạt động không thuộc quy trình kiểm thử là thiết kế kiểm thử dựa trên yêu cầu. Thiết kế kiểm thử nên được thực hiện độc lập với yêu cầu để đảm bảo tính khách quan và toàn diện. Việc thiết kế kiểm thử dựa trên yêu cầu có thể dẫn đến kiểm thử không đầy đủ hoặc không chính xác.

Các công cụ phát triển yêu cầu bao gồm các công cụ mô hình hóa, thu thập thông tin và tạo bản mẫu. Trong số các lựa chọn trên, công cụ kiểm soát phiên bản không thuộc nhóm công cụ phát triển yêu cầu. Công cụ kiểm soát phiên bản được sử dụng để theo dõi và quản lý các phiên bản của mã nguồn, thường được sử dụng trong quy trình phát triển phần mềm. Trong khi đó, công cụ mô hình hóa giúp tạo ra các mô hình của hệ thống, công cụ thu thập thông tin giúp xác định yêu cầu của hệ thống và công cụ tạo bản mẫu giúp tạo ra các bản mẫu của hệ thống. Vì vậy, công cụ kiểm soát phiên bản không thuộc nhóm công cụ phát triển yêu cầu.

Khi muốn giải quyết yêu cầu mâu thuẫn giữa các lớp người dùng, cách tiếp cận phù hợp nhất là dựa trên mục tiêu kinh doanh. Điều này có nghĩa là việc đưa ra quyết định sẽ được hướng dẫn bởi các mục tiêu kinh doanh, giúp đảm bảo rằng các quyết định được đưa ra là có lợi cho doanh nghiệp. Cách tiếp cận này giúp giải quyết mâu thuẫn giữa các lớp người dùng bằng cách đặt mục tiêu kinh doanh lên trên hết, giúp đảm bảo rằng các quyết định được đưa ra là có lợi cho doanh nghiệp.

Loại nỗ lực nào trong các lựa chọn dưới đây đòi hỏi ít nhất yêu cầu và công việc phát triển để tạo ra một sản phẩm phần mềm giải pháp đóng gói?

Dưới đây là câu hỏi về việc sử dụng danh sách kiểm tra lỗi trong quy trình phát triển phần mềm. Câu hỏi yêu cầu người tham gia đánh giá tính chính xác của tuyên bố: 'Phát triển danh sách kiểm tra lỗi và sử dụng nó cho tất cả các loại tài liệu yêu cầu'. Để trả lời câu hỏi này, chúng ta cần xem xét vai trò của danh sách kiểm tra lỗi trong quy trình phát triển phần mềm. Danh sách kiểm tra lỗi là một công cụ quan trọng giúp đảm bảo chất lượng của sản phẩm phần mềm. Nó giúp phát hiện và sửa lỗi trong quá trình phát triển, từ đó cải thiện chất lượng của sản phẩm. Việc sử dụng danh sách kiểm tra lỗi cho tất cả các loại tài liệu yêu cầu là một thực hành tốt, giúp đảm bảo rằng tất cả các yêu cầu được kiểm tra và xác minh một cách đầy đủ. Điều này giúp giảm thiểu khả năng xảy ra lỗi và cải thiện chất lượng của sản phẩm phần mềm. Vì vậy, tuyên bố trên là đúng.

Một mục tiêu của một phân loại yêu cầu là giúp tổ chức dữ liệu vào các lớp. Điều này giúp chúng ta nghĩ về các lớp mà chúng ta có thể bỏ qua nếu không có phân loại. Ví dụ, khi phân loại yêu cầu cho một hệ thống quản lý thư viện, chúng ta có thể tạo các lớp như 'sách', 'nhân viên', 'khách hàng'. Việc phân loại này giúp chúng ta xác định rõ các yêu cầu của hệ thống và tránh bỏ qua các yêu cầu quan trọng. Ngoài ra, phân loại yêu cầu cũng giúp chúng ta dễ dàng tìm kiếm và truy cập các yêu cầu đã được xác định.

Để tìm được giọng nói của người dùng, chúng ta cần thực hiện các bước sau. Trước hết, chúng ta phải xác định được các lớp người dùng khác nhau cho sản phẩm của mình. Sau đó, chúng ta cần chọn và làm việc với các cá nhân đại diện cho mỗi lớp người dùng và các nhóm liên quan khác. Tiếp theo, chúng ta cần thống nhất về người quyết định yêu cầu cho dự án của mình. Cuối cùng, chúng ta cần hiểu được các nhiệm vụ mà người dùng thực hiện trong quá trình hoạt động kinh doanh của họ. Tuy nhiên, không phải tất cả các lựa chọn đều là bước trong quá trình tìm kiếm giọng nói của người dùng. Lựa chọn không phải bước trong quá trình này là 'Các nhiệm vụ họ thực hiện trong quá trình hoạt động kinh doanh của họ'.

Trong dự án hệ thống thời gian thực và hệ thống nhúng, nhà phân tích nên phân tích các yêu cầu hệ thống riêng lẻ thành nhiều yêu cầu được suy ra. Loại yêu cầu nào sẽ phân bổ cho người?

Ecosystem map là một công cụ giúp minh họa ranh giới và các mối liên kết giữa hệ thống đang phát triển và tất cả các yếu tố khác trong vũ trụ. Nó giúp chúng ta hiểu rõ hơn về hệ thống và cách nó tương tác với các hệ thống khác. Ecosystem map không chỉ dừng lại ở việc minh họa ranh giới và các mối liên kết, mà còn giúp chúng ta xác định các hệ thống liên quan đến hệ thống đang quan tâm và cách chúng tương tác với nhau. Điều này giúp chúng ta có cái nhìn tổng quan hơn về hệ thống và cách nó hoạt động trong môi trường xung quanh.

Ví dụ về yêu cầu tương tự cho các nền tảng đa dạng là cơ hội tái sử dụng yêu cầu. Điều này xảy ra khi một ứng dụng được triển khai trên nhiều nền tảng khác nhau, chẳng hạn như Mac và Windows hoặc iOS và Android. Mặc dù có thể có một số khác biệt về yêu cầu chi tiết và/hoặc thiết kế giao diện người dùng dựa trên nền tảng, nhưng vẫn sử dụng một bộ yêu cầu cốt lõi. Điều này cho phép tái sử dụng các yêu cầu và giảm thiểu sự lặp lại trong quá trình phát triển phần mềm.

Yêu cầu được giả định là những yêu cầu mà người dùng mong đợi mà không có sự thể hiện rõ ràng. Điều này có thể xảy ra khi người dùng không thể mô tả rõ ràng những gì họ cần, nhưng họ vẫn có một hình dung về kết quả cuối cùng. Ví dụ, một người dùng có thể nói rằng họ muốn một hệ thống có thể quản lý dữ liệu của họ, nhưng họ không thể mô tả rõ ràng cách thức hoạt động của hệ thống. Trong trường hợp này, yêu cầu được giả định là hệ thống phải có khả năng quản lý dữ liệu một cách tự động và chính xác. Yêu cầu được giả định thường được phát hiện qua quá trình thu thập yêu cầu (requirements elicitation) và cần được xác định rõ ràng để đảm bảo rằng hệ thống đáp ứng được nhu cầu của người dùng.

Khi tiếp cận hệ thống, điều đầu tiên chúng ta cần làm là hiểu được những gì cần thiết và những gì không cần thiết. Điều này liên quan đến việc phân tích và đánh giá các thành phần của hệ thống, bao gồm cả những gì được gọi là 'meta-model analysis'. Meta-model analysis là quá trình phân tích và mô hình hóa các thành phần cơ bản của hệ thống, bao gồm các quy tắc, quy định và các yếu tố ảnh hưởng đến hệ thống. Quá trình này giúp chúng ta hiểu được cấu trúc và chức năng của hệ thống, từ đó có thể xác định được những gì cần thiết và những gì không cần thiết.

Mô tả phạm vi dự án thường thay đổi theo thời gian và phụ thuộc vào nhiều yếu tố như yêu cầu của khách hàng, nguồn lực và ngân sách. Trong khi đó, tầm nhìn sản phẩm thường là một khái niệm cố định, thể hiện mục tiêu và hướng phát triển của dự án. Vì vậy, phạm vi dự án có thể được xem là động hơn so với tầm nhìn sản phẩm.

Mẫu bản yêu cầu chung được viết từ góc độ người dùng được thể hiện như sau: "Tên lớp người dùng hoặc tên người dùng tham gia shall được phép làm gì với một đối tượng Điều kiện đủ Thời gian hoặc chất lượng phản hồi" Ví dụ: "Người dùng khách hàng shall được phép đặt hàng trực tuyến Điều kiện đủ: khách hàng đã đăng ký tài khoản Thời gian phản hồi: trong vòng 5 phút Chất lượng phản hồi: chính xác 100%" Mẫu này cho phép người dùng thể hiện rõ yêu cầu của mình từ góc độ người dùng, giúp cho việc viết yêu cầu trở nên rõ ràng và dễ hiểu hơn.

Để xác định template phù hợp với yêu cầu ví dụ được viết dựa trên quan điểm của hệ thống, chúng ta cần phân tích yêu cầu. Yêu cầu yêu cầu hệ thống hiển thị danh sách tất cả các thùng chứa hóa chất đang có trong kho nếu hóa chất được tìm thấy trong kho hóa chất. Template phù hợp với yêu cầu này là 'optional precondition optional trigger event the system shall expected system response'. Template này mô tả các điều kiện không bắt buộc, sự kiện kích hoạt và phản hồi của hệ thống khi đáp ứng yêu cầu.

Một cơ hội để tái sử dụng yêu cầu quy trình kinh doanh là khi các quy trình kinh doanh thường xuyên được chia sẻ giữa các tổ chức và cần được hỗ trợ bởi phần mềm. Nhiều tổ chức duy trì một bộ mô tả quy trình kinh doanh được tái sử dụng trên các dự án IT. Ví dụ, một tổ chức có thể có quy trình kinh doanh chung cho việc quản lý nhân sự, bao gồm việc tuyển dụng, đào tạo và đánh giá hiệu suất. Phần mềm được thiết kế để hỗ trợ các quy trình kinh doanh này có thể được tái sử dụng trên các dự án khác, giảm thiểu thời gian và chi phí phát triển.

Theo Karl Wiegers và Joy Beatty trong sách Software Requirements, phiên bản thứ ba, mô hình yêu cầu phần mềm (Software Requirements model) có bao nhiêu cấp độ? Cấp độ này được sử dụng để mô tả các yêu cầu phần mềm ở các mức độ khác nhau. Mô hình này bao gồm các cấp độ sau: cấp độ 1 - yêu cầu chức năng, cấp độ 2 - yêu cầu không chức năng và cấp độ 3 - yêu cầu kỹ thuật. Mỗi cấp độ này cung cấp thông tin chi tiết về các yêu cầu phần mềm ở mức độ khác nhau, giúp các nhà phát triển phần mềm hiểu rõ hơn về yêu cầu của khách hàng và thực hiện các yêu cầu đó một cách chính xác.

Trong kỹ thuật yêu cầu, việc tập trung vào những người quan trọng nhất trong tổ chức là một chiến lược hiệu quả. Điều này có nghĩa là bạn nên ưu tiên những người có ảnh hưởng lớn đến quyết định và quá trình thực hiện dự án. Họ có thể cung cấp thông tin chi tiết và chính xác về yêu cầu của dự án, giúp bạn hiểu rõ hơn về nhu cầu của khách hàng và tổ chức. Bằng cách tập trung vào những người quan trọng nhất, bạn có thể thu thập được thông tin chất lượng cao và đảm bảo rằng dự án được thực hiện đúng hướng.

Trong các dự án được giao thầu (Outsourced Projects), người mua (Acquirer) không cần phải gửi cho nhà cung cấp (Supplier) sản phẩm phần mềm đã hoàn thiện. Điều này là vì nhà cung cấp đã chịu trách nhiệm phát triển và cung cấp sản phẩm phần mềm. Người mua chỉ cần cung cấp các yêu cầu và tiêu chí chấp nhận để nhà cung cấp thực hiện và đảm bảo sản phẩm phần mềm đáp ứng được yêu cầu. Các tài liệu cần thiết mà người mua phải gửi cho nhà cung cấp bao gồm yêu cầu đề xuất (Request for proposal), yêu cầu kỹ thuật phần mềm (Software Requirements) và tiêu chí chấp nhận (Acceptance criteria).

Các thuật ngữ sau có thể được sử dụng thay thế cho nhau. Dưới đây là giải thích về các thuật ngữ này và thuật ngữ tiêu chuẩn trong ngành công nghiệp.

Các nguồn thông tin liên kết theo dấu vết có thể bao gồm nhiều loại khác nhau. Ví dụ, nếu nguồn liên kết là yêu cầu hệ thống, thì đích liên kết có thể là yêu cầu chức năng. Nếu nguồn liên kết là yêu cầu người dùng, thì đích liên kết cũng có thể là yêu cầu chức năng. Tương tự, nếu nguồn liên kết là thành phần thiết kế, thì đích liên kết có thể là mã nguồn. Do đó, tất cả các câu trả lời trên đều có thể đúng tùy thuộc vào ngữ cảnh cụ thể.

Để bắt đầu xác định yêu cầu dữ liệu trong hệ thống phần mềm mới mà bạn muốn phát triển, bạn nên bắt đầu bằng việc xác định các luồng đầu vào và đầu ra trên sơ đồ ngữ cảnh của hệ thống. Sơ đồ ngữ cảnh là một trong những công cụ quan trọng trong thiết kế hệ thống, giúp bạn hiểu rõ về các thành phần và mối quan hệ giữa chúng trong hệ thống. Bằng cách xác định các luồng đầu vào và đầu ra trên sơ đồ ngữ cảnh, bạn có thể xác định được các yêu cầu dữ liệu cơ bản của hệ thống, bao gồm các loại dữ liệu cần được nhập vào và xuất ra. Điều này sẽ giúp bạn có một cái nhìn tổng quan về yêu cầu dữ liệu của hệ thống và từ đó có thể thiết kế hệ thống phần mềm phù hợp.

Loại phân tích dự đoán (predictive analytic) thường liên quan đến việc tạo ra các kịch bản 'nếu - thì' để so sánh dự đoán tương lai. Điều này cho phép các nhà phân tích và quản lý đưa ra quyết định sáng suốt hơn về các chiến lược kinh doanh và đầu tư. Ví dụ, một công ty có thể sử dụng phân tích dự đoán để dự đoán doanh số bán hàng trong tương lai dựa trên các yếu tố như xu hướng thị trường, giá cả và nhu cầu của khách hàng. Từ đó, họ có thể đưa ra quyết định về việc tăng hoặc giảm sản xuất, mở rộng hoặc thu hẹp các kênh phân phối, hoặc thậm chí là thay đổi chiến lược tiếp thị.

Khi một người quản lý dự án muốn chuyển sang công việc phân tích kinh doanh trong tương lai, một thách thức cơ bản mà họ phải đối mặt là thay đổi cách tiếp cận của mình. Trước đây, họ tập trung vào việc quản lý dự án, bao gồm việc lập kế hoạch, quản lý thời gian, phân bổ nguồn lực và quản lý ngân sách. Tuy nhiên, khi trở thành phân tích kinh doanh, họ cần phải tập trung vào việc hiểu nhu cầu kinh doanh và đặt ưu tiên cho các yêu cầu của khách hàng. Điều này đòi hỏi họ phải có khả năng giao tiếp hiệu quả, hiểu biết về kinh doanh và kỹ năng phân tích dữ liệu để đưa ra quyết định sáng suốt.

Phương pháp xác định ưu tiên yêu cầu dựa trên mức độ quan trọng và cấp thiết thuộc về kỹ thuật so sánh cặp đôi và xếp hạng (Pairwise comparison and rank ordering). Điều này có nghĩa là các yêu cầu sẽ được so sánh với nhau một cách cặp đôi để xác định mức độ quan trọng và cấp thiết của từng yêu cầu. Sau đó, các yêu cầu sẽ được xếp hạng theo mức độ quan trọng và cấp thiết để xác định ưu tiên thực hiện. Phương pháp này giúp đảm bảo rằng các yêu cầu quan trọng và cấp thiết được ưu tiên thực hiện trước.

Khi chuẩn bị cho quá trình thu thập yêu cầu (elicitation) trên dự án của mình, bước đầu tiên quan trọng là quyết định phạm vi và chương trình thu thập yêu cầu (decide on elicitation scope and agenda). Điều này giúp bạn xác định rõ những gì cần thu thập, ai sẽ tham gia vào quá trình thu thập, và mục tiêu của quá trình thu thập yêu cầu. Bằng cách quyết định phạm vi và chương trình thu thập yêu cầu, bạn có thể đảm bảo rằng quá trình thu thập yêu cầu được thực hiện một cách hiệu quả và đạt được mục tiêu mong muốn. Ngoài ra, quyết định phạm vi và chương trình thu thập yêu cầu cũng giúp bạn tránh được những sai sót và nhầm lẫn trong quá trình thu thập yêu cầu.

Khái niệm yêu cầu người dùng (User Requirement) được định nghĩa là một mô tả về tính chất hoặc đặc điểm mà hệ thống phải đáp ứng hoặc một ràng buộc mà hệ thống phải tuân thủ. Điều này có nghĩa là yêu cầu người dùng xác định những gì hệ thống phải làm hoặc không làm để đáp ứng nhu cầu và mong muốn của người dùng. Ví dụ, một yêu cầu người dùng có thể là hệ thống phải có khả năng lưu trữ dữ liệu một cách an toàn hoặc hệ thống phải có khả năng xử lý thông tin một cách nhanh chóng. Yêu cầu người dùng là một phần quan trọng trong quá trình phát triển hệ thống, vì nó giúp đảm bảo rằng hệ thống đáp ứng được nhu cầu và mong muốn của người dùng.

Trong quá trình tạo ra tài liệu yêu cầu kiểm tra, hoạt động cơ bản cuối cùng là 'Follow-up'. Đây là bước cuối cùng trong chuỗi hoạt động kiểm tra, bao gồm các bước khác như chuẩn bị, cuộc họp kiểm tra, sản phẩm kiểm tra ban đầu, sản phẩm kiểm tra cuối cùng và sửa đổi. Hoạt động 'Follow-up' liên quan đến việc kiểm tra lại sản phẩm sau khi đã được sửa đổi để đảm bảo rằng các vấn đề đã được giải quyết và sản phẩm đáp ứng được yêu cầu.

Một trong những lý do không nên ưu tiên thực hiện một trường hợp sử dụng (use case) là vì nó sẽ không được thực hiện trong nhiều tháng. Điều này có thể dẫn đến việc lãng phí thời gian và nguồn lực vào một thứ không cần thiết. Thay vào đó, chúng ta nên ưu tiên những trường hợp sử dụng quan trọng và cần thiết cho hệ thống. Ví dụ, nếu một trường hợp sử dụng mô tả một phần của quy trình kinh doanh cốt lõi mà hệ thống cho phép, hoặc nếu nó được yêu cầu bởi một nhóm người dùng quan trọng, hoặc nếu nó cần thiết để tuân thủ các quy định pháp luật, thì đó là lý do để ưu tiên thực hiện. Tuy nhiên, nếu trường hợp sử dụng đó sẽ không được thực hiện trong nhiều tháng, thì chúng ta nên xem xét lại ưu tiên của nó.

Hoạt động mô hình hóa môi trường ứng dụng và tạo bản mẫu nên được thực hiện ở giai đoạn Elicitation. Elicitation là giai đoạn đầu tiên trong quá trình phát triển phần mềm, trong đó người phát triển sẽ thu thập thông tin về yêu cầu của khách hàng và mô hình hóa môi trường ứng dụng để hiểu rõ hơn về yêu cầu của khách hàng. Hoạt động này giúp người phát triển xác định rõ yêu cầu của khách hàng và tạo ra bản mô hình hóa môi trường ứng dụng để sử dụng trong các giai đoạn tiếp theo.

Ký hiệu đồ họa cho phép bạn thể hiện các mục được xem xét và mối quan hệ giữa chúng. Điều này giúp dễ dàng theo dõi và phân tích các mối quan hệ phức tạp giữa các yếu tố khác nhau. Ví dụ, trong một sơ đồ tổ chức, ký hiệu đồ họa có thể được sử dụng để thể hiện mối quan hệ giữa các bộ phận khác nhau của công ty, bao gồm cả mối quan hệ giữa các nhân viên và các bộ phận khác nhau. Điều này giúp dễ dàng theo dõi và phân tích các mối quan hệ phức tạp giữa các yếu tố khác nhau.

Trong kỹ thuật yêu cầu, tài liệu tự do có một số vấn đề. Thứ nhất, tài liệu tự do hạn chế sử dụng tham chiếu trước (Limited Use of Forward References). Điều này có nghĩa là người đọc phải tìm kiếm thông tin trong tài liệu trước khi có thể hiểu được các khái niệm mới. Thứ hai, tài liệu tự do khó địa hóa thông tin cụ thể (Hard to localize specific information). Điều này có nghĩa là khi cần tìm kiếm thông tin cụ thể trong tài liệu, người đọc phải dành nhiều thời gian và công sức để tìm kiếm. Các vấn đề này có thể làm giảm hiệu quả và hiệu suất trong quá trình yêu cầu.

Câu hỏi này yêu cầu người đọc đánh giá tính đúng sai của một tuyên bố. Tuyên bố cho rằng các dự án khác nhau sẽ đòi hỏi cùng một bộ các đặc tính chất lượng. Điều này không phải lúc nào cũng đúng vì các dự án khác nhau có thể có các yêu cầu và mục tiêu khác nhau. Vì vậy, câu trả lời đúng là 'False'.

Trong quy trình quản lý yêu cầu, việc giải quyết xung đột là một phần quan trọng. Khi phát hiện ra bất kỳ xung đột nào, việc giải quyết xung đột càng sớm càng tốt là rất quan trọng. Điều này giúp tránh được những vấn đề phức tạp và tốn thời gian sau này. Elicitation của thông tin có thể diễn ra sau khi giải quyết xung đột, nhưng việc giải quyết xung đột phải được ưu tiên. Việc giải quyết xung đột sớm giúp đảm bảo rằng các yêu cầu được rõ ràng, chính xác và không mâu thuẫn với nhau. Điều này giúp cho quá trình phát triển sản phẩm trở nên hiệu quả hơn và giảm thiểu các vấn đề phát sinh trong tương lai.

Câu hỏi này yêu cầu học viên phân biệt giữa các câu nói khác nhau về thay đổi yêu cầu. Câu không đúng về thay đổi yêu cầu là 'Requirements changes do not affect requirement effort.' (Thay đổi yêu cầu không ảnh hưởng đến nỗ lực yêu cầu). Điều này không đúng vì thay đổi yêu cầu thường ảnh hưởng đến thời gian, chi phí và nguồn lực của dự án. Học viên cần hiểu được tầm quan trọng của việc quản lý thay đổi yêu cầu và cách nó ảnh hưởng đến dự án.

Kỹ năng của một nhà phân tích kinh doanh bao gồm nhiều yếu tố khác nhau. Trong số đó, kỹ năng điều phối (facilitation skills) giúp họ tổ chức và dẫn dắt các cuộc họp, thảo luận và các hoạt động nhóm một cách hiệu quả. Kỹ năng quan sát (observational skills) giúp họ thu thập thông tin và dữ liệu cần thiết. Kỹ năng tổ chức (organizational skills) giúp họ quản lý và sắp xếp công việc một cách khoa học. Kỹ năng lãnh đạo (leadership skills) giúp họ đưa ra quyết định và dẫn dắt nhóm. Tuy nhiên, kỹ năng lập trình và kỹ thuật (coding and technical skills) không phải là kỹ năng cần thiết cho một nhà phân tích kinh doanh. Họ có thể không cần phải lập trình hoặc có kiến thức kỹ thuật sâu rộng, nhưng họ cần phải có khả năng hiểu và làm việc với các công nghệ và hệ thống hiện có.

Các khu vực tiềm ẩn rủi ro được liệt kê dưới đây. Hãy xác định khu vực nào thuộc về các phân ngành kỹ thuật của quy trình thu thập yêu cầu (elicitation processes) trong kỹ thuật yêu cầu.

Hoạt động không thuộc về quy trình thiết kế và mã hóa là: "Trace requirements to design and code". Hoạt động này liên quan đến việc theo dõi các yêu cầu để đảm bảo chúng được thực hiện một cách chính xác trong quy trình thiết kế và mã hóa. Tuy nhiên, nó không phải là một phần của quy trình thiết kế và mã hóa chính thức. Các hoạt động khác như "Have developers review requirements", "Use quality attributes to drive architecture", "Allocate requirements to components", và "Use requirement priorities to drive process iteration" đều là các bước quan trọng trong quy trình thiết kế và mã hóa.

Các yêu cầu kinh doanh mô tả tại sao tổ chức đang triển khai hệ thống, lợi ích kinh doanh mà tổ chức hy vọng đạt được. Fokus là trên các mục tiêu kinh doanh của tổ chức hoặc khách hàng yêu cầu hệ thống. Các yêu cầu kinh doanh giúp xác định được mục tiêu và lợi ích mà hệ thống cần đạt được. Nó giúp cho việc triển khai hệ thống trở nên hiệu quả hơn và đáp ứng được nhu cầu của tổ chức. Các yêu cầu kinh doanh cũng giúp cho việc đo lường hiệu suất của hệ thống trở nên dễ dàng hơn. Nó giúp cho việc đánh giá và cải thiện hệ thống trở nên hiệu quả hơn.

Khái niệm yêu cầu không chức năng có cùng ý nghĩa với đặc tính chất lượng hoặc yêu cầu chất lượng dịch vụ. Yêu cầu không chức năng thường bao gồm các thuộc tính như tính bảo mật, tính khả dụng, tính tương thích, tính mở rộng, tính bảo trì, tính dễ sử dụng và tính ổn định. Những thuộc tính này giúp đảm bảo rằng hệ thống hoặc ứng dụng đáp ứng được các yêu cầu và tiêu chuẩn của người dùng, tổ chức hoặc thị trường. Vì vậy, việc xác định và quản lý các yêu cầu không chức năng là rất quan trọng trong quá trình phát triển phần mềm.