(From the Back Cover) * Reduce the incidence of duplicate and inconsistent requirements;
* Communicate requirements that are understandable to both users and developers;
* Communicate a vision of what the application needs to do without the distractions inherent in a coded prototype;
* Document the entire requirements process clearly and efficiently.
Use Cases: Requirements in Context first examines the difficulties of requirements gathering and briefly introduces both use cases and the Unified Modeling Language (UML). Using detailed examples that run through the book, it then elaborates a four-step method for establishing requirements--an iterative process that produces increasingly refined requirements. Drawing on their own extensive experience, the authors offer practical advice on how to manage this process, including guidance on planning, scheduling, and estimating. They also dedicate an entire chapter to the common mistakes made during requirements capture and specification, particularly those related to use case creation.
This detailed, hands-on book shows you how to:
* Describe the context of relationships and interactions between actors and applications using use case diagrams and scenarios;
* Specify functional and non-functional requirements;
* Create the candidate use case list;
* Break out detailed use cases and add detail to use case diagrams;
* Add triggers, preconditions, basic course of events, and exceptions to use cases.
Other tools examined in this book include the stakeholder interview, use case name filters, the context matrix, user interface requirements, team organization, and quality assurance.
Review By: Cyndee Schwartz 09/29/2003Requirements drive software development. If the requirements process is flawed in any way, chances are the project itself will be flawed, and in danger of failing. What makes good requirements, and what makes bad requirements? And how do use cases fit into the scheme of things? You will find the answer in Use Cases: Requirements in Context. The authors, Daryl Kulak and Eamonn Guiney, first spend a considerable amount of time with you, illustrating what a requirement is, and what it isn’t. Then you are introduced to the use case.
What is a use case? According to the authors, use cases are meant to show the interaction between the system and the entities external to the system. Use cases illustrate the "what" that needs to be done, but not the "how." A use case is concerned only with what the system is supposed to do for the user.
How does the use case fit into the requirements process? The use case, as explained by Kulak and Guiney, shows the system from the user's point of view, and becomes what the users require from the software. So, how do you create a use case? Where the first chapter is dedicated to the requirements process, the next seven chapters go into exhaustive detail about the four stages of use case development. Those stages are: façade, filled, focused, and finished. The authors supply real-life examples, with explanations and easy to use templates to follow.
They don't stop there. Kulak and Guiney spend time in the management process as well, delving into topics such as splitting up the work; avoiding quality problems; avoiding redundancy; and of all things, classic mistakes. Their philosophy about learning from others' mistakes is that you don’t learn from others' mistakes. You will make the same ones. So, make them, recognize them, and move on to other ways of doing things. The appendices give full blown case studies of requirements processes using use cases. Risk analysis and business rules are also covered in these sections.
Use Cases: Requirements in Context, is an excellent resource for both the product marketing team, and the project management team. It is easy to read and packed with good, solid, usable information. The most important part of the software development life cycle is the requirements gathering process. Strong, thorough requirements analysis will build a strong, solid design, which will, in turn, be the basis for a strong, quality product.
Unfortunately, there is often a communication breakdown between the engineering department and the end-user, causing the finished product to not be very much like what the user expected. The use case process, as outlined by the authors, Daryl Kulak and Eamonn Guiney, turns "system-based" development into "user-based" development, where the users dictate what they need the software to accomplish.
Though the content is not focused towards quality assurance, QA analysts, and managers who are involved in the software design process will benefit from the information supplied in that they will derive a better understanding of the how the design process should work. There is also a bit of coverage on how the use case can evolve into the QA test case during the testing phase of the project.
However, the best use of the information contained in these pages will be in the hands of those who play a major role in putting together those software design documents – the system analysts, and the managers who are driving the project. All in all, a very informative book and a must read for all those with any involvement in the design process of software development.