Requirement vs. Presales

Being involve in the presales is not a work that i really enjoy and probably i still can''t catch the essence of presales of the preliminary activity for sales. Doing presales, one needs knowledge of the product or at least the domain knowledge on the business itself, it's also a story hook up time or if you like to call it - BS.


I have watched this movie called "Thank you for Smoking", in which i like the way the messages is being conveyed, famous line, "It is not a negotiation, it's an argument", there's lot of art of "negotiation" so to speak in this movie. Being in the dilemna having a job as the vice president of Academy of Tobacco, selling cigarrettes and knowing it is causing cancer, and having all the bad health results, however he has turning each argument to a winning cards, wow ....

Anyways, my point is being in presales is tough for me, a lot of softskills is needed, a lot of general knowledge is needed and a lot of integrity is needed, why integrity ? ha! I feel we should have certain honesty to the customer when a certain level of message is delivered, especially when you say, "Yes, it can be done for sure", or should be rephrase a little, "By having such condition, i'm sure it could be done"? Well i guess it's the art of how we convey messages, probably i should start looking into the speech methodolgy in this case huh.

Requirement vs. QA / Tester

What is QA? What is Tester? I was being asked to deliver test cases, UAT and perform integration tests on the system. The reason is , I was the BA, a SA and so the best candidate to make sure the developed system maps the requirement being designed accordingly.

eehmmm ... i have been struggling of what's been said above. It does make sense theoritically. The best way to test the system is to identify the possible scenarios from the business process and test the situation with the system. Then i thought, what could possibly happen on the scope of work for a BA?

After each requirement workshop or session, I will start preparing for documents like business processes, requirement list, business rules and sometime scenarios and most of the time these information is being verified by the customer themselves and then this information will start to translate into the use case specs or functional specs (i don't like to work on functional specs and i always think the more appropriate person to work in should be the solution architect) but anyways, during the analysis and translation process, i thought, there should have a certain level of QA be inplaced, to check on standards, logic, etc and it should be not be done by the BA/SA alone, simple reason behind, when oneself is too into a certain work, they are tendencies of overlooking other aspect and also some important details that may be needed during the development cycle and therefore a QA is needed in here.

Not sure if it's a good or bad situation to bring in QA during documentatations, which ended up spending more time explaining the situation to the QA why certain work is being done accordingly and most of all the expectation is rather different when they start asking after this screen, where the cancel button will be leading to ? ...... The idea was, to let the QA check on the flow and i mean the business flow and how this is carry into the system, but so detail until how eash screen flow would be, if i would want to look into such details then i could be the solution architect and start designing each button, or link actions? .... hmmm is there a QA for business processes then ?

What about testers? the conflict starts during the interation testing. A lot of time, the tester or it could be the programmer himself doing testing in the development environement, test goes out well, when it comes into integration test, it always got haywired, so now the question comes back, who should do integration testing? the tester? the BAs? ...

Requirement vs. Solution Architect

From most of the projects that i have involved, there's always conflict of interest between a BA, SA or a Solution Architect. A lot of times, there's thin line between each role and if the expectation is not being managed correctly, job responsibilities, the so called "ideal" solution architecture may varies, and i mean WAY different from what is captured from the business point of view.

HOWEVER, i enjoy working with them, in which people from different background see requirements in different angle, in which this can further empower how a requirement should be written and support with other necessary documents, i.e reports, chart,draft flows, etc. How bad could it go? Let's see the famous chart that portaying how requirement is being captured, "ASSUME" and documented below, which i think is really appropriate.


and of course, what customer really wants is:

I have learned something over the years, there's a couple of scenarios may occur when a requirement gathering, or analysis went too wrong:
1. A new feature evolve!!
2. A feature the customer will NEVER use!
3. A Bug that would never SOLVED! and the customer needs to work around it.

I also learn to accept and "negotiate" for what the idea and concept is presented. A lot of times, I will try to iterate the requirements by draft out the high level screen flows (Which may not be same like what SA will draw), but just to keep a common understanding between the team members, and the customer ... and how the document should be written (hey i won't want to write something that we can't even deliver!). So then i found some hot approaches are pretty useful, i.e RUP!

note: i know the artifacts are crazy! and time always the issue in SDLC!