Phase 3: Publish Business Requirements

This is the client's chance to insert "must-haves" into the specification. If you're very lucky, you can get them to limit it to actual high-level functional requirements, such as "ability to input Sales Orders from remote connection using laptop computers." If you're unfortunate, the client will attempt to specify the software, or OS, or programming language, or (God forbid!) color of the buttons. Try to discourage this. If they must include such things, try to have it put in the form of "suggestions" for the User Interface. This prevents the project from being enslaved to requirements that literally have no connection to the desired functionality, and frees the project designer to use the best technology for the job.

Originator: The client.

Deliverable: Business Requirements document. (template)

Components:

  1. Functional Requirements. This might include some high-level UML Use Case diagrams.
  2. Interface Requirements. By this I don't mean detailed interface specifications. I mean something more along the lines of "must be able to interface with with our SendMail system to send system maintenance alerts to our Network Technicians' pagers," or "must be able to post to SBT Payroll via the external posting feature."
  3. Requirements for User Acceptance.
  4. Constraints. These are business considerations that may constrain your design.
    1. Time
    2. Resources
    3. Enterprise Planning
    4. Budget
    5. Other

The House:
This is where you decide on some BROAD specifications for your house. How many bedrooms must it have? Baths? Must it be a single floor? You aren't even creating a floorplan yet (that's the next phase), but you're working on functional requirements... the things your home must have.

Phase 2. Business Case Phase 4. Functional System Design

The informational content of this website is copyright 1997-2002 by David F. Leigh unless otherwise stated. Permission to distribute is granted under the terms of the GNU Free Documentation License.