Add details about Chipmunk's NFRs.

[Mornix]

(Issue #53)

First version of nonfunctional requirements for Chipmunk. Most of the changes in the SRS PDF begin on the bottom half of page 25 and end on the top half of 26.

The nonfunctional requirements are missing a correctness section as I'm still not quite sure what correctness is referring to in this case.

[smiths]

@Mornix, I apologize for the lengthy delay in responding to this review request. I like the direction in which you are going, but I still have some feedback that I would like you to address:

• NFR1 and NFR2 are too specific. "Calculate a step of the simulation involving 1000 rigid bodies in no more than 1 s on 60 minimum hardware (NFR9)" sounds good, but it is not an abstract requirement. What you are giving is the performance that you think is necessary to get at the "real" nonfunctional requirement. The real nonfunctional requirement will be something like "Users perceive the physical simulations to be smooth and uninterrupted." This new requirement is ambiguous, so we need some means to make it unambiguous. We could use a fit criteria, like in the Volere template. The new requirement might be something like: "At least SATISFIED_USERS percent of surveyed users find the simulations in the set of BENCHMARK_TESTS to be smooth. The surveyed users will meet the minimum hardware requirements." SATISFIED_USERS and BENCHMARK_TESTS are symbolic constants that would be defined in a section at the end of the document.
• NFR3 and NFR4 "Provide interface documentation generated from the code." is not really a nonfunctional requirement. Providing documentation is a functional requirement on the process used to create the software. The requirements are for users, so being able to generate the documentation isn't really a user level requirement. As for performance, you want something that is abstract and unambiguous for understandability. Again, you could consider phrasing the requirement with respect to a user survey.
• NFR5 to NFR7 these seem like reasonable requirements, except that they are ambiguous. What does "Run" mean? I think we could use something like BENCHMARK_TESTS as a reference to what we mean by running.
• NFR9 isn't a nonfunctional requirement. Rather than state it this way, I think we could introduce the minimum system requirements as a symbolic constant, similar to BENCHMARK_TESTS.
• NFR10 - I think the reliability requirement could also be made abstract and unambiguous. Again, I think this involves referencing test cases in some way.
• NFR11-NFR13 - These requirements are a means to achieve Maintainability, they aren't actually the abstract statement that we are looking for. I always find Maintainability a difficult one to specify. At the moment, my thinking is a statement like: "Completing any of the likely changes (Section 6) should take less than DEV_TIME_FRACTION of the original development time."