Vous êtes sur la page 1sur 8

Understanding Requirements

Chapter 5 Applying UML and Patterns -Craig Larman

Requirements
These

are the capabilities and conditions that the system, the project, and the product must provide and meet Managing re!uirements is a best practice "or project managers #e!uirement issues are the leading cause o" project "ailure $ven i" you do a per"ect job o" building the %rong thing, its no good&

Not Waterfall Requirements


There

is an attempt in the %ater"all method to describe the re!uirements "ully and accurately and '"ree(e) them Uni"ied process reali(es that change is constant, so plans "or change instead o" setting an impossible goal

Managing Requirements
*ta+eholder

re!uirements are "re!uently unclear and change over time ,re!uently ne% re!uirements are discovered as part o" the development process There must be a 'systematic approach to "inding, documenting, organi(ing, and trac+ing the changing re!uirements o" a system ) -#UP.

FURPS+
Functional

-"eatures, capabilities, security. Usability -human "actors, help, documents. Reliability -"ailures, recovery, predictable. Per"ormance -response, throughput, etc. Supportability -maintainability, con"iguration. + ancillary and sub-"actors -ne/t slide.

Ancillary and sub-factors


0mplementation 0nter"ace 1perations Pac+aging Legal

-includes limitations.

#e!uirements

Functional Requirements
2etailed

in the Use Case Model and in the *ystem ,eatures list o" the 3ision arti"act They are speci"ied in detail in 1peration Contracts %here necessary

Non-functional requirements
1"ten

called the '-ilities) o" a system4 !uality, reliability, usability, per"ormance, etc The glossary, data dictionary and supplemental speci"ications describe many non-"unctional re!uirements 0n addition, architectural documents may have non-"unctional re!uirements

Vous aimerez peut-être aussi