OU blog

Personal Blogs

Sebastian Tyrrell

M883 TMA01 Q2 ...

Visible to anyone in the world

I got a pertinent question on this so am sharing the answer more widely: if you have already submitted and as a result of this post you are having doubts do contact me - you can resubmit.

Q2s are quite tricky! In all the TMAs they will relate to the sort of process that you might go through in a real project, so the answers need to hang together (the collaborative sections, the Q3s, will "slot in" to this process as well).

The "investigation" you are being asked to perform here is in effect this process, the target of the investigation is the website project and the overall goal of your answer is to define the blastoff phase (for TMA01à of the project.

Hope this helps

Permalink Add your comment
Share post
Sebastian Tyrrell

Link to post on fit criteria

Visible to anyone in the world
Edited by Sebastian Tyrrell, Wednesday, 4 May 2011, 17:28
I have just posted some musings on the subject of fit criteria at my own blog, http://needsmust.wordpress.com/2011/05/04/fit-for-purpose/. Hope you find them useful.
Permalink
Share post
Sebastian Tyrrell

Coming up to TMA 02.

Visible to anyone in the world

Happy New Year all!

This blog is aimed at students on the current (2010K) presentation of M883 but comments and questions are welcome from anyone.

TMA02 is approaching fast, and I am happy to see there is a good deal of activity in the wiki groups. It is only natural that you are thinking of the collaboration first, but I would urge you to think a little about Question 2 before you rush off to think about your functional requirements in Q3: Q2 gives you valuable context, it is where you develop the mental maps that will lead you to the functional requirements.

In all the TMAs, but maybe most importantly in this one because we are now at the very core of the course, questions 2 and 3 lead you through a part of the requirements' analysis process: here setting the context, finding the business events, developing the business use cases into product use cases and on to functional requirements and then refining that list within the collaborative groups.

If you follow the process you will find that functional requirements flow quite naturally from the business events in which your particular actor is involved. Trying to do it backwards is much more difficult!

Of course, there is an important caveat: this is not a reason for failing to meet the deadlines you have all agreed for yourselves.

It does however provide a natural path for your learning in this area, and will make the TMA seem a little easier!

 

 

Permalink Add your comment
Share post
Sebastian Tyrrell

Some notes on DFDs

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

 

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: 75040