=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 requirements document and then fill in the gaps. At DEC CSS we had an ISO9001 mediated documentation standard which gave minimum contents of controlled documents like requirements analysis. Most interesting (to me) was how the phrasing and tense changed between requirements, design, and detailed design. But for Jason, I've no resources to refer to. I could only guess or workshop 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 requirement 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=20 > 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 PCBs that ar= e part of > > larger systems? How might one go about organizing 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 mech= anical > > engineers at company B. This is avionics and there are lots of re= quirements > > coming from many different regulatory standards and control drawi= ngs. Good > > document organization and "conceptual 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://mailman.mit.edu/mailman/listinfo/piclist > > > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist -- James Cameron http://quozl.netrek.org/ -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist Path of least resistance was often to grab the headings from a previous requirements document and then fill in the gaps. At DEC CSS we had an ISO9001 mediated documentation standard which gave minimum contents of controlled documents like requirements analysis. Most interesting (to me) was how the phrasing and tense changed between requirements, design, and detailed design. But for Jason, I've no resources to refer to. I could only guess or workshop 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 requirement 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=20 > 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 PCBs that ar= e part of > > larger systems? How might one go about organizing 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 mech= anical > > engineers at company B. This is avionics and there are lots of re= quirements > > coming from many different regulatory standards and control drawi= ngs. Good > > document organization and "conceptual 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://mailman.mit.edu/mailman/listinfo/piclist > > > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist -- James Cameron http://quozl.netrek.org/ -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist   --=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 .