Ans:
Documentation:
In computer hardware and software product development, documentation is the information that describes the product to its users. Software documentation: program listings or technical manuals describing the operation and use of programs.
Documentation is Instructions for using a computer device or program. Documentation can appear in a variety of forms, the most common being manuals. When you buy a computer product (hardware or software), it almost always comes with one or more manuals that describe how to install and operate the product. In addition, many software products include an online version of the documentation that you can display on your screen or print out on a printer. A special type of online documentation is a help system , which has the documentation embedded into the program. Help systems are often called context-sensitive because they display different information depending on the user's position (context) in the application.
Documentation is often divided into the following categories:
- installation: Describes how to install a program or device but not how to use it.
- reference: Detailed descriptions of particular items presented in alphabetical order. Reference documentation is designed for people who are already somewhat familiar with the product but need reminders or very specific information about a particular topic.
- tutorial: Teaches a user how to use the product. Tutorials move at a slower pace than reference manuals and generally contain less detail.
1. System Requirement Specification
A System Requirements Specification (SRS) is a document where the requirements of a system that is planned to be developed are listed.
A Business analyst (BA), sometimes titled System analyst, is responsible for analysing the business needs of their clients and stakeholders to help identify business problems and propose solutions. Within the systems development life cycle domain, the BA 12 typically performs a liaison function between the business side of an enterprise and the information technology department or external service providers.
Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users.
Requirements analysis is critical to the success of a development project. Requirements must be actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design
Systematic requirements analysis is also known as requirements engineering.It is sometimes referred to loosely by names such as requirements gathering, requirements capture, or requirements specification. The term requirements analysis can also be applied specifically to the analysis proper, as opposed to elicitation or documentation of the requirements, for instance.
Requirement engineering is a subdiscipline of systems engineering and software engineering that is concerned with determining the goals, functions, and constrains of hardware and software systems. In some life cycle models, the requirement engineering process begins with a feasibility study activity, which leads to a feasibility report. If the feasibility study suggest that the product should be developed, then requirement analysis can begin. If requirement analysis precedes feasibility studies, which may foster outside the box thinking, then feasibility should be determined before requirements are finalized.
2. System Design Specification
The system design specifications address the "look and feel" of the interface, with rules for the display of global and particular elements.
Flow or Logic Diagram
Flow diagrams define the end-user's paths throng the site and site functionality. A flow diagram for a commerce site would detail the sequence of pages necessary to gather the information required by the commerce application in order to complete an order.
Logic diagrams describe the order that logic decisions are made during the transmission, gathering, or testing of data. So for example, upon submission of a form, information may be reviewed by the system for field completeness before being reviewed for algorithmic accuracy; in other words, the system may verify that required fields have in fact been completed before verifying that the format of the email address is correct or the credit card number is an algorithmically valid number. Another example would be the logic applied to a search query, detailing the steps involved in the query cleanup and expansion, and the application of Boolean operators.
System Architecture Diagram
A system architecture diagram illustrates the way the system hardware and software must be configured, and the way the database tables should be defined and laid out.
Prototypes and Mock-ups
A prototype is a model of the system delivered in the medium of the system. For example, a web site prototype would be delivered as a web site, using the standard web protocols, so that it could be interacted with in the same medium as the project's product. Prototypes don't have to be fully functioning, they merely have to be illustrative of what the product should look and feel like.
In contrast, a mock-up is a representation in a different medium. A web site mock-up might be a paper representation of what the pages should look like.
The authors of Constructing Superior Software describe several categories of prototypes: low fidelity prototypes which correspond to what I've labeled "mock-ups", and high fidelity prototypes.
Low fidelity prototypes are limited function and limited interaction prototypes. They are constructed to depict concepts, design alternatives, and screen layouts rather than to model the user interaction with the system....There are two forms of low fidelity prototype: abstract and concrete....The visual designer works from the abstract prototype and produces drawings of the interface as a concrete low fidelity prototype....High fidelity prototypes are fully interactive (p 70-71).
Prototypes and mock-ups are important tools for defining the visual design, but they can be problematic from a quality assurance and testing point of view because they are a representation of a designer's idea of what the product should look and feel like. The issue is not that the designer's may design incorrectly, but that the prototype or mock-up will become the de facto design by virtue of being a representation. The danger is that the design will become final before it has been approved; this is known as "premature concretization" or "premature crispness of representation", where a sample becomes the final design without a formal decision. If you have every tried to get page element removed from a design, you have an idea what this problem is like. The value of prototypes is that they provide a visual dimension to the written requirements and specifications; they are both a proof of concept and the designers' sketchpad wrapped up in one package.
Technical Specifications
Technical specifications are typically written the by developers and coders, and describe how they will implement the project. The developers work from the functional specifications, and translate the functions into their actual coding practices and methodologies.
3. Test Document
In this document, we give the test plan and test results for unit testing of some of the key modules of the Personal Investment Management System (PIMS).
2.Unit Testing Methodology
2.1 Selection of units: We selected only the most important functional and critical classes for formal unit testing. In the test environment we used, a unit for unit testing is a class. Here we illustrate the testing methodology by discussing only two classes.
2.2 Test Scripts: As we used Junit for unit testing. The test scripts were java programs and each test case corresponded to a method in these java programs.
2.3 Fixing of Defects: The programmer fixed the defects found. Unit testing was successfully complete only if the script executed without any defects.
2.4 Test Script Enhancement: As testing proceeded, some new test cases were added. 15 This was done by adding new test methods to the testing program.
3. The Testing Tool: Junit
We used Junit as the tool for unit testing. It is open source software which can be used to test Java modules. It can be freely downloaded from the website www.junit.org The general way to test the module (usually a ‘class’) by Junit: We create a class extending TestCase(a predefined class of Junit), and write the following methods:
(a) setUp(): In this we instantiate various objects needed to perform the testing.
(b) tearDown(): In this we deallocate all or some of the memory which was used up by objects created in setUp() method. This is called at the end of all tests.
(c) suite(): This method is used to create a test suite, which specifies as to which tests will be performed.
(d) Various methods of the name testXXX(): These methods contain the actual code for testing. In any such method, we do whatever operations we want to do, and then call the method assertTrue()/assertFalse(), with a boolean as the argument, which specifies as to what condition we wish to hold true/false, for being convinced that the tested method performs correctly.
4. Tests Performed
We unit tested the methods of following two classes:
(a) Alerts, and
(b) Investment
(a) Testing methods of class Alerts:
4
User Manual
As the name implies, User manual are written to help people understand an software application or IT system. They are also called User guide. When writing a User manual, use simple language with short sentences. This writing style helps the user understand the application.
User manual are the first port of call when something needs to be read. As many people read user guides when frustrated and after having lost patience with the software, you need to write your material to address their concerns quickly.
User manual are often written for non-technical individuals. The level of content and terminology differs considerably from, for example, a System Administration Guide, which is more detailed and complex.
This rest of article offers some guidelines to consider when writing your User Guide, such as:
a) Identifying your audience
b) Writing sections
c) Defining style guide and standards
d)
Delivery formats
