software requirements

Scope doesn’t creep; understanding grows alvin February 14, 2019 - 9:20am

“Scope doesn’t creep; understanding grows.”

From Jeff Patton in User Story Mapping (something I tried to explain to people many years ago)

Business Analyst: How to write accurate software requirements

When you're working as a business analyst, the words you write are what you get paid for. Just like the author of a book, when you write software requirements, you shouldn't be loose with the words you write.

While working on a recent project, I started thinking about software requirements again, and was reminded how vague a requirement can be, even when you think it's well written. What made me think about this today was running across this performance requirement I found in an a requirements specification:

How to know when a software requirements specification process is done

Summary: This short article describes a way to know when a software requirements specification is complete by using Function Point Analysis techniques.

I've written dozens — maybe hundreds — of software requirement specifications over the years, and at one point in my career I learned an important little secret about knowing when the process of gathering requirements for a software requirements specification was really complete. Here's my secret.

A free "real world" software requirements specification

Last night I ran across a software requirements specification that I meant to share out here a long time ago, but unfortunately I never did. I created this software requirements specification for one of my customers, and they kindly gave me permission to publish this document out here (after I took out a few things specific to their business).