[[TOC]]
[wiki:BluePrints] | !BluePrint
= !BluePrint: !BluePrint =

== What is a !BluePrint? ==

We use [http://en.wikipedia.org/wiki/Blueprint BluePrints] to capture ideas, requirements and design options for Eden components.

This can start with a simple [http://en.wikipedia.org/wiki/User_story User Story] (or a full [http://en.wikipedia.org/wiki/Use_case Use Case])

 - [http://mekongict.org/2010/06/user-oriented-design/ User-Oriented Design]
 - [http://www.jnd.org/dn.mss/activity-centered_design_why_i_like_my_harmony_remote_control.html Activity-Centered Design]

It can then be mocked-up using [http://webstyleguide.com/wsg3/10-forms-and-applications/4-design-process.html Wireframes], using tools like:

  - '''[http://code.google.com/p/evoluspencil Evolus Pencil]''' (FOSS, also as Add-on for Firefox 3.5+, GPL2)
    - Install Pencil as Firefox Add-on directly from [http://code.google.com/p/evoluspencil/downloads/detail?name=Pencil-1.2-0-fx.xpi here]
  - [http://live.gnome.org/Dia Dia] (FOSS, GPL)
  - [http://balsamiq.com Balsamiq] (non-OSS, US$79)
  - [http://doc.google.com GoogleDoc]'s new Drawing functionality

!BluePrints can be used by yourself or other contributors to:

    - develop and evaluate solutions
    - develop [wiki:DeveloperGuidelinesTesting test cases]
    - write documentation

Typically, a !BluePrint would contain the following sections:

    ||'''Section'''||'''Contents'''||
    ||Description||Introduction into the problem and general description of the suggested solution||
    ||Requirements||Outline of the requirements||
    ||Use-Cases||Descriptions of use-cases of the suggested solution||
    ||Design||Suggestions for the design of the solution||
    ||Implementation||List of existing implementations||

!BluePrints are developed collaboratively and in several iterations. You can just start with
some bullet points, discuss the idea with others and then elaborate.

'''Tip:''' keep the !BluePrint as clear and simple as possible
== Description ==

Start with a description of the solution you have in mind, remember to include:

    - an introduction of the problem
    - overview of the stakeholders
    - overview of the architecture of the solution
    - important functionality to be implemented

'''Tip:''' involve the stakeholders you have named already in the development of your !BluePrint.
== Requirements ==

Outline [http://en.wikipedia.org/wiki/Requirements_analysis requirements] for the solution, typically including:

    - Functional requirements
    - [http://en.wikipedia.org/wiki/Non-functional_requirements Non-functional requirements]
    - Applicable standards
    - System Constraints
    - Interoperability Aspects

If you include links to external resources, please remember to describe what (contents+format) they contain.

== Use-Cases ==

Describe the use-cases of the solution in detail, typically including:

    - actors and use-cases
    - activities (work flow) from the user's perspective

'''Tip:''' a simple, fast and multi-platform tool to draw UML diagrams is [http://www.umlet.com UMLet] (Java-based UML drawing tool).

== Design ==

Describe the possible design of the suggested solution, typically including:

    - data model (e.g. EER or class diagrams)
    - interaction models and sequences
    - screen mockups and wireframes
    - code samples

'''Tipp:''' it is absolutely reasonable (in fact - desired) to have alternative design options.

== Implementation ==

Append a list of implementations of this !BluePrint, each including:

    - a brief description of the implementation (date/time, name, design options chosen)
    - a link to the code
    - list of deployments of the implementation
    - links to case studies
    - short analysis of achievements/problems

== !BluePrint Template ==

Copy and paste this into the wiki editor, then fill in the sections:

{{{
[[TOC]]
= !BluePrint: <Name of the solution> =

== Introduction ==
<Introduce the problem the solution is meant for>
<Explain why this could be relevant for Eden>

== Description ==
<Briefly describe the solution, e.g. start with a user story>
<Name existing solutions, e.g. in other applications>

== Requirements ==
<Outline the requirements here>
<Group requirements in subsections, e.g. functional, non-functional, interoperability etc.>

== Use-Cases ==
<Describe actors and use-cases>
<Describe workflows>
<Include diagrams where useful>

== Design ==
<Describe a possible design, repeat any design sections for alternative designs>
<Include diagrams, screen mockups and wireframes where useful>

== Implementation ==
<Leave open for a list of implementation>

----
BluePrints
}}}

== Eden Development Model ==

  - We could look at following a [http://behaviour-driven.org/BDDProcess Behaviour-Driven Development] style to formalise requirements whilst still being [http://en.wikipedia.org/wiki/Agile_software_development Agile] (e.g. using tools like [http://www.codeplex.com/pyspec pyspec] or [http://pypi.python.org/pypi/PyFIT/0.8a2 PyFIT]).
  - Joel Spolsky has a good write-up on [http://www.joelonsoftware.com/articles/fog0000000036.html Why to write Functional Specs] & [http://www.joelonsoftware.com/articles/fog0000000035.html How]

----
BluePrints