Adaptable Process Model Checklists: Software Requirements Elicitation
	IMPORTANT NOTICE: The complete Adaptable Process Model (APM) is provided for informational purposes and for assessment by potential users. The APM is copyrighted material and may not be downloaded, copied, or extracted for use in actual project work. The full hypertext (html) version of the APM may be licensed for use and customization within your organization. Contact R.S. Pressman & Associates, Inc. for complete licensing information.
	Preparing for Software Requirements Elicitation Eliciting requirements need not be like pulling teeth … but sometimes it is. The problem is lack of preparation by the software engineer and lack of interest by the organization or person requesting the work. You'd think that the customer would be very interested, since the software to be built solves a problem that the customer has. But often, the customer expects the developer to "know" and has little interest in spending time doing "computer stuff." A mistake, no doubt, but reality none the less. For this checklist, the more questions that elicit a negative response, the higher the risk that the elicitation work will fail. Is there a written request for the work to be done? Does the written request outline the problem to be solved, the output to be produced, and the input that will be required? Does the written request have a single named author? Does the named author have authority to make decisions about the request? Is the person doing requirement elicitation familiar with the business area under consideration? Is the person doing requirement elicitation familiar with local jargon, business issues, personnel and politics? Has a formal meeting been requested with the customer? Has an agenda for the meeting been established; have ground rules for the meeting been defined; have all people who need to attend been invited? Has a "definition mechanism" been defined? Is the customer willing to attend the meeting(s)? Have context-free questions (SEPA, 5/e, p. 275) been asked and answered? Have written usage scenarios been developed as part of the elicitation activity? Has the customer walked through the usage scenarios? Have inaccuracies and modification been specified? Have basic output objects been fully defined? Have input object been defined? Have the functions to be implemented been defined, decomposed and tied to usage scenarios? Has the behavior of the system been fully defined (from the customer's viewpoint) under various operating conditions? Have user interface characteristics been discussed and defined? Has earned value been determined for customer requirements? Have constraints and limitation been identified? Have requirements been ranked by importance to the customer? Have review(s) been conducted for all information collected as part of requirements elicitation? Return to Checklist Table of Contents