CKAN for Research Data Management Workshop, London, 18th February 2013 Joss Winn, University of Lincoln http://orbital.blogs.lincoln.ac.uk
“There are no such things asrequirements, there are only wishes.” Kent Beck, 2000. Requirements = wishesLet’s split into different types of users and createwish lists. If you like, you can be a ‘proxyuser’, taking on the role of someone else.
Essential components of a requirement• What should the required function/feature do?• Who is intended to use it?• How does it provide value?• What major constraints affect the design?Requirements evolve through negotiation and as further clarification isprovided during development. Today, we’re going to create ‘stories’that can be returned to at a later date.Taken from Cockburn(2005) Crystal Clear. A Human powered Methodology for Small Teams
ExamplesFormat: As a X user, I want to X, so that Xe.g. Who, what, why?“As a Publisher I want to Archive resources so that old or out of dateresources can be hidden”*“As a User I want to Browse and search for other users so that I knowabout others active on the site” *Go here for actual requirements from workshop: http://lncn.eu/mxz2* Taken from the (old) CKAN wiki list of user stories
The Constraints “What major constraints affect the design?”• Resourcing: “That would take four developers 6 months to implement” < Break it down!• Existing design/technology decisions: “The software is designed for the web, not a desktop application.” < Can desktop apps be written to use the web APIs?• Social constraints: “Most of our existing users would find that feature confusing/irrelevant.” < Create an extension for esoteric features.
Creating Use CasesCan we group our requirements into use cases?How do certain requirements relate to oneanother? e.g.• Data store requirements• Data repository requirements• Data catalogue requirementsExample use case: http://j.mp/Y6uWvD