Use cases are not necessarily the only way one needs to express functional requirements: - They are detailed. Stakeholders often want a short summary that identifies the most noteworthy functions.
- Simply listing the use case names often long and can obscure noteworthy functions
- Some noteworthy functionality is naturally expressed as short statements that do not conveniently map to use case names or Elementary Business Process-level goals. F.e.: Middleware API
System Features - Functional Requirements (cont.) UP definition of the system feature: An externally observable service provided by the system which directly fulfills a stakeholder need Features are things a system can do. They should pass this linguistic test: The system shall do Vision may be used as a formal or informal contract between development and business. System features are a mechanism to summarize in this contract what the system will do. This is complementary to the use cases, as the features are terse. Most system features will find detailed expression in use case text. Notation and Organization First and foremost, short high-level descriptions are important. One should be able to read the system features list quickly. It is common to organize a two-level hierarchy of system features. In the Vision document more than two levels leads to excessive detail; the point of system features in the Vision is to summarize the functionality, not decompose it into a long list of fine-grained elements. Sometimes, these second level features are essentially equivalent to use case names (or user-level goals), but that is not required; features are an alternative way to summarize functionality. Nevertheless, most system features will find detailed expression in the use cases.
Do'stlaringiz bilan baham: |
