Systems Analysis book

[Firefly]

Can anyone recommend a good SA book on the market...one with a large amount of practical bits as opposed to just theory. Also, one focusing on dealing with 3rd party vendors.

Many thanks,

Firefly.

 

[aldark]

Firefly,
could be a bit of a tall order. First of all what do you want to know about system analysis -e.g a methodology or a how-to? Regarding dealing with 3rd parties, do you mean vendors who will be delivering a system based on your spec? Not sure if any sa book will be so broad in scope as to cover outsourcing.

Anyway, if you've never done any sa stuff before, all the methodologies do is
a) provide a common framework so you can communicate your work with others doing the same kind of thing
b) provide some simple error checks e.g. most of the stages in ssadm are based on verifying your initial work by making sure you havn't left out anything.

I would work out exactly what it is you need to know that common sense wouldn't already tell you!

BTW, most 3rd parties will work fairly closely with you on any build project ie you could build the project team - identify your subject matter experts, bring on the third party and chair the team as you identify the requirements before supervising the same team in qa.

 

[Firefly]

Thanks for that Aldark. To be more specific I would like to get a list of best practice tools to use to manage the project such as DFDs, ERD and the like and also common pitfalls that affect system integration when dealing with vendors. I have dealt with vendors myself on a few projects but in a narrow tecnical space but am looking for info on more general technical areas.

 

[aldark]

Firefly, you'll have to put a lot of that together from a couple of subject areas . Sounds like you really need to get a project management thing first though.

pick up any pm book and have a look at its description of the project stages - initiation, planning, implementation etc. there should also be some stuff on team/vendor management.

Mind you the first thing is to define the project - what is it that needs to be done so that its a success - who will know when its finished, how will you communicate that to your boss. Who's going to be paying for all of this and whats the link with you - is there a project "sponsor" or board ie. someone with organisational clout who can lean on any unwilling project participants!

For the sa stuff, you'll need to get the concept and have some kind of knowledge of its feasibility before you can even think of going to your 3rd party. If you're doing all this yourself, then you'll be the system analyst on the team - not a bad thing imo in smaller projects. You will need to be able to document your requirements so the fulfillment party can understand them. This can be surprisingly difficult and will need
a) some experience
b) some flexibility and lattitude in the fulfillment agreement
c) some knowledge of things like data flows, data definition etc. etc. pick your methodology and make sure 3rd party understands method and that you don't leave any i's undotted etc.

I would recommend some kind of initial stab of the data and procedural flow with some kind of prototyping mock up - making sure that your business expert is evaluating the prototype. The difficult thing here is ensuring completeness - has your business expert thought of all the cases the new system must handle - and qa - has your 3rd party done everything that's been spec'd.

Sounds like a lot of fun - you'll be wiser at the end of it!

 

[Firefly]

Firefly, you'll have to put a lot of that together from a couple of subject areas . Sounds like you really need to get a project management thing first though.

pick up any pm book and have a look at its description of the project stages - initiation, planning, implementation etc. there should also be some stuff on team/vendor management.

Mind you the first thing is to define the project - what is it that needs to be done so that its a success - who will know when its finished, how will you communicate that to your boss. Who's going to be paying for all of this and whats the link with you - is there a project "sponsor" or board ie. someone with organisational clout who can lean on any unwilling project participants!

For the sa stuff, you'll need to get the concept and have some kind of knowledge of its feasibility before you can even think of going to your 3rd party. If you're doing all this yourself, then you'll be the system analyst on the team - not a bad thing imo in smaller projects. You will need to be able to document your requirements so the fulfillment party can understand them. This can be surprisingly difficult and will need
a) some experience
b) some flexibility and lattitude in the fulfillment agreement
c) some knowledge of things like data flows, data definition etc. etc. pick your methodology and make sure 3rd party understands method and that you don't leave any i's undotted etc.

I would recommend some kind of initial stab of the data and procedural flow with some kind of prototyping mock up - making sure that your business expert is evaluating the prototype. The difficult thing here is ensuring completeness - has your business expert thought of all the cases the new system must handle - and qa - has your 3rd party done everything that's been spec'd.

Sounds like a lot of fun - you'll be wiser at the end of it!

Thanks a mil. Have an academic background in PM and but just interested in the technical aspects of putting systems together...what bits work well together. Thanks for all your help, again.

 

[aldark]

Ah! you mean the proper meaning of sa as in not business analysis - understood. This is also a complex area - tech has moved on a bit in this area - now its all frameworks e.g. .net or corba etc. However, technical analysis and feasibility is always mentioned in all the methodologies. Not much to add except that its highly dependent on the systems to be integrated. This is usually hugely expensive and is what was partly responsible for the rise of erp systems in the '90s - get rid of everything and put in our system which does everything anyway! Now what you have is a proprietory system with supposedly defined standards for modification and enhancement. These days everything has to be a "web service" which should also ease those integration blues.