Formatteed markdown
This commit is contained in:
parent
26c8ad888a
commit
131a792853
@ -1,10 +1,17 @@
|
||||
# Feature Set
|
||||
|
||||
Line-by-line Instructions
|
||||
Features by Release and Priority
|
||||
## Line-by-line Instructions
|
||||
|
||||
### Features by Release and Priority
|
||||
|
||||
The advantage of this feature set organization is that it visualizes the overall sequence of work on features across releases. It also provides a visually clear way to manage the scope of a release by slipping features into a later release: the lowest priority features in one release are simply moved down the list into a later release.
|
||||
Features by Release and Risk
|
||||
|
||||
### Features by Release and Risk
|
||||
|
||||
This feature set organization helps to visualize and manage the risk to the success of the project that is inherent in the scope of each release. If a given release has too many risky features, it will be impossible to have confidence in the schedule. It is better to understand the amount of risk in each release and slip some risky features to later releases.
|
||||
Features by Feature Area
|
||||
|
||||
### Features by Feature Area
|
||||
|
||||
This is a logical organization of features into feature areas. Each feature area is a group of features that help users accomplish a related set of tasks that support a claimed benefit of the product. For example, if one of the claimed benefits of page layout application is the ability to import and export graphics in standard formats, then all of the individual import and export features will be in the "import/export" feature area.
|
||||
|
||||
It is useful to visualize features by feature area as a way to estimate the amount of support given for each claimed benefit. Continuing the page layout application example, if there are no import/export features, then the claimed benefit is not supported. Likewise, if there are far too many import/export features, that indicates that a redesign may be needed.
|
||||
|
@ -1,11 +1,19 @@
|
||||
# Use Case Suite
|
||||
|
||||
Line-by-line Instructions
|
||||
Use Cases by Feature Area
|
||||
## Line-by-line Instructions
|
||||
|
||||
### Use Cases by Feature Area
|
||||
|
||||
This organization of the use case suite is useful because it visually shows coverage of the set of features. Any feature area that is too few use cases may be under-specified and need more work to fully specify it.
|
||||
Use Cases by Stakeholder
|
||||
|
||||
### Use Cases by Stakeholder
|
||||
|
||||
This organization of the use case helps to make sure that you have understood the needs of all classes stakeholders and users. If there is any class of user that doe not have as many use cases as you feel are needed, you can clearly see that and realize that you must add more use cases.
|
||||
Use Cases by Priority
|
||||
|
||||
### Use Cases by Priority
|
||||
|
||||
This use case suite organization highlights the most important use cases for this release. Development, documentation, and quality assurance efforts could be focused on these use cases.
|
||||
Use Cases by Business Object and Actor
|
||||
|
||||
### Use Cases by Business Object and Actor
|
||||
|
||||
This grid organization helps you to visually recognize missing use cases. For each cell in the table, ask youself "what does user X do with business object Y?". If the answer is "nothing", then write "N/A". If the answer is something, note down the names of some use cases. If the user does do something with that business object, but you don't know what that is, write "TODO" as a reminder to come back to that cell.
|
||||
|
Loading…
Reference in New Issue
Block a user