SA re defined part 2
From UG
(Difference between revisions)
(→About) |
(→About) |
||
Line 11: | Line 11: | ||
* We need to continue to improve BAs work: | * We need to continue to improve BAs work: | ||
- | ** train BAs to bring their skills to acceptable level | + | ** continue to train BAs to bring their skills and experience to acceptable level |
- | + | ||
** skills that are critical for BA role: writing, analytical thinking, interviewing | ** skills that are critical for BA role: writing, analytical thinking, interviewing | ||
+ | ** BA should provide as detailed info as possible about problems/needs including background info, existing workflows, etc | ||
** SA must help BA to finalize her section. This means potentially re-writing it or writing it together. | ** SA must help BA to finalize her section. This means potentially re-writing it or writing it together. | ||
** SA should avoid repeating info that was already presented in BA section | ** SA should avoid repeating info that was already presented in BA section |
Revision as of 00:00, 13 December 2010
About
This is a continuation of an effort to streamline SA work. Fist article is here: SA re defined
Based on negative feedback from Dev Manager about a number of recent spec I propose the following changes:
- We need to bring Systems Analysis on a new professional level. It is a critical activity and must be done by a professional with appropriate level of technical training, experience and proven abilities
- core skills: excellent technical skills (details TBD), excellent communication skills, excellent documentation skills (Systems Analysis section and Proposal)
- existing staff must be re-trained or/and new staff must be hired
- For now: Alex will do SA for Project type tasks; all other tasks (tweaks) can be forwarded to Andrei for SA
- We need to continue to improve BAs work:
- continue to train BAs to bring their skills and experience to acceptable level
- skills that are critical for BA role: writing, analytical thinking, interviewing
- BA should provide as detailed info as possible about problems/needs including background info, existing workflows, etc
- SA must help BA to finalize her section. This means potentially re-writing it or writing it together.
- SA should avoid repeating info that was already presented in BA section
- Role of Architect to be introduced who must review all Project type specs (BA and SA sections) and major tweaks.
- He must post Architect comments into "Architect Review" section (ideally) and mantis
- If Architect rejects solution then it must be returned to SA (not BA)
- If solution is accepted then developer must be assigned and task forwarded for estimation
- Spec will have the following structure:
1 Info 2 Business Analysis 2.1 Requirements 2.2 Possible solutions 2.3 RFP 3 Systems Analysis 4 Architect Review 5 Implementation Summary 6 QA Plan 7 History
- Since "Systems Analysis" section will not provide exact solution I introduce Implementation Summary section.
- To be completed by Developer. Goal: provide enough info so that QA and UAT know how to verify solution.
Examples
Below are examples of spec that were built with new principles in mind: