Model Call Girl in Tilak Nagar Delhi reach out to us at 🔝9953056974🔝
CKAN for RDM workshop
1. CKAN for Research Data
Management
Workshop, London,
18th February 2013
Joss Winn, University of Lincoln
http://orbital.blogs.lincoln.ac.uk
2. “There are no such things as
requirements, there are only wishes.” Kent Beck, 2000.
Requirements = wishes
Let’s split into different types of users and create
wish lists. If you like, you can be a ‘proxy
user’, taking on the role of someone else.
3. 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 is
provided 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
4. Examples
Format: As a X user, I want to X, so that X
e.g. Who, what, why?
“As a Publisher I want to Archive resources so that old or out of date
resources can be hidden”*
“As a User I want to Browse and search for other users so that I know
about 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
5. 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.
6. Creating Use Cases
Can we group our requirements into use cases?
How do certain requirements relate to one
another? e.g.
• Data store requirements
• Data repository requirements
• Data catalogue requirements
Example use case: http://j.mp/Y6uWvD