About Software Requirements In General
From UG
| Line 1: | Line 1: | ||
[[Category:Business Analysis]] | [[Category:Business Analysis]] | ||
| + | [[Category:Documentation]] | ||
== What language? == | == What language? == | ||
Current revision as of 01:04, 8 February 2010
Contents |
[edit] What language?
"Despite its shortcomings, structured natural language, augumented with graphical models, remains the most practical way for most software projects to document their requirements" [#KW]
[edit] How much details?
Depends on who do you want to make decision about R details and when. You need to balance cost and risk. It takes more time and cost more to develop R /document R in greater detail.
The requirements maybe vague but the product will be specific.
Ask customer: "If you do not want to make these decision now, who do you think should make them and when?"
[edit] Less detail needed
- customers are extensively involved
- developers have considerable domain experience
[edit] More detail needed
- development will be outsourced
- project team members are geographically dispersed
- testing will be based on requirements
[edit] Duplicate or not to duplicate?
In most cases - no. Keep each in separate place and provide links.
[edit] The fuzzy line between Requirements and Design
Often said: R is about what you build and D is about how you build. Specific design imposes constraint.
[edit] Defining the project scope
[edit] The baseline
[edit] References
[edit] KW1
Software Requirements. Karl E. Wiegers. Microsoft Press
[edit] KW2
More about Software Requirements. Karl E. Wiegers. Microsoft Press
http://en.wikipedia.org/wiki/Requirement
