SYSTEM DESIGN DOCUMENT

Overview The System Design Document describes the system requirements, operating environment, system and subsystem architecture, files and database design, input formats, output layouts, humanmachine interfaces, detailed design, processing logic, and external interfaces. 1 1.1 INTRODUCTION Purpose and Scope It describes about the creation of an Industrial Website for the purpose of 1.2 Promotion Marketing Sales Managing Advertising

Project Executive Summary It provides a description of the project from a management perspective and an overview of the framework within which the conceptual system design was prepared. It contain System Overview How Is the Site Layout Made and Why? The site layout is simple and gives Perfect Industrial site Look. What Can You Customize with Industrial website System In Terms Of Design/Layout? Its user friendly and it contains minimum requirements of a corporate site in terms of design and the layout is organized in cells contain rows and columns for effective management. What Is Your Navigation Bar? It provides the functionality for the user to jump into various sections of the site for the content. It briefly includes all the functionality links that a website provides. What Are The Pages Built Into Your System And How Do They Function? There are two kinds of pages static and dynamic were o Static pages A static web page (sometimes called a flat page[1]) is a web page that is delivered to the user exactly as stored, in contrast to dynamic web pages which are generated by a web application.

Consequently a static web page displays the same information for all users, from all contexts, subject to modern capabilities of a web server to negotiate content-type or language of the document where such versions are available and the server is configured to do so. Static web pages are often HTML documents stored as files in the file system and made available by the web server over HTTP. However, loose interpretations of the term could include web pages stored in a database, and could even include pages formatted using a template and served through an application server, as long as the page served is unchanging and presented essentially as stored. Advantages Inherently publicly cacheable (i.e., a cached copy can be shown to anyone). No particular hosting requirements are necessary. Can be viewed directly by a web browser without needing a web server or application server, for example directly from a CD-ROM or USB Drive. Disadvantages Any personalization or interactivity has to run client-side (ie. in the browser), which is restricting. Maintaining large numbers of static pages as files can be impractical without automated tools. Programming skills are required to create it. o Dynamic Pages Dynamic web pages are web sites that are generated at the time of access by a user or change as a result of interaction with the user. Dynamic web pages are a fundamental part of Web 2.0 which facilitates information sharing across multiple websites. Using client-side scripting to change interface behaviors within a specific web page, in response to mouse or keyboard actions or at specified timing events. In this case, the dynamic behavior occurs within the presentation. The Client-side content is generated on the user's local computer system. Such web pages use presentation technology called rich interfaced pages. Client-side scripting languages like JavaScript or ActionScript, used for Dynamic HTML (DHTML) and Flash technologies respectively, are frequently used to orchestrate media types (sound, animations, changing text, etc.) of the presentation. The scripting also allows use of remote scripting, a technique by which the DHTML page requests additional information from a server, using a hidden Frame, XMLHttpRequests, or a Web service. The first "widespread used" version of JavaScript was 1996 (with Netscape 3 an ECMAScript standard). A program running on the web server (server-side scripting) is used to

change the web content on various web pages, or to adjust the sequence of or reload of the web pages. Server responses may be determined by such conditions as data in a posted HTML form, parameters in the URL, the type of browser being used, the passage of time, or a database or server state. Such web pages are often created with the help of server-side languages such as ASP, ColdFusion, Perl, PHP, WebDNA and other languages. These server-side languages often use the Common Gateway Interface (CGI) to produce dynamic web pages. Two notable exceptions are ASP.NET and JSP, which reuse CGI concepts in their APIs but actually dispatch all web requests into a shared virtual machine. Dynamic web pages are often cached when there are few or no changes expected and the page is anticipated to receive considerable amount of web traffic that would create slow load times for the server if it had to generate the pages on the fly for each request. How Does Your Homepage Work? A home page or index page has various related meanings to do with web site: It is also usually the first page that the link/site takes the user to. When the user first opens their web browser, it automatically brings you to this page. It most often refers to the initial or main web page of a web site, sometimes called the "front page" (by analogy with newspapers). The web page or local file that automatically loads when a web browser starts or when the browser's "home" button is pressed; this is also called a "home page". The user can specify the URL of the page to be loaded, or alternatively choose e.g. to re-load the most recent web page browsed. A personal web page, for example at a web hosting service or a university website, that typically is stored in the home directory of the user. In the 1990s the term was also used to refer to a whole web site, particularly a personal web site (perhaps because simple web sites often consisted of just one web page). A home page can also be used outside the context of web sites, such as to refer to the principal screen of a user interface, which is also referred to as a home screen on mobile devices such as cell phones. URL are one way to track down websites like Google and yahoo which are set as "common Homepages". How Does Your Footer Work? Footer contains links to some main sections of the site like home, about us, privacy policy, Terms and conditions.

Functional Requirements Products

It includes addition and deletion of products. Editing if there is any correction. News Events It includes new posts related to company activities. Adding and deleting a post. Slideshow in home page. Careers It includes addition and deletion of posts related to jobs. Contact Information of dealers in various places. It includes addition and deletion of existing and new dealers. Some static pages describing company activities, founders, services it provide.

Non-Functional Requirements 1.3 Usability Reliability Scalability Security

Project References

www.asp.net www.w3schools.com

www.larsentoubro.com

www.hager.co.in www.keltron.org
2 2.1

www.siemens.co.in

SYSTEM ARCHITECTURE It provides an approach to the design and planning of website which, like architecture itself, involves technical, aesthetic and functional criteria. As in traditional architecture, the focus is properly on the user and on user requirements. This requires particular attention to web content, a business plan, usability, interaction design, information architecture and web design. For effective search engine optimization it is necessary to have an appreciation of how a single website relates to the World Wide Web. System Software Architecture ASP.NET is a Web application framework developed and marketed by Microsoft to allow programmers to build dynamic Web sites, Web applications and Web services. It was first released in January 2002 with version 1.0 of the .NET Framework, and is the successor

2.2

to Microsoft's Active Server Pages (ASP) technology. ASP.NET is built on the Common Language Runtime (CLR), allowing programmers to write ASP.NET code using any supported .NET language. The ASP.NET SOAP extension framework allows ASP.NET components to process SOAP messages.

Microsoft SQL Server is a relational database management system developed by Microsoft. As a database, it is a software product whose primary function is to store and retrieve data as requested by other software applications, be it those on the same computer or those running on another computer across a network (including the Internet).

2.3

System Hardware Architecture In this section, describe the overall system software and organization. Include a list of software modules (this could include functions, subroutines, or classes), computer languages, and programming computer-aided software engineering tools (with a brief description of the function of each item). Use structured organization diagrams/object-oriented diagrams that show the various segmentation levels down to the lowest level. All features on the diagrams should have reference numbers and names. Include a narrative that expands on and

enhances the understanding of the functional breakdown. If appropriate, use subsections to address each module. Note: The diagrams should map to the FRD data flow diagrams, providing the physical process and data flow related to the FRD logical process and data flow. 2.4 Internal Communications Architecture In this section, describe the overall communications within the system; for example, LANs, buses, etc. Include the communications architecture(s) being implemented, such as X.25, Token Ring, etc. Provide a diagram depicting the communications path(s) between the system and subsystem modules. If appropriate, use subsections to address each architecture being employed. Note: The diagrams should map to the FRD context diagrams. 3 FILE AND DATABASE DESIGN Interact with the Database Administrator (DBA) when preparing this section. The section should reveal the final design of all database management system (DBMS) files and the nonDBMS files associated with the system under development. Additional information may add as required for the particular project. Provide a comprehensive data dictionary showing data element name, type, length, source, validation rules, maintenance (create, read, update, delete (CRUD) capability), data stores, outputs, aliases, and description. Can be included as an appendix. 3.1 Database Management System Files This section reveals the final design of the DBMS files and includes the following information, as appropriate (refer to the data dictionary): Refined logical model; provide normalized table layouts, entity relationship diagrams, and other logical design information A physical description of the DBMS schemas, sub-schemas, records, sets, tables, storage page sizes, etc. Access methods (such as indexed, via set, sequential, random access, sorted pointer array, etc.) Estimate of the DBMS file size or volume of data within the file, and data pages, including overhead resulting from access methods and free space Definition of the update frequency of the database tables, views, files, areas, records, sets, and data pages; estimate the number of transactions if the database is an online transaction-based system

3.2

Non-Database Management System Files In this section, provide the detailed description of all non-DBMS files and include a narrative description of the usage of each fileincluding if the file is used for input, output, or both; if this file is a temporary file; an indication of which modules read and write the file, etc.; and file structures (refer to the data dictionary). As appropriate, the file structure information should:

Identify record structures, record keys or indexes, and reference data elements within the records Define record length (fixed or maximum variable length) and blocking factors Define file access methodfor example, index sequential, virtual sequential, random access, etc. Estimate the file size or volume of data within the file, including overhead resulting from file access methods Define the update frequency of the file; if the file is part of an online transaction-based system, provide the estimated number of transactions per unit time, and the statistical mean, mode, and distribution of those transactions

HUMAN-MACHINE INTERFACE This section provides the detailed design of the system and subsystem inputs and outputs relative to the user/operator. Any additional information may be added to this section and may be organized according to whatever structure best presents the operator input and output designs. Depending on the particular nature of the project, it may be appropriate to repeat these sections at both the subsystem and design module levels. Additional information may be added to the subsections if the suggested lists are inadequate to describe the project inputs and outputs.

4.1

Inputs This section is a description of the input media used by the operator for providing information to the system; show a mapping to the high-level data flows described in Section 1 .2.1, System Overview. For example, data entry screens, optical character readers, bar scanners, etc. If appropriate, the input record types, file structures, and database structures provided in Section 3, File and Database Design, may be referenced. Include data element definitions, or refer to the data dictionary. Provide the layout of all input data screens or graphical user interfaces (GUTs) (for example, windows). Provide a graphic representation of each interface. Define all data elements associated with each screen or GUI, or reference the data dictionary. This section should contain edit criteria for the data elements, including specific values, range of values, mandatory/optional, alphanumeric values, and length. Also address data entry controls to prevent edit bypassing. Discuss the miscellaneous messages associated with operator inputs, including the following: Copies of form(s) if the input data are keyed or scanned for data entry from printed forms Description of any access restrictions or security considerations Each transaction name, code, and definition, if the system is a transaction-based processing system

4.2

Outputs This section describes of the system output design relative to the user/operator; show a mapping to the high-level data flows described in Section 1.2.1. System outputs include reports, data display screens and GUIs, query results, etc. The output files are described in Section 3 and may be referenced in this section. The following should be provided, if appropriate: Identification of codes and names for reports and data display screens Description of report and screen contents (provide a graphic representation of each layout and define all data elements associated with the layout or reference the data dictionary) Description of the purpose of the output, including identification of the primary users Report distribution requirements, if any (include frequency for periodic reports) Description of any access restrictions or security considerations

DETAILED DESIGN This section provides the information needed for a system development team to actually build and integrate the hardware components, code and integrate the software modules, and interconnect the hardware and software segments into a functional product. Additionally, this section addresses the detailed procedures for combining separate COTS packages into a single system. Every detailed requirement should map back to the FRD, and the mapping should be presented in an update to the RTM and include the RTM as an appendix to this design document.

5.1

Hardware Detailed Design A hardware component is the lowest level of design granularity in the system. Depending on the design requirements, there may be one or more components per system. This section should provide enough detailed information about individual component requirements to correctly build and/or procure all the hardware for the system (or integrate COTS items). If there are many components or if the component documentation is extensive, place it in an appendix or reference a separate document. Add additional diagrams and information, if necessary, to describe each component and its functions, adequately. Industry-standard component specification practices should be followed. For COTS procurements, if a specific vendor has been identified, include appropriate item names. Include the following information in the detailed component designs (as applicable): Power input requirements for each component Signal impedances and logic states Connector specifications (serial/parallel, 11-pin, male/female, etc.) Memory and/or storage space requirements Processor requirements (speed and functionality) Graphical representation depicting the number of hardware items (for example, monitors, printers, servers, I/O devices), and the relative positioning of the components to each other Cable type(s) and length(s)

 5.2

User interfaces (buttons, toggle switches, etc.) Hard drive/floppy drive/CD-ROM requirements Monitor resolution

Software Detailed Design A software module is the lowest level of design granularity in the system. Depending on the software development approach, there may be one or more modules per system. This section should provide enough detailed information about logic and data necessary to completely write source code for all modules in the system (and/or integrate COTS software programs). If there are many modules or if the module documentation is extensive, place it in an appendix or reference a separate document. Add additional diagrams and information, if necessary, to describe each module, its functionality, and its hierarchy. Industry-standard module specification practices should be followed. Include the following information in the detailed module designs: A narrative description of each module, its function(s), the conditions under which it is used (called or scheduled for execution), its overall processing, logic, interfaces to other modules, interfaces to external systems, security requirements, etc.; explain any algorithms used by the module in detail For COTS packages, specify any call routines or bridging programs to integrate the package with the system and/or other COTS packages (for example, Dynamic Link Libraries) Data elements, record structures, and file structures associated with module input and output Graphical representation of the module processing, logic, flow of control, and algorithms, using an accepted diagramming approach (for example, structure charts, action diagrams, flowcharts, etc.) Data entry and data output graphics; define or reference associated data elements; if the project is large and complex or if the detailed module designs will be incorporated into a separate document, then it may be appropriate to repeat the screen information in this section Report layout

5.3

Internal Communications Detailed Design If the system includes more than one component there may be a requirement for internal communications to exchange information, provide commands, or support input/output functions. This section should provide enough detailed information about the communication requirements to correctly build and/or procure the communications components for the system. Include the following information in the detailed designs (as appropriate): The number of servers and clients to be included on each area network Specifications for bus timing requirements and bus control Format(s) for data being exchanged between components

Graphical representation of the connectivity between components, showing the direction of data flow (if applicable), and approximate distances between components; information should provide enough detail to support the procurement of hardware to complete the installation at a given location LAN topology

EXTERNAL INTERFACES External systems are any systems that are not within the scope of the system under development, regardless whether the other systems are managed by the State or another agency. In this section, describe the electronic interface(s) between this system and each of the other systems and/or subsystem(s), emphasizing the point of view of the system being developed.

6.1

Interface Architecture In this section, describe the interface(s) between the system being developed and other systems; for example, batch transfers, queries, etc. Include the interface architecture(s) being implemented, such as wide area networks, gateways, etc. Provide a diagram depicting the communications path(s) between this system and each of the other systems, which should map to the context diagrams in Section 1.2.1. If appropriate, use subsections to address each interface being implemented.

6.2

Interface Detailed Design For each system that provides information exchange with the system under development, there is a requirement for rules governing the interface. This section should provide enough detailed information about the interface requirements to correctly format, transmit, and/or receive data across the interface. Include the following information in the detailed design for each interface (as appropriate): The data format requirements; if there is a need to reformat data before they are transmitted or after incoming data is received, tools and/or methods for the reformat process should be defined Specifications for hand-shaking protocols between the two systems; include the content and format of the information to be included in the hand-shake messages, the timing for exchanging these messages, and the steps to be taken when errors are identified Format(s) for error reports exchanged between the systems; should address the disposition of error reports; for example, retained in a file, sent to a printer, flag/alarm sent to the operator, etc. Graphical representation of the connectivity between systems, showing the direction of data flow Query and response descriptions

If a formal Interface Control Document (ICD) exists for a given interface, the information can be copied, or the ICD can be referenced in this section. 7 SYSTEM INTEGRITY CONTROLS Sensitive systems use information for which the loss, misuse, modification of, or unauthorized

access to that information could affect the conduct of State programs, or the privacy to which individuals are entitled. Developers of sensitive State systems are required to develop specifications for the following minimum levels of control: Internal security to restrict access of critical data items to only those access types required by users Audit procedures to meet control, reporting, and retention period requirements for operational and management reports Application audit trails to dynamically audit retrieval access to designated critical data Standard Tables to be used or requested for validating data fields Verification processes for additions, deletions, or updates of critical data Ability to identify all audit information by user identification, network terminal identification, date, time, and data accessed or changed.