technical design document - templeate

8/12/2019 Technical Design Document - TEMPLEATE

1/21

Template for IDA Project (Project Id)

Template for specific development (Contract Id)

Technical Design DocumentIssue 1


2/21

Technical Design Document Page iiIDA-MS-TDIssue 1

TABLE OF CONTENTS

0 PREFACE......................................................................................................................1

0.1 Purpose of this document.............................................................................................1

0.2 Use of this document....................................................................................................10.3 Overview........................................................................................................................20.4 !sis of this "ocument.................................................................................................20.# A Reference Architecture for the $"A Pro%r!mme....................................................30.& 'pecific "esi%n Consider!tions...................................................................................3

1 $()RO"UC)$O(........................................................................................................#

1.1 Purpose..........................................................................................................................#1.2 'cope..............................................................................................................................#1.3 "efinitions* Acron+ms !nd A,,revi!tions..................................................................#1.4 References......................................................................................................................&1.# Overview........................................................................................................................&

2 '-')E O/ER/$E................................................................................................

2.1 '+stem Ch!r!cteristics.................................................................................................2.2 '+stem Architecture......................................................................................................2.3 $nfr!structure 'ervices.................................................................................................

3 '-')E CO()E).................................................................................................10

4 '-')E "E'$(.....................................................................................................11

4.1 "esi%n ethod !nd 't!nd!rds..................................................................................11

4.2 "ocument!tion 't!nd!rds.........................................................................................124.3 (!min% conventions...................................................................................................134.4 Pro%r!mmin% 't!nd!rds............................................................................................134.# 'oftw!re deve5opment too5s.......................................................................................134.& Outst!ndin% $ssues.....................................................................................................144. "ecomposition "escription........................................................................................14

# COPO(E() "E'CR$P)$O(...............................................................................1#

#.1 Component $dentifier.................................................................................................1&

& 'OF)ARE RE6U$REE()' )RACEA$7$)- A)R$.............................1

"OCUE() CO()RO7.....................................................................................................20

"OCUE() '$(OFF........................................................................................................20

"OCUE() C8A(E RECOR".....................................................................................20


3/21

Technical Design Document Page 1IDA-MS-TDIssue 1

0 PREFACE

0.1 PURPOSE OF THIS DOCUMENT

#1 This document is a generic Technical Design Document document for use by IDA

Projects. It provides guidance and template material which is intended to assist therelevant management or technical staff whether client or supplier in producing a

project!specific Technical Design Document document. It is also useful bac"groundreading for anyone involved in developing or monitoring the IDA anagement$ystem %IDA!$&.

0.2 USE OF THIS DOCUMENT

#1 This Preface is addressed to the users of this generic document and is not meant to beretained in any project!specific Technical Design Document documents based on it.

#' The remaining sections %numbered 1 ' ()& constitute a template that should beused to construct the project!specific Technical Design Document document.

Te*t in normal case is in the most part +boilerplate, that can be retainedamended or deleted in the document.

Te*t in italicsprovides instructions on how to complete a section and should beremoved once the section is written.

#( The template should be used pragmatically that is ! where a section is not relevant itshould be omitted. -onversely the material contained in this document is notnecessarily e*haustive if there is a subject that is relevant to the IDA Project but isnot included in this document it should still be included.

#/ This document has been prepared using $ 0ord 2. The following variables arecurrently recorded as 3ile +Properties, under $ 0ord. They may be modified bythat means or overwritten directly at each occurrence in the document at thediscretion of the user.

a. Summary Properties

Title Type of document i.e. Technical Design Document!

Author Authors! of document

"ey#ords Document reference i.e. IDA-MS-TD!

$. %ustom Properties

Pro& Id Short mnemonic of IDA Pro&ect set' in this document'to Pro&ect Id!

Pro&ect (ull name of IDA Pro&ect set' in this document' toTemplate for IDA Pro&ect!

%ontr Id Short identifier of contract set' in this document' to%ontract Id!

%ontract (ull name of contract set' in this document' toTemplate for specific de)elopment!

*ersion Issue num$er currently Issue 1!

Date Date of document currently 1+ ,anuary 1!


4/21

Technical Design Document Page IDA-MS-TDIssue 1

0.3 OVERVIEW

#1 This preface is for information only.

#' This preface will therefore not be retained in the project!specific document.

#( The remaining sections %numbered 1 ' ()& constitute a template that should beused to construct the project!specific document.

Te*t in normal case is in the most part +boilerplate, that can be retainedamended or deleted in the document.

Te*t in italicsprovides instructions on how to complete a section and should beremoved once the section is written.

Te*t in$lue italicsincludes discussion and specific recommendations on theapproach to Technical Design in the IDA conte*t.

#/ The template should be used pragmatically that is ! where a section is not relevant it

should be omitted. -onversely the material contained in this document is notnecessarily e*haustive if there is a subject that is relevant to the project but is notincluded in this document it should still be included.

0.4 BASIS OF THIS DOCUMENT

#1 This following introductory sections set out an approach to designing systems thatmay be developed under IDA. It attempts to set standards and create a consistentapproach to the design and development of systems across the IDA Programme. Itwill enable the Programme to benefit from 4economies of scale5 and a consistency inthe approach to building and deploying systems. Important issues that need to be

considered include the architecture of systems lin"s to legacy systems contemporaryapproaches to design %6bject 6riented Design& aims for code re!use and the need todevelop systems that will wor" on an operational basis over many years and theassociated desire to ma"e such systems easily supportable and affordable.

#' A "ey point will be to build on the wor" already carried out in IDA and itspredecessor programmes where a large number of specific 4technical5 developmentswere underta"en loo"ing at for e*ample standards for data e*change such as78$8$ and the introduction of contemporary technologies and infrastructures.

#( The concept of aReference Architectureis also introduced as part of the process ofcreating an interoperable environment which facilitates the e*change of information

between administrations through setting out a number of standard building bloc"saround which solutions can be assembled. These building bloc"s or 4componentsreflect the emerging technologies that should form the technical basis of the IDAdevelopments. These include the -ommon 6bject 9e:uest ;ro"er Architecture%-69;A& 9emote ethod Invocation %9I& and 8nterprise


5/21

Technical Design Document Page /IDA-MS-TDIssue 1

selected to build elements of the overall IDA Programme to propose their ownsolutions or the solutions proposed by their selected suppliers thereby e*acerbatingthe e*isting heterogeneous environment which is in direct conflict with the aim ofcreating an interoperable architecture.

#' In practice the IDA Programme should see" to create what can be referred to as aReference Architecturefor systems > in effect a series of established building bloc"son which a variety of systems should be assembled. The 9eference Architecture

should then become part of the IDA Architecture 0uidelines1.

#( The 9eference Architecture would ta"e an n!tier client!server model as its basis andstate that the persistence layer would be implemented through a number of standardAPI'calls to a particular database system. This use of a 9eference Architecture wouldprovide some guidelines to organisations tas"ed with developing individual elementsof the IDA Programme and would in time move solutions towards a commonhomogeneous standard > with all of its associated benefits.

#/ 9ecommendations could be made on the reporting tool that should be used in systemsif one were re:uired the 0eb ;rowser could be standardised as could any security

features that needed to be built into the system. The 9eference Architecture wouldfacilitate re!use throughout the IDA Programme as individual projects could bearranged to support the development of libraries of components that can be re!used.This will be one of the major potential benefits that could arise from the creation of a

9eference Architecture.

0.6 SPECIFIC DESIGN CONSIDERATIONS

#1 Perhaps one of the most crucial aspects of this is the level of concurrency that will be

present in typical IDA projects. Thus far projects falling within the IDA Programmehave tended generally not to involve large scale transaction!based computing. Thetransmission of information from an $A to the 8uropean =nion containinginformation on > for e*ample > employment statistics has focused on the need tocreate common approaches to the formatting of the data and to handling languageissues. It is possible that future projects will involve more fre:uent updates from

participating administrations. In this case attention in the 9eference Architecture tothe loading on computer systems will be necessary.

#' 66D will also become increasingly used in the IDA Programme as developments see"to create systems that are more maintainable over their deployment lifetime. The"noc" on effect of this will be an increasing emphasis on the use of -ommercial 6ffThe $helf %-6T$& pac"ages in the software architecture in areas such as thedatabase middleware reporting tools and in the 7raphical =ser Interface.

#( IDA projects may well shift from a traditional waterfall development approach to thedesign and development of solutions towards 9apid Applications Development%9AD&. This will have fundamental implications for the design process. IDA project

1The IDA Architecture 0uidelines #ere de)eloped in 1 in co-operation #ith the TA0 Telematics forAdministrations 0roup! Su$group on 2ori3ontal and 4egal Issues' a group of e5perts from 67 Mem$er Statesand 66A states. They descri$e concepts and references for a #ell-defined' common architecture that supportsnet#or8 interopera$ility #ithin and across different administrations. Article 9 of the IDA Interopera$ilityDecision :o. 1+;1;6%! defines the re


6/21


leaders will need to consider the creation of


7/21


8/21

Technical Design Document Page ?IDA-MS-TDIssue 1

Activity Diagram Describes activities and actions ta"ing place in a system

$e:uence Diagram $hows one or several se:uences of messages sent among a set ofobjects

-ollaboration Diagram Describes a complete collaboration among a set of objects

=se!case Diagrams Illustrates the relationships between use cases

-omponent Diagram A special case of a -lass Diagram used to describe components withina software system

Deployment Diagram A special case of a -lass Diagram used to describe hardware withinthe overall system architecture

$ystem ;loc" diagram A diagram showing the major components of the system with itsinterconnections and e*ternal interfaces

1.4 REFERENCES

#1 This section should list all the applicable and reference documents identified by titleauthor and date. 8ach document should be mar"ed as applicable or reference. Ifappropriate report number journal name and publishing organisation should be

included.

#' The IDA Architecture 0uidelines%incorporating if developed the IDA 9eferenceArchitecture& which should provide the starting point for the system architectureshould be referenced. The elements of the recommended architecture which are usedshould be described.

#( There should also be a reference to the document which states how changes to thisdocument are controlled. It is recommended that one of the references highlight the

system development model that is to be followed in developing the system such as0aterfall H model or 9AD. This may reference an internal document or an industry

standard wor" on software development approaches. If an 6bject 6riented Design

%66D& approach is to be followed a reference to the guidelines to be adopted ondeveloping the design should be provided.

:um. Title Applica$ility @ eference! Author Date Issue

1.5 OVERVIEW

;1 Section 1 is the introduction and includes a description of the pro&ect' applica$le andreference documents.

; Section pro)ides a system o)er)ie#.

;/ Section / contains the system conte5t.

;9 Section 9 descri$es the system design method' standards and con)entions.

;= Section = contains the component descriptions.

;? Section ? includes the e


9/21

Technical Design Document Page +IDA-MS-TDIssue 1

2 SYSTEM OVERVIEW

#1 This section should briefly introduce the system conte*t and design and discuss the

bac"ground to the project. This section may also summarise the costs and benefits ofthe selected architecture and may refer to feasibility studies and prototypinge*ercises. This section should also describe how the design proposed aligns with theIDA Architecture 0uidelines(and ma"es use of the outputs of IDA Boriontal Actionsand easures %BAs&.

2.1 SYSTEM CHARACTERISTICS

#' The description of the system should be given in terms of the Architecture of thesolution that is being implemented with high level data flows described to set theconte*t of the system i.e. to loo" at its e*ternal interfaces. This section should also

set out to 4characterise5 the system describing aspects of its operation that indicate ifthe system has inter aliaG

to operate in real!time or in bursts lin"ed to month!end reporting for e*ample

the nature of the interface to the users of the system

a large number of concurrent users

to be highly resilient or fault tolerant

to provide security features to protect data

to be scaleable and easily maintainable in the future

to have any special bac"!up facilities to protect important data.

2.2 SYSTEM ARCHITECTURE

#1 This section should describe the Architecture of the system based where feasible onthe IDA Architecture 0uidelines.

#' The system under consideration will perhaps be based upon an n!tier client!serverarchitecture. It is possible that the architecture will have secure managed interfacesor pro*ies to isolate systems from illegal access. The Architecture may be a simpleclient!server system in which web technologies are used to provide forms from a

simple server that can be filled in remotely by someone for e*ample at a border post.0ith a simple re:uirement to collect basic information which can be entered as it iscaptured by the user this two!tier architecture may well be :uite sufficient.

#( The access layer %client& may have to cater for a range of terminals that mayeventually need to access information. It is not impossible to foresee the day when0AP access to information may be re:uired to allow the citiens of 8urope directaccess to certain pieces of information stored within the overall data systemsoperated by the 8uropean =nion. 0ith enlargement IDA systems may have to handlea wide range of so!called 4client5 systems ranging from simple database applications%Access& to information being collected from large!scale mainframe applications.

/:ote that the design M7ST not contradict the IDA Architecture 0uidelines


10/21

Technical Design Document Page BIDA-MS-TDIssue 1

#/ 7iven this li"ely wide range of means of access the current emphasis in client!serverarchitectures of brea"ing down the architecture into several layers will be factors thatwill have to be addressed in the course of defining solutions that can be rolled outacross the increased 8uropean =nion. The architecture proposed is a tried approachthat when implemented across the 8uropean =nion will provide the fle*ibility to

support ever!changing business %often legislatively driven& re:uirements. Its "eyfeature is that it separates out business logic client access technology and centrallyheld data into discrete layers with standard open interfaces. Today n!tierarchitectures can often be divided into several tiers as followsG

a. client or 4access5 tier > which facilitates access by both e*ternal and internalclients through technologies such as web browsers

b. presentation tier > the layer that accesses information from the other systems asre:uired and can contain its own 4business rules5 for simple processes

c. business tier > contains the business information layer

d. persistence tier > the database layer which provides the facilities to store data.

# Depending upon the solution proposed for the system in :uestion there may be abalance of functions placed into each of these layers. 0e believe that in the design

process it is vital however to have a layered architecture as the basis of the solutionto facilitate change and adaptation of the system in the future > in other words to

protect the investment that has been made in the system as technologies develop inthe future. The degree of isolation afforded to elements of the system throughadopting a layered approach is significant and can help immunise the project fromhaving to be replaced in full in years to come > some "ey elements will survivetechnological developments.

#E 8nlargement both in the medium and long term could be a crucial factor in thedesign of IDA systems. $calability of the architecture could become an issue. 0ith alayered approach the ability to scale to meet future re:uirements is relatively easy asadditional server power can be deployed into the various layers of the system. It maybe for e*ample that with enlargement solutions are devised with 4regional nodes5which connect administrations not directly into a central server but into a 9egional-entre of e*pertise in a subject area.

#2 $uch ideas are already common place in current -ommunity systems such as thoseconnected with 8I6C8T. Bere regionally based centres of e*cellence in the

processing of environmental data collect and process information prior to it being

forwarded into the 8uropean 8nvironmental Agency %88A&.

#J This illustrates a "ey point in the design of the architecture of the systems. Dependingupon where the data is going to be processed and analysed different physical layoutsof servers may be re:uired to provide the levels of service re:uired by the users of the

system. It may be that there are local nodes that collect information in eachadministration and it is then routed to a specialist node and from there onto acentral repository which contains the master files where regional factors areconsidered in order to help establish policy in an effective way.


11/21

Technical Design Document Page IDA-MS-TDIssue 1

2.3 INFRASTRUCTURE SERVICES

#1 Infrastructure $ervices should be provided to all applications with a view to reducingthe time cost and ris"s of development through re!use. To gain full advantage of

infrastructure services the re:uirements of all current applications and theanticipated re:uirements from future applications should be analysed. These shouldbe fed into the design of the services. The Infrastructure $ervices can be builtincrementally implementing the most common re:uirements first followed by more

specialised services. Topics covered in this section might includeG

a. $ecurity

b. Audit

c. Performance monitoring and reporting

d. 8rror Bandling

e. Debugging f. ?ogging.


12/21


3 SYSTEM CONTET

#1 This section should define all the e*ternal interfaces. This discussion should be

based on a system bloc" diagram or conte*t diagram to illustrate the relationshipbetween this system and other systems. The e*ternal interfaces should be defined interms ofG

a. types of data and information flowing over the interfaces

b. the form that data flow ta"es e.g. a defined message format such as 78$8$

c. the physical medium of the interface for e*ample a K.' lin" T-PLIP lin" afloppy dis" data entered by an operator etc.

d. rates of information flow covering the fre:uency of information being updatedthe volume of information sent in a message bloc" how often the information is

updated

/

e. what can happen if the interface fails for some reason such as the loss of acommunications lin".

#' It is suggested that the reader give some serious thought to the use of the emergingK? standards to define e*ternal data flows into and out from the candidate system.The freedom K? offers in defining labels for data enable the user of the technologyto create what is in effect their own data description language for the data that isencapsulated by the K? constructs. Bowever care should be ta"en to

a. adhere to standards %de jure or de facto& where they e*ist

b. ma"e use of the IDA 9eference Architecture and the output of IDA BAs whererelevant.

9In typical IDA pro&ects the e5ternal interfaces are communications lin8s that ena$le MSAs to transmitinformation into a central facility or to other MSAs. It is the case that information flo#s can $e infre


13/21


4 SYSTEM DESIGN

#1 This and the following section should provide sufficient information for a developer

to produce the system. The detailed content will depend upon the approach to thedesign process that is to be used.

#' According to one source there are over (M different object design methodologies andnotations of which =? is perhaps the best "nown.

#( If the project is to follow the traditional waterfall approach its documentation willdiffer from a development approach based on 9AD or D$D. oreover an 66Dbased philosophy for the design using =? would be different from one based onanother design methodology such as $$AD or ourdon. Depending upon theapproach to be ta"en the software may be produced using coding statements or it maybe automatically generated by an application development tool or a mi*ture of both.

#/ 3or the e*ample presented in the rest of this section we will assume that new IDAprojects move towards the use of =? and 66D based methodologies. 6ne goal of66D is to create a collection of reusable software objects that can be reused acrossother IDA projects in effect offering some significant savings in development costs.0ith the proposal to create a IDA 9eference Architecture a central library of objectscould be reused across projects that have similar aims and objectives 4to collectinformation5 but whose application areas %health tourism employment environment-ustoms etc& vary.

4.1 DESIGN METHOD AND STANDARDS

#1 The design method used should be named and referenced. A brief description may beadded to aid readers not familiar with the method. Any deviations and e*tensions ofthe method should be e*plained and justified.

#' In this paper we give an e*ample of how client!server technologies can be developedon the basis of a given design paradigm that enables web technologies to be appliedto IDA projects offering ease of maintenance and savings in life cycle costs.

#( The design standard might need to be different if more than one method orprogramming language is involvedG for e*ample if some


14/21


generalised description of a group of objects that have the same data item%s& andmethod organisation.

#2 In designing objects there are four important 4cardinal points5 to be remembered.These areG

a. attributes > what the object "nows

b. methods > what the object does

c. states > the changes that occur due to process flow

d. events > responses to the outside world.

#J 6bject definitions should be annotated with these items. This will provide thebeginnings of a detailed specification document. In addition each object should be

put into a =? diagram set as this helps summarise the information into small tightrepresentations of each object in a standard format > there are nine =? diagramsas referenced in $ection 1.(. In the course of the process the diagrams will betransformed into a class diagram that represents the relationship between the objects

> in effect a blueprint for the structure of the business objects.

# 6ne area where careful attention to design can reap rewards in the longer term is inthe interface between the client and the so!called presentation layer. 3rom its earliestinception in projects using the $malltal" language the odel Hiew -ontroller %H-&

paradigm has been one of the most implemented solutions in client!server computing.In implementations based on web technologies such as


15/21

Technical Design Document Page 1/IDA-MS-TDIssue 1

4.3 NAMING CONVENTIONS

#1 This section should e*plain all naming conventions used and draw attention to anypoints a maintenance programmer would not e*pect. A table of the filetypes and the

permitted names or e*tensions for each is recommended for :uic" reference.#' -onventions for naming files,programs modules and possibly other structures such

as variables and messages should all be documented here.

4.4 PROGRAMMING STANDARDS

#1 This section should define the project programming standards. 0hatever languagesor standards are chosen the aim should be to create a convenient and easily usablemethod for writing good!:uality software. If an application development tool is usedthere may be other conventions that need to be defined e.g. colour schemes.

#' 0hen programming in any new language a standard for its use should be written toprovide guidance for programmers. This standard may be referenced or includedhere.

#( 0here there are e*ternal interfaces the programming standards for the interfacesre:uired should be referenced.

#/ In general the programming standard should define a consistent and uniformprogramming style. $pecific points to cover areG

a. modularity and structuring

b. headers and commenting

c. indenting and layout

d. library routines to be used

e. language constructs to use

f. language constructs to avoid.

4.5 SOFTWARE DEVELOPMENT TOOLS

#1 This section should list the tools chosen to assist software development includingtesting. The actual software chosen will be heavily dependent upon the language in

which the system will be implemented.

#' The list may includeG

a. an application development too

b. a configuration manager L builder

c. BT? authoring tools

d. a word processor for documentation

e. a tool for drawing diagrams

f. automated testing tools.


16/21


#( Prototyping projects might ma"e use of an interpretative tool such as an incrementalcompilerLinterpreterLdebugger.

#/ 8*ternal interfaces may re:uire some of the modules to be pre!compiled.

4.6 OUTSTANDING ISSUES

#1 Provide details of any design issues that remain unresolved at the date of issue of thisdocument. 8*plain options pros and cons and give an estimate of which option ismost li"ely. 6utline impact of each option on the rest of the design.

4.! DECOMPOSITION DESCRIPTION

#1 The software components should be summarised. This should be presented asstructure charts or object diagrams showing the hierarchy control flow and data flowbetween the components.

#' If the =? paradigm is used then the decomposition description should ma"ee*tensive use of the nine 4=? Diagrams5 that in effect define the operation of the

system.


17/21

Technical Design Document Page 1=IDA-MS-TDIssue 1

5 COMPONENT DESCRIPTION

#1 3or a software implementation this and the previous section should provide sufficient

information for a programmer to produce the software and for a maintainer whomay not be the developer to ma"e subse:uent changes. The detailed content willdepend upon the software tool to be used. The software may be produced usingcoding statements written by an application programmer. In contrast it may beautomatically generated by an application development tool or indeed a mi*ture ofboth.

#' It is worth reflecting for a moment on the term 4component5 and giving somedefinition as to what a 4component5 might entail. The following definitions are offeredto the readerG

-lient!;ased -omponents > =ser!centric graphical interface classes and widgets

%e.g. 7eneral!purpose language libraries or bindingsthat aid in the implementation of a design in a particular language %e.g. 9eusable architectural and configuration concepts

that are documented and ready for reapplication %e.g. publishLsubscribe $tore N3orward Push& implemented through automated tools li"e =? modelling tools.

#( -omponent!based design offers a great economy of effort by encapsulatingfunctionality at the right level. Application components offer re!use and can easily beenhanced. 9e!useable components capture the repeated functionality of common

system behaviour %such as infrastructure services&.

#/ The descriptions of the components should be laid out hierarchically. There shouldbe subsections dealing with the following aspects of each componentG

.n -omponent identifier

.n.1 Type

.n.' Purpose

.n.( 3unction

.n./ $ubordinates

.n. Dependencies

.n.E Interfaces

.n.2 9esources

.n.J 9eferences


18/21

Technical Design Document Page 1?IDA-MS-TDIssue 1

.n. Processing

.n.1M Data

# The number OnO should relate to the place of the component in the hierarchy.

5.1 COMPONENT IDENTIFIER

#1 8ach component should have a uni:ue identifier. The identifiers to be used forcomponents should be defined by the project and described elsewhere.

5.1.1 T"#$

#1 This section should describe the type of component e.g. tas" subroutinesubprogram pac"age file.

#' The contents of some component description sections depend on the component type.

3or the purpose of this template the categoriesG e*ecutable i.e. contains computerinstructions or non!e*ecutable i.e. contains only data are used.

5.1.2 P%'($

#1 The purpose of a component should be defined by tracing it to the softwarere:uirements that it implements.

#' ;ac"wards traceability depends upon each component description e*plicitlyreferencing the re:uirements that justify its e*istence.

5.1.3 F%)*+')

#1 The function of a component must be defined in this document. This should a shortdescription of what the component does and will depend upon the component typee.g. it may be a description of the process or of the data to be stored or transmitted.

#' ore detail will be provided in Processing %see below&.

5.1.4 S%-'&)/+$(

#1 This section should list the modules that are 4called by5 this component. Thesubordinates of a database could be the files that 4compose5 it. The subordinates ofan object are the objects that are 4used by5 it.

5.1.5 D$#$)$)*$(

#1 The dependencies of a component should be defined by listing the constraints placedupon its use by other components. 3or e*ampleG

what operations have to have ta"en place before this component is called

what operations are e*cluded when this operation is ta"ing place

what components have to be e*ecuted after this one

5.1.6 I)+$&/*$(

#1 ;oth control flow and data flow aspects of an interface need to be specified. Dataaspects of Onon!e*ecutableO components should be defined in $ubsection .n.1M.


19/21

Technical Design Document Page 1+IDA-MS-TDIssue 1

#' The control flow to and from a component should be defined in terms of how thiscomponent is to be e*ecuted e.g. subroutine call and how it is to be terminated e.g.return. This may be implicit in the definition of the type of component and adescription may not be necessary. -ontrol flows may also ta"e place duringe*ecution e.g. interrupt and these should be defined if they e*ist.

#( The data flow input to and output from the component must be detailed. Datastructures should be identified thatG

a. are associated with the control flow e.g. call argument list

b. interface components through common data areas and files.

#/ If a component interfaces to components in the same system then the interfacedescription should be defined. If a component interfaces to components in other

systems the interface description should be defined in an interface document.

5.1.! R$('%&*$(#1 The resources a component re:uires should be defined by itemising what the

component needs from its environment to perform its function. Items that are part ofthe component interface are e*cluded. 8*amples of resources that might be neededby a component are displays printers and buffers.

5.1. R$$&$)*$(

#1 8*plicit references should be inserted where a component description uses or impliesmaterial from another document.

5.1. P&'*$(()#1 The processing should be defined by summarising the control and data flow within it.

3or some "inds of component e.g. files there is no such flow. Techni:ues of processspecification include Program Design ?anguage Pseudo -ode and 3low -harts.

#' Any specific algorithms to be used should be stated or referenced.

5.1.10 D/+/

#1 The data internal to a component should be defined. The amount of detail re:uireddepends strongly on the type of component. The logical and physical data structure

of files that interface major components should be defined in detail.#' Data structure definitions must include theG

a. description of each element e.g. name type dimension

b. relationships between the elements i.e. the structure

c. range of possible values of each element

d. initial values of each element.


20/21

Technical Design Document Page 1BIDA-MS-TDIssue 1

6 SOFTWARE REUIREMENTS TRACEABILITY MATRI

#1 This section should contain a table that summarises how each software re:uirement

has been met in this document. The tabular format permits one!to!one and one!to!many relationships to be shown.

System Req.Number

System Ref. Item ComponentIdentifier

Component Item


21/21


DOCUMENT CONTROL

)it5e9 Technical Design Document

$ssue9 Issue 1

"!te9 1+ ,anuary 1

Author9 Dr Da)e Sloggett

"istri,ution9 6% D0 6nterprise C 0a)ino MurgiaPro&ect Team

Reference9 IDA-MS-TD

Fi5en!me9 /9/19B.doc

Contro59 eissue as complete document only

DOCUMENT SIGNOFF(!ture of 'i%noff Person 'i%n!ture "!te Ro5e

Authors Dr Da)e Sloggett Pro&ect Mem$er

e)ie#ers Mar8 Pillatt %onsultant

DOCUMENT CHANGE RECORD

"!te /ersion Author Ch!n%e "et!i5s

,anuary 1 Issue 1 Draft Da)e Sloggett (irst complete draft

B ,anuary 1 Issue 1 Draft / Mar8 Pillatt e)ie# and update

1 ,anuary 1 Issue 1 Draft 9 Sue Turner 7pdating format

1+ ,anuary 1 Issue 1 Mar8 Pillatt Apply re)ie# comment and

issue

technical design document - templeate

Documents