Software requirements

Software development consists of many knowledge-intensive processes. One of the most difficult to model, however, is requirements elicitation. This paper presents a mathematical model of the requirements elicitation process that clearly shows the critical role of knowledge in its performance. One meta-process of requirements elicitation, selection of an appropriate elicitation technique, is also captured in the model. The values of this model are: (1) improved understanding of what needs to be performed during elicitation helps analysts improve their elicitation efforts, (2) improved understanding of how elicitation techniques are selected helps less experienced analysts be as successful as more experienced analysts, and (3) as we improve our ability to perform elicitation, we improve the likelihood that the systems we create meet their intended customers’ needs.

 

Requirements elicitation is recognized as one of the most critical, knowledge-intensive activities of software development; poor execution of elicitation will almost guarantee that the final project is a complete failure. Since project failures are so rampant, it is quite likely that improving how the industry performs elicitation could have a dramatic effect on the success record of the industry.

To better understand the importance of the current paper, let us contrast its goal with the goal of the many dozens of writings, e.g., that present a specific methodology for elicitation broken down into multiple steps.

In this paper we use specific definitions for some terms:

  • Requirements Process. The activities that when performed result in an understanding and documentation of the desired external behavior (i.e., the requirements) of a system.
  • Process Model. A representation showing the processes to be performed in order to achieve some well-defined goal.
  • Technique. A documented series of steps along with rules for their performance and criteria for verifying completion. A technique usually applies to a single process
    a process model. Sometimes includes a notation and/or a tool.
  • Methodology. A process model, along with documented techniques and/or tools to support each process in the model.

Requirements Process

The requirements process is also often described as a series of activities such as elicitation, modeling, triage, specification, and verificatiorr2:

  • Elicitation. Learning, uncovering, extracting, surfacing, and/or discovering needs of customers, users, and other potential stakeholders.
  • Modeling. Creating and analyzing models of requirements, with the goals of increasing understanding and searching for incompleteness and inconsistency.
  • Triage. Determining which subset of the requirements ascertained by elicitation are appropriate to be addressed in specific releases of a system.
  • Specification. The documentation of the desired external behavior of a system.
  • Verification. Determining the reasonableness, consistency, completeness, suitability, and lack of defects in a set of requirements.

 

Requirements elicitation

As mentioned earlier, elicitation is all about determining the needs of stakeholders. Most models of requirements elicitation focus on specific methodologies or techniques.

This paper has introduced a new unified model of requirements elicitation. Although its significance will be determined only in the future, our hope is that this formal model of elicitation becomes the norm among researchers and practitioners. The model described herein highlights the critical knowledge required by, and defines the underlying basis of, an implementation of the elicitation technique selector function, which when complete, will enable:

  • All (not just the most experienced) analysts will be able to select elicitation technique based on explicit knowledge, hitherto considered tacit.
  • Project managers will have an improved appreciation for the critical role elicitation plays in overall project success.
  • Analysts will be able to compare and contrast the assumptions and results achieved by the use of any elicitation technique.
  • Analysts will be able to easily tailor existing methodologies for unique situations.
  • Researchers will be forced to explicitly state the assumptions their elicitation methodologies are making about the situation at every step.
  • Analysts will no longer be bound by pre-defined methodologies, but instead will be able to create new elicitation methodologies easily, by defining situational characteristics and then observing and recording the resultant instances of methodologies.

 

Colorado Univ., Colorado Springs, CO, USA
Colorado Univ., Colorado Springs, CO, USA