Software Engineering

• This is _not_ a course on SE
• Different companies do this differently
• The important thing is that there is a plan (and not just random flailing about / putting out the currentely biggest fire)
• We'll be using one approach in this class
  • So that I've got an idea of what to expect from you
  • You're allowed to reasonably deviate, but the further you go the more likely it'll be that what you & I think it reasonable will diverge (which will cost you points)

SRS - Software Requirement Specification

• The goal here is to have a document that clearly specifies what the program needs to do
  • Does NOT specify how the program will do it
  • Does NOT specify what the program will look like, etc
    • The Software Design Doc (SDD) spells out what the software looks like
  • When you're actually coding stuff up & you're not sure what to do (and the Design Doc isn't helpful) this will (hopefully) help you figure out what the answer is
    • And if it doesn't then you talk to the customer again
• Signed off by the customer & you
  
• You don't need to do a 30 page doc for this class
• You're allowed to copy parts of the example, but only if you're super-clear about which parts
  • I'd recommend visually identifying the parts - blue or green highlight, bold red text, etc
    
• Let's look at the example linked to on the website
  • 1.1 - Purpose
    • Specifically says it'll be for customer + devs
  • 1.2 - Scope of Project
  • 2.2 - Use cases
    • This & the functional requirements spell out how the program will be used
  • Requirement types
    • Functional requirements: Something that the software does
    • Non-functional requirements; something that has to be true (wikipedia link) - stuff like 'it's secure',