The Community Blog for Business Analysts

David Wright
David Wright

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.

This entry was published on Aug 24, 2011 / David Wright. Posted in Business Analysis. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  3 members liked this article

Related Articles


Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.


Copyright 2006-2024 by Modern Analyst Media LLC