1. oneM2M-REQ-2012-0012R03 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. oneM2M-REQ-2012-0012R03 This document is informative only 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 when work in oneM2M is just starting. Other useful documents: – http://www.reqexperts.com/media/papers/writing_good_requirements.htm http://www.reqexperts.com/media/papers/writing_good_requirements.htm – http://www.etsi.org/WebSite/document/Legal/ETSI%20Drafting%20Rules%20January% 202012.pdf http://www.etsi.org/WebSite/document/Legal/ETSI%20Drafting%20Rules%20January% 202012.pdf

3. oneM2M-REQ-2012-0012R03 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. – Pre-conditions (only if the flow of the use case requires that they are fulfilled). – Flow of the use case: a step-by-step description of what happens from the stakeholders point of view and what information flows happen. – Alternative flows, if the flow foresees alternative outcomes. (Do not describe error cases!) “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. oneM2M-REQ-2012-0012R03 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? – if a M2M system could still comfortably work as intended without the required functionality then don’t write the requirement. 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. Write positive requirements wherever possible (i.e. what shall be supported - rather than what shall be avoided) 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.) Note: the usage of verbs (SHALL, SHOULD, MAY, …) is expected to be specified in a dedicated document on Drafting Rules by oneM2M SC.