[Note: The following template is provided for use with Rational Unified Process.

Text between]
brackets and those appearing in blue italics (style = InfoBlue) are included to provide guidance to
the author's and must be removed before publishing the document. A paragraph introduced in this style is
will automatically adjust to normality (style = Body text).

Revision history
Date Version Description Author
<dd/mmm/yy> NAME
 Table of contents
1. Introduction
1.1 Purpose
1.2 Scope of application
1.3 Definitions, acronyms, and abbreviations
1.4 References
1.5 General information

2. Positioning
2.1 Business Opportunity
2.2 Statement of the problem
2.3 Product Position Statement

3. Description of stakeholders and the User

3.1 Demographic Market
3.2 Summary of the stakeholders
3.3 User summary
3.4 From the user environment
3.5 Stakeholder profiles
3.5.1 <Name <Stakeholder
3.6 User profiles
3.6.1 <name
3.7 The key stakeholders or user needs
3.8 Alternatives and competition
3.8.1 <aCompetitor>
3.8.2 anotherCompetitor

4. Product description
4.1 Product perspective
4.2 Summary of the Capabilities
4.3 Assumptions and dependencies
4.4 Cost and prices
4.5 Granting of licenses and installation

5. Product characteristics
5.1 <aFeature>
5.2 <anotherFeature>

6. Restrictions

7. Quality Ranges

8. Precedence and priority

9. Other product requirements

9.1 Applicable regulations
9.2 System requirements
9.3 Performance Requirements
9.4 Environmental requirements
10. Documentation requirements
10.1 User manual
10.2 Online help
10.3 Installation, configuration, and Read Me file guides
10.4 Labeling and packaging

Attributes
 Vision
1. Introduction
The purpose of this document is to gather, analyze, and define high-level needs.
characteristics of <<name>>. It focuses on the capabilities required by stakeholders and
the end users, and why these needs exist. The details of how the <<name>> complies with
these needs are detailed in the use case and additional specifications.
The introduction of the Vision document provides an overview of the entire document. It should include
the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this
vision document.
1.1 Purpose
Specify the purpose of this document Vision.
1.2 Scope of application
Everything that is most affected or influenced by this document a brief description of the scope of
this document Vision, Project(s) that is associated with and.
1.3 Definitions, acronyms and abbreviations
This section provides the definitions of the terms, acronyms, and abbreviations required for
properly interpret the document of Vision. This information can be provided by
reference to the project glossary.
1.4 References
This section provides a complete list of all the documents referenced anywhere in the
Vision document. Identify each document by its title, report number (if applicable), date and
organization that publishes it. Specify the sources from which the references can be obtained. This
Information may be provided by reference to an appendix or another document.
1.5 General information
This section describes what the rest of the document contains, the vision, and explains how it is organized.
document.
2. Positioning
2.1 Business Opportunity
Briefly describe the business opportunity that was created by this project.
2.2 Statement of the problem
Provide a statement that summarizes the problem to be solved by this project. The following
format can be used:
The problem of the [Describe the problem]
affects The actors affected by the problem
whose impact is What is the impact of the problem?
a satisfactory solution would be List of some key benefits of a solution
successful
2.3 Product Position Statement
Provide a general statement that summarizes, at the highest level, the unique position of the product.
It intends to fill in the market. The following format can be used:]
For [Customer target]
Who Statement on the need or the opportunity
The (product name) it is a product [category]
What Status of the main advantages, that is, the reason for
weight to buy
Unlike Competitive alternative principal
Our product [State of primary differentiation]
A product position statement communicates the intent of the request and the importance of
project to all the concerned staff.
3. Description of stakeholders and the User
To effectively make available products and services that meet the needs of its stakeholders
real users' needs, it is necessary to identify and involve all stakeholders
as part of the Requirements Modeling process. It must also identify the system users
and ensure that the community of stakeholders is adequately represented. This section provides a
profile of the stakeholders and users involved in the project, and the main issues
that they perceive will be addressed in the proposed solution. It does not describe their requests or requirements.
specific since these are captured in an independent actor artifact requests. Instead, they
they present the background and justification of why the requirements are necessary.
3.1 Demographic Market
Summary of the key demographic data of the market that drive their decisions.
product. Describe and position the target market segments. Estimate the market size and the
growth through the number of potential users, or the amount of money that their customers spend
trying to meet the needs that your product or improvement would fulfill. Review of the main
industry trends and technologies. Answer these strategic questions:
What is your company's reputation in these markets?
What does it feel like to be?

How does this product or service support your goals?

3.2 Summary of stakeholders
There are a number of stakeholders interested in the development and not all of them are end users. Present
a summary list of these non-user actors. (Users are summarized in section 3.3.)
Name Description Responsibilities
Type name of Briefly describe the Summary of the main
interest. stakeholders. responsibilities of the parties
interested in relation to the
system under development, that is,
your interest as part
interested. For example, this
interest group
Ensure that the system will be
easy to maintain
Ensures that there will be a
market demand for the
product characteristics
Monitor the progress of
project
Approve the financing
- And so on]

3.3 User summary

Present a summarized list of all identified users.
Name Description Responsibilities The stakeholders

[Name of [Describe] List of key responsibilities of If the user is not

type of briefly it user regarding the system in directly represented
user. what development, for example: identify the stakeholders
represent he is responsible for representing the
Capture the details
regarding user interests.
to the system. Prepare reports
Coordinates the work
And so on

3.4 From the user environment

Details about the work environment of the target user. Here are some suggestions:
Number of people involved in carrying out the task? Is this a change?
How long does a task cycle last? Amount of time dedicated to each activity? Is this
change?
Any unique environmental restrictions: mobile, outdoors, in flight, etc.?
 What system platforms are currently in use? Future platforms?
What other applications are in use? Does your application need to integrate with them?
Here is where extracts from the business model could be included to outline the task and the
employees of participating companies, etc.
3.5 Stakeholder profiles
Describe each of the stakeholders in the system here by filling in the following table for each
actor. Remember that stakeholders can be as diverse as users,
departments, and technical developers. A complete profile would cover the following topics for each
type of stakeholders.
3.5.1 <Name <Stakeholder
Representative Who is the representative of the interested parties in the
project? (Optional if documented elsewhere.) What
What we want here is the names.
Description Brief description of the interest rate.
Type Train stakeholders in knowledge, techniques, and the background
degree of sophistication, that is, the guru, business, experts, users
occasional, etc.]
ResponsibilitiesList of the main responsibilities of the stakeholders in
relationship with the developing system, that is, its interest as part
interested.
Success Criteria How does the actor define success?
What is the award-winning actor like?

Participation How is the stakeholder in the project? They refer as much as possible
for Rational Unified process functions, that is, the requirements
authors, etc.
Deliverables Are there additional benefits required by the parties?
interested? These could be the benefits of the project or the
outputs of the system in development.
Comments The problems that interfere with success and any other information
Problems relevant to go here.

3.6 User profiles

Describe each unique user of the system by filling in the following table for each type of user.
user. Remember that user types can be as diverse as gurus and
beginners. For example, a guru may need a sophisticated and flexible tool with
cross-platform support, while a novice may need a tool that is
easy to use and easy to use. A complete profile covers the following topics for each type of user.
3.6.1 <name
Representative Who is the representative of the users for the project? (Optional if
documented elsewhere.) Often, this refers to the parts
interested parties represented by the group of users, for example, the
stakeholders. Stakeholder1]
Description A brief description of the type of user.
Type Rate the user on knowledge, background techniques, and the degree of
sophistication, that is, the guru, the occasional user, etc.
ResponsibilitiesList of the key user responsibilities related to the
system in development, that is, captures details, produces reports,
coordinates the work, etc.]
Success criteria How does the user define success?
What is the rewarded user like?
Participation How does the user participate in the project? They refer to it as much as possible.
for Rational Unified process functions, that is, the requirements
authors, etc.
Deliverables Are there results that the user produces and, if so, for whom?
Comments / Problems [that interfere with success and any other information]
Problems relevant to go here. These include the trends that make the
The user's work is easier or more difficult.

3.7 Key stakeholders or user needs

List of the main problems with existing stakeholder view solutions. Clarify the
the following aspects for each problem:
What are the reasons for this problem?
How is it resolved now?
What solutions does the actor or user want?
It is important to understand the relative importance or the user places the stakeholders in the solution.
of each problem. Classification and cumulative voting techniques indicate the problems
which should be resolved in comparison with the issues they would like to address.
Fill in the following table if Rational RequisitePro is used to capture the requirements, this
it could be a certificate or a report of that tool.
 Do you need Priorities The Current solution Solutions
concern proposals
s
Transmit messages

3.8 Alternatives and competition

Identify alternatives that the stakeholder perceives as available. These may include the purchase.
from competing products, the creation of an in-house harvesting solution or simply maintaining
the status quo. Make a list of known competitive options that exist or may exist.
available. It includes the main strengths and weaknesses of each competitor according to perception of
end user or stakeholders.
3.8.1 <aCompetitor>
3.8.2 another competitor
4. Product description
This section provides a high-level overview of the product's capabilities, interfaces with other
applications and system configurations. This section consists of three parts, as follows:
Product perspective
Product functions
Assumptions and dependencies
4.1 Product perspective
This section of the Vision document places the product in the context of other products.
related and user the environment. If the product is independent and fully autonomous,
stay here. If the product is a component of a larger system, then this section applies.
how these systems interact and the interfaces between the relevant systems are identified. One way
easy to show the main components of the larger system, the interconnections, and the
external interfaces is with a block diagram.
4.2 Summary of Capabilities
Summary of the main advantages and features of the product. For example, a document.
Division for a customer service system can use this part to address issues.
of documentation, routing, and status reports, not to mention the amount of detail each
one of these functions requires.
Organize the functions of the list to be understandable for the customer or for anyone else.
to read the document for the first time. A simple table lists the main advantages and their functions of
support could be enough. For example:
 Table 4.1 Customer Support System
Benefit for the customer Support functions
support staff from Nueva Knowledge base helps support staff in
you can quickly catch up. the rapid identification of known solutions and
solutions.
Customer satisfaction is improved The problems are especially detailed,
because nothing falls through the cracks. classified and monitoring of the entire process of
resolution. Automatic notification occurs for
all issues of aging.
Management can identify the areas and distribution of trend reports allow
problems and measure the burden of a high-level review of the condition of
staff work. problem.
Support teams have been distributed. Replication Server allows the base information
they can work together to solve current data to be shared across the
problems. company.
Customers can help themselves. Knowledge base can be made available to
same, the cost reduction of through the Internet. Includes search capabilities
support and improve the time of of hypertext and the graphic query engine.
response.
4.3 Assumptions and dependencies
List of each of the factors that affect the mentioned characteristics in the
DocumentVision.List of assumptions that, if changed, alter the DocumentVision. For example,
A supposition might assert that a specific operating system will be available for the equipment.
designated for the software product. If the operating system is not available, the
The vision document will have to change.

4.4 Cost and prices

For the products sold to external customers and for many applications in the company, issues
of costs and pricing can directly affect the definition of the application and
execution. In this section, record of all cost and price limitations that are
relevant. For example, the distribution costs (number of diskettes, # of CD-ROMs, the domain of
CD) or other costs of sold goods limitations (manuals, packaging) can be important
for the success of the projects, or irrelevant, depending on the nature of the request.
4.5 License grant and installation
The granting of licenses and installation problems can also directly impact the effort.
of development. For example, the need to support serialization, security password or
The granting of network licenses will create additional system needs that must be considered.
in the development effort.
Installation requirements can also affect code or create the need for software.
separate installation.
5. Product features
List and briefly describe the product features. The features are the capabilities.
high-level system components that are necessary to provide benefits to users. Each function is a
external service that usually requires a series of inputs to achieve the result
desired. For example, a feature of a bug tracking system could be the
ability to present trend reports. As the use case model is configured, updates
the description for referring to the use cases.
Because the document of reviewed Visions by a wide variety of involved personnel, the
the level of detail must be general enough for everyone to understand. However, with
Sufficient detail must be available to provide the team with the information they need.
to create a use case model.
To effectively manage application complexity, it is recommended for any new system, or
an increase to an existing system, the capabilities are abstractions of a level sufficiently
high for 25-99 account result. These characteristics constitute the fundamental basis for the
definition of the product, scope management, and project management. Each function will be elaborated on further.
detail in the use case model.
Throughout this section, each feature is externally perceivable by users,
operators or other external systems. These features should include a description of the
functionality and the relevant usability issues that must be addressed. The guidelines
the following will be applied:

• Avoid design. Keep the function of the descriptions at a general level. Focus on the capabilities.
necessary and why (non-technical) that must be applied.
If you are using the Rational RequisitePro toolkit, all must be selected as
the type requirements to facilitate consultation and tracking.
5.1 <aFeature>

5.2 anotherFeature
6. Restrictions
Please note the possible design limitations, external constraints, or other dependencies.
7. Quality Ranks
Definition of quality ranges for performance, robustness, fault tolerance, usability and
similar features that are not captured in the feature set.
8. Precedence and priority
Definition of the priority of the different system features.
9. Other product requirements
At a high level, the applicable standards list the hardware or platform requirements.
performance requirements, and environmental requirements.
9.1 Applicable standards
List of all the regulations that the product must comply with. These can include standards of
legal and regulatory communication (FDA, UCC) (TCP/IP, ISDN), compliance with standards of the
platform (Windows, UNIX, etc.), and the quality and safety standards (UL, ISO, CMM).
9.2 System Requirements
Define the system requirements necessary to support the application. These may include systems
support for operational networks and platforms, memory configurations, peripherals and software
of the company.
9.3 Performance Requirements
Use this section to detail the performance requirements. Performance issues can
include elements such as user load factors, bandwidth capacity or the
communication, performance, accuracy, reliability, and response times or under a variety of
loading conditions.
9.4 Environmental requirements
Details of environmental requirements, as necessary. For hardware-based systems, the
Environmental problems can include temperature, shocks, humidity, radiation, etc. For
software applications, environmental factors may include usage conditions, the environment of
user, resource availability, maintenance issues, and management and recovery of
errors.
10. Documentation requirements
This section describes the documentation that must be developed to support the successful deployment of
applications.
10.1 User Manual
Describe the purpose and content of the user manual. Discuss the desired length, the level of
Detail, the need for an index, glossary of terms, against the tutorial strategy manual of reference.
and so on. Formatting and printing the restrictions must also be identified.
10.2 Online help
Many applications offer an online help system to assist the user. The nature of
these systems are unique for application development as they combine aspects of programming
(hyperlinks, etc) with aspects of technical writing, such as organization and presentation. Many
they have found the development of the online help system is a project within a project that is
benefits from the initial scope management and planning activity.
10.3 Installation guide
A document that includes installation instructions and configuration guides is important for a
complete solution it offers. In addition, a Read Me file is usually included as a
standard component. The Read Me file may include a 'What's new in this version'
section, and a discussion of backward compatibility issues. Most of the
users will also appreciate documentation that states that none of the known errors and
solutions in the Readme file.
10.4 Labeling and packaging
requests [from today the state of the art provides a coherent aspect that begins with the
product packaging and is manifested through installation menus, startup screens, the systems
help, graphical user interface dialog boxes, and so on. This section defines the
needs and types of labeling to be incorporated into the code. Examples include rights
of authors and patent notices, corporate logos, standardized icons, and other graphic elements,
etc.]
Attributes
Features [attributes are given that can be used to evaluate, track, prioritize, and manage
the elements of the proposed product for its application. All types of requirements and attributes are
they are described in the Requirements Management Plan, however you may want to list and describe
briefly the attributes of the features that have been chosen. The following sections
they represent a set of trait attributes suggested.
A.1 Legal and Social Condition
Game after negotiation and review by the project management team. Follow-up of
progress during the definition of the project's baseline.
Proposed It is used to describe the characteristics that are under
discussion, but they have not yet been reviewed and accepted by the 'channel
official", just like a working group made up of representatives
from the project team, product management, and the user or the
customer community.
Approved The capabilities that are considered useful and feasible, and have been
approved for execution by the official channel.
Incorporated Features incorporated into the product baseline in a
specific point in time.

A.2 Benefit
Set by marketing, the product manager or the business analyst. All requirements
they are not the same. Ranking of needs by their performance in relation to the end user opens
a dialogue with clients, analysts, and members of the development team. ] It is used in management of
scope and determine the priority of development.
 Critique Essential characteristics. The lack of application, the system does not
respond to the customer's needs. All critical functions
must be implemented in the release or schedule of
sliding.
ImportantImportant characteristics for the effectiveness and efficiency of the system
for most applications. The functionality cannot be
provided in a simple way in some other manner. The lack of
Inclusion of an important aspect can affect clients or the
user satisfaction, and even revenue, but their freedom is not
will be delayed due to the lack of some important functions.
Tools Features [that are useful in less typical applications are used
less frequently or for those who reasonably solutions
efficient can be achieved. There are no significant revenues or impact from the
customer satisfaction can be expected if such a product is not included
in a statement.

A.3 Effort
Defined by the development team. Since some functions require more time and resources than
others, the estimation of the number of team members or weeks, the lines of code needed or
function points, for example, is the best way to measure the expectations of complexity and the
set of what can and cannot be achieved at a given moment frame. ] It is used in the
scope management and determine the priority of development.
A.4 Risk
Game by the development team based on the likelihood that the project will experience effects
adverse events, such as cost overruns, delays in timelines, or even cancellation. Most of
From the project managers, identifying risks and classifying them as high, medium, and low is sufficient, although more...
Subtle gradations are possible. Risk can often be assessed indirectly through the
measurement of the uncertainty (range) of the estimation for scheduling the project team.
A.5 Stability
Set by the analyst and the development team based on the probability that the function is going to
Change or the team's understanding of the change feature. It is used to help
establish development priorities and determine the elements for which additional elicitation is
the following appropriate action.
A.6 Objective of the premiere
Documents of the proposed product version, that the first feature will appear.
The field can be used to assign the characteristics of a document in a statement.
of baseline in particular. When combined with the status field, your team can propose,
register and analyze the various characteristics of the release without incurring them for the
development. Only the state functions are established in Incorporated and whose destination is defined from
the launch will take place. When scope management occurs, the goal Release Number
it can be increased so the topic will remain in the division document, but it will be scheduled
for a later version.
A.7 Assigned to
In many projects, the features will be assigned to the 'function of the responsible teams of'
the additional acquisition, in writing the software and implementation requirements. This simple list
The dropdown will help everyone in the project team to better understand their responsibilities.
A.8 Reason
This text field is used to track the source of the requested function. Requirements exist for
specific reasons. This field records an explanation or a reference to an explanation. For
for example, the reference could be a page number and the line of a requirements specification from
product or a timestamp marker in a video of an important customer review.