THOLOS Survey Application Architecture

Project Overview

Welcome to the THOLOS Survey Application Architecture challenge! This is the first technical challenge in a series to build out a scalable product testing survey application! We may be starting small with the scope of this application, but the possibilities in the future are endless! Get in on the ground floor of this exciting initiative today and join us as we map the future of product prototype testing!

 

Requirements

In this challenge we are looking for architecture for a survey application using specific technologies. The application is designed to be a MVP (minimum viable product), and thus we are looking to keep it as simple as possible. The architecture should be designed in such a way that the application can be scaled in the future, and addition of new features or modules will be easy.

There are specific technology requirements listed below:

• Database - Connector required for SQL Server and mySQL

• REST API - .NET

• Front End - Angular.js, HTML5, CSS, Javascript, Zurb Foundation

See the attached wireframes for a view into the application’s expected functionality. Also attached to this challenge is a set of user flows and persona documentation to help you understand who will use this application and how they expect to use it.

Some architecture decisions have been defined in advance. The application must use a .NET based REST API to deliver data to an Angular.js front end. The application will be hosted in a Windows Server environment.

The two primary user types documented will each use a different form factor:

• Survey Manager - Desktop/Laptop Browser Based

• Participant - Mobile Browser Based

Other notable application requirements:

• Authentication

  • Simple password based login is acceptable. No SSO requirements at this time.

  • Participant users will use a different login/password for every survey. There must be a relationship between survey and user to match these up. If a user is participating in more than one survey, they will have a separate login for each.

  • Participant usernames/passwords must be generated by the system based on the number of participants in the survey. A csv output of this data can be downloaded by the Survey Manager at any time after the creation of the survey.

  • First/Last name  or any other personally identifiable information of participants will not be tracked in the application.

• Authorization

  • Survey Managers:

    • Access to only Survey Manager pages (see wireframe)

  • Participants

    • Access only to participant pages

• Question data

  • Question data will be loaded directly into the database by a database administrator.

  • Some questions will have follow-up questions based on the answer. See the existing question data structure for more details.

• In-Progress Surveys

  • Progress through the questionnaire must be saved as each question is answered. A user should be able to resume an in progress set of questions after leaving the website and logging back in.

• Survey Results

  • A survey manager should be able to download the following related to any survey:

    • CSV Output of survey results

    • Zip file containing before/after images of products, with corresponding participant ID & Prototype Code.

Final Submission Guidelines

Deliverables

Submit the following to TopCoder Online Review:

• Architecture Specification Document

• API Specification Documentation (swagger.io) - must include data model definitions in JSON

• TCUML Interface / Class Diagrams, Data Model, Sequence Diagrams, etc...