| 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. |
| 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 |
| 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 === |
| | 45 | http://en.wikipedia.org/wiki/Non-functional_requirements |
| | 46 | === Interoperability === |
| | 47 | === Standards === |
| | 48 | === System Constraints === |
