1 Requirements definition
Chapter1: Requirement Definition
1.1 Initial Situation and Objective Target
1.1.1 Introduction
Our company was engaged to develop a software-system with the working title
''Archaeological Data System - ADS'' which first of all shall:
- Provide an interface via the world-wide-web enabling our customer to enter
archaeological data such as tombs, settlements or artefacts into a central
database.
- Enable third parties to query the database for information via the world-wide-web.
- Present the data via a virtual museum.
We are responsible for the design and implementation of this system including
the following points:
- Web-front-end to manipulate and display data.
- The design and implementation of the database itself.
- Maintain these services.
- Host the database on a server or at least administrate this work.
1.1.2 Database
One record will consist of approximately 20 attributes and can also contain
pictures, sketches, movies and sounds. The expected annual growth of data is
about 400 records at all (400 pics, 400 sketches, 10 movies and several sound-samples).
The multimedia-files have to be uploaded through our web-interface. These files
will not be stored into the database, but rather using the filesystem. The database
will only store the path to the respective files.
1.1.3 Entering Data
There will be five user groups so far who are allowed to enter data into the
database.
1.1.5 Virtual Museum
The software-system shall include a virtual museum where the visitors can walk
through and zoom into descriptions of archaeological objects and artefacts.
The museum shall not host all the data collected as the customer wants to perform
special exhibitions on current topics. The visitors have the ability to search
here for archeoligical artefacts. As a result they will get a descritpion how
to get to the desired item in the museum. If one selects an item in a showcase
he is given the available data from the database.
A museum will initially have three floors, each of which consist of about ten
rooms. In every room there are several showcases which can contain various archeological
artefacts each. The designer has the ability to design the museums.
1.1.6 Additional Notes
The customer wants to produce represantative CDs as well as catalogues of the
virtual museum and its exhibitions.
1.2 System Environment
- Hardware: ADS will be hosted by our company. We will be responsible
for readiness for use and maintenance of the system and also accessibility
via the internet.
- Software: The demand of software for the ADS-users is very small.
Only an OS and a web-browser is required.
- Data: The database will initially contain about 4000 records (each
has about 20 attributes) of archeological data. Every year there will be about
400 new records to enter the database. Since the customer himself is responsible
to fill the database we don't need to know anymore.
-
Users: The system distinguishes between five user-groups. Four active
groups who can change the database and one passive group (visitors) who
can only query the database. The visitors will be the ones accessing ADS
most of the time (about 100 hits at a time), while (scientific) data collectors
will use it approximately twice or three times per day (400 new entries
per year plus manipulations of existing data). The administrator is expected
to work very few with the system.
1.3 User Interface
See storyboards.
1.4 Documentation Requirements
As our customer has no previous experience with similar software-systems and
wishes to be independent after finishing the project, the product manual has
to contain detailed instructions dealing with the following issues:
- Modification of the data-access-system. Explains how to
- change the rights of certain groups
- add users and groups
- change the group of a user
- Modification of the Virtual Museum. Explains how to:
- add floors, rooms, showcases and artefacts to the museum
- equip rooms and showcases with topics
- change the layout of rooms and showcases
- Update the database. Explains how to
- enter data-records into the database
- upload files into the database
1.5 Risk Analysis
- Database: The expected amount of data in the database is rather modest
and should not be a problem for a modern database management system. If the
system should run short of storage space in the future, it will be no problem
to provide additional disk space. Hence, the risk of problems with that part
of the software-system can be classified as low.
- Web-Frontend: The only risk connected with the web-frontend is, that
the customer might not be satisfied with our design proposals. It will be
important to show him some basic layouts in an early stage, to make clear
what the customer is looking for and in doing so, avoid the risk of wasting
too much time and manpower on unnecessary design work. The technical specifications
of the web-frontend should not be a problem for our experienced developers.
- Virtual Museum: Concerning the virtual museum, it has to be said
that the customer has very loose ideas of what it should finally look like.
This might lead to problems, if the customer is not satisfied with our developer's
suggestions. To avoid the necessity of last-minute adjustments of the whole
concept, this risk should be minimized by clarifying if our proposals meet
his demands.
- Stability: As the system shall always be up and we are responsible
for it's stability and readiness for use, this point is quite important to
ensure smooth working. We therefore should use a well-known and reliable hardware
and operating system for the servers as well as make a contract with a service-company
for case that the hardware fails. The use of XML and possible choice of SQL
as the basis for database lead to a quite platform-independent design of the
core-components.
- Staff: As our project team is rather small, it can have a great influence
on the software-development and on the project if somebody leaves the team.
If we had to recruit new personnel this could cost a lot of time and money.\newline
On the other side the facts, that within our team the project-leader changes
with every new assignment and every team member has to work out an individual
solution for the current assignment, have the effect that every team-member
is on the same know-how-level. So, if one team-member will be disabled for
just a little time, this will not handicap the whole team. But if three or
more members drop out for the same time, the project is endangered.
- Hardware: The only limitation to the used hardware is it's stability.
If it turns out that there are not enough resources, such problems can easily
be solved by adding more resources. As we have no limitations concerning financial
investments, the hardware shouldn't be a problem.
- Miscellaneous:
- If there is much traffic on the internet, the response time may drop
down. Since we can do nothing about this, we have to accept the risk of
partially slow connections.
- In case of electric power breakdown, our power generator will start
up, to ensure power supply for our servers. Customers won't recognice
that at all.
- It remains negotiated with our customer who shall be held responsible
for possible loss of data. Nevertheless, such a risk shall be minimized
by making regular backups.
- It is the responsibility of our management to evaluate our cutomer's
credit-worthiness.