SA re defined
From UG
(Difference between revisions)
(→Exemplary specs) |
|||
(11 intermediate revisions not shown) | |||
Line 1: | Line 1: | ||
[[Category:PM (public)]] | [[Category:PM (public)]] | ||
- | == | + | == Audience == |
- | Systems Analysts | + | Systems Analysts, BAs |
== Summary == | == Summary == | ||
Line 14: | Line 14: | ||
:* point out on missing elements | :* point out on missing elements | ||
:* help them finalize Business Requirements | :* help them finalize Business Requirements | ||
+ | :* provide brief additional technical information required for developers | ||
* '''No ZUL''' | * '''No ZUL''' | ||
Line 24: | Line 25: | ||
* '''UI/functionality prototype''' | * '''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 | + | : a) Due to changes above UI and functionality can be presented for review AFTER it was coded on Demo server. We call this Fully Functional Prototypes. This is replacing a mechanism of demonstrating solution by 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 | + | : b) in some cases UI mock ups will be used. Examples: |
- | + | :: *in '''Design Ideas''' section; in pdf based proposals to Clients | |
+ | :: *if Proposal is required as a request to [[RFP]] | ||
* '''SA Notes''' | * '''SA Notes''' | ||
: Section "Detailed Design will be replaced" with "SA Notes" | : Section "Detailed Design will be replaced" with "SA Notes" | ||
Line 39: | Line 41: | ||
* '''Exemplary specs''' | * '''Exemplary specs''' | ||
: Create a list of specs that comply to the new standard. See [[#Exemplary specs]] | : Create a list of specs that comply to the new standard. See [[#Exemplary specs]] | ||
+ | |||
+ | * '''Impact on existing code''' | ||
+ | : SA should state in SA Notes section what impact will have proposed change on existing components if any (reports, etc) | ||
+ | |||
+ | == See also == | ||
+ | |||
+ | * [[RFP and 3CS specs]], [[White and black box design]], [[Proposals vs Fully Functional Prototypes]] | ||
== Exemplary specs == | == Exemplary specs == | ||
Line 44: | Line 53: | ||
=== Non Shipment billing component === | === Non Shipment billing component === | ||
* wiki: [[Non Shipment billing component]] | * wiki: [[Non Shipment billing component]] | ||
+ | * Module Owner (MO): Karen | ||
* Authors: Tracie (BA) and Alex (SA) | * Authors: Tracie (BA) and Alex (SA) | ||
* score: A+ | * score: A+ | ||
* comments: | * comments: | ||
- | ** Kostya: | + | ** Kostya: ''Carefully read this spec. I like it very much: it is short, clear and has everything that is required.'' |
=== Air Status EDI === | === Air Status EDI === | ||
* wiki: [[Air Status EDI]] | * wiki: [[Air Status EDI]] | ||
+ | * Module Owner (MO): Simon and Marc | ||
* Authors: Tracie (BA) and Alex (SA) | * Authors: Tracie (BA) and Alex (SA) | ||
* score: TBD | * score: TBD | ||
- | * comments: SA Notes section possibly too detailed. When do we pass this task to developer? What is the role of SA? Should he discuss XML design specifics with Descartes here or it is a developers job? | + | * comments: |
+ | ** '''Alex''': SA Notes section possibly too detailed. When do we pass this task to developer? What is the role of SA? Should he discuss XML design specifics with Descartes here or it is a developers job? | ||
=== CT Records Per Client Company (Web Portal) === | === CT Records Per Client Company (Web Portal) === | ||
* wiki: [[CT Records Per Client Company (Web Portal)]] | * wiki: [[CT Records Per Client Company (Web Portal)]] | ||
+ | * Module Owner (MO): Simon | ||
* Authors: Tracie (BA) and Alex (SA) | * Authors: Tracie (BA) and Alex (SA) | ||
* score: TBD | * score: TBD | ||
* comments: | * comments: | ||
+ | |||
+ | === Visibility Redesign === | ||
+ | * wiki: [[Visibility Redesign]] | ||
+ | * Module Owner (MO): Simon and Marc | ||
+ | * Authors: Alex (BA) and Alex (SA) | ||
+ | * score: TBD | ||
+ | * comments: | ||
+ | |||
+ | === KPIs for OpsTruck phase 1 === | ||
+ | * wiki: [[KPIs for OpsTruck phase 1]] | ||
+ | * Module Owner (MO): Simon, Marc, Bill (Arden) | ||
+ | * Authors: Alex (BA) and Alex (SA) | ||
+ | * score: TBD | ||
+ | * comments: | ||
+ | |||
+ | === Archive (Feature) === | ||
+ | see [[Archive (Feature)]] |
Current revision as of 16:32, 3 December 2010
Contents |
[edit] Audience
Systems Analysts, BAs
[edit] Summary
Dev Team expressed concerns to me about what SAs put into wiki spec. To address them we agreed to the following.
[edit] 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
- provide brief additional technical information required for developers
- 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. We call this Fully Functional Prototypes. This is replacing a mechanism of demonstrating solution by 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
- *if Proposal is required as a request to RFP
- 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
- Impact on existing code
- SA should state in SA Notes section what impact will have proposed change on existing components if any (reports, etc)
[edit] See also
[edit] Exemplary specs
[edit] Non Shipment billing component
- wiki: Non Shipment billing component
- Module Owner (MO): Karen
- Authors: Tracie (BA) and Alex (SA)
- score: A+
- comments:
- Kostya: Carefully read this spec. I like it very much: it is short, clear and has everything that is required.
[edit] Air Status EDI
- wiki: Air Status EDI
- Module Owner (MO): Simon and Marc
- Authors: Tracie (BA) and Alex (SA)
- score: TBD
- comments:
- Alex: SA Notes section possibly too detailed. When do we pass this task to developer? What is the role of SA? Should he discuss XML design specifics with Descartes here or it is a developers job?
[edit] CT Records Per Client Company (Web Portal)
- wiki: CT Records Per Client Company (Web Portal)
- Module Owner (MO): Simon
- Authors: Tracie (BA) and Alex (SA)
- score: TBD
- comments:
[edit] Visibility Redesign
- wiki: Visibility Redesign
- Module Owner (MO): Simon and Marc
- Authors: Alex (BA) and Alex (SA)
- score: TBD
- comments:
[edit] KPIs for OpsTruck phase 1
- wiki: KPIs for OpsTruck phase 1
- Module Owner (MO): Simon, Marc, Bill (Arden)
- Authors: Alex (BA) and Alex (SA)
- score: TBD
- comments: