From Charing Wong, SE2009:

  Here're some thoughts in bullet points - not particularly coherent :P

  *General thoughts*:

  Unfortunately, it's a little far back now, so thoughts are fuzzy.

  From what I can recall, the biggest thing that jumped out to do was
  that the requirements (made up by the TA?) felt artificial
  
  In the real world, it's hard to "collect requirements" when you
  don't have a person experiencing a real problem that needs to be
  solved.
  
  Nowadays, I dislike the term "collecting
  requirements". Users/Customers don't know what software is capable
  or incapable of, generally. They can't "give" you requirements. They
  tell you their problems - you figure out what is required.

  *What I do at work when figuring out requirements*:

  At work, when I need to figure out what needs to be built, I talk to
  users about their problems - I literally post on facebook
  groups/craigslists to find the right users, and then schedule half
  hour phone calls to casually ask about their current experience with
  something. And from there figure out what problems we want to go
  after, and what our goals are.
  
  After a few sessions of these, you sort of have a sense of what
  things could be interesting
  
  You start mocking up ways you can solve this - a simple end-to-end
  flow (while keeping the problems + goals in mind)
  
  Then you can start to figure how to model this (what's the data model,
  what stack, how to structure API, how all of this plugs in with
  existing code, etc). UX drives technical requirements.
  
  This differs across companies, but I do think that thinking ahead
  about what to build and writing a short doc about how you choose to
  approach it has been useful.

  *What I would change about the course*:

  Find a way to talk to real users who have a real problems - teach
  them to be scrappy if needed when . doing user research (e.g. use
  craigslist, post on facebook, put up posters in SLC, who knows)
  
  Emphasis that the "SRS" is living document - requirements change all
  the time. It's not like a work-term report, and don't worry about
  writing it in a very formal way. Most of our specs/dev docs are
  fairly lightweight and are done in google docs or just in markdown
  in github. We write as much as need to communicate the idea. In
  fact, most of the designing happens on whiteboards, that are then
  written down later in docs for sharing.