Succeeding with Use Cases: Working Smart to Deliver Quality
| This book is for anyone doing use case-driven development who wants to think outside the box a little to try some new ideas. Here's some guidance on who should read what parts and chapters of the book, and what background you are assumed to have. Table P.1 provides a guide to the parts and chapters of the book likely to be of greatest interest based on the role you play in product development. As is clear from this table, this book has something of interest for just about every role in product development. A check indicates a topic that is core to a team role: this is the role that would likely be applying that topic. A plus sign indicates that understanding of topic is a "plus" for a team role (e.g., your role interfaces with team members that would be using that technique, so your understanding would be beneficial).
Knowledge About Use Cases
The only assumption made about your background as a reader is that you are already familiar with use cases. The scope of the book does not include an introduction to use cases, UML, Unified Software Development Process, and so on. Many excellent books already cover these topics. Knowledge About the Other Software Engineering Disciplines
Previous knowledge of the other software engineering disciplines discussed in this book is not necessary. Do keep in mind that whole quality engineering disciplines have been condensed down to two chapters each. These are disciplines that merit whole books, and have large conferences and research and development communities, so what you will see is only a small part of what are large disciplines, but they are parts that yield a good bang for the buck for the use case community. Ample references have been provided to allow you to explore topics in more depth if you desire. A goal of this book is to increase the visibility of these other disciplines to the use case community, and I think references are key to this goal. For Those Who Hate Math
Two parts of the bookPart 2, "Software Reliability Engineering," and Part 3, "Model-Based Specification"have a little math in them. Part 2 involves a little probability and an equation or two, all of which you will be walked through carefully, so no prior background in probability is needed. Part 3especially the first chaptermay be the book's most challenging technically, more due to the concepts than the math. The only assumption made is that you are familiar with arithmetic and simple algebra. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||