Within a systems requirements report, which contents are typically included before detailed design begins?

Introduction / Context:
The systems requirements report (sometimes called the requirements specification) consolidates what the solution must accomplish and the rationale for pursuing a particular approach. It anchors scope for stakeholders and provides a bridge to design and implementation planning.

Given Data / Assumptions:

• Alternative solutions were investigated during analysis.
• Stakeholders need a clear view of proposed scope and boundaries.
• A high-level structure may be sketched to communicate feasibility and partitioning.

Concept / Approach:
Comprehensive requirements reports usually include: (1) alternatives with feasibility and selection criteria; (2) models of the proposed system such as context and data flow diagrams to set boundaries; and, in many methodologies, (3) a preliminary module hierarchy or structure view to communicate how responsibilities might be partitioned. While detailed structure charts belong to design, a top-level hierarchy overview is often included to aid planning and stakeholder understanding.

Step-by-Step Solution:

Verification / Alternative check:
Review standard templates: most include business needs, scope, use cases/process models, data models/DFDs, alternatives and feasibility, and often a high-level solution concept (including tentative module decomposition).

Why Other Options Are Wrong:

Common Pitfalls:
Treating a preliminary hierarchy as final design, or skipping alternatives which later undermines stakeholder buy-in when trade-offs surface during implementation.

Final Answer:
All of the above.