软件设计文档模板(英文)

合集下载

SDD_Template(软件设计文档英文版)

SDD_Template(软件设计文档英文版)

Software Design Document (SDD) TemplateSoftware design is a process by which the software requirements are translated into a representation of software components, interfaces, and data necessary for the implementation phase. The SDD shows how the software system will be structured to satisfy the requirements. It is the primary reference for code development and, therefore, it must contain all the information required by a programmer to write code. The SDD is performed in two stages. The first is a preliminary design in which the overall system architecture and data architecture is defined. In the second stage, i.e. the detailed design stage, more detailed data structures are defined and algorithms are developed for the defined architecture. This template is an annotated outline for a software design document adapted from the IEEE Recommended Practice for Software Design Descriptions. The IEEE Recommended Practice for Software Design Descriptions have been reduced in order to simplify this assignment while still retaining the main components and providing a general idea of a project definition report. For your own information, please refer to IEEE Std 1016­1998 1 for the full IEEE Recommended Practice for Software Design Descriptions.1 http://www.cs.concordia.ca/~ormandj/comp354/2003/Project/ieee­SDD.pdf(Team Name)(Project Title)Software Design Document Name (s):Lab Section: Workstation:Date: (mm/dd/yyyy)T ABLE OF C ONTENTS1. I NTRODUCTION 2 1.1 Purpose 2 1.2 Scope 2 1.3 Overview 2 1.4 Reference Material 21.5 Definitions and Acronyms 22. S YSTEM O VERVIEW 23. S YSTEM A RCHITECTURE 2 3.1 Architectural Design 2 3.2 Decomposition Description 33.3 Design Rationale 34. D ATA D ESIGN 3 4.1 Data Description 34.2 Data Dictionary 35. C OMPONENT D ESIGN 36. H UMAN I NTERFACE D ESIGN 4 6.1 Overview of User Interface 4 6.2 Screen Images 46.3 Screen Objects and Actions 47. R EQUIREMENTS M ATRIX 48. A PPENDICES 41. I NTRODUCTION1.1 PurposeIdentify the purpose of this SDD and its intended audience. (e.g. “This software design document describes the architecture and system design of XX. ….”).1.2 ScopeProvide a description and scope of the software and explain the goals, objectives and benefits of your project. This will provide the basis for the brief description of your product.1.3 OverviewProvide an overview of this document and its organization.1.4 Reference MaterialThis section is optional.List any documents, if any, which were used as sources of information for the test plan.1.5 Definitions and AcronymsThis section is optional.Provide definitions of all terms, acronyms, and abbreviations that might exist to properly interpret the SDD. These definitions should be items used in the SDD that are most likely not known to the audience.2. S YSTEM O VERVIEWGive a general description of the functionality, context and design of your project. Provide any background information if necessary.3. S YSTEM A RCHITECTURE3.1 Architectural DesignDevelop a modular program structure and explain the relationships between the modules to achieve the complete functionality of the system. This is a high level overview of howresponsibilities of the system were partitioned and then assigned to subsystems. Identify each high level subsystem and the roles or responsibilities assigned to it. Describe how these subsystems collaborate with each other in order to achieve the desired functionality. Don’t go into too much detail about the individual subsystems. The main purpose is to gain a general understanding of how and why the system was decomposed, and how the individual parts work together. Provide a diagram showing the major subsystems and data repositories and their interconnections. Describe the diagram if required.3.2 Decomposition DescriptionProvide a decomposition of the subsystems in the architectural design. Supplement with text as needed. You may choose to give a functional description or an object­oriented description.For a functional description, put top­level data flow diagram (DFD) and structural decomposition diagrams. For an OO description, put subsystem model, object diagrams, generalization hierarchy diagram(s) (if any), aggregation hierarchy diagram(s) (if any), interface specifications, and sequence diagrams here.3.3 Design RationaleDiscuss the rationale for selecting the architecture described in 3.1 including critical issues and trade/offs that were considered. You may discuss other architectures that were considered, provided that you explain why you didn’t choose them.4. D ATA D ESIGN4.1 Data DescriptionExplain how the information domain of your system is transformed into data structures.Describe how the major data or system entities are stored, processed and organized. List any databases or data storage items.4.2 Data DictionaryAlphabetically list the system entities or major data along with their types and descriptions. If you provided a functional description in Section 3.2, list all the functions and function parameters. If you provided an OO description, list the objects and its attributes, methods and method parameters.5. C OMPONENT D ESIGNIn this section, we take a closer look at what each component does in a more systematic way. Ifyou gave a functional description in section 3.2, provide a summary of your algorithm for each function listed in 3.2 in procedural description language (PDL) or pseudocode. If you gave an OO description, summarize each object member function for all the objects listed in 3.2 in PDL or pseudocode. Describe any local data when necessary.6. H UMAN I NTERFACE D ESIGN6.1 Overview of User InterfaceDescribe the functionality of the system from the user’s perspective. Explain how the user will be able to use your system to complete all the expected features and the feedback information that will be displayed for the user.6.2 Screen ImagesDisplay screenshots showing the interface from the user’s perspective. These can be hand­ drawn or you can use an automated drawing tool. Just make them as accurate as possible.(Graph paper works well.)6.3 Screen Objects and ActionsA discussion of screen objects and actions associated with those objects.7. R EQUIREMENTS M ATRIXProvide a cross­reference that traces components and data structures to the requirements in your SRS document.Use a tabular format to show which system components satisfy each of the functional requirements from the SRS. Refer to the functional requirements by the numbers/codes that you gave them in the SRS.8. A PPENDICESThis section is optional.Appendices may be included, either directly or by reference, to provide supporting details that could aid in the understanding of the Software Design Document.。

软件开发计划模板 英语

软件开发计划模板 英语

软件开发计划模板英语Software Development Plan.Introduction.A software development plan is a roadmap that outlines the steps required to successfully develop and deliver a software product. It serves as a guide for the project team, providing clarity on roles, responsibilities, timelines,and deliverables. By following a comprehensive plan, teams can increase efficiency, reduce risks, and ensure project success.Steps in Software Development Plan.1. Requirements Gathering.Define the problem or opportunity that the softwarewill address.Conduct user interviews, surveys, and workshops to gather requirements.Document the requirements in a clear and concise manner.2. Design.Create a high-level design that outlines the overall architecture of the software.Develop detailed designs for each component of the software.Conduct design reviews to ensure the design meets the requirements.3. Development.Implement the software according to the design specifications.Use appropriate coding standards and best practices.Perform unit testing to ensure the individual components of the software are functioning correctly.4. Testing.Conduct integration testing to ensure the different components of the software work together seamlessly.Perform system testing to ensure the software meets the overall requirements.Conduct acceptance testing to ensure the software meets the needs of the users.5. Deployment.Plan and execute the deployment of the software to the production environment.Ensure the software is deployed smoothly and withminimal downtime.6. Maintenance.Provide ongoing support and maintenance for the software.Fix bugs and address performance issues as needed.Implement new features and enhancements based on user feedback.7. Monitoring.Monitor the performance of the software and identify any potential issues.Collect metrics and data to track key performance indicators (KPIs).Use monitoring tools to ensure the software is running smoothly and efficiently.Conclusion.Following a structured software development plan is crucial for the success of any software project. By clearly defining the steps, roles, and deliverables, teams can ensure that the software is developed and delivered in a timely and efficient manner. The plan provides a roadmapthat guides the project through each phase, from requirements gathering to maintenance, ensuring that all aspects of the project are addressed and that the final product meets the desired objectives.中文回答:软件开发计划。

软件设计说明书英文五百字

软件设计说明书英文五百字

软件设计说明书英文五百字Software Design Specification1. IntroductionThis document serves as a specification for the design of the software system. It outlines the functional and non-functional requirements of the software and describes the overall design structure.2. ObjectivesThe main objective of the software is to provide a user-friendly interface for managing and organizing tasks. The software should be able to handle multiple users and allow them to create, edit, and track their tasks efficiently.3. Functional Requirements3.1 User Registration and Authentication- The software should allow users to register and create an account with a unique username and password.- Users should be able to log in to the system securely using their credentials.3.2 Task Management- Users should be able to create tasks, set deadlines, and assign priority levels.- The software should provide options for categorizing tasks and adding additional notes.- Users should be able to view, edit, and delete tasks.3.3 Task Tracking- The software should display an overview of all tasks, including their current status and progress.- Users should be able to filter tasks based on criteria such as priority, deadline, or category.- The software should notify users of impending deadlines or overdue tasks.4. Non-Functional Requirements4.1 User Interface- The software should have an intuitive and user-friendly interface that is easy to navigate.- The design should prioritize simplicity and efficiency to enhance user experience.4.2 Security- The software should implement security measures to protect user data and prevent unauthorized access.- Users' passwords should be encrypted and stored securely.4.3 Performance- It should be able to handle multiple users simultaneously without significant performance degradation.5. Design StructureThe software will be developed following the Model-View-Controller (MVC) architectural pattern. This structure separates the presentation and user interaction from the application logic and data management.- The Model represents the data and business logic, including tasks and user information.- The View handles the presentation layer, providing an interface for users to interact with the software.- The Controller acts as an intermediary between the Model and the View, coordinating data flow and user actions.6. ConclusionThis software design specification outlines the functional and non-functional requirements of the software system. It describes the desired features, user interface design, and overall architectural structure. This document will serve as a guide for the development team during the implementation phase.。

ASPICE软件质量保证设计文档英文版

ASPICE软件质量保证设计文档英文版

ASPICE软件质量保证设计文档英文版Document Title: ASPICE Software Quality Assurance Design DocumentIntroductionThis document outlines the design of the software quality assurance process for ASPICE (Automotive SPICE) compliant software development. The goal is to ensure high-quality software products that meet the requirements of the automotive industry.ScopeThe scope of this document covers the entire software development lifecycle, from requirements analysis to testing and validation. It includes the processes, tools, and responsibilities related to software quality assurance.Objectives1. Define the software quality assurance process2. Establish quality standards and metrics3. Ensure compliance with ASPICE requirements4. Identify and mitigate risks related to software quality5. Improve overall software development efficiency and effectivenessProcess OverviewThe software quality assurance process consists of the following key activities:1. Requirements analysis and validation2. Design review and verification3. Code review and static analysis4. Testing and validation5. Defect tracking and resolution6. Process improvement and lessons learnedQuality StandardsThe software quality assurance process will adhere to industry best practices and ASPICE guidelines. Quality standards will be defined for each phase of the software development lifecycle to ensure consistency and reliability.MetricsMetrics will be established to measure the effectiveness of the software quality assurance process. Key performance indicators (KPIs) will be used to track progress, identify areas for improvement, and ensure that quality objectives are met.ComplianceCompliance with ASPICE requirements is essential for successful software development in the automotive industry. The software quality assurance process will be designed to ensure full compliance with all relevant standards and regulations.Risk ManagementRisk management is a critical aspect of software quality assurance. Risks related to software quality will be identified, assessed, and mitigated throughout the development lifecycle to minimize the impact on product quality.ConclusionThe ASPICE software quality assurance design document outlines the process, standards, metrics, compliance, and risk management strategies for ensuring high-quality software products in the automotive industry. By following these guidelines, we aim to improve overall software development efficiency and effectiveness.。

软件系统设计说明书模板

软件系统设计说明书模板

软件系统设计说明书模板XX Software System Design Specification(OO)XX 软件系统设计说明书 (OO)版权所有不得复制Copyright ? BroadenGate Technologies, Co., Ltd.. All Rights ReservedRevision Record 修订记录Catalog⽬录1Introduction 简介 (6)1.1Purpose ⽬的 (6)1.2Scope 范围 (6)1.2.1Name 软件名称 (6)1.2.2Functions 软件功能 (6)1.2.3Applications软件应⽤ (6)2Level 0 Design Description第0层设计描述 (6)2.1Software System Context Definition 软件系统上下⽂定义 (6)2.2Design Considerations (Optional)设计思路(可选) (6)2.2.1Design Alternatives 设计可选⽅案 (6)2.2.2Design Constraints 设计约束 (7)2.2.3Other Design Considerations 其他 (7)3Level 1 Design Description第⼀层设计描述 (7)3.1System Architecture系统结构 (7)3.1.1Description of the Architecture系统结构描述 (7)3.1.2Representation of the Business Flow业务流程说明 (7)3.2Decomposition Description分解描述 (8)3.2.1Module/Subsystem 1 Description模块1/⼦系统1描述 (8)3.2.2Module/Subsystem 2 Description模块2/⼦系统2描述 (8)3.3Dependency Description依赖性描述 (8)3.4Interface Description接⼝描述 (8)3.4.1Module/Subsystem 1 Interface Description模块1/⼦系统1的接⼝描述 (8) 3.4.2Module/Subsystem 2 Interface Description模块2/⼦系统2的接⼝描述 (8) 4Level 2 Design Description第⼆层设计描述 (8)4.1Module Name (1) 模块1名称 (9)4.1.1Design Description模块设计描述 (9)4.1.2Function Illustration功能实现说明 (10)4.2Module Name (2) 模块2名称 (10)4.2.1Design Description模块设计描述 (10)4.2.2Function Illustration功能实现说明 (10)5Database Design数据库设计 (10)5.1Entities Definition实体定义 (10)5.1.1Decomposition Description分解描述 (10)5.1.2Internal Dependency Description内部依赖性描述 (10)5.2Behaviors Definition⾏为定义 (11)5.2.1Decomposition Description分解描述 (11)5.2.2External Dependency Description外部依赖性描述 (11)5.2.3Internal Dependency Description内部依赖性描述 (11)6Detailed Design of Module 模块详细设计 (11)6.1Class1 CLASS的设计 (11)6.1.1Overview简介 (11)6.1.2Class Diagram类图 (11)6.1.3Status Design状态设计 (11)6.1.4Attributes属性 (12)6.1.5Methods⽅法 (12)6.2Class2 CLASS的设计 (12)7Detailed Design of the Database数据库详细设计 (12)7.1Stored Procedure1 #/Trigger1# 存储过程1#/触发器1#的名称 (13)7.2Stored Procedure 2#/Trigger2# 存储过程2#/触发器2#的名称 (13)Keywords 关键词:Abstract 摘要:List of abbreviations 缩略语清单:<对本⽂所⽤缩略语进⾏说明,要求提供每个缩略语的英⽂全名和中⽂解释。

程序文件英文版模板

程序文件英文版模板

程序文件英文版模板Program File TemplateWhen it comes to creating program files, having a wellstructured and clear template is crucial It not only ensures consistency and professionalism but also makes the file more understandable and manageable for all involvedThe first section of the program file should typically contain the file header This includes essential information such as the file name, version number, date of creation, and the author or the team responsible for the file For example:File Name: Specific Program NameexeVersion: 10Date: Month/Day/YearAuthor: Name of Author/TeamNext, comes the introduction or overview section This provides a brief description of the purpose and functionality of the program It helps the readers quickly understand the main objective and scope of the programPurpose: This program is designed to describe the main purpose of the program, eg, calculate financial data, manage inventory, etcFunctionality: The program will outline the key functions and operations it performs, eg, input data, perform calculations, generate reports, etcAfter the introduction, it's important to detail the requirements and dependencies of the program This includes the software and hardware requirements needed to run the program smoothly, as well as any external libraries or frameworks that the program relies onSoftware Requirements:Operating System: Specify the supported OS, eg, Windows 10, Mac OS X, etcProgramming Language Version: Indicate the version of the programming language used, eg, Python 38Hardware Requirements:Processor: Minimum processor speed or type, eg, Intel Core i5Memory: Minimum amount of RAM, eg, 8GBDependencies:List any external libraries or frameworks needed, eg, TensorFlow, NumPy, etcThe next major section is the design and architecture of the program This explains how the program is structured internally, including the different modules, classes, and functions, and how they interact with each otherModule Structure:Describe the main modules of the program and their responsibilitiesProvide a highlevel overview of the flow of data and control within the programAlgorithm and Flowchart (if applicable):If there are specific algorithms or complex logic, describe them in detail or provide a flowchart for better understandingThe coding standards and conventions section is essential to maintain consistency and readability of the code This includes guidelines for naming variables, functions, classes, and formatting the codeNaming Conventions:Variables: Use desired naming style for variables, eg, camelCaseFunctions: Follow function naming rules, eg, use descriptive verbsCode Formatting:Indentation: Use number of spaces or tabs for indentationCommenting: Provide clear and useful comments throughout the code explain the style and requirements for commentsTesting and validation is another critical aspect This section outlines the methods and criteria used to test the program to ensure its correctness and reliabilityTest Cases:List the different types of test cases, eg, unit tests, integration tests, etc Describe the input and expected output for each test caseError Handling and Exception Handling:Explain how the program handles errors and exceptions what kind of messages are displayed, how the program recovers, etcDocumentation is often overlooked but is extremely important for the longterm maintenance and usability of the programUser Manual: Provide instructions on how to install, run, and use the program for endusersTechnical Documentation: Include detailed explanations of the code structure, algorithms, and any other technical aspects for developers who might work on the program in the futureFinally, the conclusion section can summarize the key points of the program file and provide any additional notes or remarksThis template provides a basic framework for creating program files However, it can be customized and expanded based on the specific needs and nature of the program Remember, a welldocumented and organized program file is a key to the success of any software development projectIt's important to note that as the program evolves and changes over time, the program file should also be updated accordingly to reflect the latest version and functionality This ensures that the documentation remains accurate and useful for all stakeholders involved in the project。

软件设计报告格式范文

软件设计报告格式范文

软件设计报告格式范文英文回答:Software design reports are essential for documenting the design process of a software project. They provide a detailed description of the software architecture, design patterns used, and the rationale behind design decisions. The format of a software design report can vary depending on the organization or project requirements, but here is a general outline that can be followed:1. Introduction: This section provides an overview of the software project, its purpose, and the target audience. It also includes a brief description of the problem being addressed and the goals of the software design.2. System Architecture: In this section, the overall structure of the software system is described. It includes the high-level components and their interactions. The architecture may be presented using diagrams, such as UMLdiagrams or block diagrams, to illustrate the relationships between the components.3. Detailed Design: This section delves into thedetails of each component in the system architecture. It describes the responsibilities of each component, the interfaces they expose, and the algorithms or data structures used. This section may include class diagrams, sequence diagrams, or other design artifacts to provide a visual representation of the detailed design.4. Design Patterns: If design patterns are used in the software design, this section explains the patterns chosen and how they are applied in the system. It discusses the benefits of using these patterns and any trade-offs made in their implementation.5. Implementation Considerations: This section discusses any specific considerations or constraints that influenced the design decisions. It may include discussions on performance optimization, security measures, or integration with other systems.6. Testing and Validation: This section describes the testing strategies and techniques used to validate the software design. It includes information on unit testing, integration testing, and any other relevant testing methodologies employed.7. Conclusion: The conclusion summarizes the key points discussed in the report and highlights the successful aspects of the software design. It may also mention any future improvements or recommendations for further development.中文回答:软件设计报告对于记录软件项目的设计过程至关重要。

ASPICE软件需求分析设计文档英文版

ASPICE软件需求分析设计文档英文版

ASPICE软件需求分析设计文档英文版Document Title: ASPICE Software Requirement Analysis and Design DocumentIn the realm of software development, the ASPICE (Automotive Software Process Improvement and Capability Determination) framework plays a crucial role in ensuring the quality and efficiency of software products in the automotive industry. This document aims to provide a comprehensive analysis and design of software requirements within the ASPICE framework.The software requirement analysis phase involves gathering, documenting, and analyzing the needs and constraints of the software system. This includes defining functional and non-functional requirements, identifying stakeholders, and understanding the context of product usage.Designing software requirements involves creating a blueprint for the software system based on the analysis phase. This includes definingsystem architecture, data structures, algorithms, and interfaces. The design phase also considers factors such as scalability, performance, and security.Throughout the process, it is essential to adhere to ASPICE guidelines to ensure compliance with industry standards and best practices. By following a structured approach to software requirement analysis and design, organizations can enhance the quality of their software products and improve overall efficiency.In conclusion, this document serves as a guide for software developers and engineers to effectively analyze and design software requirements within the ASPICE framework. By following the principles outlined in this document, organizations can achieve greater success in developing high-quality software products for the automotive industry.。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

Software Design SpecificationI. Table of ContentsI. TABLE OF CONTENTS (1)1.0 INTRODUCTION (3)1.1 G OALS AND O BJECTIVES (3)1.2 S YSTEM S TATEMENT OF S COPE (3)1.2.1 General Requirements (3)1.3 S YSTEM C ONTEXT (4)1.4 M AJOR C ONSTRAINTS (4)2.0 DATA DESIGN (5)2.1 D ATABASE D ESCRIPTION (5)3.0 ARCHITECTURAL AND COMPONENT-LEVEL DESIGN (6)3.1 P ROGRAM S TRUCTURE (6)3.1.1 Overall (6)3.1.2 Create Inspection (7)3.1.3 During Inspection (7)3.1.4 Post-Inspection (7)3.1.5 Approval (7)3.2 D ESCRIPTION FOR C OMPONENTS (7)3.2.1 Switch User (7)3.2.2 Facility (8)3.2.3 Create/Modify Inspection – Step 1 (8)3.2.4 Create/Modify Inspection – Step 2 (9)3.2.5 File Results – Step 1 (9)3.2.6 File Results – Step 2 (10)3.2.7 Approval (10)3.2.8 Checklist Maintenance (11)3.2.9 Letter Maintenance (11)4.0 USER INTERFACE DESIGN (13)4.1 D ESCRIPTION OF THE U SER I NTERFACE (13)4.1.1 Screen Images (13)Login Screen (13)Search Pages (17)Approval Queue (17)4.1.2 Objects and actions (17)ØMenu Items (18)4.2 I NTERFACE D ESIGN R ULES (23)4.3 C OMPONENTS A VAILABLE (23)4.3.1 Intrinsic Controls (23)4.3.2 ActiveX Controls (25)5.0 RESTRICTION, LIMITATIONS, AND CONSTRAINTS (26)T IME (26)E MPLOYEE S KILLS (26)I NSUFFICIENT R ESOURCES (26)6.0 TESTING ISSUES (27)6.1 C LASSES OF T EST (27)6.2 P ERFORMANCE B OUNDS (37)6.3 I DENTIFICATION OF C RITICAL C OMPONENTS (37)7.0 APPENDICES (39)Rechargeable batteries (39)Palm OS versus Windows CE (39)Screen Size (39)HotSyncing (39)Voice Recognition/cursive writing (39)Handwriting Input (41)Free Programs and Utilities (41)1.0 IntroductionThis section describes the design for the W aste M anagement I nspection T racking S ystem (WMITS).1.1 Goals and ObjectivesThe main purpose of WMITS is to help automate the entire process that the Department of Environmental Quality (DEQ) Waste Management Division (WMD) staff members perform throughout an inspection. The goals of WMITS are:•To minimize the time span of any inspection•To minimize the amount of paper work required•To provide a searchable database of all past inspections•To provide an automated channel for the public to request information (under Freedom of Information Act)Critique: The specific goals and objective of the WMITS design should also be discussed.1.2 System Statement of Scope1.2.1 General RequirementsThe following general requirements were laid out for our project named WMITS:• A way in which DEQ could add new facilities to the database.• A way in which DEQ could generate electronic checklists.• A search on all electronic checklists.• A way in which they could generate letters to be sent out to facilities based on inspection results.• A way in which all letters and checklists could be stored electronically.• A way to search for existing facilities.• A way to print blank checklists and staff reports.• A way in which they could view data which was entered into the database prior to our software.•DEQ wanted a product that would allow them to easily add new checklists and letters or change existing checklists and letters.•Interface EnhancementsStaff members of WMD have requested a lot of interface enhancements that will increase the usability of the product for the staff.•Database Administrative InterfaceThere is current no documented interface for WMD staff members to maintain the checklist and letter templates. Should no such interface existed, Cyber Rovers will have to implement one from scratch.•Online HelpTo develop an extensive help menu for the users and also to setup the online help for the need of the help in the future.•TrainingThe staff members have also requested throughout training for the entire staff for use with the software.We will also implement a web-based helpdesk for WMD staff members to report bugs and request support. The helpdesk will be located at .1.3 System ContextEventually, multiple users will be using the product simultaneously. Therefore, concurrent connection will be an issue for implementation. In addition, this is a pilot product that hopefully, if successful, can be used in other locations as well. This leads to issues about future support for a larger user base.1.4 Major ConstraintsTimeWe only have about two months to finish all documentation, software creation and enhancements. We have a lot of ideas but cannot implement them due to time constraint. One of the major ones is to move the application to be completely browser-based.FundingTo develop and implement the Palm Pilot integration, we will need funding to buy at least one Palm Pilot. We will request the funding from University of Michigan –Dearborn should we decided to pursue this function.2.0 Data Design2.1 Database DescriptionEntities Each record in the entity represents a(n)…TITLE Staff titleSTAFF Staff memberACCESS FacilityMODULE ModuleFACILITY TYPE Facility TypeEPA_CODE EPA CodeINSPECTION InspectionINSPECTION_DETAIL Inspection Checklist ItemINSPECTION_CHKLIST Inspection Checklist3.0 Architectural and Component-Level Design 3.1 Program Structure3.1.1 OverallMenu ItemsThe following shows the architecture of the main menu:•File•Switch User•Exit•Facility•Inspection•Create/Modify•File Results•Get Approval•Print Letters•View Schedule •Approval•Reports•Print Staff Report•Print Blank Checklists•Efficiency Report•… (more TBD)•Maintenance•Checklists•Letters•Users•Options •Help•Contents•About3.1.2 Create Inspection3.1.3 During Inspection3.1.4 Post-Inspection3.1.5 Approval3.2 Description for Components3.2.1 Switch UserMajor Form(s): frmLoginMajor Action(s): LoginThe form frmLogin will appear. User enters their username in txtUserName and password in txtPassword. Then click cmdOkay. User will be logged in if it is a valid username and password pair. If user clicks cmdCancel on this form, application will end if they confirmed their action.3.2.2 FacilityMajor Form(s): frmFacility, frmFacilityBrowse, and frmFacilitySearchMajor Action(s): Browse, Search, Save, Delete and ViewBrowseObject Name: cmdBrowse To browse all facilities, user can click on the bomb button next to the txtFacilityID field. frmFacilityBrowse will appear. User can highlight a facility in the grid, then click cmdOkay. All the information on frmFacility will be filled in.SearchObject Name: cmdSearchTo search for a facility, user can click on the multi-page document button next to the txtFacilityID field. frmFacilitySearch will appear. User can highlight a facility in the result grid, the click cmdOkay. All the information on frmFacility will be filled in.SaveObject Name: cmdSaveThe Save button should be disabled unless the txtFacilityID field is filled in, and any there have been changes made to any field on the frmFacility. When the Save button is clicked, new record will be generated if the Facility ID does not exist in the system, otherwise, current record will be updated.DeleteObject Name: cmdDeleteThe Delete button should be disabled unless no historical data have been found for the facility. The Delete and View button should never be enabled at the same time.ViewObject Name: cmdViewThe View button should be disabled unless historical data have been found for the facility. The Delete and View button should never be enabled at the same time.3.2.3 Create/Modify Inspection – Step 1Major Form(s): frmInspection, frmInspectionBrowse, frmInspectionSearch,frmFacilityBrowse, and frmFacilitySearchMajor Action(s): Create Inspection, Modify Inspection (Inspection Browse,Inspection Search), Next Step and Add/Edit/Delete DateCreate InspectionTo create an inspection, user needs to enter a new Inspection ID in the txtInspectionID field. To use an automatic number, click on the blank paper button, an automatic number will be generated and filled in the txtInspectionID field.User also needs to enter the Facility ID. The browse and search functions are identical to the ones in the Facility module.Modify InspectionTo modify an inspection, user needs to enter an existing Inspection ID in the txtInspectionID field. To browse all open inspections, user can click on the bomb button next to the txtInspectionID field. frmInspectionBrowse will appear. User can highlight an inspection in the grid, then click cmdOkay. All the information on frmInspection will be filled in.Add Onsite Visit DateUser needs to click on the calendar icon, pick a date. txtTime can be left blank. User can then click cmdDateAdd to add the date to the grid.Edit/Delete Onsite Visit DateIf a user highlights a row in the date grid, he or she can edit the contents in the txtDate (using the calendar control) and txtTime field. Then he or she can click on cmdDateEdit to update the record. The user can also click cmdDateDelete to remove the highlighted row.Next StepfrmPickCheckList will appear. See Create/Modify Inspection – Step 2 for more info.3.2.4 Create/Modify Inspection – Step 2Major Form(s): frmPickCheckListMajor Action(s): Pick Checklist(s), FinishFor the second step user needs to pick the checklist(s) that they will be using for the inspection using the intuitive cmdAdd and cmdRemove buttons. Once they have clicked cmdFinish, the inspection will be created/modified in the database.3.2.5 File Results – Step 1Major Form(s): frmFileResults1, frmInspectionBrowse, and frmInspectionSearch Major Action(s): Browse/Search Inspections, Next StepTo file inspection results, user needs to first select a previously created inspection. He or she can use the standard browse and search function to locate the inspection. After an inspection has been chosen, user needs to choose the checklist(s) that they want to file the results. Click cmdNext to proceed to Step 2.3.2.6 File Results – Step 2Major Form(s): frmFileResults2Major Action(s): Add/Edit/Remove comments and status for each inspection item,Preview Letter, Spell Check (2)Add CommentsTo add comment for an inspection item in the checklist, user needs to highlight an item in lstRegulations, enter comments in the txtComments and select status in cboStatus. Then he or she needs to click cmdAdd. The item will be added to lstInspected.Remove CommentsTo remove comments for an added inspection item. User needs to highlight an item in lstInspected then click cmdRemove.Edit CommentsTo edit comments for an added inspection item. User needs to highlight an item in lstInspected. The comments for that item will be shown to the right. The user can then update the comments and click cmdEdit to apply the changes.Spell CheckUser can click on cmdSpellCheck1 (for Add) and cmdSpellCheck2 (for Edit) to check the spellings in the respective comments box.Preview LetterWhen cmdPreview is clicked, the application will generate a letter in the right portion of the screen. Which letter to use will depend on the letter chosen in cboLetters.3.2.7 ApprovalMajor Form(s): frmApproval, frmLetterDisplayMajor Action(s): View, Approve, and DenyfrmApproval will include a data grid that shows the approval requests submitted by the inspectors. The user has the option to view open or closed requests on the data grid. Once a row has been highlighted, the user can click cmdView to view the letter. frmLetterDisplay will appear. He or she then has the option to either approve (frmLetterDisplay.cmdApprove) or deny (frmLetterDisplay.cmdDeny) it. The user can also click on the frmApproval.cmdApprove and frmApproval.cmdDeny to perform those actions without viewing the letter.3.2.8 Checklist MaintenanceMajor Form(s): frmMaintainChecklistsMajor Functions: New, Browse/View, Save, View, Delete, CloseNewWhen cmdNewChecklist is clicked, frmMaintainChecklists will be cleared and the internal checklist ID, intChecklistID will be set to null as well.BrowseWhen cmdBrowseChecklists is clicked, frmBrowseChecklists will appear. After the user made a selection in frmBrowseChecklists (see details in the frmBrowseChecklists component description), txtChecklistID will be filled in by the value returned by frmBrowseChecklists. frmMaintainChecklists will be refreshed with all the details of that checklist. The bottom data grid will be filled in with items from the checklist.RemoveWhen the user click on cmdDeleteChecklist, a warning message will appear to confirm the user’s action. If the user confirms the action, the appropriate checklist header record in CHKLIST_HEADER will be removed. Records in CHKLIST_ITEM that are related to that header will also be removed. Afterwards, lstChecklists will be refreshed.CloseWhen cmdCloseChecklist is clicked, if changes were made to any field within the form, a warning message will appear to confirm user’s action. If the user confirms, the form will be closed and no actions will be performed on the databaswe. If the user does not confirm, user will simply be returned to the form.SaveWhen the user clicks on save, if intChecklistID already exists in the database, the header record in CHKLIST_HEADER with CH_ID equals to intChecklistID will be updated. Also, all records in CHKLIST_ITEM with CI_CH_ID equals to intChecklistID will be updated as well. If intChecklistID does not exist, a header record will be recorded in CHKLIST_HEADER. Appropriate number of records will also be created in CHKLIST_ITEM.3.2.9 Letter MaintenanceMajor Form(s): frmMaintainLettersMajor Functions: New, Browse/View, Save, View, Delete, CloseNewWhen cmdNewLetter is clicked, frmMaintainLetters will be cleared and the internal letter ID, intLetterID will be set to null as well.BrowseWhen cmdBrowseLetters is clicked, frmBrowseLetters will appear. After the user made a selection in frmBrowseLetters (see details in the frmBrowseLetters component description), txtLetterID will be filled in by the value returned by frmBrowseLetters. frmMaintainLetters will be refreshed with all the details of that letter. The bottom data grid will be filled in with items from the letter.RemoveWhen the user click on cmdDeleteLetter, a warning message will appear to confirm the user’s action. If the user confirms the action, the appropriate letter header record in LETTER_HEADER will be removed. Records in LETTER_ITEM that are related to that header will also be removed. Afterwards, lstLetters will be refreshed.CloseWhen cmdCloseLetter is clicked, if changes were made to any field within the form, a warning message will appear to confirm user’s action. If the user confirms, the form will be closed and no actions will be performed on the databaswe. If the user does not confirm, user will simply be returned to the form.SaveWhen the user clicks on save, if intLetterID already exists in the database, the header record in LETTER_HEADER with LTR_ID equals to intLetterID will be updated. Also, all records in LETTER_ITEM with LTRI_LTR_ID equals to intLetterID will be updated as well. If intChecklistID does not exist, a header record will be recorded in LETTER_HEADER. Appropriate number of records will also be created in LETTER_ITEM.4.0 User Interface DesignThere will be about 30 interfaces in the program. We can’t design on the exact number of it yet. Because the clients still have to think over on several interfaces, to see rather they can be combined some of the forms or put some them in separated forms.4.1 Description of the User InterfaceBelow are some of the forms in the program. After fire up the program, the login screen will appear. If the users enter the right user name with the matching password, it will immediately take them to the main interface (mdiDEQ).4.1.1 Screen ImagesLogin ScreenMain InterfaceGenerate Check ListFacility InformationSearch PagesApproval Queue4.1.2 Objects and actions1.Login ScreenUser NameUser name can be ranged from 6 to 20 letters (numbers), as the industry standard. No special characters, space. And mostly likely the users will use their DEQ user name for this system as well.There are 10 people using this project in DEQ, as current status. Eight of them are inspectors, one manager, and one network administrator. Even with a small group like that, we are not going to use the drop down menu for the login name. Logically speaking, drop down menu do save time, and more convenience. But we change our mind after one of the inspector we corresponded with make an interesting comments, “if someone can’t even remember their login name, they would find a new job.” Further more, with a blind login name system, it will provide extra level of security. Because it’s harder to get a user’s user name and password compare to just get their password. PasswordPassword can be ranged from 6 to 20 letters (numbers), as the industry standard. No special characters, space.OKIf the users enter the right user name with the matching password, it will immediately take them to the main interface.CancelIf the user wishes to exit the program, hit the “Cancel” button.2.Main InterfaceØMenu ItemsThe followings show the architecture of the main menu:•File•Switch User•Exit •Facility •Inspection•Create/Modify•File Results•Get Approval•Print Letters•View Schedule •Approval•Reports•Print Staff Report•Print Blank Checklists•Efficiency Report•… (more TBD)•Maintenance•Checklists•Letters•Users•Options •Help•Contents•AboutØSwitch UserMajor Form(s): frmLoginMajor Action(s): LoginThe form frmLogin will appear. User enters their username in txtUserName and password in txtPassword. Then click cmdOkay. User will be logged in if it is a valid username and password pair. If user clicks cmdCancel on this form, application will end if they confirmed their action.ØFacilityMajor Form(s): frmFacility, frmFacilityBrowse, and frmFacilitySearchMajor Action(s): Browse, Search, Save, Delete and ViewØBrowseObject Name: cmdBrowseTo browse all facilities, user can click on the bomb button next to the txtFacilityID field. frmFacilityBrowse will appear. User can highlight a facility in the grid, then click cmdOkay. All the information on frmFacility will be filled in.ØSearchObject Name: cmdSearchTo search for a facility, user can click on the multi-page document button next to the txtFacilityID field. frmFacilitySearch will appear. User can highlight a facility in the result grid, the click cmdOkay. All the information on frmFacility will be filled in.ØSaveObject Name: cmdSaveThe Save button should be disabled unless the txtFacilityID field is filled in, and any there have been changes made to any field on the frmFacility. When the Save button is clicked, new record will be generated if the Facility ID does not exist in the system, otherwise, current record will be updated.ØDeleteObject Name: cmdDeleteThe Delete button should be disabled unless no historical data have been found for the facility. The Delete and View button should never be enabled at the same time.ØViewObject Name: cmdViewThe View button should be disabled unless historical data have been found for the facility. The Delete and View button should never be enabled at the same time.ØCreate/Modify Inspection – Step 1Major Form(s): frmInspection, frmInspectionBrowse, frmInspectionSearch,frmFacilityBrowse, and frmFacilitySearchMajor Action(s): Create Inspection, Modify Inspection (Inspection Browse,Inspection Search), Next Step and Add/Edit/Delete DateØCreate InspectionTo create an inspection, user needs to enter a new Inspection ID in the txtInspectionID field. To use an automatic number, click on the blank paper button, an automatic number will be generated and filled in the txtInspectionID field.User also needs to enter the Facility ID. The browse and search functions are identical to the ones in the Facility module.ØModify InspectionTo modify an inspection, user needs to enter an existing Inspection ID in the txtInspectionID field. To browse all open inspections, user can click on the bomb button next to the txtInspectionID field. frmInspectionBrowse will appear. User can highlight an inspection in the grid, then click cmdOkay. All the information on frmInspection will be filled in.ØAdd Onsite Visit DateUser needs to click on the calendar icon, pick a date. txtTime can be left blank. User can then click cmdDateAdd to add the date to the grid.ØEdit/Delete Onsite Visit DateIf a user highlights a row in the date grid, he or she can edit the contents in the txtDate (using the calendar control) and txtTime field. Then he or she can click on cmdDateEdit to update the record. The user can also click cmdDateDelete to remove the highlighted row.ØNext StepfrmPickCheckList will appear. See Create/Modify Inspection – Step 2 for more info.ØCreate/Modify Inspection – Step 2Major Form(s): frmPickCheckListMajor Action(s): Pick Checklist(s), FinishFor the second step user needs to pick the checklist(s) that they will be using for the inspection using the intuitive cmdAdd and cmdRemove buttons. Once they have clicked cmdFinish, the inspection will be created/modified in the database.ØFile Results – Step 1Major Form(s): frmFileResults1, frmInspectionBrowse, and frmInspectionSearch Major Action(s): Browse/Search Inspections, Next StepTo file inspection results, user needs to first select a previously created inspection. He or she can use the standard browse and search function to locate the inspection. After aninspection has been chosen, user needs to choose the checklist(s) that they want to file the results. Click cmdNext to proceed to Step 2.ØFile Results – Step 2Major Form(s): frmFileResults2Major Action(s): Add/Edit/Remove comments and status for each inspection item,Preview Letter, Spell Check (2)ØAdd CommentsTo add comment for an inspection item in the checklist, user needs to highlight an item in lstRegulations, enter comments in the txtComments and select status in cboStatus. Then he or she needs to click cmdAdd. The item will be added to lstInspected.ØRemove CommentsTo remove comments for an added inspection item. User needs to highlight an item in lstInspected then click cmdRemove.ØEdit CommentsTo edit comments for an added inspection item. User needs to highlight an item in lstInspected. The comments for that item will be shown to the right. The user can then update the comments and click cmdEdit to apply the changes.ØSpell CheckUser can click on cmdSpellCheck1 (for Add) and cmdSpellCheck2 (for Edit) to check the spellings in the respective comments box.ØPreview LetterWhen cmdPreview is clicked, the application will generate a letter in the right portion of the screen. Which letter to use will depend on the letter chosen in cboLetters.ØApprovalMajor Form(s): frmApproval, frmLetterDisplayMajor Action(s): View, Approve, and DenyfrmApproval will include a data grid that shows the approval requests submitted by the inspectors. The user has the option to view open or closed requests on the data grid. Once a row has been highlighted, the user can click cmdView to view the letter. frmLetterDisplay will appear. He or she then has the option to either approve (frmLetterDisplay.cmdApprove) or deny (frmLetterDisplay.cmdDeny) it. The user can also click on the frmApproval.cmdApprove and frmApproval.cmdDeny to perform those ViewView details of the reportRedoSend back to the inspector, either ask the inspector redo it, or take it over on some detailsApprovalApproval the report, and computer will generate a message, tells that the report has been approval. Once the inspector sees the message, he/she will print out the report, and send it to the facility.4.2 Interface Design RulesInterface design focuses on three areas of concern:1.The design of interfaces between software modules;2.The design of interfaces between the software and other nonhuman producers andconsumers of information (i.e., other external entities);3.The design of the interface between a human (i.e., the user) and the computer.Easy to LearnReadabilityEasy navigate between interfaces4.3 Components AvailableSince we are using Visual Basic as our front-end development language, there are a lot of ready-made components that are available for us to use already. The following is a list of controls that we will be using for this software.4.3.1 Intrinsic ControlsTextBoxA TextBox control, sometimes called an edit field or edit control, displays information entered at design time, entered by the user, or assigned to the control in code at run time.LabelA Label control is a graphical control you can use to display text that a user can't change directly.LineA Line control is a graphical control displayed as a horizontal, vertical, or diagonal line.ImageUse the Image control to display a graphic. An Image control can display a graphic from a bitmap, icon, or metafile, as well as enhanced metafile, JPEG, or GIF files.ListBoxA ListBox control displays a list of items from which the user can select one or more. If the number of items exceeds the number that can be displayed, a scroll bar is automatically added to the ListBox control.ScrollbarsScroll bars provide easy navigation through a long list of items or a large amount of information. They can also provide an analog representation of current position. You can use a scroll bar as an input device or indicator of speed or quantity—for example, to control the volume of a computer game or to view the time elapsed in a timed process. CommandButtonUse a CommandButton control to begin, interrupt, or end a process. When chosen, a CommandButton appears pushed in and so is sometimes called a push button.MenuA Menu control displays a custom menu for your application. A menu can include commands, submenus, and separator bars. Each menu you create can have up to four levels of submenus.ComboBoxA ComboBox control combines the features of a TextBox control and a ListBox control—users can enter information in the text box portion or select an item from the list box portion of the control.CheckboxA CheckBox control displays an X when selected; the X disappears when the CheckBox is cleared. Use this control to give the user a True/False or Yes/No option. You can use CheckBox controls in groups to display multiple choices from which the user can select one or more. You can also set the value of a CheckBox programmatically with the Value property.OptionButtonAn OptionButton control displays an option that can be turned on or off.ShapeThe Shape control is a graphical control displayed as a rectangle, square, oval, circle, rounded rectangle, or rounded square.4.3.2 ActiveX ControlsDataRepeaterThe DataRepeater control functions as a scrollable container of data-bound user controls. Each control appears in its own row as a "repeated" control, allowing the user to view several data-bound user controls at once.DateTimePickerThe DateTimePicker control enables you to provide a formatted date field that allows easy date selection. In addition, users can select a date from a dropdown calendar interface similar to the MonthView control.MSFlexGridThe Microsoft FlexGrid (MSFlexGrid) control displays and operates on tabular data. It allows complete flexibility to sort, merge, and format tables containing strings and pictures. When bound to a Data control, MSFlexGrid displays read-only data.TreeViewA TreeView control displays a hierarchical list of Node objects, each of which consists of a label and an optional bitmap. A TreeView is typically used to display the headings in a document, the entries in an index, the files and directories on a disk, or any other kind of information that might usefully be displayed as a hierarchy.StatusBarA StatusBar control provides a window, usually at the bottom of a parent form, through which an application can display various kinds of status data. The StatusBar can be divided up into a maximum of sixteen Panel objects that are contained in a Panels collection.ToolbarA Toolbar control contains a collection of Button objects used to create a toolbar that is associated with an application.CommonDialogThe CommonDialog control provides a standard set of dialog boxes for operations such as opening and saving files, setting print options, and selecting colors and fonts. The control also has the ability to display help by running the Windows Help engine.。

相关文档
最新文档