Upload
truongdung
View
256
Download
0
Embed Size (px)
Citation preview
The WEISS Product Specification Document Deliverable D9: WEISS Product Specification Document
VMM - Greet Vos, Stefaan Hermans
VITO - Guy Engelen, Leen van Esch, Inge Uljee, Tim Op ’t Eyndt
April 2011
Table of content
I
TABLE OF CONTENT
Table of content _______________________________________________I
Chapter 1 Background ________________________________________ 2
Chapter 2 Functional specifications ______________________________ 4
2.1 Introduction__________________________________________________4
2.2 Functional specifications ________________________________________5
2.2.1 Installation and general set-up________________________________5
2.2.1.1 First .ini datafile _________________________________________7
2.2.2 Overview & navigation ______________________________________8
2.2.3 Input – calculation – output: details____________________________9
2.3 User requirements out of scope__________________________________26
Chapter 3 Non-functional specifications _________________________ 27
3.1 Software development_________________________________________27
3.1.1 Development_____________________________________________27
3.1.2 Authentication____________________________________________28
3.1.3 Performance _____________________________________________28
3.2 Language___________________________________________________28
3.3 Documentation ______________________________________________28
3.4 Installation__________________________________________________28
3.5 Security ____________________________________________________29
Chapter 4 Conclusion ________________________________________ 30
2
CHAPTER 1 BACKGROUND
The main aim of the elaboration of an innovative Water Emissions Inventory Planning
Support System (WEISS) is to support competent authorities across Europe,
including the Flemish Environmental Agency, with the implementation of the Water
Framework Directive (WFD). These authorities need a new tool for two reasons:
- firstly to determine the significant emission sources and their contribution
to the pollution of water bodies in order to formulate mitigation measures,
and
- secondly, to control and monitor compliance with the objectives to stop
(or gradually terminate) and decrease pollution as defined in article 4,
part 1, under (a), point IV of the Water Framework Directive
(2000/60/EG).
WEISS will above all be developed as a tool to generate a transparent inventory of all
significant emissions, discharges and losses to water bodies caused by human
activities.
The objective of the tool is to calculate as precisely as possible how various
pollutants will affect water bodies. It will simulate the pathways of the pollutants
from sources to sinks and quantify the importance of the flows in various nodes of
the transport route.
Finally, WEISS will take advantage of the data stored in its databases and its
calculation capacity to support the user in designing and assessing measures aimed
at reducing emissions and their impacts on water bodies. The WEISS system is thus
intended to address a multitude of polluting sources, both point and non-point. It
considers the various pathways and accounts for the removal of pollutants
transported to treatment facilities prior to their discharge in water bodies. By means
of chained algorithms, it conserves the true geographical nature of the processes at
high spatial resolutions, thus enabling the analysis and design of mitigation measures
that are spatially explicit. The spatial approach is most relevant for countries and
regions, such as Flanders, with high population densities and resulting pressures on
the environment, where policy measures will often affect or be affected by intensive
anthropogenic activities.
The elaborated system will be used for the State of the environment reporting in the
framework of the Water Information System for Europe (WISE) and will use
advanced Shared Environmental Information System (SEIS) compliant reporting
technology.
3
Product Specification Document objective
This document aims to develop the precise functional specifications of the WEISS
system. It was mainly carried out in parallel and in strong interaction with Action 2
and 3, the organization of a Local and a EU-wide stakeholder consultation to gather
new and update the intended WEISS user requirements. The outcome of this exercise
was delivered in a User Requirements Document (Deliverables 5 and 8).
The WEISS Product Specification Document (Deliverable 9) will give an overview of
the current state of affairs regarding the water emission inventory and list the needs
and expectations expressed by the end users, thus reflecting an ideal, desired
situation. This document will describe the functional needs of the user interface for
uploading data and maps, the generic functionalities for the creation of new sources,
the desired approaches for calculating and reporting.
Needs and expectations reported will be confronted with implementation
opportunities, technical constraints, potential bottlenecks and cost-benefit
considerations to result in a list of priorities that will be taken as a guideline for the
implementation of the system.
4
CHAPTER 2 FUNCTIONAL SPECIFICATIONS
The main objectives of the functional specifications are to present a clear set of user
interface specifications able to meet the user requirements obtained in the previous
stages of the project.
To present the design of the user interface in a clearer format, we have developed
mock-ups of the most important screens. These mock-ups or prototype screens
provide an insight in the functionalities of the system and enable testing of the
design. The mock-ups are mostly used for demonstration purposes. The screen
layouts and contents will change along the way and depending on new insights
gathered, progress made with the implementation and constraints encountered with
the existing software technology.
2.1 Introduction
During the user requirements analysis the objective was to get a clear view on the
processes that each local or EU stakeholder or potential user is involved in to
generate a transparent inventory of all significant emissions, discharges and losses to
water bodies caused by human activities. The list of user requirements were critically
reviewed and completed in a final WEISS User Requirement Document.
The resulting list is the complete overview of all the potential needs that live within
the community of consulted end-users. It is the objective now to prioritize it with a
view to meet the needs of the market as neatly as possible, yet, to remain within the
constraints set by time and resources available in the Life+ project. The further detail
of the functionalities implemented in the WEISS Life+ project will be described in this
Product Specification Document.
First, a summary of the most important user requirements is given
WEISS:
is an inventory of all significant emissions, discharges and losses to water
bodies caused by human activities;
simulates the pathways of the pollutants from sources to sinks and
quantifies the importance of the flows in various nodes of the transport route;
estimates pollution aggregated over a 1 year period: no seasonality nor peak
flows nor extreme weather events;
is in principle unlimited with respect to the sources and the pollutants to be
incorporated;
enables accounting in line with the requirements of the mandatory
monitoring and reporting obligations;
5
delivers a good balance between completeness and user-friendliness;
During the development of the functional specifications, the focus was on the WEISS
approach: its user-friendliness, flexibility, applicability, effectiveness and technical
specifications. How adequate is WEISS for addressing specific problems in a specific
region?
The WEISS approach is:
essentially bottom-up;
is geographically explicit and grid-based: the user chooses the resolution
in function of his needs and data;
allocates the source respecting its physical manifestation in space as well as
data availability;
incorporates the various pathways;
supports accounting at various levels of detail.
2.2 Functional specifications
2.2.1 Installation and general set-up
After its installation, WEISS is available as an empty shell with generic algorithms
and functionalities to perform the desired calculations and deliver the desired
outputs. From this point on, the user can start creating overall WEISS data files (.ini)
which are defined by:
- a fixed application region: this is the global area for which all calculations
will be performed. It has to be set from the beginning and cannot be changed
once the project has begun. The assumption underlying this design choice is
that the data (in particular the Emission Factors and Emission Explanatory
Variables) entered in the system are area specific and hence would change if
the area is changed. In principle, WEISS will always perform all of its
calculations on this area. During analysis mode, it will be possible to zoom in
on a sub-area for viewing or selecting more detailed information
- the spatial resolution: Select one base resolution for the application,
determined by:
• the sources dealt with
• the spatial detail desired
• the legislative framework
• the quality of the base data
• computational constraints: size of the study area/region, and number
of sources and pollutants
WEISS will perform all its computations at this base resolution.
- a calculation year: For reporting purposes, WEISS allows only a temporal
resolution of 1 year. The database enables to enter data for more than one
reference year. In fact, it is flexible at this level, meaning to say that not
6
every source needs to be represented for all reference years. When
performing a calculation for a precise point in time, WEISS will automatically
select the data from the reference year which is nearest, but smaller or equal,
to the defined point in time.
The first screen that appears after installing and opening WEISS will be a dashboard
view:
This example shows the empty dashboard, which will be displayed when opening
WEISS for the first time. On the left side, the user is able to create a new datafile.
Once the tool is used, the user will also be able to open existing datafiles by browsing
to the right directory or selecting one of the most recent datafiles which were opened
before.
In the lower left corner, the user will have the possibility to open the documentation.
The right side will show details of the currently opened datafile, but as long as there
is no existing, nor opened file this will remain empty.
7
2.2.1.1 First .ini datafile
In order to guide the user carefully through this initial set-up process, the system will
save the 3 parameters through a step-by-step process. This process will be repeated
each time the user wants to set up a new datafile.
The user chooses the name of the new datafile, for example “Vlaanderen 2012” and
selects the “Create” button.
During this process the user will get specific orders to set-up these parameters, like
the file-format of the application map, and information of the consequences of
selecting a certain spatial resolution.
Once the first datafile is created, the current set-up is shown on the right:
8
The calculation year shown here, has another functionality. Because it is possible in
WEISS to insert data for multiple years, the user is able to select a previous
calculation year to check the input data used during that year or even perform extra
analysis on that data. It will indeed not be possible to change input data of years,
other than the last. This is to avoid that data, which has been the subject of
reporting would be changed, hence that the reported numbers could not be
reconstituted anymore.
The user has the possibility to create new “calculation” years. This will close the
current calculation year and will freeze the data in the database. This would allow for
functionalities such as trend analysis and year-by-year comparisons.
By creating a new year, the user is asked whether he wants to copy the data of the
last to current year, in order to change the former data or start with a clean
datasheet.
2.2.2 Overview & navigation
Selecting “Start” will lead you to the detailed screens. In general, WEISS will be
organised with a classic input-calculation-output set-up:
9
The user-interface will help the user through these various steps:
• Setting-up the system: specifying the sectors, sources and substances
• Defining the parameters: Emission factors (EF) and Emission Explanatory
Variables (EEV), characteristics of the UWWTP and sewage infrastructure, and
the set-up of the run-off module.
• Computing: performing default or specific calculations by selecting the
source(s), sector(s), substance(s) or subsets of them all.
• Analysing: viewing the outputs in map and tabular format per region,
hydrological unit, UWWT-unit, user-defined area, etc.
Each side-bar menu item will be discussed in detail in the next chapter.
2.2.3 Input – calculation – output: details
One of the most important aspects of WEISS will be the insertion of input parameters
available in the selected application region. Within this project, the Flanders case will
be used to develop and set-up the system and examples shown in the mock-up
screens will therefore be of this area. But in general, WEISS will be developed as a
generic tool that can be implemented in each desired application region and will allow
calculation with more or less detailed data.
Once all the data parameterisation is done, the user can perform multiple new
calculations or work on existing ones. After each computation, output is generated
for a minimum of one source and one pollutant and a maximum for all sources in all
10
sectors and for all pollutants. The results are automatically stored in a temporary,
local version of the database and are available to be analysed.
Input
The WEISS Conceptual framework shows the architecture of WEISS, consisting of in
fact mostly geographical submodels or other input parameters and thus are
represented in the scheme by means of a mapping-layer symbol. All these input
parameters will be integrated into one complete computer based system, which
improves the harmonization of the quantification of emission data.
A number of GIS-modules, models and operators have to be parameterised:
The user of WEISS decides on the level of detail required / desired / possible for his
application:
The set of substances considered;
The set of sources and their nesting;
The specification of the Emission Factor(s);
The Emission Explanatory Variable representing the source;
The spatial representation of the sources and their transport;
The run-off module;
The characteristics of the UWWTP and sewage infrastructure;
Details of the water system for the selected application region.
11
An important note is that each uploaded GIS-map has to comply with the setting
given to the application region and the spatial resolution. All maps have to be
uploaded with the same coordinate system as the application region.
1. Substances
The first step is to insert all significant substances (Nitrogen, phosphates, heavy
metals, PAH… ) for mandatory reporting or more specific for the application region
and the performing institution. The list can be extended or shortened freely.
Each substance contains following information:
- Group (*)
- Symbol (*)
- Name (*)
- Measurement unit (*)
- Mobility in soil
- CAS-number
- Reporting obligation: E-PRTR (Yes/No), WFD (Yes/no), WISE SoE (Yes/No)
- Validity date
- General remark field
(*) obligated field
This will result in a simple table screen with an overview of all substances, sorted by
group.
12
The user has the possibility to add new substances, to change existing ones. Deletion
is not possible, but the validity date will be used to set a date from which on the
substance is no longer allowed to be used in the calculations.
The user also has the possibility to create new groups (ex. Metals, PAH’s, ...), change
the name of an existing group or delete an existing group with no substances.
In order to promote user-friendliness of first use, an option is foreseen to upload all
this information at once with a default .cvs template file.
2. Sources
Sources can be point sources, meaning that they are precisely located by means of
their X-Y coordinates. Households are a good example of this. But sources can just as
well be diffuse and cover the entire territory in pockets of higher or lower density.
This is the case among others for atmospheric deposition. Here we name them
surface sources. Finally sources can be distributed along networks or line objects.
Here we name them line sources. Various forms of traffic and road infrastructure are
examples of the latter.
Available information with regards to these emissions needs to be allocated and
mapped as precisely as possible with respect to their true location in space. Each of
these types of emissions need to be allocated by means of the appropriate spatial
algorithms operating on ancillary (cartographic) information representative of the
location of the source.
This is most straightforward for the point sources as they are reported and hence
located on the basis of precise X-Y coordinates. For the location of surface sources,
dasymetric mapping has already been applied successfully in the studies carried out
so far, but other allocation techniques will be implemented too. For line sources,
various forms of allocation proportional to the presence of the source on the network,
or the intensity of usage of the network will be applied.
Their contribution to the overall pollution will be estimated on the basis of the 2
essential concepts, namely: Emission Factor (EF) and Emission Explanatory Variable
(EEV). An Emission Explanatory Variable (EEV) represents the real physical source
causing the emission, such as a ‘detached house’ emitting heavy metals, or, a
‘farming activity’ emitting nitrogen. An Emission Factor expresses the amount of the
substance released per unit of EEV, such as the amount of zinc emitted per year by a
typical detached house, or the amount of nitrogen emitted by one ha of a field
growing crop X.
WEISS should be able to incorporate all emitting sources generating significant
pollution quantities. Treating sources at different levels of abstraction in line with
data availability will be supported. Extending the system in the course of time with
more sources, or disaggregating sources in more specific subcategories is possible.
In order to capture all significant emissions, discharges and losses to water bodies
caused by human activities, a nesting principle is proposed:
13
� Sector
� Sub-sector
� Source
� Substance
Again, the screen will give a clear overview of all data available. The Sector-Sub-
sector(s)-Source nesting is represented on the left side with a general tree view. In
the right part, detailed information, not in the least the table with the Emission
Factors per substance of the selected source is shown.
The user will have the possibility to add new sectors, sub-sectors and sources or
change the name of any of those. Deletion is only possible for sectors or sub-sectors
which don’t have any sources yet. Sources will also work with a validity date.
Other information that will be set for sources are:
- Name (*)
- Type (point, line, surface) (*)
- Path: Drain percentage, Surface percentage, Water percentage and Loss at
source percentage (*)
- E-PRTR or SME –source
- URL-link to factsheet
- Validity date
- General remark field
14
Each source will then allow a selection of relevant pollutants (based on the total list
of substances) of which next data is needed:
- Emission factor (EF) of each selected pollutant (*)
For every source, the EF per unit of Emission Explanatory Variable (EVV)
needs to be specified. EF can be a single number if it applies uniformly over
the whole territory, but it can also be a GIS-map if it is geographically
specific. Emission Factors can be entered and visualised.
- Validity date
- Emission explanatory variable (EVV): see 3. Algorithms (EVV) (*)
- Rain-sensitivity
(*) obligated field
3. Algorithms (EVV)
Each sector has specific characteristics that need to be taken into account and
treated with great care. A generic set of algorithms which can be maximally tuned to
the precise (and competing) needs of each sector will be developed in order to
enable this in an efficient manner.
Each algorithms will generate raster GIS-maps and each source can then be linked to
an algorithm to compute it’s EVV.
A detailed description of the applied algorithms will be provided in the Architecture
and Design document (deliverable 10). The initial parameterisation of each algorithm
will be possible with a clear step-by-step procedure.
4. Pathways
15
WEISS also considers various pathways through which significant pollution quantities
are transported or discharged:
a. Overland transport of diffuse sources will be handled by a run-off
algorithm. Pollutants thus transported will end-up directly in the surface
water, in ditches and other drainage networks and/or in the sewage
network.
b. Point sources will often deliver their waste waters directly to the sewage
system. The sewage network will transport the waste waters and
dissolved pollutants to the sewage treatment plants where the pollutants
are partly removed. The remainder will be discharged in the surface water
as part of the effluent.
c. Another part of the pollutants will infiltrate into the soil and further into
the groundwater. They are transported dissolved in the groundwater to
feed the surface waters in particular locations where groundwater
surfaces.
For each of these pathways, a step-by-step approach will be proposed to
parameterise the available data in the application region to raster-GIS maps which
can be incorporated into the calculations module.
a. Run-off
These are essentially 2 raster GIS-maps:
16
(1) the run-off coefficient per cell expressing the quantity of the pollutant (or
water) flows into the downstream cell on an annual basis
(2) the Local Drainage Direction (LDD) defining the direction of the flow from a
cell to its downstream cell
In Flanders, the WETSPA-model works with a DEM and LDD network for run-off-
model.
b. Sewage System
This is a vector GIS-map showing the location of the sewage network, including the
location of the UWWTP. It also incorporates tabular information with respect to the
UWWTP (type, efficiency for various substances, etc.) which can be consulted by
clicking on a UWWTP.
In Flanders, the sewage network AWIS, version May 11th 2010, will be used after a
compatibility analysis and implementation in WEISS.
Detailed maps are used to calculate and follow the transport through the sewers.
17
c. Water system
This is a vector GIS-map with the location of the water bodies and the associated
basins.
5. Geographical entities
The system has to be geographically explicit and able to handle different
geographical scales: aggregation towards level of municipality, smaller basins and
sub basins and even on water body scale.
WEISS offers the possibility to select any area you wish to report for or set-up pre-
defined areas like cities or an area that you delineated yourself. From country to
waterbody. The desired area and its subdivisions has to be entered by means of a
raster map.
18
Computation
The user will be able to perform computations filtered by:
• One or more sources;
• One or more sectors;
• One or more substances.
Results are stored each time. When a specific ‘sector-source-substance’ combination
is run again with new parameters, the stored data will be overwritten.
To give the user an overview of which calculations are run, we will use some clear
icons visualise the status of each ‘sector-source-substance’ combination.
19
The user also has the opportunity to compute all combinations at once. This will give
the most flexibility during analysis.
20
Output
Once output is generated, the user is able to analyse it in different ways:
• Selection of map-output per node in the flow-diagram;
• Map output is stored and available to user for further analysis, using a Map
manager;
• Tabular output, also per node in the flow-diagram;
The base screen from which every analysis should start, is the set-up flow scheme:
WEISS generates for every source and every substance:
� A map of the gross emissions to the surface waters;
� A map of the net emissions to the surface waters;
� A map per node in the flow diagram;
This means that, starting from this screen, each possible output can be consulted.
For now we will focus on 5 types of output that is required:
• Maps: geographical output
• Top 10: table of 10 most important contributors
• Brut/Net: comparison of brut/net emissions of the selected area
• Tables: Data in tabular output, like averaged data or specific reporting
• Scenario-analysis
WEISS will allow quick navigation between different Sector-Substance-Sources
combinations or management of multiple-source and multiple-sector computations.
Also the possibility to select any geographical entitie you wish to report for or set-up
pre-defined areas like cities or an area that you delineated yourself.
21
1. Maps
By double-clicking on the preferred node, the map manager will open a new screen
with detailed geographical explicit information:
22
The WEISS Map Manager will offer typical geo-component functionalities: The map
view of the model output allows the user to visualise the model output. A GIS viewer
is provided to the effect that allows the user to do typical GIS operations such as
zooming, panning, viewing coordinates, add information layers (rivers, sewage
network, borders), change legends, ...
2. Top 10
By selecting the top 10 menu option, a graphical representation of 10 most important
contributors is shown:
3. Brut/Net
23
The brut/net calculation will allow the user to view a graphical comparison or view
directly into the datatable:
4. Tables
24
In the Tables menu-section the user will be proposed several types of tabular output
or tabular output transformed geographically, like pie-charts:
25
WEISS output will deal with prescriptions for state of the environment reporting in
the framework of the Water Information System for Europe (WISE) and use of an
advanced Shared Environmental Information System (SEIS) compliant reporting
technology.
Together with the Flemish Environmental Agency a couple of reporting templates for
for mandatory EU-reporting will be set up.
For each tabular output, it is possible to export the necessary data to Excel.
5. Scenarios
Finally, WEISS will also offer scenario-building functionalities. The user will be able to
define specific measures, like implementation of EU directives, ban of products,
decreased use, treatment efficiencies or riparian buffers.
When a complete calculation is run with the reference data, WEISS has to be set-up
user-friendly and flexible enough to change certain necessary parameters easily,
without overwriting all existing reference data. New computations will be done on a
mirror database, which allows assessing the outcome of measures.
26
2.3 User requirements out of scope
Unfortunately, not all user requirements listed in the User Requirements Document
are possible to be implemented. In this paragraph we report the requirements which
are considered out of scope for the moment. If project resources permit, they could
be reconsidered later. Similarly, the ‘out of scope’ list can become longer with time
and as resources are getting to be depleted.
• Flow scheme adaptations: Possibility of adding nodes and pathways in
the flow scheme.
• Specific reporting needs:
o Specific output for Water Quality Models: WEISS should be able in
the future to deliver compatible and right input data for water quality
models.
o Specific output for obliged EU reporting: The list of EU reporting
needs is long. In this first development of WEISS a first example will
be given of the reporting possibilities of the tool, but not all EU
reporting needs will be in scope.
• Take into account the impact or inflow of pollutants of neighbouring
countries or areas: In the future WEISS could offer the user the possibility
to draw a buffer around study domain to account for the run-off impact of
surrounding sources.
• Possibility to run future estimation: based on data from different
followings years, it should be possible to set simple trend lines. A more
interesting approach could be the involvement of future EVV’s based on
scenario analysis towards the future.
• Possibility of seasonal, peak variations: During both workshops, different
stakeholders asked about the possibility to introduce seasonal or peak
variations instead of yearly calculation. Technically this could be feasible.
However it would require a lot of additional data.
• Scenarios
o Comparison of several scenarios/measures
o Comparison with current situation.
o Identify trends over years.
o Possibility to enforce a transport route
27
CHAPTER 3 NON-FUNCTIONAL SPECIFICATIONS
There are a lot of choices that have to be made when designing a software
architecture. The appropriate option in these choices depends on the functional and
non-functional requirements of the applications that will be built using the
architecture.
In this chapter, the non-functional specifications are treated. The following quality
attributes were identified:
3.1 Software development
3.1.1 Development
WEISS will be developed as a Windows standalone C++ application. The user
interface is a Multiple Document Window interface. It thus allows to view the
contents of several windows simultaneously.
28
3.1.2 Authentication
As a stand-alone version, no authentication is required. Each user with access to the
PC can open WEISS and modify databases.
3.1.3 Performance
The general performance of WEISS has to fulfil the standard user needs, this mains
that screen action will be executed within 3 seconds for 95% of the time.
Only the calculation run will be an exception. Depending on the selected sectors, sub-
sectors, sources and substances, the computation run can take some time. During
the development process action will be taken to lower the calculation time as much
as possible.
For example,
3.2 Language
The languages in the user-interface of the resulting system will be English and Dutch
(a Dutch and English version will be developed). An extension to another European
language will be limited to the translation of the terms used in the user-interface and
their incorporation in a table, however will require the intervention of the developers.
The user is allowed to input all the data in his own language, so specific output will
also be available in this language.
3.3 Documentation
WEISS will be available as an executable with documentation and training materials.
It is a computational framework and will essentially be an empty shell, set up to
perform the required calculations in a generic fashion. For that reason a clear set-up
user guide will be delivered.
3.4 Installation
The executable will guide the user through the installation process.
29
3.5 Security
No specific security requirements are implemented.
30
CHAPTER 4 CONCLUSION
Based on these functional and non-functional requirements, a prototype of WEISS
will be developed as a first full-scale application for the Flemish region, Belgium,
which represents the most densely populated areas of the Scheldt and Meuse River
Basins.
The envisaged system and its models will be highly generic in nature: its algorithms
represent well studied physical processes and principles such as the conservation of
mass, water balances, water movement through channels, etc. at an appropriate
level of detail. The scale of analysis can be set to the goals and end-user
requirements of the system. The architecture of WEISS will enable it to be easily
adapted for situations outside Flanders.
The next action will define the essential underlying components as well as their
technical implementation and integration into WEISS. It is an activity that will result
in the precise technical design and software architecture of the WEISS system which
is essential for the practical implementation of the system. This will involve additional
decisions on the selection of components in terms of algorithms, models and
associated analytical tools for data management, visualization, reporting and
assessment.
During the different development cycles of the evolutionary delivery development
methodology, the different prototypes will result in increasing complexity and
capability. This means that the specifications drawn out in this document can be
extended or changed during the course of the development. This is also the reason
why some functional specification are not yet drawn out in full detail.
In order to assure the optimal usability of the final product (as well as each
intermediary prototype), the end users will be involved in the development process
along the way. Every intermediary product will be assessed duly with respect to its
level of utility and usability.