Posts:
20,296
Registered:
12/6/03
|
|
|
|
Requirements Process description
Posted:
Mar 6, 2000 11:00 PM
|
|
[Originally posted by dblaine]
Great book!
Although it is tough to summarize a complex process such as developing sw
requirements, we need a starting point. One purpose of such a description is
to specify the activities that must be performed, the work-products of each
activity and a rough notion of the effort to perform the activities - the
typical project manager worries.
The process description, like a sw requirements, distinguishes "what" from
"how" depending upon a person's perspective (as you noted from Davis93).
Question: Does the following summarize the requirements process? Would anyone
like to add value to this summary?
() Define product/project goal and objectives
() Identify user types (and their surrogates)
() Identify existing industry standards that describe problem domain
[e.g., for two-way radios there is a pile of FCC standards
, for radar air traffic control, there is a set of standards ]
() Develop the Product Requirements by ...
()() Determining appropriate problem frames
()() Describing information model, events, responses and interfaces
that are relevant to chosen problem frame(s)
()() Determine decomposition method(s) for each problem frame:
()()() partitioning
()()() abstraction
()()() projection
()() For each function|state|entity in problem frame, describe
()()() define attributes
()()() define constraints on design solution
()()() define preferences and expectations
() Develop the software interface specification by ...
()() Refining information model contained in requirements
()() Determing method of organizing specification contents
()()() by same external event
()()() by same Feature
...
()() Specifying the software's execution platform
()()() computer processor, memory
()()() operating system / executive; interrupt service routines
()()() messaging and tasking
()() Specifying interfaces to the software
()()() via hardware devices
()()() via software messaging or shared memory
()() For each interface, specify
()()() Events and responses in a State Transtion Diagram or Table
[] end process description
Ben, can this serve as an overall process description? Can you add value to
this?
Thanks,
--dave
|
|
Posts:
20,296
Registered:
12/6/03
|
|
|
|
Re: Requirements Process description
Posted:
Mar 9, 2000 11:00 PM
in response to:
import-bot
|
|
[Originally posted by bkovitz]
Dave Blaine asked:
> Ben, can this serve as an overall process description? Can you
> add value to this?
It looks quite good, Dave! I've never seen programmers fail to
love having this kind of information spelled out simply and
clearly.
Here are a few thoughts on adding value:
1. Planning and problem-exploration
Because different kinds of software are *so* different, I
think there needs to be an early step to plan out the process for
the specific project at hand. For example, the process for
developing a large web application is very different from the
process for developing a program to analyze musical styles, and
both would have processes very different from what would be
appropriate for software to control equipment that manufactures
tires. This is also the time to identify the areas of greatest
uncertainty and how to address them.
The planning step should follow a loose problem-definition or
problem-exploration step, in which one talks with the customer
and subject-matter experts about the thing that really interests
them, and stays away from describing the software (except
realized domains). This is the real problem-framing stage, in
which you can make the most radical sorts of adjustments in what
you're trying to do. It's also an intrinsically unstructured,
chaotic phase, in which the software developer mainly *listens*,
just trying to understand rather than fit things into any
pre-existing structure.
Neither of these steps should take very long: no more than three
weeks for problem-exploration and no more than one week for
planning (and hopefully both are much shorter). You can
certainly make adjustments to both the plan and the problem
definition later, as the software takes shape.
I think that these two stages, in some form or other, are crucial
for developing high-quality software. Without them, one runs
into the all-too-typical scenario of forcing the software into
some prefabricated or inappropriate mold. If the software
developer rushes into large commitments too early, before
exploring the problem space, the development team is blocked from
exercising its creativity on behalf of the customers, and the
users feel like they're up against a brick wall. With a
premature plan, often the team and the users feel that they can't
even consider radically different approaches which could greatly
simplify the problem.
For example, here is a very common way that things go. When you
first meet the customer, the customer wants software that
duplicates something they're already familiar with, with a few
modifications. As you explore the problem domain, staying away
from talking about the software, you quickly find out that what
the customer is *really* interested in has little to do with
software--and therefore little to do with the customer's original
statements about what they want the software to do.
A classic example is the way that early on-line library systems
simply duplicated the manual card catalog. No one wants to
retrieve cards from an on-line card catalog; people just want to
find books. That leads you to ask some very different questions
of the customer: "When and how do the books get moved around?"
"Who can tell the computer when this happens?" "What do users
have in their minds when they search for a book--i.e. what
information can they provide for a search, and how does that
information map to real books?"
Here's another example. The users might tell you that they need
the system to make certain calculations according to tax
laws--e.g. "Print out form showing whether proposed grant of
stock option would exceed stockholder's $100,000 limit." If you
dutifully take that down without exploring the reasons for it,
you'd miss some big opportunities to make the software useful.
It turns out that:
(a) As described above, the customer is just proposing
duplicating their manual processes, and the better solution is
for the software to just automatically adjust the stock grant
to conform to the $100,000 limit right when the user requests
the grant. There's no need to print the form at all. The
form was only a worksheet that they used when they performed
this calculation manually or in a spreadsheet as a supplement
to their old software. The real, problem-domain requirement
is: "Corporation never grants stock in violation of the
$100,000 limit."
(b) The limit changes every year, and different corporations
have different policies. Hard-coding the calculation just as
the customer requested it would be inefficient and
error-prone. Much better in this case to "generalize the
problem": define a workpiece problem in which the user can
define the parameters of the calculation and modify them at
will. This actually makes the programming *simpler*, because
the burden of keeping the software in sync with the details of
the problem domain is now on the customer, not the programmers
and analyst.
(Often, though, generalizing the problem makes things more
complicated, and attempts to anticipate changes in the problem
domain that just can't be anticipated. But it's almost always
worth 10 minutes or so to explore the idea. Often you find
some wonderful way to simplify things.)
Once you've understood the problem domain, *then* you're in a
position to plan software development intelligently. "What would
get some useful, visible subset of the software running as quickly as
possible?" "What tasks can people do manually for a while?"
"What are the areas that look like the biggest potential snarls
and what can we do about them?" "When are we most likely to need
to make course-corrections?"
If people pick a goal very early and stick to it, they lose the
opportunity to explore such ideas. That unstructured
problem-exploration phase is when you can let your conception of
the problem evolve very quickly and cheaply, and come up with
something much more valuable. That's when you can raise
questions like, "Do we want to print out calculation worksheets
for specific tax laws, or do we want corporations' stock grants
to always accord with ever-changing tax laws and policies?" It's
much harder to raise a question like that when you're three
months into the project, lots of money has been spent, and there
are bugs and problems and unanticipated complexity all over the
place.
2. Operating procedures and usability testing
In typical business software, once you've understood the problem
domain, it helps to organize the design of the software around
operating procedures, or "tasks". The term "use case" has become
the popular term for this. (I have no idea why, though, since
everyone understands "operating procedure" and "task", while "use
case" is terribly vague and has led to the most radically
different interpretations and confusions.)
Just as the requirements (pertaining to the problem domain) are
not going to be right the first time, your initial design for the
software is not going to be right, either. As early as possible,
it helps to get screens up in front of the users: have them try
out tasks, and watch the troubles they have. This is called
"usability testing", and it's helpful not only for streamlining
the design, but for spotting details that you missed in the
problem domain. When the users see something on-screen, they
scream things like, "Hey! There's no predecessor when someone
invokes the 801 rule!" And then you discover that you'd
completely misunderstood the 801 rule, and you have to make
changes to the software.
The earlier you can get that feedback loop going, the better.
This is something to include in the project plan, not something
to imagine that you can prevent by perfect research and planning.
(And of course the earlier you educate the customer about these
kinds of uncertainty, the better.)
The list of operating procedures is something you can create very
easily and very early (right after initial problem-exploration).
It serves wonderfully as a backbone for all sorts of development
work: usability testing, architecture and coding, database
(transaction) design, system testing, and writing on-line help or
user's manuals.
Another list you can make early and quickly is a list of windows.
Together with the list of operating procedures, this gives you a
very clear view of the scope of the project.
Of course, this doesn't apply to all kinds of software. For
example, software to make a cell phone talk to the phone system
doesn't have windows. Hence the need for that project-specific
planning phase...
3. Off-the-shelf components
Finally, in today's world, there is an enormous amount of
software already available. You very well might want to adjust
your requirements and/or interface designs to take advantage of
it.
This is particularly true for "engines" that already implement
workpiece problems. For example, there is lots of generic
workflow software out there. People have already generalized
workflow problems, so you don't need to.
Virtually any project plan these days should include some time to
research what software is already available and adjust the plan,
requirements, or interface design to incorporate it.
BK
|
|
|
Legend
|
|
Gold: 300
+
pts
|
|
Silver: 100
- 299
pts
|
|
Bronze: 25
- 99
pts
|
|
Manning Author
|
|
Manning Staff
|
|
