Component X (Business Purpose and Use Cases)
From UG
(Difference between revisions)
| (12 intermediate revisions not shown) | |||
| Line 1: | Line 1: | ||
[[Category:Spec Templates]] | [[Category:Spec Templates]] | ||
| + | [[Category:Business Analysis]] | ||
| + | [[Category:Documentation]] | ||
| + | |||
== About this document == | == About this document == | ||
| - | ''Purpose | + | '''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 | + | '''Completeness and scope.''' It should have enough details for [[Design Team]] to complete its work with minimal additional input. 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.'' | ||
| - | + | '''Sections.''' In general this document should have several sections - see below. | |
| - | + | === Component's Business Purpose === | |
| - | + | This section helps to define the purpuse of this CT2 component for the business workflow, what existing [[business needs]] / user [[needs]] this component is addresing. Or what new idea and as a result new [[business needs]] it is creating. This should not define any details. It is very important to understand what are we trying to acomplish with this component / feature and what we are not. Sometimes of course it is obvious. But in many cases users have different ideas about this. That is why it should be clearly defined. 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.'' | |
| + | |||
| + | ::''[[ICom]] - we never defined purpose clearly and I am afraid many end users now do not understand the difference between [[EQuery]] and [[ICom]].'' | ||
| + | |||
| + | === Use Cases and Functionality Requirements === | ||
| + | |||
| + | 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 1: Send EQuery." | ||
| Line 20: | Line 29: | ||
::''Use Case 3: Edit EQuery." | ::''Use Case 3: Edit EQuery." | ||
::''Use Case 4: Delete EQuery." | ::''Use Case 4: Delete EQuery." | ||
| + | |||
| + | === User Interface requirements === | ||
| + | |||
| + | === Integration Requirements === | ||
| + | |||
| + | === Other Requirements === | ||
| + | |||
| + | == Challenges == | ||
| + | |||
| + | Where is the dividing line between Analysis and Design? Therefore where is the dividing line between Analysis wiki and Design wiki? | ||
| + | |||
| + | == See Also == | ||
| + | * http://en.wikipedia.org/wiki/Requirement | ||
Current revision as of 01:05, 8 February 2010
Contents |
[edit] 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 with minimal additional input. 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.
Sections. In general this document should have several sections - see below.
[edit] Component's Business Purpose
This section helps to define the purpuse of this CT2 component for the business workflow, what existing business needs / user needs this component is addresing. Or what new idea and as a result new business needs it is creating. This should not define any details. It is very important to understand what are we trying to acomplish with this component / feature and what we are not. Sometimes of course it is obvious. But in many cases users have different ideas about this. That is why it should be clearly defined. 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.
[edit] Use Cases and Functionality Requirements
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."
[edit] User Interface requirements
[edit] Integration Requirements
[edit] Other Requirements
[edit] Challenges
Where is the dividing line between Analysis and Design? Therefore where is the dividing line between Analysis wiki and Design wiki?
