Hypothetical Application Of Critical Thinking

Critical thinking is an extremely important quality that should be nurtured, refined and actively applied to every decision we make.

What Exactly is Critical Thinking?

In simple terms, critical thinking may be defined as reasonable reflective thinking focused on deciding what to believe or do. A more complete definition by the Critical Thinking Community is: “a mode of thinking, about any subject, content, or problem where the thinker improves the quality of his or her thinking by skillfully analyzing, assessing, and reconstructing reality. Critical thinking is self-directed, self-disciplined, self-monitored and self-corrective thinking.”

Being critical is like being paranoid—not taking everything you hear or read at face value. Critical

• The report may not be necessary at all—perhaps what the stakeholder really needs is a single functionality for adding up the total number of applications per month.

• The frequency of use may imply that the requirement should be assigned a lower priority or even deferred till a later phase.

This hypothetical example of the application of critical thinking shows how a lot of time can be saved from the get-go as opposed to a situation where the analyst just takes the requirements at face value without finding out what the real requirements are.

In certain situations, a stakeholder may put forward a requirement that’s not necessarily tied to any business value but rather to increasing their own convenience. Being critical allows the BA to distinguish between requirements that add value to the business and those that should be given a lesser priority.

There’s a huge difference between what a user wants and what they need. Being critical means separating bells and whistles functionality from the core functionality the system should

Some assumptions or concerns are valid while others are not. If a stakeholder shares a concern, the onus is on the BA to investigate the concern and ascertain its validity. One of the things the BA may want to find out is if stakeholder concerns are general concerns shared by others or if they’re isolated concerns stemming from a single experience one stakeholder had in the past. This will help to avoid the fallacy of hasty generalization.

For example, a stakeholder may state, “The application is slow—a single operation takes ages to complete.” This statement requires further investigation. The BA should, in this instance, verify which operation is slow, the speed of the network, and if other users have encountered the same problem. The user for instance, could have been executing a complex calculation involving an extensive range of data over a poor network connection. Such claims should be investigated critically before recommendations are made.

The key takeaway is to be investigative in your approach. You never know what you may