\documentclass[12pt,a4paper,twoside]{article}
\usepackage{a4wide}
\usepackage{t1enc}
\usepackage[polish]{babel}
\usepackage[latin2]{inputenc}
\usepackage{graphicx}
\usepackage{amsfonts}
\usepackage{amsmath}
\usepackage{amsthm}


\RequirePackage[T1]{fontenc}
\RequirePackage{times}
\RequirePackage[latin2]{inputenc}
\RequirePackage[polish]{babel}

\RequirePackage{comment}

\RequirePackage{a4wide}
\RequirePackage{longtable}
\RequirePackage{multicol}
\RequirePackage{url}

\author{Autorzy}
\title{io08-7X :: Wizja projektu}


% $Id: $

\begin{document}

\maketitle

\newpage

\begin{abstract}
Streszczenie streszczenia.
\end{abstract}

\newpage

\tableofcontents

\newpage

% Note: The following template is provided for use with the
% Rational Unified Process. Text enclosed in square brackets and displayed in
% blue italics (style=InfoBlue) is included to provide guidance to the author and
% should be deleted before publishing the document. A paragraph entered following
% this style will automatically be set to normal (style=Body Text).

%   

% some table, check it

\section{Wprowadzenie}

% The purpose of this document is to collect,
% analyze, and define high-level needs and features of the <<System Name>>.  It focuses on the capabilities needed by the
% stakeholders, and the target users, and why these needs exist.  The details of how the <<System Name>> fulfils these
% needs are detailed in the use-case and supplementary specifications.

%  [The
% introduction of the Vision document should provide an overview of the
% entire document. It should include the purpose, scope, definitions, acronyms,
% abbreviations, references, and overview of this Vision document.

\subsection{Cel}

% Specify the purpose of this Vision document.

\subsection{Zakres}

% A brief description of the scope of this Vision
% document; what Project(s) it is associated with, and anything else that is
% affected or influenced by this document.

\subsection{Definicje}

% This subsection should provide the
% definitions of all terms, acronyms, and abbreviations required to properly
% interpret the Vision document.  This information may be provided by
% reference to the project Glossary.

\subsection{Załączniki}

% This subsection should provide a complete
% list of all documents referenced elsewhere in the Vision document.  Each document should be identified by title,
% report number (if applicable), date, and publishing organization.  Specify the sources from which the
% references can be obtained. This information may be provided by reference to an
% appendix or to another document.

\subsection{Omówienie reszty dokumentu}

% This subsection should describe what the
% rest of the Vision document contains and explain how the document is
% organized.

\section{Kontekst produktu}

\subsection{Korzyści}

% Briefly describe the business opportunity being met by this
% project.

\subsection{Postawienie problemu}

% Provide a statement summarizing the problem being solved by
% this project. The following format may be used (fill the XXXX whith the
% content described after `%':

Problem of XXXX                % describe the problem
affects XXXX                   % the stakeholders affected by the problem
the impact of which is XXXX    % describe the impact of the problem
A succesful solution would be  % list some key benefits of a successful solution
XXXX


\subsection{Kontekst produktu}

% Provide an overall statement summarizing at the highest
% level, the unique position the product intends to fill in the marketplace. The
% following format may be used:

For XXXX           % [name the target customer]
who XXXX           % [statement of the need or opportunity] (needs, wants etc)
The [product name] XXXX % is a [product category]
That XXX           % [statement of key benefit; that is, compelling reason
                   % to buy]
Unlike XXXX        % [primary competitive alternative]
Our product XXXX   % [statement of primary differentiation]

% A product position statement communicates the intent of the
% application and the importance of the project to all concerned personnel.

\section{Osoby mające wpływ na wymagania i projekt}

% To effectively
% provide products and services that meet your stakeholders and users' real
% needs, it is necessary to identify and involve all of the stakeholders as part
% of the Requirements Modeling process. 
% You must also identify the users of the system and ensure that the
% stakeholder community adequately represents them.  This section provides a profile of 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 specific requests or requirements as these are captured in a
% separate stakeholder requests artifact. 
% Instead it provides the background and justification for why the
% requirements are needed.

\subsection{Demografia rynku}

% Summarize the key
% market demographics that motivate your product decisions. Describe and position
% target market segments. Estimate the markets size and growth by using the
% number of potential users, or the amount of money your customers spend trying
% to meet needs that your product or enhancement would fulfill. Review major industry
% trends and technologies. Answer these strategic questions:

%           What is your organizations reputation
% in these markets? 

%            What would you like it to be? 

%           How does this product or service
% support your goals?

\subsection{Lista osób mających wpływ na wymagania}

% Present a summary
% list of all the identified stakeholders.

\begin{longtable}{|p{1in}|p{2in}|p{2in}|}
\hline
{\bf Name} & {\bf Represents} & {\bf Role}\\
\hline
\endhead
Name the stakeholder type. &
Briefly describe what they represent with respect to the development. &
Briefly describe the role they are playing in the development.
For example, Ensure this?\\
\hline
\end{longtable}

\subsection{Lista potencjalnych użytkowników produktu}

% Present a summary
% list of all the identified users.

\begin{longtable}{|p{1in}|p{2in}|p{2in}|}
\hline
{\bf Name} & {\bf Description} & {\bf Stakeholder}\\
\hline
\endhead
Name the user type. &
Briefly describe what they represent with respect to the system. &
List how the user is represented by the stakeholders.
For example, Represented by Stakeholder 1.1\\
\hline
\end{longtable}

\subsection{Środowisko użytkownika}

% Detail the working
% environment of the target user. Here are some suggestions:

% Number of people
% involved in completing the task? Is this changing?

% How long is a task
% cycle? Amount of time spent in each activity? Is this changing?

% Any unique
% environmental constraints: mobile, outdoors, in-flight, etc.?

% Which systems
% platforms are in use today? Future platforms?

% What other
% applications are in use? Does your application need to integrate with them?

% This is where
% extracts from the Business Model could be included to outline the task and
% workers involved etc.

\subsection{Charakterystyka osób mających wpływ na wymagania}

% Describe each
% stakeholder in the system here by filling in the following table for each
% stakeholder.  Remember stakeholder types
% can be as divergent as users, strategy departments and technical
% developers.  A thorough profile should
% cover the following topics for each type of stakeholder:

\subsubsection{<Stakeholder Name>}

\begin{longtable}{|p{1in}|p{4in}|}
\hline
Representative &
Who is the stakeholder representative to the project?
(optional if documented elsewhere.) What we want here is names. \\

\hline
Description &
Brief description of the stakeholder type.\\

\hline
Type &
Qualify the stakeholder's expertise, technical background, and degree
of sophistication-that is, guru, business, expert, casual user, etc.\\

\hline
Responsibilities &
List the stakeholder's key responsibilities with regards to the system
being developed-that is, their interest as a stakeholder.\\

\hline
Success criteria &
How does the stakeholder define success? How is the stakeholder rewarded?\\

\hline
Involvement &
How the stakeholder is involved in the project? Relate where possible
to RUP workers-that is, Requirements Reviewer etc.\\

\hline
Deliverables &
Are there any additional deliverables required by the stakeholder?
These could be project deliverables or outputs from the system under
development.\\

\hline
Comments / Issues &
Problems that interfere with success and any other relevant information
go here.\\

\hline
\end{longtable}

\subsection{Charakterystyka użytkowników}

% Describe each
% unique user of the system here by filling in the following table for each user
% type.  Remember user types can be as
% divergent as gurus and novices. For example, a guru might need a sophisticated,
% flexible tool with cross-platform support, while a novice might need a tool
% that is easy to use and user-friendly. A thorough profile should cover the
% following topics for each type of user:

\subsubsection{<User Name>}

\begin{longtable}{|p{1in}|p{4in}|}
\hline
Representative &
Who is the user representative to the project? (optional if documented
elsewhere). This often refers to the Stakeholder that represents the set
of users, for example, Stakeholder: Stakeholder1.\\

\hline
Description &
A brief description of the customer type.\\

\hline
Type &
Qualify the customer's expertise, technical background, and degree of
sophistication-that is, guru, casual user, etc.\\

\hline
Responsibilities &
List the user's key responsibilities with regards to the system being
developed -- that is, captures customers details, produces reports,
coordinates work, etc.\\

\hline
Success criteria &
How does the customer define success? How is the customer rewarded?\\

\hline
Involvement &
How the customer is involved in the project? Relate where possible to
RUP workers-that is, Requirements Reviewer, etc.\\

\hline
Deliverables &
Are there any deliverables the customer produces and, if so, for whom?\\

\hline
Comments / Issues &
Problems that interfere with success and any other relevant information go
here. These would include trends that make the customer's job easier or
harder.\\

\hline
\end{longtable}


\subsection{Kluczowe wymagania}

% List the key
% problems with existing solutions as perceived by the stakeholder. Clarify the
% following issues for each problem:

%           What are the reasons for this problem?
% 

%           How is it solved now?

%           What solutions does the stakeholder
% want?

% 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
% following table - if using ReqPro to capture the Needs, this could be an
% extract or report from that tool.

{\small\begin{longtable}{|p{1.5in}|p{.5in}|p{1in}|p{1in}|p{1in}|}
\hline
Need & Priority & Concerns & Current Solution & Proposed Solution\\
\hline
\endhead

Broadcast Messages & \  & \  & \  & \  \\
\hline
\end{longtable}}

\subsection{Alternatywy i konkurencja}

% Identify
% alternatives the stakeholder perceives as available. These can include buying a
% competitors product, building a homegrown solution or simply maintaining the
% status quo. List any known competitive choices that exist, or may become
% available. Include the major strengths and weaknesses of each competitor as
% perceived by the stakeholder.

\subsubsection{<aCompetitor>}

\subsubsection{<anotherCompetitor>}

\section{Omówienie produktu}

% This section provides a high level view of the product
% capabilities, interfaces to other applications, and systems configurations.
% This section usually consists of three subsections, as follows: 

%           Product
% perspective 

%           Product
% functions 

%             Assumptions
% and dependencies

\subsection{Umiejscowienie produktu}

% This subsection of the Vision document should put the
% product in perspective to other related products and the users environment. If
% the product is independent and totally self-contained, state it here. If the
% product is a component of a larger system, then this subsection should relate
% how these systems interact and should identify the relevant interfaces between
% the systems. One easy way to display the major components of the larger system,
% interconnections, and external interfaces is via a block diagram.

\subsection{Podsumowanie możliwości}

% Summarize the major benefits and features the product will
% provide. For example, a Vision document for a customer support system
% may use this part to address problem documentation, routing, and status
% reporting without mentioning the amount of detail each of these functions requires.

% Organize the functions so the list is understandable to the
% customer or to anyone else reading the document for the first time. A simple
% table listing the key benefits and their supporting features might suffice. For
% example:

\begin{center}
{\sffamily\bfseries\large Customer Support System}

\begin{longtable}{|p{2.5in}|p{2.5in}|}
\hline
\bf Customer Benefit & \bf Supporting Features\\
\hline\endhead

New support staff can quickly get up to speed. &
Knowledge base assists support personnel in quickly identifying known fixes
and workarounds \\
\hline

Customer satisfaction is improved because nothing falls through the cracks. &
Problems are uniquely itemized, classified and tracked throughout the
resolution process. Automatic notification occurs for any aging issues.\\
\hline

Management can identify problem areas and gauge staff workload. &
Trend and distribution reports allow high level review of problem status.\\
\hline

Distributed support teams can work together to solve problems. &
Replication server allows current database information to be shared across
the enterprise\\
\hline

Customers can help themselves, lowering support costs and improving
response time. &
Knowledge base can be made available over the Internet.  Includes hypertext
search capabilities and graphical query engine\\
\hline
\end{longtable}
\end{center}

\subsection{Założenia i zależności}

% List each of the factors that affects the features stated in
% the Vision document. List assumptions that, if changed, will alter the Vision
% document. For example, an assumption may state that a specific operating
% system will be available for the hardware designated for the software product.
% If the operating system is not available, the Vision document will need
% to change.

\subsection{Koszta}

% For products sold to external customers and for many in-
% house applications, cost and pricing issues can directly impact the
% applications definition and implementation. In this section, record any cost
% and pricing constraints that are relevant. For example, distribution costs, (#
% of diskettes, # CD-ROMs, CD mastering) or other cost of goods sold constraints
% (manuals, packaging) may be material to the projects success, or irrelevant,
% depending on the nature of the application.

\subsection{Licencjonowanie i instalacja}

% Licensing and installation issues can also directly impact
% the development effort. For example, the need to support serializing, password
% security or network licensing will create additional requirements of the system
% that must be considered in the development effort.

% Installation requirements may also affect coding, or create
% the need for separate installation software.

\section{Własności produktu}

% List and briefly describe the product features. Features are
% the high-level capabilities of the system that are necessary to deliver
% benefits to the users. Each feature is an externally desired service that
% typically requires a series of inputs to achieve the desired result. For
% example, a feature of a problem tracking system might be the ability to provide
% trending reports. As the use-case model takes shape, update the description to
% refer to the use cases.

% Because the Vision document is reviewed by a wide
% variety of involved personnel, the level of detail should be general enough for
% everyone to understand. However, enough detail should be available to provide
% the team with the information they need to create a use-case model.

% To effectively manage application complexity, we recommend
% for any new system, or an increment to an existing system, capabilities are
% abstracted to a high enough level so 25-99 features result. These features
% provide the fundamental basis for product definition, scope management, and
% project management. Each feature will be expanded in greater detail in the use-case
% model.

% Throughout this section, each feature should be externally
% perceivable by users, operators or other external systems. These features
% should include a description of functionality and any relevant usability issues
% that must be addressed. The following guidelines apply:

%           Avoid design. Keep feature
% descriptions at a general level. Focus on capabilities needed and why, (not
% how)   they should be implemented.

%           If you are using the Requisite
% toolkit, all should be selected as requirements of type for easy reference and
% tracking.

\subsection{<aFeature>}

\subsection{<anotherFeature>}

\section{Ograniczenia}

% Note any design constraints, external constraints or other
% dependencies.

\section{Założenia jakościowe}

% Define the quality ranges for performance, robustness, fault
% tolerance, usability, and similar characteristics that are not captured in the
% Feature Set.

\section{Priorytety}

% Define the priority of the different system features.

\section{Inne wymagania}

% At a high-level, list applicable standards, hardware or
% platform requirements, performance requirements, and environmental
% requirements.

\subsection{Standardy}

% List all standards with which the product must comply. These
% can include legal and regulatory (FDA, UCC) communications standards (TCP/IP,
% ISDN), platform compliance standards (Windows, Unix, etc.), and quality and
% safety standards (UL, ISO, CMM).

\subsection{Wymagania systemowe}

% Define any system requirements necessary to support the
% application. These can include the supported host operating systems and network
% platforms, configurations, memory, peripherals, and companion software.

\subsection{Wymagania wydajnościowe}

% Use this section to detail performance requirements.
% Performance issues can include such items as user load factors, bandwidth or
% communication capacity, throughput, accuracy, and reliability or response times
% under a variety of loading conditions.

\subsection{Wymagania środowiska}

% Detail environmental requirements as needed. For hardware-
% based systems, environmental issues can include temperature, shock, humidity,
% radiation, etc. For software applications, environmental factors can include
% usage conditions, user environment, resource availability, maintenance issues,
% and error handling, and recovery.

\section{Wymagania dokumentacyjne}

% This section describes the documentation that must be
% developed to support successful application deployment.

\subsection{Podręcznik użytkownika}

% Describe the purpose and contents of the User Manual.
% Discuss desired length, level of detail, need for index, glossary of terms,
% tutorial vs. reference manual strategy, etc. Formatting and printing constraints
% should also be identified.

\subsection{Pomoc on-line}

% Many applications provide an on-line help system to assist
% the user. The nature of these systems is unique to application development as
% they combine aspects of programming (hyperlinks, etc) with aspects of technical
% writing (organization, presentation). Many have found the development of
% on-line help system is a project within a project that benefits from up-front
% scope management and planning activity.

\subsection{Instalacja i konfiguracja}

% A document that includes installation instructions and
% configuration guidelines is important to a full solution offering. Also, a Read
% Me file is typically included as a standard component. The Read Me can include
% a "What's New With This Release section, and a discussion of
% compatibility issues with earlier releases. Most users also appreciate
% documentation defining any known bugs and workarounds in the Read Me file.

\subsection{Oznaczenia markowe}

% Today's state of the art applications provide a consistent
% look and feel that begins with product packaging and manifests through
% installation menus, splash screens, help systems, GUI dialogs, etc. This
% section defines the needs and types of labeling to be incorporated into the
% code. Examples include copyright and patent notices, corporate logos,
% standardized icons and other graphic elements, etc.

\appendix
\section{Appendix 1 - Feature Attributes}

% Features should be given attributes that can be used to
% evaluate, track, prioritize, and manage the product items proposed for
% implementation. All requirement types and attributes should be outlined in the
% Requirements Management Plan, however you may wish to list and briefly
% describes the attributes for features that have been chosen. Following
% subsections represent a set of suggested feature attributes.

\subsection{Status}

% Set after negotiation and review by the project management
% team. Tracks progress during definition of the project baseline.

\begin{longtable}{|p{1in}|p{4in}|}
\hline
Proposed &
[Used to describe features that are under discussion but have not yet
been reviewed and accepted by the "official channel," such as a working
group consisting of representatives from the project team, product
management and user or customer community.] \\
\hline

Approved &
[Capabilities that are deemed useful and feasible and have been approved
for implementation by the official channel. ] \\
\hline

Incorporated &
[Features incorporated into the product baseline at a specific point in
time.] \\
\hline

\end{longtable}

\subsection{Spodziewane korzyści}

% Set by Marketing, the product manager or the business
% analyst. All requirements are not created equal. Ranking requirements by their
% relative benefit to the end user opens a dialogue with customers, analysts and
% members of the development team. Used in managing scope and determining
% development priority.

\begin{longtable}{|p{1in}|p{4in}|}
\hline
Critical &
[Essential features. Failure to implement means the system will not meet
 customer needs. All critical features must be implemented in the release
 or the schedule will slip.] \\
\hline

Important &
[Features important to the effectiveness and efficiency of the system for
 most applications. The functionality cannot be easily provided in some
 other way. Lack of inclusion of an important feature may affect customer
 or user satisfaction, or even revenue, but release will not be delayed due
 to lack of any important feature.] \\
\hline

Useful &
[Features that are useful in less typical applications, will be used less
 frequently, or for which reasonably efficient workarounds can be achieved.
 No significant revenue or customer satisfaction impact can be expected if
 such an item is not included in a release.] \\
\hline

\end{longtable}

\subsection{Pracochłonność}

% Set by the development team. Because some features require
% more time and resources than others, estimating the number of team or
% person-weeks, lines of code required or function points, for example, is the
% best way to gauge complexity and set expectations of what can and cannot be
% accomplished in a given time frame. Used in managing scope and determining
% development priority.

\subsection{Ryzyko}

% Set by development team based on the probability the project
% will experience undesirable events, such as cost overruns, schedule delays or
% even cancellation. Most project managers find categorizing risks as high,
% medium, and low sufficient, although finer gradations are possible. Risk can
% often be assessed indirectly by measuring the uncertainty (range) of the
% projects teams schedule estimate.

\subsection{Niezmienność}

% Set by analyst and development team based on the probability
% the feature will change or the teams understanding of the feature will change.
% Used to help establish development priorities and determine those items for
% which additional elicitation is the appropriate next action.

\subsection{Planowane wydanie}

% Records the intended product version in which the feature
% will first appear. This field can be used to allocate features from a Vision
% document into a particular baseline release. When combined with the status
% field, your team can propose, record and discuss various features of the
% release without committing them to development. Only features whose Status is
% set to Incorporated and whose Target Release is defined will be implemented.
% When scope management occurs, the Target Release Version Number can be
% increased so the item will remain in the Vision document but will be
% scheduled for a later release.

\subsection{Przypisane do}

% In many projects, features will be assigned to "feature
% teams" responsible for further elicitation, writing the software
% requirements and implementation. This simple pull down list will help everyone
% on the project team better understand responsibilities.

\subsection{Przyczyna}

% This text field is used to track the source of the requested
% feature. Requirements exist for specific reasons. This field records an
% explanation or a reference to an explanation. For example, the reference might
% be to a page and line number of a product requirement specification, or to a
% minute marker on a video of an important customer interview.

\section{Historia zmian}

\begin{verbatim}

$Log: $

\end{verbatim}

\end{document}


