SA re defined

From UG

Revision as of 02:49, 19 November 2010 (edit) Alex (Talk | contribs) (→Exemplary specs) ← Older edit		Revision as of 02:59, 19 November 2010 (edit) (undo) Alex (Talk | contribs) (→A) Newer edit →
Line 43:		Line 43:
	=== A ===		=== A ===
-	* link: [[Non Shipment billing component]]	+	* 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 1 To 2 Summary 3 Agreements 4 Exemplary specs 4.1 A

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