I want to know all About System Analysis and Design.?

Question

a.)Some systems analysts maintain that source documents are unnecessary. They say that an input can be entered directly into the system, without wasting time in an intermediate step.
Do you agree? Can you think of any situations where source documents are essential?


b.)Some systems analysts argue," Give users what they ask for. If they want lots of reports and reams of data, then that is what you should provide. Otherwise, they will feel that you are trying to tell them how to do their jobs. "Others say, "Systems analysts should let users know what information can be obtained from the system. If you listen to users, you'll never get anywhere, because they really don't know what they want and don't understand information systems." What do you think of these arguments?

Answer 1

a) Source documents are necessary if the person entering the data does not have direct access to the data, or is uncomfortable using the system, or the data needs to be checked over before inputting it into the system.

IMO, that's pretty much it. Those are the situations where source documents are warranted. Otherwise, it's much easier, for both the designer and the end user, if data goes directly into the system. Any supplemental documents can then be easily exported from the system.

b) The correct answer is, "both."

The user should never be ignored. They are the ones that know how they work. They are the ones that know what the system needs to do (ideally, although in my experience, they rarely do, although they can be trained - if you consistently ask them the same types of questions, they learn what types of questions they need to be able to answer). They are the ones that know how comfortable they are with different ways of doing things.

OTOH... you are the one who knows the potential for the system. You are the one who knows what the most efficient way of doing things is. You are the one who knows the eventual consequences for bad design decisions.

The solution is... communication. Lots and lots of communication, where you listen carefully to what the user has to say, translate it into design terms, explain to the user, in design terms (I find ER diagrams drawn up on the fly helps if you're actually sitting down in a meeting with them), just what you understand... and then start giving them ideas for what else the system might be able to do for them. In the end, what the user says, goes.

The exception to the rule is when the user gives you instruction for exactly how they want the underlying tables designed... and the tables are very badly designed (with social security number as the primary key in a system where the SSN isn't always known, for example). This calls for much more communication. Find out why they want the tables designed that way. Explain all the reasons why it's a bad idea. Then explain how their needs can be met when using a real primary key. Explain how, if the system is designed this way, it will cause much slowness and programming headaches down the line, and will cost them lots and lots and lots of money. Then, again, leave the final decision up to them.