About Software Requirements In General
From UG
(→KW2) |
|||
| Line 42: | Line 42: | ||
http://en.wikipedia.org/wiki/Unified_Modeling_Language | http://en.wikipedia.org/wiki/Unified_Modeling_Language | ||
| + | |||
| + | http://en.wikipedia.org/wiki/Requirements_analysis | ||
Revision as of 20:33, 26 January 2010
Contents |
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]
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?"
Less detail needed
- customers are extensively involved
- developers have considerable domain experience
More detail needed
- development will be outsourced
- project team members are geographically dispersed
- testing will be based on requirements
Duplicate or not to duplicate?
In most cases - no. Keep each in separate place and provide links.
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.
Defining the project scope
The baseline
References
KW1
Software Requirements. Karl E. Wiegers. Microsoft Press
KW2
More about Software Requirements. Karl E. Wiegers. Microsoft Press
http://en.wikipedia.org/wiki/Requirement
