Functional specifications and OO
Philip Malin
Hi all.
Just recently I've been reading some articles concerning OOAD methods in
the grand scheme of things (in regards to a software project's life-
cycle). One thing that a few articles mentioned was that there is no
place for functional specifications in an OO world since OO places an
emphasis on describing a system in terms of objects and their
relationships rather than what functions need to be performed.
However, it seems to me that a natural format of the requirements
specification includes a list of what functions the system needs to
perform.
How do people here reconcile this apparent impedance mismatch between
such a requirements spec. and the analysis and design of the resulting
software? Would you ensure that the RS is not written in such a way?
Do you not believe that there is any impedance mismatch and feel
functional-based specs can be naturally embraced by an OOAD method?
----
Phil Malin, Senior Systems Engineer | | For each one who asks
Research & Technology, Melbourne IT | --+-- receives; and he who
207 Bouverie St,Carlton,Australia 3053 | | seeks finds; and to him
ph: +613-9344-9379 | | who knocks it shall be
fax: +613-9347-9473 | opened. Mat 7:8
Esben Dalsgaard
There are several different perspectives:
- seen from the programmers point of view
- seen from the costumer point of view
- seen from a math. point of view
- seen from a software architural point of view (interface, function, model)
- etc.
When writing a requirement specification you should see "function" from the
costumers point of view. In this context "costumer" has a quite broad
definition - it could be people or other software systems or even hardware -
something/someone that needs whatever the software you are about to develop
can do.
Seen from that perspective "function" can easily been described in terms of
UML. In our Software Requirement Specifications (SRS) we use Use Cases to
describe what the "costumer" want - how he/she/it interacts with the
software system - what he/she/it gets out of it - and that includes
"functions" understood from the "costumers" point of view.
A cut from our SRS is shown below:
4 Requirements
4.1 Architectural Requirements
4.1.1 Technical platform
4.1.2 Hardware
4.1.3 Development tool
4.2 General Requirements
4.3 Functional Requirements
4.3.1 Use Case Description
4.4 Interface Requirements
4.4.1 GUI
4.4.2 API
4.4.3 CLI
4.4.4 Configuration files
4.4.5 Debug information
4.4.6 Hardware interface
I can only recoment to use Use Cases in the SRS - they really gives insight
into the software that is about to be developed.
Esben Dalsgaard M.Sc.
Welding and robot control
AMROSE A/S
Forskerparken 10
5230 Odense M
Denmark
Phone 63 15 71 90
Direct 63 15 72 16
Telefax 63 15 71 61
e-mail e...@amrose.spo.sk
Esben Dalsgaard
Esben Dalsgaard
Ben Kovitz
<p...@melbourneit.com.au> wrote:
>Just recently I've been reading some articles concerning OOAD methods in
>the grand scheme of things (in regards to a software project's life-
>cycle). One thing that a few articles mentioned was that there is no
>place for functional specifications in an OO world since OO places an
>emphasis on describing a system in terms of objects and their
>relationships rather than what functions need to be performed.
>
>However, it seems to me that a natural format of the requirements
>specification includes a list of what functions the system needs to
>perform.
>
>How do people here reconcile this apparent impedance mismatch between
>such a requirements spec. and the analysis and design of the resulting
>software? Would you ensure that the RS is not written in such a way?
>Do you not believe that there is any impedance mismatch and feel
>functional-based specs can be naturally embraced by an OOAD method?
I believe that there is no impedance-mismatch whatsoever between
object-oriented programming methods and such descriptions as requirements
and specifications. The reason is that the subject matter of each is
different.
Something that might bring this into focus is a question occasionally
asked by new technical writers when they hear that a piece of software is
to be written in an object-oriented language. They sometimes ask, "How
should I write the user's manual for an object-oriented program?" The
answer, of course, is "No differently than for a program written in
hand-coded assembly language."
The reason is that the subject matter of the user's manual is not the
source code or the the ways that data flows between elements of the
program or even which parts of the program perform which computations.
Instead, a user's manual describes (some of) the behavior rules of the
program's interface, together with the responsibilities that the users
must fulfill in order for the software to perform correctly. That has
nothing to do with which methods are bundled with which classes, the
inheritance tree by which abstract method calls are mapped to concrete
program code, whether there is a top-level procedure that is divided into
subprocedures or a set of communicating implementations of abstract data
types, or indeed any other aspect of programming.
An interface design document describes all of the behavior rules of the
input/output devices that the program is to control. It states the rules
for what the computer does in response to each button-click, every error
message and when the computer is to display it, what information is to be
displayed in each field, what each item on pull-down menus does, etc. It
also describes the users' responsibilities, e.g. "When user receives
invoice, user must go to 'New Invoice' window and type in the following
data..." (This is one form of "use case".) This is true even for
non-human interfaces. There, the interface design specifies such things
as communication protocols in detail, showing each state and
state-transition, data formats, etc.
("Interface design" is my preferred name for "functional spec", since the
latter does not indicate clearly to people that the interface is to be
described down to the last detail, nor even that the interface is the
subject matter. Consequently people sometimes treat functional specs as
high-level program descriptions, not as detailed interface descriptions.)
A requirements document describes the effects that the interface is to
achieve in the problem domain and the means available in the problem
domain to achieve them. For example, if the program is supposed to
control a set of valves at a water-treatment plant, the requirements state
the rules according to which the valves are to open and close. The
subject matter of those rules is strictly the problem domain: strictly the
valves and when they're supposed to open and close. The interface design
describes the rules according to which the wires or screens or other
output devices respond to input signals from the valves. The interface
design meets the requirements if and only if it causes the effects
described in the requirements. The majority of a really useful
requirements document is actually devoted to just describing the elements
of the problem domain: the possible states of the valves, how they are
connected to the computer, the effects on the valves that different
signals from the computer cause, ways that things can go wrong and how to
detect them, etc.
A simple way to think of this is that a requirements document, an
interface design, and a program are three different descriptions, of
*different subjects*. The requirements document describes the problem
domain, the interface design describes the borderline between the problem
domain and the machine to be programmed, and the program describes a
configuration of the machine (i.e. the instructions and other data loaded
into the machine to make it behave as described in the interface design).
Because each description is of a different subject matter, there can be no
clash between them.
However, there is another conception of requirements which does indeed
have a major mismatch with object orientation. Back in the days of
structured analysis, the requirements or specification was thought of as a
high-level description of program structure, which the programmers were to
decompose into smaller and smaller program fragments until they finally
reached implemented instructions. In effect, the analyst would write some
very high-level subroutines, which the programmers were to flesh out into
lower-level subroutines. This does indeed clash with OO, in exactly the
way that you describe in your first paragraph. In OO, you define and
implement abstract data types and let them communicate; you don't break
down top-level procedures into subprocedures.
If the analyst is trying to *sketch the program* instead of *describe the
desired effects of the program*, the analyst and the programmers will
indeed be stepping on each other's toes, especially if they have radically
different conceptions of good program structure.
--
Ben Kovitz <apteryx at chisp dot net>
Author, Practical Software Requirements: A Manual of Content & Style
http://www.amazon.com/exec/obidos/ASIN/1884777597
http://www.manning.com/Kovitz
Philip Malin
On Wed, 15 Sep 1999 08:57:30 +0200, Esben Dalsgaard <e...@amrose.spo.dk>
wrote:
>I think one have to ask: What do you mean by "function".
>
>There are several different perspectives:
>- seen from the programmers point of view
>- seen from the costumer point of view
>- seen from a math. point of view
>- seen from a software architural point of view (interface, function,
> model)
>
>- etc.
Yes, that's a good point. I suppose it's the word "function" that is
tripping me up and, as Ben mentions in the next message, the way things
were done in the old days - interpreting the requirements as simply a
high-level description of the program structure.
> [snip snip: about Use Cases]
On a side note, how do you find using scenarios (use cases) when it
comes to analysis? Jacobson seems to advocate heavy reliance on them
but Meyer seems to warn against relying on them in any significant way
(this is in respect to analysis (finding the classes in your design)
rather than gaining an understanding of the user requirements).
Cheers.
JRStern
Malin) wrote:
>Do you not believe that there is any impedance mismatch and feel
>functional-based specs can be naturally embraced by an OOAD method?
Just so. And at great length, if need be.
Any OO yahoo who advances the idea that functional specs are not
needed in an OO project, has never actually delivered one to
production, bet on it.
I do know there are people who advocate what you say, that building
the objects is the whole deal. One might as well say that, once
you've delivered a truckload of well-designed bricks, that the house
is complete.
Joshua Stern
JRS...@gte.net
Philip Malin
extreme in the way I worded what some OO articles advocated - i.e. that
there is no place for functional specs in an OO world. Certainly there
needs to be some form of requirements listed before a system can be
designed and built and I don't think they would dispute this.)
Perhaps this is all a knee-jerk reaction to the other view of the
requirements spec. you mentioned, that it was to be interpreted as a
high-level view of the program structure. Which, of course, is a
problem with the interpretation of the RS rather than the concept of an
RS itself.
Your book looks really interesting (thanks for the sample chapter!).
I'll be keeping my eyes out for it (although here in Australia there
doesn't seem to be that big a selection in most bookshops).
Philip Malin
>[snip snip]
>
>Any OO yahoo who advances the idea that functional specs are not
>needed in an OO project, has never actually delivered one to
>production, bet on it.
In hindsight I think I was too extreme in my summary. I'd be surprised
if anyone would actually advocate against using a functional
spec. (although stranger things have happened in the history of the
world).
>I do know there are people who advocate what you say, that building
>the objects is the whole deal. One might as well say that, once
>you've delivered a truckload of well-designed bricks, that the house
>is complete.
Indeed.
Ben Kovitz
Malin <p...@whitedove.melbourneit.com.au> wrote:
>Thanks for the great elaboration Ben. (I think I may have been a bit
>extreme in the way I worded what some OO articles advocated - i.e. that
>there is no place for functional specs in an OO world. Certainly there
>needs to be some form of requirements listed before a system can be
>designed and built and I don't think they would dispute this.)
>
>Perhaps this is all a knee-jerk reaction to the other view of the
>requirements spec. you mentioned, that it was to be interpreted as a
>high-level view of the program structure. Which, of course, is a
>problem with the interpretation of the RS rather than the concept of an
>RS itself.
Thanks! I can't speak for the articles you've read, but I have run across
people in the day-to-work working world who oppose the writing of
functional specs. It's a real phenomenon, and the reasoning sounds very
plausible.
Perhaps another aspect of it is the "program-centric" view of software
engineering: that making software is nothing more or less than writing
code, so the only thing you can do in advance of coding is make
"high-level" descriptions of the program, such as the high-level
architecture. It's really a profound shift to step into an analyst or
UI-designer role, where the use of the software is king and the program is
merely a serf.
BTW, last weekend I picked up Donald Norman's latest book, _The Invisible
Computer_. The comments on Amazon were not entirely favorable, pointing
out that the book is poorly edited, somewhat rambly, and old hat to a lot
of people. Indeed the book seems to be a lot of thinking out loud, but
it's fascinating thinking out loud, going far beyond the ostensible topic
("information appliances"). It wasn't old hat to me, but that's probably
just my ignorance showing. One of many interesting ideas in the book is
that as a technology matures, the market becomes much more focused on
usability, and less on exciting new features. That is, people start
buying not because they want the latest, coolest gizmo, but because they
just want some help doing some task. Perhaps this is something like the
shift from a programmer's perspective to an analyst's perspective.