Software Engineering
Home Planning Requirements Writing Hazard Analysis Requirement Analysis Config Control Software Design Software Testing Software Standards Basic Logic

Requirements Analysis - Organizational Issues

Each individual has a given tolerance for uncertainty as a personality trait.

“Having intolerance of ambiguity means that you tend to perceive situations as threatening rather than promising. You prefer more structured situations. In contrast, people who score high on tolerance respond better to change and tend to be more creative.” – Prentice Hall Self-Assessment.

People with little or no tolerance for uncertainty may prefer careers in manufacturing or quality assurance, where their traits contribute to eliminating uncertainty from systems that cannot function with uncertainty. No one would want to buy prescription medication whose label reads "May contain some or all of the following..." Manufacturing is all about adhering to a baseline without deviation - the elimination of uncertainty.

In contrast, people with a high tolerance for uncertainty may prefer careers in marketing, product development, or a similar creative field, where their comfort with uncertainty contributes to product concept and development. Many highly creative people may even enjoy the uncertainty and prefer to remain at the “100,000 foot level” during product concept. Marketing and engineering have to be able to give form to concepts that are only vaguely defined - if at all. "What does the customer need? We'll have to find out!"

Conflict occurs when these differing mindsets have to collaborate on a project. A person with little tolerance for uncertainty will prefer a descriptive approach to testing, and may be uncomfortable with documents unless they contain a high degree of detail. In contrast, someone with a high tolerance for uncertainty will prefer a prescriptive test approach, and may actively resist writing highly detailed requirements or test steps.

Conflict can be a dialectic process with constructive results, or it can be personal with highly destructive results. When the conflict is strictly related to facts, then it will likely be dialectic and constructive. When the conflict is personal, involving ego and personality traits, then it will likely be destructive and result in team dysfunction. The greatest threat is probably that from people with little tolerance for uncertainty. As the Roman philospher Tacitus stated, if uncertainty is not acceptable, it turns into fear; only when uncertainty is acceptable can it turn into alertness and creativity.

Because the software development process begins with a high degree of uncertainty and ends with a low degree of uncertainty, there is ample opportunity for these two mindsets to conflict. To help ameliorate this effect I recommend the following flow of responsibility:

  1. Marketing passes control Development at the outset of the requirements phase (very high uncertainty to high/moderate uncertainty). Establishing the SRS should be controlled by software development, with Marketing input. Document is controlled by the Project Team.

  2. During development, a senior Software Quality Engineer (SQE) performs requirements analysis. The SQE is an R&D role, rather than a QA role, because it still requires some tolerance for uncertainty. The SQE creates the test objectives and provides feedback to the SRS.

  3. During unit and integration testing, developers provide detail to the test objectives, which the SQE can then use to create the detailed test procedure.

  4. A test group within R&D conducts testing, using the test procedure. Test results are reviewed by other testers and/or the SQE. The SQE writes the final test report.

  5. Independent QA reviews the test report and test data to ensure compliance with regulations. QA may also provide feedback to the test procedure. This role is likely to be filled by people with little or no tolerance for uncertainty, therefore they should only be involved when uncertainty no longer exists.

This allows the workflow to match the person’s comfort with uncertainty. This structure should be established in advance, so that team members are aware of their roles. Those who are intolerant of uncertainty (QA, etc.) will also be intolerant of role uncertainty, making it even more essential to have the roles and responsibilities established in advance. They will also be more likely to react out of fear rather than creativity unless they can accept the creative possibilities inherent in uncertaintly.