Feasibility study contents: A feasibility document for an information-system project should include all of the following <em>except</em> which item?

Introduction / Context:
Feasibility studies evaluate whether a proposed system is worthwhile before substantial design and implementation work begins. Knowing what belongs—and what does not—keeps early documentation lean and decision-focused.

Given Data / Assumptions:

• A feasibility document should support a go/no-go decision.
• It summarizes scope, problems, alternatives, costs, benefits, risks, and constraints.
• Detailed design artifacts (for example, DFDs) are usually produced later during analysis/design phases.

Concept / Approach:
Early documents emphasize business justification and outline solution paths. While high-level context diagrams may appear, detailed data-flow diagrams are typically premature and can bias decision makers or waste effort if the project is not approved.

Step-by-Step Solution:
List required items: project identity, problem statements, options, cost-benefit estimates, schedule, and risks.Determine which item is a detailed design artifact: DFDs.Select “data-flow diagrams” as the exception.

Verification / Alternative check:
Stage-gate methodologies separate feasibility/business case (Gate 1) from detailed analysis/design (later gates) where DFDs and models are elaborated.

Why Other Options Are Wrong:

• Project name and problem descriptions: Fundamental context.
• Feasible alternatives: Central to the decision.
• None of the above: Incorrect because DFDs are the exception at this stage.

Common Pitfalls:
Over-investing in design before approval; presenting low-fidelity cost/benefit without clear assumptions; excluding risk and constraints.

Final Answer:
data-flow diagrams (detailed DFDs)