Introduction

The TopCoder software development methodology is mostly based on the usage of open community members. Many low level steps of software building have been opened to the development community. Anybody can participate in designing and coding software components, making the software GUI, assembling and testing final applications. But now, a new exciting possibility is available – making application Concepts and Specifications of business requirements. It means, the community members are able to work with TopCoder customers from the very beginning of the project. The output is a high level picture of the project – so your ideas and concepts will be the initial requirements for architects, designers, coders, assemblers and testers!

A short picture of the Conceptualization and Specification competitions is shown below (from TC process).

The Conceptualization challenge produces the Conceptualization Document with high level use cases and requirements. And the Specification challenge produces a specification document with detailed activities (exact description of the business requirements, data definition and verification, etc...) .

The entire TopCoder process is also available here: http://www.topcoder.com/wiki/display/tc/The+TopCoder+Platform+-+Software+Application+Development+Methodology

Conceptualization and Specification challenges produce the business REQUIREMENTS for the application. Those challenges are not Architecture and not Design, because we are not implementing the system there, but we are defining the customer needs of that system.
The common order of software competitions for application development is as follows:

1. Studio Storyboard (optional)
2. Conceptualization (high level application description)
3. Studio Wireframes or Prototype
4. Specification (detailed description how the system should meet business requirements)
5. Architecture
6. and so on...

Processed Documents

The documents, involved in the Conceptualization challenges, are shown on the next table.

The customers describe their project needs in the Questionnaire. That explanation is mostly brief, informal and just a starting point of application requirements. We have to ask the customer on the forum to get clarifications. Sometimes, the company standards for existing technologies and other technological best practices are provided by customer or TopCoder PM. We have to follow those rules.

The Conceptualization Document is the most important output of the Conceptualization competition. Briefly, it has 4 common sections:

• Introduction
  Describes the intro overview of the application, its main goal and objectives (the tasks to be completed for project success). We define high level assumptions and limitations of the project there, as well as open business risks.
• Existing Application
  Explains the previous version of the application or the business flows of current actions in the customer company. That section mostly focuses on the current problems in the business model, opportunities and failures to be solved in the new application.
• Proposed Application
  Shows a very high level structure of the new application, the business flows and what business documents are involved. That section mostly focuses on how the new system solves the existing problems.
• Requirements
  Defines the formal requirements to the new application. This is a core space to keep the needed application functionality. All of what is defined here –will next be implemented in the actual application. We describe the application features from the customer and application user point of view. Some technical details arrive there, but, of course, only at quite a high level.

The context diagrams and process maps (workflows) are parts of the Conceptualization Document and visually show how the application works. The Use Case diagram is a formal UML diagram, showing the application functionality from the client point of view. That diagram is well known for the Architecture and Design competitions. Any other diagrams and maybe screen shots of the proposed application are appreciated in the Conceptualization challenges, but they are fully optional.

The documents for the Specification competition are as following:

Please note, the most input documents are from the previously finished Conceptualization contest. And the most important output is BRD. This is a formal requirements specification (full with technical details) for starting the Architecture phase of application development. There are two main sections:

• Logical Requirements
  Every use case from the Conceptualization Document should be expanded by the activity diagram. The Activity UML diagram shows the high level application actions, which are needed for implementing the feature, defined by the use case item. Next, each action from the activity diagram is described with technical details. Every data field and data format is described and the validation rules are provided. The requirements from Conceptualization Document are clarified, expanded, and more technical details should be added. All the alternative flows (like error messages) are described.
• Technical Requirements
  Defines the common GUI requirements, application look and feel, communication interfaces with external systems, used environment (OS, DB, web-servers, hardware, etc), performance and security needs.

Competition Process

The input documents are not enough for those competitions. The reason is that the client will select the competitor by one simple rule – which competitor showed the best understanding of the customer business needs. Some of those needs are provided in Questionnaire (in very brief and informal way), some are in the customer’s minds, others – maybe the client will remember them just during review.

So, the most needed skills for Conceptualization and Specification competitions – are communication skills. Constantly ask the client questions every day of the competition, request additional diagrams, screenshots, maybe currently used business documents, and so on. Try to be at the customer’s and at the user’s place for the proposed application. Maybe, some client ideas could be modified and any creative suggestions for the application are much appreciated. But note, we have to satisfy and not confuse the customer. So, any new ideas should be first clarified and confirmed on the forum.

Actually, there are just two tasks to success in such competitions:

1. A good understanding of the client’s needs.
2. Carefully documenting the business needs of the application.

Technically speaking, the competitors should just fill some output Word-based templates (with guidelines provided), draw use cases and activity UML diagrams, and some high level Visio-based structures of the application. The usage of MS Visio and MS Word/Excel shareware is not required, and some options of free software are available. But please note, MS Visio outperforms other tools very much and it is just faster to use Visio for making diagrams.

The judging process of the Conceptualization and Specification competitions is different (if compared to Architecture and Design). The reviewers are customers and TopCoder PMs. The Conceptualization competition has recently changed to the mini-tournament format: http://forums.topcoder.com/?module=Thread&threadID=630177&start=0

There are two rounds of each Conceptualization competition. In the first round, the customer will subjectively select three winners (with prizes like $100, $75, $50 and no DR points). And to win in round 1, we have to convince the customer that our submission better describes the customer’s needs. The second round is used to improve quality of the initial submissions. The client accumulates all the new/fresh ideas from the submissions and will post them on the forum. The submissions are kept non-public, and all participants from the round 1 can post improved submissions in round 2. Then the submissions will be judged according to the formal scorecard, which evaluates quality aspects of each section of the submitted documents. A total score higher than 75% is needed to pass round 2 and winners will be selected by higher scores.

Judging of Specification competition is very similar – just round 1 is absent.

The TopCoder has plans to invite community members for reviewing Conceptualization and Specification challenges. They will be able to check much more detail and may be even have an influence on customer.

Tips & Tricks

The next guidelines were prepared after winning several conceptualization and specification competitions:

1. Print client documents and carefully read it several times in a comfortable place. Mark all confusing and non-clear places. Try to imagine the entire application picture in your mind.
2. Ask questions on the forum about all non-clear issues in the client documentation.
3. Write the high level overview and all the easy topics (like performance, security, etc.).
4. Replay the application in your mind several times from different actor’s point of view. You will find all the external subsystems and potential flows after that.
5. Next, describe the current and proposed flow (for the Conceptualization competitions).
6. The Context Diagram must have your application in the center, but users and external systems – around the central circle. This diagram should be informative and not bulky at the same time.
7. Please think about buying MS Visio – that’s a great tool for diagrams, very powerful, stable and fast.
8. Several process map (workflow) diagrams should be provided (for Conceptualization competition), and they should be quite high level. But all inputs/outputs and main processing steps should be shown.
9. When describing the process map, we have to provide slightly more details (not just process step’s names).
10. The Use Case diagram should be designed from the user’s points of view and should be high level. Only business features should be shown and much room for the next Architecture and Design phases should be left. Please divide large use case diagrams to produce several smaller ones (for example, provide one use case diagram per each actor).
11. Each use case will be expanded by requirements (for the Conceptualization competition). This is very important part of the Conceptualization document. Please provide all the high level requirements in the clear form and without any low level details (up-to next Specification competition).
12. Each use case will be expanded by activity diagrams (for the Specification competition). Please be ready to produce dozens of such diagrams, which should not be large. Validation and error conditions are expected on the activity diagrams by most TC PMs. Please do NOT name decision/merge diamonds, but produce name guards on arrows and add a question bubble before decision diamonds. If activity diagram becomes large (not readable after zooming and placing to the Word document) – then please divide it by several smaller ones (there is a scorecard question penalizing for large activity diagrams).
13. The Specification competitions need a lot of tables for all the data used in the proposed application. The tables will contain field names, formats, validation rules and description. Please use common sense for setting field sizes and validation rules.
14. Spell-check text documents. Carefully submit all deliverables with double check (by downloading submitted file).

Summary

In short, the Conceptualization and Specification competitions define the high level requirements for applications to be developed at TopCoder. The Conceptualization is mostly focuses on explanation of the business process and high level requirements. The Specification expands requirements, makes them traceable, and describes how to test the expected functionality of the application. Those competitions being posted here: http://www.topcoder.com/wiki/display/tc/Software+Specification+Active+Contests

The winner responsibilities are: