Exercise:
Create a set of use cases for the following system:
OTMC is an innovative young firm that sells memberships to people who have an interest in certain products. People pay membership fees for 1 year and each month receive a product by mail. For example, OTMC has a coffee‐of‐the‐month club that sends members one pound of special coffee each month. OTMC currently has six memberships (coffee, wine, beer, cigars, flowers, and computer games), each of which costs a different amount.
Customers usually belong to just one, but some belong to two or more. When people join OTMC, the telephone operator records the name, mailing address, phone number, e‐mail address, credit card information, start date, and membership service(s) (e.g., coffee). Some customers request a double or triple membership (e.g., 2 pounds of coffee, three cases of beer).
The computer game membership operates a bit differently from the others. In this case, the member must also select the type of game (action, arcade, fantasy/science fiction, educational, etc.) and age level. OTMC is planning to greatly expand the number of memberships it offers (e.g., video games, movies, toys, cheese, fruit, vegetables), so the system needs to accommodate this future expansion. OTMC is also planning to offer 3‐month and 6‐month memberships.
Draw a level 0 DFD for the OTMC system described above
I have created the use case diagrams
I am not sure how to create DFD Level 0 diagram. So far, I have figured out that processes are shown in rectangle - Member Registration", "Product Shipment", "Membership Management"
Please help to create DFD Level 0 diagram.
Preliminary remark: UML or not UML?
This is a strange exercise: use-case and class-diagrams are UML. But DFD is not UML and somewhat obsolete compared to UML's rich and standardise behavioural modelling such as activity diagrams. High time that your teacher modernises the exercises!
What does the DFD standard say?
Well, there is no authoritative DFD standard. For example, the DFD notation, does not necessary use rectangles for processes as you seem to think: there exist several variants of the notation: The most common are Gane&Sarson with rounded rectangles for processes, and Yourdon/DeMarco with circles for processes.
A common modelling practice that emerged over time was to use context diagrams. The aim is to show the big picture:
the whole system (rounded rectangle or circle, depending on the notation) in its external environment ("context"), which is made of :
the DFD "entities" that generally correspond to the actors of a use-case diagram. (Here you'd have the telephone operator (it is not clear if customers also operate the system or receive some information from the system.)
Aggregated data flows from/to these entities and the system. (e.g. one for new member data, and one for subscription, probably also those that you already have identified).
What is the DFD level 0?
DFD modelling belongs to the structured analysis techniques. The principle shared by all authors (Gane&Sarson, DeMarco and others) is a top-down analysis that starts at the top level, and level by level, provides for each item at level n, a diagram that decomposes it further with details at level n+1.
However, there is an ambiguity regarding the level 0. Some practitioners start at the context diagram (e.g. SADT modelling uses a level 0 summary diagram, other authors make a distinction between level zero and level 0), whereas others start one level below, with the main processes of the system. Gane&Sarson for example don't use "level 0" terminology but use "top level" which seems less ambiguous. DeMarco introduced the level numbering and started at 0 for the top level, because he used a consistent decimal numbering for all the processes in a model, and the level indicate the length of the prefix (level 0: 1, 2, 3, level 1: 1.1, 1.2, 2.1, 2.2, etc...). Here you have to look at what your teacher uses as a practice. If it is at top level below the context diagram, I'd see the subscription, and the monthly shipments, and I'd leave all the other details for further levels.
Some more thoughts about UML
UML would be better suited than DFD, because it supports object flows, which facilitates modelling generic processes, but use specialisation (e.g. by product category where each subscription category could need different attributes, see example of video-games) to let the system evolve without resigning everything, according to the open-close principle.
Your UML use-case is by the way much too complicated. Each use-case should correspond to an actor goal. Moreover it should not be misused to show the process: there should be no required ordering between different use-cases.