1. “Substitute “damn” every time you’re inclined to write “very.” Your editor will delete it and the writing will be just as it should be.” Here, Twain offers some advice that can help writers young and old learn to express themselves more clearly. By eliminating unnecessary words, you’ll make your writing more precise and ultimately more effective, even if today we don’t find damn as objectionable as they did in Twain’s time.

2. “Write without pay until somebody offers to pay.” If you’re going to be a writer, your reason for wanting to be a writer should always be because you love it. If you’re in it for the money you might wind up sorely disappointed.

3. “The time to begin writing an article is when you have finished it to your satisfaction. By that time you begin to clearly and logically perceive what it is that you really want to say.” As a writer, you won’t have too many times in your life when the first draft of your story will be the one you ultimately end up going with. As Twain suggests here, the first draft is merely a chance to get your ideas on paper, after which you can really begin crafting a clear, well-organized and intelligent story.

4. “Anybody can have ideas–the difficulty is to express them without squandering a quire of paper on an idea that ought to be reduced to one glittering paragraph.” Why say something in a page that you can say in a sentence? Economy of words is still considered a value in writing today, and was a value that Twain often espoused. If you can’t yet limit yourself to a few words, work at it. The best writers can say a whole lot with very little.

5. “It was by accident that I found out that a book is pretty sure to get tired along about the middle and refuse to go on with its work until its powers and its interest should have been refreshed by a rest and its depleted stock of raw materials reinforced by lapse of time.” As in many creative fields, writers are subject to bouts of writer’s block and burnout. The cure? Twain offers it here: a break. Sometimes taking a break from a project, for a few hours or a few months, will let you return to it with more ideas and a fresh perspective. Twain often left books for years at a time only to return to them later, or sometimes, never again.

6. “Great books are weighed and measured by their style and matter, and not the trimmings and shadings of their grammar.” While an understanding of grammar is surely an important asset to have as a writer, good grammar doesn’t make a good story. Focus more on your ideas, style and story, and hammer out the details of grammar later.

7. “As to the Adjective: when in doubt, strike it out.” Twain felt there was no virtue in overly flowery, descriptive prose. While everyone has a unique style, using more adjectives than necessary likely won’t improve the quality of the story. Quality over quantity should always be the rule when it comes to writing.

8. “I notice that you use plain, simple language, short words and brief sentences. That is the way to write English–it is the modern way and the best way. Stick to it; don’t let fluff and flowers and verbosity creep in.” While not everyone believes this is the best style, and many writers have had successful careers with fluff and flowers, in general, being clear, concise and to the point in your writing is the best route. If your writing becomes too superfluous or showy, you may bore readers and distract from the point of your story.

9. “Don’t say the old lady screamed. Bring her on and let her scream.” Here, Twain is asking writers to do something fairly straightforward but sometimes difficult to accomplish. You don’t need to tell your story as though you were not there, it will distance your readers. Instead, describe a scene as if it were happening right in front of you. It will make your writing far more interesting.

10. “I don’t give a damn for a man that can only spell a word one way.” While Twain might have seemed the type to shy away from such indulgences as creative spellings, here he encourages writers to play with language. After all, many words in the English language came from writers like Shakespeare who simply made them up. Grammar and spelling are fine, but don’t be afraid to have a little fun with the language as well.

11. “The difference between the right word and the almost right word is the difference between lightning and a lightning bug.” While this might be a bit of an extreme example, choosing the right words for what you mean in a piece of writing is essential. One word might be a synonym for another, but it doesn’t mean the two have exactly the same meaning or connotation. Spend some time working on your language to make sure each word is just right for where you’ve placed it.

12. “The more you explain it, the more I don’t understand it.” Here, again, Twain presses for writers to be more clear, concise and brief when writing. You could write pages and pages on something and have it be more obtuse than one, simple, clearly written paragraph. If you’re struggling, start with the long version and figure out just what you can omit or change without changing the point.

Source: http://www.onlineuniversities.com/blog/2010/07/12-timeless-writing-tips-from-mark-twain/

Tweet This Post Buzz This Post Delicious Digg This Post

http://www.author-it.com/
Help Authoring Tools (HATs) that are integrated with Microsoft Word
Doc-To-Help
Write or import content in Microsoft Word®, HTML, or Doc-To-Help’s editor and then publish professional quality outputs for desktop, Web, and print use. That’s the power of Doc-To-Help. Just focus on the content; Doc-To-Help produces impressive and useful deliverables for virtually any communication needs you may have.
http://www.componentone.com/SuperProducts/DocToHelp/
XDK
Turning Word into an XML Workshop!!
At last… a new generation authoring tool for documentation professionals. It’s a beautiful marriage of advanced technology with clean-and-simple design. It’s called XDK and it will empower you to efficiently create online documents and help systems that will really deliver for your readers.
XDK is a serious authoring tool. It has got to be one of the easiest tools to use, yet has so many power- features borne from the experience of supporting over 40,000 HDK customers worldwide. Here’s just a snapshot of some of the highlights:
Utilizing the power of Word
Today, Word is a reasonably powerful document-editing tool. It delivers many clever design and proofing tools and it is able to integrate other office documents. Rather than give you a tool with an inferior editing environment and an unfamiliar interface, we’ve turned Word into a complete XML workshop.
XDK is a fully integrated dynamic pane within Word, so you get all the benefits of Word’s extended functionality, without the learning curve. This means better results in less time for you!
Getting Word to deliver XML
XDK uses the latest in online technology and formatting, XML. Only XML gives you the greatest degree of control over how your online documents will look. You also get to leverage off all the additional functionality XML provides. Even if you’ve got complex nested tables with bulleted lists and graphics, XDK will deliver an accurate edition for online.
And since XML is so powerful, when it comes to delivering your online documents and help systems, XDK can instantly create multiple editions using different technologies and designs from the one-source. You’re guaranteed that your project will look great and perform well, no matter if it’s for the Internet, Intranet, or software application Help.
http://www.vmtech.com/xdk.htm
Help Producer
MGTEK Help Producer is a document conversion tool for that allows you to create professional HTML help systems from a Microsoft® Word® document.
Help Producer is an add-in that is seamlessly integrated into the user interface of Microsoft Word, which makes authoring a help file as easy as writing a regular Word document. With a click on a button, Help Producer will analyze your Word document and generate all files necessary to build a help file, such as project files, table of contents files, index files, HTML topic files, and graphics.
Help Producer can take advantage of many of Microsoft Word’s existing editing and formatting features, including colors, fonts, styles, lists, tables, embedded pictures or objects, and even auto-shapes. In addition to the ability to leverage off the authoring features offered by Microsoft Word, Help Producer has many innovative and exciting features that will help technical writers create professional help files.
http://www.mgtek.com/helpproducer/

Converters for Microsoft Word, FrameMaker, and XML-DITA documents

ePublisher
The ePublisher Platform allows technical communicators to achieve their business goals by:
Automatically converting and publishing documentation from one format (FrameMaker, Microsoft Word, DITA) to another desired format, such as: Eclipse Help, WinHelp, Java Help, HTML Help, PDF, XHTML, HTML and Confluence, Media, MoinMoin Wiki.
Utilizing a design function that allows an administrator or designer to choose the look, feel and behavior of the final content.
Producing documentation that allows users of product documentation to access the information they need quickly, improving overall user experience.
Reducing the need for documentation stored outside of the approved documentation architecture.
Alleviating the need to purchase multiple software packages in order to publish or convert your content from multiple formats.
http://www.webworks.com/Solutions/By_Role/Technical_Communicator/
ReWorx
From Word to Web with zero coding!!
ReWorx is a ‘beautifully simple’ way to create full-featured online document systems automatically from within Word.
Using only six steps, you are able to produce powerful online document systems automatically from within Word. ReWorx will convert your Word documents using the latest XML technology for reliable formatting and enhanced end-user functionality. And the great thing is, you don’t have to know anything about HTML, XML or the Web! Simply create your documents in Word and then use ReWorx to republish them to the Internet, Intranet or Help.
True single-source for print and online
Since ReWorx does such a brilliant job of creating online document systems from Word documents, you can continue to do all your development within Word. This means that from the one source document, you are able to create both printed and online output. One source file to maintain means less work for you and fewer mistakes… your print and online versions are effectively locked together.
http://www.vmtech.com/reworx.htm
Mif2Go
Mif2Go is the fastest, easiest, and least expensive way to convert your FrameMaker files for online Help, Word, and the Web.
Fast, accurate conversion from FrameMaker MIF to HTML, XML, printable Word RTF, HTML Help, and many more Help formats!
FrameMaker plus Mif2Go does it all, faster, better, and cheaper. Convert single files or entire books in one operation.
We support Windows FrameMaker 8.0, 7.2, 7.1, 7.0, 6, and 5.5 fully with our plugin, and convert MIF produced on any platform from FM 4 on.
WinNT/2K/XP are preferred, but Win9x/ME/Vista are also supported; sorry, UNIX and Mac versions are not available at this time. Mif2Go does, however, run on OS X under Parallels (or other virtualization environments) with a Windows version of FrameMaker.
http://www.omsys.com/dcl/mif2go_main.htm
Word-2-CHM
A powerful CHM creator/generator helping you to create professional HTML help. Convert Word document (.doc, .rtf, .htm, etc.) to perfect HTML help or CHM e-book without any HTML or CHM skills. Make CHM file in seconds with a single click. Keep the format/style/layout of the original document. Create topic tree according to the outline of the Word document.
http://www.macrobject.com/en/word-2-chm/index.htm
Word-2-Web/HTML
A powerful Web online document creator/generator help you to create professional Web help. Convert Word document (.doc, .rtf, .htm, etc.) to perfect Web help and full fit for your web site. Make online help to be integrated into your web site in seconds with a single click. Keep the format/style/layout (include images and tables) of the original Word document. Create topic tree according to the outline of the Word document.
http://www.macrobject.com/en/word-2-web/index.htm
CHM-2-Web
A powerful CHM convertor helping you to create Web help on your web site from HTML help. Convert CHM to perfect Web help in seconds. Keep format/styles of original compiled HTML Help and create topic tree.
http://www.macrobject.com/en/chm-2-web/index.htm
CHM-2-Word
A powerful CHM convertor helping you to create Word document from HTML help. Convert CHM files to perfect Word document without any HTML or CHM skills. Make Word document from CHM file in seconds with a single click. Keep the format/style/layout (include images and tables) of the original CHM file. Embed all images into Word document and no external files are required.
http://www.macrobject.com/en/chm-2-word/index.htm
CHM-2-HTML
A powerful CHM convertor helping you to create HTML document from HTML help. Convert CHM files to perfect HTML document without any HTML or CHM skills. Make HTML document from CHM file in seconds with a single click. Keep the format/style/layout (include images and tables) of the original CHM file. Embed all images into HTML/MHT document and no external files are required.
http://www.macrobject.com/en/chm-2-html/index.htm
WordToWeb
The Word to HTML Converter that integrates directly with Microsoft Word
WordToWeb 2.5 is a Word to HTML converter that makes it easy and automatic to create fully formatted, linked HTML publications from within Microsoft Word. WordToWeb picks up where Word’s built-in “Save as HTML” feature leaves off–completely automating the Word document to HTML conversion process and saving hours of tedious HTML editing, linking, formatting and other conversion issues.
Need to convert a technical manual or other long Word document into HTML, complete with a table of contents, index and easy frame-based navigation? Or perhaps you need to convert lots of existing Word documents to HTML, get them online and format them to match the design and layout of your website…
WordToWeb’s easy-to-use wizard interface makes it a breeze to convert any Word document to HTML!
http://www.solutionsoft.com/w2w.htm

Assembly, component, and code documentation Tools

Doc-O-Matic Professional
Doc-O-Matic Professional enables you to develop, manage and maintain both source code documentation and Help authoring projects. With its advanced management and QA features and its wide variety of output formats its suitable for any kind of project, no matter how big.
This version supports C/C++, C#, Delphi, VB.NET, IDL, Java, ASPX, JSP, JavaScript, Matlab and PHP. Source code documentation can be done in-source and off-source, both Unicode and ANSI source files are supported.
Doc-O-Matic Professional makes it possible to create Online Help and printable documents from a single source, it supports PDF, Web Help/browser based Help, HTML Help, Help 2, Windows Help and XML output. Documentation authoring and output design are completely separated, targeting different audiences with multiple configurations and setups has never been easier.
http://www.doc-o-matic.com/editions_professional.html
Document! X
Document! X automates the process of creating and maintaining documentation for a wide range of solution elements:
.NET Framework Assemblies (.NET Framework 1.0, 1.1, 2.0, 3.0, 3.5 and 4.0);
Compiled COM Components and Controls;
COM Type Libraries;
ASP.NET Ajax Javascript;
Access, SQL Server and other Databases with an OLEDB driver
http://www.innovasys.com/products/dx2010/overview.aspx
West Wind Html Help Builder
Create end user or developer documentation and help files quickly and easily with Help Builder. Help Builder’s unique environment focuses on creating documentation content quickly with an interactive editor using design templates that let you concentrate on content creation. Create documentation for Html Help 1.0 and 2.0, Html and Word formats. If you’re a developer you can quickly import and document .NET, FoxPro and COM objects, Web Services, Sql Server and FoxPro databases. Help Builder is your one stop documentation solution.
http://www.west-wind.com/wwHelp/
VSdocman
VSdocman Code Commenter and Generator of Class Documentation for VB .NET and C#
Generate documentation for your .NET code on professional level. See how easy the commenting can be with powerful comment templates and sophisticated WYSIWYG comment editor.
Create MSDN-like assembly documentation, IntelliSense and F1 context sensitive help for your Visual Basic .NET and C# projects (including ASP .NET).
http://www.helixoft.com/vsdocman/overview.html
VBdocman
VBdocman Commenter and Generator of Technical Documentation for VB 6
Generate technical documentation from your Visual Basic 6 source code with single click. Let the comment editor create complex JavaDoc comments.
VBdocman creates documentation in various formats with the table of contents, index, topics, cross-references, and context sensitive help.
http://www.helixoft.com/vbdocman/overview.html
GenHelp and GenHelp Pro
GenHelp and GenHelp Pro are new generation tools to assist in documenting code and creating help files.
They take source files and import them to produce a file that can be used to create several forms of documentation.
The files provided can then be shipped out with components, giving a much more professional product.
GenHelp can also produce simple normal help files without requiring knowledge of rich text coding.
http://www.frasersoft.net/genhelp/index.htm
TwinText™
TwinText™ is a simple yet powerful source code documentation tool. It allows you to create documentation based on your code comments for a wide range of programming languages and code commenting styles, all without tags, complex rules, or XML.

Document from the source
ONE TOOL, multiple languages
20+ documentation output styles
Windows and Unix file handling
Supports virtually any comment box
Scales up to thousands of files
GUI and command line interface
http://www.ptlogica.com/TwinText/overview.htm
AS2Doc Pro
AS2Doc is a powerful, easy to use and fast documentation generator for your ActionScript 2 based classes.
AS2Doc reads your sourcecode, included comments and creates a rich content documentation automaticly!
You can choose various options to customize your documentation. Various output formats are supported by using AS2Doc Styles (XSL). You can even write your own style for any custom output format!
http://www.as2doc.com/
VisDoc
VisDoc generates html documentation from ActionScript 2.0, 3.0 and Java class files
From December 2009 VisDoc is free (as in beer).
VisDoc integrates a smart processor to parse class files – you don’t need to prepare or rewrite your classes. Even if you don’t use doc comments, you can generate handy class documentation with a Table of Contents.
Class relations mean everything. VisDoc links interfaces, superclasses and their methods and properties to give a quick overview how classes are connected.
Flexibility is built in: documentation pages are formatted with editable templates (XSL and CSS). Just customize to have your own layout and style.
Changed some classes? Start up the application and hit the Process button – VisDoc remembers all your settings from the last time. You can also save these settings in a project file, so you can use multiple projects without changing settings inbetween.
For even more speed, update only modified or added files. VisDoc detects which files have been updated since the last run, and can process only those.
http://visiblearea.com/visdoc/
Sandcastle
Sandcastle produces accurate, MSDN style, comprehensive documentation by reflecting over the source assemblies and optionally integrating XML Documentation Comments. Sandcastle has the following key features:
• Works with or without authored comments
• Supports Generics and .NET Framework 2.0
• Sandcastle has 2 main components (MrefBuilder and Build Assembler)
• MrefBuilder generates reflection xml file for Build Assembler
• Build Assembler includes syntax generation, transformation..etc
• Sandcastle is used internally to build .Net Framework documentation
http://www.microsoft.com/downloads/details.aspx?familyid=E82EA71D-DA89-42EE-A715-696E3A4873B2&displaylang=en#Overview
ROBODoc
It is difficult to keep documentation in sync with source code. One of the reasons is that documentation and source code are stored in separate files that usually also require different editors to edit them. ROBODoc solves this problem. Specially formatted documentation headers are extracted from source files and stored in a different file. ROBODoc can reformat the documentation in HTML, XML DocBook, TROFF, ASCII, LaTeX or RTF format. Indirectly you can convert to pdf and windows help format.
This way ROBODoc allows you to include your documentation in the source code. You can edit the source code as well as the documentation in a single file with your favourite editor. This makes it easier to keep your documentation in sync with your source code.
ROBODoc can be used to document functions, methods, classes, variables, makefile entries, system tests, and anything else you can think of.
ROBODoc works with C, C++, Fortran, Perl, shell scripts, Assembler, DCL, DB/C, Tcl/Tk, Forth, Lisp, COBOL, Occam, Basic, HTML, Clarion, and any other language that supports remarks.
http://www.xs4all.nl/~rfsber/Robo/robodoc.html
Javadoc
Javadoc is a tool for generating API documentation in HTML format from doc comments in source code.
http://java.sun.com/j2se/javadoc/
HeaderDoc
HeaderDoc is a tool for generating HTML reference documentation from comments in headers, and source code written in C, C++, Objective-C , Java, JavaScript, Pascal, PHP, Perl, MIG, and shell scripts. It is written in Perl for easy portability. Similar to JavaDoc, it allows developers to easily document their interfaces and export that information into HTML.
http://developer.apple.com/opensource/tools/headerdoc.html
Doxygen
Doxygen is a documentation system for C++, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavors), Fortran, VHDL, PHP, C#, and to some extent D.

It can help you in three ways:

It can generate an on-line documentation browser (in HTML) and/or an off-line reference manual (in ) from a set of documented source files. There is also support for generating output in RTF (MS-Word), PostScript, hyperlinked PDF, compressed HTML, and Unix man pages. The documentation is extracted directly from the sources, which makes it much easier to keep the documentation consistent with the source code.
You can configure doxygen to extract the code structure from undocumented source files. This is very useful to quickly find your way in large source distributions. You can also visualize the relations between the various elements by means of include dependency graphs, inheritance diagrams, and collaboration diagrams, which are all generated automatically.
You can even `abuse’ doxygen for creating normal documentation (as I did for this manual).
Doxygen is developed under Linux and Mac OS X, but is set-up to be highly portable. As a result, it runs on most other Unix flavors as well. Furthermore, executables for Windows are available.
http://www.stack.nl/~dimitri/doxygen/
DoxyS
DoxyS, a C++ documentation tool.
DoxyS is a code documentation tool for C++/C. DoxyS strives to yield a very professional looking output, presenting the the code in a structured easy to navigate set of HTML pages. Easy to use: Just navigate to the root of your code directory and type doxys.
Currently it runs on Windows and Linux, but should be quite portable.
Main features
Generated output reflects the code directory structure.
Layers of abstraction with heavy use of overview tables providing names and brief descriptions of classes, functions etc. Inspired by Microsoft documentation.
Wiki like syntax for writing directory level documentation and related documentation pages or even design documents.
Inheritance, collaboration graphs
Good support for overloded functions and template specializations.
Incremental search.
http://www.doxys.dk/doxys_homepage/index.html
VBDoxygen
VB doxygen is a Visual Basic addin that converts VB code into java like syntax for processing through the doxygen documentation generator. This allows the production of advanced documentation for Visual Basic.
http://vbdoxygen.sourceforge.net/
Natural Docs
Natural Docs is an open-source documentation generator for multiple programming languages. You document your code in a natural syntax that reads like plain English. Natural Docs then scans your code and builds high-quality HTML documentation from it.
http://www.naturaldocs.org/
For more Source Code Documentation Generators, refer to the following wikipedia link:
http://en.wikipedia.org/wiki/Comparison_of_documentation_generators

Tools related to Linux and Mac OS

QuickHelp
Author help on Macintosh or Windows, then deploy it on both platforms. With conditional help topics and text, the same help file can present customized help based on the specific platform or your product edition. Help information can even be parameterized when your application is installed or at runtime making it easy to fully customize the user experience.
QuickHelp authoring requires no programming experience or HTML knowledge. In minutes, you can begin creating a professional help system that works with any Macintosh or Windows application regardless of the development system or programming language used to create it.
http://www.excelsoftware.com/quickhelpplatforms.html
HelpLogic
Available for Mac OS X, HelpLogic’s award-winning design removes the development headaches usually associated with help authoring. With time-saving features like the built-in Visual TOC Builder, Project Workshop, HTML Editor, Link Manager and more, HelpLogic is the ideal solution for cross-platform software developers, help authors, web site designers, and documentation writers.
http://www.ebutterfly.com/helplogic/
Simple Help Editor
Smart software developers know the importance of good documentation. Simple Help Editor helps you create great online Help the smart way. It offers more power and flexibility than ever before.
Simple Help Editor 4.1 makes it simple to create and re-use content for different platforms, different products, or different versions. You can produce Help content for viewing in Apple Help Viewer, Windows’ HTML Help viewer, or a Web browser. Changing from one to another can be as easy as a few mouse clicks.
http://www.pandaware.com/simple/index.html
HelpBlocks
Anthemion HelpBlocks is an HTML authoring tool specifically designed for writing cross-platform application help, generating Microsoft HTML Help and wxWidgets HTML Help files.
With HelpBlocks, you can:
easily create a hierarchical structure appropriate for your manual;
write HTML rapidly with the aid of a syntax-highlighting editor, macro preprocessor and HTML element catalog;
preview your help file as you work;
create a keyword index for your help file;
generate and view Microsoft HTML Help and wxWidgets HTML Help files.
Why not also try our dialog editor for wxWidgets – DialogBlocks. Cross-platform dialog editing made as simple as – well, wxWidgets itself.
HelpBlocks provides tools to help make writing your manual as straightforward as possible. Auto-complete and an attribute editor speed up HTML element insertion. Specialised dialogs allow quick selection of page references, images and colours. Project and page templates make light work of creating new projects and pages.
If you have an existing MS HTML Help project, you can import it when you create a new HelpBlocks project.
And of course, HelpBlocks is cross-platform – edit your files on Windows, Linux or Mac.
http://www.helpblocks.com/

Tweet This Post Buzz This Post Delicious Digg This Post

Source: http://www.htp.gov.in/ParkingZones.html

Tweet This Post Buzz This Post Delicious Digg This Post

eChallan Status

Campaigns

Traffic Police Station of your area

Statistics

Road Rules

Alternate Routes and so on.

Thanks to the entire team of Hyderabad police for this valiant effort that you have put in we are proud of you. Don’t you agree with me friends?

Regards,
Vivekanand Raula

Tweet This Post Buzz This Post Delicious Digg This Post

1. Scope
This section is divided into the following paragraphs.
1.1 Identification
This paragraph shall contain a full identification of the system and the software to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).
1.2 System overview
This paragraph shall briefly state the purpose of the system and the software to which this document applies. It shall describe the general nature of the system and software; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; identify current and planned operating sites; and list other relevant documents.
1.3 Document overview
This paragraph shall summarize the purpose and contents of this manual and shall describe any security or privacy considerations associated with its use.
2. Referenced documents
This section shall list the number, title, revision, and date of all documents referenced in this manual. This section shall also identify the source for all documents not available through normal Government stocking activities.
3. Software summary
This section is divided into the following paragraphs.
3.1 Software application
This paragraph shall provide a brief description of the intended uses of the software. Capabilities, operating improvements, and benefits expected from its use is described.
3.2 Software inventory
This paragraph shall identify the software files, if any, including databases and data files, that the user is responsible for requesting in order to access the software described in this manual. The identification shall include security and privacy considerations for each file and identification of the software necessary to continue or resume operation in case of an emergency.
3.3 Software environment
This paragraph shall identify the hardware, software, manual operations, and other resources needed to access and use the software. This paragraph is based on the assumption that the software is installed in a computer center or other centralized or networked environment and shall focus on the resources that a user must have to access and use the software in that environment. Included, as applicable, is identification of:
a. Computer equipment that must be present, such as terminals, printers, or other input/output devices
b. Communications equipment that must be present
c. Other software that must be present, such as networking software
d. Forms, procedures, or other manual operations that must be present
e. Other facilities, equipment, or resources that must be present
3.4 Software organization and overview of operation
This paragraph shall provide a brief description of the organization and operation of the software from the user’s point of view. The description shall include, as applicable:
a. Logical components of the software, from the user’s point of view, including databases and data files the user can access, Database Management Systems (DBMSs), and communications paths, and an overview of the purpose/operation of each component
b. Performance characteristics that can be expected by the user, such as:
1) Types, volumes, rate of inputs accepted
2) Types, volume, accuracy, rate of outputs that the software can produce
3) Typical response time and factors that affect it
4) Typical processing time and factors that affect it
5) Limitations, e.g, restrictions on what data may be queried and from what location
6) Error rate that can be expected
7) Reliability that can be expected
c. Relationships of the functions performed by the software with interfacing systems and with the organizations or stations that are sources of input or recipients of output
d. Supervisory controls that can be implemented (such as passwords) to manage the software
3.5 Contingencies and alternate states and modes of operation
This paragraph shall explain the differences in what the user will be able to do with the software at times of emergency and in various states and modes of operation, if applicable.
3.6 Security and privacy
This paragraph shall contain an overview of the security and privacy considerations associated with the software. A warning is included regarding making unauthorized copies of software or documents, if applicable.
3.7 Assistance and problem reporting
This paragraph shall identify points of contact and procedures to be followed to obtain assistance and report problems encountered in using the software.
4. Using the software
This section is divided into the following paragraphs to describe how to prepare inputs to, and interpret output from, the software. If the software has a query capability, this paragraph shall reference section 5 for a description of this capability. If the software can be accessed via terminal, this paragraph shall reference Sections 6 through n to describe terminal processing procedures. Safety precautions, marked by WARNING or CAUTION, is included where applicable.
4.1 Initiation procedures
This paragraph shall contain the procedures that must be followed to initiate use of the software. Included may be information such as sample job request forms or sample control statements.
4.2 Description of inputs
This paragraph is divided into the following subparagraphs.
4.2.1 Input conditions
This paragraph shall describe the conditions to be observed in preparing each type or class of input to the software. The conditions shall include the following, as applicable:
a. Reason for input, such as normal status report, need to update data
b. Frequency of input, such as monthly, on demand
c. Origin of input, such as the organization or station authorized to generate the input
d. Medium of input, such as magnetic tape
e. Related inputs that are required to be entered at the same time as this input
f. Other applicable information, such as priority; security and privacy considerations
4.2.2 Input formats
This paragraph shall illustrate the layout formats to be used in the preparation of inputs to the software and shall explain the information that may be entered in the various sections and lines of each format.
4.2.3 Composition rules
This paragraph shall describe any rules and conventions that must be observed to prepare inputs. The rules of syntax, usage of punctuation, and so on., is explained. The rules shall include the following, as applicable:
a. Input transaction length, such as 100 characters maximum
b. Format conventions, such as all input items must be left-justified
c. Labeling, such as usage of identifiers to denote major data sets to the software
d. Sequencing, such as order and placement of items in the input
e. Punctuation, such as spacing and use of symbols (virgule, asterisk, character combina-tions, and so on.) to denote start and end of input, of data groups, and of fields
f. Restrictions, such as rules forbidding use of particular characters or parameter sets
4.2.4 Input vocabulary
This paragraph shall explain the legal character combinations or codes that must be used to prepare inputs. An appendix may be provided containing an ordered listing of these codes.
4.2.5 Sample inputs
This paragraph shall provide examples that illustrate and explain each type or class of input acceptable by the software. Included is information on the following types of inputs, as applicable:
a. Headers denoting the start of input
b. Text or body of the input
c. Trailers denoting the end of input
d. Portions of the input that may be omitted
e. Portions of the input that may be repeated
4.3 Description of outputs
This paragraph is divided into the following subparagraphs.
4.3.1 General description
This paragraph shall provide the following information, as applicable, for each type or class of output:
a. Reasons why the output is generated
b. Frequency of the output, such as monthly, on demand
c. Any modifications or variations of the basic output that are available
d. Media, such as printout, display screen, tape
e. Location where the output will appear, such as in the computer area or remotely
f. Any additional characteristics, such as priority, security and privacy considerations, associated outputs that complement the information in this output
4.3.2 Output formats
This paragraph shall illustrate and explain the layout of each type or class of output from the software. The following aspects are explained, as applicable:
a. Security and privacy markings
b. Data that may appear in headers
c. Information that may appear in the body or text of the output, including column headings and subsets or sections in the output format
d. Data that may appear in trailers
e. Additional characteristics, such as the meaning of special symbols
4.3.3 Sample outputs
This paragraph shall provide illustrations of each type or class of output from the software. A description of each sample is provided, including, as applicable:
a. Meaning and use of each column, entry, and so on.
b. Source, such as extracted from database, calculated
c. Characteristics, such as when omitted, range of values, unit of measure
4.3.4 Output vocabulary
This paragraph shall describe any codes or abbreviations that appear in the output that differ from those used in the input described in paragraph 4.2.4.
4.4 Use of outputs
This paragraph shall explain the use of the output by the operational area or activity that receives it.
4.5 Recovery and error correction procedures
This paragraph shall list the error codes generated by the software, give their meanings, and describe the corrective actions to be taken by the user. Also included are the procedures to be followed by the user with respect to restart, recovery, and continuity of operations in the event of emergencies.
4.6 Communications diagnostics
This paragraph shall describe the diagnostic procedures available to the user for validating communications and for identifying and classifying problems.
5. Query procedures
This section is prepared for software with a query capability. It is divided into the following paragraphs.
5.1 Database/data file format
This paragraph shall provide a user’s view of the format and content of each database and data file that can be queried. Information such as the following is provided for each data element, as applicable:
a. Data element name
b. Synonymous names
c. Definition
d. Format
e. Range and enumeration of values
f. Unit of measurement
g. Data item names, abbreviations, and codes
5.2 Query capabilities
This paragraph shall identify and describe the preprogrammed and ad hoc query capabilities provided by the software.
5.3 Query preparation
This paragraph shall provide instructions for preparing queries.
5.4 Control instructions
This paragraph shall provide instructions for the sequencing of runs and other actions necessary to extract responses to query requests. These instructions shall include control statements that may be required by the computer system or software.
6. User terminal processing procedures
This section is divided into the following paragraphs to provide the user with information on the use of terminals to accomplish processing. If the procedures are complicated or extensive, Sections 7 through n may be added in the same paragraph structure as this section and with titles meaningful to the sections selected. The organization of the document will depend on the characteristics of the software being documented. For example, sections might be based on the organizations in which users work, their assigned positions, work sites, or the tasks they must perform. For other software, it may be more appropriate to have Section 6 be a guide to menus, Section 7 be a guide to the command language, and Section 8 be a guide to functions. Detailed procedures are intended to be presented in paragraphs 6.2 through 6.5. Depending on the design of the software, the subparagraphs might be organized on a function by function, menu by menu, transaction-by-transaction, or other basis. Safety precautions, marked by WARNING or CAUTION, is included where applicable.
6.1 Available capabilities
This paragraph shall describe in general terms the capabilities for retrieval, display, and update of data through terminal operations.
6.2 Access procedures
This paragraph shall present the sequence of steps and any applicable rules pertaining to accessing the software to initiate software operations.
6.3 Display, updates, and retrieval procedures
This paragraph is divided into subparagraphs to provide the step-by-step procedures necessary to produce the displays, updates, and retrievals that are available through the use of a terminal. Each procedure shall include the name of the operation, input formats, and sample responses, as applicable.
6.4 Recovery and error correction procedures
This paragraph shall identify error messages that may be displayed and shall indicate their meanings and any corrective actions that should be taken. Also included are any procedures to be followed by the user with respect to restart, recovery, and continuity of operations in the event of emergencies.
6.5 Termination procedures
This paragraph shall present the sequence of steps necessary to terminate the processing.
7. Notes
This section shall contain any general information that aids in understanding this document (for example, background information, glossary, rationale). This section shall include an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of terms and definitions needed to understand this document. If section 6 has been expanded into section(s) 7,…, this section is numbered as the next section following section n.
8. Appendixes
Appendixes may be used to provide information published separately for convenience in document maintenance (for example, charts, classified data). As applicable, each appendix is referenced in the main body of the document where the data would normally have been provided. Appendixes may be bound as separate documents for ease in handling. Appendixes are lettered alphabetically (A, B, and so on.).

Tweet This Post Buzz This Post Delicious Digg This Post

Tweet This Post Buzz This Post Delicious Digg This Post

1. Scope
This section is divided into the following paragraphs.
1.1 Identification
This paragraph shall contain a full identification of the system and the software to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).
1.2 System overview
This paragraph shall briefly state the purpose of the system and the software to which this document applies. It shall describe the general nature of the system and software; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; identify current and planned operating sites; and list other relevant documents.
1.3 Document overview
This paragraph shall summarize the purpose and contents of this document and shall describe any security or privacy considerations associated with its use.
2. Referenced documents
This section shall list the number, title, revision, and date of all documents referenced in this document. This section shall also identify the source for all documents not available through normal Government stocking activities.
3. CSCI-wide design decisions
This section is divided into paragraphs as needed to present CSCI-wide design decisions, that is, decisions about the CSCI’s behavioral design (how it will behave, from a user’s point of view, in meeting its requirements, ignoring internal implementation) and other decisions affecting the selection and design of the software units that make up the CSCI. If all such decisions are explicit in the CSCI requirements or are deferred to the design of the CSCI’s software units, this section shall so state. Design decisions that respond to requirements designated critical, such as those for safety, security, or privacy, is placed in separate subparagraphs. If a design decision depends upon system states or modes, this dependency is indicated. Design conventions needed to understand the design is presented or referenced. Examples of CSCI-wide design decisions are the following:
a. Design decisions regarding inputs the CSCI will accept and outputs it will produce, including interfaces with other systems, HWCIs, CSCIs, and users (4.3.x of this DID identifies topics to be considered in this description). If part or all of this information is given in Interface Design Descriptions (IDDs), they may be referenced.
b. Design decisions on CSCI behavior in response to each input or condition, including actions the CSCI will perform, response times and other performance characteristics, description of physical systems modeled, selected equations/algorithms/rules, and handling of unallowed inputs or conditions.
c. Design decisions on how databases/data files will appear to the user (4.3.x of this DID identifies topics to be considered in this description). If part or all of this information is given in Database Design Descriptions (DBDDs), they may be referenced.
d. Selected approach to meeting safety, security, and privacy requirements.
e. Other CSCI-wide design decisions made in response to requirements, such as selected approach to providing required flexibility, availability, and maintainability.
4. CSCI architectural design
This section is divided into the following paragraphs to describe the CSCI architectural design. If part or all of the design depends upon system states or modes, this dependency is indicated. If design information falls into more than one paragraph, it may be presented once and referenced from the other paragraphs. Design conventions needed to understand the design is presented or referenced.
4.1 CSCI components
This paragraph shall:
a. Identify the software units that make up the CSCI. Each software unit is assigned a project-unique identifier.
Note: A software unit is an element in the design of a CSCI; for example, a major subdivision of a CSCI, a component of that subdivision, a class, object, module, function, routine, or database. Software units may occur at different levels of a hierarchy and may consist of other software units. Software units in the design may or may not have a one-to-one relationship with the code and data entities (routines, procedures, databases, data files, and so on) that implement them or with the computer files containing those entities. A database may be treated as a CSCI or as a software unit. The SDD may refer to software units by any name(s) consistent with the design methodology being used.
b. Show the static (such as “consists of”) relationship(s) of the software units. Multiple relationships may be presented, depending on the selected software design methodology (for example, in an object-oriented design, this paragraph may present the class and object structures as well as the module and process architectures of the CSCI).
c. State the purpose of each software unit and identify the CSCI requirements and CSCI-wide design decisions allocated to it. (Alternatively, the allocation of requirements may be provided in 6.a.)
d. Identify each software unit’s development status/type (such as new development, existing design or software to be reused as is, existing design or software to be reengineered, software to be developed for reuse, software planned for Build N, and so on) For existing design or software, the description shall provide identifying information, such as name, version, documentation references, library, and so on.
e. Describe the CSCI’s (and as applicable, each software unit’s) planned utilization of computer hardware resources (such as processor capacity, memory capacity, input/output device capacity, auxiliary storage capacity, and communications/network equipment capacity). The description shall cover all computer hardware resources included in resource utilization requirements for the CSCI, in system-level resource allocations affecting the CSCI, and in resource utilization measurement planning in the Software Development Plan. If all utilization data for a given computer hardware resource are presented in a single location, such as in one SDD, this paragraph may reference that source. Included for each computer hardware resource is:
1) The CSCI requirements or system-level resource allocations being satisfied
2) The assumptions and conditions on which the utilization data are based (for example, typical usage, worst-case usage, assumption of certain events)
3) Any special considerations affecting the utilization (such as use of virtual memory, overlays, or multiprocessors or the impacts of operating system overhead, library software, or other implementation overhead)
4) The units of measure used (such as percentage of processor capacity, cycles per second, bytes of memory, kilobytes per second)
5) The level(s) at which the estimates or measures will be made (such as software unit, CSCI, or executable program)
f. Identify the program library in which the software that implements each software unit is to be placed
4.2 Concept of execution
This paragraph shall describe the concept of execution among the software units. It includes diagrams and descriptions showing the dynamic relationship of the software units, that is, how they will interact during CSCI operation, including, as applicable, flow of execution control, data flow, dynamically controlled sequencing, state transition diagrams, timing diagrams, priorities among units, handling of interrupts, timing/sequencing relationships, exception handling, concurrent execution, dynamic allocation/deallocation, dynamic creation/deletion of objects, processes, tasks, and other aspects of dynamic behavior.
4.3 Interface design
This paragraph is divided into the following subparagraphs to describe the interface characteristics of the software units. It includes both interfaces among the software units and their interfaces with external entities such as systems, configuration items, and users. If part or all of this information is contained in Interface Design Descriptions (IDDs), in section 5 of the SDD, or elsewhere, these sources may be referenced.
4.3.1 Interface identification and diagrams
This paragraph shall state the project-unique identifier assigned to each interface and shall identify the interfacing entities (software units, systems, configuration items, users, and so on) by name, number, version, and documentation references, as applicable. The identification shall state which entities have fixed interface characteristics (and therefore impose interface requirements on interfacing entities) and which are being developed or modified (thus having interface requirements imposed on them). One or more interface diagrams are provided, as appropriate, to depict the interfaces.
4.3.2 (Project unique identifier of interface)
This paragraph (beginning with 4.3.2) shall identify an interface by project unique identifier, shall briefly identify the interfacing entities, and is divided into subparagraphs as needed to describe the interface characteristics of one or both of the interfacing entities. If a given interfacing entity is not covered by this SDD (for example, an external system) but its interface characteristics need to be mentioned to describe interfacing entities that are, these characteristics is stated as assumptions or as “When [the entity not covered] does this, [the entity that is covered] will . . . .” This paragraph may reference other documents (such as data dictionaries, standards for protocols, and standards for user interfaces) in place of stating the information here. The design description includes the following, as applicable, presented in any order suited to the information to be provided, and shall note any differences in these characteristics from the point of view of the interfacing entities (such as different expectations about the size, frequency, or other characteristics of data elements):
a. Priority assigned to the interface by the interfacing entity(ies)
b. Type of interface (such as real-time data transfer, storage-and-retrieval of data, and so on) to be implemented
c. Characteristics of individual data elements that the interfacing entity(ies) will provide, store, send, access, receive, and so on, such as:
1) Names/identifiers
a) Project-unique identifier
b) Non-technical (natural-language) name
c) DoD standard data element name
d) Technical name (for example, variable or field name in code or database)
e) Abbreviation or synonymous names
2) Data type (alphanumeric, integer, and so on)
3) Size and format (such as length and punctuation of a character string)
4) Units of measurement (such as meters, dollars, nanoseconds)
5) Range or enumeration of possible values (such as 0-99)
6) Accuracy (how correct) and precision (number of significant digits)
7) Priority, timing, frequency, volume, sequencing, and other constraints, such as whether the data element may be updated and whether business rules apply
Security and privacy constraints
9) Sources (setting/sending entities) and recipients (using/receiving entities)
d. Characteristics of data element assemblies (records, messages, files, arrays, displays, reports, and so on) that the interfacing entity(ies) will provide, store, send, access, receive, and so on, such as:
1) Names/identifiers
a) Project-unique identifier
b) Non-technical (natural language) name
c) Technical name (for example, record or data structure name in code or database)
d) Abbreviations or synonymous names
2) Data elements in the assembly and their structure (number, order, grouping)
3) Medium (such as disk) and structure of data elements/assemblies on the medium
4) Visual and auditory characteristics of displays and other outputs (such as colors, layouts, fonts, icons and other display elements, beeps, lights)
5) Relationships among assemblies, such as sorting/access characteristics
6) Priority, timing, frequency, volume, sequencing, and other constraints, such as whether the assembly may be updated and whether business rules apply
7) Security and privacy constraints
Sources (setting/sending entities) and recipients (using/receiving entities)
e. Characteristics of communication methods that the interfacing entity(ies) will use for the interface, such as:
1) Project-unique identifier(s)
2) Communication links/bands/frequencies/media and their characteristics
3) Message formatting
4) Flow control (such as sequence numbering and buffer allocation)
5) Data transfer rate, whether periodic/aperiodic, and interval between transfers
6) Routing, addressing, and naming conventions
7) Transmission services, including priority and grade
Safety/security/privacy considerations, such as encryption, user authentication, compartmentalization, and auditing
f. Characteristics of protocols that the interfacing entity(ies) will use for the interface, such as:
1) Project-unique identifier(s)
2) Priority/layer of the protocol
3) Packeting, including fragmentation and reassembly, routing, and addressing
4) Legality checks, error control, and recovery procedures
5) Synchronization, including connection establishment, maintenance, termination
6) Status, identification, and any other reporting features
g. Other characteristics, such as physical compatibility of the interfacing entity(ies) (dimensions, tolerances, loads, voltages, plug compatibility, and so on)
5. CSCI detailed design
This section is divided into the following paragraphs to describe each software unit of the CSCI. If part of all of the design depends upon system states or modes, this dependency is indicated. If design information falls into more than one paragraph, it may be presented once and referenced from the other paragraphs. Design conventions needed to understand the design is presented or referenced. Interface characteristics of software units may be described here, in Section 4, or in Interface Design Descriptions (IDDs). Software units that are databases, or that are used to access or manipulate databases, may be described here or in Database Design Descriptions (DBDDs).
5.1 (Project-unique identifier of a software unit, or designator of a group of software units)
This paragraph shall identify a software unit by project-unique identifier and shall describe the unit. The description includes the following information, as applicable. Alternatively, this paragraph may designate a group of software units and identify and describe the software units in subparagraphs. Software units that contain other software units may reference the descriptions of those units rather than repeating information.
a. Unit design decisions, if any, such as algorithms to be used, if not previously selected
b. Any constraints, limitations, or unusual features in the design of the software unit
c. The programming language to be used and rationale for its use if other than the specified CSCI language
d. If the software unit consists of or contains procedural commands (such as menu selections in a database management system (DBMS) for defining forms and reports, on-line DBMS queries for database access and manipulation, input to a graphical user interface (GUI) builder for automated code generation, commands to the operating system, or shell scripts), a list of the procedural commands and reference to user manuals or other documents that explain them
e. If the software unit contains, receives, or outputs data, a description of its inputs, outputs, and other data elements and data element assemblies, as applicable. Paragraph 4.3.x of this DID provides a list of topics to be covered, as applicable. Data local to the software unit is described separately from data input to or output from the software unit. If the software unit is a database, a corresponding Database Design Description (DBDD) is referenced; interface characteristics may be provided here or by referencing section 4 or the corresponding Interface Design Description(s).
f. If the software unit contains logic, the logic to be used by the software unit, including, as applicable:
1) Conditions in effect within the software unit when its execution is initiated
2) Conditions under which control is passed to other software units
3) Response and response time to each input, including data conversion, renaming, and data transfer operations
4) Sequence of operations and dynamically controlled sequencing during the software unit’s operation, including:
a) The method for sequence control
b) The logic and input conditions of that method, such as timing variations, priority assignments
c) Data transfer in and out of memory
d) The sensing of discrete input signals, and timing relationships between interrupt operations within the software unit
5) Exception and error handling
6. Requirements traceability
This section shall contain:
a. Traceability from each software unit identified in this SDD to the CSCI requirements allocated to it. (Alternatively, this traceability may be provided in 4.1.)
b. Traceability from each CSCI requirement to the software units to which it is allocated.
7. Notes
This section shall contain any general information that aids in understanding this document (for example, background information, glossary, rationale). This section includes an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of any terms and definitions needed to understand this document.
8. Appendixes
Appendixes may be used to provide information published separately for convenience in document maintenance (for example, charts, classified data). As applicable, each appendix is referenced in the main body of the document where the data would normally have been provided. Appendixes may be bound as separate documents for ease in handling. Appendixes is lettered alphabetically (A, B, and so on).

Tweet This Post Buzz This Post Delicious Digg This Post

1. Scope
This section is divided into the following paragraphs.
1.1 Identification
This paragraph shall contain a full identification of the system and software to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).
1.2 System overview
This paragraph shall briefly state the purpose of the system and the software to which this document applies. It shall describe the general nature of the system and software; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; identify current and planned operating sites; and list other relevant documents.
1.3 Document overview
This paragraph shall summarize the purpose and contents of this manual and shall describe any security or privacy considerations associated with its use.
2. Referenced documents
This section shall list the number, title, revision, and date of all documents referenced in this manual. This section shall also identify the source for all documents not available through normal Government stocking activities.
3. Software summary
This section is divided into the following paragraphs.
3.1 Software application
This paragraph shall provide a brief description of the intended uses of the software. Capabilities, operating improvements, and benefits expected from its use is described.
3.2 Software inventory
This paragraph shall identify all software files, including databases and data files, that must be installed for the software to operate. The identification shall include security and privacy considerations for each file and identification of the software necessary to continue or resume operation in case of an emergency.
3.3 Software environment
This paragraph shall identify the hardware, software, manual operations, and other resources needed to install and operate the software. Included, as applicable, is identification of:
a. Computer equipment that must be present, including amount of memory needed, amount of auxiliary storage needed, and peripheral equipment such as terminals, printers, and other input/output devices
b. Communications equipment that must be present
c. Other software that must be present, such as networking software, operating systems, databases, data files, utilities, permanent files that are referenced, created, or updated by the software; and databases/data files necessary to resume operation in the event of emergencies
d. Forms, procedures, or other manual operations that must be present
e. Other facilities, equipment, or resources that must be present
3.4 Software organization and overview of operation
This paragraph shall provide a brief description of the organization and operation of the software from the operator’s point of view. The description shall include, as applicable:
a. Logical components of the software, from the operator’s point of view, and an overview of the purpose/operation of each component
b. Types of inputs/access that can be made to the software and the software’s response to each type
c. The reports and other outputs that are produced by the software, including security and privacy considerations for each
d. Typical run times and factors that affect it
e. Organization of software operation into runs. This description shall use a chart, if applicable, showing how the different operations are interrelated. If sets of runs are grouped by time periods or cycles, each set of integrated operations required on a daily, weekly, etc., basis is presented. If runs may be grouped logically by organizational level, the groups of runs that can be performed by each organizational level such as headquarters processing, field activity processing, etc., is presented.
f. Any system restrictions, waivers of operational standards, information oriented toward specific support areas (for example, library, small computer and teleprocessing support, interfaces with other systems), or other special aspects of processing
g. General description of the communications functions and processes of the software, including, as applicable, a diagram of the communications network used in the system
3.5 Contingencies and alternate states and modes of operation
This paragraph shall explain the differences in software operation at times of emergency and in various states and modes of operation, if applicable.
3.6 Security and privacy
This paragraph shall contain an overview of the security and privacy considerations associated with the software. A warning is included regarding making unauthorized copies of software or documents, if applicable.
3.7 Assistance and problem reporting
This paragraph shall identify points of contact and procedures to be followed to obtain assistance and report problems encountered in operating the software.
4. Installation and setup
This paragraph shall describe any procedures that the operator must perform to install the software on the equipment, to configure the software, to delete or overwrite former files or data, and to enter parameters for software operation. Safety precautions, marked by WARNING or CAUTION, is included where applicable.
5. Description of runs
This section is divided into the following paragraphs to provide a description of the runs to be performed. Safety precautions, marked by WARNING or CAUTION, is included where applicable.
5.1 Run inventory
This paragraph shall provide a list of the runs to be performed, identifying the software and the jobs that make up each run. It shall include a brief summary of the purpose of each run and shall relate the list to the run descriptions included in the remainder of this section.
5.2 Phasing
This paragraph shall describe acceptable phasing of the software into a logical series of operations. A run may be phased to permit manual or semiautomatic checking of intermediate results, to provide the user with intermediate results for other purposes, or to permit a logical break if higher priority jobs are submitted. An example of the minimum division for most systems would be edit, file update, and report preparation.
5.3 Diagnostic procedures
This paragraph shall provide the setup and execution procedures for any software diagnostics. Included is procedures for validation and trouble shooting. All parameters (both input and output), codes, and range values for diagnostic software is explained.
5.4 Error messages
This paragraph shall list all error messages output by the software, along with the meaning and corresponding correction procedure for each message.
5.5 Description of each run
This paragraph is divided into the following subpara-graphs.
5.5.1 Run description for (run name or identifier)
This paragraph shall identify a run and is divided into the following subparagraphs to describe the run.
5.5.1.1 Control inputs
This paragraph shall provide a listing of the run stream of job control statements needed to initiate the run.
5.5.1.2 Run management information
This paragraph shall provide the information needed to manage the run including, as applicable:
a. Peripheral and resource requirements
b. Security and privacy considerations
c. Method of initiation, such as on request, after another run, or at a predetermined time
d. Estimated run time
e. Required turnaround time
f. Messages and responses
g. Procedures for taking check points
h. Waivers from operational standards
5.5.1.3 Input-output files
This paragraph shall provide information about the files and databases that serve as input to or that are created or updated by the run. Included for each is information such as name, security and privacy, recording medium, retention schedule, and disposition.
5.5.1.4 Output reports
This paragraph shall provide information about the reports that are produced during the run. In-cluded for each report is the following information, as applicable: report identifier, product control number, report control symbol, title, security and privacy, media (for example, hard copy, magnetic tape), volume of report, number of copies, and distribution of copies.
5.5.1.5 Reproduced output reports
This paragraph shall provide information about computer-generated reports that are subse-quently reproduced by other means. Included for each report is information such as report identification, security and privacy, reproduction technique, paper size, binding method, number of copies, and distribution of copies.
5.5.1.6 Procedures for restart/recovery and continuity of operations
This paragraph shall provide procedures to be followed by operator personnel concerning re-start/recovery in the event of a system failure and for continuity of operations in the event of emergencies.
6. Notes
This section shall contain any general information that aids in understanding this document (for example, background information, glossary, rationale). This section shall include an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of terms and definitions needed to understand this document.
7. Appendixes
Appendixes may be used to provide information published separately for convenience in document maintenance (for example, charts, classified data). As applicable, each appendix is referenced in the main body of the document where the data would normally have been provided. Appendixes may be bound as separate documents for ease in handling. Appendixes are lettered alphabetically (A, B, and so on).

Tweet This Post Buzz This Post Delicious Digg This Post

1. Scope
This section is divided into the following paragraphs.
1.1 Identification
This paragraph shall contain a full identification of the system to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).
1.2 System overview
This paragraph shall briefly state the purpose of the system to which this document applies. It shall describe the general nature of the system; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; identify current and planned operating sites; and list other relevant documents.
1.3 Document overview
This paragraph shall summarize the purpose and contents of this document and shall describe any security or privacy considerations associated with its use.
2. Referenced documents
This section shall list the number, title, revision, and date of all documents referenced in this document. This section shall also identify the source for all documents not available through normal Government stocking activities.
3. Current system or situation
This section is divided into the following paragraphs to describe the system or situation as it currently exists.
3.1 Background, objectives, and scope
This paragraph shall describe the background, mission or objectives, and scope of the current system or situation.
3.2 Operational policies and constraints
This paragraph shall describe any operational policies and constraints that apply to the current system or situation.
3.3 Description of current system or situation
This paragraph shall provide a description of the current system or situation, identifying differences associated with different states or modes of operation (for example, regular, mainte-nance, training, degraded, emergency, alternative-site, wartime, peacetime). The distinction between states and modes is arbitrary. A system may be described in terms of states only, modes only, states within modes, modes within states, or any other scheme that is useful. If the system operates without states or modes, this paragraph shall so state, without the need to create artificial distinctions. The description shall include, as applicable:
a. The operational environment and its characteristics
b. Major system components and the interconnections among these components
c. Interfaces to external systems or procedures
d. Capabilities/functions of the current system
e. Charts and accompanying descriptions depicting inputs, outputs, data flow, and manual and automated processes sufficient to understand the current system or situation from the user’s point of view
f. Performance characteristics, such as speed, throughput, volume, frequency
g. Quality attributes, such as reliability, maintainability, availability, flexibility, portability, usability, efficiency
h. Provisions for safety, security, privacy, and continuity of operations in emergencies
3.4 Users or involved personnel
This paragraph shall describe the types of users of the system, or personnel involved in the current situation, including, as applicable, organizational structures, training/skills, responsibili-ties, activities, and interactions with one another.
3.5 Support concept
This paragraph shall provide an overview of the support concept for the current system, including, as applicable to this document, support agency(ies); facilities; equipment; support software; repair/replacement criteria; maintenance levels and cycles; and storage, distribution, and supply methods.
4. Justification for and nature of changes
This section is divided into the following paragraphs.
4.1 Justification for change
This paragraph shall:
a. Describe new or modified aspects of user needs, threats, missions, objectives, environ-ments, interfaces, personnel or other factors that require a new or modified system
b. Summarize deficiencies or limitations in the current system or situation that make it unable to respond to these factors
4.2 Description of needed changes
This paragraph shall summarize new or modified capabilities/functions, processes, interfaces, or other changes needed to respond to the factors identified in 4.1.
4.3 Priorities among the changes
This paragraph shall identify priorities among the needed changes. It shall, for example, identify each change as essential, desirable, or optional, and prioritize the desirable and optional changes.
4.4 Changes considered but not included
This paragraph shall identify changes considered but not included in 4.2, and rationale for not including them.
4.5 Assumptions and constraints
This paragraph shall identify any assumptions and constraints applicable to the changes identified in this section.
5. Concept for a new or modified system
This section is divided into the following paragraphs to describe a new or modified system.
5.1 Background, objectives, and scope
This paragraph shall describe the background, mission or objectives, and scope of the new or modified system.
5.2 Operational policies and constraints
This paragraph shall describe any operational policies and constraints that apply to the new or modified system.
5.3 Description of the new or modified system
This paragraph shall provide a description of the new or modified system, identifying differences associated with different states or modes of operation (for example, regular, mainte-nance, training, degraded, emergency, alternative-site, wartime, peacetime). The distinction between states and modes is arbitrary. A system may be described in terms of states only, modes only, states within modes, modes within states, or any other scheme that is useful. If the system operates without states or modes, this paragraph shall so state, without the need to create artificial distinctions. The description shall include, as applicable:
a. The operational environment and its characteristics
b. Major system components and the interconnections among these components
c. Interfaces to external systems or procedures
d. Capabilities/functions of the new or modified system
e. Charts and accompanying descriptions depicting inputs, outputs, data flow, and manual and automated processes sufficient to understand the new or modified system or situation from the user’s point of view
f. Performance characteristics, such as speed, throughput, volume, frequency
g. Quality attributes, such as reliability, maintainability, availability, flexibility, portability, usability, efficiency
h. Provisions for safety, security, privacy, and continuity of operations in emergencies
5.4 Users/affected personnel
This paragraph shall describe the types of users of the new or modified system, including, as applicable, organizational structures, training/skills, responsibilities, and interactions with one another.
5.5 Support concept
This paragraph shall provide an overview of the support concept for the new or modified system, including, as applicable, support agencies); facilities; equipment; support software; repair/replacement criteria; maintenance levels and cycles; and storage, distribution, and supply methods.
6. Operational scenarios
This section shall describe one or more operational scenarios that illustrate the role of the new or modified system, its interaction with users, its interface to other systems, and all states or modes identified for the system. The scenarios shall include events, actions, stimuli, information, interactions, etc., as applicable. Reference may be made to other media, such as videos, to provide part or all of this information.
7. Summary of impacts
This section is divided into the following paragraphs.
7.1 Operational impacts
This paragraph shall describe anticipated operational impacts on the user, acquirer, developer, and support agencies. These impacts may include changes in interfaces with computer operating centers; change in procedures; use of new data sources; changes in quantity, type, and timing of data to be input to the system; changes in data retention requirements; and new modes of operation based on peacetime, alert, wartime, or emergency conditions.
7.2 Organizational impacts
This paragraph shall describe anticipated organizational impacts on the user, acquirer, developer, and support agencies. These impacts may include modification of responsibili-ties; addition or elimination of responsibilities or positions; need for training or retraining; and changes in number, skill levels, position identifiers, or location of personnel in various modes of operation.
7.3 Impacts during development
This paragraph shall describe anticipated impacts on the user, acquirer, developer, and support agency(ies) during the development effort. These impacts may include meetings/discussions regarding the new system; development or modification of databases; training; parallel operation of the new and existing systems; impacts during testing of the new system; and other activities needed to aid or monitor development.
8. Analysis of the proposed system

8.1 Summary of advantages
This paragraph shall provide a qualitative and quantitative summary of the advantages to be obtained from the new or modified system. This summary shall include new capabilities, enhanced capabilities, and improved performance, as applicable, and their relationship to deficiencies identified in 4.1.
8.2 Summary of disadvantages/limitations
This paragraph shall provide a qualitative and quantitative summary of disadvantages or limitations of the new or modified system. These disadvantages and limitations shall include, as applicable, degraded or missing capabilities, degraded or less-than-desired performance, greater-than-desired use of computer hardware resources, undesirable operational impacts, conflicts with user assumptions, and other constraints.
8.3 Alternatives and trade-offs considered
This paragraph shall identify and describe major alternatives considered to the system or its characteristics, the trade-offs among them, and rationale for the decisions reached.
9. Notes
This section shall contain any general information that aids in understanding this document (for example, background information, glossary, and rationale). This section shall include an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of any terms and definitions needed to understand this document.
10. Appendixes
Appendixes may be used to provide information published separately for convenience in document maintenance (for example, charts, classified data). As applicable, each appendix is referenced in the main body of the document where the data would normally have been provided. Appendixes may be bound as separate documents for ease in handling. Appendixes are lettered alphabetically (A, B, and so on).

Tweet This Post Buzz This Post Delicious Digg This Post

Then go through below link to get online status
http://59.90.212.185:8787/publicview/

Tweet This Post Buzz This Post Delicious Digg This Post