It is best practice to define the business requirements and the process(es) an application will manage as part of the application development plan. What are some of the considerations to document as…

Question

Options

• ABusiness problem, data input/output, users/stakeholders, and process steps
• BBusiness problem, data input/output, project schedule, and process steps
• CBusiness problem, data input/output, users/stakeholders, and database capacity
• DBusiness problem, users/stakeholders, available licenses, and database capacity

• A
  89% (25)
• B
  7% (2)
• C
  4% (1)

Explanation

Option A captures the four core components of a business process document: defining the business problem (why the app exists), data input/output (what information flows through it), users/stakeholders (who interacts with or is affected by it), and process steps (how it works end-to-end).

B is wrong because "project schedule" is a project management artifact, not a business process consideration - schedules belong in a project plan, not a process definition. C swaps out "process steps" for "database capacity," which is a technical/infrastructure concern, not a business process element. D replaces both "data input/output" and "process steps" with "available licenses" and "database capacity" - both of which are resource/infrastructure concerns that come later in the development lifecycle.

Memory tip: Think of the acronym BDUS - Business problem, Data I/O, Users/stakeholders, Steps. If an answer swaps any of these for infrastructure or schedule items, it's wrong.

No community discussion yet for this question.