I have been tasked to QA a 200 page requirements document submitted to us by our vendor. The requirements document has very details about database design and workflow that I am not qualified to give comment upon. Any advice on how to go about QA? I am not sure what is expected of me. Saving Changes...
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Dear Anonymous, it sounds like you are reviewing vendor boiler-plate, rather than a requirements document. In most SDLC models there is a planning phase that is followed by requirements and then functional design, etc. It sounds like you are looking at and seeking to QA Requirements, Specifications, and Functional Design detail all at once. But you have to work with what you have, so one approach is to develop a QA checklist and assessment of how well the requirements document meets the objectives of the previously defined project requirements. That is, are the requirements accurate, comprehensive, and tied back to the project objectives and business purpose with respect to the end user? For example, do the requirements satisfy the required end user need such as using a hand-held device to look up an inventory item and quote a price to a customer. Typically, the things in your 200 page document that show database design and workflow one would expect to see later in a functional design document. Read the document thoroughly and note any pages, tables, or illustrations that are out of order, missing, or just don't make any sense. And if you find the document too long or unwieldly to comprehend and manage from a requirements point of view, then by all means assess and QA that as well. Good luck. -- Mark Perry, VP of Customer Care, BOT International Saving Changes...
