Consequently, it is not reasonable to expect us to make sound business or technical decisions on behalf of the customers, or to resolve conflicting requirements supplied by different end users, or to set priorities for the many requirements that might be collected.
The consequence of not explicitly discussing these quality tradeoffs is a surprise upon delivery, when the customer finds that his implicit quality attribute requirements have not been achieved
One way to reach an appropriate middle ground in the specification process is to conduct formal inspections of the SRS. A structured document like the IEEE SRS is readily inspected by the design team, the project champions, other representative users, and other software engineers who are not directly involved with the project
sadly, this is something that is always left to the end to 'clean up'. Meaning, the spec is complete when the project is delivered versus kept up to date and in sync with what we are delivering.
A prototype is intended to answer specific questions about functionality or interaction styles. If you don't have any questions, don't bother with a prototype
Even in a small software group, a focus on accurately and completely capturing, documenting, and modeling the user requirements is a major contributor to building high quality information systems
I shouldn’t need to go into this one but to be thorough I like this definition of security: the measure of system’s ability to resist unauthorized attempts at usage or behavior modification, while still providing service to legitimate users.