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.