Component X (Business Purpose and Use Cases)
From UG
(Difference between revisions)
(→About this document) |
(→About this document) |
||
Line 2: | Line 2: | ||
== About this document == | == About this document == | ||
- | ''Purpose:'' This document defines given CT2 component from the business prospective. It is completed by [[Analysis Team]] and serves as a [http://en.wikipedia.org/wiki/Blueprint blueprint] for [[Design Team]]. | + | '''Purpose:''' This document defines given CT2 component from the business prospective. It is completed by [[Analysis Team]] and serves as a [http://en.wikipedia.org/wiki/Blueprint blueprint] for [[Design Team]]. |
- | ''Completeness and scope:'' It should have enough details for [[Design Team]] to complete its work. | + | '''Completeness and scope:''' It should have enough details for [[Design Team]] to complete its work. But it should not have too many implementation details because this would limit choices and as a result better design might not be considered (better in terms of time it takes to implement or usability). See example below. |
::'' CT2 has 3 similar in functionality components: ICom, Com, Query. If Analysis Team did not originally mandate that they are absolutely different then [[Design Team]] might have combine then and this would result in significant savings in terms of programming, testing and support man-hours.'' | ::'' CT2 has 3 similar in functionality components: ICom, Com, Query. If Analysis Team did not originally mandate that they are absolutely different then [[Design Team]] might have combine then and this would result in significant savings in terms of programming, testing and support man-hours.'' |
Revision as of 22:55, 6 February 2010
About this document
Purpose: This document defines given CT2 component from the business prospective. It is completed by Analysis Team and serves as a blueprint for Design Team.
Completeness and scope: It should have enough details for Design Team to complete its work. But it should not have too many implementation details because this would limit choices and as a result better design might not be considered (better in terms of time it takes to implement or usability). See example below.
- CT2 has 3 similar in functionality components: ICom, Com, Query. If Analysis Team did not originally mandate that they are absolutely different then Design Team might have combine then and this would result in significant savings in terms of programming, testing and support man-hours.
- CT2 component's Business Purpose - what is the purpuse of this CT2 component for the business workflow, what business needs this component is addresing. See example below.
- EQuery component's main purpose is to provide a quick way for jaguar user to ask question Operator of last change about particular CT record. This works best when user has this record open because with one click of a mouse she can reach EQuery tab and start typing her question. It takes just another click ('Submit' button) to send request.
- Additional purpose / benefit is that all questions are being logged and always displayed on the EQuery tab.
- Use Cases - each use case is one type of end user's workflow that involves this component. It could be expressed in one sentence or expressed as a sequence of steps. See examples below.
- Use Case 1: Send EQuery."
- Use Case 2: Send EQuery and copy to another user."
- Use Case 3: Edit EQuery."
- Use Case 4: Delete EQuery."