You already have plenty of supplementary requirements: “A faster device, all in one, the software should not slow the device.”

   The performance requirement is that the device has to be fast. However “fast” is subjective as is the other requirement that the software should not slow the device. Get some real numbers. Clarify response time for a transaction (average, maximum), throughput (e.g., transactions per second), capacity (e.g., the number of customers or transactions the system can accommodate), degradation modes (what is the acceptable mode of operation when the system has been degraded in some manner), resource utilization: memory, disk, communications, etc. If it is hard to obtain this from the stakeholders, let them compare their performance expectations with the current version of the system.

   Once you have clarified the performance requirements follow with reliability (availability – specify % of time available ( xx.xx%), hours of use, maintenance access, etc;), and supportability - requirements that will enhance the supportability or maintainability of the system being built, including coding standards, naming conventions, class libraries, maintenance access, maintenance utilities.

   Then precede with the usability requirements. Specify the required training time for a normal user and power users to become productive at particular operations, measurable task times for typical tasks, or base usability requirements of the new system on other systems that the users know and like. It may be OK to say that a user of the current version should be able use the PDA version with minimal or no training at all. Specify requirements to conform to common usability standards – e.g., IBM’s CUA standards, or the GUI standards published by Microsoft for Windows 95. Consider visually impaired and colorblind users, as well as users using different languages, if your application will offer multilingual support. And so on.

   Don’t forget the design constraints. The first one that comes to mind is that the PDA has at least 5 times smaller screen than the desktop and it may be black and white for some models.

   Then start thinking about the interfaces. You may specify protocols, ports and logical addresses, etc, so that the software can be developed and verified against the interface requirements. Describe the user, hardware, software and communication interfaces to be developed. Identify how the software will be installed for example. If it uses a database what is required for the transition to the PDA version, etc.

   Don’t forget to include any components that will be purchased, and any licensing requirements or other usage restrictions which are to be exhibited by the software. The necessary legal disclaimers, warranties, copyright notices, patent notice, wordmark, trademark, or logo compliance issues for the software should be detailed as well.

   Any kind of user documentation: online, help, manuals, etc. should be considered.

   You may also include any applicable standards that have to be followed during the design and development.

Handle the business and functional requirements as usual. 

Be specific. Write clear and measurable requirements.

-Vessela