1. General

1.1. There are many requests coming to UCS head office from dealers who want to change the software.

1.2. Normally, dealer should make task for development of new features or changing system behaviour (not related to errors) with detailed description.

1.3. Detailed description must be done with supporting files explaining ideas, structure, relations, etc. Dealer must show logic and explain purpose.

1.4. Dealer actions after he got request from customer:

1.4.1. Examine the roots and details

1.4.2. Check, if you can do something similar using existing functionality

1.4.3. Decide if development is necessary and worth doing

1.4.4. Who will do this development (UCS side, another third person or company, dealer himself). It might be other software developer in case of integration with their software.

1.4.5. Terms on time and money and other conditions.

1.4.5.1. Most devepment tasks are made on paid basis. You have to coordinate cost of this service.

1.4.5.2. You have to make agreement on timing.

1.4.6. Find out technical details: what information to input by user, to show on user GUI, to exchange between applications, frequency, etc.

1.4.7. Other types of dealer requests has to be resolved using tracker task as well.

1.4.8. Technical task document should be made in PDF or similar one-file format with all information inside. See p.5.

2. Report or printing layout

2.1. As for reporting system, dealer is able to make report and layout himself.

2.2. In some complicated cases, dealer may get report from UCS developers.

2.3. For new report preparation, dealer should provide the following detailed description. This is valid both for new report and remake of existing preset or not system preset report.

2.3.1. Report name and alternative name (in case you use non-english one).

2.3.2. Do you need to include this report into common distributive or you want it to be imported to your system only?

2.3.3. Specify report type (input data method) and data layout (output) type: interactive, direct SQL-query, cube OLAP; FR4 layout or Desktop grids or both.

2.3.4. Do you need active buttons designed in order to change layout type? If yes, specify each button name in each language chosen. Draw buttons on scheme.

2.3.5. Complete description of inner data as Excel page(s) scheme(s). Scheme may contain data examples like if you exported ready report to XLS.

2.3.5.1. Each column names in all languages chosen. In case of several tables on one page - do it for each table.

2.3.5.2. Header line names in all languages chosen.

2.3.5.3. List of filters called with report and their possible values, format of filter user input.

2.3.5.4. Add grouping and sorting descriptions. Specify new page separation rules.

2.3.5.5. Specify total lines where they must be shown, which column totals you want to add.

2.3.6. Specify the report parent (place in classification tree) and main group. To which existing dataset it will belong to (or new dataset name and description).

2.3.7. If you know similar preset reports/datasets mention them. Attach initial layout if you ask to modify the report.

2.3.8. If you want changes in existing report, provide that initial (Cube, SQL-query, XML-exported or other format).

2.3.9. Describe changes in data which you want to make. If you add data - specify data source.

2.3.10. For each column, header or whatever you add to report, you must provide names in each chosen language.

2.3.11. You must specify application will be used for report execution. Here you must define is it back office or front office report.

3. Feature (procedure)

3.1. Feature or procedure or operation or another system behaviour development can be done by additional scripting or souce code changes.

3.1.1. Scripting can be done by dealer himself except complicated cases. Difficult scripts are written by UCS developer.

4. Visual user interface

4.1. Simple changes in GUI are available for maintaince by engineer.

5. Development technical task

5.1. Prepate technical task as one file document.

5.2. Use PDF format or similar.

5.3. Put text, tables, images - all in one document.

5.4. This document will be used for official reference, during development cost estimation and quality assurance procedures.

5.5. Document must include information about

5.5.1. Persons and companies who need this development and dealer information, who requested development.

5.5.2. The main purpose and advantages explaination. List of benefits for customer.

5.5.3. Technical details based on current software funtions, with relative comparison to latest version.

5.5.4. Specify exact application for rework, its interface (window, state, area), which are expected to be modified.

5.5.5. Images of wannable interface look after development.