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: | ||
| - | * We need to bring Systems Analysis on a new professional level | + | * 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]]) | ** 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 | ** existing staff must be re-trained or/and new staff must be hired | ||
| Line 17: | Line 18: | ||
** SA should avoid repeating info that was already presented in BA section | ** SA should avoid repeating info that was already presented in BA section | ||
| - | * Role of Architect to be introduced | + | * Role of Architect to be introduced: |
| - | ** | + | ** must review all [[Project]] type specs (BA and SA sections) and major tweaks. |
| + | ** 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 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 | ** If solution is accepted then developer must be assigned and task forwarded for estimation | ||
Revision as of 00:01, 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:
- must review all Project type specs (BA and SA sections) and major tweaks.
- 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:
