Difference between revisions of "Rich Picture"
(Typographic fix-up) |
(→Used In) |
||
(17 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | + | == What == | |
− | + | [[Image:Rich Picture.png|200px|thumb|left|Rich Picture]] | |
− | [[Image: | + | |
− | == | + | Rich Picture - drawn in cooperation with the customer showing the environment in which the system-to-be should operate. |
+ | |||
+ | == How == | ||
+ | |||
+ | '''The dish''' | ||
+ | |||
+ | ''Rich Picture'' | ||
− | |||
'''Ingredients''' | '''Ingredients''' | ||
− | + | * Meeting with the customer | |
− | + | * Information about the customer | |
− | + | * Information about the IT system-to-be | |
'''Process''' | '''Process''' | ||
Line 19: | Line 23: | ||
Prepare yourself by reading all material already given by the customer and seek related information on the Internet and other places where relevant information is available. Relevant information can be: | Prepare yourself by reading all material already given by the customer and seek related information on the Internet and other places where relevant information is available. Relevant information can be: | ||
− | + | * Information about the customer: | |
− | + | ** general information about the company | |
− | + | ** products | |
− | + | ** line of business, etc. | |
− | + | * Specific knowledge about the type of IT system in which you are going to be involved: | |
− | + | ** controlling systems | |
− | + | ** monitoring systems | |
− | + | ** administrative systems, etc. | |
− | + | * Information about other suppliers to the company, etc. | |
− | Spend the first minutes at the meeting with the obligatory general small talk. | + | Spend the first minutes at the meeting with the obligatory general small talk. Then, you should start asking questions about the environment which the IT system-to-be will be part of. During your conversation with the customer, you should draw a simple sketch simultaneously using symbols - pictograms - that illustrate the environment of the IT system. |
− | After the meeting make a new sketch on a sheet of white paper eliminating the "noise" introduced during the talks. Scan the sketch and include it as part of | + | After the meeting, make a new sketch on a sheet of white paper eliminating the "noise" introduced during the talks. Scan the sketch and include it as part of your documentation. |
− | There may | + | There may be a need for several meetings with the customer. If so, remember to bring along your rich pictures and use them continuously at the meetings. |
'''In Details''' | '''In Details''' | ||
− | + | Use simple pictograms (simple drawings of the item in question) to illustrate the environment. It is unnecessary and time-consuming to draw on a computer. Often, the time used to draw a sketch on the computer is wasted, because the drawing program may not contain the pictograms needed. Do not waste precious time. Finally, avoid using symbols that may not give you or the customer an immediate understanding of the item in question, because it may well decrease the value of the Rich Picture. Simple hand drawings will do. Re-sketch if necessary to eliminate "noise" from the final sketch, and scan the drawing for use in your documentation material. If you draw on a blackboard or whiteboard, take a snapshot of the drawing with a digital camera. It is important to understand that a sketch can tell more than a thousand words and give both the developer and the customer a deeper insight of the entire scenario. | |
Use simple symbols like the examples shown below: | Use simple symbols like the examples shown below: | ||
+ | [[Image:Person.png]] A Person [[Image:Car.png]] A Car [[Image:House.png]] A House | ||
− | + | [[Image:Clock.png]] Clock - Time - Timer [[Image:Powerlines.png]] Power Lines | |
− | + | ||
+ | [[Image:Arrow.png]] Action [[Image:Conflict.png]] Possible conflict [[Image:Departemental_conflict.png]] Departmental conflict | ||
− | + | In systems with a high level of human interaction, or where the system is part of several departments' information processing, there may be hidden conflicts that are not related to the system itself, but is merely located in the work process. Strive to illustrate these potential conflicts in the sketch and make it clear to the customer that the new system will not be able to handle human conflicts in the organisation; it is the organisation's own responsibility to handle such conflicts. Look here for examples of conflicts. Conflicts can be illustrated with a knife or two crossed swords or the like. | |
− | + | ||
− | + | ''One question often arises: Should the [[system-to-be]] be part of the sketch? The most common answer is that it is seldom part of the sketch. If we incorporate the system-to-be in the sketch, we often end up with a block diagram or a data-processing diagram rather than a sketch showing the environment of the [[system-to-be]]. And indeed the main point of drawing rich pictures is to get an understanding of the surrounding environment in order to develop a system that fulfils the customer's needs. | |
− | + | '' | |
− | + | == Why == | |
+ | The system developer's first task in a new project is to get an initial understanding of the system-to-be and its environment along with the customer's needs. | ||
− | + | There are different types of customers; some produce very fine requirement specifications whereas others do not. Regardless of requirement specifications or not, the developer needs to understand the system-to-be. This is where the so-called Rich Picture plays a very important role. | |
+ | Too often when two or more project participants (within the engineering world) communicate about complex matters, they draw sketches on a piece of paper, a blackboard or a whiteboard. This is an excellent way for the developer to grasp the system-to-be. The best situation is where the customer representative joins the process and provides details about the environment of the system-to-be. Many issues will be clarified by spending a couple of hours with the customer talking about the new system and its environment. | ||
− | + | A Rich Picture is a very powerful and effective way of understanding the system-to-be. Rich Pictures are powerful because: | |
+ | * they are not technical, so a non-technical customer can understand them, | ||
+ | * they facilitate the communication between the customer and the developer, whereby the developer achieves important information for use in the further development process, | ||
+ | * they are easy and handy tools that everybody can use, and finally but not least, | ||
+ | * they most likely give rise to huge financial savings in the entire project. | ||
− | + | '''Honestly, why should I use the Rich Picture?''' | |
− | + | ||
− | + | There are a number of reasons for using the Rich Picture during the development of an IT system. Amongst these are (depending of the type of the system-to-develop): | |
− | + | ||
− | + | 1. The developer and the customer get a common perception of the system-to-be and the environment in which it should operate. | |
+ | 2. The Rich Picture can be put on both the customer's and the developer's wall as a means to keep focus for all involved. | ||
− | + | 3. The Rich Picture is both a very concrete and at the same time an abstract approach to a problem. | |
+ | 4. The Rich Picture can be used to illustrate several different solutions, thereby allowing the customer to select the best solution. | ||
− | + | 5. The Rich Picture displays the structure in which the system-to-be should be implemented. | |
+ | 6. The Rich Picture can be used to display the distribution of responsibilities in an organisation. | ||
− | + | 7. The Rich Picture can be used to display the relations between persons, departments or other kinds of organisational divisions. | |
− | + | ||
− | + | 8. The Rich Picture displays possible conflicts or synergy between persons or departments. | |
− | + | ||
− | + | 9. The Rich Picture displays cooperation or need for cooperation between persons or departments. | |
− | + | 10. The Rich Picture displays external influence from legislation authorities, suppliers, customers, etc. | |
− | + | 11. The Rich Picture can be used as a historical display showing why something is done the way it is today. This can lead to how the vision about the future can be implemented. | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | 12. The Rich Picture displays responsibility and decision competences. | |
− | + | ||
− | + | ||
− | + | ||
+ | == Example == | ||
− | + | [[Image:Rich Picture.png|500px]] | |
− | + | == Used In == | |
− | + | The Rich Picture is used in many subsequent processes. Especially in the beginning of the analysis processes, the Rich Picture comes in handy to create an overview of the environment of the [[system-to-be]]. | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + |
Latest revision as of 13:13, 5 February 2015
What
Rich Picture - drawn in cooperation with the customer showing the environment in which the system-to-be should operate.
How
The dish
Rich Picture
Ingredients
- Meeting with the customer
- Information about the customer
- Information about the IT system-to-be
Process
Schedule a meeting with the customer.
Prepare yourself by reading all material already given by the customer and seek related information on the Internet and other places where relevant information is available. Relevant information can be:
- Information about the customer:
- general information about the company
- products
- line of business, etc.
- Specific knowledge about the type of IT system in which you are going to be involved:
- controlling systems
- monitoring systems
- administrative systems, etc.
- Information about other suppliers to the company, etc.
Spend the first minutes at the meeting with the obligatory general small talk. Then, you should start asking questions about the environment which the IT system-to-be will be part of. During your conversation with the customer, you should draw a simple sketch simultaneously using symbols - pictograms - that illustrate the environment of the IT system.
After the meeting, make a new sketch on a sheet of white paper eliminating the "noise" introduced during the talks. Scan the sketch and include it as part of your documentation.
There may be a need for several meetings with the customer. If so, remember to bring along your rich pictures and use them continuously at the meetings.
In Details
Use simple pictograms (simple drawings of the item in question) to illustrate the environment. It is unnecessary and time-consuming to draw on a computer. Often, the time used to draw a sketch on the computer is wasted, because the drawing program may not contain the pictograms needed. Do not waste precious time. Finally, avoid using symbols that may not give you or the customer an immediate understanding of the item in question, because it may well decrease the value of the Rich Picture. Simple hand drawings will do. Re-sketch if necessary to eliminate "noise" from the final sketch, and scan the drawing for use in your documentation material. If you draw on a blackboard or whiteboard, take a snapshot of the drawing with a digital camera. It is important to understand that a sketch can tell more than a thousand words and give both the developer and the customer a deeper insight of the entire scenario.
Use simple symbols like the examples shown below:
Clock - Time - Timer
Power Lines
Action
Possible conflict
Departmental conflict
In systems with a high level of human interaction, or where the system is part of several departments' information processing, there may be hidden conflicts that are not related to the system itself, but is merely located in the work process. Strive to illustrate these potential conflicts in the sketch and make it clear to the customer that the new system will not be able to handle human conflicts in the organisation; it is the organisation's own responsibility to handle such conflicts. Look here for examples of conflicts. Conflicts can be illustrated with a knife or two crossed swords or the like.
One question often arises: Should the system-to-be be part of the sketch? The most common answer is that it is seldom part of the sketch. If we incorporate the system-to-be in the sketch, we often end up with a block diagram or a data-processing diagram rather than a sketch showing the environment of the system-to-be. And indeed the main point of drawing rich pictures is to get an understanding of the surrounding environment in order to develop a system that fulfils the customer's needs.
Why
The system developer's first task in a new project is to get an initial understanding of the system-to-be and its environment along with the customer's needs.
There are different types of customers; some produce very fine requirement specifications whereas others do not. Regardless of requirement specifications or not, the developer needs to understand the system-to-be. This is where the so-called Rich Picture plays a very important role.
Too often when two or more project participants (within the engineering world) communicate about complex matters, they draw sketches on a piece of paper, a blackboard or a whiteboard. This is an excellent way for the developer to grasp the system-to-be. The best situation is where the customer representative joins the process and provides details about the environment of the system-to-be. Many issues will be clarified by spending a couple of hours with the customer talking about the new system and its environment.
A Rich Picture is a very powerful and effective way of understanding the system-to-be. Rich Pictures are powerful because:
- they are not technical, so a non-technical customer can understand them,
- they facilitate the communication between the customer and the developer, whereby the developer achieves important information for use in the further development process,
- they are easy and handy tools that everybody can use, and finally but not least,
- they most likely give rise to huge financial savings in the entire project.
Honestly, why should I use the Rich Picture?
There are a number of reasons for using the Rich Picture during the development of an IT system. Amongst these are (depending of the type of the system-to-develop):
1. The developer and the customer get a common perception of the system-to-be and the environment in which it should operate.
2. The Rich Picture can be put on both the customer's and the developer's wall as a means to keep focus for all involved.
3. The Rich Picture is both a very concrete and at the same time an abstract approach to a problem.
4. The Rich Picture can be used to illustrate several different solutions, thereby allowing the customer to select the best solution.
5. The Rich Picture displays the structure in which the system-to-be should be implemented.
6. The Rich Picture can be used to display the distribution of responsibilities in an organisation.
7. The Rich Picture can be used to display the relations between persons, departments or other kinds of organisational divisions.
8. The Rich Picture displays possible conflicts or synergy between persons or departments.
9. The Rich Picture displays cooperation or need for cooperation between persons or departments.
10. The Rich Picture displays external influence from legislation authorities, suppliers, customers, etc.
11. The Rich Picture can be used as a historical display showing why something is done the way it is today. This can lead to how the vision about the future can be implemented.
12. The Rich Picture displays responsibility and decision competences.
Example
Used In
The Rich Picture is used in many subsequent processes. Especially in the beginning of the analysis processes, the Rich Picture comes in handy to create an overview of the environment of the system-to-be.