Changeset 943

Timestamp:

Jun 9, 2004, 6:05:58 AM (22 years ago)

Author:

eugene

Message:

SDRS changes to psError wording
SRS changes: shall to must

Location:

trunk/doc/pslib

Files:

• psLibSDRS.tex (modified) (3 diffs)
• psLibSRS.tex (modified) (7 diffs)

trunk/doc/pslib/psLibSDRS.tex

@@ -1 @@
-%%% $Id: psLibSDRS.tex,v 1.53 2004-06-08 20:12:36 price Exp $
+%%% $Id: psLibSDRS.tex,v 1.54 2004-06-09 16:05:58 eugene Exp $
 \documentclass[panstarrs]{panstarrs}
 
@@ -949 +949 @@
 PSLib and any project needed to use PSLib must define the necessary
 error codes and associated message strings.  An array of error codes
-may be registered with the PSLib error handler using a private
-function:
+may be registered with the PSLib error handler using the function:
 \begin{verbatim}
 void psErrorRegisterSet(const psErrorDescription *errors, int nerror);
@@ -962 +961 @@
 \end{verbatim}
 PSLib internal errors must be registered with the function
-psErrorRegister, which should be called as part of the program
-initialization to set up the error codes.  It is left to the external
-project to produce their own error registration functions which must
-also be called during initialization. There is a clear need to
-coordinate the choice of error numbers.  It is expected that error
+\code{psErrorRegisterSet}, which should be called as part of the
+program initialization to set up the error codes.  It is left to the
+external project to produce their own error registration functions
+which must also be called during initialization. There is a clear need
+to coordinate the choice of error numbers.  It is expected that error
 code ranges for different projects must be managed by the Project
 Office within Pan-STARRS.

trunk/doc/pslib/psLibSRS.tex

@@ -1 @@
-%%% $Id: psLibSRS.tex,v 1.4 2004-04-23 21:57:43 eugene Exp $
+%%% $Id: psLibSRS.tex,v 1.5 2004-06-09 16:05:58 eugene Exp $
 \documentclass[panstarrs]{panstarrs}
 
@@ -79 +79 @@
 \paragraph{Languages}
 
-Source code shall be in C.  All source code shall be compiled with
+Source code must be in C.  All source code must be compiled with
 `gcc' version v2.95 or higher.
 
-Scripting language shall be in \tbd{Python, version TBD}. 
+Scripting language must be in \tbd{Python, version TBD}. 
 
 \paragraph{Interfaces}
 
-Access to low-level Library functions shall be provided via C APIs
+Access to low-level Library functions must be provided via C APIs
 consisting of the function calls and the defined data structures and
-other data types.  Access to high-level functions shall be provided
+other data types.  Access to high-level functions must be provided
 via C APIs as well as SWIG interfaces, where specified.  Access to
-processing jobs shall be available via the UNIX shell.
+processing jobs must be available via the UNIX shell.
 
 \paragraph{Coding Standards} 
 
-The C code shall comply with ANSI Standard C99.  Because the delivered
-code is required to run on UNIX machines, the delivered code shall be
+The C code must comply with ANSI Standard C99.  Because the delivered
+code is required to run on UNIX machines, the delivered code must be
 in compliance with the language-independent UNIX operating system
 standard POSIX (Open Group Based Specifications Issue 6, IEEE Std
-1003.1, 2003).  Source code files shall use the UNIX line-break
-convention (line-feed only).  C coding style shall adhere to the
+1003.1, 2003).  Source code files must use the UNIX line-break
+convention (line-feed only).  C coding style must adhere to the
 standard defined in the document 'Pan-STARRS C-coding standard'
-(PSDC-430-004).  \tbd{Python coding shall follow the Python standard
+(PSDC-430-004).  \tbd{Python coding must follow the Python standard
 defined in the document TBD}.
 
@@ -179 +179 @@
 \paragraph{Commenting and Documentation}
 
-Commenting of delivered C and Python code shall follow the C and
-Python coding standards and shall provide tags for Doxygen
+Commenting of delivered C and Python code must follow the C and
+Python coding standards and must provide tags for Doxygen
 interpretation of the comments and program structures.
 
 Documentation for the IPP consists of source code documentation and
-user documentation.  Source code documentation shall be generated with
-Doxygen from the in-line comments and shall be provided as HTML,
+user documentation.  Source code documentation must be generated with
+Doxygen from the in-line comments and must be provided as HTML,
 Latex, and man pages.  User documentation includes the API usage for
 the modules and library functions as well as user interface
 description for the higher-level architectural systems.  User
-documentation shall be delivered as PDF documents.
+documentation must be delivered as PDF documents.
 
 \paragraph{Version Control}
 
-Source code version control shall be implemented with CVS.  
+Source code version control must be implemented with CVS.  
 
 \paragraph{CSCI Deliverable}
 
 All final source code generated for the IPP is to be delivered via
-CVS, including the test code.  CVS revision history shall be included
+CVS, including the test code.  CVS revision history must be included
 and made available via CVS.
 
 \paragraph{Platform architectures and operating systems}
 
-Makefiles shall be provided with appropriate flags set so that all
+Makefiles must be provided with appropriate flags set so that all
 code compiles without warnings under 'gcc -Wall' for the following
 platform architectures and operating systems:
@@ -278 +278 @@
 \section{Test Verification}
 
-A testing regime shall be implemented to demonstrate the working state
-of the provided software.  Certain tests as specified shall be
+A testing regime must be implemented to demonstrate the working state
+of the provided software.  Certain tests as specified must be
 performed by MHPCC, with code release contingent on success.  Other
 specified tests will be performed by IfA to verify the validity of the
@@ -288 +288 @@
 \subsection{Software Configuration Tests}
 
-MHPCC shall test the validity of the software configuration,
+MHPCC must test the validity of the software configuration,
 specifically to check that the code can be compiled on the specified
 platforms and that the compilation produces no errors or warnings,
@@ -295 +295 @@
 \subsection{Software Integrity Tests}
 
-MHPCC shall test the integrity of the software, specifically to check
+MHPCC must test the integrity of the software, specifically to check
 that the code does not produce memory leaks, segmentation faults.
 
 \subsection{Basic Unit Tests}
 
-MHPCC shall perform basic unit tests with sample input data and known
+MHPCC must perform basic unit tests with sample input data and known
 output results, including invalid input data to test error handling.
 These tests should exercise the complete range of module options.
@@ -306 +306 @@
 \subsection{Detailed Functional Analysis}
 
-IfA shall perform detailed tests with a wide range of input data and
+IfA must perform detailed tests with a wide range of input data and
 compare the results with existing software system.