Talk:Software analyst

This description was not written by a software analyst, BTW, it was 

written by someone who obviously couldn't boil down the details of the skills that make them what they are..

I think it would be better to elaborate on these skills as the first two are the same skill.. Knowing software technology and knowing computer programming, is the same thing..

Now if knowing "software" is the first, and the last is knowing "how to program", those are distinct skills..

What a software analyst does is translate a needs into solutions, and those solutions either map to existing "shelf" software or map to custom solutions. If you are a good software analyst, you will know to pick your battles. It's a question of ethics, whether you demand the client buy into a custom solution, or whether the solution use existing software, as the "shelf solution" may not rack in so much money into the project.

The major problem with most projects is the client comes in with a solution that is too large and complex, and assumes that there is some shelf solution that does that, and it's the software analysts job to extract the core need from the client, that addresses the problem accurately, as the solution should match the demands of the need, not of the want or all encapsulating desires of the client.. Best to let the client dream up a solution, then to ask them again "what do you need".. And the client is forced to boil it down.. Then to ask "what to do you absolutely need", then the client to boil it down even more.. The software analyst has to intent on finding and addressing the need and ruling out any false expectations, detailing assumptions, and negotiating a solution..

And if you need to simplify what a software analyst process is like.. It is this: Play a game with the client.. Role playing..

1. I'm a user of this solution, I come in the door, or onto your web page.. What do I see?

 Then the client responds..

2. Then you ask, Why that?

 Then the client specifies the need in detail for this feature, or 
 recognizes a flaw in their expectations.. 

3. Then you ask, okay so you want to do this?

 Then the client realizes that you speak a different language, from a different 
 culture, and is forced to boil down their expectations and assumptions into 
 something a baby could understand.. 

4. Then you write down better, that need in details you or anyone could understand.

5. Then what does the user do now?

6. Goto to #2 .

7. You do this "ad infinitum" until the need is mapped out.

8. Go through the roughed blue print of the process, with a programmer or if you can afford it a program designer, weeding out unneeded details, then creating a list of scenerios that more aptly should address the need and confronting the client with these.. Then permitting the client to say "wow, yes that better solves that problem" or "no, let me explain."

9. Assess the needs again, boil it down with a programmer, and if needed do #8 again.

10. Get everyone to sign off on this blue print as "the facts".. And churn out the implementation.

What goes on elsewhere is a matter of the your companies tastes in how to conduct business. You may just present the grand solution, or if you are smart, present an initial rough of the solution.. To allow the client to clear up problems before the concrete sets.

Then to do several more phases of the implementation in this way..

It is even possible that one could implement "pilots" or "proof of concepts" or whatever would allow the client to play with the solution interactively..

But comical idea of what a software analyst does is: suck the clients minds out through their sensory organs, until the intrals of the need are laying on the ground between you. And then you stomp on it, cut it up, and compress it, sew it up, and add some lightning and magic, and soon it's walking around like Frankenstein's monster.

Note, I actually had a friend who took the job title for this as a "design nosferatu".

---

I hate lists of skills, this is how I'd elaborate on them, please feel free to elaborate on my elaborations:

• Working knowledge of software technology (eg. existing applications)
• Computer programming experience and expertise

  know the language and culture of programming

• General business knowledge

  know the language and culture of business

• Problem solving skills

  flow charting, role playing, other techniques

• Interpersonal relation skills

  ability to know ones limitations, interact with others in ways that are productive

• Be flexible and adaptable

  Don't be set on a solution before understanding the need, adapt to the need and be willing to understand it. But flexibility and adaptability is a two way road.. Lack of flexibility from 

either or both ends, or any end, will just make things harder..In some cases, it's best just to back down from the client if they are inflexible.. But software analysis is not something one does at the submission of the client, it is something one does with the client. It's better if the software analyst is involved in the process of psycho analyzing the client and determining if "we should even address this clients need, or back down and present an ultimateum".

It takes courage to push the client, then when one backs down, they at least have the satisfaction of knowing the problem couldn't be addressed.. —Preceding unsigned comment added by 68.35.150.60 (talk) 19:19, 19 June 2008 (UTC)