Is there anything you can add to this? I send send more information if needed
A Software Design Specification Template Group E Software Design Specification Table of Contents 11. Introduction 21.1. Document Outline 41.2. Document Description 41.2.1. Introduction 51.2.2. System Overview 52. Design Considerations 52.1. Assumptions and Dependencies 52.2. General Constraints 62.3. Goals and Guidelines 62.4. Development Methods 63. Architectural Strategies 74. System Architecture 84.1. Subsystem Architecture 85. Policies and Tactics 96. Detailed System Design 96.1. Classification 96.2. Definition 106.3. Responsibilities 106.4. Constraints 106.5. Composition 106.6. Uses/Interactions 106.7. Resources 106.8. Processing 116.9. Interface/Exports 116.10. Detailed Subsystem Design 117. Glossary 118. Bibliography 1. Introduction The following is Group E’s Software Design Specification. This document is designed to serve as training and reference material for both new and old developers. The goal is to explain enough about the Additive Manufacturing PM program, its design, and implementation and new members of the team can quickly get up to speed. This will also serve as a quick reference for anyone looking into the project. This document is not all encompassing, and is designed to be used in conjunction with Group E’s Project Management Plan and Group E’s User’s Guide and Test Plan. 1.1. Document Outline Here is the outline of the proposed template for software design specifications. Please note that many parts of the document may be extracted automatically from other sources and/or may be contained in other, smaller documents. What follows is just one suggested outline format to use when attempting to present the architecture and design of the entire system as one single document. This by no means implies that it literally is a single document (that would not be my personal preference): · Introduction · System Overview · Design Considerations · Assumptions and Dependencies · General Constraints · Goals and Guidelines · Development Methods · Architectural Strategies · strategy-1 name or description · strategy-2 name or description · ... · System Architecture · Inventory Management Component · Printer Settings Tracker Component · Policies and Tactics · policy/tactic-1 name or description · policy/tactic-2 name or description · ... · Detailed System Design · module-1 name or description · module-2 name or description · ... · Glossary · Bibliography 1.2. Document Description In the following Introduction we will discuss the purpose, scope, and a description of the contents of the Additive Manufacturing PM for software design specifications: 1.2.1. Introduction The purpose of this document is to document and record the design and specification of the Additive Manufacturing PM application. This is a living document and will be updated as the project is developed and changes are made. This should help new developers and support staff get up to speed on the project, as well as anyone else interested. We will go over the design of the application without worrying about implementation details. Accompanying this document are Group E’s Project Management Plan and Group E’s User Guide and Test Plan, as well as a glossary of important terms. 1.2.2. System Overview Provide a general description of the software system including its functionality and matters related to the overall system and its design (perhaps including a discussion of the basic design approach or organization). Feel free to split this discussion up into subsections (and subsubsections, etc ...). 2. Design Considerations This section describes many of the issues which need to be addressed or resolved before attempting to devise a complete design solution. 2.1. Assumptions and Dependencies The following are the software and hardware dependencies for this application: · Java compatible IDE · JRE 8 · Windows 10 / 11 · Computer capable of running windows 10/11 We can assume that the end user will be tracking filament via weight, and that possible changes in functionality would be limited to the amount or variety of inventory. 2.2. General Constraints The current limitation other than those mentioned above is the end user have permissions to execute the program on their PC. 2.3. Goals and Guidelines The current goals and guidelines are as follows: · Keep the code clean. · It is hard to follow the flow when there is too much going on in one method. Break what you can in to pieces to make it understandable by someone looking in. · Keep the code simple. · Fast code is great, but not if no one else can figure out what it does! While it might be the fastest by a microsecond, if it is difficult to grasp it might not be the best to use. · Comment so everyone can understand the code. · It helps everyone figure out what the code is doing. · Make a product that is enjoyable to use! 2.4. Development Methods The development methods used for this application were a simple. We had a group discussion to whiteboard the application, and then due to the limited timeframe for development we are using the agile methodology to be able to adapt to any changes in the project requirements and to keep communications between teammates. 3. Architectural Strategies The base architectural strategy for the Additive Manufacturing PM application is that it will be developed using Java. This was decided due to the cross-platform nature of the language, as well as it being the most commonly known language among the team. This will speed development, but also allow for the application to be moved to other environments in the future as long as they are capable of running the JVM. Another strategy that we would like to implement is for the application to be easily extendable. 3D printing enthusiasts tend to be the type to tinker, so we want to make this application extendable to specific user cases. We also want to make the application simple to use without a complex learning curve. 4. System Architecture This section should provide a high-level overview of how the functionality and responsibilities of the system were partitioned and then assigned to subsystems or components. Don't go into too much detail about the individual components themselves (there is a subsequent section for detailed component descriptions). The main purpose here is to gain a general understanding of how and why the system was decomposed, and how the individual parts work together to provide the desired functionality. At the top-most level, describe the major responsibilities that the software must undertake and the various roles that the system (or portions of the system) must play. Describe how the system was broken down into its components/subsystems (identifying each top-level component/subsystem and the roles/responsibilities assigned to it). Describe how the higher-level components collaborate with each other in order to achieve the required results. Don't forget to provide some sort of rationale for choosing this particular decomposition of the system (perhaps discussing other proposed decompositions and why they were rejected). Feel free to make use of design patterns, either in describing parts of the architecture (in pattern format), or for referring to elements of the architecture that employ them. If there are any diagrams, models, flowcharts, documented scenarios or use-cases of the system behavior and/or structure, they may be included here (unless you feel they are complex enough to merit being placed in the Detailed System Design section). Diagrams that describe a particular component or subsystem should be included within the particular subsection that describes that component or subsystem. Note: This section (and its subsections) really applies only to newly developed (or yet-to-be developed) portions of the system. If there are parts of the system that already existed before this development effort began, then you only need to describe the pre-existing parts that the new parts of the system depend upon, and only in enough detail sufficient to describe the relationships and interactions between the old parts and the new parts. Pre-existing parts that are modified or enhanced need to be described only to the extent that is necessary for the reader to gain a sufficient understanding of the nature of the changes that were made. 4.1. Subsystem Architecture If a particular component is one which merits a more detailed discussion than what was presented in the System Architecture section, provide that more detailed discussion in a subsection of the System Architecture section (or it may even be more appropriate to describe the component in its own design document). If necessary, describe how the component was further divided into subcomponents, and the relationships and interactions between the subcomponents (similar to what was done for top-level components in the System Architecture section). If any subcomponents are also deemed to merit further discussion, then describe them in a separate subsection of this section (and in a similar fashion). Proceed to go into as many levels/subsections of discussion as needed in order for the reader to gain a high-level understanding of the entire system or subsystem (but remember to leave the gory details for the Detailed System Design section). If this component is very large and/or complex, you may want to consider documenting its design in a separate document and simply including a reference to it in this section. If this is the option you choose, the design document for this component should have an organizational format that is very similar (if not identical to) this document. 5. Policies and Tactics Describe any design policies and/or tactics that do not have sweeping architectural implications (meaning they would not significantly affect the overall organization of the system and its high-level structures), but which nonetheless affect the details of the interface and/or implementation of various aspects of the system. Such decisions might concern (but are not limited to) things like the following: · Choice of which specific product to use (compiler, interpreter, database, library, etc. ...) · Engineering trade-offs · Coding guidelines and conventions · The protocol of one or more subsystems, modules, or subroutines · The choice of a particular algorithm or programming idiom (or design pattern) to implement portions of the system's functionality · Plans for ensuring requirements traceability · Plans for testing the software · Plans for maintaining the software · Interfaces for end-users, software, hardware, and communications · Hierarchical organization of the source code into its physical components (files and directories). · How to build and/or generate the system's deliverables (how to compile, link, load, etc. ...) Each particular policy or set of tactics employed should probably be discussed in its own subsection, or (if it is large or complex enough) in a separate design document (with an appropriate reference here of course). Make sure that when describing a design decision that you also discuss any other significant alternatives that were considered, and your reasons for rejecting them (as well as your reasons for accepting the alternative you finally chose). For this reason, it may frequently be convenient to use one of the more popular "pattern formats" to describe a given tactic. For this particular section, it may become difficult to decide whether a particular policy or set of tactics should be discussed in this section, or in the System Architecture section, or in the Detailed System Design section for the appropriate component. You will have to use your own "best" judgement to decide this. There will usually be some global policies and tactics that should be discussed here, but decisions about interfaces, algorithms, and/or data structures might be more appropriately discussed in the same (sub)section as its corresponding software component in one of these other sections. 6. Detailed System Design Most components described in the System Architecture section will require a more detailed discussion. Other lower-level components and subcomponents may need to be described as well. Each subsection of this section will refer to or contain a detailed description of a system software component. The discussion provided should cover the following software component attributes: 6.1. Classification The kind of component, such as a subsystem, module, class, package, function, file, etc. .... 6.2. Definition The specific purpose and semantic meaning of the component. This may need to refer back to the requirements specification. 6.3. Responsibilities The primary responsibilities and/or behavior of this component. What does this component accomplish? What roles does it play? What kinds of services does it provide to its clients? For some components, this may need to refer back to the requirements specification. 6.4. Constraints Any relevant assumptions, limitations, or constraints for this component. This should include constraints on timing, storage, or component state, and might include rules for interacting with this component (encompassing preconditions, postconditions, invariants, other constraints on input or output values and local or global values, data formats and data access, synchronization, exceptions, etc.) 6.5. Composition A description of the use and meaning of the subcomponents that are a part of this component. 6.6. Uses/Interactions A description of this components collaborations with other components. What other components is this entity used by? What other components does this entity use (this would include any side-effects this entity might have on other parts of the system)? This concerns the method of interaction as well as the interaction itself. Object-oriented designs should include a description of any known or anticipated subclasses, superclasses, and metaclasses. 6.7. Resources A description of any and all resources that are managed, affected, or needed by this entity. Resources are entities external to the design such as memory, processors, printers, databases, or a