The Requirement Elicitation Techniques

Published Date: 02 Nov 2017

The Requirement engineering process is the processing of the requirements right from the beginning to the end of the software development. The following diagram will illustrate the Requirement Engineering process more clearly.

Requirement

Engineering

Requirement

Management

Requirement

Analysis

Requirement

Elicitation

Requirement

Verification

Requirement

Specification

3.1 Requirement Elicitation

This is the most important step of the Requirement Engineering process. In this step the user and the developer discover, review, articulate, and understand the users need and the constraints of the software and the development activity. This step helps the user and developer know what can be expected from the software to be developed. During this phase a lot of initiative has to be taken from the developer side.

Requirement Elicitation Techniques:

1) Interviewing and Questionnaire

2) Requirements Workshop

3) Brain storming and Idea Reduction

4) Story Boards

5) Use Cases

6) Role Playing

7) Prototyping

1) Interviewing and Questionnaire:

In this technique the developer conducts an interview with the user based on a questionnaire with context-free questions. Such as ‘Who is actual user?’ ’What are their needs?’

This technique helps in

a) Knowing the customers’ needs well

b) Assessing the problem well

c) Understanding the user environment

d) Knowing the user’s understanding about the software

e) Easier in suggesting solutions

2) Requirements Workshop:

In this technique all the key stake holders and developers come together for a short but intensely focused period where an exchange of ideas take place. An agenda is decided and a format is laid out for working. An outside experienced facilitator ensures the success of the workshop. The facilitator helps in carrying the workshop efficiently by:

a) By taking care that the session takes a good progressive route as it advances.

b) Controlling the workshop well, by sticking to the agenda throughout the session.

c) Seeing that each stakeholder participates in the workshop.

d) Managing the time of the workshop.

3) Brainstorming and Idea Reduction:

This technique involves both idea generation and idea reduction. Various voting techniques are used to prioritize the ideas. This is a very effective requirement elicitation technique because many creative and innovative ideas come from seemingly unrelated ideas. The idea reduction phase helps in pruning the ideas that are not worthy of further discussion and grouping the similar ideas together.

4) Storyboarding:

Storyboarding identifies the players, explains what happens to them and how it happens. Its helps resolve the "yes, but" reactions in the requirement elicitation phase.

5) Use Cases Techniques:

This is the most common technique used in the requirement elicitation phase. This phase like the storyboarding technique identifies the who, what and how of the system behavior. It describes the interaction between the user and developer. Giving an idea of what the software does for the user. It gives an idea of the systems/software’s functional behaviour.

6) Role playing:

Role playing techniques allows the user and the developer exchange roles and thus understands each other’s perspective better. It helps the user understand the constraints of the software.

7) Prototyping Technique:

In this technique a partial implementation of software is done. It helps the user and developer understand the requirements in a better way. Prototyping takes care of the fuzzy requirements those that are poorly defined or poorly understood.

Challenges faced during the Requirement Elicitation step:

1) "Yes, but" syndrome –

This problem stems up from the human nature. The user is not necessarily an IT friendly person. Sometimes they fail to understand constrains and limitations of the software. They are unable to see the software as a physical device. Thus this problem comes up when the expectations from the software and the developers are too high and the functionality of the software is not clear to the user.

2) The undiscovered ruins syndrome –

"In many ways, the search for requirements is like a search for undiscovered ruins: the more you find, the more you know remain" [Dean Leffingwell, Don Widrig]. If the requirements are discovered in the later stages of the development phase it gets difficult to take care of them then, thus increases the cost of the software.

3) The User and developer syndrome –

This takes place because of miscommunication between user and developer. The user many times is not able to articulate his /her requirements well thus making a completely different demand. Analysts think they understand the user’s problem better

than the users, thus creating confusion. Techniques like storyboarding and role play help in dealing with this kind of situations. They also help in understanding the requirement from multiple viewpoints, thus giving a clearer picture.

4) Living with the sins of your Predecessors –

The user’s past bad experiences with software development can make situations difficult and make it difficult to gain trust from the users.

Requirement Elicitation guidelines:

1) Assess system feasibility.

2) Be sensitive to organizational and political consideration

3) Take multiple viewpoints into consideration

4) Record requirement sources

5) Identify and consult system stakeholders.

6) Prototype poorly understood requirements

7) Reuse requirements.

8) Look for domain constraints.

3.2 Requirement Analysis

In the requirement analysis step the requirement gathered in the Requirement elicitation step are studied and analyzed. This is a very critical step in the software development process. Steps in Requirement Analysis phase:

1) Fix software boundaries-

In this step a study is made of all the requirements collected from the stakeholder. This study helps in understanding and setting up boundaries to the software project.

2) Identify the user –

From all the data collected during the requirement elicitation step, it becomes easy to identify which user is doing what. Study the requirement from each user and have a brief idea as what is the requirement of each user.

3.3 Requirement Specification

Requirement Specification is the step in which all the requirements that are understood and analyzed are put on a document. This document is often called Software Requirement Specification (SRS). It is a proof of all the requirements that are finalized by the user and developer. SRS specifies the functions and the capabilities that will be carried by the software. A well designed SRS specifies the functional requirement and non-functional requirements only it is not for the design suggestions. SRS works as a guideline in moving ahead with the development work. It acts as checklist and help in ensuring that all the requirements are taken care off. "The SRS often works as the ‘Parent’ document because all subsequent documents like the design specification, statement of work, design architecture specification, testing and validation plans and documentation plans are related to it", article by Donn Le Vie.

A well designed and well-structured SRS takes care of four things:

1) SRS provides a proper feed back to the users. It is an assurance to them that the development organization understands the issues and the software behaviour necessary to address those problems.

2) SRS helps in organizing the data, drawing borders around the problem, solidifying ideas and breaking down the problem domain in various components.

3) SRS serves as an input to the design specification.

4) SRS also serves as a product validation check.

Content of Software Requirement Specification (SRS):

Several standard organizations (including the IEEE) have identified nine important key elements that should be taken care of while writing and designing an SRS:

1) Interfaces

2) Functional Capabilities

3) Performance levels

4) Data structures/Elements

5) Safety

6) Reliability

7) Security/Privacy

8) Quality

9) Constraints and Limitations

3.4 Requirement Verification/Validation

Verification phase tells us if we are building the product right. It means that each "stage" of development follows processes and standards. Quality is the main goal. Validation tells us if what we are building is right. It also checks if the overall product and process meets the user needs. User satisfaction is the goal. It is a process of ensuring that the SRS is in compliance with the users’ needs, conforms to the documents standards of the requirement phase and is an adequate base for the architectural design phase. (David A Cook).

Requirement Verification and Validation techniques:

Some of the most commonly used requirement verification and validation techniques are:

1) Tracing approaches- This approach helps in keeping a check on goals against tasks, features and requirement. It is generally done using a traceability matrix.

2) Prototyping- This technique helps in demonstrating the requirements to the users. Test scenarios are developed which provide broad coverage of all the requirements.

3) Testing- Inventing test cases to check on the requirements is an effective validation technique. It is very useful and essential if functional requirements have test cases associated with them.

4) User manual writing- Writing user manual is one very effective way of checking on the validity of the requirements. It describes the functionality and implementation of the system.

5) Reviews and Inspections- In this technique a group of different people read and analyze the requirements, look for problems, discuss them and agree on an action plan to address these problems.

Types of requirement reviewing techniques:

a) Reading a document and signing for endorsement.

b) Formal Inspections: Very structured and detailed review, defined roles for participants and preparation is needed.

3.5 Requirement Management

In this step requirements are managed and controlled.

The following things are carried out in the Requirement Management Phase:

1) Controlling the baseline requirement.

2) Keeping a track of the changed requirement and maintaining history of the same.

3) Process proposed changes to the requirement.

4) Keeping requirement consistent with the plans and work products. How does requirement Management help?

1) In keeping track of the budget.

2) The history helps in reusing the requirement.

3) Improves efficiency.

3.6 Product and Practices

The requirement engineering practices differ a lot between the SMEs

1) Type of system: market-driven vs. customer-specific systems.

2) Degree of adaptability: user –configurable vs. vendor-configured system.

3) Type of software development vs. sub-contracting.

According to the workshop a majority of the SMEs develop market driven systems. In a market driven system two strategies are visible:

1) Starting directly with a market concept

2) Generalizing the solution for one initial customer to the needs of other similar customers.

Projects in SMEs are usually triggered by

1) Technology changes (e.g. new operating /window system, new hardware)

2) New features to be integrated to market pressures.

3) Customer specific adaptation.

3.7 Requirements Sources and Elicitation Activities

The major sources for requirements are customers and users, observations of the market and in-house domain expert. In the initial phase interviews with the prototypical customer are conducted and domain experts are involved. In the later stages workshops are held with potential and future customers to elicit further requirements. The workshop also helps the customer gain deep practical insight about the software.

3.8 Requirement Specification, Verification and Validation

Documenting requirements strongly depends upon the type of software development; in-house development or by sub-contracting the project. It also depends upon the degree of adaptability: user-configurable or vendor configured system. The sub contracting SMEs must have a complete SRS. The SMEs that develop vendor-configured systems usually state the requirements that have particularly customer-specific adaptation. These become part of the legal contract which the customers possess. In many market-driven systems that are developed in-house (where the developer and the requirements sources are located at the same place) requirements are communicated verbally and not documented. Hence there is absence of the requirement document. Some SMEs use the user manual as an SRS but face problems as user manuals are not detailed enough.

3.9 System Evolution

SMEs that did not produce an SRS faced problems during the testing phase since the first task of the test personnel is to elicit the requirement again in order to create test cases. Thus a large amount of time and effort is spent on testing and rework. During the maintenance phase the new requirement can cause unforeseeable interaction with the already implemented requirement.

3.10 Quality

3.10.1 Quality as a concept

Quality is a concept that lacks a clear and concise definition and is thus difficult to accurately measure, improve or even compare across different industries, products and services. The quality of a service refers to the extent to which the service fulfils the requirements and expectations of the customer.

An understanding of the basic concepts on quality and its management is essential for the professional management of Quality of Service (QoS). According to ISO 8402 standard the concept of quality can be defined as "totality of characteristics of an entity that bear on its ability to satisfy stated and implied needs". An entity is an item that can be individually described and considered. An entity may be an activity or a process, a physical product or an organisation, actually anything that has a quality attribute.

Quality is a phenomenon; it is an emergent property of people’s different attitudes and beliefs, which often change over the development life-cycle of a project.

The concept of quality can be observed different standpoints. Lillrank [1990] names six different viewpoints. A customer oriented viewpoint emphasises customer satisfaction, which arises from fitness for use. A manufacturing oriented viewpoint means similarity and consistency in the manufacturing process. A product oriented viewpoint emphasises product performance and value oriented viewpoint concentrates on getting best possible quality for the lowest possible price. Additionally an environment oriented viewpoint emphasises the environmental impact of the product. A basic element of quality is that it is not free: it always requires efforts typically reviews, testing, inspections etc. which cost but on the other hand it always adds some value to the customer. Experiences in manufacturing relating to the cost and return of quality improvements suggest that there are diminishing returns to quality expenditures.

Therefore the key management problem is how to make profitable decisions on quality expenditures. Typically quality characteristics is essential of not, or may be required to a greater or lesser degree, and trade-offs may be made among them.

3.10.2. Software quality

Software of good quality can be defined as software without any errors and deficiencies.

Yet it is very difficult to prove that software doesn't contain any errors. Thus software of

good quality is software without any known errors and deficiencies.

The business value of a software product results from its quality. Quality is increasingly seen as a critical attribute of software, since its absence results in financial loss as well as dissatisfied users, and may even endanger lives.

Since the importance of setting software quality requirements and assessing quality is better recognised a shift from creating technology-centred solutions is made to satisfying stakeholders. Software acquisition, development, maintenance and operations organizations confronted with such a shift are, in general, not adequately equipped to deal with it. Until recently, they did not have the quality models or measurement instruments to allow or facilitate the engineering of quality throughout the entire software product life cycle. The objective of software product quality engineering is to achieve the required quality of the product through the whole production process:

definition of quality requirements and their implementation, measurement of appropriate quality attributes, and evaluation of the resulting quality. The objective is, in fact, software product quality.

Software quality can be divided into three main categories or topics: software quality fundamentals, software quality management processes and practical considerations as in Figure 10 below [Abran, Moore (eds) et al., 2004].

Figure 3.1. Categories of software quality.

Software quality is based on software engineers who share a commitment to software quality as part of their culture. Ethics can play a significant role in software quality, the culture, and the attitudes of software engineers. Quality culture cannot be "bolted on" to an organization; it has to be designed-in and nurtured. The ultimate aim of upper management is to instil a culture that will allow the development of high quality products and offer them at competitive prices, in order to generate revenues and dividends in an organization where employees are committed and satisfied [Duggan and Reichgelt, 2006].

Software process engineering has made many advances in the last decade and has introduced numerous quality models and standards concerned with the definition, implementation, measurement, management, change, and improvement of the software engineering process itself. Process quality is part of the technical and managerial activities within the software engineering process that are performed during software acquisition, development, maintenance, and operation. The most common quality standards are the ISO9001-2000 standard, CMMI (Capability Maturity Model Integration) TQM (Total quality management) and ITIL (the IT Infrastructure Libraby), which is actually a collection of best practices.

The quality of software products can be augmented through a continual process of continuous improvement which requires control management, coordination, and feedback from many concerted processes: the software life cycle evolution, the process of error/defect detection, removal, and prevention, and the quality improvement process.

Software quality management (SQM) applies to all perspectives of software processes, products, and resources. It contains three basic processes: quality planning, quality control, and quality improvement. It defines processes, process owners, and requirements for those processes, measurements of the process and its outputs, and feedback channels. The software quality management processes addresses how well software product will satisfy customer and stakeholder requirements, provide value to the customers and other stakeholders, and provide the software quality close to meet software requirements. Capability maturity model (CMM) is method to estimate and improve the processes of organization [Capability Maturity Model Integration, 2002]. It scales the maturity of organization into five levels which describe how the processes in organization function. The maturity level of an organization provides a way to predict the future performance of an organization within a given discipline or set of disciplines.

At the first maturity level called Initial the processes are usually ad hoc and chaotic. At the fifth level called Optimizing the processes are continually improved based on a quantitative understanding of the common causes of variation inherent in processes. Maturity level 5 focuses on continually improving process performance through both incremental and innovative technological improvements. At this level the quality of production is easy to maintain because of the support of processes.

Software quality assurance (SQA) processes provide guarantee that the software products and processes in the project life cycle conform to their specified requirements by planning, enacting, and performing a set of activities to provide adequate confidence that quality is being built into the software. This means ensuring that the problem is clearly and adequately stated and that the solution’s requirements are properly defined and expressed.

Software verification and validation is a disciplined approach to assess software products throughout the product life cycle. It uses testing techniques which can locate defects so that they can be addressed. The verification and validation process determines whether products of a given development or maintenance activity conform to the requirement of that activity, and whether the final software product fulfils its intended purpose and meets user requirements. The quality of software is not only influenced by the quality of the process used to develop it, but by the quality of the product as well. The software product quality model provided in ISO/IEC 9126-1 defines six quality characteristics:

Functionality

– suitability, accuracy, interoperability, security, compliance

Reliability

– maturity, fault tolerance, recoverability, compliance

Usability

– understandability, learnability, operability, attractiveness, compliance

Efficiency

– time behaviour, resource utilisation, compliance

Maintainability

– analysability, changeability, stability, testability, compliance

Portability

– adaptability, installability, co-existence, replacability, compliance

Software testing should cover all these characteristics.

There are five different types of reviews and audits: management reviews, technical reviews, inspections, walk-throughs and audits. The purpose of a management review is to help in decision making. They monitor progress, determine the status of plans and schedules, confirm requirements and their system allocation, or evaluate the effectiveness of management approaches used to achieve fitness for purpose. The purpose of a technical review is to evaluate a software product to determine its suitability for its intended use. The objective is to identify discrepancies from approved specifications and standards. The purpose of an inspection is to detect and identify software product anomalies. Inspection differs from review in to aspects: an individual holding a management position over any member of the inspection team shall not participate in the inspection and an inspection is to be led by an impartial facilitator who is trained in inspection techniques. Walk-through is meant to evaluate a software product. The purpose of a software audit is to provide an independent evaluation of the conformance of software products and processes to applicable regulations, standards, guidelines, plans, and procedures.

To gain good quality software there has to be also processes in SQM to find and manage defects. Characterizing and classifying those defects into different categories according to their type and criticality is important to ease communication between the stakeholders. It also leads to an understanding of the product, facilitates corrections to the process or the product, and informs project management or the customer of the status of the process or product. Many defect taxonomies exist; the point is to establish a defect taxonomy that is meaningful to the organization and to the software engineers.

SQM techniques can be categorized to static, people-intensive, analytical, and dynamic. Static techniques involve examination of the project documentation and software, and other information about the software products, without executing them. People-intensive techniques include reviews and audits and they can be formal meetings, informal gatherings or desk-check situations. A software engineer usually uses analytical techniques. These techniques are either tool-driven or manual.Various dynamic techniques are performed throughout the development and maintenance of software. Generally, these are testing techniques, but techniques such as simulation, model checking, and symbolic execution may be considered dynamic.

Testing is also important part of quality assurance. SQA ensures that appropriate types of tests are planned, developed, and implemented, and test plans, strategies, cases, and procedures are being developed. If they are selected well measures can help the management in decision-making. They can also find problematic areas and bottlenecks in the software process and give assistance in deciding when to stop testing. The cost of SQM processes is an important issue but it is difficult to gain exact answers. Often, generic models of cost are used, which are based on when a defect is found and how much effort it takes to fix the defect relative to finding the defect earlier in the development process.

What does quality have to do with the project triangle? Quality is at the centre of the project triangle. Quality affects every side of the triangle, and any changes you make to any side of the triangle are likely to affect quality. Quality is not a factor of the triangle; it is a result of what is done during the project with time, money, and scope.

Figure 3.2 Quality in project triangle.

If there is additional time in project schedule, one might be able to increase scope by adding tasks and duration. With this extra time and scope, one can build a higher level of quality into the project and its deliverables. Or if there is need to cut costs to meet the budget, the scope has to be decreased by cutting tasks or reducing task durations. With decreased scope, there might be fewer opportunities to achieve a certain level of quality, so a lower quality results from the need to cut costs.

This study concentrates on the requirements of software. Yet all the categories of software quality by Abran, Moore (eds.) et al. [2004] described previously affect also the quality of software requirements looked from a wide point of view. The elements affect the quality of requirements differently: some elements like software quality assurance, verification and validation and reviews and audits, have more effect, some influence more covertly like software engineering culture ethics. Some elements of quality are slower to change f. ex. software engineering culture ethics, some are easier to bring into use. In next chapter the most typical quality factors of requirement analysis are discussed.

3.10.3 Quality in requirement analysis

Requirements are the foundation of the software development process. They provide the

basis for estimating costs and schedules as well as developing design and testing specifications. So the success of a software project, both functional and financial, is directly related to the quality of its requirements [Javed, Maqsood and Durrani, 2004].

Additionally defects in requirements are more difficult and expensive to fix the later they are found. Thus the quality of requirements has great importance considering whole quality and success of the project.

The primary product of the requirements engineering process is the requirements specification which should state what a system should do - not how it should do it [Kotonoya and Sommerville, 1998]. The requirements specification should state both the functional and non-functional such as performance, reliability, safety, security and usability requirements. The quality of requirements specifications lays the basis to the quality of the whole project - however it is difficult to evaluate the quality of requirements specification in time. The requirements specifications vary in structure, content, accuracy and representation formats. One reason for this is that there of many standards and guidelines which define the content and the structure for a good requirement specification document in different ways. Another reason is the influence of the requirements engineering process methods: different methods can be used or they can be emphasised differently.

Validation and verification are methods to assure the quality of requirements [Wiegers, 2003]. The activity of assuring that the requirements capture the customer intention is referred to as validation. Validation can be defined as the process of ensuring that the engineer has understood the requirements correctly, in other words, "Have we got the right requirements?" The result of requirements validation is requirements document which is an agreed, complete set of requirements. The way to add quality to requirements is reviewing, inspecting, walkthroughs and testing f. ex. By prototyping. Prototypes for requirements validation demonstrate the requirements and help stakeholders to discover problems. Checklists of what to look for may be used to drive a requirements review process [Kotonoya and Sommerville, 1998]. Designing tests for requirements can reveal problems with the requirements. If the requirement is unclear, it may be impossible to define a test for it. The activity of assuring that the software meets its requirements and ensuring that the requirements documents conform to specified standards is referred to as verification.

Verification addresses the question of "Have we got the requirements right?" [Abran, Moore (eds) et al., 2004]. In other words, the validation is the activity linking the requirements to the intention, while verification links the requirements to the implementation.

It is not simple to define what is meant by good requirement. The easiest way to approach the problem is to define features or characteristics of good requirement. According to Kotonoya and Sommerville [1988] the characteristics of good requirements are:

valid in a way that they express only the real needs of the stakeholders complete conceptually and structurally and they specify all the features of the system and on the other hand the features that are not included

consistent so that they don't contradict themselves

necessary

unambiguous

verifiable

understandable

prioritized

traceable.

Firesmith [2003] adds to features metadata so that each requirement should contain attributes or annotations that characterizes them. This metadata can include acceptance criteria, allocation, assumptions, identification, prioritization, rationale, schedule, status, and tracing information.

Although an initial set of requirements may be well documented, requirements will change throughout the software development lifecycle. Constant change addition, deletion and modification in requirements during the development life cycle impacts the cost, schedule, and quality of the resulting product. Thus the quality of requirements management is as important as requirements engineering. The typical reasons for change of requirements during the project are errors, conflicts and inconsistencies in requirements which must be corrected during analysis, validation or later development.

Especially if the project is long there will be the project staff, customers and end-user gain more knowledge of the system which may cause changes in requirements. Technical, schedule or cost problems may cause need for change as well as different external environmental changes like changing customer priorities, changing business environment, emergence of new competitors, organizational changes and new legislation.

3.10.4. Prioritization of requirements

Prioritization of requirements is a way to add quality to project work. As noted before projects are always working under limited resources trying to fulfil customer’s expectations which very often are too high. Requirements prioritization means balancing the business benefit of each requirement against its cost and any implications it has for the architectural foundation and future evolution of the product. By priorization of the requirement it is easier to create the work plan, work breakdown structure (WBS), schedule and risk management for the project and the project management gets more flexibility to decision making [Sommerville and Sawyer, 1997].

If requirements are prioritized during the analysing stage time consuming discussions with the customer are not needed during the hectic implementation phase if shortage of any resources appear.

Prioritization scales is a common approach to prioritization [Wiegers, 1999]. Usually requirements are divided into three priority categories: high, medium and low. Another scale could be essential, conditional and optional. All scales are subjective and imprecise, so everyone involved must agree on the meaning of each level in the scale they use. The granularity at which to prioritize requirements is another issue. Even a medium-sized project can have hundreds or thousands of detailed functional requirements, too many to classify analytically and consistently. An appropriate level of abstraction has to be chosen for the prioritization. It could be at the use case level, the feature level, or the requirement list level.

Another prioritization method is prioritization models with cost-value approach like analytic hierarchy process (AHP). It is used in general as a problem solving process in which different solutions are evaluated. A decision is structured into a hierarchy, determining relative priorities for the elements in the hierarchy, and combining the numbers into overall weights estimating each decision outcome.

Total quality management (TQM) actually is quality method for the whole business. Total Quality is a description of the culture, attitude and organization of a company that aims to provide, and continue to provide, its customers with products and services that satisfy their needs. The culture requires quality in all aspects of the company's operations, with things being done right first time, and defects and waste eradicated from operations. With requirements prioritization it rates each requirement against several weighted project success criteria and computes a score to rank the priority of the requirements.

Kano method classifies customer preferences into five categories: attractive, one dimensional, must-be, indifferent and undesired Quality function deployment model (QFD) uses the Kano model by structuring of the comprehensive QFD matrices [Zultner, 1992]. OFD is a comprehensive method for relating customer value to the features for a proposed product.