*Note - I am new to this forum. If you feel this topic is not appropriate
to post, just let me know. *
We have been tasked with documenting the requirements for our current legacy
software system, in sufficient detail that a vendor (preferably several
vendors) will be able to give reasonably accurate bids in response to our
Request for Proposals. The better job we do, the more and better (i.e.
lower) bids we will receive.
I'm mostly concerned with the functional requirements. Somebody else gets
to document the non-functional requirements.
The current functionalities of the legacy system must all be in the proposed
system. Some known deficiencies in the legacy system will be documented, as
we want them to be addressed in the proposed system. Minimal new
functionality will be documented, and listed as optional,
separately priced features of the proposed system. The legacy system has
multiple interfaces with other entities, and we will not be asking our
partners to change their software.
The proposal will be for design, development, testing and implementation.
We will be using UML Vision Document and Use Cases to document the
functional requirements. However, everything I've read (I'm new to UML,
just call me "old school") on the topic indicates that a Use Case, while
used by the developer, should never contain sufficient detail for the
developer. I'm okay with that -- Functional Requirements, while used by the
developer, don't contain enough detail for the developer.
I'm looking for suggestions on the best way to document the necessary detail
for the software development vendor, in addition to the Vision Document and
Since we want all our applications to have the same look and feel, we will
probably include wire frames as an appendix.
However, we don't want to eliminate an off-the-shelf-with-customization
Since the field/data edits are well-defined, we will probably include a
Field Requirements Matrix as an appendix.
I'm wondering if it would be a good use of our time and resources to
document the User Test Acceptance Plan, and include it in the RFP? The
inputs to the system will not be changing and are well defined. The end
result may differ in format, but we could use the existing formats and
include a caveat. Would Usage Scenarios fit the bill?