| Version 35 (modified by , 11 years ago) ( diff ) |
|---|
Blueprint - Template
Table of Contents
BluePrints may begin as a rough collection of ideas, but ideally should be developed into formal documentation to support the development of new features.
BluePrints are best developed collaboratively through several iterations. You can just start with some bullet points, discuss the idea with others and then elaborate.
If you include links to external resources, please remember to describe what (contents+format) they contain.
Tip: Keep the BluePrint as clear and simple as possible - while still providing enough details to clearly communicate the features and design
BluePrint Template
Copy and paste this into the wiki editor for a new page, then fill in the sections:
= !BluePrint: <Name of the solution> = [[TOC]] == Introduction == <Briefly describe the solution?> <What problem is this solution solving?> <How will this solution add value to Sahana?> <Name any similar existing solutions> == Stakeholders == <Who will be the users of the solution?> <Who else will be affected by this solution? eg. Developers, Users of Existing Functionality that may be changed?> <How will stakeholders be affected?> Tip: Engage these stakeholders in the development of your !BluePrint. == User Stories == <http://en.wikipedia.org/wiki/User_story> <A good User Story should answer the following questions:> <* Who the user is> <* What they want the solution to do for them?> <* Why they want it to do that? (goal)> <eg. A <type of user> wants the solution to <do something for them> so that <can achieve a goal>.> == Requirements == <Group requirements in subsections, e.g.,, etc.> <http://en.wikipedia.org/wiki/Requirements_analysis requirements> <Identify different types of requirements:> === Functional === === Non-functional === http://en.wikipedia.org/wiki/Non-functional_requirements === Interoperability === === Standards === === System Constraints === == Design == <Where relevant include alternative design options> === Data Model === (e.g. EER or class diagrams) === Workflows === <Diagrams or Pseudocode> === Site Map === <for User Interface solutions> === Wireframes === <for User Interface solutions> === Technologies === == Current Implementation == <Leave open for a list of existing implementation of this solution in Sahana Eden:> <*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> == Planned Implementation == <List of goals for your implementations which you (include your name/github repo/IRC handle) are currently working on> == Future Extensions == <List of features which could be included, but are outside of the scope of this extension> == Outstanding Questions == <Questions about the features or design that haven't been (and need to be) answered> == References == <Links to external resources> ---- BluePrint
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
Also see:
Note:
See TracWiki
for help on using the wiki.
