Home

  About Us

  Products

  Process Models

  SE Resources

  Commentary

  Contact us

Breaking News!

A new blog ... visit OnCenter, Roger Pressman's running commentary on the world at large

A new edition ... the 6th edition of Software Engineering is available now

A first novel ... Roger Pressman's first novel is a technothriller -- The Aymara Bridge

A new training curriculum! RSP&A has partnered with QAI to develop a comprehensive Internet-based software engineering curriculum.

A redesigned Web site ... we've done a major redesign and added many new features

 
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


Site search! We've added links to a search engine that will enable you to search our entire site for information you need. Enter the appropriate word or phrase below.

PicoSearch




Home About us Products Product Models SE Resources Commentary Contact us

Web site and all contents © R.S. Pressman & Associates, Inc. 2001 - 2006, All rights reserved.
Free website templates