Requirements elicitation

Last updated

In requirements engineering, requirements elicitation is the practice of researching and discovering the requirements of a system from users, customers, and other stakeholders. [1] The practice is also sometimes referred to as "requirement gathering".

Contents

The term elicitation is used in books and research to raise the fact that good requirements cannot just be collected from the customer, as would be indicated by the name requirements gathering. Requirements elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do or not do (for Safety and Reliability). Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brainstorming, use cases, role playing and prototyping.

Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation process. Requirements elicitation is a part of the requirements engineering process, usually followed by analysis and specification of the requirements.

Commonly used elicitation processes are the stakeholder meetings or interviews. [2] For example, an important first meeting could be between software engineers and customers where they discuss their perspective of the requirements.


The requirements elicitation process may appear simple: ask the customer, the users and others what the objectives for the system or product are, what is to be accomplished, how the system or product fits into the needs of business, and finally, how the system or product is to be used on a day-to-day basis. However, issues may arise that complicate the process.

In 1992, Christel and Kang identified problems that indicate the challenges for requirements elicitation: [3]

  1. 'Problems of scope'. The boundary of the system is ill-defined or the customers/users specify unnecessary technical details that may confuse, rather than clarify, overall system objectives.
  2. Problems of understanding. The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain, have trouble communicating needs to the system engineer, omit information that is believed to be “obvious,” specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or untestable.
  3. Problems of volatility. The requirements change over time. The rate of change is sometimes referred to as the level of requirement volatility

Requirements quality can be improved through these approaches: [4]

  1. Visualization. Using tools that promote better understanding of the desired end-product such as visualization and simulation.
  2. Consistent language. Using simple, consistent definitions for requirements described in natural language and use the business terminology that is prevalent in the enterprise.
  3. Guidelines. Following organizational guidelines that describe the collection techniques and the types of requirements to be collected. These guidelines are then used consistently across projects.
  4. Consistent use of templates. Producing a consistent set of models and templates to document the requirements.
  5. Documenting dependencies. Documenting dependencies and interrelationships among requirements.
  6. Analysis of changes. Performing root cause analysis of changes to requirements and making corrective actions.

Guidelines

In 1997, Sommerville and Sawyer suggested a set of guidelines for requirements elicitation, to address concerns such as those identified by Christel and Kang: [5]

Sequence of steps

In 2004, Goldsmith suggested a "problem pyramid" of "six steps which must be performed in sequence": [6]

  1. Identify the real problem, opportunity or challenge
  2. Identify the current measure(s) which show that the problem is real
  3. Identify the goal measure(s) to show the problem has been addressed and the value of meeting it
  4. Identify the "as-is" cause(s) of the problem, as it is the causes that must be solved, not the problem directly
  5. Define the business "wants" that must be delivered to meet the goal measure(s)
  6. Specify a product design how to satisfy the real business requirements

However Goldsmith notes that identifying the real problem "is exceedingly difficult". [6]

Complementary approaches

In 2008, Alexander and Beus-Dukic proposed a set of complementary approaches for discovering requirements: [7]

Alexander and Beus-Dukic suggested that these approaches could be conducted with individuals (as in interviews), with groups (as in focused meetings known as workshops, or via Electronic meeting systems), or from "things" (artifacts) such as prototypes. [7]

Non-functional requirements

In 2009, Miller proposed a battery of over 2,000 questions to elicit non-functional requirements. [8] Her approach is to build a stakeholder profile and then interview those stakeholders extensively. The questions are grouped into three sections, all focused on user needs: [8]

  1. Operation: how well does the [needs editing] use?
  2. Revision: how easy is it to correct errors and add functions?
  3. Transition: How easy is it to adapt to changes in the technical environment?

In 2013, Murali Chemuturi suggested the usage of Ancillary Functionality Requirements instead of Non-Functional Requirements as "Non-Functional" connotes "never functional". Second, these requirements in fact fulfill some requirements which are supportive to main or Core Functionality Requirements. [9]

Bibliography

See also

Related Research Articles

<span class="mw-page-title-main">Acceptance testing</span> Test to determine if the requirements of a specification or contract are met

In engineering and its various subdisciplines, acceptance testing is a test conducted to determine if the requirements of a specification or contract are met. It may involve chemical tests, physical tests, or performance tests.

In software and systems engineering, the phrase use case is a polyseme with two senses:

  1. A usage scenario for a piece of software; often used in the plural to suggest situations where a piece of software may be useful.
  2. A potential scenario in which a system receives an external request and responds to it.
<span class="mw-page-title-main">Requirements analysis</span> Engineering process

In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.

A requirement is a singular documented physical or functional need that a particular design, product, or process aims to satisfy. It is commonly used in engineering design, systems engineering, software engineering, enterprise engineering, product development, and process optimization. It is a broad concept that could speak to any necessary function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder. Requirements can come with different levels of specificity; for example, a requirement specification or requirement "spec" refers to an explicit, highly objective/clear requirement to be satisfied by a material, design, product, or service.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering terms

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

In software project management, software testing, and software engineering, verification and validation (V&V) is the process of checking that a software system meets specifications and requirements so that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. In simple terms, software verification is: "Assuming we should build X, does our software achieve its goals without any bugs or gaps?" On the other hand, software validation is: "Was X what we should have built? Does X meet the high-level requirements?"

Requirements engineering (RE) is the process of defining, documenting, and maintaining requirements in the engineering design process. It is a common role in systems engineering and software engineering.

Software prototyping is the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing.

In computing, a scenario is a narrative of foreseeable interactions of user roles and the technical system, which usually includes computer hardware and software.

Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome should conform.

Business analysis is a professional discipline focused on identifying business needs and determining solutions to business problems. Solutions may include a software-systems development component, process improvements, or organizational changes, and may involve extensive analysis, strategic planning and policy development. A person dedicated to carrying out these tasks within an organization is called a business analyst or BA.

In software engineering and systems engineering, a functional requirement defines a function of a system or its component, where a function is described as a summary of behavior between inputs and outputs.

<span class="mw-page-title-main">Systems architect</span>

The systems architect is an information and communications technology professional. Systems architects define the architecture of a computerized system in order to fulfill certain requirements. Such definitions include: a breakdown of the system into components, the component interactions and interfaces, and the technologies and resources to be used in its design and implementation.

Software product management is the discipline of building, implementing and managing software or digital products, taking into account life cycle considerations and an audience. It is the discipline and business process that governs a product from its inception to the market or customer delivery and service in order to maximize revenue. This is in contrast to software that is delivered in an ad hoc manner, typically to a limited clientele, e.g. service.

Software project management is the process of planning and leading software projects. It is a sub-discipline of project management in which software projects are planned, implemented, monitored and controlled.

In information systems, applications architecture or application architecture is one of several architecture domains that form the pillars of an enterprise architecture (EA).

<span class="mw-page-title-main">View model</span>

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of the whole system from the perspective of a related set of concerns.

A goal model is an element of requirements engineering that may also be used more widely in business analysis. Related elements include stakeholder analysis, context analysis, and scenarios, among other business and technical areas.

Software requirements for a system are the description of what the system should do, the service or services that it provides and the constraints on its operation. The IEEE Standard Glossary of Software Engineering Terminology defines a requirement as:

  1. A condition or capability needed by a user to solve a problem or achieve an objective
  2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document
  3. A documented representation of a condition or capability as in 1 or 2

Business requirements, also known as stakeholder requirements specifications (StRS), describe the characteristics of a proposed system from the viewpoint of the system's end user like a CONOPS. Products, systems, software, and processes are ways of how to deliver, satisfy, or meet business requirements. Consequently, business requirements are often discussed in the context of developing or procuring software or other systems.

References

  1. ↑ Requirements Engineering A good practice guide, Ramos Rowel and Kurts Alfeche, John Wiley and Sons, 1997
  2. ↑ Kusiak, Jan. "How To Interview Your Boss". IRM Training.
  3. ↑ Christel, Michael and Kyo C. Kang (September 1992). "Issues in Requirements Elicitation". Technical Report CMU/SEI-92-TR-012. CMU / SEI. Retrieved January 14, 2012.
  4. ↑ "PMI Requirements CoP Webinar on Requirements .Quality".
  5. ↑ Sommerville and Sawyer, 1997.
  6. 1 2 Goldsmith, 2004. Page 12
  7. 1 2 Beus-Dukic, Ljerka; Alexander, Ian (2008). "Learning How To Discover Requirements". 2008 Requirements Engineering Education and Training. Barcelona, Spain: IEEE. pp. 12–14. doi:10.1109/REET.2008.3.
  8. 1 2 Miller, 2009.
  9. ↑ Chemuturi, M. (2013). Requirements Engineering and Management for Software Development Projects. doi:10.1007/978-1-4614-5377-2. ISBN   978-1-4614-5376-5. S2CID   19818654.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.