About Software Requirements In General

From UG

Revision as of 15:29, 25 January 2010 by Alex (Talk | contribs)
Jump to: navigation, search


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

Personal tools