Leanpub Header

Skip to main content
Go to Leanpub.comLeanpub

Business Analysis & Requirements Engineering

Innovating Your Products and Processes For Sustainable Success

Peter Hruschka

We can find a solution to every problem – if we can agree on what exactly the problem is. Understanding problems and communicating requirements is the subject of this book.

Many different terms are used for this (business analysis, system analysis, requirements engineering, etc.) and there are many job titles for those involved.

Business analysis and requirements engineering are two sides of the same coin: as an entrepreneur, you want to streamline your organizational and operational structures and make them more effective. As a product developer, you want to find unique selling points for your existing or new products, whether it's price, quality, or performance. As an IT department, you want to understand these requirements in order to deliver great products and systems.

This book presents a pragmatic and agile approach to dealing with requirements. It provides you with methods, notations, and many practical tips for effectively handling requirements between clients and contractors.

The author is letting you choose the price you pay for this book!

Pick Your Price...
PDF
EPUB
WEB
About

About

About the Book

Business Analysis & Requirements Engineering

  • Successful cooperation between business and IT
  • ONE GOAL - independent of your job title: create products, systems and proceses that your users will love
  • Pragmatic methods to identify and communicate requirements

New in the third edition:

  • more on quality requirements
  • more criteria for structuring requirements in the large

Share this book

Categories

Software EngineeringComputer Science

Feedback

Email the author

Price

Pick Your Price...

Minimum price

$24.00

$29.00

You pay

$29.00

Author earns

$23.20
$

All prices are in US $. You can pay in US $ or in your local currency when you check out.

EU customers: prices exclude VAT, which is added during checkout.

...Or Buy With Credits!

Number of credits (Minimum 2)

2
The author will earn $24.00 from your purchase!
You can get credits monthly with a Reader Membership

Author

About the Author

Peter Hruschka

Dr. Peter Hruschka is co-founder and enthusiastic user of the (open source) req42 documentation template for requirements communication and documentation, as well as co-founder of the corresponding arc42 template for software and systems architects.

He is also a founding member of the International Requirements Engineering Board (IREB e.V.) and helped creating foundation and advanced level curricula for the certification of Business Analysts and Requiremetns Engineers worldwide.

Peter is a principal of the Atlantic Systems Guild, an international think tank that has influenced the systematic development of IT systems through numerous publications and presentations.

He lives betweeen Aachen, Germany and his holiday home in Austria with his wife Monika. When not working, he can usually be found in the most beautiful parts of the world, trying to hit little white balls into holes that are way too far away and way too small.

E-mail: peter@systemsguild.com or hruschka@b-agile.de 

Contents

Table of Contents

    • Preface
      • Preface to the Third Edition
    • 1 Problems, Goals, Ideas and Visions
      • 1.1 What are we Talking About?
      • 1.2 Quantitative Reasons
      • 1.3 Qualitative Reasons
      • 1.4 Why doesn’t Everyone Do it Right?
      • 1.5 Two More Reasons
      • 1.6 Standardization and Certification
      • 1.7 Three Pillars of Successful Projects
      • 1.8 Definition: Business Analysis and Requirements Engineering
      • 1.9 Definition: Requirement
      • 1.10 Types of Requirements
      • 1.11 Main Tasks of Analysts and Product Owners
      • 1.12 Distribution of Tasks in a Team
      • 1.13 Required Skills
      • 1.15 What Makes Analysis Easier?
      • 1.16 Different Approaches
      • 1.17 Summary
    • 2 A Successful Start
      • 2.1 Three Ingredients for a Successful Start
      • 2.2 Goals
      • 2.3 Specify Goals
      • 2.4 Stakeholders
      • 2.5 Finding Stakeholders
      • 2.6 The Most Important Stakeholders: The Users
      • 2.7 Further Sources for Requirements
      • 2.8 Scope and Context
      • 2.9 Scope and Analysts
      • 2.10 Dealing with Gray Areas
      • 2.11 Representation of the System/Product Boundary
      • 2.12 Alternative Notations
      • 2.13 The Three Ingredients for Success (Once More)
      • 2.14 Summary
    • 3 Business Processes and Product Functionality
      • 3.1 Requirements of Different Granularity
      • 3.2 Structuring and Organizing Functional Requirements
      • 3.3 Processes: The Basic Idea
      • 3.4 Finding Processes
      • 3.5 Structuring a Domain into Subdomains
      • 3.6 Recommendations and Warnings
      • 3.7 Summary
    • 4 A Closer Look at Major Functions
      • 4.1 Decomposition Criteria
      • 4.2 Where Do You Stop?
      • 4.3 Top-down or Bottom-up?
      • 4.4 Summary
    • Intermezzo
    • 5 Requirements in Natural Language
      • 5.1 IEEE Requirements for Requirements
      • 5.2 Between Perception and Written Record
      • 5.3 Good Requirements in Natural Language
      • 5.3.1 The Story Format
      • 5.3.2 Alternative Sentence Templates
      • 5.4 General Style Guidelines
      • 5.5 A Glossary for Data
      • 5.6 Good Definitions
      • 5.7 Writing Glossary Entries
      • 5.8 Summary
    • 6 Modeling Requirements
      • 6.1 Use Case Models
      • 6.1.1 Structuring Use Cases
      • 6.1.2 Use Cases and Natural Language: A Comparison
      • 6.1.3 Business Use Cases and Product Use Cases
      • 6.1.4 Finding Use Cases
      • 6.1.5 The Number of Use Cases
      • 6.1.6 Three Tricks for Simplification
      • 6.1.7 Describing Use Cases
      • 6.1.8 Description at the Kite Level
      • 6.1.9 Description at the Wave Level
      • 6.1.10 Description at the Fish Level
      • 6.1.11 The Style at the Wave Level
      • 6.1.12 Summary of Use Case Models
      • 6.2 Story Maps
      • 6.3 Context Maps
      • 6.4 Data Models
      • 6.4.1 A Brief Story
      • 6.4.2 Data Models as a Structured Glossary
      • 6.4.3 (Entity) Classes
      • 6.4.4 Entity Class Models
      • 6.4.5 Relationships
      • 6.4.6 Special Relationships
      • 6.4.7 Draw or Write?
      • 6.4.8 Three More Examples
      • 6.4.9 Processes and Data
      • 6.4.11 Summary of Data Models
      • 6.5 When the Rough Specification of Processes is not enough …
      • 6.6 Activity Diagrams
      • 6.6.1 Breaking Down Activities
      • 6.6.2 Swimlanes and Data
      • 6.6.3 Draw or Write?
      • 6.6.4 Where do you Stop?
      • 6.6.5 Once again: Top-down or Bottom-up?
      • 6.7 Alternative Function Models
      • 6.7.1 Data Flow Diagrams
      • 6.7.2 Event-driven process chains (EPC)
      • 6.7.3 Business Process Model and Notation (BPMN)
      • 6.7.4 Summary of More Detailed Functional Models
      • 6.8 Behavior Models
      • 6.8.1 Why another Model?
      • 6.8.2 Basics of State Models
      • 6.8.3 Actions and Activities
      • 6.8.4 Creating and Checking State Models
      • 6.8.5 Complex State Models
      • 6.8.6 An Example
      • 6.8.7 Drawing or Writing?
      • 6.8.8 State Models and Activity Diagrams
      • 6.8.9 Use Cases and State Models
      • 6.8.10 Summary of State Models
      • 6.9 Summary of Requirements Models
    • 7 Quality Requirements and Constraints
      • 7.1 What is this about?
      • 7.2 Categorization schemes
      • 7.3 Identify and Assign Quality Requirements and Constraints
      • 7.4 Examples of External Qualities
      • 7.5 Examples of Internal Qualities
      • 7.6 Examples of Constraints
      • 7.7 More Examples: Copy from Open Source**
      • 7.8 Measurability of Requirements
      • 7.9 Summary
    • 8 Documenting Requirements
      • 8.1 Why Document at all?
      • 8.2 Many Names and Multiple Documents?
      • 8.3 Requirements for Requirements Documentation
      • 8.4 Examples of the Structure of Requirements Documentation
      • 8.5 Minimum Content
      • 8.6 Summary
    • 9 Eliciting Requirements
      • 9.1 The Kano Model
      • 9.2 Types of Survey Methods
      • 9.3 What Influences the Selection?
      • 9.4 Examples of Question & Answer Techniques
      • 9.5 Examples of Observation Techniques
      • 9.6 Examples of Past-Oriented Techniques
      • 9.7 Examples of Creativity Techniques
      • 9.8 Survey Techniques and Tools
      • 9.9 Another Creativity Technique
      • 9.10 Overview (Recap)
      • 9.11 Summary
    • 10 Check and Consolidate Requirements
      • 10.1 Quality Gates
      • 10.2 Goals of the Check
      • 10.3 Types of Checks
      • 10.4 Who Should be Involved?
      • 10.5 What is Validated?
      • 10.6 Checklists for Content Checks
      • 10.7 What to Do in Case of Defects?
      • 10.8 Conflict Management
      • 10.9 Summary
    • 11 Requirements Management
      • 11.1 Definition: Requirements Management
      • 11.2 Preparatory Activities
      • 11.2.1 The Requirements Process
      • 11.2.2 Roles
      • 11.3 Ongoing Activities
      • 11.3.1 Attribute Assignment for Fequirements
      • 11.3.2 Creating Views
      • 11.3.3 Prioritization
      • 11.3.4 Baselines and Releases
      • 11.3.5 Change Management
      • 11.3.6 Traceability
      • 11.4 Summary
    • 12 Requirements Tools
      • 12.1 Categories of Tools
      • 12.2 Capabilities of Tools
      • 12.3 Strengths and Weaknesses of the Categories
      • 12.4 Tool Selection
      • 12.5 Introduction of Tools
      • 12.6 Summary
    • Literature

The Leanpub 60 Day 100% Happiness Guarantee

Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.

You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!

So, there's no reason not to click the Add to Cart button, is there?

See full terms...

Earn $8 on a $10 Purchase, and $16 on a $20 Purchase

We pay 80% royalties on purchases of $7.99 or more, and 80% royalties minus a 50 cent flat fee on purchases between $0.99 and $7.98. You earn $8 on a $10 sale, and $16 on a $20 sale. So, if we sell 5000 non-refunded copies of your book for $20, you'll earn $80,000.

(Yes, some authors have already earned much more than that on Leanpub.)

In fact, authors have earned over $14 million writing, publishing and selling on Leanpub.

Learn more about writing on Leanpub

Free Updates. DRM Free.

If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).

Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.

Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.

Learn more about Leanpub's ebook formats and where to read them

Write and Publish on Leanpub

You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!

Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.

Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.

Learn more about writing on Leanpub