ECE3091:  Engineering  Design      

Lecture  2,  Week  2      

Documenta;on  

Overview:  There  are  varying  types  of  documenta;on  that  can  be  applied  generally  in  the  engineering  environment,  to  any  project.    Those  applied  specifically  to  this  unit:  • Requirements  analysis    • Design  specifica;ons    • Final  report(including  schema;cs  and  code)    • On  line  wiki      Specific  unit  requirements  for  final  report,  requirements  analysis  and  design  specifica;ons  will  be  given  in  later  lectures  and  via  blackboard.  

Documenta;on:  The  wri(ng  of  proposals,  reports,  manuals,  procedures,  papers  etc  is  an  essen(al  part  of  the  engineer’s  role.      There  are  many  types,  including:  • Laboratory  /test  reports  • Proposals  –  seek  a  contract,  funding,  approval  for  a  project,  compe((ve  tendering,  promo(ng    a  project,  yourself  or  your  company  • Specifica(ons  –  detailed  requirements  and  descrip(ons  (design,  func(on,  opera(on,  construc(on)  • Progress/status  reports  –  summarise  progress  to  date,  problems,  cos(ng  etc  

 There  are  no  par(cular  standards  for  document  names,  styles  or  formats:      • Determine  user  requirements  for  documenta(on  

• Write  according  to  audience  needs  in  terms  of  both  format  and  content  

• Find  out  your  company  requirements  –  templates,  conven(ons,  internal  standards,  view  samples    So,  the  key  is  to  find  out  what  is  required.  

In  addi(on  to  required  content,  need  to  iden(fy  required  format  ,  such  as:    • Structure  –  sec(ons  

• Organiza(onal  details  –  page  numbering  system,  headers/footers,  headings  

• Fonts  and  white  space  –  margins,  paragraphing  

• Graphical  elements  –  use  of  figures,  tables,  equa(ons,  lists  etc  

• Referencing  –  style  (IEEE,  Harvard)  

Reports:    A  design  project  is  not  complete  if  the  results  are  not  communicated  to  the  client/stakeholders  –  it  is  an  essen(al  part  of  the  project.      Purpose  is  to  inform  client  of  the  design,  project  results  and  give  descrip(on  of  outcomes.      There  are  various  types  and  styles  of  reports,  most  including  drawings  and  diagrams.  

Reports  are  required  at  various  stages  in  the  progress  of  a  project:    • Prior  to  start:  problem  statement,  proposal  –  requirements  specified  

• At  the  start  of  the  project  –  design  specifica(on/brief  

• During  project  –  progress/status  reports  –  varia(ons,  problems  

• At  comple(on  of  project  –  full  detail  of  project:  reiterate  requirements  and  specifica(ons,  demonstrate  their  achievement,  display  concept  defining  documenta(on,  detailed  code  and  calcula(ons.  

Repor(ng  should:      •  Be  thorough  and  precise  

•  Communicate  ideas  and  concepts  clearly  

•  U(lise  graphic  visualisa(on      -­‐  drawings  and  diagrams.  

Proposals:  • Must  convince  the  recipient  that  the  proposer  is  the  right  person  or  organisa(on  to  carry  out  the  project.  Aims:  • Clarify  objec(ves  –  address  client  problem  statement  .  • Detail  user  requirements  • Iden(fy  design  constraints  • Establish  func(ons  for  design  • Iden(fy  design  alterna(ves  • Establish  design  specifica(ons  • Model/analyse  design  • Test/evaluate  design  • Refine  /op(mise  design  • Document  completed  design  

Include:  • LeXer  of  transmiXal  –  brief  explana(on  of  nature  and  scope  of  proposal  • Title  page  –  descrip(ve  (tle,  team  members,  recipients  • Execu(ve  summary  • Table  of  contents  • Introduc(on  –  ra(onale,  problem  statement,  background  • Project  overview  –  conceptual  overview  • Design  solu(ons  –  alterna(ves  considered,  proposed  project  described  • Sources  of  informa(on  • Budget  and  funding  • Schedule/(ming  • Team  organisa(on  • Company  profile  • Conclusion  • References  

Progress  reports:    Vital  part  of  project  communica(on    Compare  ini(al  plan  to  actual  performance  to  date    Update  on  resource  use  and  costs    Includes  GanX  charts    Various  formats.  

Manuals:  • Part  of  product    (product  liability)  which  can  determine  its  usefulness  and  safety.  • Includes  descrip(on  of  product  and  instruc(ons  for  use  and  maintenance.  • Must  be  clear  and  easy  to  use  –  technical  descrip(ons  need  to  be  in  straigh[orward  ,  simple  language,  u(lising  diagrams  where  relevant.  • Start  to  prepare  the  manual  during  the  development  and  tes(ng  phases  of  the  project  when  problems  are  faced  and  resolved.  • Focus  on  needs  of  the  reader/user  –  see  the  manual  from  the  users  point  of  view  and  design  content  to  suit.  

Contracts:    •  Include  specifica(ons,  drawings,  cos(ng,  (ming.  

•  Must  be  documented  clearly  with  no  risk  of  ambiguity  or  misunderstanding.  

•  Technical  terms  should  be  defined.  

Specifica;ons:  A  form  of  documenta(on  that  specifies  requirements,  design,  tes(ng  etc  of  the  project.    • Gives  key  technical  details  –  quality  of  work/materials,  performance  standards,  measurable  and  achievable  outcomes  • O\en  associated  with  an  external  contract  so  accuracy,  precision  of  detail  and  clarity  are  cri(cal.  • Needs  to  be  factual  but  readable  to  avoid  misunderstandings  • Poorly  wriXen  specifica(ons  can  cause  a  range  of  problems  and  lead  to  lawsuits.  • Find  out  requirements  and  focus  on  audience  

   

Journals:    Aim  is  to  promote  a  scien(fic  and  systema(c  approach  to  work  completed.        Keeping  a  journal  helps  to  develop  good  design  prac(ces  and  is  useful  for  tracking  and  analysing  thinking  and  planning  as  you  progress  through  the  stages  of  the  design  process.    In  business  you  cannot  rely  on  memory  and  require  documenta(on  for  legal  verifica(on.  Informa(on  included  or  le\  out  can  be  vital  to  a  company’s  situa(on  rela(ng  to  proof,  project  control,  contract  details  etc.    

The  journal/diary:  

• Must  be  kept  up  to  date  –  able  to  be  accessed  by  management  or  client  at  any  (me.  Most  project  managers  keep  a  daily  journal/log  • Must  be  client  focussed  –  refer  directly  to  client  needs  and  specifica(ons  • Must  provide  an  audit  trail  –  what  has  been  done,  when  it  has  been  done,  by  whom,  outcomes  derived  –  must  be  traceable  • Will  be  used  for  verifica(on  • Is  cri(cal  for  patent,  registered  design,  copyright    -­‐  needs  dates  and  complete  details  to  protect  intellectual  property.  • Must  stand  up  to  inves(ga(on  –  i.e.  forensic  IT.  No  date  tampering!    Dates  form  the  basis  for  claiming  patentable  ideas  

Content:    Write  anything  that  could  poten(ally  affect  job  comple(on,  performance,  cost,  quality,  profitability.    Anything  that  could  become  an  issue  should  have  a  full  wriXen  record  in  journal.    Problem:  how  do  you  know  what  could  become  an  issue?    Must  be  formal,  specific,  detailed,  relevant  and  individual  and  include  details  such  as:  •  Date  •  Task  •  What  has  been  accomplished  •  By  whom  (collaborators)  •  Code,  diagrams,  charts,  photographs,  designs,  plans  

OHS  Documenta;on:    Required  for  Risk  Control    •  Risk  assessment  •  Reference  sheets  •  Examples  of  risks  

•  Is  a  form  of  legal  documenta(on  required  in  all  workplaces  for  all  projects  and  must  be  completed  and  stored  correctly.  

Referencing:  Almost  every  document  that  you  write  is  based  in  some  way  on  the  work  of  others.    You  must  acknowledge  this  by  either  including  an  acknowledgement  in  the  acknowledgements  sec(on  of  a  report,  by  using  footnotes  (usually  to  expand  on  an  idea)  or  by  using  formal  referencing.    Purpose  of  referencing:  • Protect  originator  –  give    credit  • Protect  yourself  from  accusa(ons  of  plagiarism  • Demonstrate  you  have  researched  the  latest  material  • Enable  reader  to  track  informa(on  –  go  to  source.  

Formal  referencing:  • Based  on  laws  of  copyright  and  professional  ethics  

• Require  you  to  acknowledge  your  reliance  on  other  people’s  ideas  whether  you  quote  their  words  or  use  your  own.  

• There  are  varying  conven(ons  for  ci(ng  sources  –  find  which  is  required  and  follow  the  style  guide  for  each  source.  

For  example  :  IEEE  referencing  for  electrical  and  electronic  engineers  cites  numbers  throughout  document  then  lists  sources  by  number  at  the  end  of  the  document.  

   hXp://www.eng.monash.edu.au/current-­‐students/download/using-­‐author-­‐date-­‐system.pdf          hXp://www.eng.monash.edu.au/current-­‐students/download/using-­‐ieee-­‐system.pdf          hXp://www.eng.monash.edu.au/current-­‐students/download/why-­‐reference.pdf          hXp://www.lib.monash.edu.au/tutorials/ci(ng/  

Summary:    •  There  are  many  resources  and  examples  available  for  

your  use.  •  Develop  good  prac(ces  and  a  systema(c  approach    •  (  i.e.weekly  wiki  entries)  •  Use  documenta(on  to  track  project  status  as  well  as  

for  permanent  record.  •  Detail  will  be  provided  on  the  par(cular  guidelines  

for  wri(ng  the  assessed  pieces  of  documenta(on  (requirements  analysis  and  design  specifica(on)  

•  A  later  lecture  will  be  given  detailing  the  required  format  for  the  final  report.  

Useful    resources:    C.Dym  andP.  LiXle  ‘Engineering  Design’,  USA,  John  Wiley  and  Sons  Inc  ,  2000    D.Beer  and  D.McMurray  ‘A  Guide  to  wri4ng  as  an  engineer’,  2nd  ed,  USA,  John  Wiley  and  Sons  Inc,  2005    J.Davies  ‘Communica4ng  for  engineering  students’,  UK,  Longman,  1996    S.Stevenson  and  S.Whitmore    ‘Strategies  for  engineering  communica4on’,  USA,  John  Wiley  and  Sons  Inc,  2002