OU blog

Personal Blogs

Sebastian Tyrrell

A little more for M883 students on DFDs.

Wednesday, 1 Dec 2010, 19:29
Visible to anyone in the world

It appears that the Q1(b) does not, in fact, include labels on its data flows.

It is probably not how I would have done it but here is the rationale as I would see it:

Flows to and from well-named data stores could be regarded as implicit (the flow from a "flight details" can only be flight details). Similarly the author seems to have assumed that it is obvious what data the customer is providing though this is arguably a dangerous assumption! They may have decided that labelling made the diagram less readable.

Obviously you won't lose marks for a diagram that is consistent with the one provided though clearly the flows must be clear - a store labelled "Database" with an anonymous flow for example would be marked down both on poor naming of stores and lack of detail on the flow.

Apologies for the confusion.

Tags: dfd, m883, requirements
Permalink
Share post
Sebastian Tyrrell

Some notes on DFDs

Tuesday, 30 Nov 2010, 11:42
Visible to anyone in the world

I've had a couple of questions about DFDs, and this part of Q1 is often a stumbling block so I thought I'd just give you a few pointers.

The key point with DFDs is they are formal documents, and as such they have a formal structure and need to be complete and consistent. I don't have the case study or TMA script available at the moment, so I can only comment in a very general way.

  1. make sure you include all appropriate data flows, both into and out of the processes. You will also need to think about what other data you need to be able to select an appropriate itinerary. All data flows should be specific, labelled and consistent with the data store they go to or come from.
  2. You could start with what is called a "level 0" dfd for your own benefit: a single process and think about what information the customer must provide and what result they should get back. Then develop it to think about what data the system needs to store and add those flows to and from data stores. Then you go to the next level (level 1 dfd, which is effectively what you are looking for here) and break the process down to its next level constituent parts.
  3. The general problems I see on this question are:
    • incomplete and poorly labelled data flows and inappropriately (usually vaguely) named data stores inconsistent with the data flows.
    • Not answering the question, which is usually on a very specific change to the existing diagram: concentrate exclusively on that change and answer that part completely. If in doubt about the scope then state your assumptions (that is actually general advice for all questions!).
    • Poor naming of processes, not clear what is intended (your processes have good names - clear, concise and precise - though without better data flows it is difficult to gauge how appropriate they are).

Hope this helps: you can find some more general information at the links below. .

http://openlearn.open.ac.uk/mod/oucontent/view.php?id=397581&section=4.1

http://learn.open.ac.uk/file.php/6968/%21via/resourcepage/63775995/6968/moddata/resourcepage/Some_important_course_concepts_2.pdf

 

Tags: volere, software, development, m883, requirements, dfd
Permalink Add your comment
Share post

This blog might contain posts that are only visible to logged-in users, or where only logged-in users can comment. If you have an account on the system, please log in for full access.

Total visits to this blog: 75001