\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 :: Use-Case Specification}


\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).

% To customize automatic fields (which display a gray
% background when selected), select File>Properties and replace the Title,
% Subject and Company fields with the appropriate information for this
% document.    After closing the dialog,
% automatic fields may be updated throughout the document by selecting
% Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field
% and press F9.  This must be done
% separately for Headers and Footers. 
% Alt-F9 will toggle between displaying the field names and the field
% contents.  See Word help for more
% information on working with fields.] 


\section{Nazwa Use Case}

% The following template is provided for a Use-Case
% Specification, which contains the textual properties of the use case. 
% This document is used with a requirements management tool, such as Rational
% RequisitePro, for specifying and marking the requirements within the use case
% properties

% The diagrams of the use case can be developed in a visual
% modeling tool, such as Rational Rose. A use-case report (with all
% properties) may be generated with Rational SoDA.  For more information, see the tool mentors in the Rational
% Unified Process.

\subsection{Skrócony opis}

% The description should briefly convey the role and purpose
% of the use case.  A single paragraph
% should suffice for this description.

\section{Czynności}

\subsection{Czynności podstawowe}

% This use case starts when the actor does something.  An actor always initiates use Cases.  The use case should describe what the actor
% does and what the system does in response. 
% It should be phrased in the form of a dialog between the actor and the
% system.

% The use case should describe what happens inside the system,
% but not how or why.  If information is
% exchanged, be specific about what is passed back and forth.  For example, it is not very illuminating to
% say that the Actor enters customer information. It is better to say the Actor
% enters the customers name and address. 
% A Glossary of Terms is often useful to keep the complexity of the use
% case manageabležyou
% may want to define things like customer information there to keep the use case
% from drowning in details. 

% Simple alternatives may be presented within the text of the
% use case.  If it only takes a few
% sentences to describe what happens when there is an alternative, do it directly
% within the Flow of Events section. 
% If the alternative flows are more complex, use a separate section to
% describe it.  For example, an Alternative
% Flow subsection explains how to describe more complex alternatives. 

% A picture is sometimes worth a thousand words, though there
% is no substitute for clean, clear prose. 
% If it improves clarity, feel free to paste graphical depictions of user
% interfaces, process flows or other figures into the use case.  If a flow chart is useful to present a
% complex decision process, by all means use it! 
% Similarly for state-dependent behavior, a state-transition diagram often
% clarifies the behavior of a system better than pages upon pages of text.  Use the right presentation medium for your
% problem, but be wary of using terminology, notations or figures that your
% audience may not understand.  Remember
% that your purpose is to clarify, not obscure.

\subsection{Czynności alternatywne}

\subsubsection{< First Alternative Flow >}

% More complex alternatives should be described in a separate
% section, which is referred to in the Basic Flow subsection of Flow of
% Events section.  Think of the Alternative
% Flow subsections like alternative behaviorž each alternative flow
% represents alternative behavior, many times because of exceptions that occur in
% the main flow.  They may be as long as
% necessary to describe the events associated with the alternative behavior.  When an alternative flow ends, the events of
% the main flow of events are resumed unless otherwise stated.

\paragraph{< An Alternative Sub-flow >}

% Alternative flows may, in turn, be broken down into
% subsections if it improves clarity.

\subsubsection{< Second Alternative Flow >}

% There may be, and most likely will be, a number of
% alternative flows in a use case.  Keep
% each alternative separate to improve clarity. 
% Using alternative flows improves the readability of the use case, as
% well as preventing use cases from being decomposed into hierarchies of use
% cases.  Keep in mind that use cases are
% just textual descriptions, and their main purpose is to document the behavior
% of a system in a clear, concise, and understandable way.

\section{Inne wymagania}

% A special requirement is typically a non-functional
% requirement that is specific to a use case, but is not easily or naturally
% specified in the text of the use cases event flow. Examples of special
% requirements include legal and regulatory requirements, application standards,
% and quality attributes of the system to be built including usability,
% reliability, performance or supportability requirements. Additionally, other
% requirementsžsuch
% as operating systems and environments, compatibility requirements, and design
% constraintsžshould
% be captured in this section.

\subsection{< First Special Requirement >}

\section{Warunki wstępne}

% A pre-condition of a use case is the state of the system
% that must be present prior to a use case being performed.

\subsection{< Pre-condition One >}

\section{Warunki końcowe}

% A post-condition of a use case is a list of possible states
% the system can be in immediately after a use case has finished.

\subsection{< Post-condition One >}

\section{Extension Points}

% Extension points of the use case.

\subsection{<Name of Extension Point>}

% Definition of the location of the extension point in the
% flow of events.

\section{Historia zmian}

\begin{verbatim}

$Log: $

\end{verbatim}

\end{document}


