Parts of this can be a kind of reuse, if good specifications already exist 

• Suggest modifications to the original specification (upstream first principle)
• Treat it as an open source project and make a fork.  
  • Several aspects to consider:
  • License conditions must allow it, of course
  • Good citizen / good behavior
  • Usefulness of specification will reduce if there is confusion between versions
  • → Rarely is this a good approach!
    
    
• Reuse parts of the specification as a whole and rewrite others
• Reuse with references and modifications
  
  

If modification "upstream" is not feasible then reuse through references plus additional information is a useful compromise.

This is a very useful way to create a formal specification that fits exactly to ones needs while avoiding proliferation of multiple overlapping documents.  It is a kind of "meta-specification" that is one level above and refers to others.  (Normally a "meta-specification" probably means a specification that defines how specifications should be written, so perhaps there is a better name for this).

1. Each chapter should define the requirements by minimal repetition, by referring to already written text
2. Sometimes, for clarity some copying/repetition is desired overriding rule 1
3. Modifications can be done by adding additional text that slightly changes what the original spec requires.  This still avoids repeating a lot of the major work that went into the original.
4. In particular things like "optional" and "mandatory" can be modified
   
   

Automotive Virtual Platform Specification, verxion x

1. Introduction

         Follow chapter x.y in [VIRTIO] ← this is reference to a particular version of course) .

2. Architecture

Assumptions made about the architecture, use-cases.

Limits to applicability, etc.

3. General requirements

Automotive requirements to be met (general)

3. Virtual Device Requirements

3.1 Serial Device

3.1.1 Standard Serial Device

REQ-1:   Follow chapter x.y in [VIRTIO]

3.1.2 Network device exposed as serial device

For this special type there are some additional requirements.

REQ-2:  The virtual device MUST provide an auxiliary programming interface (e.g. ioctl on POSIX) with the following feature:        

•               .... blah

3.2 Block Device

REQ-3:   Follow chapter 4.5.6 in [VIRTIO] plus chapter 4.2.1 in [Other spec]

REQ-4:   For the case when there are conflicting requirements (note: disk performance, chapter 4.9.9), the requirement in [Other spec] shall take precedence.

REQ-5:   Device type FOO listed as optional, shall be mandatory.