Eliciting Requirements

Eliciting Requirements

Almost everyone involved in software engineering or software project management during the last 20 years is well aware of the importance of requirements. We rarely hear of a success story declaring victory over the ever-elusive set of specs, but we often hear poor requirements cited as public enemy number one. As developers and managers, we're cautioned about the exorbitant cost to the project of a missed or incorrect requirement - the most expensive error to correct and the most damaging to customer relations. We're advised of the meaninglessness of a fuzzy requirement, and we're counseled about tester angst over an imprecise one. If we are far enough off the mark with requirements, we may be building a completely different system than the one actually desired; we may slip the bounds of the contractual agreement. Even when starting out on the right foot, requirements volatility can wreak havoc on the best-laid plans. Our goal is to understand the problem we have pledged to solve, even though we have multiple customers, often with conflicting needs. Each stakeholder has his own view of what is required and wanted, each has a "filter" of the world, and each has individual learning and communication styles. If we fail to listen and communicate effectively, the "right" requirements will be discovered too late, if ever. Methods exist to aid requirements elicitation, even though none is an exact science. Given that requirements form the foundation for the software product, it's well worth our time to adopt as many approaches as possible to triumph over this most challenging, yet crucial, step in the development process.

Where We Are in the Product Development Life Cycle

As illustrated in Figure 1, requirements begin to be gathered at the very beginning of the product development life cycle and continue in a gathering-refinement cycle through concept exploration, system exploration, and requirements analysis. Actually, they never stop being gathered, as most modern projects recognize an iterative development life cycle (e.g., spiral, prototyping, incremental delivery), but there comes a time when they, or a subset of them, are solid enough for the development team to move on. The activity of gathering or eliciting software requirements may begin in earnest as soon as the system requirements are firm. Once gathered, the requirements are then packaged into an official document, the Software Requirements Specification (SRS). The requirements are modeled, communicated back to the customer, and used as the basis for the software design.

Requirements Elicitation Occurs at the Beginning of the Life Cycle

"Eliciting Requirements" Relation to the 34 Competencies

Requirements elicitation, so critical to the project and product, relies upon many of the 34 competencies, as reflected in Figure 2.

Eliciting Requirements Relationship to the 34 Competencies

Product Development Techniques

3. Defining the product - The software requirements are the very definition of the software product.

5. Managing requirements - As explained in the first key process area mentioned, in the first meaningful level of SEI CMM maturity (Level 2: Repeatable), the requirements must be controlled (not changed without approvals), and baselined for driving project plans, products, and activities.

6. Managing subcontractors - If subcontractors are involved, proper communication of precise requirements is essential.

7. Performing the initial assessment - Only when it is known what the software product will be, can risks be assessed and estimates of size, cost, effort, and schedule made.

8. Selecting methods and tools - Methods such as those explained in this section (e.g., interviewing, brainstorming) may be selected to support the elicitation of requirements. Automated tools support many of these methods.

Project Management Skills

12. Building a work breakdown structure - Many project managers prefer to build a product WBS. To do so, the requirements defining the product must be known.

16. Managing risks - There are many risks to be managed in the requirements elicitation stage - the risk of goldplating, of poor negotiation for incremental release specifications, of gathering untestable requirements, and so on.

19. Selecting metrics - Requirements volatility is a useful metric that must begin with the observation of the number, type, and complexity of each requirement.

People Management Skills

25. Holding effective meetings - As will be explained in this section, most of the methods for eliciting requirements occur in the setting of a planned meeting between customers, users, and analysts.

26. Interaction and communication - At no other time in a software project is communication so important as during requirements gathering. The development team is trying to "get inside the heads" of the stakeholders. The old saw about the requirement, "Build me a sports car" when the customer envisions a Porsche and the developer envisions a Sports Utility Vehicle (SUV), remains true.

29. Negotiating successfully - It is rare that the customer will be able to receive all desired requirements in the first version of the software. Prioritizing requirements and determining release schedules requires mature and fair negotiation.

31. Presenting effectively - Requirements elicitation is an iterative affair - we listen a little, feed back a little, and do it again. The manner in which the requirements, as understood by the project team, is presented to the stakeholders marks the beginning of a project-long relationship.

Learning Objectives for "Eliciting Requirements"

Upon completion of this section, the reader should be able to:

●  Explain where requirements elicitation occurs in the product development life cycle;

●  List the product, project, and people competencies from the SQI BOK that are necessary for successful requirements gathering;

●  Explain requirements management, both in general and in connection to the SEI CMM;

●  Explain critical success factors and how they apply to software requirements;

●  Explain the criticality of accurate requirements elicitation for the success of software development;

●  Identify the characteristics of a well-written requirement (e.g., primitive, testable);

●  List the types of software requirements;

●  List several methods used in the elicitation of software requirements;

●  Explain interviewing, brainstorming, mind mapping, FAST, JAD, and use case techniques for eliciting requirements;

●  Discuss the challenges of gathering software requirements.


life cycle, software product, software project management
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2017 SPMInfoBlog.
Designed by TechPlus