Skip to content

Delivery: Design Draft 1

Jump to bottom
Alice edited this page Dec 1, 2017 · 7 revisions

Delivery

This is the delivery of the Design Draft 1. This delivery is to check that you have successfully interpreted your brief, to produce a set of requirements, and that you have been able to use those requirements, with your investigations and implementation statements, to produce an initial design.

The design is a collection of components, and the relationships between them. It is closely coupled with the implementation technology.

Operating as a small business, we use the design to give us the maximum understanding of what needs to be done, with the minimum of effort. We change the design according to new information, right through the design process, and right into the construction phase. We add to the design as needed. The complexity of the design follows the complexity of the project we are creating. For example, if we were creating a new communications protocol within our product, then obviously, it would need to be incorporated in the design. If not, we just state the standard protocol being used and leave it at that.

We will be using the design to do these things:

  1. Estimate how much the MVP will cost (in effort)
  2. How long the MVP will take to produce (given our effort commitment)
  3. Help us plan construction of the product
  4. Help us write a proposal to our client, summarising the requirements, and costs.

To help you understand what we mean, please take a look at our example project, WildLogging. We also have a bit more how-to, here

What we need

1: Delivery Document: design.md

This is the top-level document of your delivery. If you haven't yet done so, create a folder 'deliveries' in the top level of your project. create a folder:

delivery_01_12_2017

create a markdown file in the folder:

design-1.md

In the file:

  1. Title: Project: Team name
  2. Brief: Link to brief
  3. Introduction: introduce the project and a short summary of the requirements
  4. Budget: state the total effort budget in hours. Link to the checked-in spreadsheet in GitHub
  5. Features: link to the features board
  6. Investigations: link to the investigations board
  7. Implementations: link to the implementations board
  8. Design: link to the design board
  9. Tasks: link to the tasks board

2: Spreadsheet: effort_committment.xlsx

  • Update the spreadsheet with your team's current commitment
  • Check it in to your project on GitHub

3: Features Board

As complete a description of our Minimum Viable Product as possible:

  • UI
  • Behaviour
  • Data Model For each Feature, link to an investigation, if needed. For each Feature, link to an implementation statement, if needed. For UI, you may need to describe UI elements. If so, please use Evolus Pencil. You can attach descriptive wireframes pics to your features. Don't forget to check your pencil files into your repo!

4: Investigations board

The investigations board is relevant throughout the project, so is never considered complete! Contains the following lists:

  • Todo: An up-to-date list of investigations needed, prompted by describing the system in the Features board.
  • Pending: A list of investigations currently being performed. Each investigation needs an assigned person, and an estimate of the time taken for that person to do it.
  • Done: a list of completed investigations. Each investigation needs a note of the time taken to do it, a conclusion and links to evidence (source code, etc).

4. Implementations Board

An up-to-date list of implementation statements.
e.g.

Ionic / Cordova
Reason: Client request

e.g.

Stored Queue
Reason: need to store data in files for upload.
Link: Link to Investigation

5. Design Board

A list of components, with enough documentation to link them together. Start with an overview, which describes the main components of the system (Apps, APIs, Backends), then drill down into the component hierarchy. Describe each component just enough to get an understanding of its complexity and where it fits. If the the components are too complex for one board, separate them out into their own boards. Each board must have its own Overview, and be link to from its parent.

This process is there to help you understand the components which will fulfil a feature. It's up to you to put helpful information into the components, but at a minimum, link to the feature which is being fulfilled.

Remember, this is a draft: you will be embellishing this design as is becomes apparent how much information needs to be added to each component.

6. Tasks Board

A list of tasks to perform to construct the components of the design. As you describe your components in the design board and link them together, their dependencies will become apparent. Starting at the foundation components, list the tasks you will need to do to create them.

This process is there to help you understand what needs to be done, by whom, and in what order. It's up to you to put helpful information into the tasks, but at a minimum, link to the component which is being affected.

You will be estimating how long it takes to do each task, later.

Important!

  1. Your Features must fully describe your MVP
  2. Your Design must completely fulfil your features.
  3. Your Tasks must fully implement your components
  4. You effort budget must be up to date

Don't forget to email us :-)

Clone this wiki locally