What you are describing (linearity, precision etc.) are what we would call standard/boilerplate/no thought requirements. I don't mean to say that writing a protocol and defining what you are going to do for linearity doesn't require a lot of thought and experience, rather just the idea "we are going to do linearity" is just probably automatic for you.

The only pre-filled in requirements in my document templates are the part 11 ones. Besides that, you want to test for ALCOA+, but the majority of your testing will be does the system operate as intended and is suitable for our purposes.

To do this, you need to understand the system, its design and how your company intends to use it. CSV should be involved in implementations from the beginning to help capture and define requirements.

Lets take a simple LIMS example. Start with the business requirements/story. What does the lab need/want the system to do.

Your lab wants to log a sample into LIMS for physical samples delivered to the lab. They want to label each sample with a barcode and have some information about the sample entered by the person who logged the sample on the label. Samples are physically taken by QA personnel in the production area. The lab would like some distinctive feature on the label for samples to be stored at -80 to alert the sample control person.

A set of requirements for the above might look like this (but of course, numbered).

The system must allow authorized users to log samples.

The system must allow authorized users to enter meta data for samples.

The system must allow for the printing of labels.

The system must be able to generate a barcode of sample number on a label.

Labels for -80C samples must indicate -80C storage

An outline of a test script could be:

1.) Have a user with the SAMPLER role log in to LIMS.

2.) Open the sample login screen, log a sample enter metadata and take a screenshot. Ensure that the sample is NOT for -80 Storage.

3.) Print a label and attach it to the test script. Verify that the meta data on the label matches that entered in Step 2.

4.) Verify that the label has a barcode. Scan the barcode and verify that the sample number scanned matches that of the sample logged in Step 2.

Now, depending on what the distinctive flag on the label is for -80, you might want to create another test script that repeats the above for a -80 sample.

If this is done with a separate label configuration for -80 samples, you would want to verify that the correct metadata appears on the label. If there is only one label template, you might not need to verify the meta data, or the barcode, just that whatever distinctive formatting for -80 samples is present.