There is little disagreement over the fact that quality requirements are important, even essential, to the success of software projects.  If we define project success as usable, working software, then it becomes quickly apparent that we need “good” requirements that reflect what the system should do.  This begs the question, what qualities make a requirement good?

Logically, a requirement should clearly identify a real and specific business need.  This is most easily ensured by having extensive user input during requirements gathering phases and close communication with business users for elaborations.  Changing requirements are a hallmark of agile development projects and a focus on requirement elaboration and clarification are key.

Java programming enables the same code to be used on a variety of operating systems such as Windows, Unix, Linux and Macintosh. JavaHelp is Sun Microsystem’s standard for providing user assistance and electronic documentation. JavaHelp integrates HTML, XML and Java technology to create electronic documentation that can be integrated with Java enterprise applications or provided standalone. However, JavaHelp can also be easily created with RoboHelp.

JavaHelp systems can be deployed on any platform that supports the Java Runtime Environment1. Using the JavaHelp format, you can provide the assistance and documentation your users need, in the Java programming language, for a true end-to-end Java enterprise solution.

There are a few differences between HTML Help and WebHelp that you should consider before choosing your online help output solution.

HTML Help is limited in that it only runs on 32-bit Windows systems and it only works with Internet Explorer. However, the files do not run over the internet. They must be downloaded and run locally using Internet Explorer as the viewer. An advantage or disadvantage, depending on your application of the online help system is that HTML Help is complied and compressed before it can be deployed. A .CHM file is generated after the help system is compiled and is installed on the system when the application installation is performed.

In order to have a defect resolved efficiently, there are some guidelines for creating reports that are easy for developers to interpret and follow.  Bear in mind that your reports should contain information needed by developers (to fix the bug), managers (to assess risk and prioritize work) and fellow testers (to verify fixes and find out if known defects may be the source of current problems). 

1.                  Document immediately – modifications/details can always be added later