Challenges in Eliciting Requirements

Challenges in Eliciting Requirements

The most difficult single part of building a software system is deciding specifically what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, containing all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements.

- Fred Brooks

Challenges in eliciting software requirements are basically the reverse of the guidelines, and there are many of them. Based on Brooks counsel, we'll take a brief look at the challenges experience tells us to be wary of:

●  Accommodating valid requirements changes.

●  Achieving requirements completeness without unnecessarily constraining system design.

●  Analysts lack of knowledge of problem domain; user and analyst speaking different languages.

●  Changing requirements over time.

●  Conflicting views of necessary requirements.

●  Considering environmental factors (e.g., the certainty of the system's interfaces to other systems).

●  Developing prototypes that are not too expensive, and are understood to be part of requirements elicitation techniques, not implementable components.

●  Ease of omitting "obvious" information.

●  Emphasizing the computing aspects of the system instead of ways in which the system will change the way of doing business.

●  Expressing the requirements in a form that allows the developers to determine if they are implementable and testable.

●  Identifying domain experts (application and development).

●  Identifying similar systems from which to learn or borrow.

●  Ill-defined system boundaries.

●  Inadequate understanding of computer capabilities and limitations on the part of stakeholders.

●  Incomplete understanding of needs on the part of the users.

●  Involving all major stakeholder communities (customers, sponsors, users, developers, quality engineering, analysts, developers).

●  Iterating in order to rework requirements in the light of increased knowledge.

●  Keeping documentation in electronic form and up-to-date (i.e., if flip chart paper is used during a brainstorming session, it must be entered into a word processing document, spreadsheet, or database, and made available to all stakeholders).

●  Keeping the emphasis on methodology instead of technique - there is a danger in being "technique-oriented," so that the problem situation will be distorted to fit the technique; we need rather to be problem- and user-oriented.

●  Keeping the level of requirements at the level of "what," and leaving the "how" to later phases, such as design (e.g., What data does the system produce and consume? What functions must the system perform? What interfaces are required? What constraints apply?).

●  Lack of understanding of the mission of the system within the organization it will be placed.

●  Maintaining "completeness" by resolving TBDs (to be done issues).

●  Managing conflicting goals, views, and interests.

●  Modeling large quantities of data.

●  Obtaining authorizations.

●  Obtaining wish lists for each stakeholder, across multiple levels of authority (i.e., managers should not influence users).

●  Partitioning the system to reduce complexity.

●  Personnel resistance to the development of a new system (e.g., fear of losing a job because functionality will be automated).

●  Prioritizing the requirements; determining the critical functions.

●  Producing the appropriate amount of information - enough to move on to the SRS and design, but not too much, as is required by some methodologies.

●  Saving unnecessary design information given by the stakeholders until the appropriate phase.

●  Stakeholder's backgrounds are so varied that a common language for requirements is difficult to achieve.

●  Staying within cost and schedule constraints imposed by the sponsor.

●  Tailoring the requirements elicitation methods for what is appropriate to the project; integrating flexibility into the methodology.

●  Tracing requirements backward and forward.

●  Uncovering design constraints.

●  Understanding requirements for large and/or complex systems.

●  Validating that requirements are in agreement with project goals.

●  Working within nonwaterfall life cycle models where design may be taking place concurrently with requirements gathering -requirements are seldom "frozen" at the end of the requirements phase.

None of these challenges have a pat answer or an easy solution, but the methods discussed here will help to offset, if not overcome, them. The software project manager would do well to assess the project's particular challenges and translate them into risks that are documented, tracked, and controlled.


software systems, eliciting requirements, software requirements, life cycle models
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 2018 SPMInfoBlog.
Designed by TechPlus