Chapter cover


I won’t tell you how to be a software engineer; you’ll learn that over time by doing it.

Instead, this book is about software engineering methods—ways people achieve specific objectives in software engineering—that can save your project. My hope is that after reading this book (or parts of it), you’ll feel better equipped for software engineering.

What’s Software Engineering?

The definition of software engineering we will use is:

“Systematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software.” (International Organization for Standardization et al., 2017)

The definition was agreed upon by the International Organization for Standardization (ISO), International Electrotechnical Commission (IEC), and the Institute of Electrical and Electronics Engineers (IEEE) and published in their glossary of systems and software engineering vocabulary (International Organization for Standardization, 2017). The 500+ page document is meant to be internationally applicable to the field of information technology.

What’s the Purpose of Software Engineering?

Software engineering can help people create sustainable, extensible programs that solve problems people care about. Sustainable means it’s feasible for the program to grow, exist, and be maintained. Extensible means it’s feasible to add more features.

What’s the Philosophy Behind This Book?

My beliefs about software engineering influenced how I wrote this book. Some of my strongest beliefs about software engineering are described below.

Software Engineering Is Not Black and White

Throughout the book, I explain how software engineering is a gray area of computer science. “Right” answers can be hard to find and may not be reproducible in different contexts. Software engineering as a field also keeps changing as research scientists gather new findings, engineers develop new technologies, visionaries define new methods, and the outside world changes (e.g., a pandemic happened while I was writing the first edition of this book, and that changed how software engineering teams collaborate). Whereas in programming you might ask, “Is this algorithm correct?” questions in software engineering are more like, “How does my team know this software is ready to release?” or “People keep misinterpreting my code; how do I shift it toward better understandability and maintainability?”

It’s Not Necessary to Study Every Detail of Software Engineering

I’m not going to tell you everything about software engineering because (1) what you need to know can be drastically different depending on context; (2) if I tried to, this book would be thousands of pages and possibly useless; and (3) many topics are best learned on the job. Instead, I’ll introduce a set of software engineering methods that are known to be useful across multiple contexts, give guidance on when and why to use them, and point to resources for when you want more information.

Agile Isn’t Perfect, But I Really Like It (and Other People Do, Too)

This book is geared toward Agile software development. That’s because Agile development environments have become extremely popular—and because I like Agile. It matches how I think and has been appropriate for nearly all the projects I’ve worked on. But you’re not me, and Agile isn’t the be-all and end-all, so I’m planning to incorporate more from other software process models in the future.

What’s This Book Like?

This book was written iteratively (“Do something. Do it again, but better”) and incrementally (“Do a little more”). Lots of software is written the same way.

It has eight major topics:

  1. Agile: Collaboration-oriented philosophy of creating software that values doing over comprehensive planning and documentation.
  2. Project Management and Teamwork: Working in an organized way—and with other people.
  3. Requirements: Being clear about what’s expected of the software.
  4. Unified Modeling Language Class and Sequence Diagrams: A couple types of diagrams useful for communicating how your code works (or should work).
  5. Monolith versus Microservice Architectures: Two contrasting high-level ways to organize code.
  6. Paper Prototyping: Creating a good user interface design before coding it.
  7. Inclusivity Heuristics: Guidelines for making software work well for people who are not like you.
  8. Code Smells and Refactoring: Making your code nicer to work with.

This book is short and meant to be readable.

  • Important concepts are bolded.
  • Glossary terms are italicized on their first use.
  • Relevant side notes are embedded throughout.
  • References are listed at the end of each chapter in case you need more information.

My aim is to enable you to quickly (1) determine whether each topic or method is relevant to your situation and (2) get a basic understanding of the topic or method so you can discuss it with others or have a starting point for exploring more.

What’s New in the Second Edition?

Summary of changes:

  • The text has been converted from PDF/LaTeX to HTML/CSS to improve accessibility.
  • Hosting has moved from GitHub to
  • Alternative text has been added to all images.
  • References, figures, and tables now conform to APA style.
  • More in-line citations have been incorporated throughout.
  • Renamed “Additional Resources” sections to “References” for clarity; less relevant references have been removed.
  • Introduction: Added a section on changes to the new edition; adopted ISO/IEC/IEEE standard definition of software engineering; added a section about the purpose of software engineering; removed discussion of future additions because my ideas keep changing and I don’t like making pseudo-promises; updated my contact information; updated acknowledgments.
  • Chapter 2, “Project Management and Teamwork”: Added a project network diagram figure, removed an unnecessary table to improve accessibility, and improved the summary.
  • Chapter 3, “Requirements”: Added examples for INVEST; added more quality attributes and explanations; added a “constraints” type of nonfunctional requirements; enhanced the user story, given-when-then, and Definition of Done examples; linked to more use case examples; added more information about what makes a good requirement; and improved the summary.
  • Chapter 4, “Unified Modeling Language Class and Sequence Diagrams”: Linked to more real-world diagram examples; increased the image size; removed an unnecessary table to improve accessibility; and clarified “association.”
  • Chapter 5, “Monolith versus Microservice Architectures”: Added a technical case study.
  • Chapter 7, “Inclusivity Heuristics”: Updated name of the heuristics (previously called “Cognitive Style Heuristics”); added a spectra chart for more clearly explaining persona cognitive styles; added persona reactions to examples; reduced the number of examples; rewrote the whole chapter; added more brains to the artwork.
  • Chapter 8, “Code Smells and Refactoring”: Improved summary.
  • Tweaked writing throughout.

Giving Feedback

I welcome your content requests, suggestions, and other feedback. Please email me at


Thanks to Edward Isajanyan for helping make the second edition of this textbook screen-reader-friendly. Thanks to Caius Brindescu, Raffaele De Amicis, Sèanar Letaw, and Tiffany Rockwell for their feedback, advice, and support. Thanks to family and friends for their support. Thanks to the many software engineering students and other individuals who gave feedback, including Richard Brinkley, Maximillian Davensmith, Brian Doyle, Mark De Guzman, and Jack LaBarba. Thanks to Tom Weller and Scott Ashford for their letters of support. Thanks to Ashleigh McKown, the editor of this text. Thanks to the Oregon State University Open Educational Resources (OER) Unit, especially Stefanie Buck and Mark Lane, for making the whole effort possible.

Media Attributions

Images © Lara Letaw are licensed under CC BY-NC 4.0. Figure 6.3 and Figures 7.1 through 7.9 contain assets from and are in the public domain.


International Organization for Standardization, International Electrotechnical Commission, Institute of Electrical and Electronics Engineers. (2017). Systems and software engineering—Vocabulary (ISO/IEC/IEEE Standard No. 24765:2017).



Icon for the Creative Commons Attribution-NonCommercial 4.0 International License

Handbook of Software Engineering Methods Copyright © 2024 by Lara Letaw is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License, except where otherwise noted.