Project Life Cycle

Step 3: Publish Business Requirements

Here the client has a chance to insert "must-haves" into the specification. Get them to limit their requests to actual high-level functional requirements (Ability to input Sales Orders from remote connection using laptop computers. e.g.). Discourage attempts to specify the software, or OS, or programming language, or minor details like color of the buttons. If they must include such things, have them submitted in the form of "suggestions" for the User Interface. Sticking to high-level functional requirements 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. These are not detailed interface specifications. Make this a high-level list ("Must be able to interface with main frame General Ledger to post G/L entries." e.g.)

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

Step 4: Functional System Design

| Home | About Us | Clients | Project Management Resources | Tools & Templates | Links |