In this milestone, you will write a design proposal for a software engineering bot. That is, bad proposals may be rejected by the professor. So spend time in coming up with a good and crisp idea.
The proposal will be structured to include the following items:
- Problem Statement
- Bot Description
- 3 Use Cases
- Design Sketches
- Architecture Design
- Additional Patterns
You will also be working in a team of students. Remember to sign up for teams.
Remember, we are solving problems in the software engineering domain. This does not include problems, such as finding a parking spot, but it may include problems such as forgetting api tokens, drudgery associated with manually creating REST calls, difficulty in executing certain command lines tools, or not wanting to wake up at 3am to restart a server that crashed.
What is the problem? Why is it a problem?
This should be a good paragraph or two.
What does your bot do? Why is a bot a good solution for the problem? Does your bot have a converstation with users (e.g. hubot), or does it just response to events (e.g., coveralls bot on github)? Does your bot fit in one of the categories we talked about in class? A code drone vs documentation bot?
This should be a good two paragraphs.
A use case is a way to describe a task that a user wants to perform and the required sequence of steps needed to accomplish that task. It also includes possible error states. For more information about use cases, see slides.
Based on your design, describe at least three use cases that describes the primary functionality of your bot.
This is an example use case:
Use Case: Create a meeting
1 Preconditions
User must have google calendar api tokens in system.
2 Main Flow
User will request meeting and provide list of attendees [S1]. Bot will provide possible meeting times and user confirms [S2]. Bot creates meeting and posts link [S3].
3 Subflows
[S1] User provides /meeting command with @username,@username list.
[S2] Bot will return list of meeting times. User will confirm time.
[S3] Bot will create meeting and post link to google calendar event.
4 Alternative Flows
[E1] No team members are available.
You can think of this as a set of conversations/interactions you want to be able to support with your bot.
- Create a wireframe mockup of your bot in action.
- Create a storyboard that illustrates the primary task that a user undergoes with bot.
- Create a diagram that illustrates the components of your bot, the platform it is embedded in, third party services it may use, data storage it may require, etc.
- Describe the architecture components in text.
- Describe any constraints or guidelines that should be established in building software for your architecture (e.g., a bot cannot send data from one user to another user).
- Describe any additional design patterns that may be relevant for your bot design.
This section should be several diagrams + paragraphs of text. This is the opportunity to really think through how you might build your system. Consider all the criteria listed here in your description. Generic architectures that do not properly reflect a solution will receive low scores.
Create a team repository for your bot. In your README.md, list all team members and their unity ids. Add a DESIGN.md document (linked from README.md) with the following materials included.
- Problem Statement (15%)
- Bot Description (10%)
- Use Cases (15%)
- Design Sketches (30%)
- Architecture Design + Additional Patterns (30%)
DUE: FRIDAY, SEPTEMBER 22, Midnight.
Submit here.