Functional specifications document

Next, one should develop the functional specifications for a system. The functional specifications document should establish the HPLC system s actual capabilities as they apply to the full scope of the URS. Some of the more specific URS requirements may be included in the functional specifications as well. This document is often developed with significant vendor interaction and input. 

This is a single document (clear, concise, accurate, and complete) describing the purpose and function of the system. System Overviews are therefore not necessary for less complex systems where there is a single URS or Functional Specification document. 

Abstract Software and computer systems are tested during all development phases. The user requirements and functional specifications documents are reviewed by programmers and typical anticipated users. The design specifications are reviewed by peers in one to two day sessions and the source code is inspected by peers, if necessary. Finally, the function and performance of the system is tested by typ-... 

The functional specifications document that is available for users to write their own requirement specifications and operational qualifications or acceptance testing... 

At this phase no technical hurdles are anticipated. Future actions include conducting a safety design review (HazOps analysis), establishing an activity-based target date for a critical design review, and generating a system level functional specification document which will help define the research boundaries for this project. 

A short stability curve is not necessarily a reason to reject a particular column. If the unique selectivity of a given column is essential for achieving a particular analytical separation, it can be used so long as its performance is validated to persist for a specified number of runs and a column log is maintained to document that its usage is limited accordingly. Periodic analyses to document that it is still within functional specification may also be prudent. The point is to ensure that assay performance does not fall victim to an undetected source of progressive variation. 

Confirm and document that system is operating according to vendor s functional specifications ( 0)... 

The IQ is typically followed in close succession by the OQ protocol. The OQ confirms and documents that an instrument operates in accordance with the vendor s functional specifications. Again, similar to that for the IQ, the OQ protocol is often partly, if not totally, developed by the vendor of the instrument. In some laboratories, the internal calibration tests may be incorporated as part of the OQ protocol. In most cases the protocol is typically carried out by a vendor s qualified service engineer. Since the same service engineer often performs both the IQ and the OQ, the IQ and PQ are often combined as part of an overall IQ/OQ protocol. 

The scope, defining the purpose of the OQ protocol may be combined with the overall scope of an IQ/OQ protocol. It should describe what component/software will be validated as operating according to the functional specifications. Again, as described for the IQ, the scope of the OQ should provide a basic outline as to implementation tasks, and define the overall documentation, validation and installer s qualification requirements. 

Design qualification document consisting of user requirement specifications (URS) and functional specifications (FS) [URS and FS can be combined into one system requirement specifications document (SRS)]... 

The most important factors for the entire process of equipment qualification and computer system validation in analytical laboratories are proper planning, execution of qualification according to the plan, and documentation of the results. The process should start with the definition of the analytical technique and the development of user requirement and functional specifications. For computer systems, a formal vendor assessment should be made. This can be done through checklists and vendor documentation with internal and/or external references. For very complex systems, it should go through a vendor audit. 

The installation should be documented. The accuracy of software installation should be verified, and for networked systems, drawings with diagrams should be generated. The instrument should be tested for compliance to user requirements and functional specifications, as defined during the design qualification. Critical parameters should be tested before and during routine analysis. System suitability... 

Use case specifications document functional requirements. The next step is to design the partial system that the current iteration is supposed to deliver. The gap between requirements and design is not trivial, and a bridge between the two is desired. This bridge is what object-oriented analysis is about. The domain analysis object model is not the final design. However, it provides a starting point for the design process. 

Develop use case specification documents to capture detailed functional requirements (Chapter 9). Use System Sequence Diagrams and Activity Diagrams as complements. Use case specifications should be developed, communicated, and reviewed at the beginning of each iteration. 

The specification names used here are one example, but there are many ways to refer to the same documents. The URS might instead be called the business requirements specification (BRS).The FRS might be functional specification (FS) or the system requirements specification (SRS). The DDS might be a design specification (DS) or an engineering specification (ES). The intended purpose of the specification must be delineated in the document to avoid confusion. 

Life-cycle project management and documentation Software and hardware selection considerations User requirements Functional specification Testing... 

This is essentially the same document as described earlier for the Project Initiation phase but defining the scope of the supplier s role and responsibility. The Supplier Quality Plan should act as an extension to the Supplier Proposal and Contract of Supply. The Supplier Quality Plan should be approved before the Functional Specification is approved. If the supplier is an internal function of the pharmaceutical or healthcare company, these plans do not need to exist as separate documents but rather can be integrated within overall project Validation Plans, Project Plans, and Quality Plans. 

Depending on the nature of the Invitation to Tender, the supplier s response may amount to little more than a covering letter with accompanying standard literature. This is often the case for COTS products that the supplier believes meets the user s requirements, or when a dedicated supplier proposal for a more bespoke or customized solution is to follow. Some suppliers may even draft an initial Functional Specification to demonstrate the suitability of the solution they have in mind. Functional Specifications are discussed in detail in Chapter 8. Other proposal documentation might include draft Project and Quality Plans. 

Is a written functional specification or design document a mandatory prerequisite for software development ... 

The Functional Specification should, as far as possible, avoid detailed design and concentrate on defining the operation and user interaction with the computer system. This is generally more difficult than it sounds. In some instances it is not even applicable because the URS specifically requests particular equipment or a particular design to be used. Similarly for small projects, it is often more convenient to combine the Functional Specification and Design documents into what is often referred to as a Functional Design Specification, System Definition, or System Description. 

In many circumstances, the supplied system will be based on a standard COTS product and include additional features that are superfluous in the intended context. These features cannot normally be disabled because they are integral to the COTS product. Such redundant features should be included in the Functional Specification, noted as superfluous and, if possible, rendered inaccessible to users within the implemented computer system. Standard features that support compliance, such as audit trails for electronic records, should be used even if not defined within the URS. In such circumstances it may be necessary to make additional design allowances for the inclusion of these features (e.g., for audit trail functionality, extra storage capacity may be required). Standard documentation for COTS products can be referenced by the Fnnctional Specification, if available for inspection, rather than reproduced. Care must be taken to refer to the correct version of COTS documentation and to keep cross-references up to date following any system upgrades. 

Functional specifications should be developed for the host machine, its operating system, and utilities. The scope will include the use of any servers. Design documentation should cover the actual configuration and semp of the computing hardware and associated equipment. 

Some pharmaceutical and healthcare companies combine the intent of URS and Functional Specification when condncting retrospective validation into a docnment called a System Specification. The System Specification will inclnde a statement to the effect that the document represents not only a description of the system in nse but also that this description fnlfills user requirements... 

Functional specifications Design specifications — high level and detailed Code docnmented and commented Testing plans, docnmented test results Review of all documentation by knowledgeable people Release criteria and maintenance plan Validation plans, procednres, and report... 

Electronic audit trail. Check if the audit trail records events as specified in the functional requirement specifications document. 

It is important to realize that the URS is a living document and must be updated as the system changes and evolves for example, an URS should be written to select a system. It will then be reviewed and updated to reflect the selected CDS and version that will be validated and the functions specific to the laboratory where it will be installed. 

A requirements trace matrix (RTM) is a tool to map requirements. However, these can become large and difficult to maintain. An alternative approach is to provide implicit traceability by having a common structure and numbering system for all system design and test documentation. The one area where this is often difficult to achieve is with the User Requirements Specification (URS). The URS often covers not only the DCS requirements but those of the wider project, and is also produced before the system vendor has been selected. In this case a requirements traceability matrix should be generated to confirm requirements relevant to the DCS are addressed within the functional specifications. 

---