Book contents
- Frontmatter
- Contents
- Foreword
- Preface
- Acknowledgments
- About the Authors
- How to Customize This Book
- Chapter 1 Introduction
- Chapter 2 Aligning to the Business
- Chapter 3 Adding Rigor to the Requirements
- Chapter 4 Sketching the Inside Structure
- Chapter 5 Sketching the Inside Dynamics
- Chapter 6 Moving Toward Components
- Chapter 7 Mapping from Classes to Data Models
- Chapter 8 Concluding Remarks
- Some Suggested Readings
- Index
Chapter 3 - Adding Rigor to the Requirements
Published online by Cambridge University Press: 14 October 2009
- Frontmatter
- Contents
- Foreword
- Preface
- Acknowledgments
- About the Authors
- How to Customize This Book
- Chapter 1 Introduction
- Chapter 2 Aligning to the Business
- Chapter 3 Adding Rigor to the Requirements
- Chapter 4 Sketching the Inside Structure
- Chapter 5 Sketching the Inside Dynamics
- Chapter 6 Moving Toward Components
- Chapter 7 Mapping from Classes to Data Models
- Chapter 8 Concluding Remarks
- Some Suggested Readings
- Index
Summary
Business modeling concerns process owners, reengineers, or business analysts with IT specialists in an advisory role. Later, in class modeling and especially in object interaction modeling, IT people become the driving force. Here, in adding rigor to the requirements through use-case modeling, there's a shared effort. Business experts provide the essence of the requirements, while IT specialists provide the structure. Having modeled the business, we now start aligning the system specification – most of it being the functional requirements – to the requirements of our business processes.
A diagram technique for this is very widespread: UML standard use cases that were pioneered some 20 years ago by Ivar Jacobson. Use cases are simply the ways in which the actors use the system. A similar step is natural in any knowledge industry because exact requirements minimize lead time and misunderstandings.
Use Cases
Human-computer interaction (HCI) is a vast field, to which use cases contribute with a practical, down-to-earth technique for the doers. To end users of the planned solution, the user interface often seems to be the entire system. Use cases extend this simplified view by modeling what's going to happen at the user interface, as well as interfaces to other systems. Use cases, interface layout examples, and prototypes complement each other, so they fully define the functional requirements of the system. Any remaining UML diagrams specify the inside/kernel of the system hidden behind that interface.
- Type
- Chapter
- Information
- UML Xtra-LightHow to Specify Your Software Requirements, pp. 27 - 46Publisher: Cambridge University PressPrint publication year: 2002