AG-3144-I-16-0059_OCIOIP_Supplemental_Specification.pdf

OCIO Integration Project (OCIOIP)

Non-Functional Requirements Page 1 of 6 August 17, 2016

Supplemental Specification

Non-Functional Requirements Page 2 of 6 August 17, 2016

Table of Contents

1. Introduction

2. Usability

2.1 Accessibility

2.2 OCIO Common Look and Feel

2.3 Mobile Web-friendly Access

2.4 Personalized Access

2.5 Data Export and Printing Capabilities

2.6 Pre-populating Input Fields

3. Reliability

3.1 Availability

3.2 Mean Time To Repair (MTTR)

4. Performance

4.1 Response Times

4.2 Capacity

5. Supportability

5.1 Messages

5.2 Solution Organization

6. Design Constraints

6.1 USDA Integrated IT Governance Framework (IITGF)

6.2 User Interface (UI) Separation

6.3 Single Page

7. Security

7.1 eAuthentication

7.2 Username and Password Process

7.3 User Roles

7.4 User Access

8. Logging

8.1 Audit Trail

9. Purchased Components and Licensing Requirements

Non-Functional Requirements Page 3 of 6 August 17, 2016

OCIO Integration Project (OCIOIP) Supplemental Specification

1. Introduction

The supplemental specification document captures the solution requirements that are not readily captured in the use cases of the use-case model, including:

Legal and regulatory requirements, including application standards.

Quality attributes of the system to be built, including usability, reliability, performance, and supportability requirements.

Other requirements, such as operating systems and environments, compatibility requirements, and design constraints.

2. Usability

2.1 Accessibility

The User Interface will be fully compliant with section 508 requirements. Section 508 compliance requirements are documented at http://www.section508.gov/.

Parts of the system intended for users such as the user interface and user manuals will be written in plain language with minimal use of acronyms, abbreviations or unfamiliar terms. When necessary to use these items, inline explanation or context help should be provided. No references to internally-used systems should be used.

2.2 OCIO Common Look and Feel

The User Interface will incorporate existing USDA design guidelines and related body of knowledge where and when appropriate in the design process

For internal access, Internet Explorer will be the standard browser.

For public access, Internet Explorer, Chrome and Safari will be the standard browsers, but other browsers may be used to access the application. The user interface design should allow flexibility to support multiple browsers. For optimal user experience, extensive testing will be limited to the latest versions for these browsers.

2.3 Mobile Web-friendly Access

The solution will render optimally for different device types including smartphones, tablet, laptops and desktops utilizing a responsive design.

The solution shall provide access to “full site” functionality on all supported device types.

2.4 Personalized Access

The solution will provide personalized access that will limit or customize the information presented to the user based on his role and authorization.

2.5 Data Export and Printing Capabilities

The solution will provide standardized (clean, well-formatted) printable results that can be previewed and printed from all sections for the site.

The solution will allow for the consistent publishing of well formatted PDF files for specially selected sections of the site.

Non-Functional Requirements Page 4 of 6 August 17, 2016

The solution will allow for the consistent export of well formatted data in CSV format that can be opened in excel and other popular data manipulation tools.

2.6 Pre-populating Input Fields

The solution shall make use of existing or known information (pre-populating input fields) to drive system behavior, simplify user interactions and make interaction more efficient.

Drop down lists, selection boxes, etc. shall be used whenever possible to minimize the possibility of data entry errors.

3. Reliability

3.1 Availability

The desired availability is 24x7 with expected peak usage being after business hours (Monday through Friday 6am – 6pm central). System maintenance shall be performed outside of normal business hours.

3.2 Mean Time To Repair (MTTR)

MTTR should be no more than 1 week. When the solution is down information can be provided to customers through the use of internal applications that are available during business hours.

4. Performance

4.1 Response Times

All queries must be completed within 100 milliseconds and rarely exceed 1000 milliseconds. The response time is limited to the system boundary and does not include external network latency.

All updates must be completed within 200 milliseconds and rarely exceed 1000 milliseconds.

All operations taking more than 10 seconds should have explicit indication of progress

4.2 Capacity

The figures given here are estimates as the solution does not have legacy information to determine exact figures:

Number of primary users --------- 1000

Number of concurrent users ------------ 40

Number of user hits per month ------------ 150

5. Supportability

5.1 Messages

A centralized feature shall be provided for capturing exceptions, system and business process messages. Standardization shall be required on how and when to use this mechanism within each component of the system.

Logging of messages may be accomplished through the use of flat files, database, or system console.

5.2 Solution Organization

The solution shall be designed to allow for growth. Many important features will not be available in early releases. The solution shall be flexible so the full site rewrites are not required.

Non-Functional Requirements Page 5 of 6 August 17, 2016

The solution shall be designed to allow for dynamic generation of links and references. Links and references change slowly over time and should not be hard-coded into the solution.

The solution shall clearly organize links and references to external content in such a way that it is not confusing to the user.

6. Design Constraints

6.1 USDA Integrated IT Governance Framework (IITGF)

The solution will be developed following the methodology defined in the USDA IITGF.

All required artifacts will be developed in accordance with the SDLC Statement of Understanding.

6.2 User Interface (UI) Separation

The application must have complete separation between the User Interface and the backend systems/services. This means that nothing in the UI can be coupled to a backend system.

There must be no business rules in the UI layer. All business rules shall be applied before any data is passed to the UI layer.

The UI cannot have knowledge of internal data fields and structures pertaining to a backend system.

No backend services shall have any knowledge of how the UI layer operates.

Any communication between the UI layer and the backend services must be thru well defined RESTful service interfaces i.e. the server does not keep track of any client state information.

6.3 Single Page

A Single Page Application (SPA) is a web application designed to fit on a single page with the goal of providing a rich user experience similar to a locally-installed desktop application. All necessary static code—HTML, CSS, and JavaScript—is to be retrieved when the page is initially called.

Additional resources can be loaded dynamically in response to user actions if such a design is desired. However, the page is never wholly reloaded in order to improve responsiveness and user experience.

AJAX (Asynchronous JavaScript and XML) is a crucial piece of the Single Page Architecture.

Despite the acronym, development may be with either XML or JSON (JavaScript Object Notation) as the data interchange format, gaining access to improved efficiencies offered by JSON. JSON is the preferred format for this solution.

The solution shall use AJAX calls to retrieve data from backend services without the need to reload the page. The data retrieved can then be applied, changing only smaller parts of the visible page.

All static content shall be cached in a Content Delivery Network, resulting in faster retrieval and delivery of said content on initial user access. USDA already has an existing Content Delivery Network based on Akamai that can be used.

7. Security

7.1 eAuthentication

Users will gain access to the solution through USDA eAuthentication with a level 2 account

Non-Functional Requirements Page 6 of 6 August 17, 2016

7.2 Username and Password Process

The standard eAuthentication processes for establishing and maintaining usernames and passwords will be used. This includes forgotten and expired passwords.

o The current eAuthentication requirement for changing passwords is:

Every 60 days for employees and contractors

7.3 User Roles

User roles will be established and controlled through the standard features of eAuthentication.

7.4 User Access

Access to information within the system will be derived from information that OCIO already maintains about a customer without the need to establish special security access that must be maintained by the security office.

8. Logging

8.1 Audit Trail

As changes are made in the system, the application shall provide an audit log including at a minimum, the id of the user who made the change and the timestamp of the change.

9. Purchased Components and Licensing Requirements

TBD