FIT2001 week 3: werewolves and pepsi
Thoughts
This week we started to really fill our Systems Analysis and Design tool kit, with an emphasis on tools needed for gathering requirements, which is pretty much all of the analysis phase! I liked the phrase “fact finding” as opposed to mushroom gathering when it comes to requirements. I also found it interesting that you might not need to talk to all the users in order to design a system, but it’s important so that they are validated and feel an important part of the process, and also to balance the different needs and ideas of the stakeholders.
Check you have the right requirements, then prioritise and resolve conflicts between different stakeholder requirements, build a prototype (don’t make it too good, or your pointy haired boss will think it will take a lot shorter to do the project!) look at alternatives, and review the analysis to see if we should continue to design and build this system.
The Business Process Re-engineering and Analysis (BPR) sounds like it has the potential to go nuts and make huge mistakes; but it is a good idea to look at how best to solve the problem with IT, not just implement the manual system with computers.
When I sat in the Clayton lecture I thought: “What is JAD?” and saw the slide with a JAD room. On listening to the Caulfield lecture I got a better idea of what it was: Joint Application Design Sessions, where you rent a special room off site to
- minimise distractions
- send a “this project is important” vibe
- send a “you are valuable to this project” vibe
and basically get stuff done quickly. It is good when you have conflicts to resolve and therefore it is good to have the decision makers there, ready to make decisions. The JAD session seems to me to be a corporate version of something like a Start Up Weekend where a group of people get together and hammer out a new product from scratch and hopefully launch it.
Some other key phrases this week:
- Functional Requirements: what the system has to do.
- Non-functional Requirements: how the system has to do it.
- Questionnaire: good for getting data from a lot of people (users, stakeholders)
- Interview: good for getting detailed information about the system.
- Open Items list: good for tracking issues and fixing them.
- prototype: original, primitive, from protos “first” + typos “impression”
(prototype from etymology online) - logical model: information based, like “invoice details”
- physical model: physical object based, like “the invoice”
- Activity Diagram
- Structured Walk through
Tutorial
I really enjoyed the video that we watched in the tutorial, but I quibble that it was a “podcast” as we didn’t subscribe to it. However It was good to talk about new technologies, like podcasts and twitter, and remind everyone that we need to keep up with the new technologies to help us impress our clients. I reckon it was good to talk about stuff like that at the Clayton campus which feels a bit dinosaurish when it comes to IT technology sometimes. The content of the podcast, even though it didn’t directly mention Systems Analysis and Design, was extremely relevant. People are not good at knowing what they want, and are good at making up stories, so we have to be careful when it comes to asking people for their requirements. It also made me sit up and listen when Gladwell talked about the sip test versus drinking a whole can of coke or pepsi, and the changing beauty perceptions of the aeron chair. Lesson for Systems Analysis and Design? Pay attention to what people really need, not what they say they need.
Weekly Quiz
I found the Open ended questions frustrating for my method of quiz taking. The close ended ones are easier for me to work out the right answers. Confusing why “mock up” was in there, I guess to throw us when the correct answer is “prototype”.
Observation on learning techniques
There is one key thing when it comes to learning: remembering. While understanding is also crucial, it doesn’t help if you understand something and then don’t remember it (It also helps you remember if you understand.) I bet you’ve all been reading this blog post looking for a reference to werewolves- well here it is: you can use the werewolf effect to help you remember things. Rather, it’s the Von Restorff effect, which says that you will remember something that sticks out to you, and you are also more likely to remember something that is close to the “werewolf”. (This term “werewolf effect” is one I first read in a book on Memory when I was in grade 5, and even helped me to remember the name “Von Restorff” to google for the relevant wikipedia link after all these years.) This is why I liked the video about the exploding whale (and the earlier one about counting the basketballs) because they should help me to remember the Systems Analysis stuff also.
Another way that we remember is by telling and remembering stories- I don’t think I will forget Peter’s “*boop* *boop*” example where the shop assistants were scanning each item twice with the barcode scanner, and then wondering why the system was charging everyone double at the end of the month. Lesson? Observation is very important.
The final point of the requirements gathering process is to check back with your client and make sure that you are both on the same page and understand what the system will be built like.
Thanks for the “blog of the week” award last week P O’Donnel, I hope including another Dilbert cartoon doesn’t look like an attempt to sway the judges! Hey, I can’t help it if they’re relevant to this material. 