Communicating the Assumptions in Writing

As you collect requirements, and even as you build a new business process, make the assumptions explicit and present them to technical and business personnel alike, in writing. Your goals are

• to specify the purpose of each application

• to identify which parts of the software inventory can remain in use

• to clarify which departments and personnel have which responsibilities during the project

• to address issues that may lead to conflict

• to help decision-makers reach agreement

• to have a record that can be useful when people later ask what the rationale was for a given decision

If you fail to identify assumptions, you're likely to present a solution that needs rework.

Assumptions can concern a variety of issues, including

• standards of measurement, with decisions such as:

  • Monetary values are in dollars.

  • Timestamps reflect Coordinated Universal Time.

• scope of effort, with decisions such as:

  • Fee collection is outside of scope.

  • Underwriters are responsible for setting rejection criteria.

• quality of service, with decisions such as:

  • Service A must be available 99 percent of the time.

  • The application must be able to support 1,000 requesters concurrently.

After you list assumptions, you'll discover that some don't apply to your project at all. That's normal. You'd do well to consider many issues even if you later ignore a few.