*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 Use Cases. 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 proposal. 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? Thanks for your time. ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [email protected] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
