7.1 Requirements Elicitation
Requirement elicitation is obtaining the requirements of a software application or a product to be built from the Business, End users, Customers, and other Stakeholders. Requirement’s elicitation process helps to understand and collect the requirements.
The requirements phase is the first phase where the defects will enter, a proper elicitation mechanism will play a gate to arrest those injection. If an error occurs in the requirements stage, it will percolate to subsequent development phases which will result in a higher failure cost and sometimes lead to shelving the project itself.
One of the most common reasons for project failures is inadequate attention to customer /user requirements elicitation. Approximately 50–60 % of the defects occur due to poor requirement management. If we do not involve the customer sufficiently in the requirements elicitation process or only take what the customer says he wants without dwelling on it, then there are more chances of the requirements is not properly collected and misunderstood at the analysis stage. Any defect injected in the requirement stage then with each next stage of the project the amount of work needed to be done increases to fix the errors – around 40 % of the work at the design stage and around 70 % at the implementation stage etc. The requirements elicitation process is an important part of the project requirements analysis that ensures product stability and lower cost of quality. The relative costs have been shown in the below diagram.
A survey conducted on European companies found that more than 60% of them considered requirements elicitation problems as very significant.
The requirements (need of the customer) obtained correctly and understood in its entirety solves much of the quality issues. The requirements are not only the Functional Requirements and Non-Functional Requirements of the product, but also the internal and external quality standards set by the customers/contractors to be considered
Requirements Engineering is pivotal and critical to every successful software development project. There are several reasons why software projects fail; however, poorly elicited, documented, validated, and managed requirements contribute grossly to software projects' failure.
Though a variety of techniques may be used to elicit system requirements like Brainstorming, Questionnaire, Group Discussions, Document Analysis, interviews, Prototyping, etc, all these techniques have their own limitations. Organisation has developed different requirements elicitation techniques and kept is as guidelines in the process framework. People use such techniques which they feel appropriate for the eliciting requirements.
7.2 Defects
Quality is defined as conformance to requirements. Quality is the absence of Bug (when the software does not perform as expected), Defect (When the software has an undesirable feature), and Error (when the software deviates from a correction value). In software engineering, the words Defect, Bug, and Error are interchangeably used though the ultimate consequence is the same. In this paper “Defect” is used as a common word for all three types.
Whatever has been asked by the customer or user, giving the same in its entirety is Quality. The product or application delivered should satisfy the purpose. So, understanding the requirement is key to developing the product/application without defects. Without a thorough understanding of the requirements, the defects injection increase multi-fold challenging the quality and stability of the product and in an increased failure and maintenance cost.
As customer needs keep on increasing and changing, the application or the product required to meet these will be more complex. If the application or product is more sensitive (say a medical product or aerospace application), the defects will be very damaging
7.3 Shift Left
Shift Left is a simple but powerful concept of uncovering all the defects upfront in the development lifecycle itself. In simple words Shift Left concepts guide you to detect the defects early and over a period to prevent the defects. It is used in Software testing as it attempts to move the validation upfront in the lifecycle, however in this paper the concept of Shift Left is used for the process, i.e., preventing the defects through strong process coupled with techniques. Detecting defects early and preventing them is most crucial at the same time the most neglected activity in any software organization. This is because the rework has been institutionalized as normal work in many organizations.
Defect Fix is always a non-value added (NVA) activity and it should be avoided to the maximum extent. Using the Shift Left concept a big chunk of NVA can be eliminated. The key to successful project delivery is to invest early in preventive activities which will minimize rework and the risk of downstream business impact
In software development, the defects are injected in Requirements, Design, and coding phases. The cost of defect removal increases exponentially as the development lifecycle progresses. In addition, later the defects are found and fixed, the greater the risk to the business they pose.
The objective of Shift left is concentrate on left side of the Lifecyle i.e. instead of deducting the defects in testing and production, move to left and prevent the defects during the defect injection stage itself. This will bring more product stability and overall cost reduction. Shift left initiatives will have a positive impact in reducing the Total cost of Quality.