Changes between Version 32 and Version 33 of BluePrint/Guidelines/Template


Ignore:
Timestamp:
04/12/13 03:34:22 (8 years ago)
Author:
Michael Howden
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrint/Guidelines/Template

    v32 v33  
    11= Blueprint - Template =
    22[[TOC]]
     3!BluePrints may begin as a rough collection of ideas, but ideally should be developed into formal documentation to support the development of new features.
    34
    4 Although !BluePrints may begin as a rough collection of ideas, ideally they should be developed into formal documentation to support the development of features and requirements. This will contain the following sections:
    5 
    6     ||'''Section'''||'''Contents'''||
    7     ||Description||Introduction into the problem and general description of the suggested solution||
    8     ||Users/Stakeholders|| Who will be engaged?||
    9     ||User Stories|| http://en.wikipedia.org/wiki/User_story User Story ||
    10     ||Requirements||Outline of the requirements||
    11     ||Use-Cases||Descriptions of use-cases of the suggested solution||
    12     ||Design||Suggestions for the design of the solution||
    13     ||Implementation||List of existing implementations||
    14 
    15 !BluePrints are developed collaboratively and in several iterations. You can just start with
    16 some bullet points, discuss the idea with others and then elaborate.
    17 
    18 '''Tip:''' keep the !BluePrint as clear and simple as possible
    19 
    20 == Description ==
    21 Start with a brief description of the solution you have in mind, remember to include:
    22 
    23     - an introduction of the problem
    24     - overview of the technology architecture of the solution
    25     - important functionality to be implemented
    26 
    27 '''Tip:''' involve the stakeholders you have named already in the development of your !BluePrint.
    28 
    29 == Users/Stakeholders ==
    30 A list of the stakeholders/users who will be engaged in the solution.
    31 
    32 == User Stories==
    33 A good User Story should answer the following questions:
    34 * Who the user is
    35 * What they want the application to do for them?
    36 * Why they want it to do that? (Purpose)
    37 
    38 '''A <type of user> wants the system to <do something for them> so that <can achieve a goal>.'''
    39 
    40 == Requirements ==
    41 
    42 Outline [http://en.wikipedia.org/wiki/Requirements_analysis requirements] for the solution, typically including:
    43 
    44     - Functional requirements
    45     - [http://en.wikipedia.org/wiki/Non-functional_requirements Non-functional requirements]
    46     - Applicable standards
    47     - System Constraints
    48     - Interoperability Aspects
     5!BluePrints are best developed collaboratively through several iterations. You can just start with some bullet points, discuss the idea with others and then elaborate.
    496
    507If you include links to external resources, please remember to describe what (contents+format) they contain.
    518
    52 == Use-Cases ==
    53 
    54 Describe the use-cases of the solution in detail, typically including:
    55 
    56     - actors and use-cases
    57     - activities (work flow) from the user's perspective
    58 
    59 '''Tip:''' a simple, fast and multi-platform tool to draw UML diagrams is [http://www.umlet.com UMLet] (Java-based UML drawing tool).
    60 
    61 == Design ==
    62 
    63 Describe the possible design of the suggested solution, typically including:
    64 
    65     - data model (e.g. EER or class diagrams)
    66     - interaction models and sequences
    67     - screen mockups and wireframes
    68     - code samples
    69 
    70 '''Tip:''' it is absolutely reasonable (in fact - desired) to have alternative design options.
    71 
    72 == Implementation ==
    73 
    74 Append a list of implementations of this !BluePrint, each including:
    75 
    76     - a brief description of the implementation (date/time, name, design options chosen)
    77     - a link to the code
    78     - list of deployments of the implementation
    79     - links to case studies
    80     - short analysis of achievements/problems
    81 
    82 == References ==
    83 Links to external resources
     9'''Tip:''' Keep the !BluePrint as clear and simple as possible - while still providing enough details to clearly communicate the features and design
    8410
    8511== !BluePrint Template ==
    8612
    87 Copy and paste this into the wiki editor, then fill in the sections:
     13Copy and paste this into the wiki editor for a new page, then fill in the sections:
    8814
    8915{{{
     
    9218
    9319== Introduction ==
    94 <Introduce the problem the solution is meant for>
    95 <Explain why this could be relevant for Eden>
     20<Briefly describe the solution?>
     21<What problem is this solution solving?>
     22<How will this solution add value to Sahana?>
     23<Name any similar existing solutions>
    9624
    97 == Description ==
    98 <Briefly describe the solution, e.g. start with a user story>
    99 <Name existing solutions, e.g. in other applications>
     25== Stakeholders ==
     26<Who will be the users of the solution?>
     27<Who else will be affected by this solution? eg. Developers, Users of Existing Functionality that may be changed?>
     28<How will stakeholders be affected?>
     29Tip: Engage these stakeholders in the development of your !BluePrint.
    10030
    10131== User Stories ==
     32<http://en.wikipedia.org/wiki/User_story>
     33<A good User Story should answer the following questions:>
     34<* Who the user is>
     35<* What they want the solution to do for them?>
     36<* Why they want it to do that? (goal)>
     37<eg. A <type of user> wants the solution to <do something for them> so that <can achieve a goal>.>
    10238
    10339== Requirements ==
    104 <Outline the requirements here>
    105 <Group requirements in subsections, e.g. functional, non-functional, interoperability etc.>
     40<Group requirements in subsections, e.g.,, etc.>
     41<http://en.wikipedia.org/wiki/Requirements_analysis requirements>
     42<Identify different types of requirements:>
     43=== Functional ===
     44=== Non-functional ===
     45http://en.wikipedia.org/wiki/Non-functional_requirements
     46=== Interoperability ===
     47=== Standards ===
     48=== System Constraints ===
    10649
    10750== Use-Cases ==
    108 <Describe actors and use-cases>
    109 <Describe workflows>
     51<Describe what the system does for different users>
    11052<Include diagrams where useful>
    111 < A <type of user> wants the system to <do something for them> so that <can achieve a goal>. >
     53Tip: a simple, fast and multi-platform tool to draw UML diagrams is [http://www.umlet.com UMLet] (Java-based UML drawing tool).
    11254
    11355== Design ==
    114 <Describe a possible design, repeat any design sections for alternative designs>
    115 <Include diagrams, screen mockups and wireframes where useful>
     56<Where relevant include alternative design options>
     57=== Data Model ===
     58(e.g. EER or class diagrams)
     59=== Workflows ===
     60<Diagrams or Pseudocode>
     61=== Site Map ===
     62<for User Interface solutions>
     63=== Wireframes ===
     64<for User Interface solutions>
     65=== Technologies ===
    11666
    11767== Implementation ==
    118 <Leave open for a list of implementation>
     68<Leave open for a list of existing implementation of this solution in Sahana Eden:>
     69<*a brief description of the implementation (date/time, name, design options chosen)>
     70<*a link to the code>
     71<*list of deployments of the implementation>
     72<*links to case studies>
     73<*short analysis of achievements/problems>
    11974
    12075== References ==
     
    12681
    12782== Eden Development Model ==
    128 
    12983  - 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]).
    13084  - 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]