SA re defined part 2
From UG
(Difference between revisions)
(→About) |
(→About) |
||
Line 5: | Line 5: | ||
Based on negative feedback from Dev Manager about a number of recent spec I propose the following changes: | Based on negative feedback from Dev Manager about a number of recent spec I propose the following changes: | ||
- | * Alex will do SA for [[Project]] type tasks | + | * 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 |
- | ** He | + | ** 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: | ||
+ | ** train BAs to bring their skills to acceptable level | ||
+ | ** BA should provide as detailed info as possible about problems/needs including background info, existing workflows, etc | ||
+ | ** skills that are critical for BA role: writing, analytical thinking, interviewing | ||
+ | ** 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: | * Spec will have the following structure: | ||
Line 22: | Line 35: | ||
7 History | 7 History | ||
- | * Since "Systems Analysis" section will not provide exact solution | + | * 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 == | == Examples == |
Revision as of 23:58, 12 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:
- train BAs to bring their skills to acceptable level
- BA should provide as detailed info as possible about problems/needs including background info, existing workflows, etc
- skills that are critical for BA role: writing, analytical thinking, interviewing
- 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: