SA re defined part 2

From UG

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:

• 0002525 PI redesign