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:
-
Functional Requirements. This might
include some high-level UML Use Case diagrams.
-
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.)
-
Requirements for User Acceptance.
-
Constraints. These are business
considerations that may constrain your design.
-
Time
-
Resources
-
Enterprise Planning
-
Budget
-
Other
Step 4: Functional System Design
| Home | About Us | Clients | Project Management Resources | Tools & Templates | Links |
|
The manager asks how and when; the leader asks what and why. ~ Warren Bennis
Next to doing the right thing, the most important thing is to let people know you are doing the right thing. ~ John D. Rockefeller
|