Our standard format has heading as follows: - Page 1 - Front Cover Page, with boxes for sign-off of approvals. Page 2 - blank Page 3 - Change Record, giving issue no., date and description of change Page 4 - blank Page 5 - Contents page Page 6 - blank Page 7 - Section 1 - Introduction This will have a brief description of the reason/basis for the document. Section 2 - Acronyms In this age of TLAs, TLAs, and FLAs (and more) it is worth making sure ever= yone is using the same meaning for whatever abbreviations and acronyms you = use. Section 3 - Reference Documents This will contain a list of documents that have requirements you need to wo= rk to. E.G. mechanical arrangements, connector types called out, signal interfaces= etc. Section 4 - Requirements Set out the requirements of what you are going to design. There may be several subsections in here, each dealing with a different asp= ect, e.g. inputs, outputs, mounting requirements, heat dissipation. This should also have references to the Reference Documents in section 3 as= the basis for what you are doing. Sometimes we may also have an Applicable Documents section after the Refere= nce Documents as being documents from which you may glean information, e.g.= wire current carrying capacity, derating when wires are bundled, etc. You may end up with other section headings as well, along with Appendices f= or data sheets, mechanical drawing of your enclosure, or other relevant in= formation.=20 If the document is always going to be in electronic form then you may wish = to do away with the blank pages. -----Original Message----- From: piclist-bounces@mit.edu On Behalf Of Ruben = J=F6nsson Sent: 19 November 2019 14:33 To: piclist@mit.edu Subject: Re: [EE] How to write a requirements document for a PCB that is pa= rt of a larger system? =09   Write the requirement source e.g. Standard, User Need, Commercial, Ris= k Management (if you have that). Link the requirement to other references like other requirements (SW a= nd/or HW req.), Risk Control Measure No. and Standard and clause. If you specify a numeric value for a requirement, specify the unit and a to= lerance. Write simple requirements, don't concatenate several requirements into one. Write it so you can use it for validation/verification Give each requirement an ID that you can use for traceability.  Den Tue, 19 Nov 2019 09:06:50 +1100, James Cameron <quozl@laptop.org>= skrev: Path of least resistance was often to grab the headings from a previous req= uirements document and then fill in the gaps. At DEC CSS we had an ISO9001 mediated documentation standard which gave min= imum contents of controlled documents like requirements analysis. Most interesting (to me) was how the phrasing and tense changed between req= uirements, design, and detailed design. But for Jason, I've no resources to refer to. I could only guess or worksho= p what was needed; physical dimensions, environment, mass, interconnectors = position and specifications. Organisation could be an ordering based on how critical the requirement is,= or the units the requirement has, or the test phase at which the requireme= nt is assessed. On Mon, Nov 18, 2019 at 08:59:46PM +1300, RussellMc wrote: > Any input from anyone on this from a few days back? > > Looks like a useful question which some are liable to have experience = in. > > > Russell > > On Fri, 15 Nov 2019 at 04:11, Jason White > wrote: > > > Hello everyone, > > > > I would like to know if anyone has advice for, or can recommend r= esources > > on, writing high level/system level requirements for PCB= s that are part of > > larger systems? How might one go about organiz= ing the document? > > > > For reference: I'm an electrical engineer in company A. I'm desig= ning a > > controller PCB for an electromechanical assembly designed = by mechanical > > engineers at company B. This is avionics and there = are lots of requirements > > coming from many different regulatory st= andards and control drawings. Good > > document organization and "con= ceptual integrity" is the goal. > > > > -- > > Jason White > > -- > > http://www.piclist.com/techref/piclist PIC/SX FAQ & list arch= ive > > View/change your membership options at > > http://mailm= an.mit.edu/mailman/listinfo/piclist > > > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive &= gt; View/change your membership options at > http://mailman.mit.edu/mail= man/listinfo/piclist -- James Cameron http://quozl.netrek.org/ -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/c= hange your membership options at http://mailman.mit.edu/mailman/listinfo/pi= clist Path of least resistance was often to grab the headings from a previous req= uirements document and then fill in the gaps. At DEC CSS we had an ISO9001 mediated documentation standard which gave min= imum contents of controlled documents like requirements analysis. Most interesting (to me) was how the phrasing and tense changed between req= uirements, design, and detailed design. But for Jason, I've no resources to refer to. I could only guess or worksho= p what was needed; physical dimensions, environment, mass, interconnectors = position and specifications. Organisation could be an ordering based on how critical the requirement is,= or the units the requirement has, or the test phase at which the requireme= nt is assessed. On Mon, Nov 18, 2019 at 08:59:46PM +1300, RussellMc wrote: > Any input from anyone on this from a few days back? > > Looks like a useful question which some are liable to have experience = in. > > > Russell > > On Fri, 15 Nov 2019 at 04:11, Jason White > wrote: > > > Hello everyone, > > > > I would like to know if anyone has advice for, or can recommend r= esources > > on, writing high level/system level requirements for PCB= s that are part of > > larger systems? How might one go about organiz= ing the document? > > > > For reference: I'm an electrical engineer in company A. I'm desig= ning a > > controller PCB for an electromechanical assembly designed = by mechanical > > engineers at company B. This is avionics and there = are lots of requirements > > coming from many different regulatory st= andards and control drawings. Good > > document organization and "con= ceptual integrity" is the goal. > > > > -- > > Jason White > > -- > > http://www.piclist.com/techref/piclist PIC/SX FAQ & list arch= ive > > View/change your membership options at > > http://mailm= an.mit.edu/mailman/listinfo/piclist > > > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive &= gt; View/change your membership options at > http://mailman.mit.edu/mail= man/listinfo/piclist -- James Cameron http://quozl.netrek.org/ -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/c= hange your membership options at http://mailman.mit.edu/mailman/listinfo/pi= clist   -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/chang= e your membership options at http://mailman.mit.edu/mailman/listinfo/piclis= t --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .