When someone joins the project, it is useful to be able to say, "Welcome! Please go read the 7 - page Vision at the project website." It is also useful to have an executive summary that briefly describes the project, as a context for the major players to establish a common vision of the project.
The Vision should not be long, nor should it attempt to describe firm requirements in detail. And it should summarize some of the information in the Use - Case Model and Supplementary Specification.
The Key High - Level Goals and Problems of the Stakeholders
This section summarizes the goals and problems at a high level often higher than specific use cases - and reveals important non - functional and quality goals that may belong to one use case or span many, such as:
Guideline: What are Some Facilitation Methods?
It is especially during activities such as high - level problem definition and goal identification that creative, investigative group work occurs. Here are some useful group facilitation techniques to discover root problems and goals, and support idea generation and prioritization: mind mapping, product vision box creation, fishbone diagrams, pareto diagrams, brainstorming, multi - voting, dot voting, nominal group process, brain writing, and affinity grouping. Check them out on the Web. I prefer to apply several of these during the same workshop, to discover common problems and requirements from different angles.
Summary of System Features
Simply listing the use case names is not sufficient in the Vision to grasp the major features. Why?
Therefore, an alternative, complementary way to express system functions is with features, or more specifically in this context, system features, which are high - level, terse statements summarizing system functions. More formally, in the UP, a system featureis "an externally observable service provided by the system which directly fulfills a stakeholder need" [KruchtenOO].
The system does payment authorization.
Functional system features are to be contrasted with various kinds of non - functional requirements and constraints, such as: "The system must run on Linux, must have 24 / 7 availability, and must have a touch - screen interface." Note that these fail the linguistic test; for example, the system does Linux.
Guideline: How to Write the Feature List?
Terse is good in the Vision - indeed, in any document.
Here is a features example at a high level, for a large multi - system project of which the POS is just one element:
The major features include:
It is common to organize a two - level hierarchy of system features. But 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. A reasonable example in terms of detail:
The major features include:
How many system features should the Vision contain?
Guideline: Should We Duplicate Other Requirements in the Vision?
In the Vision, system features briefly summarize functional requirements often detailed in the use cases. Likewise, the Vision can summarize other requirements (for example, reliability and usability) that are detailed in the Supplementary Specification. But be careful to avoid going down the path of repeating yourself.
Guideline: Should You Write the Vision or Use Cases First?
It isn't useful to be rigid about the order. While developers are collaborating to create different requirements artifacts, a synergy emerges in which working on one artifact influences and helps clarify another. Nevertheless, a suggested sequence is:
Glossary Revision History
UML Related Interview Questions
|Adv Java Interview Questions||Java collections framework Interview Questions|
|Design Patterns Interview Questions||Rational robot Interview Questions|
|Web semantic Interview Questions||Spring MVC Framework Interview Questions|
|Advanced C++ Interview Questions||Advanced jQuery Interview Questions|
|XML DOM Interview Questions||Object Oriented Analysis and Design Interview Questions|
Object-oriented Analysis And Design
Iterative, Evolutionary, And Agile
Inception Is Not The Requirements Phase
Iteration 1 Basics
System 'sequence Diagrams
Requirements To Design-iteratively
Logical Architecture And Uml Package Diagrams
On To Object Design
Uml Interaction Diagrams
Uml Class Diagrams
Grasp: Designing Objects With Responsibilities
Object Design Examples With Grasp
Designing For Visibility
Mapping Designs To Code
Test - Driven Development And Refactoring
Uml Tools And Uml As Blueprint
Iteration 2 - More Patterns
Quick Analysis Update
Grasp: More Objects With Responsibilities
Applying Gof Design Patterns
Iteration 3 Intermediate Topics
Uml Activity Diagrams And Modeling
Uml State Machine Diagrams And Modeling
Relating Use Cases
Domain Model Refinement
More Ssds And Contracts
Logical Architecture Refinement
More Object Design With Gof Patterns
Designing A Persistence Framework With Patterns
Uml Deployment And Component Diagrams
Documenting Architecture: Uml & The N+1 View Model
More On Iterative Development And Agile Project Management
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.