SA re defined part 2
From UG
(Difference between revisions)
(→About) |
(→About) |
||
Line 3: | Line 3: | ||
This is a continuation of an effort to streamline SA work. Fist article is here: [[SA re defined]] | 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 | + | Based on negative feedback from Dev Manager about a number of recent spec I announce 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: |
Revision as of 00:06, 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 announce 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 and major tweaks (after BA and SA sections are completed)
- must post Architect comments into "Architect Review" section
- 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
- I introduce Implementation Summary section
- needed since "Systems Analysis" section will not provide exact solution, just direction in many cases
- 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: