Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
98 The following section describes the functional and non-functional requirements that were identified to guide the development of PMDb. Functional Requirements In software engineering, a functional requirement defines a function of a system or its compo- nent. Functional requirements define what a system is supposed to accomplish. The functional requirements of PMDb are summarized in the table below. A p p e n d i x C Pavement-Maintenance Database System Requirements Functional Requirement Description View resources/references All users will have the ability to browse and review documentation in the system and access links to references and resources used in the development process. View glossary All users will have the ability to browse, search, and review glossary terms and definitions as they pertain to data elements within the database system. Terms should be presented to users in alphabetical order as well as tagged to data elements and attributes. View system statistics All users should have the ability to view the summarized statistics that describe the amount of data contained within the database system. The statistics should include a quantity of pavement maintenance sections, availability of data, types of treatments, all potentially broken out by state agency. It may also be presented graphically by a chart or map to help communicate what states have contributed data to encourage system use. Register for access All users will be able to complete a registration process to request access to datasets within the database system. Access requests will be processed by a system administrator or an email validation routine. Once access is provided, users will receive a notification by email and be allowed to browse, search, and download specific data within the database system. Browse and view system records and source records (pavement sections) Registered users will be able to browse the pavement maintenance sections that are contained within the database to view the data that are available with the section. The goal is to view section locations and treatment types and identify what types of data elements are available for the given pavement maintenance section. Query for pavement section datasets Registered users will be able to query the database system to identify maintenance sections that contain the desired characteristics. Users should be able to select any data element within the database and select either a value that exists or range of values that exist and be presented with a result set of pavement maintenance sections that match the given criteria. Users may combine data element criteria to form a complex filter.
Pavement-Maintenance Database System Requirements 99 Append data Contributor users will be able to append additional data to existing pavement sections over time. For example, it is anticipated that condition data will be collected on a periodic basis and will be appended to the existing pavement section. Contributor users will be able to identify individual pavement sections to add data to. In general, users will be adding condition data, although support will be provided for users to upload and append data elements where they do not exist. At this time, no support for collision detection will be provided, the last data in will override any existing data. Publish data Once a contributor user has uploaded data, the data will remain in a draft state, available and visible only to the contributor user until it is moved to a published state. Contributor users can only publish data they have uploaded through a simple state change for any selected pavement section. Contributor users will not be able to publish portions of data for a given pavement section; it will be all or nothing. Append new data terms and elements Contributor users will have the ability to add new values to the glossary and data terms over time to maintain system flexibility and scalability. During the upload process for data submission, users will be presented with an interface for helping to normalize their existing data with values already in the system. For example, for each maintenance treatment name that doesnât match an existing name in the database, users will be presented the option of normalizing it to an existing value or creating a brand new treatment. This is done in order to help normalize the wide variance in the naming conventions for treatments and group them in a logical way for subsequent analysis. Perform user management functions Administrator users will be able to view all users in the system and manage their credentials and access level. Administrators can reset user passwords, grant a registration request, change user access levels to registered or contributor, as well as revoke access. Administrators may also log in as any user in order to assist with their upload functions or perform a function on their behalf. Modification of data Administrator users will be able to modify or remove data from the database system. At this time, the function will be limited to direct database manipulation; a web interface may be desired if this function becomes a greater need. Download pavement section datasets Registered users will be able to download pavement section datasets from the results of the query for pavement section of the database system. The download will include all pavement section data by default. Data will be packaged into the following format for maximum portability: .csv (100K max rows). Data in the download will match the data model of the database system and include a copy of the current data dictionary. Perform user account functions Registered users will be able to perform standard user account functions. When not logged in, users will be able to retrieve their password by email and log in. When logged in, users will be able to update their profile information and modify their password. They may also request to become a contributor to the database system by sending an email to the site administrator. Submit new data Contributor users will be able to submit new data to the database system for their state. Contributors may only submit data for the states for which they are authorized. Administrators can submit data for any state. For submission, users will be expected to format their existing data into a suitable acceptance format for upload to the database system. This format will be provided in a template to all contributor users for download once logged in. During the import process, users will proceed through a workflow discussed below to help normalize their data to the existing dataset such that meaningful analysis can be conducted. Functional Requirement Description
100 Framework for a pavement-Maintenance database System Non-Functional Requirements A non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions. A summary of the suggested non-functional requirements for PMDb is described here. Product Requirements ⢠Performance requirements (availability, capacity, speed, and storage): ⢠The system should be available 99% outside of scheduled maintenance periods (down < 87.6 hours per annum). ⢠Scheduled maintenance periods for upgrades ⢠No more than 24 hours of downtime per month ⢠Estimated total capacity of 250 registered users (5 per state) ⢠Maximum simultaneous connections projected at 2% user load (5 users) ⢠Reliability: can have up to a maximum of a single week outage at a time (not a mission critical application) ⢠Alert users of application downtime or outages via the maintenance page with email notifica- tions to user account emails ⢠Network response (browser client) ⢠Reports and visualizations: simple reports and visualizations which render non-compound query content should be constructed and viewable in under 10 seconds. ⢠Page loads should take less than 5 seconds to complete ⢠Data downloads will happen asynchronously (may take longer time) ⢠Connection speed supported ⢠Broadband internet connection (256 kBps or better) ⢠Scalability and load: the system should be able to maintain the aforementioned speed requirements on the server to support the maximum simultaneous web users ⢠Initial support for less than 500 GB is expected based on sample data from customers. ⢠Database and file storage is expected to grow over time both with additional projects and more data per project. ⢠The system should provide scalable support for storage either locally or in the cloud to manage large datasets. Interface Requirements ⢠Display size and resolution ⢠Minimum screen resolution of 1024 x 768 as this application does not demand nor warrant mobile access. ⢠Widescreen support (1366 x 768) ⢠Standards requirements ⢠The systemâs communications should function over HTTP V1.1 and be compliant with the latest web standards. ⢠Look and feel standards to follow applicable branding and font guidelines. Security Requirements ⢠Access to the website URL will be available to all Internet users. ⢠Access to individual functions of the website will be managed by user groups as described later in this document.
pavement-Maintenance database System Requirements 101 ⢠Encryption strength: no encryption will be used for this project at this time as the data is all public domain. User Account Requirements ⢠Username will be the email address registered to the user account. The username will be used as the key value in the authentication process. All government issued emails (.gov) will be validated as registered users. ⢠Passwords should contain at least eight characters, at least one upper- and one lower-case letter, and at least one number. Passwords will not timeout. ⢠Metadata ⢠All user accounts will be required to provide a first and last name. ⢠All user accounts will indicate what organization/agency they work for. Portability Requirements ⢠Browser client: browser interfaces will be compatible with the most current version of Chrome, Firefox, and Safari at the time of release. Internet Explorer, Version 8 and above, will be supported as well. ⢠Server: platform and architecture of the server component will be on Linux x64 systems, utilizing PHP 5.3+ to provide multiple release options. Operational Requirements ⢠Failure and restart: In the event of failure, the system shall provide for the execution of an automatic restart process. ⢠During the process of automatic restart, there should be a default webpage displayed to browser client users and a message to tablet client users (in the event of a synchronization request), announcing that the system will be available shortly. ⢠In the event of an automatic restart, the system will be fully functional within 120 seconds of rebooting. ⢠All data file transfers between the client and the server will occur via an asynchronous batch- ing process that provides a per-batch file download confirmation to the sender when ready. ⢠Downloaded data files shall be stored for 30 days and then removed from the server to limit storage requirements. Maintainability Requirements ⢠The system will support an update release process which will involve taking the system offline for no longer than 24 hours. Usability Requirements ⢠The system should allow for training and orientation via solely online resources. ⢠No further assistance should be required to become proficient in the use of the application. Support Requirements ⢠Documentation will be supplied via access to online materials hosted on the site. ⢠Documentation to include: userâs manual for end users ⢠Case study examples of conducting search and analysis
102 Framework for a pavement-Maintenance database System ⢠Integrated help tool tips for users (included within application) ⢠Localization: The system will not support localization. ⢠English language only ⢠U.S. customary units only Infrastructure Requirements ⢠Cloud or Single Machine Support ⢠The system will be deployable to a cloud implementation such as Amazon Web Services (AWS), as well as to a Linux, Apache, MySQL, and PHP (LAMP) stack local or customer controlled machine. ⢠The system should be designed in a manner that allows for movement between solutions in a somewhat simple manner. External Requirements ⢠Legal requirements or disclaimer: the system must support the display of a standard dis- claimer message to the user.
