= Blueprint - Template =
[[TOC]]
!BluePrints may begin as a rough collection of ideas, but ideally should be developed into formal documentation to support the development of new features. 

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

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

'''Tip:''' Keep the !BluePrint as clear and simple as possible - while still providing enough details to clearly communicate the features and design

== !BluePrint Template ==

Copy and paste this into the wiki editor for a new page, then fill in the sections:

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

== Introduction ==
<Briefly describe the solution?>
<What problem is this solution solving?>
<How will this solution add value to Sahana?>
<Name any similar existing solutions>

== Stakeholders ==
<Who will be the users of the solution?>
<Who else will be affected by this solution? eg. Developers, Users of Existing Functionality that may be changed?>
<How will stakeholders be affected?>
Tip: Engage these stakeholders in the development of your !BluePrint.

== User Stories ==
<http://en.wikipedia.org/wiki/User_story>
<A good User Story should answer the following questions:>
<* Who the user is>
<* What they want the solution to do for them?>
<* Why they want it to do that? (goal)>
<eg. A <type of user> wants the solution to <do something for them> so that <can achieve a goal>.>

== Requirements ==
<Group requirements in subsections, e.g.,, etc.>
<http://en.wikipedia.org/wiki/Requirements_analysis requirements>
<Identify different types of requirements:>
=== Functional ===
=== Non-functional ===
http://en.wikipedia.org/wiki/Non-functional_requirements
=== Interoperability ===
=== Standards ===
=== System Constraints ===

== Design ==
<Where relevant include alternative design options>
=== Data Model ===
(e.g. EER or class diagrams)
=== Workflows ===
<Diagrams or Pseudocode> 
=== Site Map ===
<for User Interface solutions>
=== Wireframes ===
<for User Interface solutions>
=== Technologies ===

== Current Implementation ==
<Leave open for a list of existing implementation of this solution in Sahana Eden:>
<*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>

== Planned Implementation ==
<List of goals for your implementations which you (include your name/github repo/IRC handle) are currently working on>

== Future Extensions ==
<List of features which could be included, but are outside of the scope of this extension>

== Outstanding Questions ==
<Questions about the features or design that haven't been (and need to be) answered>

== References ==
<Links to external resources>

----
BluePrint
}}}

== 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]

----
Also see:
* [BluePrint BluePrints]
* BluePrint/Guidelines