Looking Ahead

With this background, we can now turn our attention to two more specific problem analysis techniques that can be applied in certain application domains. In Chapter 6, we'll look at business modeling, a technique we can apply to IS/IT applications. In Chapter 7, we'll look at systems engineering for software- intensive systems, which can be applied to applications in the embedded-system domain.

As for the third domain, that of the ISVs, problem analysis techniques are typically focused on such activities as the following:

• Identifying market opportunities and market segments

• Identifying classes of potential users and their particular needs

• Studying the demographics of the potential user base

• Understanding potential demand, pricing, and pricing elasticity

• Understanding sales strategies and distribution channels

Clearly, these are interesting topics to a software product company, but to help us manage the scope of this book, we will not discuss these specific issues further. However, you can rest assured that the team skills we explore in later chapters apply equally well to this class of application, as we will illustrate .

Note

One of the most difficult things about writing this book was attempting to present a variety of techniques to build the team skills sets. No one technique works in all situations; no two situations are the same.

In prior chapters, we focused on a general philosophical approach to problem analysis that appears to work in most systems contexts. However, the problem of selecting a technique to apply becomes even more acute in the following chapters of the book, wherein we define a technique for business modeling and a technique for systems engineering, and then go on to define a variety of techniques in Team Skill 2, Understanding User and Stakeholder Needs, where we present a wide variety of techniques you can use to understand the needs of stakeholders and users with respect to a system you are about to build.

However, we think it's important to point out that the techniques described in this book ”from problem analysis to brainstorming ”can be used in many different parts of the software process, not just in the part of the process where we have chosen to describe them. For example, the team could use problem analysis to define a sales order entry system problem or to resolve a technical problem within its implementation. Similarly, the team could use brainstorming to determine the potential root causes in a problem analysis exercise or to determine potential new features for a system. We make no attempt to describe every circumstance under which a particular technique will apply; instead, we focus on helping the team develop the skills we describe so that it can add these techniques to its bag of tricks ”to be pulled out and used at appropriate points in the project.