\chapter{Conclusions}
\markboth{Conclusions}{}

In this work, two contributions are that,

\begin{enumerate}
\item \program{WD-pic} was implemented and
\item a case study of using a program's user's manual as the program's  
requirement specification was carried out.
\end{enumerate}
 
We have the following conclusions.

First, \program{WD-pic} follows a new paradigm for WYSIWYG direct-manipulation 
picture drawing programs. It has the following advantages.
\begin{itemize}
\item It inherits all the advantages that the batch mode \program{pic} program 
has and it fixes the disadvantages of the batch and most WYSIWYG picture 
drawing programs.
\item It provides convenient direct manipulations and directly editing the 
internal representation of picture to users. 
\item Input by mouse or by keyboard are fully interchangeable. The user does 
not have to inform the application where its next input is coming from. 
\item It minimizes the mouse movement.
\end{itemize}

However, because \program{WD-pic} is built on top of the \program{pic} 
program, its features are limited to the features that \program{pic} can 
provide. Besides this, the current implementation of \program{WD-pic} also has 
some other shortcomings that are independent of \program{pic}. 
\begin{itemize}
\item Changing the sizes and locations of objects cannot be done by direct 
mouse manipulations. 
\item \usecase{Copy}, \usecase{paste}, \usecase{cut}, \usecase{undo}, and 
\usecase{redo} do not work with the canvas. 
\item Changing attributes of constructs cannot be done by direct 
manipulations. 
\item Pictures cannot be output in a standard graph format. 
\end{itemize}

The first two are not real limitations. They can be overcome by using the 
built-in text editor. They are not difficult to fix based on the current 
implementation. The latter two are the challenges for the designer of the next 
version.

Second, the case study shows it is useful to write the user's 
manual during the requirement phase. A non-ambiguous, use-case-centered user's 
manual helps the whole process of software development.

\begin{itemize}
\item The user's manual makes an excellent requirement specification for CBSs. 
It specifies the what-not-how of the CBS at the users level. 

\item It helps requirements elicitation by helping both the customer and the 
software engineer to see what is wanted. However, it cannot solve the problem 
that sometimes, the customer does not know what he or she wants.

\item The user's manual is a good validation tool; it helps the customer to 
verify the requirements specification and helps software engineer to verify 
the design and implementation. 

\item The user's manual as a repository of use cases, and a useful source of a 
test plan and covering test cases.

\item There is no need to write the user's manual again after the development 
finished. 
\end{itemize} 

The reader should remember that this case study of writing a
requirements specification in the form of a user's manual is just that,
a case study. Certainly, the case study was a success in that
\begin{itemize}
\item the user's manual describes the product completely,
\item the user's manual provided a covering set of test cases,
\item the user's manual helped the programmer meet the
overall schedule even though writing it caused a schedule slip in the
requirements phase, and
\item the customer is satisfied with both the end product
and the match between the manual and the product.
\end{itemize}

However, the success could have been the result of a bunch
of other factors including
\begin{itemize}
\item the abilities of the programmer and the client,
\item the client's previous experience with the application,
\item the user-interface centeredness of the application,
\item and the medium size of the application.
\end{itemize}
Therefore, it is not correct to conclude that user's manuals will
always make good requirements specifications and that writing the
user's manual as the requirements specification will always help a
project to be successful.

There is no completely satisfactory way to validate any software
engineering method. In order to be able to afford to do a statistically
significant controlled experiment validating the effectiveness of any
method, we have to use many replications of small, toy versions of a
problem on which the method is applicable. However, then it is not
certain that the conclusions are useful. We know that methods that work
on toy problems, of the size needed for a controlled experiment, do not
necessarily scale up to industrial-sized problems. Hence, we are left
to doing many introspective case studies on applications of the method
to industrial-sized examples, and reporting the lessons learned. This
thesis is only one of several being carried out by this author's
advisor.

This case study should be looked at for its lessons learned. It can
guide anyone who wishes to try the approach out his or her own
development. If the reader believes that user's manuals make good
requirements specifications, he or she should attempt another case
study and report what happens.
   





