About Software Requirements In General
From UG
(Created page with 'Category:BA/SA == Misc == "Despite its shortcomings, structured natural language, augumented with graphical models, remains the most practical way for most software project…') |
|||
| (8 intermediate revisions not shown) | |||
| Line 1: | Line 1: | ||
| - | [[Category: | + | [[Category:Business Analysis]] |
| + | [[Category:Documentation]] | ||
| - | == | + | == 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] | "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 == | == References == | ||
| - | === | + | === KW1 === |
Software Requirements. Karl E. Wiegers. Microsoft Press | Software Requirements. Karl E. Wiegers. Microsoft Press | ||
| + | |||
| + | === KW2 === | ||
| + | More about Software Requirements. Karl E. Wiegers. Microsoft Press | ||
| + | |||
| + | |||
| + | http://en.wikipedia.org/wiki/Requirement | ||
| + | |||
| + | http://en.wikipedia.org/wiki/Unified_Modeling_Language | ||
| + | |||
| + | http://en.wikipedia.org/wiki/Requirements_analysis | ||
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
