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.
- Functional Requirements.
This might include some high-level UML Use Case diagrams.
- 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
- Requirements for User Acceptance.
These are business considerations that may constrain your design.
- Enterprise Planning
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.