After completing this problem analysis activity, we can be reasonably confident that we have
In other words, we are now better prepared for the journey ahead.
As for the third domain, that of the ISVs, problem analysis techniques are typically focused on such activities as the following:
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
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