symposia

This week, I’ll reflect on the topics that I’ve looked during Week 3 of this subject. In these weeks, we looked at the topic of Requirements Gathering (or in some circles, Requirements Re-engineering…which I think is a little excessive, but I’ll spare you from the opinion rant).

I’ll try and make shorter than the last!

System requirements gathering should preference quantitative methods and values over qualitative simply because they much more easily measured and compared. It is also easier to develop information systems if there are clear objectives available as opposed to esoteric and generalised ones. However, it’s important not to get lost in the development of the system as it can be easy to lose focus on the system’s main user – the client. Therefore, it’s important to maintain a ‘users point of view’ when developing the system.

However, some personal opinion here – you’d need to be extremely mindful of the technical aptitude of the client. Some clients will feel belittled if you abstract the information too much. On the other hand, some will be bewildered at the slightest mention of technical language. I would say it becomes a matter of getting to know who you’re talking to.

The idea of requirements gathering centres on the ability to communicate effectively with the client. This is often in the form of an interview. Analysts need to be able to ask questions of the client which draw out the answers that they need, as clients are often unsure of the information one may need to develop a system. This means that questions should start off being quite general and become more and more specific as the client introduces information. To this end, an analyst could not expect to ‘stick to a script’ of pre-defined questions to a tee (but they should have to ensure they have the intended basics covered). Questions can, and will, need to be constructed on the fly based on the client’s responses to the pre-defined questions.

Sometimes the client can get it wrong, as all humans do when under pressure – and there is plenty of it in a one on one consultation with a (relatively) unknown party, so it is important to ensure that the gathered requirements are feasible and accurate.

In the tutorial group, we were given an activity to do in regards to this – to listen to a pre-recorded interview and create another interview based on this. This was a good exercise, and I found it to be beneficial in terms of practice. However, I’m a concerned that the exact requirements for the activity weren’t spelled out clearly (that is, I wasn’t sure whether I had to create an entirely NEW interview or find gaps in the existing one. The details of the organisation we were ‘mock’ interviewing weren’t made clear either.

From this blog entry onwards, I will be writing after the end of the following week (that is, Week 5 for week 3). I feel this is fair given that we are to reflect on the tutorial activities too, as these do not occur until the next week.