Requirements
DfR must be targeted at researcher's real needs or it will not be used. This requires us to find out what those needs are and see how to meet them. This is an area that has many unknowns and it is easy to make false assumptions. But simply asking researchers what they want will not work since DfR is not bespoke software automating well known processes. It is a creative work that imagines what could be a good infrastructure for researchers. So we must create a design that is innovative but still grounded in satisfying real needs. In particular, we anticipate a new research life cycle that includes retaining and curating valuable data for future researchers. Since we are designing a software infrastructure in the face of many unknowns we must use methodologies that help this project to reduce false assumptions and produce value. This section contains the work products of the agile requirements development methodologies that guide this project. In particular, this process is guided by Minimum Viable Products methods that balance ideas with reality.Assumptions
Surveys
Interview Questionnaires
Requirements Interviews
This section contains the notes of individual interviews of DfR constituencies to help learn their needs and constraints.
User Stories
The majority of requirements are derived and traced from user stories. The stories are scenarios that describe, in the users language, what they want to do with the DfR software. At the most detailed level, developers should be able to implement the story within a single iteration. Anything more complex than that is called an "epic" and must be subdivided into stories for development. I most cases the story should be written defining the actor and what they want the software to do. Actors are roles, they may be people or processes. The story should include who (the actor), what (needs to be done) and why (it needs to be done). It should be clear how to test the story for acceptance.
