Case Study

1.What Is a Case Study?

Ans. A case study is an in-depth study of one person. Much of Freud's work and theories were developed through individual case studies.In a case study, nearly every aspect of the subject’s life and history is analyzed to seek patterns and causes for behavior. The hope is that learning gained from studying one case can be generalized to many others. Unfortunately, case studies tend to be highly subjective and it is difficult to generalize results to a larger population.2. Case Studies types?

Ans. Under the more generalized category of case study exist several subdivisions, each of which is custom selected for use depending upon the goals and/or objectives of the investigator. These types of case study include the following:

Illustrative Case StudiesThese are primarily descriptive studies. They typically utilize one or two instances of an event to show what a situation is like. Illustrative case studies serve primarily to make the unfamiliar familiar and to give readers a common language about the topic in question.

Exploratory (or pilot) Case StudiesThese are condensed case studies performed before implementing a large scale investigation. Their basic function is to help identify questions and select types of measurement prior to the main investigation. The primary pitfall of this type of study is that initial findings may seem convincing enough to be released prematurely as conclusions.

Cumulative Case StudiesThese serve to aggregate information from several sites collected at different times. The idea behind these studies is the collection of past studies will allow for greater generalization without additional cost or time being expended on new, possibly repetitive studies.

Critical Instance Case StudiesThese examine one or more sites for either the purpose of examining a situation of unique interest with little to no interest in generalizability, or to call into question or challenge a highly generalized or universal assertion. This method is useful for answering cause and effect questions.

3. . Case Studies design?

Ans. After considering the different sub categories of case study and identifying a theoretical perspective, researchers can begin to design their study. Research design is the string of logic that ultimately links the data to be collected and the conclusions to be drawn to the initial questions of the study. Typically, research designs deal with at least four problems:

What questions to study What data are relevant What data to collect How to analyze that data

In other words, a research design is basically a blueprint for getting from the beginning to the end of a study. The beginning is an initial set of questions to be answered, and the end is some set of conclusions about those questions.

Because case studies are conducted on topics as diverse as Anglo-Saxon Literature (Thrane 1986) and AIDS prevention (Van Vugt 1994), it is virtually impossible to outline any strict or universal method or design for conducting the case study. However, Robert K. Yin (1993) does offer five basic components of a research design:

1. A study's questions.2. A study's propositions (if any).3. A study's units of analysis.4. The logic linking of the data to the propositions.5. The criteria for interpreting the findings.

In addition to these five basic components, Yin also stresses the importance of clearly articulating one's theoretical perspective, determining the goals of the study, selecting one's subject(s), selecting the appropriate method(s) of collecting data, and providing some considerations to the composition of the final report.

4.When use case studies?

Ans. A case study is an intensive analysis of an individual unit (e.g., a person, group, or event) stressing

developmental factors in relation to context.[1] The case study is common in social sciences and life sciences. Case

studies may be descriptive or explanatory. The latter type is used to explore causation in order to find underlying

principles.[2][3] They may be prospective (in which criteria are established and cases fitting the criteria are included as

they become available) or retrospective (in which criteria are established for selecting cases from historical records

for inclusion in the study).

Thomas[4] offers the following definition of case study: "Case studies are analyses of persons, events, decisions,

periods, projects, policies, institutions, or other systems that are studied holistically by one or more methods. The

case that is the subject of the inquiry will be an instance of a class of phenomena that provides an analytical frame —

anobject — within which the study is conducted and which the case illuminates and explicates."

Rather than using samples and following a rigid protocol (strict set of rules) to examine limited number of variables,

case study methods involve an in-depth, longitudinal (over a long period of time) examination of a single instance or

event: a case. They provide a systematic way of looking at events, collecting data, analyzing information, and

reporting the results. As a result the researcher may gain a sharpened understanding of why the instance happened

as it did, and what might become important to look at more extensively in future research. Case studies lend

themselves to both generating and testing hypotheses.[5]

Another suggestion is that case study should be defined as a research strategy, an empirical inquiry that

investigates a phenomenon within its real-life context. Case study research can mean single and multiple case

studies, can include quantitative evidence, relies on multiple sources of evidence, and benefits from the prior

development of theoretical propositions. Case studies should not be confused with qualitative research and they can

be based on any mix of quantitative and qualitative evidence. Single-subject research provides the statistical

framework for making inferences from quantitative case-study data.[3][6] This is also supported and well-formulated in

(Lamnek, 2005): "The case study is a research approach, situated between concrete data taking techniques and

methodologic paradigms."

The case study is sometimes mistaken for the case method, but the two are not the same.

5. Key elements of a case study:

Ans.key elements of a case study:

Widest (not just Harvard Business model) multimedia as appropriate flexible for multiple purposes permitting contextual interactivity supporting materials

Peer-reviewed models of practice

Analysis Theory to practice

Shared explicit examples

Rich case material to engage viewers

Visual message permits "show me"

Examples to include good bad AND mediocre stages of innovation

Framework or metaphor for a case or a collection of minicases ...

Vignettes Walkthroughs

Series of minicases

Long (45-1 hour for context) remains important

Mediation of Case studies

Community of practice Framework

Design metaphor for engagement or facilitation

Assessment optional. Evaluation/assessment of performance for a variety of perspectives and purposes.

Inspiring reflection through

Shared view of the action with images/sound Background with teacher's view; student's views; materials; institutional 'stage'

 Support materials

Indexing and databasing of examples

Units of practice that support the video examples

Different “characters” talk from their Points of View

7. "System" box?

Ans. The system box only appears on the top-level diagram (remember that a typical UML Use Case description will be composed of many diagrams and sub-diagrams), and should contain use case ovals, one for each top-level service that your system provides to its actors. Any kind of internal behavior that your system may have that is only used by other parts of the system should not appear in the system box. One useful way to think of these top-level services is as follows: if a use case represents a top-level service, then it should make sense for the actors who interact with it to request only that service of your system in a single session (in whatever sense a "session" is intelligible in your system.)

8. What is a UML Use Case Diagram (UCD), and when should I use it?

Ans. In software and systems engineering, a use case (pronounced /juːs/, a case in the use of a system) is a list of

steps, typically defining interactions between a role (known in UML as an "actor") and a system, to achieve a goal.

The actor can be a human or an external system.

In systems engineering, use cases are used at a higher level than within software engineering, often representing

missions or stakeholder goals. The detailed requirements may then be captured in SysML or as contractual

statements.

History

In 1986 Ivar Jacobson first formulated textual, structural and visual modeling techniques for specifying use cases. In

1992 his co-authored book[1] helped to popularize the technique for capturing functional requirements, especially in

software development. Originally he used the terms usage scenarios and usage case – the latter being a direct

translation of his Swedish term användningsfall – but found that neither of these terms sounded natural in English,

and eventually he settled on use case.[2] Since then, others have contributed to improving this technique, notably

including Alistair Cockburn.

[edit]Use case structure[edit]Martin Fowler

Martin Fowler states "There is no standard way to write the content of a use case, and different formats work well in

different cases."[3]:100 He describes "a common style to use" as follows:[3]:101

Title: "goal the use case is trying to satisfy"[3]:101

Main Success Scenario: numbered list of steps[3]:101

Step: "a simple statement of the interaction between the actor and a system"[3]:101

Extensions: separately numbered lists, one per Extension[3]:101

Extension: "a condition that results in different interactions from .. the main success scenario". An

extension from main step 3 is numbered 3a, etc.[3]:101

[edit]Alistair Cockburn

Alistair Cockburn describes a more detailed structure for a use case, but permits it to be simplified when less detail is

needed. His "fully-dressed" use case structure is:[4]:9-10

[edit]Fully dressed use case structure

Cockburn's Fully dressed use case template lists the following fields:[5]

Title: "an active-verb goal phrase that names the goal of the primary actor"[6]

Primary Actor

Goal in Context

Scope

Level

Stakeholders and Interests

Precondition

Minimal Guarantees

Success Guarantees

Trigger

Main Success Scenario

Extensions

Technology & Data Variations List

Related Information.

In addition, Cockburn suggests using two devices to indicate the nature of each use case: icons for design scope and

goal level.

Cockburn's approach has influenced other authors; for example, Alexander and Beus-Dukic generalize Cockburn's

"Fully dressed use case" template from software to systems of all kinds, with the following fields differing from

Cockburn:[7]

Variation scenarios "(maybe branching off from and maybe returning to the main scenario)"

Exceptions "i.e. exception events and their exception-handling scenarios"

[edit]Casual use case structure

Cockburn recognizes that projects may not always need detailed "fully-dressed" use cases. He describes a Casual

use case with the fields:[5]

Title (goal)

Primary Actor

Scope

Level

(Story): the body of the use case is simply a paragraph or two of text, informally describing what happens.

[edit]Design scope icon

Cockburn suggests annotating each use case with a symbol to show the "Design Scope", which may be black-box

(internal detail is hidden) or white-box (internal detail is shown). Five symbols are available:[8]

Organization (black-box), a filled icon of a house

Organization (white-box), an unfilled icon of a house

System (black-box), a filled icon of a box

System (white-box), an unfilled icon of a box

Component, an icon of a screw or bolt.

Other authors sometimes call use cases at Organization level "Business use cases".[9]

[edit]Goal level icon

Cockburn suggests annotating each use case with a symbol to show the "Goal Level";[10] the preferred level is "User-

goal" (or colloquially "sea level"[3]:101).

Very high summary, an icon of a cloud

Summary, an icon of a flying kite

User-goal, an icon of waves at sea

Subfunction, an icon of a fish

Too low, an icon of a seabed clam-shell.

[edit]Actors

A use case defines the interactions between external actors and the system under consideration to accomplish a

goal. Actors must be able to make decisions, but need not be human: "An actor might be a person, a company or

organization, a computer program, or a computer system — hardware, software, or both."[11] Actors are

always stakeholders, but many stakeholders are not actors, since they "never interact directly with the system, even

though they have the right to care how the system behaves."[11] For example, "the owners of the system, the

company's board of directors, and regulatory bodies such as the Internal Revenue Service and the Department of

Insurance" could all be stakeholders but are unlikely to be actors.[11]

Similarly, a person using a system may be represented as different actors because he is playing different roles. For

example, user "Joe" could be playing the role of a Customer when using an Automated Teller Machine to withdraw

cash from his own account, or playing the role of a Bank Teller when using the system to restock the cash drawer on

behalf of the bank.

Actors are often working on behalf of someone else. Cockburn writes that "These days I write 'sales rep for the

customer' or 'clerk for the marketing department' to capture that the user of the system is acting for someone else."

This tells the project that the "user interface and security clearances" should be designed for the sales rep and clerk,

but that the customer and marketing department are the roles concerned about the results.[12]

A stakeholder may play both an active and an inactive role: for example, a Consumer is both a "mass-market

purchaser" (not interacting with the system) and a User (an actor, actively interacting with the purchased product).

[13] In turn, a User is both a "normal operator" (an actor using the system for its intended purpose) and a "functional

beneficiary" (a stakeholder who benefits from the use of the system).[13] For example, when user "Joe" withdraws

cash from his account, he is operating the Automated Teller Machine and obtaining a result on his own behalf.

Cockburn advises to look for actors among the stakeholders of a system, the primary and supporting (secondary)

actors of a use case, the system under design (SuD) itself, and finally among the "internal actors", namely the

components of the system under design.[11]

[edit]Use case notation

In the Unified Modeling Language, the relationships between all (or a set of) the use cases and actors are

represented in a Use Case Diagram or diagrams, originally based upon Ivar Jacobson's Objectory notation. SysML,

a UML profile, uses the same notation at the system block level.

[edit]Limitations

Limitations of Use cases include:

Use cases are not well suited to capturing non-interaction based requirements of a system (such as

algorithm or mathematical requirements) or non-functional requirements (such as platform, performance, timing,

or safety-critical aspects). These are better specified declaratively elsewhere.

Use case templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s).

Use cases are complex to write and to understand, for both end users and developers.

As there are no fully standard definitions of use cases, each project must form its own interpretation.

Some use case relationships, such as extends, are ambiguous in interpretation and can be difficult for

stakeholders to understand.

In Agile, simpler user stories are preferred to use cases.

Use case developers often find it difficult to determine the level of user interface (UI) dependency to

incorporate in a use case. While use case theory suggests that UI not be reflected in use cases, it can be

awkward to abstract out this aspect of design, as it makes the use cases difficult to visualize. In software

engineering, this difficulty is resolved by applying requirements traceability, for example with a traceability matrix.

Use cases can be over-emphasized. Bertrand Meyer discusses issues such as driving system design too

literally from use cases, and using use cases to the exclusion of other potentially valuable requirements analysis

techniques.[14]

Use cases are a starting point for test design, [15] but since each test needs its own success criteria, use

cases may need to be modified to provide separate postconditions for each path.[16]

12.What is a UML Use Case Diagram (UCD), and when should I use it?

UML Use Case Diagrams can be used to describe the functionality of a system in a horizontal way. That is, rather than merely representing the details of individual features of your system, UCDs can be used to show all of its available functionality. It is important to note, though, that UCDs are fundamentally different from sequence diagrams or flow charts because they do not make any attempt to represent the order or number of times that the systems actions and sub-actions should be executed. There are a number of graphical examples in this FAQ; you might want to look over them to familiarize yourself with the look of them. 

UCDs have only 4 major elements: The actors that the system you are describing interacts with, the system itself, the use cases, or services, that the system knows how to perform, and the lines that represent relationships between these elements. 

You should use UCDs to represent the functionality of your system from a top-down perspective (that is, at a glance the system's functionality is obvious, but all descriptions are at a very high level. Further detail can later be added to the diagram to elucidate interesting points in the system's behavior.) Example: A UCD is well suited to the task of describing all of the things that can be done with a database system, by all of the people who might use it (administrators, developers, data entry personnel.) 

You should NOT use UCDs to represent exception behavior (when errors happen) or to try to illustrate the sequence of steps that must be performed in order to complete a task. Use Sequence diagrams to show these design features.Example: A UCD would be poorly suited to describing the TCP/IP network protocol, because there are many exception cases, branching behaviors, and conditional functionality (what happens when a packet is lost or late, what about when the connection dies?) 13. How is a UML Use Case Diagram different from a traditional flow chart?

As mentioned above, UCDs represent functionality in a top-down way, whereas flow charts represent behavior in a linear, time-based way. Also, the way you develop them is all-together different. 

Example: (This text refers to the diagrams below.) When constructing a UCD, the initial step is to identify all of the top-level behavior. Once you have done this (not a very tricky process) you have already described, at least in a high-level way, all of the things your system knows how to do. You can then continue to add detail by decomposing your use cases into more use cases which are used by the top-level use cases. At every stage of development, though, your UCD is a complete description of the system's functionalty: it may lack detail, but it will not lack feature set elements. And if functionality or behavior is added or deleted over the life of your project, the scope of the change you need to make is proportional to both the scope of the change in the system itself, and the maturity of your model. This is useful because it means that when your model is very young (only high-level diagrams drawn) making sweeping changes to the system does not involve throwing very much work away. A flow chart, however, does not correctly describe the system until you have finished drawing it, and even then small changes in the system will result in significant reworking of your flow charts. In general, UCDs support the process of analysis and design much better than flow charts. 

15. UML stands for Unified Modeling Language which is used in object oriented software engineering. Although typically used in software engineering it is a rich language that can be used to model an application structures, behavior and even business processes. There are 14 UML diagram types to help you model these behavior. They can be divided into two main categories structure diagrams and behavioral diagrams. All 14 UML diagram types are listed below with examples, brief introduction to them and also how they are used when modeling applications.List of UML Diagram TypesTypes of UML diagrams with structure diagrams coming first and behavioral diagrams starting from position 8. Click on any diagram type to visit that specific diagram types description.

1. Class Diagram 2. Component Diagram 3. Deployment Diagram 4. Object Diagram 5. Package Diagram 6. Profile Diagram 7. Composite Structure Diagram 8. Use Case Diagram 9. Activity Diagram 10. State Machine Diagram 11. Sequence Diagram 12. Communication Diagram 13. Interaction Overview Diagram

14. Timing Diagram

16. Structure diagrams show the things in a system being modeled. In a more technical term they show different objects in a system. Behavioral diagrams shows what should happen in a system. They describe how the objects interact with each other to create a functioning system.Class diagrams are arguably the most used UML diagram type. It is the main building block of any object oriented solution. It shows the classes in a system, attributes and operations of each class and the relationship between each class. In most modeling tools a class has three parts, name at the top, attributes in the middle and operations or methods at the bottom. In large systems with many classes related classes are grouped together to to create class diagrams. Different relationships between diagrams are show by different types of Arrows. Below is a image of a class diagram. Follow the link for more class diagram examples.

UML Class Diagram with Relationships

A component diagram displays the structural relationship of components of a software system. These are mostly used when working with complex systems that has many components. Components communicate with each other using interfaces. The interfaces are linked using connectors. Below images shows a component diagram.

Simple Component Diagram with Interfaces

A deployment diagrams shows the hardware of your system and the software in those hardware. Deployment diagrams are useful when your software solution is deployed across multiple machines with each having a unique configuration. Below is an example deployment diagram.

UML Deployment Diagram ( Click on the image to use it as a template )

Object Diagrams, sometimes referred as Instance diagrams are very similar to class diagrams. As class diagrams they also show the relationship between objects but they use real world examples. They are used to show how a system will look like at a given time. Because there is data available in the objects they are often used to explain complex relationships between objects.

UML Object Diagram Example

As the name suggests a package diagrams shows the dependencies between different packages in a system. Check out this wiki article to learn more about the dependencies and elements found in package diagrams.

Package Diagram in UML

Profile diagram is a new diagram type introduced in UML 2. This is a diagram type that is very rarely used in any specification. For more detailed technical information about this diagram type check this link.

Basic UML Profile Diagram structure

Composite structure diagrams are used to show the internal structure of a class. For a detailed explanation of composite structure diagrams click here.

A simple Composite Structure Diagram

Most known diagram type of the behavioral UML diagrams, Use case diagrams gives a graphic overview of the actors involved in a system, different functions needed by those actors and how these different functions are interacted. It’s a great starting point for any project discussion because you can easily identify the main actors involved and the main processes of the system. Click through to read more about use case diagram elements and templates.

Use Case diagram showing Actors and main processes

Activity diagrams represent workflows in an graphical way. They can be used to describe business workflow or the operational workflow of any component in a system. Sometimes activity diagrams are used as an alternative to State machine diagrams. Check out this wiki article to learn about symbols and usage of activity diagrams.

Activity Diagrams with start, end, processes and decision points

State machine diagrams are similar to activity diagrams although notations and usage changes a bit. They are sometime known as state diagrams or start chart diagrams as well. These are very useful to describe the behavior of objects that act different according to the state they are at the moment. Below State machine diagram show the basic states and actions.

State Machine diagram in UML, sometime referred to as State or State chart diagram

Sequence diagrams in UML shows how object interact with each other and the order those interactions occur. It’s important to note that they show the interactions for a particular scenario. The processes are represented vertically and interactions are show as arrows. This article explains thepurpose and the basics of Sequence diagrams.

Sequence Diagrams in UML shows the interaction between two processes

Communication diagram was called collaboration diagram in UML 1. It is similar to sequence diagrams but the focus is on messages passed between objects. The same information can be represented using a sequence diagram and different objects. Click here to understand the differences using an example.

Communication Diagram in UML

Interaction overview diagrams are very similar to activity diagrams. While activity diagrams shows a sequence of processes Interaction overview diagrams shows a sequence of interaction diagrams. In simple term they can be called a collection of interaction diagrams and the order they happen. As mentioned before there are seven types of interaction diagrams, so any one of them can be a node in an interaction overview diagram. ( img – http://www.sa-depot.com/?page_id=645 )

Interaction overview diagram in UMLTiming diagrams are very similar to sequence diagrams. They represent the behavior of objects in a given time frame. If its only one object the diagram is straight forward but if more then one objects are involved they can be used to show interactions of objects during that time frame as well. ( img –http://blog.tangcs.com/2008/01/10/uml-2-diagrams/ )

Timing Diagram in UML

Mentioned above are all the UML diagram types. The links given in each section explains the diagrams in more detail and covers the usage, symbols etc. UML offers many diagram types and sometimes two diagram can explain the same thing using different notations.Check this blog post to learn which UML diagram best suits you.If you have any questions or suggestions feel free to leave a comment.

11. Case methodThe case method is a teaching approach that consists in presenting the students with a case, putting them in

the role of a decision maker facing a problem (Hammond 1976). The case method overlaps with the case

study method, but the two are not identical.[1]

Case studies recount real life business or management situations that present business executives with a dilemma or

uncertain outcome. The case describes the scenario in the context of the events, people and factors that influence it

and enables students to identify closely with those involved

The case method is a teaching method that is largely used in business schools. For instance it was used at

the Harvard Business School since the founding of the school in 1908 (Corey 1998).

Teaching cases

Teaching cases are available through clearing repositories such as the Caseplace and European Case

Clearing House, or through professional writing and publishing centers, such as Globalens at the University of

Michigan.

Teaching case studies, and to a lesser extent writing them, is a central function performed at the top business

schools worldwide. Some organizations, such as European Case Clearing House and GlobaLens, run

competitions to identify the best new teaching cases. Some of the institutions that are the most active at writing

teaching cases (as determined by the quantity and quality validated by awards) are: Harvard Business

School, IESE, the Darden School at the University of Virginia, University of Michigan Ross School of

Business (through Globalens, INSEAD, Richard Ivey School of Business, the Asian Institute of

Management, Indian Institute of Management, Ahmedabad and Asian Case Research Centre at the University

of Hong Kong.

A business case is a document that illustrates a business or policy situation to be solved and includes

information for classroom discussion and other study. The situation does not have an obvious solution. The

case provides information to stimulate an educated conversation concerning possible outcomes. Each case

has one central decision point, dilemma, or angle. The nature of the situation is clearly apparent within the first

two paragraphs.

The writing in a case is precise and nuanced, yet always clear and concise. It is neither colloquial nor stuffily

formal. It is also engaging and interesting to the reader. It is imperative for a case writer to always be objective

—a case is not a marketing pamphlet for the featured organization, though the writer may portray biases that

the protagonist may have.

Structure

Writing styles may be unique to the individuals developing a case, yet almost every successful case employs

the following structure:

Title and Introduction (½-2 pages)

For the title, in fewer than 10 words make clear what is special about this particular case.

Within the first paragraph, identify the case’s central person and business or organization, and provide

a sense of the situation the person is in.

Within the first two paragraphs, present what the central person sees as the decision point or dilemma.

Identify other major players if relevant.

In the remainder of the introduction, provide the context for the situation: when the situation took place

(at least the year), the location and purpose of the company or organization, the relevant important

business factors, and the goal or aim of the central person.

[edit]Background on the Company, Industry and Competitors (3-7 pages)

Begin this section with the first subhead. If the section is long or relatively complex, use more than one

subhead within the section to organize separate aspects.

Often the best method for writing this section is to organize the information chronologically, with a very

brief history of the company or organization.

Provide the essential company, organization, competitor, and/or industry information that the central

person had at the time of the case. What and where are the major products or services and their

customers?

Include enough background information for the reader to analyze the decision point presented in the

introduction. Revenues, profits and losses, and other financial valuations may be crucial.

Do not simplify or weight the background section to lead students to an easy decision.

Include, as appropriate, historical information, trends, direct quotations from participants and analysts,

and simple and/or essential tables and figures. The section can also include references to exhibits placed

in the appendix, though the references should be clear and complete enough that the reader can continue

without having to turn immediately to the exhibits.

Consider depicting the culture of the company or organization if relevant.

What are the important challenges and responsibilities of the central person?

Are certain portions of the person’s career particularly important to the current situation?

Connect the background in this section to the current situation, including underlying causes and

current results.

[edit]The Decision Point in More Detail (1-5 pages)

Begin this section with a subhead. Within it, use more subheads if appropriate.

Go more deeply into the context and possible consequences of the decision point, dilemma or central

angle. Include the consequences for the career of the central person as well as for the person’s company

or organization.

Show, if true, how the decision point or dilemma differs from the one initially perceived.

Include the degree of urgency involved in the decision-making, or the timeline for the decision to be

made.

Conclude the text with alternatives available to the central person.

[edit]Exhibits and Endnotes (4-10 pages)

Use a subhead before any exhibits and before any listing of endnotes. Use a small title with each exhibit,

beginning “Exhibit 1:” Exhibits can include financial statements, time lines, diagrams, charts, tables, pictures,

and graphs. In some cases it is possible to include or link to multimedia supplements such as an interview

video with the case’s central person. An endnote is needed for anything mentioned in the text for which a

reasonable reader would want to know the source of the assertion, quotation, or apparent fact. The endnotes

are referred to by number in the text and the notes themselves appear in order, all together, after the exhibits.

An exhibit can have an endnote or its sourcing can appear as part of the exhibit.

More information is available on How to Write a Case Study.

8. A quick guide to five common color terms your clients may not fully understand.

Color terminology helps designers and decorators accurately share their vision with clients before it comes into existence. But even the most basic terms are often misunderstood by clients and even by some designers. Words that have a very specific meaning in color theory can have much broader, more nebulous meaning in the average person's mind. So being sure your client understands what you mean when you're describing a color scheme can be a tricky proposition.

Here's a handy glossary defining five of the most common – and most commonly misused – color terms: tint, shade, tone, value and saturation.

Tint.Put simply, a tint is a lighter variation of a color. Tints are created by adding white to colors. For example, pink is a tint of red. A commonly held meaning of this word is to add color to something (blue-tinted hair), so it's important to be clear with clients that the color-theory meaning is quite different.

Shade.A color made darker by adding black to it. Navy is a shade of blue. This word is routinely used to describe any variation of color, even much lighter ones — take for example the 1960s song "A Whiter Shade of Pale" — so some clients may not understand that shades are darker than the base color.

Tone.If gray is added to a color, a tone of that color is created. Tones are generally more muted versions of colors. Clients sometimes refer to grayer versions of colors as “tints” or “shades,” a distinction not widely known outside the art and design communities.

Value.This term describes the lightness or darkness of a color. Colors with more white (tints) have higher value, and darker colors (shades) have lower value. It's a very helpful term when describing the possibilities of color, but you'll want to explain it clearly to clients.

Saturation.The purity or intensity of a color is called saturation. The most-saturated colors are vivid and strong, where less-saturated colors can appear washed out or muted. Gray has zero saturation. The quality of light can affect saturation; for example, a painted wall's color can appear more saturated during the day and less so as the light fades, and different types of artificial light can enhance or diminish saturation.