| lol, re: Systems Analysis. I thought that class was easy. Even TA'd the next semester (yes, as an undergrad!) I really can't think of a more important class when it comes to applied CS or CIS. If you're working on a system and haven't done an analysis, then you should first step back and perform the analysis.
I really think that that is what distinguishes me from what 99% of others do. Others build what the client asks for and never understand the client's system(s). This results in a program which doesn't facilitate business process, but, instead, requires business processes to be adjusted to facilitate the program. I tell my clients, "right now I don't know anything about your business, but by the time I'm finished I'll know more about your business than most employees -- otherwise, I haven't done what you've paid me for." I don't have many clients, but those I do are faithful, recommend friends as clients and I have zero complaints (except for a few personality issues being the nerd that I am, but absolutely no complaints for my work). I honestly feel that without systems analysis, one should not do anything but elementary work for a client. Don't believe me? Try it just once. You'll find that your work takes a bit longer, brings in more money, and, very importantly, the client is infinitely more satisfied at the end of the process than if you just did what they asked you to.
Clients don't have a clue what they want from a program. That's not their job; it's yours. Clients only know how their business works and try to best explain it for a program. Your job should be to understand their business sufficiently well enough to be able to suggest a program which decreases their work, enhances their life, and works within their current business processes (unless a modification to the process is warranted, in which case you help their overall business whether or not they go with you, but you leave an irrepressible impression of superiority over the "average" programmer.) |