TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Re: Anyone a Business System Analyst? From:puff -at- guild -dot- net To:techwr-l -at- lists -dot- raycomm -dot- com Date:Mon, 2 Oct 100 14:27:41 -0400 (EDT)
John Prince writes:
> I just accepted a new position as a Business System Analyst (BSA) -
> and I'm excited about it. It's a *little* different in what I'm
> doing now because I design the software (based on internal and
> customer feedback), make a prototype of it (in VB or JAVA,
> depending) and then write the functional spec for it. When that's
> complete, I hand over the prototype to the development team and they
> build the actual app. I feel it's a great fit for my skills, and I
> know I'm going to love doing this.
> I am curious if there are any other Tech Writers on here who hold
> that title or perform similar duties.
I've been called a systems analyst in the past; my current
business card lists my title as "Geek". :-). In my personal
experience the difference between an analyst and a programmer is
trivial-to-nonexistent, however I'm an odd breed of cat.
Specifically, my communications skills have been as important (or more
important) as my technology skills.
I've been in discussions in the past that drew more of a fine
line; in one conversation that included my boss, his boss, and a
coworker, the general consensus seemed to be that an analyst has to
have more focus on "why" and not just "what". An analyst has a
broader responsibility to check assumptions and figure out what should
be done, not just how to do it. Of course, that also fits my
definition of "programmer", not to mention "professional", but maybe
that's just me.