| 6 | | The Blueprints should act as the [http://en.wikipedia.org/wiki/Requirement Requirements] specification for [DeveloperGuidelinesTesting Testers] to work with.[[BR]] |
| 7 | | This 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]] |
| 8 | | [http://mekongict.org/2010/06/user-oriented-design/ User-Oriented Design] |
| 9 | | [[BR]] |
| 10 | | It 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 |
| 11 | | |
| 12 | | 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]). |
| 13 | | |
| 14 | | 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] |
| | 6 | - [wiki:BluePrintBluePrint About BluePrints] |
