SA re defined
From UG
(Difference between revisions)
(→Exemplary specs) |
(→A) |
||
Line 43: | Line 43: | ||
=== A === | === A === | ||
- | * | + | * wiki: [[Non Shipment billing component]] |
+ | * Authors: Tracie (BA) and Alex (SA) | ||
* status: candidate | * status: candidate | ||
* score: TBD | * score: TBD | ||
* comments: none | * comments: none |
Revision as of 02:59, 19 November 2010
Contents |
To
Systems Analysts
Summary
Dev Team expressed concerns to me about what SAs put into wiki spec. To address them we agreed to the following.
Agreements
- Main role of SA
- It is in most cases to:
- receive and review Business Requirements from BA,
- point out on missing elements
- help them finalize Business Requirements
- No ZUL
- No zul code should be created by SA. Reasons:
- a) time consuming;
- b) UIs should be created by developers
- No mock-up
- Same reasons as above
- UI/functionality prototype
- a) Due to changes above UI and functionality can be presented for review AFTER it was coded on Demo server. This is replacing a mechanism of creating/presenting UI mock ups.
- b) in some cases UI mock ups will be used. Examples: in Design Ideas section; in pdf based proposals to Clients
- SA Notes
- Section "Detailed Design will be replaced" with "SA Notes"
- Related specs must be linked
- Keep it simple
- First things first
- Explain most important things first... then stop. If you have more time say more.
- Exemplary specs
- Create a list of specs that comply to the new standard. See #Exemplary specs
Exemplary specs
A
- wiki: Non Shipment billing component
- Authors: Tracie (BA) and Alex (SA)
- status: candidate
- score: TBD
- comments: none