Understanding Requirements: Applying UML and Patterns - Craig Larman
Understanding Requirements: Applying UML and Patterns - Craig Larman
Understanding Requirements: 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&
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.
-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