Software Engineering

Practical:1

 Case Study of Library information system.

 A Library information System is a software built to handle the primary housekeeping

functions of a library. Libraries rely on library information systems to manage asset
collections as well as relationships with their members. Library information systems
help libraries keep track of the books and their checkouts, as well as members’
subscriptions and profiles.
 Library information systems also involve maintaining the database for entering new
books and recording books that have been borrowed with their respective due
dates.

 Set of System requirements while designing the library information System:

1) Any library member should be able to search books by their title, author, subject
category as well by the publication date.
2) Each book will have a unique identification number and other details including a
rack number which will help to physically locate the book.
3) There could be more than one copy of a book, and library members should be
able to check-out and reserve any copy. We will call each copy of a book, a book
item.
4) The system should be able to retrieve information like who took a particular
book or what are the books checked-out by a specific library member.
5) There should be a maximum limit (5) on how many books a member can check-
out.
6) There should be a maximum limit (10) on how many days a member can keep a
book.
7) The system should be able to collect fines for books returned after the due date.
8) Members should be able to reserve books that are not currently available.
9) The system should be able to send notifications whenever the reserved books
become available, as well as when the book is not returned within the due date.
10) Each book and member card will have a unique barcode. The system will be able
to read barcodes from books and members’ library cards.

 We have three main actors in our system:

1) Librarian: Mainly responsible for adding and modifying books, book items, and
users. The Librarian can also issue, reserve, and return book items.
2) Member: All members can search the catalog, as well as check-out, reserve,
renew, and return a book.
3) System: Mainly responsible for sending notifications for overdue books,
cancelled reservations, etc.
 Here are the top use cases of the Library Management System:

1) Add/Remove/Edit book: To add, remove or modify a book or book item.

2) Search catalog: To search books by title, author, subject or publication date.
3) Register new account/cancel membership: To add a new member or cancel the
membership of an existing member.
4) Check-out book: To borrow a book from the library.
5) Reserve book: To reserve a book which is not currently available.
6) Renew a book: To reborrow an already checked-out book.
7) Return a book: To return a book to the library which was issued to a member.

Case Diagram
 Here are the main classes of our Library Management System:

1) Library: The central part of the organization for which this software has been
designed. It has attributes like ‘Name’ to distinguish it from any other libraries
and ‘Address’ to describe its location.
2) Book: The basic building block of the system. Every book will have ISBN, Title,
Subject, Publishers, etc.
3) Book Item: Any book can have multiple copies; each copy will be considered a
book item in our system. Each book item will have a unique barcode.
4) Account: We will have two types of accounts in the system, one will be a general
member, and the other will be a librarian.
5) Library Card: Each library user will be issued a library card, which will be used to
identify users while issuing or returning books.
6) Book Reservation: Responsible for managing reservations against book items.
7) Book Lending: Manage the checking-out of book items.
8) Catalog: Catalogs contain list of books sorted on certain criteria. Our system will
support searching through four catalogs: Title, Author, Subject, and Publish-date.
9) Fine: This class will be responsible for calculating and collecting fines from library
members.
10) Author: This class will encapsulate a book author.
11) Rack: Books will be placed on racks. Each rack will be identified by a rack number
and will have a location identifier to describe the physical location of the rack in
the library.
12) Notification: This class will take care of sending notifications to library members.

 Activities that are carried out:

1) Check-out a book: Any library member or librarian can perform this activity. Here
are the set of steps to check-out a book.
2) Return a book: Any library member or librarian can perform this activity. The
system will collect fines from members if they return books after the due date.
Here are the steps for returning a book.
3) Renew a book: While renewing (re-issuing) a book, the system will check for
fines and see if any other member has not reserved the same book, in that case
the book item cannot be renewed. Here are the different steps for renewing a
book.

 Summary:
1) The quest to make life easier and processing faster has led to computerization of
various
2) processes. Computer technology has transformed so many sectors especially the
Educational
3) sector in no small measure. In an effort to foster technology driven education, a
Library
4) Management System has been developed to manage all library operations such
as borrowing,
5) returning of books etc.
 Recommendation:
For further research work to be carried out. The following
1) University Library should be developed to work on any platform.
2) Diagrammatic representation as a lecturing aid should be included in
a University Library.
3) University library lecturing should also be extended to other field of study such
as chemistry, English Biology Agricultural science and many others.
4) University library should be developed to support audio, video and a
diagrammatic aid to learning.
Practical: 2
 Case study of Villager Telephone System.

 The use of formal methods in the development of a benchmark application we call

the Village Telephone System which is characteristic of a class of network and
telecommunication protocols. The aim is to show an effective integration of
methodology and tools in a software engineering task that proceeds from user-level
requirements to an implementation. In particular, we employ a general methodology
which we advocate for requirements capture and refinement based on a treatment
of designated terminology, domain knowledge, requirements, specifications, and
implementation.
 The problems of modelling and tool integration on an illustrative problem we call the
Village Telephone System VTS The VTS provides an accessible but non trivial
application similar to many others in the telecommunications and networking
domains.
 It also explains the real world meaning of each primitive term Obviously these
explain nations are informal if they were formal then the terms would not be primi-
Tive In general designated terminology must be classied into one of four categories
according to control and visibility environment-controlled system hidden
Environment controlled system visible system-controlled environment visible
and system-controlled environment hidden. When we need to represent these
variables in mathematical formulae, we shall write them as eh ev vs. and sh where
each of these is to be viewed as a list of variables The system controlled
and environment hidden variables sh only arise within the implementation and
will not be covered here the purpose of the designations is to clarify the role
these terms may play in the formation of the domain knowledge speciation
and requirements It also is critical in formulating the basic theorems that need
to relate these components Using the variable class cation we can represent the
domain knowledge by Weh ev sv represent the requirements by Reh ev sv
represent the speciation by Sev sv represent as an input output relation a
program implementing the speciation by Pev sv sh and represent knowledge
of the programming platform machine on which the program will be run by
Mev sv sh Notice that the domain knowledge and the requirements cannot
reference those variables controlled by the system and hidden from the envi
ronment and that the speciation can only reference those variables visible to
both the system and the environment Suppressing the arguments the ultimate
theorems we wish to hold are given in Table Formulas and are consistency
properties and is the correctness of the implementation relative to
the domain knowledge and requirements From and we can prove the
consistency of the requirements relative to the domain knowledge to prove
and we will factor through the speciation If we prove
and then we can derive both and from them.
 Requirements:

 Because this is a very friendly village, we require the system to make it as easy as
possible for villagers to talk to each other. Intuitively, the requirement is that if a
villager want to talk to somebody another villager who is off hook and not
engaged in another conversation, and there fore free to talk. This effort may
include alerting one or more villagers whose phone are unhook in the hope that
a phone will then go off hook and can be connected. There are many possible
versions of these informal requirements. In all versions we assume that time is
discrete and that system is fast enough to complete its response to each event
before the next environment event occurs. In our case this means that then
connected and then alerting can be viewed as instantaneous state changes.
 The first thing that anybody would want out of a telephone system is that
communication can happen;

 Conclusion:

 So, here as shown how to carry out an “end to end” formal development of an
illustrative software system. This process included modelling parts of the process
that are not usually treated formally, such as the user-level requirements. By a
systematic approach to refinement, we have shown how these requirements can
be reduced to a specification and a corresponding HOL specification, and a gap
between our Mocha specification and a corresponding HOL specification. The
benefit of closing the first gap is probably not worthy the trouble in the case, but
better integration between Mocha and HOL could yield interesting benefits.
Practical: 3
 Waste Management Inspection Tracking System (WMITS).

 Goals and Objectives: The main purpose of WMITS is to help automate the entire
process that the Department of Environmental Quality (DEQ) Waste Management
Division (WMD) staff members perform throughout an inspection.
 To minimize the time span of any inspection.
 To minimize the amount of paper work required.
 To provide a searchable database of all past inspections.
 To provide an automated channel for the public to request information (under
Freedom of Information Act).

 System Context: Eventually, multiple users will be using the product simultaneously.
Therefore, concurrent connection will be an issue for implementation. In addition,
this is a pilot product that hopefully, if successful, can be used in other locations as
well. This leads to issues about future support for a larger user base.

 Introduction: This section gives a general overview of the Test Specification for the
Waste Management Inspection Tracking System (WMITS).

 Goals and Objects: Put it in a simple way, a good product will be work perfectly,
doing the right thing at the right time. To do that, the software has to go through a
series of tests before its final release. Error free software is extremely difficult to
achieve. After all, nothing is perfect. Especially for software developed in a short
time frame. But high quality can be achieved with a detailed test specification. All (or
least most) of the test case will be listed, the development team will follow it step by
step, item by item, to test all the necessary objects, data flows, limits, boundaries,
and constraints of the software.
 The team’s goal is to assist the project team in developing a strategy to deal with any
errors. For this, the team will take a look at the most common errors to some very
uncommon errors as well.

 Major Constraints: The team has limitation on time to test the product at the client’s
facility. We have access to the facility only during the regular office hours. We also
have to set us schedule around the available time of the inspector that is to help us,
so time schedule will be a major constraint when we talk about testing at the site.
 The team also has got funding for only one hand held PC. This means that we cannot
test the software using the PC from some other brand or PC that is of lesser price
and lower hardware.
 The team does not know any hacker that can help us test the security problems. So
we have to rely on our own knowledge and have to trust the software for the
security.
 The team also does not have large enough group to have many people use the
applications at the same time to perform real stress related testing. So we have will
not be able to test the product for the larger user base.

 Testing Plan: The total software development time on the testing. Below is the
description of the testing procedure and strategy. We will also be presenting the
timing and scheduled of the tests to be carried out.
1) Interfaces: Login Window
We will make use of several different names to log in to the system, so will be
testing login window. We will also test OK and Cancel buttons on this window
by performing test above – Microsoft Visual Basic [Design] Window
This is the main window that we will use to access the database using Visual
Basic. We will have several different drop-down menus in this window. File,
Facility, Inspection, approve, Reports, Maintenance and Help are the drop-
down menu that will be available in this window we will try to use all the
menus and then different options available in each of the window.
2) Testing Strategy: In the following section will describe the testing strategy.
And will user four different methods to test our product.

A. Unit Testing: In the unit test case we will be testing the separate
modules of the software. We will carry out white box testing where
each module or component of the software is tested individually. We
will test the components by passing data through it and we will be
monitoring data to find the errors. We will be looking for entry and
exit conditions of the data. We will make sure that all the components
work without any troubles. The test primarily be carried out by the
programmer who designed and implemented the module. Lead tester
will than carry out test on the modules to finalise the testing.

B. Integration Testing: In this method of testing, we will implement the

software at the client’s location and will run it. So, we will be testing
the product on client’s network. As part of testing, will be looking for
any signs of the collision between our software components and
those of the clients. We want to make sure there is no confusion
among the application on the network when they are running
simultaneously.
 We will install the software at the client’s site and will run it. We will
have several different other applications open as well. These
applications will be the once that have to interact with our software
on normal bases. We will make sure that all the data is saved correctly
and there is no loss of data or data base anomalies in the product.
 We will start from the login window and will go through all the all the
software functions and will test the. We will be carefully looking for
any sort of collision between several different applications.
C. Validation Testing: In this method of the test, we will be working with
the customer to find out if the software developed in valid for the
clients. We want to make sure that the client is getting what he asked
for. We will look at the software requirement document in the case of
conflict or misunderstanding with client regarding software
components.
 We will perform the black box testing where the software is
completed and we test all the software components together. We will
have several input data or test data that we will derive results for. We
will insert this data in the software and will get results from the
software. We will compare the results from the software with the
results that we derived. This way will check for the validation of the
software.
 In case there are problems with the software we will create a
deficiency list and will record all the problems in there. We will test all
the components and subcomponents of the software to perform
validation test.
 We have and will try our best so that we don’t have to create
deficiency list. This is necessary because if the errors are found at this
stage of the software development, we cannot fix them by the time
we reach the software deliverance date. In this case we have to
negotiate with the customer to give us extension on the project.

D. High-order Testing: In this test method we will combine several

different other types of the testing. We will test for several different
conditions by following several different test methods.
i. Recovery testing: Here we are concerned with ability of
the software to retrieve lost data. We want to make sure
that the software is fault tolerance and does not loose data
in case of system shutdown or if the system ceases.
ii. Security Testing: In this method of the test, we want to
make sure that the security checks are working and no one
is able to temper with the data. This is crucial since our
software is design to track the activity that is not legal.
iii. Stress Testing: In this test method we want to monitor
stress caused to system and the software due to
simultaneous use. We want to make sure that the system
does not break down under the extreme use conditions.
iv. Performance Testing: Performance bounds are set during
the design part of the software development. These
bounds will help us in determining the effectiveness of the
software. It will also help us to minimize stress level that is
caused to user because of our software.
Practical: 4
 Case study of Flight Control System.

 INTRODUCTION: The Flight Control System (FCS) is one the most critical systems
inside an aircraft and, like many other embedded systems, its size and complexity
has grown in recent years. Verification and validation (V&V) of such a system is thus
essential but not easy. Classical V&V methods consist in simulation and tests but
formal verification is now a credible method to complement the classical ones.

 Software Development process: The development cycle. Three levels are

distinguished: aircraft, system and equipment. The most critical systems, like flight
control systems, are designed using the formal language SCADE [1]. A qualified code
generator automatically generates most of the embedded code. Some verification is
raised from the code to the design. level. Main V&V activities at Airbus are the
following:
 Model tests: the considered system is validated in a simulated environment. This
is performed on desktop simulators providing a panel of commands representing
possible pilot actions. Testers define test scenarios with respect to the detailed
requirements. The scenarios are executed on the simulator; the testers then
decide whether or not the test is successful.
 Aircraft level simulation: several systems are validated in a simulated
environment.
 Formal verification at code level: Airbus uses abstract-interpretation based tools
to verify non-functional properties of programs (such as absence of run-time
errors) and uses proof-based tools to verify functional properties on the parts of
the programs that are manually coded. These uses of formal methods have been
very successful [2] and are being extended. They are not addressed in this paper;
we consider the system level and a different technique (model checking).
 Software integration tests:
 Lab tests: first tests with real equipment’s, on a single system or on several
systems.
 Ground tests and Flight tests. This paper focuses on the verification activity at
system design level, which currently involves model tests. As the design is
expressed in the SCADE formal language, the possibility of using formal analysis
for part of the verification at this level has been studied. It must be noted that
the SCADE model is a detailed design from which the embedded code is
generated; it is thus more complex than models that are specifically defined for
formal verification purposes

 Effectiveness of formal verification: Although the Ground Spoiler function involves

little numerical computation, it is sufficiently complex to challenge the verification
tool because of the presence of temporal counters. It took about 48 hours to
exhaustively analyse the correct version, analysis being run on a 1.7-GHz Pentium 4
processor with 256 MB of RAM. As regards the incorrect version, the production of
counterexamples lasted from minutes to hours, depending on the length of the
counterexample and the chosen exploration strategy (SCADE offers two strategies).
The returned counter-examples were between 50 and 160 cycles length. Formal
verification proved quite effective. Let us recall that the model tests did not manage
to trigger property violation. This is due to the fact that highly dynamic aspects are
not the focus of these early tests: unusual aircraft trajectories, such as the one
associated with the violation scenarios, are not considered at this stage for validating
the logic. The flight dynamics is more deeply addressed by lab tests (using a full flight
simulator) and of course by flight tests. However, the earlier the flaws are detected,
the less costly it is. Our study shows that model checking may be a practical means
to achieve detection at design level. The study also provided rich feedback on the
flawed behaviour, by allowing us to identify two violation scenarios (corresponding
to aircraft trajectories that are quite different in each case).

 Iterative approach to verification: Due to the above-mentioned problems

(expression of properties and hypotheses, interpretation of counterexamples),
conducting formal verification is far from a single push-button experiment. It is more
like an iterative “what-if” approach, as shown in Figure 9. Iterations are required to
explore alternative formulations of the verification problem (including both the
property and the hypotheses). The results of initial verification steps provide a useful
guide to revise formulation. Analysis failure indicates the need for additional
hypotheses. Irrelevant counterexamples question the adequacy of either the
hypotheses or the property. Figure 9 emphasizes the importance of human analysis
when a counterexample is found. Note that in some cases, attempts to find a
system-level interpretation may yield questions on other parts of the SCADE model
(for example, the part corresponding to the computation of Boolean Cond used by
the Ground Spoiler logic). Those new parts come with new verification artifacts to be
formulated.
 Given a verification problem, the first counterexample returned by the tool is not
necessarily a meaningful one. It may represent some unrealistic behaviour that could
not easily be excluded by means of input hypotheses. Analysis must continue to
determine whether or not other counterexamples can be found, that may reveal a
real violation problem. Or in case a real problem is revealed, it may be useful to gain
deeper insights into the various violation scenarios it induces. During the study, we
encountered those various cases justifying the search for additional
counterexamples. Unfortunately, SCADE Design Verifier (like most model-checkers)
does not allow for several counterexamples. Repeating verification can only yield the
same counterexample to be produced again and again. To overcome this problem,
we had to use a trick. We manually modified the P observer so as to exclude the
counterexample previously found. This way, we managed to explore alternative
paths toward property violation. We eventually retrieved the flaw found by testing,
and demonstrated that it could yield at least two different violation scenarios.

 Conclusion: The experiments reported in this paper were targeting the Airbus
development process for Flight Control Systems. The Airbus context particularizes
the application of the model checking technique as follows:
• In the target process, a SCADE formalization occurs at system design. The analysed
models are thus at a concrete level of details.
• The FCS functions run on a multi-processor and multi-clock environment (multi-
clock aspects also arise inside a single processor).
• FCS functions range from simple Boolean functions to functions involving complex
numerical calculation. Determining their valid input domain is usually non-trivial,
because of the need to consider the flight dynamics.
• The target properties may be, or not, at the same level of abstraction as the
models. It depends on whether they come from the detailed or high-level
requirements. Some of the above characteristics are likely to be shared by other
industrial companies also developing control systems. For example, the automated
generation of code from design models is not uncommon: whether such design
models are suitable to formal analysis is a question that may be relevant to different
safety-critical domains.
Practical: 5
 Case study of Ambulance Dispatching System.

 Introduction: The emergency ambulance dispatch system or computer aided

dispatch system (CAD) is a web-based application that efficiency receives a phone
call from all services, records the details of an emergency including location, find the
next available ambulance and dispatches the ambulance as fast as possible with
some minute.
 As technology and particularly computer technology evolved, the dispatching of EMS
resources took on an entirely new dimension and required completely new skill sets.
The process of dispatching was supported by computers and moved in many locates
to a paperless system that require above average computer skills.
 System not only permitted in dispatcher to record the call information, but also
automated the call triage process, allowing system to become algorithm-based
decision support tools.
 The computer aided dispatcher system will constantly monitor the location and
status of response resources, making response resource assignment
recommendations to human dispatchers, allowing human dispatchers to watch the
physical movement of their resources across a computerized map.
 Ambulance dispatchers required little in the way of qualifications, apart from good
telephone manners and knowledge of a local geography.

 Theoretical Background: Today, it is believed that the application of computer

technology in any activity would go a long way in making that activity much easier.
This system is designed to locate the available ambulance near the incident location
and dispatch them as per requirement, to the researcher. To this end, the researcher
sees the above statement as a theory until proven otherwise by ambulance dispatch
system. It is also understood that the benefit of using computer supersede that of
the manual method. The design and implementation of the new system will prove
beyond doubt by the researcher.

 Statement of the Problem: The sudden increase in the number of emergencies

reported by the federal road safety has transcended the manipulation of the existing
system used by the ambulance dispatcher and this prompted a lot of problem which
encompass the delay of dispatching ambulance it was very complicated to observed
or track the location of any dispatch ambulance. Since there was no tracking facility
in the manual method. It was very difficult to keep record of ambulance available
and ambulance on duty. All these and more are encountered due to the debilitation
of the prevailing system used.

 Aim and Objectives of the Study: The aim of this research is to build a dispatch
system that will help to speed up the rate of dispatching ambulance in order to
carter for an emergency in the society. The objectives of the system include:
 i. To provide fastest ambulance services to the victims of any emergency
incidents.
ii. To decrease the amount of paper work must be file.
iii. To help the company ensure that provide an adequate amount of ambulance
for each of the service.
iv. To enable management, track the status of each ambulance and the
ambulance activity.

 Significance of the Study:

This research work will have the following significance.
i. Introduce a software that will speed-up the rate of dispatching ambulance.
ii. Enable the company to track the status of each ambulance.

 Scope of the Study: The research project focuses on ambulance dispatch system
using federal road safety, Uyo.

 Organization of the Study: The research project has been arranged in the following
order. Chapter one contains the introduction, theoretical background, statement of
problem, scope of the study and definition of terms. Chapter two focused on the
relevant literature review on the subject matter. Chapter three is concerned with the
system design, which emphasis on system design and flow chart. It also expands the
development of the new information. Chapter four is the system implementation
which gives the direction of system and analysis of modules. Chapter five
summarizes, show the limitation of the study, conclude the research work and offer
some useful recommendation.

 Conclusion: Emergencies such as accidents require immediate medical attention

where patients need to be transported from the place of incident to hospital. In such
situations, emergency systems are crucial in saving precious lives. The importance of
taking a patient to hospital can be judged by the fact that if the arrival of an
ambulance is delayed due to any problem, it can worsen the patient medical state
and even cause death. The delays can occur due to time consumed for dialling
emergency numbers and carrying out conversation for guiding the address to the
place of incident to the ambulance dispatch service provider representative. The
immense need of automation of ambulance dispatch system is necessary for solving
this problem. This research work provides a comprehensive system that tackles this
problem of manual ambulance dispatching by replacing it with Automatic
Ambulance Dispatch System AADS. AADS comprises of android based application
where the user (victim or the caretaker of the victim) has to press a simple “help”
button on the AADS android application to signal and buzz any ambulance near the
place of incident along with the victim’s geographical location just on one click. The
objective of this research is to minimize the time consumed for the arrival of
ambulance through automation
Practical: 6
 Case study of Development of requirements specification

 Abstract: In this paper, we formulated, designed, implemented and evaluated a

model used for classifying stakeholders' requirements that are specified for web
application development. The study employed both qualitative and quantitative
research approaches in a case study. Requirements were elicited from stakeholders
using the interview approach. This involved speaking with the stakeholders directly
via groupware and asking them questions about their specific needs that are
relevant to the development of web application. In particular, 10 customers of
Procrea8 Technology Solution Limited and 9 developers were used as respondents.
An interactive genetic algorithm was used to formulate the model. The design was
specified using the Unified Modelling Language (UML) tool, and implemented using
specified web technology tools. The model was evaluated for completeness and
consistency using recall and precision as parameters. The results showed that a list
of ordered requirements was produced based on the stakeholders' priorities
inputted into the model. The output indicated the order of priorities finally
assigned to each of the requirements. The evaluation revealed that the model is
effective, efficient, user-friendly, reliable (with 96.3% accuracy), scalable (prioritized
over 500 requirements), less time-consuming (prioritizing over 500 requirements)
and able to update ranks whenever changes occur automatically. Also, the model
evaluation indicates 97.1% precision (consistency), and 96.0% recall (completeness).
The study shows that requirements engineers could use the model to collate
stakeholders’ requirements from wide geographical locations.

 Introduction: Software engineering (SE) as a discipline has brought immeasurable

changes in the advancement of technology, software development practices and the
entire spectrum of computing. Notably, the impact of software development in
practice is generally becoming indistinguishable in a way we reason and live. Since
the emergence of the World Wide Web (WWW), focus on application development
using the variety of software development lifecycle (SDLC) has concentrated on the
web [1]. The resulting web applications are software applications that run on a
remote server. The software in this regard provides support for almost all the
business operations [2, 3] on the web. So, for software engineers, it becomes almost
inevitable to develop the needed skills, techniques and tools that will guarantee
quality web application and software products.

 Methodology: In this paper, both qualitative and quantitative approach in case study
research [42] were followed. We reported the design specification of the model and
the prototype tool in [16]. Stakeholders’ requirements were elicited using interviews
on groupware platform. This involved speaking with the users (stakeholders) directly
via groupware (TeamViewer) and asking them questions about their specific needs
that are relevant to the web application under development. In particular, ten (10)
customers of Procrea8 Technology Solution Limited and nine (9) developers were
 used as respondents. Also, the secondary data was elicited from system domain
documents. The customer relationship management domain document was
inspected to know the basic needs (business requirements) and the description of
the system domain. Based on the requirements gathered, a model was formulated
using an interactive genetic algorithm.

 Conclusion and recommendation for future work: Achieving the goal of delivering a
robust market-driven web application demands the proper handling of the
requirement overload situation. This paper revealed that the overload situation is
the cause of delay and cost in the development of web applications. In an attempt to
address the situation, we engaged in a case study research to develop and evaluate a
model that analysed stakeholders’ requirements in a large-scale web development
project. Requirements were elicited from stakeholders in different geographical
location via TeamViewer; an interactive genetic algorithm that is efficient and
effective for ordering web application requirements was proposed. We developed a
prototype tool to support the analysis and classification of these requirements via
prioritization. The tool is simple to use with a friendlier user interface. Also, the
proposed approach produces solutions that allow the system analyst/developer to
make decisions concerning the set of requirements that shall be implemented in the
web application to be developed. More so, the tool allows stakeholders that are not
in the same location to take part in the prioritization process. This research has
contributed to knowledge by providing a model that collates stakeholders’
requirements from wide geographical locations. Also, the model can analyse
stakeholders’ requirements to present first-hand information to requirement
analysts. Thus, the analyst can quickly identify users’ expectations in a large-scale
web application development project. The study also provides a prototype that will
enable requirement engineers to prioritize and rank large scale of requirements in
web development, thereby reducing the cost of development. In future works, more
experiments are required with more alternative settings on other real-life case
studies to generalize the findings in this research. An intelligent model to adequately
handle issues on requirements dependencies is inevitable to strengthen the
automation of the model further.