Plug-in Ior open oIIice

Version: 1.0
Vision Date: 04/10/2010~

As an individual project, 2011 Page 1











PIug-In for open Office
Vision Document







Plug-in Ior open oIIice
Version: 1.0
Vision Date: 04/10/2010~

As an individual project, 2011 Page 2






Revision History























Date Version Description Author
04/10/2010~ 1.0 Plug-in Ior Open OIIice which provides set
OI Iunctionalities to do matrix operations
and to Iind out principle components with
eigen values.
Chathuri Gunawardhana



Plug-in Ior open oIIice
Version: 1.0
Vision Date: 04/10/2010~

As an individual project, 2011 Page 3







TabIe of Contents
1. Introduction 4
1.1 ReIerences 4
2. Positioning 4
2.1 Problem Statement 4
2.2 Product Position Statement 4
3. Stakeholder and User Descriptions 4
3.1 Stakeholder Summary 4
3.2 User Summary 4
3.3 User Environment 4
3.4 Summary oI Key Stakeholder or User Needs 4
3.5 Alternatives and Competition 4
4. Product Overview 6
4.1 Product Perspective 6
4.2 Assumptions and Dependencies 6
5. Product Features 6
6. Other Product Requirements 7
Plug-in Ior open oIIice
Version: 1.0
Vision Date: 04/10/2010~

As an individual project, 2011 Page 4

Vision (SmaII Project)
1. Introduction
The purpose oI this document is to collect, analyze, and deIine needs and Ieatures oI the open oIIice spreadsheet. It
is to extend the area oI spreadsheet like in matrix operations and statistical analysis. It Iocuses on the capabilities
needed by the stakeholders and the target users, and hy these needs exist.
1.1 References
This subsection provides a complete list oI all documents reIerenced elsewhere in the Vision document. IdentiIy
each document by title, report number iI applicable, date, and publishing organization. SpeciIy the sources Irom
which the reIerences can be obtained. This inIormation may be provided by reIerence to an appendix or to another
document.|
. Positioning
.1 ProbIem Statement
Provide a statement summarizing the problem being solved by this project. The Iollowing Iormat may be used:|
The problem oI Not having suIIicient Iunctions to do data analysis
aIIects Students ,Mathematicians and data analyzers
the impact oI which is Spending time to do them diIIicult way, reduce the demand
Ior spreadsheet
a successIul solution would be Come up with solutions to above problems
. Product Position Statement
Provide an overall statement summarizing, at the highest level, the unique position the product intends to Iill in the
marketplace. The Iollowing Iormat may be used:|
For all
Who Use spreadsheet Ior statistical data analysis
This plugin is a very important tool
That will work accurately, save the time, and easy to use
Unlike Other statistical data analytical tools
Our product Is user Iriendly and easy to use and don`t require lot oI
knowledge oI statistics.
3. StakehoIder and User Descriptions
To eIIectively provide products and services that meet your stakeholders` and users' real needs it is necessary to
identiIy and involve all oI the stakeholders as part oI the Requirements Modeling process. You must also identiIy
the users oI the system and ensure that the stakeholder community adequately represents them. This section provides
a proIile oI the stakeholders and users involved in the project, and the key problems that they perceive to be
addressed by the proposed solution. It does not describe their speciIic requests or requirements as these are captured
in a separate stakeholder requests artiIact. Instead, it provides the background and justiIication Ior why the
requirements are needed.|
3.1 StakehoIder Summary
There are a number oI stakeholders with an interest in the development and not all oI them are end users. Present a
summary list oI these non-user stakeholders. (The users are summarized in section 3.2.)|
Plug-in Ior open oIIice
Version: 1.0
Vision Date: 04/10/2010~

As an individual project, 2011 Page 5

ame Description Responsibilities
Name the
stakeholder type.|
rieIly describe the
stakeholder.|
Summarize the stakeholder`s key
responsibilities with regard to the system
being developed; that is, their interest as a
stakeholder. For example, this stakeholder:
ensures that the system will be maintainable
ensures that there will be a market demand Ior
the product`s Ieatures
monitors the project`s progress
approves Iunding
and so Iorth|
3. User Summary
Present a summary list oI all identiIied users.|
ame Description Responsibilities Stakeholder
Name
the user
type.|
rieIly describe
what they represent
with respect to the
system.|
ist the user`s key responsibilities
with regard to the system being
developed; Ior example:
captures details
produces reports
coordinates work
and so on|
II the user is not directly
represented, identiIy which
stakeholder is responsible Ior
representing the user`s
interest.|

3.3 User Environment
Detail the working environment oI the target user. Here are some suggestions:
Number oI people involved in completing the task? Is this changing?
How long is a task cycle? Amount oI time spent in each activity? Is this changing?
Any unique environmental constraints: mobile, outdoors, in-Ilight, and so on?
Which system platIorms are in use today? Future platIorms?
What other applications are in use? Does your application need to integrate with them?
This is where extracts Irom the usiness Model could be included to outline the task and roles involved, and so on.|
3.4 Summary of Key StakehoIder or User Needs
ist the key problems with existing solutions as perceived by the stakeholder or user. ClariIy the Iollowing issues
Ior each problem:
What are the reasons Ior this problem?
How is it solved now?
What solutions does the stakeholder or user want?|
Plug-in Ior open oIIice
Version: 1.0
Vision Date: 04/10/2010~

As an individual project, 2011 Page 6

It is important to understand the relative importance the stakeholder or user places on solving each problem.
Ranking and cumulative voting techniques indicate problems that must be solved versus issues they would like
addressed.
Fill in the Iollowing tableiI using Rational RequisitePro to capture the Needs, this could be an extract or report
Irom that tool.|
eed Priority Concerns Current Solution Proposed Solutions
roadcast messages

3.5 AIternatives and Competition
IdentiIy alternatives the stakeholder perceives as available. These can include buying a competitor`s product,
building a homegrown solution, or simply maintaining the status quo. ist any known competitive choices that exist
or may become available. Include the major strengths and weaknesses oI each competitor as perceived by the
stakeholder or end user.|
4. Product Overview
This section provides a high level view oI the product capabilities, interIaces to other applications, and system
conIigurations. This section usually consists oI two subsections, as Iollows:
Product perspective
Assumptions and dependencies|
4.1 Product Perspective
This subsection oI the Vision document puts the product in perspective to other related products and the user`s
environment. II the product is independent and totally selI-contained, state it here. II the product is a component oI a
larger system, then this subsection needs to relate how these systems interact and needs to identiIy the relevant
interIaces between the systems. One easy way to display the major components oI the larger system,
interconnections, and external interIaces is with a block diagram.|
4. Assumptions and Dependencies
ist each Iactor that aIIects the Ieatures stated in the Vision document. ist assumptions that, iI changed, will alter
the Vision document. For example, an assumption may state that a speciIic operating system will be available Ior
the hardware designated Ior the soItware product. II the operating system is not available, the Vision document will
need to change.|
5. Product Features
ist and brieIly describe the product Ieatures. Features are the high-level capabilities oI the system that are
necessary to deliver beneIits to the users. Each Ieature is an externally desired service that typically requires a series
oI inputs to achieve the desired result. For example, a Ieature oI a problem tracking system might be the ability to
provide trending reports. As the use-case model takes shape, update the description to reIer to the use cases.
ecause the Vision document is reviewed by a wide variety oI involved personnel, the level oI detail needs to be
general enough Ior everyone to understand. However, enough detail must be available to provide the team with the
inIormation they need to create a use-case model.
To eIIectively manage application complexity, we recommend Ior any new system, or an increment to an existing
system, capabilities be abstracted to a high enough level so 25-99 Ieatures result. These Ieatures provide the
Iundamental basis Ior product deIinition, scope management, and project management. Each Ieature will be
expanded in greater detail in the use-case model.
Throughout this section, each Ieature will be externally perceivable by users, operators, or other external systems.
These Ieatures should include a description oI Iunctionality and any relevant usability issues that must be addressed.
The Iollowing guidelines apply:
Plug-in Ior open oIIice
Version: 1.0
Vision Date: 04/10/2010~

As an individual project, 2011 Page 7

Avoid design. Keep Ieature descriptions at a general level. Focus on capabilities needed and why (not how)
they should be implemented.
II you are using the Rational RequisitePro toolkit, all need to be selected as requirements oI type Ior easy
reIerence and tracking.|

DeIine the priority oI the diIIerent system Ieatures. Include, iI useIul, attributes such as stability, beneIit, eIIort, and
risk.|
. Other Product Requirements
At a high level, list applicable standards, hardware, or platIorm requirements; perIormance requirements; and
environmental requirements.
DeIine the quality ranges Ior perIormance, robustness, Iault tolerance, usability, and similar characteristics that are
not captured in the Feature Set.
Note any design constraints, external constraints, or other dependencies.
DeIine any speciIic documentation requirements, including user manuals, online help, installation, labeling, and
packaging requirements.
DeIine the priority oI these other product requirements. Include, iI useIul, attributes such as stability, beneIit, eIIort,
and risk.|