Getting to FRs, part 2 – Scope is not just mouth wash…

Let me reprise the words of Mr. Brooks …

“… the hardest single part of software development [remains] deciding precisely what to build.”
Fred Brooks
Author of the 1986 paper “No Silver Bullet”

The unspoken corollary to this is you have to be sure you don't build the wrong system. Knowing what and what not to build is a matter of defining Scope.

I will not claim this is a new revelation; how would we have everyones favorite problem, scope creep, without trying to define scope in the first place?

A number of scope definition methods exist; I started with the side-by-side list. One list is things that are in scope, beside it a comparable list of things that are out of scope. This is good, a good start for discussion, but you then have to get specific about what the system will and will not do. For that, the business has to select one of its processes as the object of the system's automation.

Using computers to automate a process sounds like data processing from the 60s or 70s, but it is still essentially true. Of course you don't just automate what people are doing today, Structured Analysis and Design taught us that a long time ago (although a bit heavily). Businesses have recognized that good process is critical, and so are the systems that support them.

So when a project starts, look for the main business process that will be impacted. An example I and my compatriots use is Ordering A Pizza, because almost everyone we work with has ordered a pizza.

Selecting a process is in fact the first act of defining Scope, because all other processes are now out of scope. In our example, an out of scope process can be Buy Pizza Ingredients.

If the project impacts more than one process, it is best to address them as separate efforts while determining any links between them. So not only is scope defined, you have already divided a large project into manageable pieces. This also addresses those concerns about doing all the requirements up front for a large project; working on one process means you can define all it's functional requirements in 5 to 10 days.

Yes, 5 to 10 days… More on how to do that next time.

Would you recommend this article?


Thanks for taking the time to let us know what you think of this article!
We'd love to hear your opinion about this or any other story you read in our publication.

Jim Love, Chief Content Officer, IT World Canada

Featured Download

IT World Canada in your inbox

Our experienced team of journalists and bloggers bring you engaging in-depth interviews, videos and content targeted to IT professionals and line-of-business executives.

Latest Blogs

Senior Contributor Spotlight