| | 1 | [[TOC]] |
| | 2 | = !BluePrint: !BluePrint = |
| | 3 | |
| | 4 | == What is a !BluePrint? == |
| | 5 | |
| | 6 | We use [http://en.wikipedia.org/wiki/Blueprint !BluePrints] to capture ideas, |
| | 7 | requirements and design options for Eden components. |
| | 8 | |
| | 9 | The Blueprints should act as the [http://en.wikipedia.org/wiki/Requirement Requirements] specification for [DeveloperGuidelinesTesting Testers] to work with.[[BR]] |
| | 10 | 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]] |
| | 11 | [http://mekongict.org/2010/06/user-oriented-design/ User-Oriented Design] |
| | 12 | [[BR]] |
| | 13 | 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 |
| | 14 | |
| | 15 | 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]). |
| | 16 | |
| | 17 | 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] |
| | 18 | |
| | 19 | !BluePrints can be used by yourself or other contributors to: |
| | 20 | |
| | 21 | - develop and evaluate solutions |
| | 22 | - develop test cases |
| | 23 | - write documentation |
| | 24 | |
| | 25 | Typically, a !BluePrint would contain the following sections: |
| | 26 | |
| | 27 | ||Section||Contents|| |
| | 28 | ||Description||Introduction into the problem and general description of the suggested solution|| |
| | 29 | ||Requirements||Outline of the requirements|| |
| | 30 | ||Use-Cases||Descriptions of use-cases of the suggested solution|| |
| | 31 | ||Design||Suggestions for the design of the solution|| |
| | 32 | ||Implementation||List of existing implementations|| |
| | 33 | |
| | 34 | !BluePrints are developed collaboratively and in iterations. You can just start with |
| | 35 | some bullet points, discuss the idea with others and then elaborate. |
| | 36 | |
| | 37 | Tipp: keep the !BluePrint as clear and simple as possible |
| | 38 | |
| | 39 | == Description == |
| | 40 | |
| | 41 | Start with a description of the solution you have, remember to include: |
| | 42 | |
| | 43 | - an introduction of the problem |
| | 44 | - a description of the stakeholders |
| | 45 | - overview of the architecture of the solution |
| | 46 | - important functionality to be implemented |
| | 47 | |
| | 48 | == Requirements == |
| | 49 | |
| | 50 | Outline [http://en.wikipedia.org/wiki/Requirements_analysis requirements] for the solution, typically including: |
| | 51 | |
| | 52 | - Functional requirements |
| | 53 | - [http://en.wikipedia.org/wiki/Non-functional_requirements Non-functional requirements] |
| | 54 | - Applicable standards |
| | 55 | - System Constraints |
| | 56 | - Interoperability Aspects |
| | 57 | |
| | 58 | If you include links to external resources, please remember to describe what (contents+format) they contain. |
| | 59 | |
| | 60 | == Use-Cases == |
| | 61 | |
| | 62 | Describe the use-cases of the solution in detail, typically including: |
| | 63 | |
| | 64 | - actors and use-cases |
| | 65 | - activities (work flow) from the user's perspective |
| | 66 | |
| | 67 | Tipp: a simple, fast and multi-platform tool to draw UML diagrams is [http://www.umlet.com UMLet] (Java-based UML drawing tool). |
| | 68 | |
| | 69 | == Design == |
| | 70 | |
| | 71 | Describe the possible design of the suggested solution, typically including: |
| | 72 | |
| | 73 | - data model (e.g. EER or class diagrams) |
| | 74 | - interaction models and sequences |
| | 75 | - screen mockups and wireframes |
| | 76 | |
| | 77 | It is absolutely reasonable (in fact - desired) to have alternative design options. |
| | 78 | |
| | 79 | == Implementation == |
| | 80 | |
| | 81 | Append a list of implementations of this !BluePrint, each including: |
| | 82 | |
| | 83 | - a brief description of the implementation (date/time, name, design options chosen) |
| | 84 | - a link to the code |
| | 85 | - list of deployments of the implementation |
| | 86 | - links to case studies |
| | 87 | - short analysis of achievements/problems |
| | 88 | |
| | 89 | ---- |
| | 90 | BluePrints |