About Software Requirements In General

From UG

(Difference between revisions)
Jump to: navigation, search
 
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

http://en.wikipedia.org/wiki/Unified_Modeling_Language

http://en.wikipedia.org/wiki/Requirements_analysis

Personal tools