Program Requirements

• References
  • This article seems a gentle introduction.
  • A wikipedia article
  • The IEEE Software Requirement Specification Template in markdown.
  • Or a Word version
• This is a major software engineering topic.
  • You should cover this in real detail in
    • Software engineering (Theoretical, Application)
    • Senior project in [Game/Web/Systems Admin]
• This is the task of figuring out what the program needs to do.
  • Not so much at the algorithm level
  • More at the task level.
  • Answer the questions
    • What does the software need to do?
    • In what environment does the software need to run?.
  • From the first article "The typical outcome of incomplete requirements is a huge gap between what the developers think they are supposed to build and what the users think they will get. "
  • Two types of requirements
    • Functional Requirements: what does the product need to do.
      • What are the business rules that apply?
    • Non-Functional Requirements:
      • What other conditions apply
  • Take a quick look at the IEEE SRS template
    • Section 1 is an overall definition of the project. While that is important now, I think 1.1 and 1.4 would be the most important portion for us right now.
    • Section 2 describes the project in more detail
      • Section 2.2 is really the most important part for the type of project we are discussing now.
      • What does the product need to do?
      • 2.4 and 2.5 do come into play as well. Especially in the context of a course.
      • In your world 2.7 should not be an issue
        • Unless you delay design until the last minute
        • Or do no design work.
        • You should have no assumptions, they should be cleared up by questions at the beginning of class or in person.
    • Section three is about interaction.
      • Again, this should be looked at, but you probably will have minimal interactions at this level.
    • Four is really an extension of 2.2
      • If the features/functions are more than skin deep, a reasonable explanation of each is useful.
    • Section five is probably not something you need to consider too deeply
      • You always have code quality expectations.
  • What should you do at this level?
    • Read the project description several times well BEFORE you start to code.
    • Make a three/four part document
      1. What is the big idea?
      2. What are the things the program needs to do? (Functional Requirements)
         • List these carefully enough that you can refer back to them when you are designing/coding.
         • This is the requirement phase portion where I find I take off the most points. Programs don't do what I ask in the description.
      3. What special considerations should I be aware of? (Non-functional Requirements)
         • I would note I/O here.
         • This is the second most portion of requirements likely to lead to point deductions.
           • If there is example I/O in the description, follow it.
      4. What questions need answered? Ambiguities?
  • The article states that good requirements are
    • Complete - they very thoroughly describe the criteria
    • Correct - they are accurate and true
    • Feasible - they can be accomplished and individual requirements do not contradict each other.
    • Necessary - they are truly needed for the system to function properly and they are really what the client wants.
    • Prioritized - in the case that not all parts of the system can be implemented at the same time, it's important to be able to distinguish "absolutely necessary" from "nice to have".
    • Unambiguous - they are clear and cannot be misinterpreted
    • Verifiable - once implemented, it can be confirmed that the system has met the requirement through observation and testing
  • Some of these lead directly to design/testing.
  • The section on gathering requirements can be somewhat ignored, your client base is very small.
  • This is somewhat minimalist, but will do for this class and probably the next.