Category: Reviews

Review: Software Requirements (3rd Edition) — the best light for a “dark art”

If software requirements really are a “black art,” Software Requirements (3rd Edition) is the field guide that turns on the lights. Karl Wiegers and Joy Beatty’s update for Microsoft Press remains the most practical, end‑to‑end treatment of requirements work I’ve seen—thorough enough for architects and business analysts, yet approachable enough to hand to a junior developer or data engineer without scaring them off. The 3rd edition (published August 15, 2013) is part of the Developer Best Practices series and runs a hefty 600+ pages, but it’s organized so you can dip in by problem, not just read cover to cover.

What the book actually covers (and why it matters)

Rather than treating “requirements” as just a bulleted wish list, the book walks the full lifecycle: defining business objectives and stakeholder goals, eliciting and analyzing needs, documenting them clearly, setting priorities, validating them, managing changes, and improving the process over time. The table of contents is unusually actionable: you’ll find chapters on Writing excellent requirements, Specifying data requirements, First things first: Setting requirement priorities, Risk reduction through prototyping, and a concluding set of chapters on management, change control, tools, and process improvement. This structure is why the book adapts well to many team shapes—product‑led, BA‑led, or engineering‑led.

What’s new in the 3rd edition

The refresh isn’t cosmetic. It adds new chapters and depth where modern teams need it most:

  • Data work gets first‑class treatment in “Specifying data requirements”—a big win for analytics and data engineering projects that too often treat schemas and quality rules as afterthoughts.
  • Writing high‑quality functional requirements and requirements reuse get dedicated chapters, codifying what “good” looks like and how to avoid rewriting the same specs every quarter.
  • Special project contexts have their own playbooks: agile, enhancement/replacement, packaged/COTS, outsourced, business process automation, business analytics/reporting, and embedded/real‑time.
  • The agile chapter is pragmatic: it doesn’t try to cram user stories into old‑school templates; instead it shows how to blend discovery, backlog management, and validation techniques so teams can be lean without being sloppy.

Why developers and data engineers should read it

Requirements are a “dark art” every developer and data engineer needs to understand—and this edition meets that moment. Two examples:

  • From user need to testable behavior. The chapters on documenting, visualizing, and validating requirements keep the focus on clarity and testability, which shortens the path to code and automated checks. If you’re used to triaging ambiguous tickets, the “writing excellent requirements” and “validating the requirements” material pays for itself quickly.
  • Data‑heavy projects. Between “Specifying data requirements” and the dedicated “Business analytics projects”chapter, it treats data models, quality attributes, lineage, and reporting behaviors as first‑class concerns—ideal guidance for modern lakehouse/warehouse and ML‑adjacent work where “the requirement” is as much about datasets, SLAs, and semantics as UI.

The strengths that make it gift‑worthy

  • Field‑tested checklists and patterns. You don’t only get principles; you get templates, self‑assessments, and a troubleshooting guide you can use in the next backlog grooming or discovery session. Those appendices—Current requirements practice self‑assessment, Requirements troubleshooting guide, and Sample requirements documents—are pure leverage.
  • Balanced tone. It respects both plan‑driven and agile contexts. The authors show how to scale the rigor up or down without lapsing into ceremony for ceremony’s sake.
  • Breadth without hand‑waving. The “special project” chapters keep you from reinventing the wheel when constraints change (enhancement vs. greenfield, packaged vs. custom, embedded vs. information systems).

A few quibbles (so you know what you’re getting)

  • Document‑first bias in spots. Some examples still assume a document‑centric flow. That’s not wrong, just heavier than many teams prefer. Pairing the guidance with story mapping, lightweight specs, and executable examples keeps it nimble.
  • Not a substitute for domain discovery. It teaches you how to discover and specify; it won’t do your product thinking for you. You still have to bring domain sense and stakeholder time to the table.

How to use the book (a practical reading path)

For developers or data engineers who want the fastest return:

  1. Ch. 1–4 for the foundations and roles.
  2. Ch. 10–12 & 14 to document clearly (text + visuals + nonfunctional qualities).
  3. Ch. 16–18 to prioritize and validate before you over‑invest.
  4. Ch. 13 & 25 if you’re in analytics/data engineering.
  5. Ch. 20 for agile projects. 
  6. Skim the self‑assessment and troubleshooting guide to identify your team’s weakest links and fix those first.

Bottom line

On the same shelf as Code Complete, Framework Design Guidelines, The C++ Programming Language, and K&R, Software Requirements (3rd Edition) earns its keep by turning fuzzy intent into testable, buildable, and maintainable software behavior—without pretending there’s only one right way to do it. If you mentor younger engineers, this is an easy book to pass along: it’s comprehensive, concrete, and relentlessly practical. For the “dark art” of requirements, this is the light you want.

CITE 2022 – Conference Review

As some of you may know, I made the jump from K-12 to private-sector consulting in late July. It has been an incredible transition for me and one that I hope will rejuvenate this blog (especially considering how long my last attempt lasted). I do plan to broaden the topics that I talk about, but I will still remember where I came from, especially regarding the very academic world of Learning Analytics. This post can be considered a bit transitionary and is a review of the 2022 CITE Annual Conference in Long Beach.

The 2022 CITE (California Information Technology in Education) conference was a different one for me. For the first time ever, I was attending not as an educational member but as an attendee. It took more than a little adjustment, but I think that I learned as much, and as much that’s immediately relevant to me as I did when I was focused on K-12. It really is amazing how much the CITE team does to focus the conference not simply on technology but on leading in a technological world.

The first thing that I want to do is congratulate the members of CTO Mentor Cohort 16! I hadn’t realized how many of you I knew, and I’m sure that all of you are going to be leaders in CiTE in the coming years. Speaking of CTO Mentor, I had a great time catching up with my own Cohort 15! I continue to recommend this program to anyone in or reaching for a position of senior technology leadership in K-12 education. There’s no better way to acquire a firm grounding in all the different skills a technology leader needs. I know that I use the skills I gained every day, even now that I’ve left K-12.

As for the conference itself, I felt that the content was the best that CITE’s had in years. There was a diverse range of sessions aimed at technologists of all levels. I particularly enjoyed Ben Markley’s improvement science session and Brianne Ford and Erick Steelman’s presentation on board presentations (also great advice for any leadership presentation). I think that IT organizations, in general, are excellent places to leverage improvement science (especially organizations that embrace the Agile mindset), and it is great to see more people talking about it. I think I’ll be adapting some of Ben’s protocols for my own use.

CITE has a history of tremendous keynotes, ranging from Kate the Chemist to Steve Wozniak, and this year was no exception. Danielle Feinberg, the visual effects supervisor from Turning Red, spoke about resiliency in the face of challenges, overcoming adversity, and her own journey from tech, to art, and back. It was a moving speech, marred only by an unexpected interruption of a fire alarm, which Danielle handled perfectly. I regret not being able to attend John Sileo’s keynote, but I heard that it was great as well. Finally, at least on the subject of the general sessions, Antonio Romayor’s MCing of the closing raffle was amazing, and I think that he may have another calling in comedy.

Anytime you attend a conference, especially one for a community as close-knit as the K-12 technology community, the conversations between the sessions are going to be at least as important and enlightening as the sessions themselves, and this year at CITE was no exception. I’ve been thinking a lot about data strategy, data leadership, and data governance lately, and especially how they intersect with technology and organizational leadership. In addition to talking about my new chapter, several conversations really helped me focus on these ideas and realize that over the next few years, we’re going to be meeting an inflection point with data strategy and data governance. They aren’t going to be “nice to haves” anymore. The reason for this is that citizen and self-service analytics tools are being released at a remarkable pace, and they’ve reached the point that anyone can be a data analyst, so we (as technology leaders) are going to have to accept and support that, rather than attempting to hold back the tide with a bucket.

Of course, no conference review would be complete without mentioning swag, and here again CITE has been ahead of the trend toward less swag and – for lack of a better phrase – better swag. The conference bag was minimal but reusable (as it has been for the last several years, a small “grocery” type bag), and the “conference swag item” was a very nice heavy-duty laptop sleeve that I can see myself using. As for the vendors, some have really upped their game, with INVZBL having what is probably the best piece of swag that I’ve ever seen and something guaranteed to be either used or passed on to someone else. It was a combination hand sanitizer bottle and dog bag dispenser, with the clip being strong enough to survive on a leash!