Doc. No.

()
Doc.No:

Date: Signature:
Author:

Reviewers:

Approvers:

QA Approver:

Instructions to the Author:

[Add some instructions here on how to populate the Word fields with the stuff from
Documentum??]
To update the fields in the document click Select All on the Edit menu, and then press
F9.
To update the headers & footers, select print preview (button or File menu)
Check the document and address text printed in red.
Check the correctness of procedures / references / abbreviations
Delete this blue text (and red text in the document) before you save / print the
document.

Page: 1 / 7 File: 26144038.doc

 Doc. No.:

Document history:
(Comments explain the reasons for changing - Please update the revision number in the header of this page
accordingly)

Revision Date Author Comments

Important Note for the Author of this Template:

The level of detail to be captured by this template needs to be defined on a project level. It must be
understood that this template is of a generic structure, and serves as a guideline. The sections that need
to be addressed depend highly on the complexity and size of the appropriate project, i.e. superfluous
sections can be removed as well new sections added.

Page: 2 / 7 File: 26144038.doc

 Doc. No.:

Table of Contents

1 INTRODUCTION...........................................................................................................4
2 DESIGN OVERVIEW.....................................................................................................4
3 APPLICATION /SYSTEM DESIGN SPECIFICATION..........................................................4
3.1 APPLICATION MODEL VIEW...........................................................................................4
3.1.1 Application /System Description..............................................................4
3.1.2 Module Description..................................................................................4
3.1.3 External Interface Design Specifications.................................................5
3.1.4 Optional Application Models....................................................................5
3.2 DATA MODEL VIEW...................................................................................................5
3.2.1 Application / System Data ......................................................................5
3.3 TECHNOLOGY MODEL VIEW..........................................................................................6
3.3.1 Network Components..............................................................................6
3.3.2 System Components................................................................................6
4 DESIGN RELATED TOPICS...........................................................................................6
4.1 APPLICATION DESIGN APPROACHES..................................................................................6
4.2 INTEGRATION STRATEGY..............................................................................................6
4.3 DATA CONVERSION STRATEGY.......................................................................................6
5 REFERENCES / GLOSSARY...........................................................................................7
6 APPENDIX .................................................................................................................7
6.1 TRACEABILITY MATRIX................................................................................................7

Page: 3 / 7 File: 26144038.doc

 Doc. No.:

1 Introduction
Indicate those organization(s) this document represents, and what part it plays in any contracts. The
relationship to other documents should be addressed as well.

2 Design Overview
This section shall briefly describe the design detailed in the rest of the document. It should serve as the
introduction to the design, rather than contain detailed design information. It should show how the system
breaks down into sub-systems i.e. the more detailed levels of design. This may be illustrated by use of a
diagram.

3 Application /System Design Specification

Use these model views to document in-house software development activities as well for customizations1
to Packages. Do not attempt to document the design of existing functionality of Off-the-Shelf Packages
(configuration) - this is the duty and responsibility of the package vendor. You need to ensure that the
vendor is developing to a SDLC and produces the appropriate documentation by executing vendor audits.
The Application / System Specification must unambiguously define how the application / system
implements the specified requirements of the Functional Specification. The code must be traceable to the
requirements.
For complex applications / systems, where different departments of Novartis are responsible for various
elements, it might be necessary to split the document into separate parts.

3.1 Application Model View

Use this section to specify the software design of your application / system. It is possible to support the
design specifications with “snapshots” or printouts of an application design tool such as Designer/2000,
Rational Rose or similar standard Novartis design tools.

3.1.1 Application /System Description

This section shall describe the modules (& sub-systems) that will form the application / system, stating
briefly the purpose of each. A list of interfaces between modules and also any interfaces to external
systems should be given. Each interface shall be uniquely justifiable. A system or application diagram may
be included. Any overall timing or scheduling of the modules may be described.

3.1.2 Module Description

A module is a logically self-contained and discrete part of a larger program. In the OO approach using UML
the module is also often referred as to “package”. For each module the following shall be covered:
• Module operation. The description may make the form of pseudo code.
• Interfaces to other Modules. These may refer to the system diagram, if one is produced.
• Any Module specific timing factors not covered in the system description.
• Error handling and Data validation
• Module data
• Sub-program Description:
For each sub-program in the software module, the following should be covered:

1
Customization: Write / cuts code; Customize the screen layout or program reports( e.g. SAP reports using
ABAP code)
Configuration: Entering / setting parameters; Set of standard screens in SAP
Page: 4 / 7 File: 26144038.doc
 Doc. No.:

- Sub-program operation: The description may make the form of pseudo code.
- Parameters: Each parameter should be identified as one of the following:
• Input parameter
• Output parameter
• Input and output parameter
• In addition each parameter should be identified as:
• Pass by value
• Pass by reference
• Any side-effects of the sub-program
• Sub-Program data
• Language, including version
• Reference to any programming standards

Please refer to section 3.1.4 for more information about possible alternatives for diagramming and
presenting the required details.

3.1.3 External Interface Design Specifications

The Interface Design Specifications can be divided into User, Application- and Hardware Interfaces. The User
Interface (USI), also often referred to as Graphical User Interface (GUI), includes the components following
components: Menu Structure, Window & Report Design. If other types of user system interfaces are
required, such as voice or multimedia, the USI specifications will contain other diagrams appropriate to the
type of interface.
Hardware Interfaces should be described in the Technology Model section.

3.1.4 Optional Application Models

Check out the comments associated with this template about Application Model Views 2to learn more about
possible model views that can be used in this section. Following one example of how the required
information can be presented:

3.2 Data Model View

This section shall outline system data, and define the major data objects. The data should be defined in a
hierarchical manner with complex objects being built up of simpler objects. The objects may include those
defined in the following chapters.
Either use this Data Model View chapter of this document or use a stand-alone document for the data model
view as outlined in the appendix. The stand-alone document may be composed of “snapshots” or printouts
of a data design tool such as Designer/2000, Rational Rose or CaseWise.
Check out the comments associated with this template about Data Model Views to learn more about
possible model views that can be used in this section. See the sub-section below as one example of how
the optional information can be presented.

3.2.1 Application / System Data

This section shall outline application / system data, and define the major data objects. The data should be
defined in a hierarchical manner with complex objects being built up of simpler objects. The objects may
include the following:
• Databases and collections of files
• Files
• Records
• Data types
Each file and data structure shall be uniquely identified. The above guidelines should not preclude the use
of Entity Relationship Models or similar. Please refer to the appendix for more information about
diagramming and presenting the required details.

2
To print out any Word Comments it is necessary to select the options in the “Print” menu and activate the
comments tick-box in the ”Include in Document” section.
Page: 5 / 7 File: 26144038.doc
 Doc. No.:

3.3 Technology Model View

This model view can be used as a stand-alone document including Network and Hardware Specifications in
order to constitute a TI Scenario design document. Check out the comments associated with this template
about Technology Model Views to learn more about possible model views that can be used in this section.
See sub-sections 3.3.1 or 3.3.2 as example of how the optional information can be presented.

3.3.1 Network Components

This section shall describe each component of the network. This may be illustrated by mean of a diagram
with explanatory notes. The following sub-sections shall be included:
• Higher component
This sub-section shall describe the components falling into the Application, Presentation and Session
layers of the network, e.g. Network Operating Software.
• Network components
This sub-section shall describe the components falling into the session and Transport layers of the
network, e.g. cables, clients and servers.
• Physical components
This sub-section shall describe the components falling into the Data Link and Physical layers of the
network

3.3.2 System Components

This section shall describe the overall configuration of the hardware system. This may be illustrated by
means of a block diagram with explanatory notes. The following sub-sections shall be included:
• Main Computer Systems
• Storage
• Interconnections
• Peripherals
• Configuration
• SW
• Input / Output
• Environment
• Electrical Supplies

4 Design Related Topics

The following chapters are recommended but not mandatory. The information provided could be very useful
for any review process (e.g., Design Qualification) or for the project team in order to get a better
understanding of how the design was approached.

4.1 Application Design Approaches

This chapter should describe the design approach that has been taken for an application:
• Error handling standards
• Standardization of program structures
• Etc.

4.2 Integration Strategy

This chapter should address, in general terms, the strategy of how to integrate and achieve seamless
integration of new system with existing systems, e.g. defining integration on entity-by-entity basis.

4.3 Data Conversion Strategy

Page: 6 / 7 File: 26144038.doc

 Doc. No.:

Data Conversion, in general terms, describes how to populate the new database(s). The special case of data
conversion, the “Data Migration”, is bringing the old system data into the new database.

5 References / Glossary
Abbreviation Explanation
FS Functional Specifications (& Conceptual Design)
HW Hardware
OO Object-Oriented
SOW Statement of Work
SSADM Structured System Analysis and Design Methodology
SW Software
UML Unified Modelling Language
URS User Requirements Specification

6 Appendix

6.1 Traceability Matrix

This section should provide traceability to the specifications of the URS. This matrix is a required work
product in GxP governed projects. It is very much recommended to use the traceability also in non-GxP
projects since it provides a good and valuable mean to control the complete translation of specification into
design.

FS-ID Module Function / Feature Name Description

#

Page: 7 / 7 File: 26144038.doc