Software Design Specification developing

Software is not a physical entity and, unlike some hardware failures, software failures occur without advanced warning. One of the most common software failures is branching, that is, the ability to execute alternative series of commands based on differing inputs. The software branching capacity makes the commands extremely complex and difficult to validate once errors occur as an answer of a specific input, and until the introduction of that specific input error has not been detected. Software input can be almost any data and, and since it is impossible to introduce all data into a software, validation of data is extremely difficult. Thus, results are considered to be of high confidence level. The majority of software problems occur as a consequence of errors in the software design and development and are not directly related to the software manufacture. It is simple to manufacture several software copies that work perfectly and as the original one. 

The FS is developed into a hardware design specification (HDS) or a software design specification (SDS) or both. The SDS provides the facihty to break each functional requirement into appropriate subfunctions, increasing in detail at each subsequent level, until eventually the design reaches a state where it can be translated into software code. The SDS should mimic the sections of the FS but be specific to software constraction. Some examples are as follows ... 

A Software Design Specification (Figure 2.14) must be developed to document the requirements of the bespoke software application. Typically, the Software Design Specification defines the software architecture in modular terms. 

Application software design and development Architecture To create a software architecture that fulfils the specified requirements for software safety To review and evaluate the requirements placed on the software by the hardware architecture of the SIS 12.4.3 SIS application software safety requirements specification SIS hardware architecture design manuals Description of the architecture design, for example, segregation of application S/W into related process subsystem and SIL(s), for example, recognition of common application S/W modules such as pump or valve sequences... 

Application software design, and development. Support tools and programming languages To identify a suitable set of configuration, library, management, and simulation and test tools, over the whole safety life cycle of the software (utility software) 12.4.4 SIS application software safety requirements specification Description of the architecture design Manuals of the SIS List of procedures for use of utility software Verification information... 

In a traditional software-engineering approach, the definition of user needs and software-design specifications come early in the development process. At this stage, the users may not have the necessary knowledge and experience to be able to define their needs. Only after using the system for a while do they know what they actually want. It may then be too expensive to change... 

Composition is an age-old idea in software specification and development any method must have clear rules about the outcome of combining designs, specifications, or code. Popular 00 methods do not address this issue in a meaningful way. Exceptions are Disco s composition of entire models [Kurth90], Syntropy s subtyping and viewpoints [Cook94], and OORAM s role-model synthesis [Reenskang95], Related work in non-00 approaches are plentiful Z, Unity, and so on. 

Hegge, F.W. et al., The Unified Tri-Service Cognitive Performance Assessment Battery (UTC-PAB), 11 Hardware Software Design and Specification, U.S. Army Medical Research and Development Command, Fort Detrick, MD, 1985. 

The procedures used to design and develop project-specific application software, including version control and management, the documentation provided, and backup copy availability. 

Operating system code availability Software/hardware specifications Software/hardware design practices Product design records Program coding standards System development records System test records Programming tools Control of nonoperational software Removal of dead code ... 

During system development and build the supplier will normally be responsible for all software and hardware development tests and reports, with the pharmaceutical manufacturer involved as agreed upon under the contract. Development test specifications are to be used to demonstrate that the developed software and hardware provides the functionality and operation as defined in the system design specifications. 

The computer system URS and FDS, the subsequent software and hardware design specifications, and instrument data sheets are the reference documents for qualification protocol development. The basis and acceptance criteria for each test should be derived from the system parameters, data, and function requirements that have been specified. It is advantageous to commence development of the test procedures at the same time as the respective specifications— this to best ensure that requirements and tests correspond, are traceable, and can be better understood. 

It is imperative that an agreement is reached on a structured approach before any programming/configuration of the software begins. This approach should provide the basis for a design specification deliverable which defines the system development scope. 

During each software or system development step, the developer provides documented evidence that implementing the requirements specified in the requirements specification deliverable developed the product. During the design, the in-process (internal) audit must be carried out in order to verify that the design of the computer system satisfies the requirements described in the computer system specification deliverable, and that the code has been developed in accordance with the technical design specification deliverable. 

In a mature software development environment, software is developed as individual components or small units. Each unit is tested individually and integrated with other units to form a module. The accurate implementation of each module is achieved by following the technical design specification deliverable. The output of the software development process is an assembled system. 

The developer must install the software product in accordance with the installation plan and procedures. It must be ensured that the software code and databases initialize, execute, and terminate as specified in the technical design specification deliverable. The installation events and results must be documented. 

Complete A Requirements Traceability Matrix (RTM) should be developed to confirm that all relevant aspects of the URS have been brought forward into the Functional Specification and Design Specifications. This includes both positive and negative requirements (the latter often overlooked), i.e., what the software is snpposed to do and what it is NOT supposed to do ... 

---