Expand the phases of software requirement

gathering in to different categories

By
Saba shahzadi
Roll No.432505
Session 2018-2020

Department of Computer Science Government

College University
Faisalabad
 Dedication

I am dedicated this thesis on my respected teachers and my parents. I thank to all their support and
coordinate me for my research work throughout the time during work.

i
 Declaration

Accordingly, I declare that this article is an original work prepared by myself. Within the scope of this work,
all sources, references and excerpts or excerpts have been correctly introduced, and the rest are listed in the
full references of the source. This thesis represents my work since studying for a master's degree. And this
institution or any other institution has not previously been included in the thesis submitted for a degree,
diploma or other qualifications. I have read the university’s current research ethics code And I have the
responsibility to follow the procedures of the university committee. I am trying to determine all the risks
associated with this research, which may arise when conducting this research.

ii
 ACKNOWLEDGMENTS

First of all I want to thank ALLAH, The Most Beneficent and The Most Merciful, who give me
the strength, peace of mind for work hard and good health to finish my research work. I highly
greateful to ALLAH for this blessing and support without his support I cannot do anything in my
life. I also pray gratitude to my all teachers of department of computer science. They all are so
valuable person because their help, motivation and guidance always move me forwards towards
the success. I sincerely pay my gratitude to my supervisor who gave me a chance to work under
his supervision and gave me his precious time for this thesis work. As we know sharing is caring
my all class felloes share information, creative approaches for my research work. Thank you so
much all of you. I want to thank many people who have contributed to my degree and the work
of this thesis. Again, this means you have to spend some time on these processes. For their
participation in the thesis committee, as well as their evaluation and feedback. Finally, I want to
thank my parents for their firm support and continuous encouragement during my years of study
and the research and writing of this article. You will always be by my side without them, it is
impossible to achieve success.
Thank you
Saba Shahzadi

iii
 ABSTRACT

The improving the quality of software products is an ideal attribute that requires hard work to
achieve the quality of the product. For this purpose divide the customer into two categories who
have knowledge about computer system and software or who did not know anything about
computer and create aware to use software for their business better performance and expand the
process of gathering actual requirements. It describes how to gather actual requirement by using
different method and different type of customers. Two types of software are developed on the
basis of requirements gathered. One is customized software and other is general software which
is developed. It is the most beneficial for all the users of software. Needs are capabilities that
should fit the product or service. In the case of serious consideration of engineering
requirements, software is the backbone of the project. Ambiguous and unrealistic requirements
are the main source of software system failures.
The requirements engineering process is complex, Because most of the required engineering
documents are written in natural language, their format is not formal and usually appeals to
designers and developers. Requirements management is the life process of a project, including
documentation, analysis and determination of requirements. and setting priorities, and finally
overcoming changes. Important issues related to demand management are usually social,
political, and cultural. Software requirements engineers who collect requirements usually think
that such matters are not in their professional scope, because they think that these matters fall
within the scope of project management. In this study, we focused on the management problems
that emerged in the requirements engineering process and explored the possibility of solving
these problems. This research is accompanied by a rigorous review of existing processes for
solving and managing software requirements.

iv
KEYWORDS
Requirement Elicitations, stockholders, Types of requirements, Requirements Analysis, Custom
and generic software, phases of software requirements, Requirement gathering.

v
 Table of contents

Table of Contents
Chapter 1 .......................................................................................................................................................................1
Introduction ...................................................................................................................................................................1
Requirement Gathering: ............................................................................................................................................1
1.2 Objectives ............................................................................................................................................................3
1.3 History..................................................................................................................................................................4
1.4 Background Information ......................................................................................................................................5
1.4.1 How to: .........................................................................................................................................................5
1.4.2 Orthogonal View: .........................................................................................................................................5
1.4.3 Software Architecture: ..................................................................................................................................6
1.4.4 Important and Additional Processes.............................................................................................................6
1.5 Feasibility Study ..................................................................................................................................................6
1.6 Scope of Study .....................................................................................................................................................7
1.7 Problem Statement..............................................................................................................................................8
1.8 Proposed Solution................................................................................................................................................8
1.9 Expand the Phases of Software Requirement Gathering into Different Categories .............................................8
1.10 Requirements Elicitation ...................................................................................................................................9
1.10.1 Requirement Elicitation Method: ..............................................................................................................10
1.10.2 Requirement Analysis ...............................................................................................................................11
1.10.3 Requirement Analysis Method: ................................................................................................................11
1.11 What is SDLC ..................................................................................................................................................12
Chapter#2 ....................................................................................................................................................................14
Literature Review ........................................................................................................................................................14
Chapter#3 ....................................................................................................................................................................19
Methodology................................................................................................................................................................19
3. Methodology of Requirement Gathering ................................................................................................................20
3.1 Techniques for demand gathering:.....................................................................................................................22
3.2 Techniques Requirement Gathering from Second Type of Customers: ............................................................23
3.2.1 Customize Software: ...................................................................................................................................23
3.2.2 Generic Software: .......................................................................................................................................23
3.2.3 Techniques Requirement Gathering from Second Type of Customers: .....................................................25
3.6 Submit the Required Technology for Software Development: ..........................................................................25
3.7 Use Case Diagram: ............................................................................................................................................27
3.7.1 Each Use Case Has Three Basic Elements: ................................................................................................27
3.7.2 Characteristics of Use Cases .......................................................................................................................28

vi
 3.7.3 There are Two Different Types of Usage. ...................................................................................................28
Business use and system use issues .....................................................................................................................28
3.7.4 Examples of Use Cases ................................................................................................................................29
3.7.5 Brainstorming .............................................................................................................................................30
3.8 Different Phases for Requirements ...................................................................................................................31
3.9 Research Methodology ......................................................................................................................................33
3.10 Detects Defect in Requirement Gathering: .....................................................................................................33
Chapter#4 ....................................................................................................................................................................35
Applications of Software Requirement Gathering.......................................................................................................35
4.1 Software Engineering Application .....................................................................................................................36
4.1.1 Application Areas: ......................................................................................................................................36
4.2 Review Software Requests ................................................................................................................................36
4.2.1 Real-time System and Software ..................................................................................................................36
4.2.2 Technical Field ............................................................................................................................................37
4.4.3 Commercial Software .................................................................................................................................37
4.4 Embedded Software ..........................................................................................................................................38
4.5 The Invention is Suitable for the Design ............................................................................................................40
4.6 Background Art .................................................................................................................................................40
4.7 Types of requirements .......................................................................................................................................41
4.7.1 Functional Requirements............................................................................................................................42
4.7. 2 Passive Requirements (NFR) ......................................................................................................................43
4.7.3 Non Functional Requirement Method:.......................................................................................................44
Chapter#5 ....................................................................................................................................................................47
Results and Analysis.....................................................................................................................................................47
5 .Analysis ....................................................................................................................................................................47
5.1 Software requirements prioritization ................................................................................................................47
5.1.1 Requirements prioritization challenges.......................................................................................................47
5.1.2 Requirement Prioritization Method: ...........................................................................................................48
5.1.4 Method of Development Trends: ...............................................................................................................49
5.2 Software method Models and Analysis on Failure of computer code Development comes ..............................50
5.2.1 Method and system for analysis of software system necessities ...............................................................50
5.4 Traditional needs Landscaping Collection .........................................................................................................52
5.5 Waterfall Model .................................................................................................................................................53
5.6.1 Agile Methodologies summary ...................................................................................................................54
5.6.2 Agile Methodologies Frameworks ..............................................................................................................55
5.7 Custom Software Development .........................................................................................................................55
5.8 Custom Software method: .................................................................................................................................57

vii
 5.9 Generic software ................................................................................................................................................57
Chapter#6 ....................................................................................................................................................................60
Analytical Review of Requirement Gathering .............................................................................................................60
6 .Analysis Overview ..................................................................................................................................................60
6.1 Software Life Cycle ...........................................................................................................................................60
6.2 Detailed Language .............................................................................................................................................61
6.4 A Common Use of Formal ................................................................................................................................63
6.3 Leads to a More Detailed Description. ..............................................................................................................64
6.5 Clause: ...............................................................................................................................................................65
6.6 The Concept Of Is Interdisciplinary Research Infrastructure: ...........................................................................69
6.6.1 Speed Up the Calculation: ..........................................................................................................................70
6.7 Submission Requirements (Data and Process ....................................................................................................71
6.7.1 Analyst Qualifications ................................................................................................................................71
6.7.2 Explain the Customer’s Business Needs .....................................................................................................72
6.8 Technology to Discover Business Needs:..........................................................................................................77
6.8.1 Customer Travel Map .................................................................................................................................77
6.8.2The same is true for Customer Relationships. .............................................................................................77
6.9 Online Survey: ...................................................................................................................................................79
CHAPTER#7 ...............................................................................................................................................................81
Conclusion and References..........................................................................................................................................81
Conclusion ...................................................................................................................................................................81
[Link] ..................................................................................................................................................82
7.1 Case study ..........................................................................................................................................................84
7.2 Acceptance Test/Criteria ...................................................................................................................................85
7.3 Extreme Programming .......................................................................................................................................86
References .....................................................................................................................................................................1

viii
 LIST OF FIGURES

Fig no Fig name Page: no

Fig:1.1 Requirement Elicitation 10
Fig:1.2 Requirement Analysis 11
Fig:3.1 Methodology 19
Fig:3.2 User Story Mapping 26
Fig:3.3 Use Case Daigram 27
Fig:3.4 Use Case 29
Fig:3.5 SDLC Cycle 33
Fig:3.6 Distributed Defects 34
Fig:4.1 Business Software 37
Fig:4.2 Embedded Software 38
Fig:4.3 Background Art 41
Fig:4.4 Non Functional 44
Fig:5.1 Requirement 48
Prioritization
Fig:5.2 Development Trends 49
Fig:5.3 Agile Methodology 54
Fig:5.4 Custom Software 56
Fig:5.5 Generic Software 58
Fig:6.1 Analytical Gathering 63

ix
Chapter 1

Introduction
Requirement Gathering:
Software needs function a baseline for any computer code project and are unit thought-
about capability or condition to that a system should adapt Run. I alternative words, needs
evocation is that Ability or operate. The employment of computer code is common day by day
and customers that require computer code for his or her business development and advantages
area unit increase in computer code house, free-lancing bank note etc. However this WHO le
system solely entertain those persons who regarding |realize |understand comprehend |fathom}
laptop or computer code people who don’t apprehend they tell his friends or any individual that
apprehend one thing about laptop computer code and he got his commission and sale computer
code to it one that don’t comprehend computer code. Create awareness to use computer code
each client that require computer code guide him and tell the advantages of usage of computer
code is also one person return to you that didn't comprehend laptop computer code after we
guide him everything he raise his friends that not comprehend laptop computer code and it
increase day by day that 2 styles of customers return to want computer code. Within the 1st
introduced agile model by jim high smith.
Agile model is employed to develop computer code with completely different techniques or
points.
• Used for important application.
• Used in organization that worker discipline technique sometimes less formal and reduced
scope. All data gathered from well-known and unknown customers, well-known implies that
WHO apprehend the pc technology utterly and unknown person is that WHO doesn't apprehend
the computers in any respect and that they don't have any plan regarding something of
computers. However they additionally create the some computer code or laptop facility, so that
they also are want some laptop work that they're implement on them. So technique that may be
applied for collection the need from unknown and well-known customers .The information that
area unit collected from customers from 2 varieties area unit completely different, well-known
individuals decide the concept quickly and no want for thus rationalization thoroughly, whereas

1
the unknown person or customers want a too additional data a minimum of that they perceive
simply then they work on this computer code or laptop instrumentality. Systems development
there's Associate in nursing increasing want for ways ability to prioritize candidates’ necessities.
as reason embrace That's not all necessities will sometimes be met with offered Time and
resource constraints that the shoppers to bigger limit area unit rigorous System configuration
foremost Fight for the deer, or those necessities should be allotted to totally Various issuances.
Economical and trust and trustworthiness ways priority necessities area unit so
powerfully Practitioners’ needs are a promising framework that Cost-value method. I
exploitation this approach, This way call manufacturers area unit given pointers on the way to
place the wants supported their relationships useful to value Implementation. It provides paper
Associate in nursing Survey six candidates’ ways Prioritizing requirements: analyzing and
categorizing method (AHP), classification AHP, extended tree matrix, bubble type, binary search
tree and priority teams. These ways will it can be used as a complete utility, or it can be used
from a price-value perspective. To test these methods, we have a tendency to consistently apply
all ways to place thirteen Clear quality necessities on a little telephone system. In call
manufacturers Comparison of paired wars wants to see that of the 2 is additional necessary, and
to what extent. In industrial comes, this approach has been seasoned as being effective, correct
and conjointly to yield informative and trustworthy result. Most likely even additional necessary,
having used the approach in many business comes, we've seasoned that practitioners area unit
terribly Comparison of paired wars still use it in different comes. Although very positive
expertise, AHP includes a basic disadvantage this is an obstacle to industrialization.
Since all unique requirement pairs must be compared, the work required may be sufficient. In
small development projects, this growth rate is acceptable, but in large development projects, the
work required may be very high. As far as we know, AHP is only used in a few applications in
the software industry. For example, Finnie and others prioritize software development factors
Used AHP He found that AHP was relatively easy to apply, but did not explain the problems that
would arise if the number of priorities increased. Other AHP applications include Delegates and
Pereira's research on telecommunications standards, and Carlson's software requirements in
business development projects. In these cases, the number of priority items is very small, and the
number of pair comparisons required will not cause irregular difficulties in the process. Since
AHP's large-scale project. This may be problematic, so we have identified five complementary

2
methods to challenge AHP. All of these methods involve pairwise comparisons, because
previous research has shown that making relevant decisions is faster, and making clearer
decisions produces more reliable results. We focus on ways to reduce the amount of work
required, but still provide high-quality results that our users consider reliable

1.2 Objectives
To help purchasers and developers manage the method of necessities gathering, we have a
tendency to advocate these five steps:
• Step 1: Behind the pain the necessity
• Step 2: Eliminate language ambiguity
Step 3: Identify extreme situations
•Step 4: Write a user case
Step 5: Develop a definition
“Done” The purpose of necessities gathering is to gather as several illustrious necessities as
potential. The method of necessities gathering is each vital and troublesome. Necessities area
unit thought-about before the event of the code. the necessities, that area unit normally thought-
about, area unit classified into 3 classes, namely, useful necessities, non-functional necessities,
and domain necessities. An honest demand states one thing that's necessary, verifiable, and
come-at-able. Although it's verifiable and come-at-able, and eloquently written, if it's not
necessary, it's not an honest demand. an honest demand ought to be clearly expressed.
• Elicitation. The induction step is wherever the necessities area unit 1st gathered
• Validation. The Validation step is wherever the “analyzing” starts Analysts prefer and
formally document documents necessities in a very necessities Appreciation report. Higher |a far
better |a much better |a higher |a stronger a more robust |an improved} understanding of the
factors that have an effect on the event of code and their interrelationships is needed so as to
realize Better understand the basics. The Code Engineering Laboratory was established in
August 1976 at National Aeronautics and {space Administration |NASA |independent agency}
Robert Hutchings Goddard will work with the Space Flight Center at the University of Maryland
to bring this understanding to the market. The next section outlines the goals and experiments in
the laboratory. The third section contains a list of current projects that have an effect on the code
development method or product and area unit to be studied or neutral. Knowledge the info the

3
information} assortment and data management activities area unit mentioned. The last part of the
fourth part contains information about the current state of the laboratory and future plans.

1.3 History
In the history of SE, at the time of writing (April 2010) it was not a wise move until 1989.
Then, I made sure it was lost. The most important date in the history of software systems
engineering is: 1968: international organization Software System Engineering Conference.
Published Digestra's statement on the dangers of participating in the event. The development of
the concept of manual programming in the early seventies. Publish old papers about concealing
information. Pascal artificial language development. The development of gossip language
introduced the concept of object-based development. In the late 1970s began to use software
system style strategies, such as the formation of Tirade and Constantine. Develop the first
programming environment. In the early eighties. The development of adenosine eliminated the
meaning of artificial language, including artificial programming and data hiding. The software
system engineering environment prompted the introduction of the CASE tool to support this
strategy. Develop iterative methods for cost accounting and estimation of software systems. 1 1
of this book | The first student edition is released because the software is the first textbook for
students majoring in systems engineering. Use object-oriented programming in the late 1980s
through languages like C++ and Objective-C. Introduction of object-oriented style strategies. in
depth Use the CASE tool. In the early nineties. Object-based development becomes a deliberate
development technique. Requires entry into the industrial tool market to support engineering.
Java was developed and released in the late 1990s and mid-1990s. More and more attention is
paid to software system design concepts. The client-server distributed architecture is slow to use.
The concept of component-based software system engineering is introduced. Unified language
projected, group action many severally developed notations for representing object-oriented
systems. For various reasons, REH practitioners and researchers have basically ignored politics
for many years. Although many of the resources we are using here are not new, we believe that
we still need to focus immediately on the fundamental issue, namely how and why the
requirements work. Over the years, engineers have changed. The aim is to improve the
understanding of current role professionals and educators compared with currently available
theories and explanatory tools and models, and to prevent any future development of the
discipline. For various reasons, RE practitioners and researchers have basically ignored politics

4
for many years. Although many of the resources we use here are not recent, we claim that there
is still an urgent need to solve the underlying problem. This article is the first public broadcast of
an extensive ongoing research project to understand how and why the role of engineer needs has
changed over the years. Our goal in this work is to improve the understanding of current role
professionals and educators by providing better concepts and explanatory tools and models than
currently available, and to address the future development of the discipline. Over the years,
customers and practitioners have proposed many different methods and methods to easily answer
complex questions. Although it may seem offensive to classify agile methods as one of the
answers below, we observe Now, sometimes the focus is on short software interactions and user
engagement as the best approach (and the closest panacea) to modern software development
practices. Although some progress has been made, software practitioners are still a long way
from mastering the methods of eliminating, analyzing and verifying requirements and satisfying
all parties. Research by Standesh Group (1995).Stimulus is the beginning of the development of
demand. The choice is to collect and explore requirements from stakeholders and other sources.
Different technologies can be used, such as shared application style (JAD) sessions, interviews,
document analysis, focus groups, etc. Stimulus is the beginning of the development of demand.

1.4 Background Information

In the previous study of requirement gathering, Data collection technology The purpose
of fact discovery technology is to determine the information requirements of the organization
used by analysts in order to develop an accurate SRS that users can perceive. Resolve potential
disputes between users and analysts. Use graphical aids to make it easier to understand and
design. The process of collecting, analyzing and recording software requirements from the client
is called requirements engineering.

1.4.1 How to:

The software engineering task system bridges the gap between engineering and software design
requirements.

1.4.2 Orthogonal View:

The software designer provides its model:
• System information (static view)
Function (function view)

5
• Behavior (dynamic view)

1.4.3 Software Architecture:

Models can be transformed into data, architecture and component-level design.

1.4.4 Important and Additional Processes

Do some design during the analysis process, do some analysis during the design process
We gift a private perspective of the Art of Programming. we have a tendency to begin Its state
can be traced back to the 1960s and continues to this day. After a conference in 1968, the term
software engineering became legendary. Do a little analysis .When clearly mentioning the
difficulties and shortcomings of planning a complex system. Start looking for a solution. He
focuses on advanced methods and tools. The most outstanding programming languages represent
process, modularity, and then object-oriented design. Software systems engineering is dedicated
to their emergence and improvement. Usually important planning work, even the automation and
testing of program documentation. Finally, it intends to replace analytical verification and
accuracy proof testing. Recently, the increase in computing power has allowed computing to be
used for more difficult tasks. This trend has greatly increased the demand for software system
engineers. Programs and systems become complicated, and it is impossible to fully understand
them. Sunk costs and large amounts of computing resources inevitably reduce reasonable
maintenance. The quality seems to be too high, which makes it into a profitable competition.
However, we must always worry about quality degradation due to quality. Our boundaries are no
longer gradually expanded by hardware, but by our own intellectual capabilities. With
professional knowledge, we all know that most programs can be significantly improved, many of
which are reliable, economical and easy to use. The Nineteen Sixties Moreover, the beginning of
software systems engineering is also unfortunate, because people who usually use computers
have little historical interest in the subject. As a result, many ideas and concepts are promoted
and advertised as new things. Such ideas and concepts have been going on for decades, and may
even be under a specific term. i feel it price whereas to often pay it slow to think about the past
and to research however terms and ideas originated.

1.5 Feasibility Study

When customers contact the organization to develop the products they need, they have an idea
of what the software should do and what functions the software should have.

6
With reference to this information, the analyst conducted a detailed study on whether it is
possible to develop the required system and its functions.
The purpose of the feasibility study is to achieve the goals of the organization. This research
analyzes whether software products can be put into practice from the aspects of implementation,
project participation in the organization, cost constraints, and the value and goals of the
organization. Explore the technical aspects of the project and product, such as usability,
retention, productivity, and integration capabilities.
The production at this stage should include a feasibility study report with appropriate
management opinions and suggestions. Whether the project should be started Requirements
analysis focuses on meeting the tasks of potential or different stakeholders to meet new or
modified product or project requirements, while taking into account potential conflicting
requirements, analysis, documentation, verification and management software.

1.6 Scope of Study

Scope of demand gathering is incredibly wide as a result of it's a most elementary step towards
the coordination among customer’s and code developers. Higher coordination’s square measure
important between the users and developers .Project scoping for options and utilities in order to
achieve the objectives of the option system is critical to the success of the project. For a long
time, the system's commitment to code development has been a challenge that practitioners are
trying to overcome. Therefore, it is important to understand the reasons and implications of the
poor scope of the project. This study puts forward the survey results about the scope of the
project, the survey results affect the need to affect the demand, and thus affect the general
requirements of the project. Summarized the reasons for the difficulty of this range and the
square measure of coherent results.
Challenges caused by poor range square measurement includes causality diagrams at work. The
strategies provided by this study can help practitioners find areas that can have a positive impact
on expanding the scope of decision-making projects. general needs stimulus method. This study
of demand gathering is that everyone necessary conditions could also be resolve throughout the
expand the phases of needs that holds all systematic conditions square measure like or resolve.
Some users or customers don't seem to perceive the complexities of comes and that they square
measure hesitated to resolve it or declare it .This are the most issue of any code developers
throughout the need gathering

7
1.7 Problem Statement
In the past there is no way to collect the information from users in a better way. In fact there
is no way to collect a requirement for who’s persons that don’t know the computer software at all
and those person that know the little bit information about computers. Different categories
whereas custom software or generic software are used to user benefits and increase the
requirement gathering process. In this process collects the information or requirements from the
users about both of this type of customers. Different ways to collect the information for two type
of customers. But in the past there is no way to collect requirement at all. Development and
benefits are increase in software house, free-lancing fiver etc but this system only entertain those
persons who know about computer or software’s.

1.8 Proposed Solution

The above problem is that the early software requirement method is that there is no way to
collect better requirement gathered for all the customers especially two categories those who
don’t know software and those who know the little bit information about computer .For resolving
this expand the phases of requirement gathering that collects the requirement or information
from all types of customers. Those who give the knowledge independently and those who don’t
give the requirement independently. Some customers have no idea about her /his software
requirement but they need to use it. So doing this expand the phases of requirement gathering.

1.9 Expand the Phases of Software Requirement Gathering into Different

Categories
It implies that there's no thanks to resolve the matter of consumers that they're not clear the
strain and desired to the code developers. This is often the fundamental supply of gathering the
need from the users to resolve the matter of any kind because of best reasoning of data.
Requirement engineering method provides importance to the System and algorithm technology
to ensure system integrity, consistency and consistency demand. Therefore demand plays a
serious and key role in advanced system development. All info gathered from notable and
unknown customers, notable implies that UN agency grasps the pc technology fully and
unknown person is that UN agency doesn't grasp the computers in the least and that they don't
have any plan concerning something of computers. However they additionally create the some
code or laptop deposit, so that they also are want some laptop work that they're implement on
them. thus technique that may be applied for grouping the need from unknown and notable

8
customers .The information that area unit collected from customers from 2 varieties area unit
completely different, notable folks decide the thought quickly and no want for therefore
rationalization very well, whereas the unknown person or customers want a too a lot of info a
minimum of that they perceive simply and so they work on this code or laptop
instrumentality. Requirements play a very important role in the development of engineering
code. If in some way, this part goes wrong, the entire project may fail. According to multiple
studies on this issue, this is the main reason for the failure of the project. Because of using
dangerous needs engineering practices. It’s been according that seventieth of the systems errors
area unit usually because of the improper needs and remaining half-hour area unit attributable to
the planning The error article is divided into four parts. This section introduces demand
management issues. The next part of this section summarizes the literary criticism of time, which
requires engineering problems and methods. The evaluation and comparison of these
technologies are described in the third part, and finally, we reached the conclusion in the last
part. Info area unit gathered for downside finding method to extend the capabilities of code to
resolve the problem of demand gathering.

1.10 Requirements Elicitation

Demand motivation aims to meet demand and set system boundaries through negotiation with
stakeholders (such as customers, developers, and consumers). The boundary of the system
outlines the context of the system. Understand the field of tools, business requirements, system
obstacles, and stakeholders, and therefore reach a consensus on the development of the system
itself. The most important technology. for necessities stimulant square measure delineate within
the remainder of this section. Lay to rest views Inter viewing may be a technique for
locating Facts and opinions command By potential customers and alternative Stakeholders in the
system being developed. Mistakes and misunderstandings will be discovered and eliminated.
Square measure 2 completely different interview format closed interview, wherever the wants
engineer encompasses a pre-defined set of queries and is trying to find answers.
• The open interview, {without associate |with none} pre-defined queries the wants engineer and
stakeholders discuss in an open-ended means what they expect from a system. In fact, there's no
distinct boundary between each forms of interviews. you begin with some queries that square
measure mentioned and result in new queries. The advantage of interviews is that they help to
perform expensive rankings on developer data. Their disadvantage is that it is difficult to master

9
such a large amount of qualitative knowledge, and completely different stakeholders can provide
conflicting data.

Fig:1.1 Requirement Elicitation

1.10.1 Requirement Elicitation Method:

Requirements engineering (RE) can be said to be a set of activities that can help us discover and
communicate the requirements, purpose, and context of the system. The RE process begins with
the submission of requirements descriptions. The failure of most software projects is an
important factor in correctly capturing system requirements. In this article, an analysis of the data
collected by practitioners is provided. From the results of the data and the discussion of the
results to election techniques
Mode pattern leads to extraction guide. We have also put forward an effective plan to eliminate
these requirements, aimed at overcoming the obstacles faced by practitioners. In the course of the
project, individuals and software developers identify different characteristics in three main areas,
which can affect the outcome of the alternative process. Second, we created three independent p-
metrics (3 ppm) for each dimension, showing the relationship between the three dimensions of a
specific technology and software. We provide surveying and mapping standards and use them to
select a subset of expertise. We use case studies to demonstrate the application of the proposed
method to review and provide relevant knowledge about the selection of elimination techniques.

1.10.2 Requirement Analysis

Demand analysis needs (demand), consistency (demand should not be contradictory),
fulfillment (no service or interruption) and feasibility (depending on the budget and the available

10
budget and the availability of the schedule). Resolve demand disputes through priority
negotiation with stakeholders. Prioritize controversial needs to identify important needs.
Determine the solution to the requirements and achieve the requirements. The key techniques
used to analyze requirements are JAD sessions, prioritization and modeling. Joint Application
Development (JAD) is a group meeting (or seminar) with a system analysis method. During the
JAD session, developers and consumers discuss the features of the desired product.
This type of discussion will be very useful if the person in charge of the meeting prevents
participants from "walking". The purpose of JAD is to define a specific project at various levels
of detail, design a solution and monitor the completion of the project. JAD promotes
cooperation, understanding and teamwork between different participant groups. Since
participants must come from different backgrounds, it is possible to collect and consider
information about different parts of the new system and provide a basis for further needs.

Fig:1.2 Requirement Analysis

1.10.3 Requirement Analysis Method:

Requirements analysis is the process of defining user expectations for the application to be built
or modified. This includes all the work that needs to be done to determine the needs of different
stakeholders. carry out. Therefore, requirements analysis means analyzing, recording, verifying,
and managing software or system requirements. Documented, feasible, able to identify high-
quality requirements when identifying business opportunities. Described to promote measurable,
measurable, testable, identifiable, and system design.
1. Eliminate demand
2. Analyze requirements

11
3. Modeling requirements
Review. Looking back and before
Eliminate the need
The process of collecting demand through interaction with consumers is called selective demand.
2- Analyze requirements
This measure helps to set the required standards. This includes determining whether the
requirements are vague, incomplete, ambiguous and contradictory. These issues have been
resolved before proceeding to the next step.
3- Modeling requirements
In modeling requirements, requirements are usually recorded in various forms, such as usage
questions, user stories, natural language documents, or process details.
4- review and frustration
This process is designed to reflect the need to improve the process.
1.11 What is SDLC?
SDLC is a systematic process used to build software to ensure the quality and accuracy of the
built software. The SDLC process aims to develop high-quality software that meets customer
expectations. System development must be completed within the default time limit and cost. The
SDLC contains a detailed plan that outlines how to plan, build, and maintain specific software.
Each stage of the SDLC life cycle has its own process and supply, and can enter the next stage.
SDLC stands for software development life cycle, also known as application development life
cycle.
Step 1: Requirements collection and analysis
Step 2: Feasibility study
Speed up Step 3: Design
Step 4: Coding
Step 5: Check
Step 6: Installation/Deployment
Step 7: Restore
Project It provides the basis for project planning, planning and estimation
Activities provide a framework for a series of activities and delivery standard

12
Project this is a way to track and control projects. The project improves the visibility of the
project plan to all stakeholders involved in the development process
Speed up the pace of development
Better customer relationship with customers
Minimize project risk and project management plan

13
Chapter#2

Literature Review

Lu et al. (2007) examine that the requirements document proposes an innovative technology
to resolve ambiguities and outlines a model called model-based object requirements engineering
(MORE). The author concludes that while using modeling and object-based technology, useful
information can be collected Domain information. Requirements for the quality stage of the
project.
Separovicand Car. (2003) examine that Proposal to manage the process model of the software
requirements of the old system. The main reasons behind any failed projects in this study are
related to the definition of incomplete requirements and the adoption of inappropriate
requirements. The conclusion is that the requirements management team should be composed of
system architects (for system architecture design), end users, business domain experts, and
consultants (who should be composed). Powerful information about new technologies,
management and developers.
Lu et al.(2007) examine that Modeling can be used to gather useful domain information.
In this research Conclude that According to the requirements of the engineering standard stage,
modeling and object-oriented technology are used.
J. M. Juran and F. M. Gryna. (1970) examine that It is completely user-friendly. As a result, the
definition of software product quality is also closely related to requirements. The conclusion of
this research is that, in other words, it is quite reasonable to assume that the quality of the
software is actually the realization of the requirements.
G. Lu and F. Yuan. (2010) examine that Propose this method In order to check and describe the
requirements, the management requirements need to be changed, and the requirements analysis
stage plays an important role in this [Link] this research conclude that Conclude that In
order to check and describe the requirements, the management requirements need to be changed,
and the requirements analysis stage plays an important role in this process.
K. E. Wiegers. (2003) examine that Requirements confirmation: This is the process of ensuring
that the requirements statement is accurate, complete, and demonstrates the required quality

15
[Link] this research Conclude that The process of ensuring that the required statement
is accurate and complete, and showing the required quality.
X. Jiang,(2003) examine that The RE process is the search object that describes the RE process
and highlights the various tools and techniques used in the RER process, implying the formal
method of the RE process. They also discussed three conventional engineering processes: up and
down, middle and up and down. In this research Conclude that: The proposed method named
REPM is formal and is an integrated method composed of the above three different processes.
However, the model lacks validation and does not specify all three RE processes, which is quite
difficult.
D. Pandey, U. Suman. (2010) examine that Emphasize that it is extremely important to execute
planning phase independently to achieve an effective requirements management .Requirements
engineering process pertains to analyzing .In this research Quality-oriented requirements
engineering can not only provide assistance in the software development phase, but also improve
the quality of the software from the perspective of customers and users. Finally, the author
proposes a requirements engineering process model to efficiently assemble requirements.
E-S Lee and J-M Bae. (2007) examine his is a difficult problem that leads to defects. In this
study, the following conclusions are drawn: A chance tree is proposed to take care of defects and
provide solutions.
Nya and I. Sommerville.(1998) examine that Requirements Elicitation Distributed pair
programming is an agile software development [Link] this research Conclude that :
Requirements are obtained from system developers (such as customers, end users, and other
stakeholders).
C Murphy, D. Phung.(2008) examine that distributed pair programming is an agile software
development methodology. In this research conclude that Conclude He: Extreme Programming is
also an agile software development method, which focuses on the initial release of the software
and aims to improve the quality of the software.
J. Cheng and Q (2008) examine that Techniques that describe the prerequisites for collecting
informationIn this research Conclude He: The basic idea of this idea is to propose an effective
and reasonable framework
M. F. Tchidi and Z.(2010) examine that explains a set of practices to improve the "Six Sigma"
process. There may be six sigma For engineering process model requirements In this research

16
Conclude that The basic technique used to describe requirements is a criticism of the project, and
different techniques are needed to determine the customer’s needs.
ES Lee and J-MB (2007) examine that The product or service may meet the characteristics and
characteristics of its characteristic (FR) or strength (NFR).In this research Assuming that the
quality of the software is actually the realization of the requirements, this is quite accurate.
G .Booch , [Link] and j. rambagh (1999) examine that in additional To meet the needs of
users, the system must also perform the following joint management operations from time to
[Link] this research conclude that To meet the needs of users, the system must also perform the
following joint management operations from time to time.
D .rosenberg and K scot (2002) examine that Main ordinary actors and auxiliary extras (NNSC
type temporary status limited company).
Joachim Karlssona,et ,al(1997) Based on the quality requirements of the telephone system, the
author uses all six methods in different situations to determine the priority of each request. Then
from the user's point of view, the method was developed according to various standards. We
found that analyzing the ranking process is the most promising method, although it may be
difficult to measure. In the industrial tracking research, we used the analytical classification
process to further study its application.
Frauke Paetsch et,al(2003) examine that Compare traditional requirements with engineering
methods and dynamic software development. This article analyzes the commonalities and
differences between the two methods and identifies possible ways in which dynamic software
development requirements can benefit from engineering methods.
Micheal jet,al(2005) examine that There is a new interest in the technology of facilitating the
selection of user interface widgets or other targets of the screen through the pointing device. We
report on research on the use of goal expansion to facilitate selection. An object that expands or
expands in response to the user's attention can reduce the initial size, thereby helping to improve
the use of screen space and making it easier to select than the target. However, the selected
performance may be affected by the reduction of the initial widget size
Bingxin Kong, Siqi Liu et,al(2018) examine that The advantage of using hybrid cloud for
service providers (SP) is to improve the quality of service (QoS) of their big data applications.
However, in order to obtain the guaranteed flexibility and/or bandwidth in their hybrid cloud,
SPs may need a virtual data center (VDC) network, where they can independently manage

17
network connections and can operate. To meet this demand, we designed and implemented a
network slicing and orchestration (NSO) system, which can create and expand VDCs in the
optical/packet domain as needed.
Min chen et,al(2012) examine that In this article, we studied the process of using Directed
Geographic Routing (DGR) to construct multi-paths to propagate multimedia data, and identified
the challenging problem of achieving multi-path balance near the source/sink. The program is
divided into an expansion phase, a parallel phase and a convergence phase. It includes two key
algorithms, namely the detection algorithm and the deflection adjustment algorithm in the road
construction phase. Repeated results confirmed the effectiveness of the program.
Penixiang Li zhang Hao goeet,e et al l(2020) examine that First, it reflects both the privacy
restoration problem and the emotional strategy, and secondly, it includes isolated emotions as the
driving factor of the privacy problem. The results of an online survey (n = 605) showed that
adapting to the privacy risks of Facebook users involves a multifaceted prescription strategy for
problem, emotion, and communication. Strategies for dealing with these problems include
establishing selective relationships with people who are old in their thinking (such as scholars).
P Ranjan,AK misra et al (2006) examine that Agent-driven software development usually
encourages the development of open and adaptive systems that are evolving to meet new
demands. The proposed method is based on model-based technology and provides a specific
model for data collection and uses this model to drive user-based demand analysis, specification
and system-based analysis.
[Link],M Haris,[Link] et al (2008) examine that The most important thing in software
engineering and project management is what needs to be ignored. 80% of projects fail due to
insufficient requirements collection and poor follow-up performance. In the software
development requirements that regard the collective process as a task, the process model will be
followed. Web development with rapid iteration and rapid release mostly follows the agile
model. The pace and principles of agile development do not allow developers to maintain
sufficient capabilities
Kavitha C.R et al (2011) examine that Understanding and management are the key factors for the
success of software development. In all development methods, including agile development
methods, the necessary engineering design is an important task. There are many demand
technologies that can be used with agile development methods.

18
PRbhat ranjan and A K Misra at al (2009) examine that An agent-based open self-adaptive
system development process is proposed, which is constantly evolving and evolving to meet new
demands. The proposed method is based on a model-based technique that provides a specific
model for collecting information and uses the model to drive the analysis process in a specific
field. Emphasis is placed on a clear separation between the requirements gathering and analysis
stages.
Markus Düchting et al (2007) examine that The demand for available products is also a
growing factor for organizations. Therefore, their development process must respond to this
demand and provide appropriate methods to integrate the "usability" element into their
development process. This article examines the views provided by the Active Software
Engineering Model on how we consider available engineering activities to ensure the creation of
usable software products. Based on their availability, two agile SE models (Scrum and XP) were
analyzed, and how to fill potential gaps without losing the process was discussed.
Pamela Zave et al (1997) examine that The needs of engineering are broadly interdisciplinary
and open in nature. It threatens to transform mathematical calculations into formal real-world
observations.

19
Chapter#3

Methodology

The discussion what percentage kinds of client would like software package we tend to divided
into 2 kinds of customers one is World Health Organization |those that people WHO recognize
one thing concerning pc/software and therefore the alternative one is those that recognize one
thing concerning pc those that recognize a touch bit we tend to add that variety of an individual
who fathom pc or software package and who failed to recognize the fundamentals of computer.
Currently first deals with WHO fathom computer/software square measure discuss below the
subsequent steps use this software package for demand gathering visual paradigms.

Fig: 3.1 Methodologies

3. Methodology of Requirement Gathering

One-on-one interviews are the most common technique for gathering requirements, as well as
one of the primary sources of requirements. To help get the most out of an interview, they should
be well thought out and prepared before sitting with the interviewee. The analyst should identify
stakeholders to be interviewed.
[Link]-on-One Interviews:

21
 One-on-one interviews are the most common technique for gathering requirements, as well as
one of the primary sources of requirements. To help get the most out of an interview, they should
be well thought out and prepared before sitting with the interviewee. The analyst should identify
stakeholders to be interviewed. These can be users who interact with the current or new system,
management, project financers or anyone else that would be involved in the system. When
preparing an interview is it important to ask open-ended questions, as well as closed-ended
questions.
2. Group Interviews:
Group interviews are similar to one-on-one interview, except there is more than one person
being interviewed. Group interviews work well when the interviewees are at the same level or
position. A group interview also has an advantage when there is a time constraint. More thoughts
and discussion can be generated, as someone in the group may state or suggest an idea that may
have been overlooked by others, which in turn can lead to a discussion or provide more
information on a particular issue
3. Questionnaires/Surveys:
Questionnaires, or surveys, allow an analyst to collect information from many people in
relatively short amount of time. This is especially helpful when stakeholders are spread out
geographically, or there are dozen to hundreds of respondents whose input will be needed to help
establish system requirements. When using questionnaires, the questions should be focused and
organized by a feature or project objective. Questionnaires should be not be too long, to ensure
that users will complete them. When constructing the questionnaire, general guideline to
determine the questions would be to ask “how, where, when, who, what, and why
4. User Observation:
The direct approaches of interviewing and questionnaires provide valuable user feedback
based on the questions asked of them; however, there are times when direct observation may be
better suited in requirement gathering. To get a better understanding of a user in their in current
work environment, the analyst may observe the user themselves. User observation is helpful in
assisting the analyst by getting a full grasp of how the user interacts with the system, firsthand.
When the objective is to improve a task, the analyst can observe the user and how their
surroundings affect their interaction with the system. Sometimes stakeholders may find it
difficult in explaining what exactly what their tasks consists of and what their requirements may

22
be, observing the user in cases like these will help provide the requirements. User observation
may also be useful in validating data that had been previously collected. Be it in cases where
users provide misleading information, or cannot fully recollect all of their tasks in how they use
the system.
5. Analyzing Existing Documents
Analyzing existing documents can prove to be a useful technique in requirement gathering, on
its own as well using it to supplement other techniques. Reviewing the current process and
documentation can help the analyst understand the business, or system, and its current situation.
Existing documentation will provide the analyst the titles and names of stakeholders who are
involved with the system. This will help the analyst formulate questions for interviews or
questionnaires to ask of stakeholders, in order to gain additional requirements. If an analyst is
uncertain why certain procedures are in place, this can also help the analyst in asking these
questions during interviews. When studying the requirements, the analysts may find problems
that they may distinguish on their own. The analyst may find there was missing information in
old documents.

6. Joint Application Design/JAD:

The fore mentioned techniques have been examples of traditional requirement gathering,
whereas JAD is an example of a more contemporary method for gathering requirements. Joint
Application Development (JAD) was introduced in the late 1970s so solve some of the problems
users experienced in the conventional methods used to gather requirements. Organizations that
have adopted JAD report savings of 40% or more in project design time. JAD is successful in
reducing time because the user and other key members are heavily involved in the process. The
goal is to get the design right the first time, thereby reducing different iterations.

7 .Prototyping: Prototyping is another form a contemporary requirement gathering method.

Prototyping is iterative process that heavily involves the users to complete. The user provides the
requirements, in which the analyst can plug in directly and show the user the outcome.
Prototyping is dependent on user interaction and cannot be utilized as its own method of
gathering requirements. The analyst must interview or perform some other form of requirement
gathering to perform before they begin prototyping.

23
3.1 Techniques for demand gathering:
1. Raise demand

2. Trawling demand

3. Prototype
4. Demand analysis
5. Paradigm two
6. Actual/pure demand
Firstly, ask clients and acquire to grasp what he select his classes if he/she select fathom
computer(type 1)deal with these sorts that square measure discuss higher than get his demand
and supply trawling to induce those needs that square measure wont to create his system then
create a dummy system that square measure meet his demand and show him to induce robust
demand that square measure wont to create real system when paradigm we tend to get additional
demand from clients that square measure wont to create a right product that client required then
when paradigm we tend to analysis {the demand |the need |the necessity} and add demand
people who come back from paradigm and mix them {to create to form to create} an entire
demand of a product afterward we tend to create a replacement paradigm that meet to customer
demand and show to customer that paradigm if he /she accepted that then we tend to create his
system in step with his purify gathering demand if he create additional demand to ascertain
ordinal paradigm then we tend to make a loop on fifth step this loop is terminated once actual
requirement square measure come back. And currently the second client that don’t fathom pc
/software we tend to take care of following steps square measure those.

3.2 Techniques Requirement Gathering from Second Type of Customers:

Idea’s from customers
1. Prototype
2. Reasonable questioning
3. Trawling requirements
4. Requirements
5. Requirement analysis
6. Actual/pure requirement

24
3.2.1 Customize Software:

Custom computer code is computer code that's particularly developed for a few specific
organization or alternative user. As such, it may be contrasted with the employment of computer
code package developed for the mass market, like industrial ready-to-wear computer code, or
existing free computer code. Custom computer code (also referred to as bespoken computer code
or tailer - created computer code. Example of after we state the definition of custom computer
code. During this case, the client had to accumulate custom developed computer code thanks to
specific needs, rather than merely shopping for associate degree ready-to-wear resolution. As
you'll see, the big selection of the options is narrowly targeted. you'll barely notice an answer for
your similar needs. In the end, the shopper has obtained associate degree all-in-one welcome and
loyalty computer code tool that utterly fill within the gaps of the progress. Moreover, the
restaurant franchise had exclusive possession of the computer code that meant zero licensing
prices Regardless of the quantity of users, accounts, and terminals.

3.2.2 Generic Software:

Ready-made package Distinction with "custom software”. See shrink wrapped package.
Package which might perform many various forms of tasks however isn't specifically designed
for one style of application. Generic processes area unit processes that area unit designed to run
outside traditional element or application process. Generic processes aren't specific to a specific
element and may be employed in any range of applications. They are like general purpose
processes.
There area unit 5 generic method framework activities:
• Communication: The package development starts with the communication between
client and developer.
• Planning: It consists of complete estimation, programming for project development and
chase.
• Modeling
• Construction
• Deployment
There area unit 5 generic method framework activities:
1. Communication:

25
The package development starts with the communication between client and developer.
1. Planning: It consists of complete estimation, programming for project development
and chase.
2. Modeling:
Modeling consists of complete demand analysis and also the style of the project like
algorithmic program, multidimensional language etc.
• The algorithmic program is that the piecemeal resolution of the matter and also the
flow chart shows an entire multidimensional language of a program.
3. Construction:
Construction consists of code generation and also the testing half. • Coding half
implements the look details exploitation associate degree acceptable artificial language. •
Testing is to see whether or not the flow of committal to writing is correct or not. •
Testing additionally confirm the program provides desired output
4. Deployment: Deployment step consists of delivering the merchandise to the client
and take feedback from them.
5. • If the client desires some corrections or demands for the extra capabilities, then the
amendment is needed for improvement within the quality.

Agile Model
Ten years ago, ideas that began to form among a few fans have now become the foundation.
One of them is the idea of using Scrum to develop agile products. A popular agility management
framework used to indicate what is being reconsidered in the buying and selling process and how
it affects the establishment of contracts is followed. Discuss the 12 principles of agility and agile
software development from the perspective of procurement and software providers. Companies
hoping to meet the demands of dynamic markets increasingly rely on agile software development
methods. Development teams using agile methods can achieve impressive results
model is used to develop software with different techniques or points.
• Used for critical application.

26
3.2.3 Techniques Requirement Gathering from Second Type of
Customers:

7. Idea’s from customers

8. Prototype
9. Reasonable questioning
10. Trawling requirements
11. Requirements
12. Requirement analysis
13. Actual/pure requirement

3.6 Submit the Required Technology for Software Development:

The tools that collect the following requirements can be used to promote the above methods, or
they can be used as techniques for collecting requirements themselves.
1: User story definition
User story mapping can be a technique that is accustomed to understanding and understanding
the needs of end users. This orders the development team to support their work, which helps
build good user skills. When using a user story on the map, you will define it, but the user
interacts with your software system (or product, service, website, etc.), or the user browses the
product Is will be able to determine which of these steps is most beneficial to your customers and
order the creation of options that can add a lot of value to their expertise.
How to draw user stories
Step 1: Assemble an excellent team composed of related workers to engage in commodity
production.
Step 2: Set up your customers, their goals, needs, etc. with the help of customer profiles
Therefore, by doing so, you analyze the collected information to explain your user issues.
However, please consider that your product will solve these problems.
Step 3: Activities performed by users while using your product. These are the stories or topics at
the top of the user
story map. You will be able to use product collaboration features to engage your team and break
down your activities into smaller stories. Put these stories on the map with the highest altitude
Step 4:

27
Although users browse products from left to right to map your user story. If there are multiple
users, a completely different event is presented to each user.

Step 5:

Devependencies, technical needs, bottlenecks that will have an effect on the work you've got
to try and do. Confirm that you just the stories that are vital for making a bigger user expertise.
Then establish the solutions in situ to beats these problems before and you intend your work is
well.

Fig.3.2 User story mapping template

3.7 Use Case Diagram:

The use case diagram visualizes the interaction between the user and the system, in other words,
the user's actions and the system's response. The development of the system helps to focus on the
needs of the end user.

Fig:3.3 Use Case Daigram

28
Usage can be a method used in system analysis to clarify, define, and manage system usage
requirements. This problem is a combination of possible interactions between the system and the
user in a very clear environment, and is related to a specific purpose. Using Square
Measurements, usually written by business analysts, can be used in many stages of code
development, such as raising system requirements, ensuring styles, testing code and online
services, and creating advanced theories for user manuals. A use case document will facilitate th
event team determine and perceive wherever errors could occur throughout a group action so that
they will resolve them.

3.7.1 Each Use Case Has Three Basic Elements:

Actor system user-this can be a person or a group of people who interact with this method.
• Purpose. the final result successfully of this methods.
• System. Methods and steps to achieve tipping goals, as well as basic objective requirements
and expected practices. Use can be a way to clarify, define, and manage system requirements in
system analysis. A use case consists of a set of interactions between the system and the user in a
clear environment and is related to the selected goal. This strategy produces a document
explaining all the steps the user takes to complete the peer-to-peer activity. Use square feet
usually written by business analysts, and can be used in many stages of software system
development, such as system requirements, simplification, software system testing and online
facilities, and advanced concepts for user manuals. The use case document will help the incident
team to establish and find out where the error occurred in the case.
Maybe to fix them. Each use case contains 3 basic elements:
•actor. System user-This can be a person or a group of people who interact with this method.
• Purpose. Complete the final result of the method.

3.7.2 Characteristics of Use Cases

Use cases describe the functional requirements of the system from the user's point of
view, create a purposeful sequence of events, and make it easier for users and developers to
implement. A complete use case will include the main process or main process and various
alternative processes. Alternative processes, also known as extensible use cases, describe subtle
changes and abnormal situations in the basic process.
If used, the following functions should be displayed:

29
Al manages active demand.
The system exemplifies the communication goals of the system/participants.
Record the path from the trigger event to the target (called a plan).
Events describe important event streams and various alternating streams.

3.7.3 There are Two Different Types of Usage.

Business use and system use issues
In the case of business use, an additional abstract description may be written to some extent with
technically agnostic sources, in which the business method is fully reflected, and the activity also
resides in the activity in. Business use cases determine the sequence of functions required by
work users to produce important, visible business results. The source needs to be executed. In
contrast, the use of the system is written in more detail than the use of the business. In the
business, they are the exact processes that occur in the various components of the system and are
designed to achieve the goals of the end user. System use cases can provide actual explanations,
as well as case diagram dependencies, necessary internal help options and optional internal
options. The three basic components that constitute the role, system and purpose of the regional
unit of the case are also used. Various other components considered for writing use cases
include:
Stakeholders, or anyone who is interested in or invests despite the implementation of the system.
• Preconditions, or the weather that has got to be true before a use case will occur.
• Triggers, or the events that cause the utilization case to start.
• Post-conditions, or what the system ought to have completed by the tip of the steps.

30
 Fig.3.4 Use case

3.7.4 Examples of Use Cases

In addition to computer code and system development, the associate degree example that will
prosecute use cases is the direction of the vehicle. The driver tried to reach the Big Apple from
the capital of Massachusetts. In this case, the actor is talking about the driver and the goal is to
reach the Big Apple, which is why the system is the network of roads and highways they want to
reach. One of the most surprising routes taken by the driver between the Massachusetts capital
and the Big Apple is possible-this is the most commonly used situation. However, many
obstacles may be encountered along this route, which may eventually lead to the development of
Apple in big cities. It measures the use of rotation and the use of extensions in completely
different paths. The goal of the driving route is to get on the road at the turn. The power has to
reach its final destination. More specifically, it is related to computer code and system
development, and the problem of use cannot be determined, but the customer has completed the
associated degree order through the online merchant. 1. Employment issues it should be gone,
that's why actors should know. In this case, the work problem is called "complete purchase", so
the participants are:
Customer
Fulfill the order fulfillment system; and

31
Charge charging system
These are learning and enhancements of expertise in gathering the computer code demand
.software demand is that the most simple step for done the or build the computer code in an
exceedingly best and economical manners .The main purpose of this writing is there's no thanks
to collaborate the simplest thanks to analyze gathering necessities in terribly correct manner
therefore all steps should be taken to resolve to manage the full atmosphere of computer code
management system.

3.7.5 Brainstorming
Used to combine the needs of brainstorming to maximize the use of a group of people
1. File analysis
[Link] group
[Link] analysis
[Link]
[Link] Observation
[Link]
[Link] needed
Gathering Information Gathering technology is a common process used to create and organize
data across various sources.
There are four types of information gathering techniques.
Root cause analysis: One technique for collecting information is root cause analysis.
Please note that these requirements will be considered before developing the software. The
requirements generally considered fall into three categories:
Active request
Ineffective demand
Primary domain requirements

3.8 Different Phases for Requirements

Step 1: Requirements Collection and Analysis:

This must be the first step in the SDLC process. This is done by senior team members with the
input of all stakeholders and domain consultants in the business. At this stage, the design and

32
related risk reorganization for the standard assurance requirements have been [Link]
stage can clearly show the scope of the completed project and the expected problems,
There are also opportunities and directions to inspire the project. The demand collective stage
requires the team to attract a broad and precise demand. This helps the company eliminate the
timetable required to complete the system.
Phase 2: Feasibility study:
After the analysis phase is complete, the next step is to define and document the SDLC software
requirements. This is done with the help of "software requirements" documents (also known as
"SRS" documents There are basically five types of probability checks:
•Legal: We treat this project as cyber law and other regulatory framework/compliance.
Operational feasibility: Can we design operations that customers can expect?
Technology: Need to check whether the existing computer system can support the software
• Timetable: Determine whether the project can be completed within the given timetable.
Phase 3: Design:
In the third part, the system and code style documents are prepared according to the
specification documents required for the square measurement. This helps the overall design of
the sketching system. This style part is the input for the later part of the model. The document
style created at this stage is 2 squares.
High-level style (HLD)
Description Brief description and name of each module
Operating instructions for each module
Interface relationship and dependencies between modules
• Database tables with key components
Technical completion of the design of technical details
Bottom style (LLD)
Functional logic of the module
Database table with layout and size
Full description of the interface
Enemy troubleshoots all types of correlation errors. List of error messages
Complete input and output of each module.
Phase 4: Coding:

33
Once the system design phase is complete, the next step is coding. At this stage, developers need
to follow some descriptive coding guidelines. They need to use programming tools such as
compilers, interpreters, and debuggers to generate and execute code. n this section, the QA and
testing team may see some errors or errors, which are given to the developers. The activity team
fixed the error and sent it back to the quality inspection department for retesting. As long as the
code has no errors, is stable and meets the business requirements of the system, this method will
continue.
Step 6: Installation/Deployment:
Once the code testing part is completed and there are no errors or errors in the system, the final
reading process begins. The feedback provided by the project manager is confirmed, the final
code is free, if any, check the problem for reading.
Phase 7: Recovery:
Once the system is established and the customer starts to use the developed system, three
activities will be carried out. • Error repair-the square degree of errors that have not been tested
in any way due to certain conditions .Level upgrade-upgrade the device to the latest version of
the code .Enhancements-Some new options have been added to the existing code. The main
focus of this SDLC section is to ensure that the system's desire to perform in accordance with the
specifications described in the system section is still met.

Fig.3.5 SDLC Cycle

34
3.9 Research Methodology

Discuss with customers and acquire to grasp what he opt for his classes if he/she opt for realize
laptop (type 1) deal with these varieties that square measure discuss on top of get his demand and
supply trawling to urge those needs that square measure accustomed create his system then
create a dummy system that square measure meet his demand and show him to urge sturdy
demand that square measure accustomed create real system once image. we tend to get a lot of
demand from clients that square measure accustomed create a right product that client required
then once image we tend to analysis {the demand |the need |the necessity} and add demand
people who come back from image and mix them {to create |to form| to create} a whole demand
of a product afterward we tend to create a brand new image that meet to client demand and show
to customer that image if he /she accepted that then we tend to create his system in line with his
purify gathering demand if he create a lot of demand to examine second image then we tend to
make a loop on fifth step this loop is terminated once actual requirement square measure come
back. And currently the second client that don’t realize laptop /software we tend to handle
following steps square measure those.

3.10 Detects Defect in Requirement Gathering:

For this reason, it is important to check for defects in the requirements part and detection
technology, especially in the SRS document itself. There is a need to develop scattered
information about defect detection technologies so that the information can be stored within the
framework of identifying defect areas. Organized data is given in classification types. Although
the "demand" part estimates multiple detection techniques.
However, little work has been done on the analysis and evaluation of the technologies that can
be achieved for different things in the requirements part. The previous classification of errors
also failed to resolve the errors in the required part, and also due to their breadth. By proposing
the classification of defects in demand allocation, these limitations are overcome. The
classification of each defect and the reason for its spread in the SRS document .In addition, this
article compares the strength and effectiveness of each reading technology with the effectiveness
of defect detection technology (reading technology) in the "Requirements" section. In addition,
this thesis provides a universal reading technique that enhances the associate degree reading
technique. The anticipated technology avoids the shortcomings of alternative reading

35
technologies. It can help engineers perform problem detection and optimize them as needed.
Therefore, the quality of the packaging can be

Fig: 3.6 Distributed defects

36
Chapter#4

Applications of Software Requirement Gathering

In recent years, many studies and seminars have emphasized the difference between HCI
(Human PC Interaction) and the software package style in software package engineering. These
studies done in these areas emphasize that the coordination between them is not strong. There are
plans to integrate many HCI and Value Techniques frameworks into the software package
development life cycle. This chapter reviews some of the most important frameworks. Despite
completely different software packages, it still evaluates their advantages and disadvantages.
For example, SWEBOK is a partner in the definition of SE data and methods in the IEEE
Initiative for Nursing, and defines HCI as a "related discipline."For example, SWEBOK is a
partner in the definition of SE data and methods in the IEEE Initiative for Nursing, and defines
HCI as a "related discipline."With choices, they can live together. This anxiety comes from the
early days of HCI. Although various HCI researchers and practitioners read "user-centered style
(UCD)" as a specific combination of processes and methods for styling and developing
interactive software package applications, HCI is not The main title is considered in SE.
For example, SWEBOK is a partner in the definition of SE data and methods in the nursing IEEE
plan. He defines HCI as a "related discipline", called "software ergonomics" (Abram et al., Allah
Almighty, 2004).
Use is considered to be one of many non-objective purposes and quality attributes. ISO 13407 is
normal, "Interactive system people. There is no mention of specific UCD practices found in the
"Rocks-style process" (ISO/IEC, 1999). The fact is that UCD and software package engineering
technology have overlapping goals in software package development methodology, namely how
to use art correctly. Effects (documents and consumables), and overlapping targets to classify
quality attributes. There is a trend of controversy regarding the methodology of software package
development.
As it presents, it requires very different ideas. The SEO community focuses on the system
1" method. Driven by specifications describing applications (including software development
interfaces). User interfaces must meet functional and usability requirements, but these

37
requirements are related to the system itself. The point is that software applications and
interfaces must meet certain requirements. One of the components.

4.1 Software Engineering Application

Software engineering applications are new ideas, tools or processes. Invention is the application
of better solutions that can meet new needs, unnecessary needs or current market needs.
Inventions are real, novel, important, and new, and can "destroy" the market or society.

4.1.1 Application Areas:

Embedded and real-time systems.
One of the most important software applications for accuracy is embedded systems.
Critical safety system.
O Service-oriented architecture.
Safety.

4.2 Review Software Requests

It is a bit cumbersome to develop key generic classes for software package applications, because
the complexity of software packages increases and it is difficult to classify applications into
clean segments. But the subsequent software package field showed a wide range of potential
applications. The system software package is dedicated to domain 1, not only for shooting in
alternative environments. The system package is divided into one of two modes

4.2.1 Real-time System and Software

Real-time code is an associated example of each system code, usually not embedded code. This
code has code solutions for specific problems that are invisible to PC and code users. It does not
form a single complete definition of the time system or its code. Therefore, some well-chosen
definitions may apply to things that can be counted without time, but the square measurement of
these definitions below is the best choice. It needs to be understood that the time period system
should not be forced to satisfy all these definition to be therefore classified. what is more,
associate actual time period system could act contrary to 1 or additional of those definitions,
however trust others. The definitions square measure listed mealy to offer a sign of the type of
behavior one may expect from a time period system.

38
4.2.2 Technical Field
Part of the "Speaking Grammar" of this patent document contains copyrighted material. The
copyright owner has no objection to the reproduction of patent documents or crops in the Patent
Speech Act because it appears in patent documents or records in the patent and trademark area,
but has other rights.

4.4.3 Commercial Software

Commercial software packages are one of the most important application spaces for software
package development today. Commercial software package samples; information systems;
databases; easy. Generally speaking, this may be because such software packages are often
referred to as MIS software packages for management information programs. A simple example
might be an assistant in a computer program beyond nursing. It can access information from a
file and display it in actually many different ways, from tables to pie charts to histograms, etc.
Using different words to express stress means summarizing and presenting information.
Potentially reflect different examples. The ability of North American countries to access all your
taxes (mainly based on SIN scope registration) nursing care ID or address. More ICBC can
flexibly remember your auto insurance terms and conditions based on the license plate.
Personnel can access information about your job (position, home address, terms and conditions
as well as contract, salary, length of service, etc.). The personnel department will support your
name and department.
Traditionally, mathematical problems have been rendered groundless in the field of software
package [Link] scope of assembly of large-scale computing applications and/or
algorithm libraries. It embodies ancient applications; physical sciences, such as imaging
sweetening algorithms, predicted orbits, mapping of star/planet orbits, geophysical and seismic
prediction data, and the final part of predictive analysis on simulation and PC.

39
 Fig: 4.1 Business Software

4.4 Embedded Software

Embedded code includes a variety of applications. For cutting-edge users, it may not be
obvious to use the computer at a certain interval during system assembly. Sometimes, the
embedded code revolves around small embedded microcontrollers (such as Intel 8051, Motorola
6811) and at a simpler level, it revolves around samples of microwave ovens, CD players, and
engine management systems that embed embedded code into cars. Acknowledge the degree to
which your computer has embedded devices, and you will be forced to bring up only 10.
Accept the current interval embedded system of general luxury car ratio. Call your horror I want
to write a great article outlining the issues related to the design and quantity design of embedded
systems, rather than having to do so. Embedded code is a type of computer code written to
control machines or equipment that are sometimes not even considered [Link]
these comments are made as embedded systems. It always specializes in the specific hardware it
is running on, and there are time and memory limitations.

Fig: 4.2 Embedded Software

40
Many embedded systems use actuators to manage their external environment or direct certain
external processes. The flight control computer engine commands the passenger, the wings and
the tail to inflate the direction so that the aircraft can fly. The chemical change management
system manages at a time, what type, and therefore calculates the additional reagents in wattage.
The corresponding object beats the center at appropriate intervals, where the electrical lead (right
side) is connected to the wall inside the heart chamber. Naturally, most systems participate
There are sensors. Despite the existence of an open-loop management system, the two parts of
management use environmental feedback to ensure that the management loop is functioning
properly. The traditional computing system completely responds to the user, while the embedded
system can move in the opposite direction with the user. However, their interaction with sensors
and actuators is more worrying. One problem caused by environmental interaction is the degree
to which Yenta ignores our opinions is a painful habit, but once we are forced to act on it.
External events are not inevitable .Once an incident occurs, the system should respond to the
incident. It is valuable that after the visceral activity ceases, the correlation diagram monitor
should promptly issue an alarm. After lightly loading the processor, the system alarm will not
work until the end of the evening
Many embedded systems can respond by nature, and over time, their response to external events
should be strictly limited. As we will see later, the management loop is very sensitive to time
delays. Process delays undermined administrative discipline. Most embedded systems set one or
more tasks at a higher level. Performing these high-level tasks particularly requires some
coordinated low-level activities. This can be called a coincidence. Since a single processor
system can only execute one element at a time, they implement one programing policy that
controls once tasks execute. In multiple-processor systems, true concurrency is accomplishable
as a result of the processors execute asynchronously. Individual processors inside such systems
schedule several threads pseudo-concurrently (only one thread could execute at any given time,
however the active thread changes in line with some programing policy), as well.
Embedded systems are typically made with the smallest amount overpriced (and, therefore, less
powerful) computers which will meet the purposeful and performance needs. Embedded systems
ship the hardware at the side of the computer code, as a part of a whole system package. As
several merchandise are very price sensitive, promoting and sales issues push for victimization
smaller processors and fewer memory. Providing smaller CPUs with less memory lowers the

41
producing price. This per-shipped-item price is named revenant cost; it recurs as every device is
factory-made. computer code has no vital revenant price, all the prices ar sure up in
development, maintenance, and support activities, creating it seem to be free.4 this suggests that
selections are most frequently created to decrease hardware prices whereas increasing computer
code development prices.

4.5 The Invention is Suitable for the Design

Development of computer software application programs of enterprises and other organizations,
especially suitable for large-scale and complex systems of networks, private networks and public
networks, which work like the Internet.

4.6 Background Art

The ever-increasing standards in the development of portable computer programs (revealing the
logic of many companies) will be programmed into machine-readable code before designing the
desired reality of these programs, which is essential for the timely and effective production of
systems. . Because organizations are forced to make little effort, the need to deliver such requests
on time and on budget without sacrificing quality is a greater challenge than ever. One of the key
issues in each field is the definition of the system, that is, the effective identification of the
accurate, complete and clear requirements for the system or application. Often online
Very accurate about the application used. These requests must not only meet the requirements
related to graphic style, content and utility, but also the complex importance of user system
interaction. These requirements are not complete and accurate requirements from the time of
display. It should be recorded. Before starting the device. The development of traditional style
packaging usually involves many important areas. The basic idea is because the "waterfall"
package is a development life cycle method. The second method attempts to improve the
effectiveness of water methods by introducing prototypes into early life events. Each of these
methods deals with important issues. The water method can be a linear and continuous
development method. Each part of water resources development has different development
goals. Once the development part is completed, the generated part will be paid.
Then there is no turning back. This part of the development is equivalent to the flow of water on
the water. It cannot return to the top of the waterfall. Using the water style method, the
}submission section usually leads to a requirement to capture paper documents. Usually, the

42
system style will generate a paper-based design based on paper-based requirements. Then, the
system developer interprets the paper-based style and converts it into actionable code.
Typically, after the United Nations agency evaluates the code to see if it satisfies the incoming
portable computer application request, then the applicable code is passed on to the tester.
Although water development allows for sectoralization and social control, it does not require
much reflection or modification. The entire process needs to be repeated to change the planning
method. However, once the partner's application is in the testing phase, please go back and
perform similar operations.
Change is a big trouble that I didn't expect. Similarly, usually, problems are discovered only after
system testing, and requirements should be run before the system achieves its intended purpose.
The evolution of needs undermines the development of events. Usually in the planning and
coding phases, you will find differences in requirements, lack of system elements, and sudden
increases in requirements. In addition, unless the system is coded, system performance cannot be
tested, and even insufficient capacity is difficult to correct. For these reasons, the premium water
model handles the failure or cancellation of many different systems. Standard water type
Proch's leading alternative method has changed the way water is used to embrace people, they
have started to have a very rough understanding of the system, and it has become wider and
wider over time, which are many small waters What it did (Spiral waterfall design). And those
with overlapping stages and sub-projects (modified waterfall).

Fig:4.3 Background Art

4.7 Types of requirements

There are two types of requirements that are useful in data gathering about software development
process.

43
4.7.1 Functional Requirements
In computer code engineering and system engineering, no matter how the behavior between
performance and output is defined, purposeful requirements describe the performance of the
system or a part of it. As described in requirements engineering, objective requirements define
the specific results of the system. The sender needs to explain the needs related to the required
mathematical purpose at the highest level. Objective needs will be different from abstract
statements. Purposeful computer code is required so that you can capture the actual behavior of
the system. The goal defines the performance of the system or part of the system, regardless of
the behavior between the defined performance and the output. Functional requirements may
include calculations, technical details, information manipulation and operations, and outline
various specific operational capabilities required to complete the design.
Behavioral requirements define all situations. As long as the system uses objective requirements,
this square measure is used. objective A metric of objective requirements supported by objective
requirements (also known as "quality requirements") that hinders planning or implementation
(such as performance requirements, safety, or reliability). Usually, the square measure of demand
based on demand is expressed as "the system should make demands when unrealistic demands
are formed". Make arrangements to achieve targeted requirements.
When designing inside the system, a passive square measurement is required. As stated in the
requirements, purposeful engineering requirements explain the specific results of the system. It
can be contrasted with passive demand that defines overall characteristics such as prices and
obligations. Objective requirements drive the design of the system, while unrealistic tasks require
the technical design of the system. In some cases, requirements analysts will have problems
when combining goals and requirements. Stakeholders need to analyze the classification of
purposeful requirements and their ease of modification; including usage issues. Stakeholders
create an application. The system engineer arranges for discussion, observation and review of all
aspects of the requirements. Use case design, entity relationship diagrams and different square
measurement models can verify requirements. With If it is documented and approved, it is
required/implemented. Each problematic case clarifies the behavior through one or more
purposeful requirements. However, the analyst can usually start using a set of usage questions, so
that the analyst can meet objective requirements so that the user can execute each usage question.

44
4.7. 2 Passive Requirements (NFR)
Determine the success of the software project. However, they are described as difficult, and in
Active Software Development (ASD), they are often underestimated and are often
undocumented. In this article, we introduce the discovery of document practices in companies
that use ASD and the challenges of NFR, and propose guidelines for enhancing NFR documents
in ASD. We interviewed practitioners from four companies, Confirm that Epic, features, user
stories, acceptance criteria, DNFR product definition (DOD), products and Sprint Back Lux are
used. Wikis, Word documents, cosmetics and spreadsheets are also used to record NFR. In
smaller companies, discuss NFR through whiteboards and flipcharts and the academic preference
of developers for documentation. However, for NFR detection, the difficulty of understanding
NFR and the limitations of NFR recording methods by joining a team of new developers are all
challenges faced by ASD. In this regard, we provide guidelines for recording NFR in [Link]
diversity of NFR is considered in the letter to provide different expression modes according to
the scope and level of detail of NFR. The proposed representation model is currently used by
ASD to avoid introducing new features that might hinder practitioners from adopting the original
format.
Architecturally significant requirements
Are there requirements that have a measurable impact on the architecture of the computer
system? This can include software and hardware requirements. They are a set of requirements, a
set of factors that affect the architecture of the system in an identifiable way. For a long time,
requirements that are important in the architecture have not been considered important ideas.
When talking about architecture, it is common to use passive requirements or quality attributes
Yes. However, recent experimental studies have shown that for a software system, not all passive
requirements will affect its architecture, and non-active requirements will also affect its
architecture. Therefore, important architectural requirements are a valuable concept and are
recommended to be used when discussing architectural requirements. Invalid requirements are
restrictions or requirements imposed on the system. They describe the quality of the software.
Idle demand scalability Bur Deal with retention, performance, portability, security, reliability,
etc. Non-functional requirements solve important software system quality issues. If the NFR is
not resolved correctly, the results may include:
• Users, customers and developers are not satisfied.

45
Conflicting software.
Without considering the NFR, the time and cost of repairing the software have increased.

Fig:4.4 Non Functional

4.7.3 Non Functional Requirement Method:

Imagine you’re buying a motorcycle. What features do you have in mind? Do you expect it to
travel at high speed of 170 miles per hour and not to fall apart? Can you attach a sidecar to it or
expand luggage space by attaching a pull-behind trailer? And let’s not forget about security
systems. While these requirements don’t directly describe the vehicle’s primary function –
delivering a person from point A to point B – they are still important to satisfy your needs as the
[Link] motorcycles or any kind of machinery, software has its own non-functional
requirements. Be it a website, a mobile or a desktop app, it should have a set of quality attributes
to meet end-user [Link]-functional requirement is a specification that describes the system’s
operation capabilities and constraints that enhance its functionality. These may be speed,
security, reliability, etc. We’ve already covered different types of software requirement but this
time we’ll focus on non-functional ones, and how to approach and document [Link] you’ve ever
dealt with non-functional requirements, you may know that different sources and guides use
different terminology. For instance, the ISO standards framework defines non-functional
requirements as system quality and software quality requirements. one of the main knowledge
sources for business , suggests the term non-functional requirements (NFR), which is currently
the most common definition. Nevertheless, these designations consider the same type of matter –
the requirements that describe operational qualities rather than a behavior of the [Link] list
of them also varies depending on the source. And, frankly, it may differ for different products.
For instance, if you intend to collect any user data and your website operates in the EU, you must
meet GDPR compliance rules. In some cases, this may not be relevant to you. Or you may have
46
additional compliance requirements if you process payments. In this article, we’ll cover only the
most common types that should make it to your checklist. However, there may be hundred.
Usually, such sources as BABOK list non-functional requirements in an isolated manner. We
grouped some of them since the approaches to documenting these requirements overlap and
some can’t be estimated without the other ones.

Performance and scalability. How fast does the system return results? How much will this
performance change with higher workloads

Portability and compatibility. Which hardware, operating systems, browsers, and their
versions does the software run on? Does it conflict with other applications and processes within
these environments?Reliability, availability, maintainability How often does the system
experience critical failures? and how much time is it available to users against downtimes

security. How are the system and its data protected against attacks localization? Does the
system match local specifics.

Usability. How easy is it for a customer to use the system?

Performance: Defines how fast a software system or its particular piece responds to certain
users’ actions under certain workload. In most cases, this metric explains how much a user must
wait before the target operation happens (the page renders, a transaction is processed, etc.) given
the overall number of users at the moment. But it’s not always like that. Performance
requirements may describe background processes invisible to users, e.g. backup. But let’s focus
on user-centric performance.

Scalability assesses the highest workloads under which the system will still meet the
performance requirements. Non Functional requirements in Software Engineering allows you to
impose constraints or restrictions on the design of the system across the various agile backlogs.
Example, the site should load in 3 seconds when the number of simultaneous users is > 10000.

47
Description of non-functional requirements is just as critical as a functional requirement. In this
tutorial, you will learn more about-

• Types of Non-functional Requirement

• Examples of Non-functional requirements
• Functional vs. Non-Functional Requirements
• Advantages of Non-Functional Requirement
• Disadvantages of Non-functional requirement
• Security Does your product store or transmits sensitive information? Does your IT
department require adherence to specific standards? What security best practices are used
in your industry?
• Capacity What are your system’s storage requirements, today and in the future? How
will your system scale up for increasing volume demands?
• Compatibility What are the minimum hardware requirements? What operating systems
and their versions must be supported?
• Reliability and Availability What is the critical failure time under normal usage? Does a
user need access to this all hours of every day?
• Maintainability Manageability How much time does it take to fix components, and
how easily can an administrator manage the system? Under this umbrella, you could also
define Recoverability and Serviceability.
• Scalability – The Black Friday test. What are the highest workloads under which the
system will still perform as expected
• Usability — How easy is it to use the product ,What defines the experience of using the
product.

48
Chapter#5

Results and Analysis

5 .Analysis
A “requirement " could also be a basic attribute in the system, that is, a handout
that identifies the qualifications, functions, or quality elements of the system as valuable to users.
"Software Project Survival Guide" compatible with Steve McConnell , " the foremost difficult a
neighborhood of requirements gathering isn't documenting what the users 'want'; it is the trouble
of helping users determine what they 'need' which can be successfully provided within the worth
and schedule parameters available to the event team. -How to have design requirements instead
of requirements? The rationale to meet various needs

5.1 Software requirements prioritization

In software development, if it is not clear which option is needed, people usually choose the
"right" requirement from many options, which is a challenge. Prioritizing needs can help people
meet important needs. Techniques that prioritize most requirements seem to work well on few
requirements, but many of them range from medium to large. There are restrictions on
requirements. Requirement priority is used to determine which candidate’s requirements for a
software project should be included in a particular release, and different techniques are used for
this. These technologies use different methods and consider various priority factors, such as cost,
price, risk, benefit, etc.

5.1.1 Requirements prioritization challenges

The priority of requirements is considered an important development activity. Throughout
this article, we describe the current state of the two case companies prioritizing requirements and
present the smart challenges involved. Our research shows that the priority of requirements is a
vague concept, and the company's current behavior is informal. Prioritizing requirements
requires decision-making in a complex environment and the development work needs to be
repeated several times. Practitioners are looking for a more systematic way to prioritize
requirements, but find it difficult to concentrate on all or any related factors that affect priority,

49
and it is difficult to clearly express different stakeholder views. In addition, practitioners need
more information about real consumer preferences.

Fig:5.1 Requirement Prioritization

5.1.2 Requirement Prioritization Method:

Many requirements prioritization approaches have been proposed, however not all of them
have been investigated empirically in real-life settings. As a result, our knowledge of their
applicability and actual use is incomplete. A 2007 systematic review on requirements
prioritization mapped out the landscape of proposed prioritization approaches and their
prioritization criteria. To understand how this sub-field of requirements engineering has
developed since 2007 and what evidence has been accumulated through empirical evaluations,
we carried out a literature review that takes as input publications published between 2007 and
2019. [Principle ideas/results] We evaluated 102 papers that proposed and/or evaluated
requirements prioritization methods. Our results show that the newly proposed requirements
prioritization methods tend to use as basis fuzzy logic and machine learning algorithms. We also
concluded that the Analytical Hierarchy Process is the most accurate and extensively used
requirement prioritization method in industry. However, scalability is still its major limitation
when requirements are large in number. We have found that machine learning has shown
potential to deal with this limitation. Last, we found that experiments were the most used
research method to evaluate the various aspects of the proposed prioritization approaches.
Identified and evaluated requirements prioritization techniques proposed between 2007 and
2019, and derived some trends. Limitations of the proposals and implications for research and
practice are identified as well.

50
5.1.3 Requirement Tendency
The definition of requirements covers all aspects of system development before the actual
system style. In the process of determining the requirements, there is a tendency to contact us,
because we believe that the system has a certain degree of insufficient participation in the
process of checking the requirements and proposing to achieve these goals, so we proposed 3
web articles. Context analysis, practical details and style barriers. The definition of requirements
replaces the widely used but well-defined term "needs analysis".

Fig:5.2 Development Trends

5.1.4 Method of Development Trends:

In virtually every decision they make, executives today consider some kind of forecast. Sound
predictions of demands and trends are no longer luxury items, but a necessity, if managers are to
cope with seasonality, sudden changes in demand levels, price-cutting maneuvers of the
competition, strikes, and large swings of the economy. Forecasting can help them deal with these
troubles; but it can help them more, the more they know about the general principles of forecasting,
what it can and cannot do for them currently, and which techniques are suited to their needs of the
moment.
Here the authors try to explain the potential of forecasting to managers, focusing special attention
on sales forecasting for products of Corning Glass Works as these have matured through the
product life cycle. Also included is a rundown of forecasting techniques. To handle the increasing
variety and complexity of managerial forecasting problems, many forecasting techniques have
been developed in recent years. Each has its special use, and care must be taken to select the
correct technique for a particular application. The manager as well as the forecaster has a role to
play in technique selection; and the better they understand the range of forecasting possibilities, the

51
more likely it is that a company’s forecasting efforts will bear fruit. The selection of a method
depends on many factors—the context of the forecast, the relevance and availability of historical
data, the degree of accuracy desirable, the time period to be forecast, the cost/ benefit (or value) of
the forecast to the company, and the time available for making the analysis. These factors must be
weighed constantly, and on a variety of levels. In general, for example, the forecaster should
choose a technique that makes the best use of available data. If the forecaster can readily apply one
technique of acceptable accuracy, he or she should not try to “gold plate” by using a more
advanced technique that offers potentially greater accuracy but that requires nonexistent
information or information that is costly to obtain. This kind of trade-off is relatively easy to make,
but others, as we shall see, require considerably more thought.

5.2 Software method Models and Analysis on Failure of computer code

Development comes
The computer code method model consists of a group of activities undertaken to style,
develop and maintain computer code systems. a range of computer code method models are
designed to structure, describe and visit the computer code development method. The computer
code method models play a really necessary role in computer code development, thus it forms
the core of the product. Computer code project failure is commonly devastating to a corporation.
Schedule slips, buggy releases and missing options will mean the top of the project or perhaps
bankruptcy for an organization. Oddly, there's disagreement over what it suggests that for a
project to fail. During this paper, discussion is completed on current method models and analysis
on failure of computer code development that shows the necessity of latest analysis.

5.2.1 Method and system for analysis of software system necessities

In the development life cycle of the software system, the software quickly reveals an existing
invented logic technology, in which the software system can help make up for the lack of the
software system's requirements for the software system's functions. The tested system
capabilities include the following strategies: (a) Logical examples of process software system
requirements; (B) Comply with software system requirements Compatible (c) Follow the logic
example of the situation checked in this figure to draw a simulation conclusion about whether the
software system needs to be modified. Preferably, the present invention is implemented as an
associated integrated tool, which is eliminated by a desktop computer or a digital computer that

52
uses a series of test graphical user interfaces (GUI) for logical testing of the software system
necessities.
5.3 Field of Invention
The present invention relates to software package development. In addition, the present invention
relates to a tool for analyzing software package requirements at the very beginning of the
software package development cycle.
Background of the invention.
The development of large software packages usually involves a "classic" development life. Such
a "classic" life cycle is evident in the development of the US national defense document DOD-
STD-2116A.
Such a "classic" life cycle is evident in the development of the US national defense document
DOD-STD-2116A. The specific development life stage is a written record, but it is also
permanent, because the new performance function is the form of acquiring computer code or
modifying the system at the same time. The life stages are as follows:
1. System analysis:
At the same time, the performance goals of the large-scale system composed of each software
package and hardware are as follows. At this stage, the key elements of the known system are
usually called "configuration items".
2. Analysis of software package requirements:
The system functions implemented by the software package are isolated. In addition, compare
each qualification with the diversity required by the software package. The interface between any
external device with any interface and the configuration of the large software package is still
provided. At the same time, the high-level package elements are known, and each element
responds to a set of requirements. The requirement grouping satisfied by the package elements is
essentially inconsistent with the requirement grouping, which is part of the package function. In
addition, advanced management (called execution control) management is carried out on the
package elements. In classic software package development, the realization of package
requirements is not managed. However, for system engineers, it would be helpful to immediately
obtain the first draft of the implementation management required by the software package.

53
Style factors of foreign software packages (such as accessible software services, barriers to
system beauty, etc.), such as system engineers who do not allow PC scientists to use software
alone can study the requirements of the software package. Finally, in the initial package style
section, the interface between the high-level package elements is outlined.
4. Full design of the software package:
It competes with the advanced software package elements in the program units that are regularly
applied to the unit. The algorithm of the program unit is described in pseudo code or program
style language (PDL), and the interface between the program unit and the regular unit is
outlined.
5. Codes and Unit Tests
Throughout that, at the routine unit level, algorithms are committed to viable code and
compiled. The compiled programs are then tested in isolation, which needs building process
environments for every unit to simulate the system within which it executes (referred to as check
harnesses). Check harnesses can usually comprise additional lines of code than the unit being
tested. Also, as they're tested, the units are increasingly joined into elements.
6. The Environment of the Whole Process
Is built around more and more elements composed of units. When the process sequence is
formed, the elements will be tested. Testing usually starts from a desktop simulation
configuration to a system laboratory where there is a specific part of a specific system hardware
also gift.
7Necessities Test:
Throughout that the high level software package elements that are created are tested with
relevance their necessities. This part is usually conducted during a systems laboratory wherever
the system is simulated (or a large number of systems and hardware components are combined)
8 System test:
Throughout that the totally completed system is tested against its performance necessities.

5.4 Traditional needs Landscaping Collection

As we have seen, the failure of the project will be attributed to the quality of the RG method
and ultimately to the quality of desire. "In terms of evacuation requirements, the [RG] procedure
will be improved, which will increase the requirements for the system and may be a better

54
system" (Crystal and Kang, 1992, p. 1). There are many variants of the RG method model, such
as Hickey and Davis (2004), Zhang (2007), Sommer Will (2005). Can be seen in Crystal & Kong
(1992), we think they lack the steps of the RG program style. , Technology selection and
technical analysis. Although Hickey and Davis (2004) accept technical choices in the model,
they do not accept the style or technical analysis of the RG method. The choice of RG
technology is an important aspect, because replacing the wrong project with the wrong method
will have a very serious impact. The analysis of RG technology is also necessary to assess the
previous effectiveness of the program. When choosing RG technology, the speaker’s goal is to
follow the most effective technique to achieve the goal. Choosing a technique is not an easy task,
and there are many ways to measure the square
I will choose RG technology. The latest technology selection technology is usually based mainly
on participation, as well as people who have worked well in the past among experts or projects
based on project managers.

5.5 Waterfall Model

• Body of water model is that the successive development model.
• Demand though Please figure it out before proceeding to the next steps After the code is
complete, the test is assigned. Each task product or activity has been completed before
proceeding to the next task.
This is true for every part of development income, without any roots
The timetable for each part of the task should be completed within the specified time
Phase documentation and testing occur at the end of each phase to help maintain project quality.
In the water model, each step freezes before the next step. It freezes its requirements before
starting the design, and starts coding after freezing the appearance. However, so far, the test team
has had incredibly difficult and expensive calculations for the operations performed section
solely. Waterfall model is a most basic once a one stage is forward then no can be moved back in
previous stage or phase. This is the major disadvantage of waterfall model. If any problem comes
in previous stage due to any mistake it cannot be resolved in time. It take more time to handle
the problems. So therefore it is most lesson use of waterfall model.
Agile model
The word agile means "quick response".
• Agile programs have an adaptive team that can respond to changing needs.

55
Satisfy customers by delivering useful software and better features faster.
Changes are welcome, even if there is a delay in development, and it may take some time to
achieve.
•Working software is usually delivered in weeks instead of months
The most important principle is to satisfy customers by providing customized software faster
and more consistently. Development and useful software.

5.6.1 Agile Methodologies summary

The core of the agile methodology was developed by seventeen individuals in 2001 in written
kind. Their Agile pronunciamento of package Development places The important mentality
related to valuable supply and cooperation with consumers is expressed in the form of the four
main values of agility: the implementation of comprehensive documentation and the interaction
between individuals and the interaction on tool kits, and contract negotiation. Changes after
customer cooperation thought.
It means that distinct pieces or grouping of code are assigned to a single owner who is
responsible for the consistency, performance, and conceptual integrity of the The ScrumMaster
acts as a liaison between the Product Owner and the team. The ScrumMaster does not manage
the team. Instead, he or she works to remove any impediments that are obstructing the team from
achieving its sprint goals. Scrum master helps the team to remain creative and productive and
makes sure of its successes visible to the Product Owner. The Scrum Master also works to advise
the Product Owner about how to maximize return over investment for the team Scrum projects
make progress in a series of sprints, which are time boxed iterations no more than a month long.
At the start of a sprint, team members commit to delivering some number of features that were
listed on the project’s product backlog. At the end of the sprint, these features are done--they are
coded, tested, and integrated into the evolving product or system. At the end of the sprint a sprint
review is conducted during which the team demonstrates the new functionality to the product
owner and other interested stakeholders who provide feedback that could influence the next
sprint which are typically one week, two weeks, or three weeks in duration. At the end of each
sprint, stakeholders and team members meet to assess the progress of a project and plan its next
steps. This allows a project’s direction to be adjusted or reoriented based on completed work, not
speculation or predictions.

56
 5.6.2 Agile Methodologies Frameworks
Today, the word Agile will talk to these values additionally because the frameworks for
implementing them, including: start, Kanab, Extreme Programming (XP), and adaptive Project
Framework (APF). Thus what's Agile methodology in project management merely place, it's a
method for managing a project characterized by constant iteration and collaboration so as to
additional absolutely answer a customer's wants.

Fig:5.2 Agile Methodology

5.7 Custom Software Development

Custom Software Development in Six Steps
• Step 1: Presentation
• Step 2: Assessment
• Step 3: Design
• •Step 4: Build
• Step 5: Acceptance
• Step 6: Warranty and Upgrades
• Step 7:gurantee and validity
• Step 8:Deployment

STEP 1: PRESENTATION
We begin our relationship with many conferences to urge to grasp you, to know what you would
like, to elucidate what we are able to provide you with, so finally, to demonstrate however we are
able to work along. Integrity and transparency square measure our core values and that we

57
promise that there'll ne'er be any funny business. The first meeting is usually a, ‘are we tend to
an honest fit‘ quite meeting. In our second, we are going to take deeper into the challenges your
organization is facing. And at the third meeting, we are going to gift you with an idea of however
we are going to overcome your challenges, and increase your method potency with method
automation.
STEP 2: ASSESSMENT
If your drawback is very complex, it should need that we tend to undergo a quick
assessment amount to completely perceive all of the small print concerned. This typically takes 2
to 3 days however isn't needed for everybody.
STEP 3: STYLE
The design section is once we produce the custom computer code blue print. Expect
variety of conferences, phone calls, and emails throughout this step as we are going to want a
great deal of data from you. The planning usually makes up between10% and two hundredth of
the project. throughout this step, we tend to build wireframes and talk over useful needs, and at
now everybody involved the project are clear on what’s being designed and why.
STEP 4: BUILD
Things begin to return to life throughout the build stage. The Developers begin to
develop, our Business Analysts can still clarify and demonstrate progress, and you'll be well-kept
so far with weekly project reports.
STEP 5: ACCEPTANCE
Along the approach and once the applying has been completed, you'll have the chance to simply
accept (or reject) the work that's being conferred to you. Once you've got accepted it, your
assurance amount can begin.
STEP 6: ASSURANCE AND UPGRADES
We encourage our purchasers to think about participating in associate sweetening decide
to keep their application up to pace with their wants. Enhancements square measure things which
will be seen as a scarcity in practicality that increase in priority till the things square measure
price building, and can conjointly make sure that your application keeps pace with new.
STEP 7: GURANTEE AND VALIDITY

58
 In customize software the developers are satisfying the customers and give advantage of
customers that there software being work for a specified period of time. And the developers are
facilitates the users or customers the validation process.
STEP 8: DEPLOYMENT
After working on software by software developers the developers are satisfying her or his
requirement and responsibilities checks send the software that are made for the customers for
used and worked on it. Deployments are the main step for any software.

Fig: 5.3 Custom Software

5.8 Custom Software method:

Custom software development is the creation of unique technology solutions.
Custom solutions are typically more expensive than out-of-the-box software options.
Custom software development requires a detailed plan. Custom software development is the
designing of software applications for a specific user or group of users within an organization.
Such software is designed to specifically address these users' needs better than more traditional
and widespread off-the-shelf software can. Custom software is typically created just for these
specific users by a third-party or in-house group of developers and is not packaged for resale.

5.9 Generic software

Different steps are used in generic software
1. Requirements analysis and definition
2. System and software design
3. Process and unit testing
4. Integration and system testing

59
5. Operation and maintenance
6. Not specified one person only
7. All queries are applied
8. Benefits for unknown persons
Generic software are developed for all the persons even who are un know from the computer
word. All necessary conditions are applied for end users and environments that hold all needs of
[Link] 3 Define, develop and support the general steps of the software system
engineering sector

In the definition-
This section focuses on aspects such as knowledge differences, interface settings, existing style
barriers, and requirements for verification standards.

• Development of –
Although this section focuses on aspects such as highlighting the structure of the information
area unit, the software is implemented in the system design, followed by the function of the
interface area unit. Prepared 3 tasks, including regional unit software system style, code
generation and software system testing.
stand by -This section focuses on changes and other aspects related to error correction
improvements attributable to dynamical client necessities, and adaptation in step with the
software system setting.

Fig: 5.4 Generic Software

60
8 .Generic Software
An OS is a generic software layer providing basic services to the applications through the
API, and communication with peripherals devices via device drivers. The benchmark target
corresponds to the OS with the minimum set of device drivers necessary to run the OS under
the benchmark execution profile. However, the benchmark target runs on a hardware
platform whose characteristics impact the results. Thus, all benchmarks must be performed
on the same hardware platform.
Although, in practice, the benchmark measures characterize the target system and the
hardware platform, we state simply that the benchmark results characterize the OS as COTS.
Our benchmark addresses the user perspective, that is, it is intended to be performed by (and
to be useful for) someone who has no thorough knowledge about the OS and whose aim is to
improve her/his knowledge about its behavior in the presence of faults. In practice, the user
may well be the developer or the integrator of a system including the OS.
As a consequence, the OS is considered as a “black box.” The only required information is its
description in terms of system calls and in terms of services provided.

61
Chapter#6

Analytical Review of Requirement Gathering

6 .Analysis Overview

This chapter analyzes the literature in several fields. We first investigate the current
work required for engineering and knowledge acquisition. Section 3 examined these two aspects
and concluded that most current technologies are focused on representing one point of view.
Some recent work has acknowledged this shortcoming. Part of the problem is that skills are
needed to compare views and resolve conflicts between views. The remaining investigations in
this chapter involve conflict areas Let us study the various aspects of the solution. Research in
the field of engineering has also entered one of these areas. The former usually involves the
development of a descriptive language, and some research has been conducted on the required
characteristics of this language. The research on the development framework is more diversified,
and many models have been proposed to model the demand process. This section discusses life
cycle models used in software engineering, and then studies detailed language and modeling
surveys.

6.1 Software Life Cycle

Many models for software development have been proposed, the most common of which is
the waterfall model commonly used in large systems. This process divides the process into
several stages. By preparing one or more artistic effects (such as description, design, code, etc.)
as AIDS management, the project can be completely "signed" at each stage. The effect of the
waterfall model .Influence encourages participants to treat it as an independent part of the
requirements process, which can be isolated from the rest of the software development. The
interface between this step and subsequent steps contains detailed information about the
requirements, which should be a complete and clear description of the requirements. Then in the
requirements phase, consider what the system should do, and [Link] the design stage, consider
how to design. In fact, this division is unrealistic, and even the waterfall model recognizes that
there is an exchange of opinions in later stages. It has been pointed out that without perfect
foresight, the specification itself cannot be changed with the design process. This kind of
predictability is impossible, because the introduction of a software system will actually change

62
its field and people's perception. Raman (1990) suggestion. This uncertainty is a direct result of
nature, and software engineering is actually an attempt to overcome this uncertainty. To illustrate
this point, he introduced three classifications of programs. The description of this type (feature)
is the only certainty and decisive factor .Type P is used to solve some stated problems and
determine success or failure based on the problem statement. With Solve the problem or
implement the type of application (embedded) in the actual field, and judge according to
acceptability, value and satisfaction. Large systems are almost always e-type, so the concept of
accuracy does not apply. The waterfall model is not sufficient for practical applications, because
the program does not allow evolution. Gaddings [1984] proposed an alternative life cycle
modeled on the experimental cycle. He introduced the differences between software similar to
Lehman Brothers, these differences are independent of its domain, so No authentication is
required, and the software depends on the domain and the domain can be changed. He introduced
a life cycle, which is actually a cycle of observation, abstraction, design, realization and
experimentation. The experimental results are returned to the next iteration. The product will be
treated as a derivative product of this cycle, rather than ending alone, leading to error correction
(for the product) and development.
(For periods) There will be differences. For software development, many other models were
explored, including research programming, rapid prototyping, and formal changes. However, in
all these models, even if the requirements are expressed in the description, understanding the
requirements is the first step. Therefore, it is important to review various efforts to support the
compliance process that adopts the life cycle model to be adopted.

6.2 Detailed Language

The study of confirmation language emphasizes the difference between requirements (to be
completed) and design (how to do it). Usually, descriptive language is used to help model future
design decisions without affecting requirements. Already prepared Explain some principles of
interpretation and require that the description must be clear, verifiable and correctable. Their
principles include: action should be separated from action. Descriptive language should be based
on action rather than mathematics. The specification should cover not only the system in which
the software is located, but also the environment of the system. These explanations Hope it can
be operated. Due to the need for flexibility, they proposed loose interpretations and provided
many rules for descriptive language. Must be able to describe the language: entity and event

63
models in the domain with constraints and assumptions. Dealing with the concept of the real
world (natural species) without causing confusion or contradiction; and represents the passage of
time. In addition, it should support abstract processes, and it is better to detect contradictions by
allowing redundancy.
Finally, these details should be easy to learn and read and easy to use. Although people have
generally reached a consensus on the general importance of these principles, there are also
differences on how to implement these principles. For example, there is a conflict between
localization expectations and suggestions that redundancy should be encouraged to help test
consistency. Some authors suggest that duplication of information should be avoided because it
inevitably leads to contradictions. Others say that it helps find errors and reduce aggregation. The
detailed information language must provide form and expressive ability, which is a characteristic
of honor. The power of expression supports the modeling of requirements and at the same time
provides formal guidance for the modeling process. Current research is devoted to the
development of a descriptive language that combines these two functions Yes, there are some
differences of opinion between those who support purely formal declarations (such as
Cunningham, and those who advocate an informal degree on the norm), and this is a good reason
for adopting a formal method. The important information they provide discusses the benefits of
accuracy levels, and it is recommended to check for incomplete and inconsistent descriptions
through formal explanations. Use formal words to disambiguate .It may be confirmed later. The
design or implementation verification part finds the components used for verification purposes.
There are many defects in the search requirements description language in the requirements, at
least there are no defects in the use of unnatural symbols. Explain some reasons why the current
official industry language has not yet been adopted in the industry. These include unnaturalness,
illiteracy, fluency (the language is still developing), lack of structure and controversial words.
First, formal descriptive language and conventional methods are needed to guide and organize
descriptive activities. Early description languages were mainly created for program functions,
aiming to simulate the language to which the programmer belongs. Among them, CLEAR is a
common example
These languages can describe data structures and operations functionally, rather than
implementation. This allows designers to discuss the characteristics of different programming
concepts and provides a basis for proving that a particular implementation satisfies a particular

64
behavior.A rich description language alone is not enough to support the description process. The
large-scale system description itself is huge and invincible, which is difficult to express and
understand [Father 1987]. In addition, many descriptive languages, especially the more formal
languages, require a lot of skills. The clarification process should be supported, which should
include guidance and guidance to identify needs. Where possible, this guide should be
formalized to achieve a certain degree of automation. It believes that software development
should be treated as strictly as the software itself, and software processes can be coded in the
same way as programs. The advantage of this is that the process becomes a physical entity,
which can be closely observed and possibly reused. Of course, this formal procedure is better
than providing a manual. However, there are warnings that software development has its
limitations in terms of programming, especially when the programming language severely limits
the way to solve the problem. Since many parts of software development involve some form of
creativity,
Unable to model. However, this is unlikely to provide any guidance in gardening, and it is
important to accurately document the decision-making process.
The experimental research conducted by the analysts at work shows the degree of attitudes that
need help. For example, Ficas, Collins, and Olivier [1987] studied analysts who analyzed
customer interviews and observed many techniques, including anxiety (such as competition,
automation effects), and minimized Improved search and summarization. Consumers are asked
to ask in detail rather than accept the price, and an important part of this process is to create an
initial model to present to the customer.

6.4 A Common Use of Formal

Specifications are to enable changes to occur. To discuss the development of a program, it can
be considered as a series of changes that caused it to be inaccurate. Conversion systems usually
use a broad-spectrum language in which implementation becomes a process of reform [Wile
1982]. Usually, the human designer will select the appropriate changes that can be performed
automatically. Since the implementation is derived directly from the specification
It has been completed, so it can be proved that it meets the specifications. However, the change
method usually assumes that an accurate change library can be created, which may not be
possible, especially because many changes will depend on the domain. From the initial

65
abstraction to the detailed description, the description process itself can be regarded as a series of
changes.

Fig : 6.1 Analytical Gathering

Individual changes either contain more detailed information or explain existing parts. However,
in this model, saving changes is not accurate and cannot be verified. Instead, the focus is to
consider the mentality that led to the creation of specific parts of the specification, so these parts
will be verified against actual needs. Wings [1987] demonstrated this method of developing
specifications; it showed how to consider the greatest degree of simplification

6.3 Leads to a More Detailed Description.

There is evidence that human designers work in this way, starting with a simple model that
ignores errors and oversimplification, and then slowly explains the details. There are some
restrictions on using the change method. First, if you use the change itself to create the
description, then there must be a starting point that can be written directly. For many troubles, a
simple program has not been designed yet. In addition, changes are used in one part of the
specification; so many checks are needed to check for side effects in other parts of the very
complex description.
The field of knowledge acquisition has become so recognized that the most difficult part of the
formation of a knowledge-based system is the accumulation and representation of knowledge.
Bose [1986] described a knowledge-based system as a system that uses clear symbolic
knowledge isolated from inference methods to solve problems. Generally, such systems use
high-speed prototyping modes provided by domain experts to help improve their repeatability.

66
This purification. Some interactive systems have been built to help with this process. For
example, Tiresias [Davis 1979] had a dialogue with experts, accepted knowledge to integrate
into the foundation, and pointed out how the system can adapt to new principles to guide the
process, thereby affecting conditions.
This tool makes extensive use of meta-knowledge to reason about the knowledge contained in
the system. However, since it is based on a governance system and does not seek to derive or
improve its principles, it requires the greatest cooperation of experts. The ADVISE system plays
a similar role, but uses multiple representations (all three methods have been implemented: rule-
based conceptual networks and relationships database). It also includes styling tools for sample
sets. Richter described many projects that tried to accumulate knowledge from various sources,
including the term "infeasible production system." Combine several active ingredients to form a
nucleolus that can increase new production rules. The main feature of these experiments is to
interact with experts through mixed active dialogues. In other words, the system needs to have a
deep understanding of what needs to be understood and plan its way of retrieving information.
This conflicts with passive expert system tools that require more work than experts.

6.5 Clause:
Before we explore other areas of conflict resolution, it is helpful to introduce appropriate
terminology. We will discuss conflicts between the parties, because conflicts can occur between
individuals, groups, organizations, or even between different roles of a person. Similarly, when
discussing dispute resolution, we will deal with the parties involved in the resolution process to
cover similar diversity. Not everyone involved in the conflict is necessary.
All parties must participate in solving the problem. The method of resolving disputes is a
solution. Methods include negotiation, competition, mediation, coercion and education.
Not all disputes need to be resolved, because not all disputes need to be resolved. Three main
solutions can be distinguished: collaborative (or collaborative) methods, including negotiation
and training. Competitive methods, including combat, coercion and competition, and third-party
methods, including mediation and appeals. Negotiate to explore possibilities to resolve dispute.
There is a style of cooperation. Its characteristic is that participants try to find a solution that
satisfies all parties as much as possible. This method is called diversified behavior or
constructive negotiation (to distinguish it from distribution or competitive negotiation). The
definition of negotiation is not universal. The author likes to limit the negotiation to its

67
diversified types, the process of bidding and granting concessions, so it is better to attack it with
an integrated approach. We tend to define negotiations more broadly and call the concession
process bargaining. In addition to negotiation, there are other ways of cooperation. Some
conflicts can be resolved through education, Participants have a better understanding of the
problem, or can easily understand each other's perspectives. Another important technique is to
correct the problem so that it disappears or becomes unimportant. On the contrary, the focus of
competition is to maximize the satisfaction of participants regardless of the satisfaction of other
parties. However, the method of competition is not necessarily adversarial. An extreme form of
competition is when all the advantages of one party are at the expense of the interests of the other
party, which is interpreted as zero in game [Link]-party resolutions cover any situation
where participants cannot resolve disputes with each other, so they must resort to external
sources, whether it is a rule book, an authorized person or a coin toss. This situation can be
resolved through negotiation or the breakdown of competition. There are two types of third-party
solutions.
Considering the matters of the case raised by each participant, we can explain it in judicial terms.
And those where the decision is arbitrary (such as a coin toss) or factors other than the case
presented (such as the relative status of the participants) are called extrajudicial. Bidding and
bargaining are all stages of the resolution process. Bidding is usually where the participants state
the required settlement terms based on their relative bargaining power. Significance In most
solutions, bidding is done in one form or another, because participants must state their own
situation, although in methods such as mandatory, bidding can be unilateral or implicit of.
A position is a set of conditions in which participants bid and commit themselves. In bargaining,
participants seek satisfactory integration of bids. In the simplest case, bid and reply
It involves a rich sequence, and at the other extreme, participants try to mix complex bids
together. Please note that a satisfactory description of the results depends on your point of view.
However, bargaining is often compromised, and truly constructive negotiations seek to develop a
new solution that fully meets the requirements of all participants.
One area of game theory and decision theory is its basic research on how to integrate individual
preferences into group decision making. Much of this work started in his paper, the standard of
which is to test different ways of combining personal preference rankings. Arrow seeks
philanthropic methods to explain the problem in a "fair" way, or to combine personal preferences

68
with social preferences Yes. A good welfare working condition proposed by Arroyo is as
follows:
1. Describes each possible combination of personal preferences.
2. On behalf of, if only one person changes their preferences in one direction, then social
preferences should not change in the opposite direction.
3. Get rid of irrelevant choices, because the social preference between the two choices is not
affected by the position of any other choice in the personal preference. Apply. Not imposed, it
contains some personal preferences. The existing ones will implement all possible social
preferences indicated. There is no conclusion yet, and no individual prioritizes social
preferences. , So no welfare work can satisfy them. Subsequent work studied the consequences
of relaxing this situation. Although no single principle can meet all Arrow's requirements, some
principles are still more acceptable than others. Discuss the most popular way to determine the
priority of society over the majority system. Largest majority rule. The problem is that it can
create collective priorities. For example, given three options x, y, and z, society may eventually
prefer x over y. From y to z and Z2X. Los and Haifa also pointed out that even if only one social
choice is needed (which is usually the case in politics), and only two choices can be offered at a
time, this order of voting will affect the final result. Zillion [1982], in Airport’s freedom to insist
on irrelevant attributes. When asked, he cites empirical research that shows that including
available options can further reveal the power of personal preferences and change their
perceptions of what is desired. On the contrary, Zillion put forward his own ideal theory of
homelessness. Everyone categorizes the options, and each person's highest ranked alternative
(unrecognizable) combination is used to guide the search for possible combinations.
The alternative that is closest to this ideal will be selected. Although working in team decision-
making expands the scope of decision-making to deal with multiple decision makers, it is still
troubled by the assumption that all options are known in game theory. For example, although it
may help determine which candidate was selected in the election, it does not consider whether
other candidates did not participate in the election. But who is more popular among everyone.
Similarly, depending on the design, we usually don't have to worry about deciding which of the
various options should be prioritized.

69
Computer Aided Cooperative Work (CSCW) studies how to use computers in collaborative
activities. This field was not recognized until the early 1980s, although its ideological roots
extend to Engelbert's work [Engelbert 1963]. It eliminates the computer itself
From a perspective, not as a driving factor, but as an enabling technology, we have studied how
to use this computer between people and between people and information resources. CSCW
divides research into two areas: real-time collaboration and unwavering collaboration. Previous
research has also shown how to use computers in meetings in order to use electronic media in
face-to-face meetings. And promote remote meetings. Asynchronous systems are used to connect
long-term working groups and provide new communication channels between colleagues. These
include emails, bulletin boards, and hypertext. CSCW focuses on conflict resolution because it
provides various tools designed to improve team collaboration and therefore conflict
management. Although some conference support tools (such as Xerox PARC) solve these
problems, most of them have conflicts and are sometimes more related to Idea's partner
organizations. Ecolab is a test meeting room that uses a high-resolution screen to change the
characters on the whiteboard. Of interest are the two software tools provided here, which can be
used to create sketches in collaboration with dialogues and papers. This Although some
conference support tools (such as Xerox PARC) solve these problems, most of them have
conflicts and are sometimes more related to Idea's partner organizations. Ecolab is a test meeting
room that uses a high-resolution screen to change the characters on the whiteboard. Of interest
are the two software tools provided here, which can be used to create sketches in collaboration
with dialogues and papers.
Summary
This chapter outlines work in many related fields. The first part discusses the need for
engineering methods, divided into language work and standard process work. These two areas
are complementary: the requirements for success depend on the complete representation of
engineering and appropriate methods. The verification process is divided into several modes,
including procedures, planning and conversion. When acquiring knowledge in Section 3.2, and
Discussed the work related to special techniques using fictitious knowledge. However, all of
these methods have encountered a mistake, in which they focused on developing the same
explanation and representing the same point of view. Part of the problem is that the current

70
method does not support the negotiation process. If a permanent explanation is needed, then the
formation of knowledge.
All disputes must be resolved first. These methods are sensitive to the conflict pressure issues
described in this chapter because they illustrate recent work that recognizes the need to resolve
conflicts in knowledge acquisition and requirements engineering. The former recognizes the
value of using more than one expert and focuses on how to integrate the knowledge of multiple
expert into the knowledge base. The back center needs to consider the needs of multiple people,
and introduces the concept of perspective as a way to represent multiple perspectives. In the
work, two main issues were raised.

6.6 The Concept Of Is Interdisciplinary Research Infrastructure:

The concept of a pre-existing (interdisciplinary) research infrastructure was created for the
strategic interaction of actual agents. It aims to provide a comprehensive overview and complete
incentives. Although this article focuses on most people, synthetic agents are also considered.
Human factors can be used to transform people to imitate human strategic interactions. In both
cases, artificial formulations can reduce costs, directly control their structure, and are widely
deployed and almost unlimited. In order to avoid incomplete information, the strategy (which
may complicate the use of strategic reasoning) is to use a clear form. Since it may be wrong to
formalize a strong strategic interrelationship, it is appropriate to reverse it appropriately. Existing
games need to establish a solid strategic engagement. This is a game based on game recovery
and software.
Recovery is almost always inaction. The design of this mechanism is tantamount to solving the
game-adjusting the game to a preconceived notion. If the game cannot be understood, the
mechanism design will be useless. In real life, movement is carried out through physical
conditions, non-participating subjects, self-participating subjects, or a subset of the previous 3
events.
1. Can go. If participating agents are (partly) responsible for paying for the game, they should
prioritize the benefits of "fraud". Non-participating subjects responsible for game perception
can also be considered rational. For example, in situations where the prisoner is suspicious,
the lawyer maintains his position where the prisoner is familiar with the suspicious reader, so
as not to damage his reputation.

71
6.6.1 Speed Up the Calculation:
Balance-like constants can be used to reduce balance counting time. This feature has been
known as the official custom capture of Sus Connect Games and should also be provided by
IGDL. The reduction in calculation time using compact representations also applies to
gameplay algorithms and can be considered in the context of game management. Reusable
and comparable. The game also forces A to reuse a language and compare game algorithms,
as suggested by Peel [35]. This also applies to game solving algorithms [7] and non-
solving/algorithmic algorithms.
4. Reusable and comparable.
5. Interdisciplinary human [Link] should be prevented from becoming a scientific form
of artificial game theory and will not lead to the ``toy game'' criticized in AI literature [8].
The graphical representation of the game can be used even better.
4. Decide. This function should be provided for IGDL to ensure that the calculation of the
result is definitely over [38] It is important to solve the game/game [Link] is also
important that they can calculate the result of the action.
5. Universal compact interchange format.
For example, at the international A-D category level, IGDL should meet the requirements of
a compact interchange format. At the same time, IGDL should be as general as possible,
where the ability to display incomplete information is the most common. Finally, examples
of all the above categories should at least theoretically conform to the IGDL to facilitate their
effective mutual alliances.
[Link].
Time is still an issue that cannot be ignored in a wide range of forms. It is conceivable that
by comparing the game with fast games and chess, the 117 times given in the decision affect
them. Therefore, time needs to be added to IGDL through clear rules to detect time-related
details. Otherwise, the duration of a series of actions is the same. It may depend on how the
current game is implemented, so it will not be provided in advance with the game. Some
examples can be provided to use IGDL. For the first example, an IGDL-compatible chess
player algorithm can be added to the system, which can compete with other chess-like games
described in IGDL.

72
 6.7 Submission Requirements (Data and Process)
An important part of successful project management and application development-
happiness. The team’s chaotic report shows this. Although the importance of collecting
requirements for application development has been recognized, it has not yet been fully
explained. Need to meet the needs of the process or develop methods to improve the process
Budgets and resources are tight, time pressure is constant, and companies continue to require
changes, enhancements and new services. There are some organizations that are not
[Link] is still a misunderstanding that reducing this activity will shorten the
development effort and save costs. But in the end the result is just the opposite. In the 1970s
and early 1980s, many organizations were entangled. Business statistics and system
requirements are not specified at startup. The development project caused considerable costs
during the software development life cycle (SDLC) stage. The reason we now know is that
analysis activities are easily transferred In the second phase of SDLC, this will result in
additional workload and rework. During design, coding or testing, something that should be
resolved during analysis was discovered. Time wasted, increased workload (due to
fluctuating effects of required changes), and increased project costs. In addition, changes in
demand during rehabilitation will increase costs As well as progressive activities, the
company currently spends an average of 70% of the department’s budget. Expense ,demand,
demand. Requests: Requests I spend Information planning. The system information planning
framework used by many organizations needs to be collected and recorded as a basis.
Collecting data processing needs is part of it.

6.7.1 Analyst Qualifications

Interview subject matter experts and needs
Organize complex information into understandable topics
Ensure stakeholder participation at all levels of participation
Draft clear and concise written documents for users and technicians
Successfully cooperate with a multifaceted team
If the company doesn't have time to fix it for the first time, when will they have time to fix it?
Taking time to analyze methods that interfere with product delivery is not the solution anyone. In
this highly competitive world, IT departments (customers and consultant partners) need to
respond better and faster, otherwise our customers will look for other providers. Nowadays, you

73
need a mechanism that can quickly, accurately and fully meet consumer needs-a standard that
can provide a flexible and serious method for high-quality manufacturing. Details, every time. It
is important for companies to meet business requirements to comprehensive business
requirements to see if application development can be successful. Activity.

6.7.2 Explain the Customer’s Business Needs

There is no doubt that these are some of the big questions we have to ask ourselves to ensure
that we develop the highest quality system that meets the needs of our customers. This is an
driving goal of our approach. Analysts need to research and solve the systematic application of
the best interview and modeling methods. Capture correctly "How do you quickly and easily
determine customer needs?" Many experts recommend using methods based on understanding
business representatives and business data to conduct requirements discovery meetings with
business representatives and experienced information management analysts.
RDS is not an interview with traditional requirements. It focuses on business, communication
and modeling techniques that should be proven and easy to use.
. A simple and systematic approach allows analysts and business users to discover all
information requirements, business rules and functions, thereby
Complete and accurate business description for the first time.
There is no panacea for this problem, but the key to success lies in the application of the
application. In order to maintain consistency, business details need to be accurate, complete and
clear. The following is a list of characteristics that represent quality and standard business
requirements.
Correct:
Are the requirements consistent-do they conflict with other requirements?
Are there any requirements that conflict with the prescribed assumptions or constraints
(business environment, technical environment, cost, schedule, and resources)?
• Do the requirements support the business, system and project goals?
Are all activities and activities necessary? Are there any definite requirements or out of scope?
Does the data require all data requirements? Does anyone want or is out of scope?
Full:
• Are the goals and objectives of the system clear and fully defined?
Are all incidents and situations handled?

74
Did all explain all the operations? Are they sufficient to meet the goals specified by the system
Does Ac define all the items and data contained in the activity details in the model?
What definitions and rules are needed for objects and statistics?
• Does the description meet the level of detail required by the team?
Is the resolution determined for the solution all undefined, resolved, and incomplete
specifications
Clear: Implementation Are all requirements not fulfilled (not limited to specific design
alternatives. Are all requirements clearly and concisely stated?
Are all actions described in terms of triggering events or situations, information requirements,
processing and results?
Can business customers/consumers understand terminology and prose?
Are there ambiguities in the statements (operations, rules, definitions, etc.)
Are all assumptions clearly stated?
Complain• Do you use Schemer Group's information management methods?
• Whether the supply meets the organization's standards, whether it meets the organization's
process goals, and whether it complies with industry standards. In the final analysis, using the
business requirement aggregation method, the organization will be able to collect, separate,
prioritize, and analyze. The application under design requires information and processes. This
understanding of business data and process requirements will lead to a usable, robust and
sustainable system
The organization has a competitive advantage.
Components:
When meeting with stakeholders to discuss the project, the project will be provided, so it is
important to collect highly accurate information to ensure the success of the project
Each project may need to use multiple technologies to gather the necessary information. The
technology used will depend on the applicability of the [Link], we explored some
different project requirements submission techniques that can be used to meet the requirements.

75
Workshop
Seminars are more structured than brainstorming and allow you to collaborate to document
stakeholder needs. Documents are prepared here, which may include static and active feedback
Interview:
Interviews with stakeholders are probably the most common technique. In order to execute and
complete a successful project, it is important to fully understand the expectations and goals of
stakeholders.
There are many things to keep in mind during the interview: Consider the point of view of the
perspective person. One stakeholder may consider it important, while another stakeholder may
not see it .Openness Ask open investigative questions and ask stakeholders to explain any areas
that need clarification.
How to investigate?
When considering the use of questionnaires or questionnaires, the main choice is to use paper or
software copies to collect information. Online softcopy has a clear cost advantage because it
does not require or will not require data entry in the future. However, if not all stakeholders have
access to reliable computers and the Internet, hard copies can increase access.
Once you have determined the useful function of presenting the questionnaire, you will consider
the nature of the question you are asking. Once you have determined the useful function of
presenting the questionnaire, please consider the nature of the question you are asking.
Some examples of survey questions include:
The error scale allows the respondent to choose a position, such as "strongly agree, agree,
neutral, disagree, disagree". It can help you understand attitude, but it can also bring a positive
response .Through scoring and ranking, your interviewees can choose a 0-5 or 0-10 level answer
that is easy to understand and analyze, but this information is your default list, not just
independent data. The Product Owner is responsible for communicating the vision of the product
to the development team. He or she must also represent the customer’s interests through
requirements and prioritization. Because the Product Owner has the most authority of the three
roles and also has the greatest responsibility. In other words, the Product Owner is the single
individual who must face the trouble when a project goes awry and also must answer questions
from the team the Product Owner is responsible for communicating the vision of the product to
the development team. He or she must also represent the customer’s interests through

76
requirements and prioritization. Because the Product Owner has the most authority of the three
roles and also has the greatest responsibility. In other words, the Product Owner is the single
individual who must face the trouble when a project goes awry and also must answer questions
from the team the Product Owner is responsible for communicating the vision of the product to
the development team. He or she must also represent the customer’s interests through
requirements and prioritization. Because the Product Owner has the most authority of the three
roles and also has the greatest responsibility. In other words, the Product Owner is the single
individual who must face the trouble when a project goes awry and also must answer questions
from the team.
•Checkboxes and safe deposit boxes
A set of default answers allows you to control more data about unresolved problems, but still
limits the creativity of the feedback you receive.
•text box
By giving you the correct answers, you can give your interviewees complete control over what
they say, but this time can be wasted on analysis and classification.
What are the benefits of conducting a survey?
In general, surveys can provide you with different data sets. This makes it easier to analyze and
present the collected information in the form of graphs, charts and information graphics. You
will have a data set with little room for interpretation. For example, there is no need to translate
any body language during the conversation.
Another advantage of using surveys is that you can invite everyone involved in the project to
participate without having to set up a representative sample. When stakeholders feel more
valued, this can increase their participation.
There are no disadvantages to using surveys
The needs analysis includes:
The work to be done when determining the requirements or conditions of a new or modified
product or project should take into account potential conflicts of requirements, analysis,
documentation, verification and management software or system requirements of different
stakeholders. The goals of the initial phase of the software project are:
Operation method:

77
The system requires software engineering tasks to narrow the gap between engineering and
software design.
3. orthogonal views:
The model provided by the software designer
• System information (static view)
Function (function view)
• Behavior (dynamic view)
Software architecture:
The model can be transformed into data, architecture and component-level design.
Diagnosis and growth process: some design is needed in the analysis process, and some analysis
is needed in the design process.
For software developers, the biggest challenge may be to share the views of the final product
with users. All stakeholders of the project-developers, end users, software managers, customers
• Manager
-Must have a general understanding of the function and purpose of the product, or be
surprised when delivering the product. Software surprises are almost never good news.
• Therefore, when we define the requirements of software products, we need some methods
to accurately capture, interpret and represent the voice of consumers.
• Needs analysis
Requirements analysis is essential to the success or failure of a system or software
project. The requirements should be recorded, operable, measurable, verifiable,
identifiable, related to the identified business needs or opportunities, and described in
detail for the system design. Conceptually, needs analysis involves four activities
[Link] for use:
Communicate with users and consumers to determine their needs. This is sometimes
called meeting demand.
Claim.
Demand analysis
Determine whether the demand is ambiguous, incomplete, ambiguous or contradictory,
and then solve these problems.

78
 1. Requirements modeling:
Requirements can be recorded in various forms, such as natural language documents,
usage problems, user cases or process descriptions.
Review
Review and frustration: Team members consider recurring things and determine steps for
improvement. Requirements analysis is the work of the team, which requires engineering skills
in hardware, software, and human factors as well as expertise in dealing with people. The main
activities involved in the needs analysis are:
Customers identify customer needs.
Assess the feasibility of the system.
Do economic and technical analysis.
Assign functions to system elements.
Timetable Set timetable and constraints.

6.8 Technology to Discover Business Needs:

Use BPMN or Archimedes to analyze gaps People usually refer to space as "the space between
where you are and where you want to be". Gap analysis is the process of comparing the baseline
and target business scenarios. In other words, difference analysis is to study what the company is
doing now and where it will go in the future, and conduct research by bridging the gap between
the two. The purpose of gap analysis is to identify gaps in improved performance. It provides
business insight into potential improvements. It answers questions such as what is the current
status of the project.

6.8.1 Customer Travel Map

This is a powerful technique for understanding customer motivations. What are their needs,
their hesitations and concerns . Although most organizations are quite good at collecting data
about their customers, data alone will not make experienced customers feel frustrated and
experienced. Use the storytelling and visual effects in the customer travel map from time to time

6.8.2The same is true for Customer Relationships.

This story is told from a consumer's perspective and provides insights into the overall customer
experience. When customers experience your product or service, it can help your team better
understand and solve customer needs and pain points. In other words, customer journey mapping

79
gives your business the opportunity to understand how your brand first attracts potential
customers, and then look at the touch points throughout the sales process. Finally, the team can
propose improvements or measures for each touch point. These suggested measures may
potential source of software requirement.
.Key results: Respondents want to see a unified interface and indicate that the interface must be
easy to use and usable outside of campus. The priorities of the various aspects of research
activities are as follows:
1. Search and retrieve published information, such as articles, essays, monographs, etc.
2. Understand funding opportunities; apply for funding.
3. Cooperate with partners in universities or other [Link] study. Share or store research
results. Improve output stability.
5. Other activities. In these activities, respondents reported the following:
Search Information
Respondents want a simple and easy-to-use tool to search multiple data sets. They also need the
latest search interface. And want to create your own search strategy. Funding: Respondents
wanted to simplify all aspects of the grant management process. They want to be able to find and
review previously suggested suggestions. They hope that the portal environment can inform
them of new financing opportunities. Collaboration: Respondents with shared diary function and
want to access their emails in the port, and want to meet with the administrator, they hope that
through this tool can make them a tool for collaboration on documents and large files. They will
want to know who has these skills. Research results: Respondents hope to find the full text
output from the university publication list and put it in the process so that the full text can be
uploaded to the system. Other questions asked: Jet in other events Important highlights include
monitoring financial expenditures. And facilities for booking conference rooms and other
resources. The results of the user needs analysis set forth the initial priorities for integrating
systems, tools and information into the EVIE portal. These include: a search interface for finding
information; tools to assist in the submission of grants. Collaborative document management
facilities; email and diary access; and the ability to upload full-text documents to the resource
library

80
6.9 Online Survey:
Appendix 2 provides a web form for the survey, in which the original words can be recognized
as a reference, and answers are provided. The high-level design of the questionnaire is as
follows: researcher's self-evaluation o faculty and staff o research qualifications (role)
l .Research all important aspects of the life cycle
Prioritize the options needed in each of these areas
Evaluation without questionnaire o Application of required options provided o Completion of
required options.

81
CHAPTER#7

Conclusion and References

Conclusion
Collect requirements to meet the abilities of different types of users participating in the
research of this article. Increase the use of software and enable users to build trust in the
software. It is expected that the future work will be in academia, and practitioners will
implement and evaluate our design. This chapter introduced however the various varieties of
necessities are often organized. Different software categories are used to develop the
requirements gathering processes or phases. These techniques are use full for the end users or
any persons or developers for gathering the requirements from the customers and practitioners.
All necessary changes are hold in it. Some users cannot understand the requirement it’s on
therefore the developers who makes the software are manage it also of mine the developers are a
special person who manage it carefully that no chance of any mistake in the time of software
development .So this study are useful for different kinds peoples who know the computer or
also for who don’t know anything about computer or its main work all users accept easily and
manage it successfully.
Categorizing the necessities make it easier to develop the question list moreover on determines.
The in information is intended to verify that the manufactured materials can be understood from
all angles. Add a list of questions and processes to the process, turning the framework into a
model (see Appendix B), and the method reflects the scope of responsibility of each role. For
example, the views of designers are very different. It's completely different from the owner's
point of view; the builder's point of view is different from the designer's point of view. Everyone
prepares the request by providing the necessary details to express their point of view.
The owner should be satisfied with the final product. ``Each role involves a completely different
perspective, and all roles form a team to create high-quality products together. When building a
house, each point needs to be considered or read individually. These ideas are aimed at the space
chosen for this method. For example, houses need red for plumbers, red for electricians with
associate degree, red for landscapes, etc.

83
Every have Similar consumables: scope, owner's model, physical model, specifications,
components, and final product. Each method has its own focus on the supply level. In terms of
software package engineering, the main goals include various purposes and unnecessary
requirements. Required fields include "who" (interface association), "what" (data), "where"
(network), "when" (event), "why" (business rule) and "how" (operation). include. Unnecessary
areas and obstacles to commercial equipment and planning. Similarly, there are eight very
different theories in each case, one for each of these eight fields. The important thing is to
understand that nothing can be seen. The "all focus and field of view" area units are very
important for preparing high-quality food. Comply with In order to verify the quality and
conduct business, every reader should have an understanding of the details. Each focus and point
of view requires very different questions. Combining different focuses and ideas requires other
types of associations or types of support that tie all the squares together. For example, once the
house is built, the electrician will talk about it.
They are forced to ensure that they will not affect the needs of plumbers. This requires more
contact between line inspectors and artists. In terms of system engineering, the demand area unit
of the association is designed using hardware and software packages. The FAQ department needs
to link the central goals and perspectives with different target areas and perspectives. We need to
expand ourselves

[Link]
The customers' wants in an exceedingly computer code project are known within the method of
computer code necessities elicitation. For building a code this method is taken into account in
concert of the foremost necessary elements. In this half it's set exactly what's going to be
engineered. A detailed interaction between developers and end-users of the system is required by
requirements’ gathering. Conferences will be pricey, inconvenient and occasional if developers
and end-users are completely different in several in numerous} organizations or different cities.
The standard of the induced requirements will greatly be wedged if there's a retardant of
communication. Demand induction may be a process troublesome to scale to massive computer
code comes with several stakeholders that involve characteristic and prioritizing necessities. A
neutral is a private or the giggling WHO will be affected by the success or failure of a project.
There are not many ways to find and rank demand. There are three main problems: data
overload, insufficient input from stakeholders, and prioritization of requirements. There are not

84
many current customization and classification methods. Prioritize current needs. Ways need
substantial efforts from {the necessities the want the necessities} engineers once there are several
requirements. to handle the problems neutral recommender model can contain ssteps:-Identify
the massive project, Analysis of requirements, determine and rank stakeholders, Predict
necessities, rank necessities. For making predictions, our approach can use one in all the
foremost acknowledge algorithms that's k-Nearest Neighbor (KNN) algorithmic program. KNN
is employed to spot similar Users with similar scoring history records to predict the scoring of
unsafe user item pairs.
KNN has found a new set of communities for every user with similar and interesting functions.
To do this, compare all efforts of the user profile with the measured degree. Create a neighbor
for each user by selecting the most similar users. The predicted level of similarity between each
attempt of the user profile due to the predictive user. Finally, Main reason behind any failed
project pertains to incomplete requirements specification and adopting improper requirements
management techniques. It is also the main reason for cost and schedule overruns which
ultimately induce conflicts with the clients. The success of a project heavily depends on
effectively managing the five key factors time, cost, performance, user satisfaction and its overall
impact on the entire organization. To establish requirements elicitation process, building the
requirements management team becomes necessary when effective project communication starts
and roles and responsibilities are defined. A requirements management team should consist of
system architects (to design the system architecture), end users, business domain experts,
consultants (having strong knowledge of new technologies), management and developers.
Testing the application logic and interviewing the domain experts. Moreover, workflow
diagrams, system architecture description, interface description and business process description
are developed in this step. The third step is the elicitation of new requirements in which
introspection or coordination of end user and experts is elaborated and documentation of desired
requirements is prepared. The fourth step is the analysis phase which involves setting priorities
for requirements verification and validation. The fifth step in this process is change management
in which necessary documents are prepared with the help of end users and domain experts. This
step iterates back with the third step. Whereas, to model the change management process for
development based on legacy system functionalities, new change request can be made by the
software engineers, end users and change control board. If the change request is within the scope

85
then it will go to requirement implementation phase or otherwise it will be shifted to
implementation phase. Present an opportunity tree through which defects are managed and
solutions are provided. A relationship is developed between the defects and their causes.
Software processes are being studied for improvement since a long time. All the software
requirements must be defined to develop high quality software. The basic technique used is
requirements elicitation which is a critical part of the project and different techniques are
required to determine the requirements. Fundamental way is to perform analysis in order to
identify people, processes and different resources involved in the project. Defects are defined as
a special type that represents the specific product in relation to the processes. Large scale
projects have thousands of defects and are found at different stages of projects. There are many
tools that are used to minimize the defects. The defect removal efficiency is used to represent
total number of defects found at one stage. Analytic hierarchy process is also used for
formalizing the decision making process. The concept of defect management is to estimate how
the defects change during the development phase. For this purpose, opportunity tree is
introduced to select main goals, sub goals, decision goals and eventually making questionnaire
for verification, as well as suggesting solution to design the opportunity tree. Different ratings
are used for defect data collection and identifications of items. Different defects are efficiently
analyzed using the defect management opportunity tree. Defect removal efficiency analysis
makes it easier to find the defects relative to the stages of the development of project.

7.1 Case study

ISO 9000 provides a framework that can be used by any size or type of organization to develop
a quality system. Today, ISO 9000 standards are rapidly being implemented in many service
industries such as educational institutions in particular. Benefits from implementing ISO 9000
standards can be divided into four different parts as benefits to system, faculty, students and
external benefits to the organizations. Today, customers expect quality in all aspects of life. The
customer wants to be assured that educational institutions provide quality service. This is an era
of competition and globalization of knowledge much importance is given to the quality. As a
result educational institutions have started implementing ISO. Quality and accountability in
higher education are inevitably going to be the principal themes in the higher education policy.
The objective of ISO documentation is mainly to provide the service continuously as before even
though the Institution decides to replace personnel all together. The control of documentation is

86
the critical element to retain the ISO registration. So, good customized software is required to do
the documentation process efficiently and effectively.

7.2 Acceptance Test/Criteria

As a vital part of the planning our project, user stories define what we are going to build in our
project. User stories are prioritized to indicate which are most important for the system and are
broken down into software engineering tasks and estimated by the development team. When we
implement a user story a more formal acceptance test will be written to ensure that the goals of
the story are fulfilled. Acceptance tests are created from user stories. Acceptance criteria are
specified indicators or measures employed in assessing the ability of a component, structure or
system to perform its intended function. They are the expectations of the product owner on what
will be delivered. Acceptance criteria can include functionality that the system will perform,
interface look and feel and necessary documentation. These are high-level tests to test the
completeness of a user story or stories 'played' during any sprint/iteration. These tests are created
ideally through collaboration between business customers, business analysts, testers and
developers; however the business customers (product owners) are the primary owners of these
tests. As the user stories pass their acceptance criteria, the business owners can be sure of the fact
that the developers are progressing in the right direction about how the application was
envisaged to work and so it's essential that these tests include both business logic tests as well as
User Interface validation elements (if need be). Acceptance test cards are ideally created during
sprint planning or iteration planning meeting, before development begins so that the developers
have a clear idea of what to develop. Gathering, understanding and managing requirements is a
key factor to the success of a software development effort. Requirement engineering is a critical
task in all development methods including the agile development method. There are several
requirement techniques available for requirement gathering which can be used with agile
development methods. These techniques concentrates on a continuous interaction with the
customer to address the evolution of requirements, changing requirements, prioritizing
requirements and delivers the most important functionalities first. This article presents an
overview of agile software development methods and a best requirement elicitation technique
used for requirement capturing. We present an application case of requirement gathering process
by using User stories for webbased, cost-effective and efficient software which automates the
ISO documentation of teaching process at the institution SNGIST using SCRUM, an agile

87
software development methodology. Requirement gathering is different for different methods,
for. E.g. in SCRUM & XP, user stories are used. Requirement specification is an iterative
process that continues until the customer is satisfied with the product. By using this method, it is
easier to react to changes and can have a better estimate and better control on the development
leading to a better quality product and customer satisfaction. Since Agile development is a fairly
new technique there is no good answers on how to handle requirements and researches are being
undertaken in this area.

7.3 Extreme Programming

Extreme Programming abbreviated as XP, was invented by Kent Beck which addresses the
specific needs of software development conducted by small teams in the face of vague or
changing requirement.

88
Expected level of the item is set according to the expected price, and where there are restrictions
on the recommended items, the first n items are displayed as the user's suggestion.

References

C-W Lu, W. C.-H. (2007). “A Modelbased Object-oriented Approach to Requirement.D.

Pandey, U. S. (2010). , “An Effective Requirement Engineering Process Model for Software
Development and Requirements Management”, International Conference on Advances in Recent
Technologies in Communication and Computing (ARTCom, 2010), pp.G. Lu and F. Yuan.
(2010). “Comparison of Requirement Items based on the Requirements Change Management
System of QONE”, Second World Congress on Software Engineering (WCSE), Institute of
Computer Technology, Chinese Academy of Science, Beijing, China Volume 2, [Link], J. M.
(1970). , Quality planning and analysis: From product development through.

V. Pavanasam, C. S. (2008). “Membrane Computing Model for Software Requirement

Engineering”, Second International Conference on Computer and Network Technology
(ICCNT), Sathyabama University, Chennai, India, pp. 487 - 49-

X. Jiang. (2008). “Modeling and Application of Requirements Engineering Process Metamodel”,

IEEE International Symposium on Knowledge Acquisition and Modeling Workshop (KAM
Workshop, 2008), Department of Commanding Communication, PLA Commanding
Communication Acad.

Young, R. R. (2003). , The Requirements Engineering.

E-S Lee and J-M Bae, “Design Opportunity Treefor Requirement Management and
SoftwareProcess Improvement”, International Conferenceon Multimedia and Ubiquitous
Engineering(MUE'07), Soongsil University, Seoul, pp. 395 -400, 26-28 April 2007.
Murphy, D. Phung and G. Kaiser, “A DistanceLearning Approach to Teaching
eXtremeProgramming”, ITiCSE, June 30-July 2, 2008,Madrid, Spain. ACM. 2008.
J. Cheng and Q. Liu, “Using Stakeholder Analysisfor Improving Statechart Merging in
SoftwareRequirement Management”, The 9th InternationalConference for Young Computer
Scientists(ICYCS, 2008), pp. 1217 - 1222, School ofSoftware, Tsinghua University M. F. Tchidi
and Z. He, “The RequirementsEngineering Process Model Based on Design forSix Sigma”,)The
2nd IEEE InternationalConference on Information Management andEngineering (ICIME, 2010),
Tianjin University,Tianjin, China, pp. 287 - 290, 16-18 April 2010.S
E-S Lee and J-M Bae, “Design Opportunity Treefor Requirement Management and
SoftwareProcess Improvement”, International Conferenceon Multimedia and Ubiquitous
Engineering(MUE'07), Soongsil University, Seoul, pp. 395 -400, 26-28 April 2007.
G. Booch, I. Jcobsan and j. rumbaugh , the unified modeling language , reference manual ,
addison wesely longmann,1999.
[Link] and K .SCott, applying use case driven object modeling with UML , addison -
wesely ,2002.
Bransford, J.D., A.L. Brown, and R.R. Cocking, eds. 2000. How People Learn. Washington,
D.C.: National Academy Press.
Bybee, R.W. 1997. Achieving Scientific Literacy. Portsmouth, N.H.: Heinemann.
Colburn, A., and M.P. Clough. 1997. Implementing the learning cycle. The Science Teacher
64(5): 30–33.
Gil, O. 2002. Implications of inquiry curriculum for teaching. Pa- per presented at National
Science Teachers Association Con- vention, 5–7 December, in Alburquerque, N.M.
Guzzetti B., T.E. Taylor, G.V. Glass, and W.S. Gammas. 1993. Promoting conceptual change in
science: A comparative meta- analysis of instructional interventions from reading education and
science education. Reading Research Quarterly 28:117–159.
Hilgard, E.R., and G.H. Bower. 1975. Theories of Learning. Englewood Cliffs, N.J.: Prentice
Hall.
Karplus, R., and H.D. Thier. 1967. A New Look at Elementary School Science. Chicago: Rand
McNally.
Lawson, A.E. 1995. Science Teaching and the Development of Thinking. Belmont, Calif.:
Wadsworth.
Lawson, A.E. 2001. Using the learning cycle to teach biology concepts and reasoning patterns.
Journal of Biological Education 35(4): 165–169. Mayer, R.E. 1979. Can advance organizers infl
uence meaningful learning? Review of Educational Research 49(2): 371–383. Thorndike, E.L.
1923. Educational Psychology, Vol. II: The Psychology of Learning. New York: Teachers
College, Columbia University.
Copyright 2003. The Science Teacher. Published by the National Science Teachers Association,
1840 Wilson 25) Blvd., Arlington, VA 22201-3000. September 2003 59
Reprinted with permission from "The Science Teacher", Vol. 70, No. 6, Copyright © 2003, by
the National Science Teachers Association (NSTA).

Accot, J. and Zhai, S. 2003. Refining Fitts' law models for bivariate pointing. In Proceedings of

ACM Conference on Human Factors in Computing Systems (CHI'03). 193--200.]]

Akamatsu, M., MacKenzie, I. S., and Hasbroucq, T. 1995. A comparison of tactile, auditory, and

visual feedback in a pointing task using a mouse-type device. Ergonomics 38, 4, 816--827.]]

Apple Computer, Inc. 2001. The “Dock”, a feature of the “Mac OS X” operating system.

[Link] (Accessed 2001--2004)]]

Baldwin, J., Basu, A., and Zhang, H. 1998. Predictive windows for delay compensation in
telepresence applications. In Proceedings of the 1998 IEEE International Conference on Robotics

and Automation. 2884--2889.]]

Baldwin, J., Basu, A., and Zhang, H. 1999. Panoramic video with predictive windows for
telepresence applications. In Proceedings of the 1999 IEEE International Conference on Robotics

and Automation. 1922--1927.]]

Baudisch, P., Cutrell, E., Robbins, D., Czerwinski, M., Tandler, P., Bederson, B., and Zierlinger,
A. 2003. Drag-and-pop and drag-and-pick: Techniques for accessing remote screen content on

touch- and pen-operated systems. In Proceedings of INTERACT'03. 57--64.]]

Bederson, B. 2000. Fisheye menus. In Proceedings of ACM Symposium on User Interface

Software and Technology (UIST'00). 217--225.]]

Bier, E. A. and Stone, M. C. 1986. Snap-dragging. In Proceedings of ACM SIGGRAPH 1986.

233--240.]] Blanch, R., Guiard, Y., and Beaudouin-Lafon, M. 2004. Semantic pointing:
Improving target acquisition with control-display ratio adaptation. In Proceedings of ACM

Conference on Human Factors in Computing Systems (CHI'04). 519--526.]]

Cockburn, A. and Firth, A. 2003. Improving the acquisition of small targets. In People and
Computers XVII: British Computer Society Conference on Human Computer Interaction

(HCI'03). 181--196.]]

Crossman, E. R. F. W. and Goodeve, P. J. 1983. Feedback control of hand-movement and Fitts'

law. Quarterly J. Experiment. Psych. 35A, 251--278. (Original work presented at the meeting of

the Experimental Psychology Society, Oxford, England, July 1963).]]

36) Dulberg, M. S., St. Amant, R., and Zettlemoyer, L. S. 1999. An imprecise mouse gesture for

the fast activation of controls. In Proceedings of INTERACT '99. 375--382.]] Feiner, S.,
Nagy, S., and van Dam, A. 1981. An integrated system for creating and presenting complex

computer-based documents. In Proceedings of ACM SIGGRAPH'81. 181--189.]]

Fitts, P. M. 1954. The information capacity of the human motor system in controlling the
amplitude of movement. J. Experiment. Psych. 47, 6 (June), 381--391. (Reprinted in Journal of

Experimental Psychology: General, 121(3):262--269, 1992).]]

Furnas, G. W. 1986. Generalized fisheye views. In Proceedings of ACM Conference on Human

Factors in Computing Systems (CHI'86). 16--23.]]

Grossman, T. and Balakrishnan, R. 2005. The bubble cursor: Enhancing target acquisition by
dynamic resizing of the cursor's activation area. In Proceedings of ACM Conference on Human

Factors in Computing Systems (CHI'05). 281--290.]] , Y., Blanch, R., and Beaudoui
Lafon, M. 2004. Object pointing: A complement to bitmap pointing in GUIs. In Proceedings of

Graphics Interface (GI'04). 9--16.]]

Gutwin, C. 2002. Improving focus targeting in interactive fisheye views. In Proceedings of ACM

Conference on Human Factors in Computing Systems (CHI'02). 267--274.]]

Gutwin, C., Dyck, J., and Fedak, C. 2003. The effects of dynamic transparency on targeting

performance. In Proceedings of Graphics Interface (GI'03). 105--112.]]

Hoffmann, E. R. 1991. Capture of moving targets: A modification of Fitts' law. Ergonomics 34,

2, 211--220.]]

Hoffmann, E. R. 1995. Effective target tolerance in an inverted Fitts task. Ergonomics 38, 4,

828--836.]]

Jagacinski, R. J., Repperger, D. W., Ward, S. L., and Moran, M. S. 1980. A test of Fitts' law

with moving targets. Human Factors 22, 2, 225--233.]]

Kabbash, P. and Buxton, W. A. S. 1995. The “prince” technique: Fitts' law and selection using
area cursors. In Proceedings of ACM Conference on Human Factors in Computing Systems

(CHI'95). 273--279.]]

Keele, S. W. 1968. Movement control in skilled motor performance. Psychologi. Bull. 70, 6

(Dec.), 387--403.]]

Keuning-Van Oirschot, H. and Houtsma, A. J. M. 2001. Cursor displacement and velocity

profiles for targets in various locations. In Proceedings of Eurohaptics 2001. 108--112.]]

Keyson, D. V. 1997. Dynamic cursor gain and tactual feedback in the capture of cursor

movements. Ergonomics 40, 12, 1287--1298.]]

MacKenzie, I. S. 1989. A note on the information-theoretic basis for Fitts' law. J. Motor Behav.

21, 3, 323--330.]]

MacKenzie, I. S. 1992. Fitts' law as a research and design tool in human-computer interaction.

Hum.-Comput. Interact. 7, 91--139.]] McGuffin, M. and Balakrishnan, R. 2002. Acquisition

of expanding targets. In Proceedings of ACM Conference on Human Factors in Computing

Systems (CHI'02). 57--64.]]

McGuffin, M. J. 2002. Fitts' law and expanding targets: An experimental study, and applications
to user interface design. Master of Science thesis, Department of Computer Science, University

of Toronto, Toronto, Ontario, Canada.]]

Meyer, D. E., Abrams, R. A., Kornblum, S., Wright, C. E., and Smith, J. E. K. 1988. Optimality
in human motor performance: Ideal control of rapid aimed movements. Psycholog. Rev. 95, 3,

340--370.]]

Meyer, D. E., Smith, J. E. K., Kornblum, S., Abrams, R. A., and Wright, C. E. 1990. Speed-
accuracy tradeoffs in aimed movements: Toward a theory of rapid voluntary action. In Attention
and Performance XIII, M. Jeannerod, ED. Lawrence Erlbaum, Hillsdale, NJ. 173--226.

[Link]

Münch, S. and Dillmann, R. 1997. Haptic output in multimodal user interfaces. In Proceedings

of ACM International Conference on Intelligent User Interfaces (IUI'97). 105--112.]]

Murata, A. 1998. Improvement of pointing time by predicting targets in pointing with a PC

mouse. Int. J. Hum.-Comput. Interact. 10, 1, 23--32.]]

Oakley, I., Adams, A., Brewster, S. A., and Gray, P. D. 2002. Guidelines for the design of
haptic widgets. In People and Computers XVI: British Computer Society Conference on Human

Computer Interaction (HCI'02).]]

Oakley, I., Brewster, S. A., and Gray, P. D. 2001. Solving multi-target haptic problems in menu
interaction. In Extended Abstracts of ACM Conference on Human Factors in Computing

Systems (CHI'01). 357--358.]]

Port, N. L., Lee, D., Dassonville, P., and Georgopoulos, A. P. 1997. Manual interception of
moving targets: I. Performance and movement initiation. Experiment. Brain Res. 116, 3, 406--

420.]]

Shoemake, K. 1992. ARCBALL: A user interface for specifying three-dimensional orientation

using a mouse. In Proceedings of Graphics Interface (GI'92). 151--156.]]

Sutherland, I. E. 1963. Sketchpad: A man-machine graphical communication system. In

Proceedings of AFIPS Spring Joint Computer Conference. 328--346.]]

Woodworth, R. S. 1899. The accuracy of voluntary movement. The Psycholog. Rev:

Monograph Supplements (also known as Psychological Monographs) 3, 2 (whole Number 13)

(July), 1--114.]]

Worden, A., Walker, N., Bharat, K., and Hudson, S. 1997. Making computers easier for older
adults to use: Area cursors and sticky icons. In Proceedings of ACM Conference on Human

Factors in Computing Systems (CHI'97). 266--271.]]

Zhai, S. 2002. On the validity of throughput as a characteristic of computer input. Tech. Rep.

IBM Research Report RJ 10253, IBM Almaden Research Center, San Jose, CA.]]

Zhai, S., Conversy, S., Beaudouin-Lafon, M., and Guiard, Y. 2003. Human on-line response to
target expansion. In Proceedings of ACM Conference on Human Factors in Computing Systems
(CHI'03). 177--184.]]

S. Sharples and T. Megaw. 2015. Definition and measurement of human workload. In

Evaluation of Human Work. John R. Wilson and Sarah Sharples (Eds.). CRC Pre

H. A. Maior, M. L. Wilson, and S. Sharples. 2018. Workload alerts-using physiological

measures of mental workload to provide feedback during tasks. ACM Transactions on

Computer-Human Interaction 25, 2 (2018), 9--30.

D. Afergan, E. M. Peck, E. T. Solovey, A. Jenkins, S. W. Hincks, E. T. Brown, R. Chang, R. J.

K. Jacob. 2014. Dynamic difficulty using brain metrics of workload. In Proceedings of the
SIGCHI Conference on Human Factors in Computing Systems (CHI’14). 3797--3806

B. F. Yuksel, K. B. Oleson, L. Harrison, E.M. Peck, D. Afergan, R. Chang, and R. J. K. Jacob.

2016. Learn piano with BACh: An adaptive learning interface that adjusts task difficulty based
on brain state. In Proceedings of the SIGCHI Conference on Human Factors in Computing

Systems (CHI’16). 5372--5384.

S. Oviatt, R. Coulston, R. Lusnsford. 2004. When do we interact multimodally?: Cognitive load

and multimodal communication patterns. In Proceedings of the 6th ACM International

Conference on Multimodal Interfaces. 129--136.

B. Myers, S. E. Hudson, and R. Pausch. 2000. Past, present, and future of user interface

software tools. ACM Transactions on Computer-Human Interaction 7, 1 (2000), 3--28. S.

Oviatt. 1999. Ten myths of multimodal interaction. Communications of the ACM 42, 73) 11

(1999), 74--81.

B. Dumas, D. Lalanne, and S. Oviatt. 2009. Multimodal interfaces: A survey of principles,

models and frameworks. In Human Machine Interaction. Springer, Berlin, 3--26.

S. Fairclough. 2009. Fundamentals of physiological computing. Interacting with Computers 21,

1--2 (2009), 133--145.

P. Petta, C. Pelachaud, and R. Cowie. (Eds.). (2011). Emotion-oriented systems: The humaine

handbook. Cognitive Technologies Series. Springer.

F. Chen, N. Ruiz, E. Choi, J. Epps, M.A. Khawaja, R. Taib, and Y. Wang. 2012. Multimodal
behavior and interaction as indicators of cognitive load. ACM Transactions on Interactive

Intelligent Systems 2, 4 (2012), 22.

S. Chen and J. Epps. 2014a. Using task-induced pupil diameter and blink rate to infer cognitive

load. Human-Computer Interaction 29, 4 (2014), 390--413.

K. Huttunen, H. Keranen, E. Vayrynen, R. Paakkonen, and T. Leino. 2011. Effect of cognitive

load on speech prosody in aviation: Evidence from military simulator flights. Applied

Ergonomics 42, 2 (2011), 348--357.

S. Oviatt, B. Schuller, P. Cohen, D. Sonntag, and G. Potamianos. 2017. The handbook of

multimodal-multisensor interfaces, 1 Foundations, User Modeling, and Common Modality

Combinations. Morgan 8 Claypool, 1--15.

D. Kahneman. 1973. Attention and Effort. Prentice-Hall, Englewood Cliffs, N.J.

A. Baddeley. 2003. Working memory: Looking back and looking forward. Nature Reviews

Neuroscience 4, 10 (2003), 829--839.

C. D. Wickens. 2008. Multiple resources and mental workload. Human Factors, The Journal of

the Human Factors and Ergonomics Society 50, 3 (2008), 449--455.

F. Paas and J. Van Merriënboer. 1994. Instructional control of cognitive load in the training of

complex cognitive tasks. Educational Psychology Review 6, 4 (1994), 351--371.

N. Lavie, A. Hirst, J. W. de Fockert, and E. Viding. 2004. Load theory of selective attention and

cognitive control. Journal of Experimental Psychology: General 133, 3 (2004), 339--354.

T. Appel, C. Scharinger, P. Gerjets, and E. Kasneci. 2018. Cross-subject workload classification

using pupil-related measures. In Proceedings of the 2018 ACM Symposium on Eye Tracking

Research 8 Applications (ETRA’18). 4.

L. Fridman, B. Reimer, B. Mehler, and W. T. Freeman. 2018. Cognitive load estimation in the
wild. In Proceedings of the 2018 SIGCHI Conference on Human Factors in Computing Systems

(CHI’18).

S. G. Hart and L. E. Staveland. 1988. Development of NASA-TLX (task load index): Results of
empirical and theoretical research. In Human Mental Workload, Hancock, P.S. and Meshkati, N.

(Eds.). North-Holland, Amsterdam, 139--183.

G. G. Reid and T. E. Nygren. 1988. The subjective workload assessment technique: A scaling

procedure for measuring mental workload. Advances in Psychology 52 (1988), 185--218.

H. Steil and A. Bulling. 2015. Discovery of everyday human activities from long-term visual
behavior using topic models. In Proceedings of the 17th ACM International Conference on

Ubiquitous Computing (UbiComp’15).

J. Epps and S. Chen. 2018. Automatic task analysis: Towards wearable behaviometrics. IEEE
System, Man and Cybernetics Magazine 4, 4 (2018), 15--20.