Changes between Initial Version and Version 1 of BluePrint/Guidelines/Template


Ignore:
Timestamp:
11/10/10 09:48:44 (14 years ago)
Author:
Dominic König
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrint/Guidelines/Template

    v1 v1  
     1[[TOC]]
     2= !BluePrint: !BluePrint =
     3
     4== What is a !BluePrint? ==
     5
     6We use [http://en.wikipedia.org/wiki/Blueprint !BluePrints] to capture ideas,
     7requirements and design options for Eden components.
     8
     9The Blueprints should act as the [http://en.wikipedia.org/wiki/Requirement Requirements] specification for [DeveloperGuidelinesTesting Testers] to work with.[[BR]]
     10This 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]]
     13It 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
     15We 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
     17Joel 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
     25Typically, 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
     35some bullet points, discuss the idea with others and then elaborate.
     36
     37Tipp: keep the !BluePrint as clear and simple as possible
     38
     39== Description ==
     40
     41Start 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
     50Outline [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
     58If you include links to external resources, please remember to describe what (contents+format) they contain.
     59
     60== Use-Cases ==
     61
     62Describe 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
     67Tipp: 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
     71Describe 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
     77It is absolutely reasonable (in fact - desired) to have alternative design options.
     78
     79== Implementation ==
     80
     81Append 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----
     90BluePrints