If you would like to participate in solving a DesignFest® problem, you do not have to submit a proposal--simply sign up when you fill out your registration form!
Content
DesignFest® problem descriptions should, in general, include:
Abstract. This concise presentation of your problem will be the basis for the participants to choose the problem they want to work on. Please keep this to under 200 words. The abstract is used in the subscription process for attendandees. It is therefore required in all proposals.
Description of the domain. A description of the contextual organisation that the solution solving the problem is to be deployed in, or the system that needs improving. This description can be accompanied by pictures, images, text or whatever. The purpose of this description is to explain the context in which the problem is placed. The text should define any terminology and should be understandable by laymen. All abbreviations must be explained, if possible in a glossary.
The problem that needs solving or the improvements required. This could be a description of the program that is wanted. This should include the goals of the program and the required functions. It should state what the program should achieve without enforcing any solutions.
Analysis diagrams. A class diagram of the problem domain's object model, or any other type of diagram which may serve as a basis for the design, could be included here.
Detailed requirements. Because of time limitations these should of course be restricted. An indication of performance and capacity requirements should be given.
Use cases. A handful of use cases should be provided. They are well suited to provide hints for the design process, as design teams tend to work on them first.
Interfaces. Descriptions of interfaces to other systems. This could be header files or file formats. This is, of course, optional when no interfaces to other systems are necessary.
References for further study. These are references to articles, other similar systems or implementations.
The expected deliverables. This is not a strict requirement, but if the author wishes to see his or her problem adressed in a particular setting or proces method this can be indicated in this way. Asking for a static and dynamic model will be a fair indication that a classical design is wanted. Asking for a domain specific language is a clear indication that Model Driven Architecture (MDA) is prefered. If the intent is to do detailed analysis rather than design, that should also be stated, and items 4-6 can be significantly less detailed.
Problem descriptions from past DesignFests® are available on the DesignFest® web site. You may want to review some descriptions to get a sense of suitability and complexity.
Expect that your problem will be revised several times before it is accepted. The sooner you submit, the more help with revision you are likely to receive.
For more information
For additional information, clarification, or questions, please contact the track chair.
