A short description of the product that all stakeholders agree upon is crucial to project success. The product description should define, in a few short paragraphs, what the product will be, what problem it will solve, and why the product is needed. The description should not delve deeply into the specifics of the problem, but rather it should create a compelling argument why the product is needed. It must be brief, however, so that it is easy enough for all project team members to understand and remember.

The business context helps the project stakeholders understand and agree upon the intended market for the product. The same set of requirements, interpreted for different customers, can yield very different systems.

The business context defines the intended market for the product, including the domain in which the system will operate (e.g. telecom, banking, web commerce, etc.). If the domain is well-understood, a short description may suffice, but for new markets a more complete description of the problem space may be needed. The market definition should include similar products and identify competing companies or solutions.

If the product is being developed to fulfill a contract, the terms of the contract should be noted. If key milestones must be passed in order to be paid for the contract, the terms of fulfillment should be noted.

If the product is an enhancement to an existing product, the existing product should be described.

State the objectives for developing the product - the reasons why this is worthwhile. This includes a tentative schedule, and some assessment of schedule risks. Clearly defined and expressed objectives provide good grounds for formulating milestones and managing risks, that is, keeping the project on track and ensuring its success.

For a commercial software product, the Business Case should include a set of assumptions about the project and the order of magnitude return on investment (ROI) if those assumptions are true. For example, the ROI will be a magnitude of five if completed in one year, two if completed in two years, and a negative number after that. These assumptions are checked again at the end of the elaboration phase, when the scope and plan are known with more accuracy. The return is based on the cost estimate and the potential revenue estimates.

For internal software projects, return is either calculated in terms of the 'Net Present Value' of the project, or in terms of an internal rate of return. With the net present value, the future stream of cash flows accruing to the project are estimated (including negative cash flows related to project development and support) and then discounted back at a required rate of return determined by the organization based on the risk of the project. A net present value of greater than zero indicates that the project has positive net economic benefit to the company.

In the case of the internal rate of return calculation, a net present value of zero is assumed, and the internal rate of return needed to produce this is computed. This internal rate of return (IRR) for the project is then compared to a minimum required rate of return for projects of similar risk. If the IRR for the project is greater than the minimum required rate of return, the project has positive net economic benefit for the company.

Net present value and internal rates of return may be calculated for commercial software products as well.

The resource estimate encompass the entire project through delivery. This estimate is updated at each phase and each iteration, and becomes more accurate as each iteration is completed.

An explanation of the basis of estimates should be included.

Express the constraints under which the project is undertaken. These constraints impact risk and cost. They could be things like external interfaces that the system must adhere to, standards, certifications, or a technical approach employed for strategic reasons, such as using a certain database technology, or distribution mechanisms.

Describe options for the product - optional capabilities and features and associated costs and benefits - and options in approaching the project. Project options might include differing contractual bases, differing project lifecycles, differing mixes of 'make' and 'buy', and so on. In each case, the effect of the option on the financial forecast, and on constraints (in turn impacting risk) should be described. The objective is to give some decision making latitude in terms of capability, cost, ROI, schedule, basis for contract, development lifecycle, technical constraints, and so on, to the reviewing manager(s) with authority to fund the project.