The document describes requirements for an online conference management system using a three-tier architecture. It defines functional requirements for different user types including program chairs, authors, and reviewers. Non-functional requirements address usability, security, performance and other qualities. Use case and sequence diagrams model adding a conference. The domain model depicts the structure of conferences, users, submissions and other entities. Overall an iterative development approach is proposed using a three-tier architecture to separate the user interface, business logic and data layers.

1. 1. Which methodology would you like to adopt for this project? Justify your choice by
listing 2 arguments.
Answer: An iterative approach is used for the online conference management system. The
incremental method is chosen to adopt in the system due to the following rationale aspects:
 Earlier in the case study, we discussed all of the system's needs. What are the new
system's expectations? has already indicated in advance of its deployment. Additionally,
the case study presented functional and non-functional needs well in advance of
execution, while an agile methodology requires you to go through all stages in a single
sprint. Additionally, the case study demonstrates that the system places a higher premium
on the requirement collecting and design phases prior to deployment. As a result, we
initially intended to run each step through many iterations, so that if modifications are
needed, we may include them into the next iteration.
 The critical point to remember is the customer's participation. The agile methodology
encourages constant engagement of the "user" and empowers them to anticipate future
needs. As was the case in the case study, the main system privileges are controlled by
HCT professors and event managers, not by students, and are pre-defined by high-
credential personnel. Thus, adaptability for new needs is not always needed for system
development, and the present epidemic, in particular, supports less student participation.
However, any comments would be much welcomed.
2. Conduct the feasibility study for this project.
Answer: The preliminary study determines the viability of the project and the probability
that the system will be beneficial to the organisation. The feasibility study's primary goal is to
determine the technical, operational, and economic viability of adding new modules and
troubleshooting an existing operating system. All systems are possible if given limitless
resources and time. Aspects of the feasibility research part of the preliminary inquiry include
the following:
1. Legal0Feasibility
2. Technical0Feasibility
3. Operation0Feasibility
4. Economical0Feasibility

2. Legal Feasibility:
The new online conference management system will be implemented throughout HCT's
many divisions. Prior to utilising the programme, both students and faculty/staff members
must agree the terms and conditions, which include account registration. The application's
rules, as established by HCT's IT department, will be enforced to prevent any unethical
actions, such as application abuse. The new system will replace the manual method while
preserving the professors and organisers' legal rights at the virtual level. The new system's
database will have administrative freedom, which means it will be terrible for low-end users
such as students.
All of the above-mentioned issues were recognised and, thankfully, addressed by HCT's
Student Life Department. HCT defines the rules about how students will demonstrate their
involvement. As a result, HCT created a dedicated department to concentrate only on the
online conference management application.
Economic feasibility
The computerised system should fully replace the manual system's data flow and processes
and should produce all of the manual system's reports in addition to a slew of additional
management reports. It should be developed as a web application, complete with a dedicated
web server and database server. This is necessary since the client's actions are dispersed
across the company and the customer desires a consolidated database. Additionally, some of
the connected transactions occur in several places. To keep costs down for the customer, open
source technologies such as android studio, java, mysql, and Linux are utilised.
Technical Feasibility:
To determine if the system is technically viable, a variety of other online applications that are
appropriate for system development were evaluated. Each stage was examined, and relevant
software was identified. The new system will replace the department's physical manual
educational system with an online conference management tool for professors and students.
Additionally, the virtual system will simulate contemporary technologies embedded in the
HCT environment. The system is theoretically viable if the following checkmarks are
present:

3.  Requirement for Application For reliable and statistical findings, we offer
alternatives for online surveys to ascertain the system audience's divergence and
the new expectations they have for the new system. Additionally, in-person
interviews will be encouraged to ascertain gain needs.
 For system design purposes, such as creating UML patterns, a publicly accessible
tool such as the StarUML with forward and reverse engineering capabilities may
be utilised. Additionally, the Invision Studio is accessible for creating UI/UX
designs.
 To implement the system's planned architecture, object-oriented programming
languages such as Java will be utilised. Additionally, HTML, CSS, and PHP will
be utilised to integrate the web application's front-end and back-end.
 Professional developers will provide technical knowledge. There will be
interactions between them in subsequent rounds. Under the supervision of HCT
professors in the Student Life Department, a dedicated team will be formed to
develop and execute the software.
Operational feasibility
1. User-friendly
The customer will utilise the forms to conduct different operations, such as adding
new conferences and examining the information of existing conferences.
Additionally, the Customer desires that the reports display the different transactions
according to the restrictions. Forms and reports are produced in a manner that is as
user-friendly as possible for the Client.
2. Reliability
The package will retrieve current online transactions. With regards to previous
transactions, the user will manually input them into the system.
3. Security
The web server and database server should be secured against hackers, viruses, and
other malicious software.
4. Portability

4. 5. The application will be built utilising industry-standard open source software such as
Java, MySQL, and others. Because these applications will run on both Windows and
Linux operating systems, portability issues will be avoided.
6. Availability
This software will be available always.
7. Maintainability
The three layered architecture (3-tier) pattern will be best for the online conference
management application as each layer is specified for particular responsibilities which
will help in making a better design and development of the application.
The front-end can be run on different (clients). The database will be running at the
server. Users access these forms by using the user-ids and the passwords.
3. Define, discover, review, document, and understand the user's needs and constraints
of the to-be system using at least two requirements gathering techniques. Justify
your choice.
Answer:
Requirement Elicitation techniques:
The following are some methods for eliciting needs and limitations from stakeholders for
the online conference management system.
Requirements:
One of the project's goals is to increase user efficiency, which is evaluated by the
expressivity and consistency of the graphical user interface. When a user uses a system
efficiently, the time required to complete a job reduces with each use. Another goal is to
provide a system that enables future enhancements and additions to the existing
capabilities. The system should be capable of managing conferences, submissions,
reviewers, available sessions, available tracks, and the conference schedule. The system
will be utilised by a variety of different types of users. The user types that will be
accessible include programme chair, who will also serve as system administrator, author,
who will submit a paper to the system and await a judgement, and reviewers. Each of

5. these user groups will have a distinct set of system-provided capabilities, which will be
referred to as goals. Different kinds of users imply varying degrees of access to system
resources, with one of the goals being the ability to access available resources depending
on the role of the person submitting the request.
Ethnography:
Observing the working environment and stakeholders in detail enables the determination
of the workflow and interaction of users with one another and with the system.
Additionally, the business analyst may ask questions while watching the culture and
working environment to identify areas for development and possibilities. Observing
students and administrators throughout the entire conference management process will
assist in creating needs that users may be unable to articulate. The ethnography creates
new needs, since practical procedures are often inconsistent with those stated in papers.
4. Create an activity diagram describing the behavior of the business process.
Because the online conference management system is a web application, rather than an
activity diagram, the following figure 4.1 depicts the system's component diagram.
Components of the business process that are described in depth.

6. Figure 4.1
5. What is the perimeter of the to-be system?
Answer: The ‘add conference event’ will be arranged in coordination of different Governmental
entities with HCT system.
6. Identify the functional and non-functional requirements of the to-be system?
Functional requirements
Functional requirements present a complete description of how the system will function from the
user's perspective. For a better management of the system requirements, these will be presented
based on the category of users that can access them. The set of functional requirements identified
for the system are presented in Table 6-1

7. Functional0requirement User
01 User0account-0forgot0password All0Users
01.1
0
Update0user0information All0Users
01.2 Upload0picture0 All0Users
020 User0management Program0chair
03 Conference0management Program0chair
03.1 Add0tracks0to0the0conference Program0chair
3.2 Add0sessions0to0the0conference0 Program0chair
3.3 Handle0notifications Program0chair
04 Handle0multi-tracks Program0chair
5 Invite0reviewers Program0chair
6 Assign0papers0to0reviewers Program0chair
7 Create0conference0program0 Program0chair
8 Create0booklet Program0chair
9 Create0e-proceedings Program0chair
10 Plagiarism0detection Program0chair
11 Info0authors Program0chair
12 Handle0submission Author
13 Display0submissions Author
13.1 Update0submission Author
13.2 Review0paper0status Author
13.3 Accept/0Reject0papers Reviewer
14 Review0paper Reviewer
Non-functional requirements
Non-functional requirements define the project's or system's characteristics and set restrictions.
They define the system's characteristics rather than what the system will perform.
Simplicity: the actions should be straightforward and logical. The activities will be guided by
basic connections and conversations. Additionally, the system will offer assistance through error
messages, comments, and documentations.
User-friendly: the system's interface should be simple to use. It should be simple to operate or to
learn. Additionally, the system's interface should be intuitive to non-expert users.
Accessibility: The conference management system will be accessible over the internet to all
users. There are no specific features for individuals with impairments or special needs.

8. Security: After verifying the actor's identification on the system, the system will enable
acceptable information flow. Additionally, the user's information should be kept private. Each
user will be identified by his ID, which will be his username, which must be unique, together
with an encrypted password. The technique of encryption mentioned in Section 4.2.3.3 Password
hashing using salt. Unless authors are registered users in the CMS, they are not permitted to
submit their articles. The database will contain information about the user's actions.
Availability: The system shall be available to all users at all times, except in the event of a
failure that may be restored within one hour.
Reliability: A system is deemed reliable if it maintains its performance throughout time. In the
event of a system breakdown during peak hours, the programme should recover within one hour.
Performance: There are no particular performance restrictions. This criterion quantifies the
system's efficiency, speed, and throughput. Any transaction on the Conference management
system will take less than ten seconds, depending on the internet/machine speed, such as:
 Log in to the system o Navigate to any CMAS page
 Messages sent to the chair or from the chair to registered users.
 Submit a new article.
 Submit a form for evaluation.
 Record your final choice on paper.
 Submit a registration form for the conference.
 Obtaining reports from the chair, such as a list of all accepted papers and
registered authors.
 Carry out more operations
Maintainability refers to the ability to add new systems that can be readily changed to
accommodate new technologies or to correct any defects. The CMS has been evaluated in such a
manner that it can readily accommodate new or future enhancements. Exporting the database (as
a backup copy) or importing it into the system is possible. The system assists users in
minimising use mistakes by giving suggestions. Additionally, verifying the input data before to
submission strengthens the system's resistance to errors. [2]

9. 7. According to your answer in Question 1 and 6, describe the requirements using either a
product backlog or a use case diagram.
System use case
Although the system's functional requirements reflect potential use cases, not all functional needs
can be converted into use cases. Create, update, read, and delete requirements do not need
presentation in the form of a use case.
System actors
Actors present in the system are the following
• Program0chair0
• Author
• Reviewer

10. 8. For each sprint/iteration, create a system sequence diagram describing the
behavior of or a user story/a use case.
Add conference use case
The sequence diagram in Figure 7.1 depicts the communication between the system's
components throughout the execution of the use case, which features a programme
chair who wishes to organise a conference. When the programme chair accesses the
website, he or she will see a form with a series of fields that must be completed. A
conference is composed of a number of sub-fields. Each conference requires
information on the conference's name, the conference's start and finish dates, and the
conference's submission periods, among other things.

11. 9. For each sprint/iteration, create a fragment of the domain class diagram
describing the structure of the to-be system.

12. 10. Merge/Refine all fragments to define the domain class diagram.

13. 11. Which architectural style you like to adopt to design the to-be system?
Apart from the obvious benefits of flexible software with well-defined interfaces, the three-
tier architecture is designed to enable any of the three levels to be updated or changed
independently in response to changing needs or technology. For instance, a change in the
presentation tier's operating system would have no effect on the user interface code.
The0user0interface0typically0runs0on0a0desktop0PC0or0workstation0and0employs0a0standard
graphical0user0interface,0as0well0as0functional0process0logic,0which0may0be0comprised0of0one0or
more0separate0modules0running0on0a0workstation0or0application0server,0and0a0database0server0or0
mainframe0that0houses0the0computer0data0storage0logic.0The0middle0layer0itself0may0be0divided
into0several0levels0(in0which0case0the0overall0architecture0is0called0an0"n-tier0architecture").
Presentation logic is concerned with presenting the information requested by the user in an
intuitive and usable way. By providing data to the browser, this level interacts with the client.
This layer provides a user interface that depicts the data contained in the database and enables the
user to add new information to the database, query the data using certain criteria, and change
existing data.
Business logic, The intermediate layer controls the system's functioning by processing input,
making choices, and performing assessments. This layer establishes the link between the next
levels by processing the data received from the presentation layer and converting it to a format
that the data layer can understand. This layer contains the logic that links the pages in the view,
the logic required for data processing and storage, and the logic essential to validate the data
received from the presentation layer.
The data layer is made up of the database. This is where data is saved and extracted. This level
keeps data isolated from the application server and logic rules, leading in speed and scalability
benefits. At this level, activities such as Create, Update, Read, and Update are performed. This
level interacts with the business level, which provides data in the form of collections pulled from
the database to this level.

14. 12. Create a high-level architectural model of the to-be system.
The database is the data layer. This is the location of data storage and extraction. This level
isolates data from the application server and logic rules, resulting in increased performance and
scalability. This level performs operations such as Create, Update, Read, and Update. This level
communicates with the business level, which supplies data to this level in the form of collections
extracted from the database.
Figure 12