Search for a command to run...
As a student, I combine the worlds of learning and blogging. With a thirst for knowledge and a will for writing, I share my notes through engaging blogs. These are the long boring lectures of my life I have survived through that I have summarized to you with a pinch of salt.
No comments yet. Be the first to comment.
Computer system failures are a common issue, with computers crashing or malfunctioning unexpectedly. This often leads to mistrust in personal computers. The dependability of a computer system refers to its trustworthiness, indicating the user's confi...
With the increasing integration of computer systems into various aspects of our lives, the repercussions of system and software failures are growing. Failures, such as server software malfunction in e-commerce or errors in embedded control systems in...
User or customer testing is a crucial stage in the testing process where users or customers provide input and feedback on the system being tested. It can involve formal testing of a system commissioned from an external supplier or an informal process...
Release testing is the process of testing a particular release of a system that is intended for use outside of the development team. Normally, the system release is for customers and users. In a complex project, however, the release could be for othe...
Test-driven development (TDD) is a programming methodology where testing and code development are interleaved. It involves incrementally developing code alongside corresponding tests, ensuring that each increment of code passes its respective test be...
Require elicitation is the process of gathering and defining the requirements for a software system. The goal of requirement elicitation is to ensure that the software development process is based on a clear and comprehensive understanding of customer needs and requirements.
Requirement elicitation involves stakeholders from this different area of organisation, including business owners, end users and technical experts. The output of the requirement elicitation process is a set of clear, concise and well-defined requirements that serve as the basis for the design and development of the software system.
In this activity software engineers work with customers and system end users to find out about the application domain, what service the system provides, the requirement performance of the system and hardware constraints.
Requirement elicitation Involves the identification collection analysis and is typically performed at the beginning of the project
The process model of elicitation and analysis process has each organisation with its version, or installation of the general model, depending on local factors such as the expertise of the staff, type of system being developed, standards used, etc
The process activities are
Requirement discovery:- this is the process of interacting with the stakeholder of the system to discover their requirements. Domain requirements from stakeholders and documentation are also discovered during this activity.
Requirement classification and organisation:- this activity takes the unstructured collection of requirements, groups related requirements and organises them into coherent clusters. The most common way of organising requirements is to use a model of a system architecture to identify subsystems and to associate requirements with each subsystem.
Requirement, prioritisation and negotiation:- this activity is concerned with prioritising requirements and finding the resolving requirement conflicts through negotiation. Usually, stakeholders have to meet to resolve differences and agree on compromise requirements
Requirement specification:- here the requirements are documented and input into the next round of the spiral. This involves formal as well as informal requirements being gathered through various techniques.
Requirement elicitation and analysis are performed in various methods:-
Interviews:-
The objective of conducting interviews is to understand the customer expectations from the software.
It is impossible to interview every stakeholder. Hence, a representative from their group is selected depending on their credibility and expertise
Interviews can be open-ended or structured. Open-ended interviews involve no preset agenda and context-free questions asked to understand the problems roughly. Structure interview involves discussion over an agenda, which is a fairly open question specifically prepared for a professional conversation.
Brainstorming sessions:-
A kind of group discussion, which leads to ideas very quickly and helps to promote creative thinking
Very popular nowadays, and being used in most organisations
Every idea is documented so everyone can see it
It is intended to generate a lot of new ideas, hence providing a platform to share views.
Finally, a document is prepared, which consists of a list of requirements and their priority if possible.
Facilitated application specification technique(FAST):-
Its objective is to bridge the expected gap. And the difference between what developers think are supposed to build and what customers think they are going to get
A team-oriented approach is developed for requirement gathering.
Each attendee is asked to make a list of objects that are part of an environment that the system surrounds, produced by the system, and used by the system.
The approach was mainly accepted to avoid confusion and misunderstanding during the requirement gathering process.
Quality function deployment:-
In this technique, customer satisfaction is the prime concern. Hence, it emphasises sound requirements, which are valuable to the customer.
The quality function development is further divided into three types-
Normal requirement
Expected requirement
Exciting requirement
Use case approach:-
This technique combines text and pictures to provide a better understanding of the requirement.
The use case, Describes the ‘what’ of a system and not ‘how’ only gives a functional view of the system.
The component of the use case design includes major things like an actor, use case and use case diagram.
The use case approach is documented using high-level use case diagrams. These diagrams represent all of the possible interactions that will be described in the system requirements documentation.
Scenario:-
Scenario-based elicitation involves working with stakeholders to identify scenarios and to capture details to be included in those scenarios
Scenarios may be written as text, supplemented by diagrams, screenshots or a mindful thought.
Each scenario usually covers one or a small number of possible interactions different forms of scenarios are developed, and they provide different types of information at different levels of detail about the system.
Ethnography:-
Ethnography is an observational technique that can be used to understand operational processes and help derive support requirements from these processes.
Ethnography informs the development of the prototype so that fewer prototype refinement cycles are required.
Ethnographic studies can reveal critical process details that are often missed by other requirement elicitation techniques However, because of its focus on the end user, the approach is not always appropriate for discovering organisational or domain requirements.
Features of requirement elicitation and analysis are:-
Stakeholder engagement:- requirement elicitation involves engaging all stakeholders to understand needs and requirement engineering.
Gathering information:- this involves gathering and collecting statistical analysis Of the data during discussion.
Validation and verification:- here. The data acquired during the discussion goes from validation and verification cheques.
Iterative process:-- elicitation is an iterative process that continues refining and updating the required document based on feedback from stakeholders
Flexibility:- elicitation adapts flexibility to changing requirements from stakeholders' needs and project constraints.
Requirement prioritisation:- the data gathered during the discussion is segregated into important and non-important topics. where the data is prioritised and given ranking which should be implemented first.
Communication and collaboration:- successful communication leads to a successful collaboration between developers and customers.
Requirement documentation:-a rough documentation is done during discussion which later is converted into a professionally drafted document.
This is all about requirement elicitation and analysis, we will learn about Requirement validation and Requirement management in the next blog.
