[[TOC]] = !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. The Blueprints should act as the [http://en.wikipedia.org/wiki/Requirement Requirements] specification for [DeveloperGuidelinesTesting Testers] to work with.[[BR]] This could 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])[[BR]] [http://mekongict.org/2010/06/user-oriented-design/ User-Oriented Design] [[BR]] It can then be mocked-up using [http://webstyleguide.com/wsg3/10-forms-and-applications/4-design-process.html Wireframes] using a tool such as [http://live.gnome.org/Dia Dia], [http://balsamiq.com Balsamiq] or just [http://doc.google.com GoogleDoc]'s new Drawing functionality 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 can be used by yourself or other contributors to: - develop and evaluate solutions - develop 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 iterations. You can just start with some bullet points, discuss the idea with others and then elaborate. Tipp: keep the !BluePrint as clear and simple as possible == Description == Start with a description of the solution you have, remember to include: - an introduction of the problem - a description of the stakeholders - overview of the architecture of the solution - important functionality to be implemented == 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 Tipp: 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 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 ---- BluePrints