Examples for technical scientific documents
Standard operating procedures, SOPs
SOPs describe exactly how a certain process step needs to be conducted and what is necessary for it. A SOP for an analytical method in a QC laboratory describes the exact performance, based on the validation, to achieve a reliable result.
In the applicability it can be defined for which product the method is used. The number of samples to be used is specified. The reaction principle of the method can be explained. Material, reagents and devices to be used are listed. It’s described how the solvents, the samples as well as the reference standard have to be prepared. The subsequent procedure is explained in detail in the actual performance description. It’s specified how the samples are diluted if necessary, where they are applied, which reagents have to be added, how long incubation needs to be done and under which conditions the measurement is taking place. Subsequently, there is a paragraph about the evaluation, in which the calculation of the results as well as the acceptance criteria to be complied with and, if necessary, the system control is described.
A SOP should be so comprehensible and detailed that a new staff member is able, after a corresponding training, to perform the method correctly, and to come to the correct result using a standard.
A specification lists the requirements for a product. It shows for which product (and, if necessary, for which dosage) the specification is applicable and which parameters need to be adhered to. A specification for the drug product includes, amongst others, information about protein content, purity, identity, efficacy, number of visible and subvisible particles and methods with which these parameters have to be tested within release and / or stability analysis.
Pharmaceutical development reports
A development report as a generally rather extensive document provides insight into the development and the first “life cycle” of a drug.
Apart from information about the product composition, it explains how they have been developed and possibly changed previously - for example, the optimal protein concentration or the selection of the best stabilizer. Apart from the description of the development process, the derivation of critical or non-critical process parameters can be part of the development report. However, the key component is the overview over all characterization and validation studies that have been conducted during development so far. The studies that have been conducted for the corresponding process step can be listed in a table. Afterwards, the results are briefly summarized. A final conclusion, with an overview in tabular form about the acceptable range of the corresponding critical process parameters if necessary, can round off the development report.
User requirements specification, URS
Before purchasing a complex system / device and the assignment of an order, there is the compilation of an URS. There, the customer’s view regarding the requirements of the device to be acquired is described (“make a wish” view of the customer). The document communicates all requirements for the product and the expected services to the supplier. A well-designed URS helps to obtain and directly compare offers from different suppliers, because the information basis is the same for each supplier.
Accordingly, the customer is confronted with the task to think in detail about his expectations and compile them in a structured document. Regarding the content, he must address functional requirements, the framework and the extent of the delivery amongst others. In case of an analytical balance for instance, this can concern the weighing range and the measurement inaccuracy, the existence of an audit trail, the user registration, the compatibility with the existing laboratory system, expandability (for example different filters in case of a fluorescence microscope), maintenance intervals, service, contributions to the qualification by the supplier etc., to name just a few examples. It’s crucial not to copy the data sheets or the manufacturer information, but to really address your own user requirements.
The counterpart to the URS is the specification sheet of the supplier. He compares it to the requirements specified in the URS. This happens in the first phase of device qualification and ends typically with ordering the desired device.
White papers are documents that are published on the internet (primarily as a PDF) as free downloads by companies and that inform the reader precisely and comprehensibly about a process, a product or a problem. They are written objectively in a factual, scientific style, are based on verifiable facts and are really useful to the reader as a source of information because they abstain from promotional aspects. Paradoxically, they’re still an important marketing instrument, especially in the B2B field, because they prove professional competence, increase publicity and improve the company website’s google ranking.
The point of a white paper is, in the case of decision support, to provide a concrete answer to a complex question or to serve as a guide with technically well-researched, detailed information. They answer questions before the purchase is made and are tailored to their target audience. A clear structure, illustrations and summaries make the reading flow easier. Even though there are no specifications for the length of a white paper, they are usually between 3 and 15 pages long, depending on the complexity of the topic. They’re supposed to put something in a nutshell instead of boring their reader.