Proposed simple guidelines for writing use cases and requirements

1. Proposed simple guidelines for writing use cases and requirements Group Name: oneM2M WG1 / WG2 Source: Joerg Swetina (NEC), Ataru Kobayashi (NEC), JaeSeung Song (NEC) Meeting Date: 2012-10-11 Agenda Item: 7

2. The following two slides are an attempt to remind of some very simple guidelines (rules-of-thumb) when writing use cases or requirements. • They should be helpful, in particular while dedicated oneM2M specification templates and explicit drafting rules are not available. • Other useful documents: • http://www.reqexperts.com/media/papers/writing_good_requirements.htm • http://www.etsi.org/WebSite/document/Legal/ETSI%20Drafting%20Rules%20January%202012.pdf

3. Writing use cases • Use cases describe in common language examples how the M2M System should function. They highlight one or a few aspects of specific capabilities. • Use cases are not requirements (but requirements may be derived from use cases) • Explain roles of commonly (in multiple use cases) used stakeholders/actors in a separate section of the document prior to describing individual use cases. • If a term is used across multiple use cases (and needs to be used consistently) capture terminology and definition in the “Definitions” section. • Per use case: • Identify stakeholders/actors and explain aims of stakeholders/actors in the use case. • [optional] If needed, describe pre-conditions that must be fulfilled prior to the flow of the use case. • Flow of the use case: a step-by-step description of what happens from the stakeholders point of view and what information flows happen. • [optional] Describe alternative flows, if needed. (but do not describe error cases!) • [optional] If needed, describe post-conditions that result from the flow(s). • “Potential requirements” from each use case must be collected. They should be written in the form of requirements (see next slide), but clearly tagged “potential”

4. Writing requirements • Write a requirement only if the standard needs to support it (for interoperability). Think: what requires global standards support and what can be product specific? • Requirements express service needs or operational needs of users, vertical industries, M2M service providers, operators, vendors... • Specify – sufficiently detailed – WHAT is needed, not HOW it is to be provided. • Requirements must be written to apply to the M2M System (or a specific part of it), not to stakeholders outside the M2M System (users, service providers.)