Reword use cases page

[jpmckinney]

The 'use cases' on this page are more like 'goals'. http://standard.open-contracting.org/latest/en/getting_started/use_cases/ My understanding of nomenclature is:

• goal: 'Value for money'
• outcome: Related to the goal of value for money, my desired outcome is 'More bidders per process', as my hypothesis is that more competition leads to lower cost to government.
• indicator: I design a methodology for periodically measuring progress against that outcome, e.g. number of bidders per process at time X compared to time Y, scoping to, e.g., procurement of medication. The same indicator may be relevant to multiple outcomes and goals.
• use case: A specific instance of using data to achieve an outcome in pursuit of a goal, which may involve the measurement of an indicator. It may be possible to generalize a use case beyond the specific context in which it was recorded.
• requirement: The specific needs to satisfy the use case, which may be needs for data, information, publication patterns, stakeholder engagement, etc.
• user need: Same as 'requirement'.
• user focus: An attention to users, which in the context of this discussion may simply mean attention to the cases where users can use OCDS to achieve outcomes in pursuit of goals.

See internal comment about this page: https://crm.open-contracting.org/issues/2217#note-21

[timgdavies]

We had a good discussion with a user researcher a few weeks ago, whose basic take was: the terminology is used very differently by different communities of practice - so the important thing is finding your terminology and being consistent about it.

I don't think we want to go down the line of the very atomistic use case language from software and systems engineering. The essence of what we're trying to do with that page is to highlight user-centricity of approach.

I think there is a risk that switching to language of 'goals' removes the agent from the story, so going with a language of 'High level use cases' for our four categories, or just 'High level user needs' might work better?

[jpmckinney]

A challenge is that we are moving towards describing more granular use cases (not as atomistic as software though), e.g. "As a researcher at a corruption monitoring organization (NGO), I use contracting data to find single-bidder or low-bidder processes as an indicator of corruption risk." (I think we can settle on an approach that just looks at the meaning of the words we use; in this example, there is a literal instance of usage, or 'use case'.)

The example use case would fall within the category of "public integrity". However, the user need that it establishes (e.g. tender/numberOfTenderers) is also relevant to use cases within each of the other categories (e.g. "as a business, I want to find buyers who tend to run single-bidder or low-bidder processes, so that I have only one competitor to beat"). Our user needs in general don't fall neatly into our four categories, except through the telling of a specific use case. So, I'd have trouble calling the categories "high level user needs". (Documenting use cases is a way of establishing requirements ('user needs'), but use cases are not interchangeable with user needs.)

We could call them "high level use cases", in so far as they do serve to organize use cases, but I think the words 'goal' or 'outcome' serve to remind the reader of the orientation we want them to take, and help distinguish between: the specific instances of usage, the requirements to perform such instances, and the goals being pursued through those instances. There's still ample opportunity to have lots of agency in the documentation.

Also, 'goal' is a word that implies an agent. You can't have goals if you lack agency.

[jpmckinney]

In #1302, the page is renamed to "user needs".