|Version 17 (modified by 11 years ago) ( diff ),|
Table of Contents
BluePrints | BluePrint
What is a BluePrint?
We use BluePrints to capture ideas, requirements and design options for Eden components.
It can then be mocked-up using Wireframes, using tools like:
- Pencil (FOSS, Add-on for Firefox 3.5+, GPL2)
- Dia (FOSS, GPL)
- Balsamiq (non-OSS, US$79)
- GoogleDoc's new Drawing functionality
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 several 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
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
Tipp: involve the stakeholders you have named already in the development of your BluePrint.
Outline requirements for the solution, typically including:
- 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.
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 UMLet (Java-based UML drawing tool).
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.
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
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 Behaviour-Driven Development style to formalise requirements whilst still being Agile (e.g. using tools like pyspec or PyFIT).
- Joel Spolsky has a good write-up on Why to write Functional Specs & How