Supplementary Specification Template

This document was developed for use by programs assigned to the Business and Enterprise Systems Directorate
(AFLCMC/HI), and does not constitute official issuance of DoD or AF policy.

File: Supplementary Specification Template Last updated: 24 September 2018
SUPPLEMENTARY SPECIFICATION TEMPLATE

FOR
<PROJECT NAME>
Page 1 of 12
Revision History
Date Version Description Author
<dd/mmm/yy> <x.x> <details> <name>
Page 2 of 12
Table of Contents
1. Introduction 5
1.1 Purpose 5
1.2 Definitions, Acronyms and Abbreviations 5
1.3 References 5
2. Functional Requirements 5
2.1 <Functional Requirement One> 5
3. Usability 6
3.1 Navigation 6
3.2 Consistency 6
3.3 Language 6
3.4 Accessibility 6
3.5 Organization 7
3.6 Aesthetics 7
4. Reliability 7
4.1 Availability 7
4.2 Mean Time Between Failures (MTBF) 7
4.3 Mean Time to Repair (MTTR) 7
5. Performance 8
5.1 Response Times for Application Transactions 8
5.2 Page Code Size 9
5.3 Throughput 9
5.4 Capacity 9
5.5 Instrumentation 9
5.6 Degradation modes (what is the acceptable mode of operation when the system has been
degraded in some manner) 9
6. Supportability 9
6.1 Maintenance 9
6.2 Extensible 10
7. Auditing 10
7.1 <Auditing Requirement One> 10
8. Software Design 10
8.1 Requirements Modeling 10
8.2 Object-Oriented Analysis: 10
8.3 Object-Oriented Design: 11
9. Development & Design Constraints 12
9.1 Software Language 12
9.2 Architecture and Design 12
10. Online User Documentation and Help System Requirements 12
10.1 Online help 12
10.2 Customer support center 12
11. Legal, Copyright, and Other Notices 13
Page 3 of 12
RDTM009
1. INTRODUCTION
The supplementary specifications along with the <use case model, the use case
specifications, and the design model> will serve as the primary input to the developers,
designers, and other groups working on the development and maintenance of the
<application name> system.
1.1 Purpose
The purpose of the supplementary specification document is to capture the following
information
 Feature sets and capabilities that need to be offered to the users.
 Quality attributes of the system such as usability, reliability, performance, and
supportability requirements.
 General security requirements.
 Requirements such as design constraints, operating systems and environments.
1.2 Definitions, Acronyms and Abbreviations

 Refer to the project glossary document for all definitions of terms, acronyms and
abbreviations.
1.3 References
 BES Process Directory (BPD)
 Performance Recommendations for Information Systems (IS)
2. FUNCTIONAL REQUIREMENTS
[This section describes the functional requirements of the system for
those requirements that are expressed in the natural language style. For
many applications, this may constitute the bulk of the SRS Package and
thought should be given to the organization of this section. This section
is typically organized by feature, but alternative organization methods,
for example organization by user or organization by subsystem, may also
be appropriate. Functional requirements may include feature sets,
capabilities, and security.
If the functional requirements for the system are documented elsewhere
in a requirements tool such as DOORS or RequisitePro, or in Use Case
documents, then they can be merely identified by reference here.]
2.1 <Functional Requirement One>

[The requirement description.]
Page 4 of 12
3. USABILITY
3.1 Navigation
 Use a recurring navigation bar that is consistent and appears in the same location on
all the pages.
 The user should never arrive on a dead-end page with no further navigational options.
 Use short descriptive titles at the top of each page so the user has a clear
understanding of where they are in the application.
 For pages that need to be printed assure that the output will be printable.
 If graphic images or icons are used as links, they should be representative of the
information available from the link.
 Searches should be flexible to allow users to specify as little or detailed criteria for
the search.
 Users should not be required to scroll excessively to view the content on a page.
 Help should be easily accessible from any page and clear instructions should be
provided on all the different means by which the user can contact customer support
for more information.
3.2 Consistency
 The presentation of information and the look and feel should be consistent throughout
the entire application
 Text, buttons, and images that appear on multiple pages, should be placed in the same
location on every page unless there is an overriding design factor.
3.3 Language
 Use domain language that the application users will be familiar with.
 Provide definitions in the help screens for terms that might need clarification.
 Use terms consistently across the application.
3.4 Accessibility
 Users should be able to seamlessly use all sections of the application after a single
sign-on.
 The application should be accessible from <minimum supported browser. i.e. -
Microsoft Internet Explorer v7.0> and above
 Users who are using a text only browser should be able to view and navigate the
contents of the application.
Page 5 of 12
3.5 Organization
 From the application homepage the user should have easy access to all the
functionality that they are required to perform on a regular basis.
 The user should have a clear indication at the top of each page as to which section
they are in.
 Application should be flexible to allow users to search for content using different
search criteria.
 For information that is not real-time, user should be informed as to when the
information was last updated.
3.6 Aesthetics
 Application users should be informed of any fields/information in the application that
is editable by the user and should not have access to modify any fields/information
that they are not authorized to.
4. RELIABILITY
4.1 Availability
 The application and all application functionality will be available to its users on a
Uptime => Downtime/year

< 99 => 87.66 hours >
< 99.5 => 43.83 hours >
< 99.9 => 52 minutes >
* Based on 365×24. Add on another 6 hours to average in the effect of leap years = 8766 hours per
year.
 If any scheduled maintenance is necessary it will be performed during <a 4-hour
window on Sunday morning from 6:00 am – 10:00 am CST>.
4.2 Mean Time Between Failures (MTBF)

 On average the application should be designed to meet a mean time between failures
of <4 months or greater>.
4.3 Mean Time to Repair (MTTR)

 If system downtime occurs the system support staff should be notified immediately.
This will be achieved by real-time monitoring of the systems.
 Any server hardware related downtime should be resolved and the service should be
restored within a <one hour> time period.
 Any external services downtime should be resolved and the service should be restored
within a <two hour> time period.
Page 6 of 12
 Accuracy – specify precision (resolution) and accuracy (by some known standard)
that is required in the systems output.
 Maximum bugs or defect rate – usually expressed in terms of bugs/KLOC (thousands
of lines of code), or bugs/function-point.
 Bugs or defect rate – categorized in terms of minor, significant, and critical bugs: the
requirements must define what is meant by a “critical” bug; for example, complete
loss of data or complete inability to use certain parts of the functionality of the
system.
 Application deficiencies – refer to the BPD Deficiency Reports Guide for definitions
of deficiency priorities and their associated time limits.
5. PERFORMANCE
Application developers should fully utilize the best practices and recommendations
published in the Performance Guide for an Information System (IS).
5.1 Response Times for Application Transactions
The application shall provide a repeatable response and must provide acceptable response
times to the user. The thresholds assume the government furnished infrastructure meets
or exceeds the minimum DoD standards.
 Threshold: All functionality shall be repeatable with the same client presentation
<100% of the time>
 Threshold: <90% of application transactions shall execute within 5 seconds>
 Threshold: <100% of application transactions shall execute within 120* seconds>
 Objective: <99% of application transactions shall execute within 5 seconds>

 Objective: <99% of application transactions shall have an internal transaction time
of less than 2 seconds>
5.1.1 Long-running asynchronous tasks

Tasks such as scheduled reporting and data warehousing transactions add a performance
load to the application. Performance requirements for these types of transactions must be
tailored to the specific transaction characteristics and needs of the application. The
general performance characteristics of the application assume that these tasks are running
during off-peak hours, such as overnight. Thus, user response rates during business hours
are not affected.
Page 7 of 12
* - The completion or failure of any transactions over 120 seconds can not be measured due to
current infrastructure (firewall/proxy) timeouts.
5.2 Page Code Size
The application shall be developed utilizing bandwidth reducing strategies/technologies.

The thresholds are for measurement of pages after caching has occurred.
 Threshold: <90% of application transactions shall not exceed 30 Kilobytes>

 Objective: <99% of application transactions shall not exceed 30 Kilobytes>

 Objective: <99% of application transactions shall have a database transaction size
of less the 2 Kilobytes.>
5.3 Throughput
 The system shall be capable of handling <50> transactions per second.
5.4 Capacity
 The system shall be capable able of supporting <1000> concurrent users.
5.5 Instrumentation
Instrumentation of the system source code helps support the requirement for application
performance measurement and analysis. Performance measurement and analysis is the
identification, collection and evaluation of performance measurements that support
management information needs and process analysis and improvement.
 Threshold: <80% (a minimum of 10)> of the application’s transactions shall be
instrumented
 Objective: <100%> of the transactions shall be instrumented
* If the application has less than 10 transactions, then all transactions will be instrumented.
* Any previously non-instrumented module that is modified for a release will be instrumented.
Page 8 of 12
5.6 Degradation modes (what is the acceptable mode of operation

when the system has been degraded in some manner)
6. SUPPORTABILITY
6.1 Maintenance
 The system will allow for scheduled downtimes on Sunday mornings from <6:00am
– 10:00am CST> for performing maintenance on the systems.
6.2 Extensible
 The system should be built so that it can be extended to support additional
functionality in future releases.
7. AUDITING
[This section indicates any auditing requirements designed to ensure internal control
integrity such as:
Detection and monitoring of system permissions or privileges assigned to
all personnel (employees, contractors, partners) to provide any required
audit trails of individual user activities.
Identification of risks of access control systems and documenting
mitigation strategies to safeguard the system and increase integrity.]
7.1 <Auditing Requirement One>

[The requirement description.]
8. SOFTWARE DESIGN
The following are the minimum recommended activities for the software analysis and
design activities.
8.1 Requirements Modeling
8.1.1 Goal
Break down business-level artifacts in order to capture and define computer system's
scope and responsibilities.
8.1.2 Activities
 Identify main business goals, processes, resources, and system features.
 Write use case descriptions with clear identification of actors and data exchanged
between the system and the environment, and the context expressed through pre-
conditions, post-conditions and invariants. Not OO specific.
 Draw use case diagram in order to depict relationships among use cases. Not OO
specific.
Page 9 of 12
8.2 Object-Oriented Analysis:

8.2.1 Goal
Decompose requirements artifacts and build a domain model. Try to establish a cognitive
bridge between the computer system and its environment.
8.2.2 Activities
 Relate use cases with respect to their main concerns. This produces the first level of
the system's decomposition into related functionality domains: domain subsystems.
Show the decomposition on the use case diagrams using the UML package notation.
Repeat this step for any identified domain subsystem. Not OO specific.
 For each domain subsystem, from use case specifications and use case diagrams,
extract classes, attributes, and relationships among them. Show the decomposition
using the UML class diagrams labeled as participants diagrams. Analysts should
have good prior domain knowledge, which should be the main source for the domain
concepts.
 For each use case, utilizing use case specifications use case diagrams, and analysis
level participants diagrams, develop analysis level use case realization interaction
diagrams. Main goals are capturing:
o How objects collaborate to accomplish functionality described in use cases.
o Definition of object interfaces.
o Objects' interaction timeliness and their relational properties.
 Develop state and/or activity diagrams for any additional processes or transactions
with a high level of complexity.
Additional Notes:
All entities and artifacts have to take into account and be related to different constraints,
business goals, business rules, non-functional requirements, and other artifacts captured
during the requirements modeling phase.
8.3 Object-Oriented Design:

8.3.1 Goal
Map domain model into design model taking into account internal system requirements
and development resources.
8.3.2 Activities
 For each domain subsystem, from use case specifications, use case diagrams, and the
analysis level class participants diagrams, add further detail to the classes,
attributes, and relationships among the use case process by creating a more detailed
design level class participants diagram. This should be the first step in transitioning
from the functional to the design/development domain.
Page 10 of 12
 For each use case, utilizing use case specifications, use case diagrams, and design
level participants diagrams, develop design level use case realization interaction
diagrams. Main goals are capturing:
o How objects collaborate to accomplish functionality described in use cases.
o Definition of object interfaces.
o Objects' interaction timeliness and their relational properties.
 Develop state and/or activity diagrams for any additional processes or transactions
with a high level of complexity.
 Define the static view of the system’s run-time configuration of processing nodes and
the components that run on those nodes in a deployment diagram. The deployment
diagram should depict the hardware for the system, the software that is installed on
that hardware, and the middleware used to connect the disparate machines to one
another.
9. DEVELOPMENT & DESIGN CONSTRAINTS

9.1 Software Language
<Java – The Java programming language is used to develop all the Enterprise Java
Beans (EJB) components. Business logic should be handled in the business layer by the
EJB components.>
<SQL – Structured Query Language (SQL) is used to access relational databases. All of
the interactions with the database system are conducted using SQL.>
<HTML – The presentation layer for the application is built using HTML with JSP tags
that make calls to the EJB components.>
<XML – XML is the standard used to exchange data between systems>.
<JavaScript – Language used to perform client side scripting activities.>
9.2 Architecture and Design

 Presentation Layer – There is a clear separation between the screens that interact
with the user and the components that process all the data and deliver the
information to the screens. The presentation layer is built using HTML with JSP tags.
The web server supports and serves up this content.
 Business Layer – The business logic is captured mainly in the business layer by EJB
components that process the data. The EJB components are developed using Java
and are served up by the WebSphere application server.
 Data layer – Data that is stored in databases is retrieved using JDBC.
 Database – The Oracle relational database system responds to requests for either
storing or retrieving information.
Page 11 of 12
10. ONLINE USER DOCUMENTATION AND HELP SYSTEM

REQUIREMENTS
10.1 Online help
 All screens presented to the user should have a link to the online help system.
 Any terms used on the screens that might need more clarity for the users should be
linked to a definitions page.
 The application will have a telephone number and email link that will let users
communicate with help desk support.
10.2 Customer support center

 The customer support center is open <24/7> to assist users by phone, e-mail, or fax.
 All e-mail messages sent to customer support will receive an automatic response
immediately and response from an individual within 24 hours.
11. LEGAL, COPYRIGHT, AND OTHER NOTICES

[This section describes any necessary legal disclaimers, warranties, copyright notices, patent
notice, word mark, trademark, logo compliance, Freedom of Information Act (FOIA), Privacy
Act, or intelligence marking issues for the software.]
Page 12 of 12

Supplementary Specification Template

Uploaded by

Copyright:

Available Formats

Supplementary Specification Template

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Supplementary Specification Template

Uploaded by

Copyright:

Available Formats

This document was developed for use by programs assigned to the Business and Enterprise Systems Directorate

(AFLCMC/HI), and does not constitute official issuance of DoD or AF policy.

SUPPLEMENTARY SPECIFICATION TEMPLATE

1.2 Definitions, Acronyms and Abbreviations

2.1 <Functional Requirement One>

Uptime => Downtime/year

4.2 Mean Time Between Failures (MTBF)

4.3 Mean Time to Repair (MTTR)

 Objective: <99% of application transactions shall execute within 5 seconds>

5.1.1 Long-running asynchronous tasks

5.2 Page Code Size

The application shall be developed utilizing bandwidth reducing strategies/technologies.

 Threshold: <90% of application transactions shall not exceed 30 Kilobytes>

 Objective: <99% of application transactions shall not exceed 30 Kilobytes>

5.6 Degradation modes (what is the acceptable mode of operation

7.1 <Auditing Requirement One>

8.2 Object-Oriented Analysis:

8.3 Object-Oriented Design:

9. DEVELOPMENT & DESIGN CONSTRAINTS

9.2 Architecture and Design

10. ONLINE USER DOCUMENTATION AND HELP SYSTEM

10.2 Customer support center

11. LEGAL, COPYRIGHT, AND OTHER NOTICES

You might also like