Posts:
20,296
Registered:
12/6/03
|
|
|
|
Problem Framing
Posted:
Sep 30, 1999 11:00 PM
|
|
[Originally posted by shawnc]
Dear Ben
I now have quite a dogged-eared copy of PSR and I'm thoroughly enjoying it.
I'm still not totally clear, however, about problems frames. The problem I'm
addressing goes like this:
My organisation is responsible for regulating the radio frequency spectrum in
Australia. We issue licences to organisations to use spectrum space. Spectrum
space is 3 dimensional - area, and frequency bandwidth. We need to know who
has what licence, be able to charge for these licences on an annual basis but
probably more importantly we need to know what space is available for future
sales. Our aim is to increase competition and increase the effective use of
spectrum space.
I know I have an information problem and there is a connection problem in
terms of users entering the information about the frequencies and areas. But
do I have a workpiece problem in the sense that spectrum space is created in
the system and we manage these spaces inside the system?
I would welcome your thoughts and would greatly appreciate it if you can give
me an idea of what the frame diagram would look like I.
Regards
Shawn Callahan
|
|
Posts:
20,296
Registered:
12/6/03
|
|
|
|
Re: Problem Framing
Posted:
Oct 17, 1999 11:00 PM
in response to:
import-bot
|
|
[Originally posted by bkovitz]
Shawn Callahan wrote:
> My organisation is responsible for regulating the radio frequency
> spectrum in Australia. We issue licences to organisations to use
> spectrum space. Spectrum space is 3 dimensional - area, and
> frequency bandwidth. We need to know who has what licence, be
> able to charge for these licences on an annual basis but probably
> more importantly we need to know what space is available for
> future sales. Our aim is to increase competition and increase
> the effective use of spectrum space.
>
> I know I have an information problem and there is a connection
> problem in terms of users entering the information about the
> frequencies and areas. But do I have a workpiece problem in the
> sense that spectrum space is created in the system and we manage
> these spaces inside the system?
Sounds like you've pegged it! Regarding the question of whether
"ownership of spectrum space" is a realized domain, here's the
question I'd ask if I were doing the analysis: do you want the
system to *decide* which parts of the spectrum space to grant to
new applicants, or do you want the system only to *inform* people
of which parts of the spectrum space are available?
An analogous example is a scheduler for conference rooms. The
main responsibility of the scheduler is to *decide* who can have
which room and when, according to certain rules, like "first
come, first served." The table of who has what room at what
times is a purely conceptual construction, which the system has
to embody within itself--hence, in a realized domain, not a
domain that the system has to connect to.
BTW, I think that whenever classification is difficult, it's
probably unimportant. The only reason for classifying things
under one category or another is because we want to take
different actions depending on the facts that lead to one
classification for another. If we have all the facts, and we
know what to do, but we're still not sure which category is
appropriate, then the distinctions made by that system of
categories probably aren't of much consequence in that situation.
For purposes of requirements engineering, the important
difference that I think different problem types relate to is that
they lead you to ask different questions. That's all I'm
shooting for: to help people ask some good questions. As long as
you ask the questions whose answers will enable you to define a
really useful system, then it doesn't matter how you classify a
given problem.
So, with that in mind, here are some thoughts on good questions
to ask, which relate to the question of whether the
spectrum-allocation domain is internal to the system (as in a
workpiece-like problem) or external to the system (as in an
information problem).
If the responsibility of the system is to make decisions about
which segments of the spectrum space to grant to new applicants,
then you have two questions to ask next. (1) What are the rules
according to which the system should make these decisions? (2)
What types of acts do you want people to be able to do with the
system, that would feed into those rules? A likely such act is
"Request a segment of spectrum space." A simple rule might be,
"Whoever first submitted a valid request for a given segment gets
that segment." (Another such act might be, "Request to override
an allocation." And the corresponding rule might be, "Only a
member of the communications commission may override an
allocation.")
The route of "the system makes the decisions" implies that the
acts that you define must have some legally recognized
significance: people must agree that they will be bound by the
rules that you define. That is, people must agree that whatever
interface behavior you invent to implement "request computer to
grant segment of spectrum space" will have legally binding
consequences (as defined by the spectrum-allocation rules).
(Making a bid on eBay is an example of one of these acts with
legally binding consequences.)
On the other hand, if the responsibility for making these
decisions is something you want to leave with the government, the
system's job might only be to inform users of current and
proposed allocations of the spectrum. In this case, there are
different questions to ask. (1) What are all the events that
change the allocation of spectrum space? (2) How can the system
find out when these events occur, along with all the pertinent
information associated with them? If the people who make the
allocation decisions are known to always or usually follow
certain rules, that's good information to gather, too, since you
can exploit that to detect data-entry errors.
A third alternative is that perhaps you don't want to give the
system the responsibility for making the decisions about what
spectrum space to grant to whom, but you want the system to serve
as an aid to the people who do make those decisions. People
could type a request into the system, and the system could
propose a possible way to satisfy the request, or perhaps let a
user view a variety of "what-if" scenarios. In this case, you
have a classic workpiece problem: the spectrum-space domain is
purely fictitious, embodied only in the computer. The software
provides a set of operations that users can perform on this
fictitious world in order to see the results.
You could also call this a sort of transformation problem, in
that the system's job is to perform calculations on data entered
by the user. Indeed small transformation problems are a
subproblem of almost every software problem. But notice that the
main questions to ask are, "What fictitious entities do you want
me to create in the computer, and what operations and/or
calculations would you like to be able to perform on them?"
Thinking of the problem as "Build me a little computerized
blackboard for exploring consequences of possible ways to satisfy
requests for spectrum space" seems to lead to all sorts of
fruitful questions. Eventually, you should wind up with answers
of a sort that you can give to a programmer, tester, and UI
designer to implement, like "An allocation has attributes X, Y,
and Z. The possible values of X are..." That's when the
requirements are really done.
BTW, for a long time now, I've been trying to come up with a
really good *first* question to ask during analysis--a question
that you can ask even before you know anything about the problem
domain. I think I've got it: "What benefit do you want to make
the software responsible for achieving?" That seems to get the
customer focused on the most important effects to be achieved in
the problem domain--informing people of something, making things
happening according to certain rules, providing the results of
certain calculations, etc.
Once you've got that main problem identified, then you can start
addressing all the subproblems involved in bringing it about,
like what services the data-entry subsystem will need to provide,
how to address the inevitable errors that will occur during data
entry, what existing systems provide what existing information,
how the system should behave during those inevitable times when
the legacy systems go down, etc.
How would your customer answer this question? "We want to see
the consequences of different ways of satisfying a request for
spectrum space before we commit to a decision"? "We want
allocation of spectrum space to be automated, so that people can
request it and be granted it without human intervention"? "We
want to make a map of allocated spectrum space available to
people via the web, and to update it as allocations change?" "We
want to billing for spectrum space to occur automatically"?
Naturally, the answer isn't limited to any of these, nor even to
just one of these.
BK
P.S. Sorry to take so long to reply. These last couple weeks
I've mostly been out of town and/or furiously busy on a project.
|
|
|
Legend
|
|
Gold: 300
+
pts
|
|
Silver: 100
- 299
pts
|
|
Bronze: 25
- 99
pts
|
|
Manning Author
|
|
Manning Staff
|
|
