<![CDATA[p KnowHow KnowWhere KnowWhat]]> http://blog.paran.com/blueyellow ko <![CDATA[er sample]]> http://blog.paran.com/blueyellow/25781812 쇼핑몰.ER1

학사관리.er1

]]> Wed, 30 Apr 2008 16:43:19 +0900 <![CDATA[2008년 LG cns 상반기 경력 사원 채용]]> http://blog.paran.com/blueyellow/25781631 lg cns 경력채용.docx]]> Wed, 30 Apr 2008 16:32:04 +0900 <![CDATA[동국대학교 프로젝트 계획서]]> http://blog.paran.com/blueyellow/25781519 동국대학교 프로젝트 계획서

프로젝트계획서(ver 1[1].0).hwp

]]> Wed, 30 Apr 2008 16:25:38 +0900 <![CDATA[소프트공학 - requirement]]> http://blog.paran.com/blueyellow/25781410 Software Requirements: A Tutorial∗ RA2_Faulk_Req_Tut.pdf
Stuart R. Faulk
∗ Published in: Software Requirements Engineering 2nd Edition, R. Thayer. M. Dorfman, Eds., IEEE Computer Society press, 1997
“The hardest single part of building a software system
is deciding precisely what to build. No other part of the
conceptual work is as difficult as establishing the
detailed technical requirements...No other part of the
work so cripples the resulting system if done wrong. No
other part is as difficult to rectify later.” [Brooks 87]
1.Introduction
Deciding precisely what to build and documenting the
results is the goal of the requirements phase of software
development. For many developers of large, complex
software systems, requirements are their biggest
software engineering problem. While there is
considerable disagreement on how to solve the
problem, few would disagree with Brooks’ assessment
that no other part of a development is as difficult to do
well or as disastrous in result when done poorly. The
purpose of this tutorial is to help the reader understand
why the apparently simple notion of “deciding what to
build” is so difficult in practice, where the state of the
art does and does not address these difficulties, and
what hope we have for doing better in the future.
This paper does not survey the literature but seeks to
provide the reader with an understanding of the
underlying issues. There are currently many more
approaches to requirements than one can cover in a
short paper. This diversity is the product of different
views about which of the many problems in
requirements is pivotal and different assumptions about
the desirable characteristics of a solution. This paper
attempts to impart a basic understanding of the many
facets of the requirements problem and the tradeoffs
involved in attempting a solution. Thus forearmed, the
reader may make his own assessment of the claims of
different requirements methods and their likely
effectiveness in addressing his particular needs.
We begin with basic terminology and some historical
data on the requirements problem. We examine the
goals of the requirements phase and the problems that
can arise in attempting those goals. As in Brooks’s
article [Brooks 87], much of the discussion is
motivated by the distinction between the difficulties
inherent in what one is trying to accomplish (the
“essential” difficulties) and those one creates through
inadequate practice (“accidental” difficulties). We
discuss how a disciplined software engineering process
helps address many of the accidental difficulties and
why the focus of such a disciplined process is on
producing a written specification of the detailed
technical requirements. We examine current technical
approaches to requirements in terms of the specific
problems each approach seeks to address. Finally, we
examine technical trends and discuss where significant
advances are likely to occur in the future.
software
requirements
software
design
system
requirements
system design
software
requirements
hardware
requirements
software
design
hardware
design
Figure2: Development paths (a) software(b) systems
(a) (b)
2
2.Requirements and the Software Life
Cycle
A variety of software life–cycle models have been
proposed with an equal variety of terminology. Davis
[Davis 88] provides a good summary. While differing
in the detailed decomposition of the steps (e.g.,
prototyping models) or in the surrounding management
and control structure (e.g., to manage risk), there is
general agreement on the core elements of the model.
Figure 1 [Davis 93] is a version of the common model
that illustrates the relationship between the software
development stages and the related testing and
acceptance phases
When software is created in the context of a larger
hardware and software system, system requirements are
defined first followed by system design. System design
includes decisions about which parts of the system
requirements will be allocated to hardware and which
to software. For software–only systems, the life cycle
model begins with analysis of the software
requirements. From this point on, the role of software
requirements in the development model is the same
whether or not the software is part of a larger system, as
shown in Figure 2 [Davis 93]. For this reason, the
remainder of our discussion does not distinguish
whether or not software is developed as part of a larger
system. For an overview of system versus software
issues, the reader is referred to Dorfman and Thayer’s
survey [Thayer 90].
In a large system development, the software
requirements specification may play a variety of roles:
• For customers, the requirements typically
document what should be delivered and may
provide the contractual basis for the
development.
• For managers it may provide the basis for
scheduling and a yardstick for measuring
progress.
• For the software designers, it may provide the
“design–to” specification.
• For coders it defines the range of acceptable
implementations and is the final authority on
the outputs that must be produced.
• For quality assurance personnel, it is the basis
for validation, test planning and verification.
The requirements may also used by such diverse groups
as marketing and governmental regulators.
It is common practice (e.g., see [Thayer 90]) to classify
software requirements as “functional” or “nonfunctional.”
While definitions vary somewhat in detail,
“functional” typically refers to requirements defining
the acceptable mappings between system inputs values
and corresponding output values. “Non-functional”
then refers to all other constraints including, but not
softw are
requirements
p reliminary
design
detailed
design
coding
unit test
p lanning
integration
test
p lanning
s y stem
testing
integration
testing
deliv ery
p roduction
dep loy ment
unit
testing
softw are
s y stem test
p lanning
maintenance
and
enhancement
Figure 1: A Software Life Cycle
3
limited to, performance, dependability, maintainability,
reusability, and safety.
While widely used, the classification of requirements as
”functional” and ”non-functional” is confusing in its
terminology and of little help in understanding common
properties of different kinds of requirements. The word
“function” is one of the most overloaded in computer
science and its only rigorous meaning, that of a
mathematical function, is not what is meant here. The
classification of requirements as functional and non–
functional offers little help in understanding common
attributes of different types of requirements since it
partitions classes of requirements with markedly similar
qualities (e.g., output values and output deadlines)
while grouping others that have common only what
they are not (e.g., output deadlines and maintainability
goals).
A more useful distinction is between what can be
described as “behavioral requirements” and
“developmental quality attributes” with the following
definitions [Clements 95]:
• Behavioral requirements - Behavioral
requirements include any and all information
necessary to determine if the run–time behavior
of a given implementation is acceptable. The
behavioral requirements define all constraints
on the system outputs (e.g., value, accuracy,
timing) and resulting system state for all
possible inputs and current system state. By
this definition, security, safety, performance,
timing, and fault–tolerance are all behavioral
requirements.
• Developmental quality attributes -
Developmental quality attributes include any
constraints on the attributes of the system’s
static construction. These include properties
like testability, changeability, maintainability,
and reusability.
Behavioral requirements have in common that they are
properties of the run–time behavior of the system and
can (at least in principle) be validated objectively by
observing the behavior of the running system,
independent of its method of implementation. In
contrast, developmental quality attributes are properties
of the system‘s static structures (e.g., modularization)
or representation. Developmental quality attributes
have in common that they are functions of the
development process and methods of construction.
Assessment of developmental quality attributes are
necessarily relativistic - for example, we do not say that
a design is or is not maintainable but that one design is
more maintainable than another.
3.A Big Problem
Requirements problems are persistent, pervasive, and
costly. Evidence is most readily available for the large
software systems developed for the U.S. Government
since the results are a matter of public record. As soon
as software became a significant part of such systems,
developers identified requirements as a major source of
problems. For example, developers of the early
Ballistic Missile Defense System noted that:
In nearly every software project that fails to
meet performance and cost goals, requirements
inadequacies play a major and expensive role
in project failure [Alford 79].
Nor has the problem mitigated over the intervening
years. A recent study of problems in mission critical
defense systems identified requirements as a major
problem source in two thirds of the systems examined
[GAO 92]. This is consistent with results of a survey of
large aerospace firms that identified requirements as the
most critical software development problem [Faulk 92].
Likewise, studies by Lutz [Lutz 92] identified
functional and interface requirements as the major
source of safety related software errors in NASA’s
Voyager and Galileo spacecraft.
Results of industry studies in the 1970’s described by
Boehm [Boehm 81], and since replicated a number of
times, showed that requirements errors are the most
costly. These studies all produced the same basic result:
the earlier in the development process an error occurs
and the later the error is detected, the more expensive it
is to correct. Moreover, the relative cost rises quickly.
As shown in Figure 3, an error that costs a dollar to fix
in the requirements phase may cost 100 to 200 dollars
to fix if it is not corrected until the system is fielded or
in the maintenance phase.
Stage Relative Repair Cost
Requirements 1-2
Design ˜ 5
Coding ˜ 10
Unit test ˜ 20
System test ˜ 50
Maintenance ˜ 200
Figure 3: Relative cost to repair a software error in
different stages
4
The costs of such failures can be enormous. For
example, the 1992 GAO report notes that one system,
the Cheyenne Mountain Upgrade, will be delivered
eight years late, exceed budget by $600 million, and
have less capability than originally planned, largely due
to requirements-related problems. Prior GAO reports
[GAO 79] suggest that such problems are the norm
rather than the exception. While data from private
industry is less readily available, there is little reason to
believe that the situation is significantly different.
In spite of presumed advances in software engineering
methodology and tool support, the requirements
problem has not diminished. This does not mean that
the apparent progress in software engineering is
illusory. While the features of the problem have not
changed, the applications have grown significantly in
capability, scale, and complexity. A reasonable
conclusion is that the growing ambitiousness of our
software systems has outpaced the gains in
requirements technology, at least as such technology is
applied in practice.
4.Why are Requirements Hard?
It is generally agreed that the goal of the requirements
phase is to establish and specify precisely what the
software must do without describing how to do it. So
simple seems this basic intent that it is not at all evident
why it is so difficult to accomplish in practice. If what
we want to accomplish is so clear, why is it so hard? To
understand this, we must examine more closely the
goals of the requirements phase, where errors originate,
and why the nature of the task leads to some inherent
difficulties.
Most authors agree in principle that requirements
should specify “what” rather than “how.” In other
words, the goal of requirements is to understand and
specify the problem to be solved rather than the
solution. For example, the requirements for an
automated teller system should talk about customer
accounts, deposits, and withdrawals rather than the
software algorithms and data structures. The most basic
reason for this is that a specification in terms of the
problem captures the actual requirements without over
constraining the subsequent design or implementation.
Further, solutions in software terms are typically more
complex, more difficult to change, and harder to
understand (particularly for the customer) than a
specification of the problem.
Unfortunately, distinguishing “what” from “how” itself
represents a dilemma. As Davis [Davis 88], among
others, points out, the distinction between what and
how is necessarily a function of perspective. A
specification at any chosen level of system
decomposition can be viewed as describing the “what”
for the next level. Thus customer needs may define the
“what” and the decomposition into hardware and
software the corresponding “how”. Subsequently, the
behavioral requirements allocated to a software
components define its “what,” the software design, the
“how, and so on. The upshot is that requirements
cannot be effectively discussed at all without prior
agreement on which system one is talking about and at
what level of decomposition. One must agree on what
constitutes the problem space and what constitutes the
solution space - the analysis and specification of
requirements then properly belongs in the problem
space.
In discussing requirements problems one must also
distinguish the development of large, complex systems
from smaller efforts (e.g., developments by a single or
small team of programmers). Large system
developments are multi–person efforts. They are
developed by teams of tens to thousands of
programmers. The programmers work in the context of
an organization typically including management,
systems engineering, marketing, accounting, and
quality assurance. The organization itself must operate
in the context of outside concerns also interested in the
software product, including the customer, regulatory
agencies, and suppliers.
Even where only one system is intended, large systems
are inevitably multi–version as well. As the software is
being developed, tested, and even fielded, it evolves.
Customers understand better what they want,
developers understand better what they can and cannot
do within the constraints of cost and schedule, and
circumstances surrounding development change. The
results are changes in the software requirements and,
ultimately, the software itself. In effect, several
versions of a given program are produced, if only
incrementally. Such unplanned changes occur in
addition to the expected variations of planned
improvements.
The multi–person, multi–version nature of large system
development introduces problems that are both
quantitatively and qualitatively different from those
found in smaller developments. For example, scale
introduces the need for administration and control
functions with the attendant management issues that do
not exist on small projects. The quantitative effects of
increased complexity in communication when the
number of workers rises are well documented by
Brooks [Brooks 75]. In the following discussion, it is
this large system development context we will assume
since that is the one in which the worst problems occur
and where the most help is needed.
5
Given the context of multi–person, multi–version
development, our basic goal of specifying what the
software must do can be decomposed into the following
subgoals:
1. Understand precisely what is required of the
software.
2. Communicate the understanding of what is
required to all of the parties involved in the
development.
3. Provide a means for controlling the production
to ensure that the final system satisfies the
requirements (including managing the effects of
changes).
It follows that the source of most requirements errors is
in the failure to adequately accomplish one of these
goals, i.e.:
1. The developers failed to understand what was
required of the software by the customer, end user,
or other parties with a stake in the final product.
2. The developers did not completely and
precisely capture the requirements or subsequently
communicate the requirements effectively to other
parties involved in the development.
3. The developers did not effectively manage the
effects of changing requirements or ensure the
conformance of down–stream development steps
including design, code, integration, test, or
maintenance to the system requirements.
The end result of such failures is a software system that
does not perform as desired or expected, a development
that exceeds budget and schedule or, all too frequently,
failure to deliver any working software at all.
4.1 Essential Difficulties
Even our more detailed goals appear reasonably
straightforward, why then do so many development
efforts fail to achieve them? The short answer is that
the mutual satisfaction of these goals, in practice, is
inherently difficult. To understand why, it is useful to
reflect on some points raised by Brooks [Brooks 87]
on why software engineering is hard and on the
distinction he makes between essential difficulties -
those inherent in the problem, and the accidental
difficulties - those introduced through imperfect
practice. For though requirements are inherently
difficult, there is no doubt that these difficulties are
many times multiplied by the inadequacies of current
practice.
The following essential difficulties attend each (in
some cases all) of the requirements goals:
• Comprehension. People do not know what they
want. This does not mean that people do not
have a general idea of what the software is for.
Rather, they do not begin with a precise and
detailed understanding of what functions
belong in the software, what the output must be
for every possible input, how long each
operation should take, how one decision will
affect another, and so on. Indeed, unless the
new system is simply a reconstruction of an old
one, such a detailed understanding at the outset
is unachievable. Many decisions about the
system behavior will depend on other decisions
yet unmade and expectations will change as the
problem (and attendant costs of alternative
solutions) is better understood. Nonetheless, it
is a precise and richly detailed understanding of
expected behavior that is needed to create
effective designs and develop correct code.
• Communication. Software requirements are
difficult to communicate effectively. As
Brooks points out, the conceptual structures of
software systems are complex, arbitrary, and
difficult to visualize. The large software
systems we are now building are among the
most complex structures ever attempted. That
complexity is arbitrary in the sense that it is an
artifact of people’s decisions and prior
construction rather than a reflection of
fundamental properties (as, for example, in the
case of of physical laws). To make matters
worse, many of the conceptual structures in
software have no readily comprehensible
physical analogue so they are difficult to
visualize.
In practice, comprehension suffers under all of
these constraints. We work best with regular,
predictable structures, can comprehend only a
very limited amount of information at one time,
and understand large amounts of information
best when we can visualize it. Thus the task of
capturing and conveying software requirements
is inherently difficult.
The inherent difficulty of communication is
compounded by the diversity of purposes and
audiences for a requirements specification.
Ideally a technical specification is written for a
particular audience. The brevity and
comprehensibility of the document depend on
assumptions about common technical
background and use of language. Such
6
commonality typically does not hold for the
many diverse groups (e.g., customers, systems
engineers, managers) that must use a software
requirements specification.
• Control. Inherent difficulties attend control of
software development as well. The arbitrary
and invisible nature of software makes it
difficult to anticipate which requirements will
be met easily and which will decimate the
project’s budget and schedule if, indeed, they
can be fulfilled at all. The low fidelity of
software planning has become a cliche yet the
requirements are often the best available basis
for planning or for tracking to a plan.
This situation is made incalculably worse by by
software’s inherent malleability. Of all the
problems bedeviling software mangers, few
evoke such passion as the difficulties of dealing
with frequent and arbitrary changes to
requirements. For most systems, such changes
remain a fact of life even after delivery. The
continuous changes make it difficult to develop
stable specifications, plan effectively, or
control cost and schedule. For many industrial
developers, change management is the most
critical problem in requirements.
• Inseparable concerns. In seeking solutions to
the forgoing problems, we are faced with the
additional difficulty that the issues cannot
easily be separated and dealt with piecemeal.
For example, developers have attempted to
address the problem of changing requirements
by baselining and freezing requirements before
design begins. This proves impractical because
of the comprehension problem - the customer
may not fully know what he wants until he sees
it. Similarly, the diversity of purposes and
audiences is often addressed by writing a
different specification for each. Thus there may
be a system specification, a set of requirements
delivered to customer, a distinct set of technical
requirements written for the internal
consumption of the software developers, and so
on. However, this solution vastly increases the
complexity, provides an open avenue for
inconsistencies, and multiplies the difficulties
of managing changes.
These issues represent only a sample of the
inherent dependencies between different facets
of the requirements problem. The many distinct
parties with an interest in a system’s
requirements, the many different roles the
requirements play, and the interlocking nature
of software’s conceptual structures, all
introduce dependencies between concerns and
impose conflicting constraints on any potential
solution.
The implications are twofold. First we are
constrained in the application of our most
effective strategy for dealing with complex
problems - divide and conquer. If a problem is
considered in isolation, the solution is likely to
aggravate other difficulties. Effective solutions
to most requirements difficulties must
simultaneously address more than one problem.
Second, developing practical solutions requires
making difficult tradeoffs. Where different
problems have conflicting constraints,
compromises must be made. Because the
tradeoffs result in different gains or losses to
the different parties involved, effective
compromises require negotiation. These issues
are considered in more detail when we discuss
the properties of a good requirements
specification.
4.2 Accidental Difficulties
While there is no doubt that software requirements are
inherently difficult to do well, there is equally no doubt
that common practice unnecessarily exacerbates the
difficulty. We use the term “accidental” in contrast to
“essential,” not to imply that the difficulties arise by
chance but that they are the product of common failings
in management, elicitation, specification, or use of
requirements. It is these failings that are most easily
addressed by improved practice.
• Written as an afterthought. It remains common
practice that requirements documentation is
developed only after the software has been
written. For many projects, the temptation to
rush into implementation before the
requirements are adequately understood proves
irresistible. This is understandable. Developers
often feel like they are not really doing
anything when they are not writing code;
managers are concerned about schedule when
there is no visible progress on the
implementation. Then too, the intangible nature
of the product mitigates toward early
implementation. Developing the system is an
obvious way to understand better what is
needed and make visible the actual behavior of
the product. The result is that requirements
specifications are written as an afterthought (if
at all). They are not created to guide the
7
developers and testers but treated as a
necessary evil to satisfy contractual demands.
Such after–the–fact documentation inevitably
violates the principle of defining what the
system must do rather than the how since it is a
specification of the code as written. It is
produced after the fact so it is not planned or
managed as an essential part of the
development but is thrown together. In fact, it
is not even available in time to guide
implementation or manage development.
• Confused in purpose. Because there are so
many potential audiences for a requirements
specification, with different points of view, the
exact purpose of the document becomes
confused. An early version is used to sell the
product to the customer so it includes
marketing hype extoling the product’s virtues.
It is the only documentation of what the system
does so it provides introductory, explanatory,
and overview material. It is a contractual
document so it is intentionally imprecise to
allow the developer latitude in the delivered
product or the customer latitude in making no–
cost changes. It is the vehicle for
communicating decisions about software
details to designers and coders so it
incorporates design and implementation. The
result is a document in which it is unclear
which statements represent real requirements
and which are more properly allocated to
marketing, design, or other documentation. It is
a document that attempts to be everything to
everyone and ultimately serves no one well.
• Not designed to be useful. Often in the rush to
implementation little effort is expended on
requirements. The requirements specification is
not expected to be useful and, indeed, this turns
out to be a self–fulfilling prophecy. Because
the document is not expected to be useful little
effort is expended on designing it, writing it,
checking it, or managing its creation and
evolution. The most obvious result is poor
organization. The specification is written in
English prose and follows the author’s stream
of consciousness or the order of execution
[Heninger 80].
The resulting document is ineffective as a
technical reference. It is unclear which
statements represent actual requirements. It is
unclear where to put or find particular
requirements. There is no effective procedure
for ensuring that the specification is consistent
or complete. The is no systematic way to
manage requirements changes. The
specification is difficult to use and difficult to
maintain. It quickly becomes out of date and
loses whatever usefulness it might originally
have had.
• Lacks essential properties. Lack of
forethought, confusion of purpose, or lack of
careful design and execution all lead to
requirements that lack properties critical to
good technical specifications. The
requirements, if documented at all, are
redundant, inconsistent, incomplete, imprecise,
and inaccurate.
Where the essential difficulties are inherent in the
problem, the accidental difficulties result from a failure
to gain or maintain intellectual control over what is to
be built. While the presence of the essential difficulties
means that there can be no “silver bullet” that will
suddenly render requirements easy, we can remove at
least the accidental difficulties through a well though
out, systematic, and disciplined development process.
Such a disciplined process then provides a stable
foundation for attacking the essential difficulties.
5. Role of a Disciplined Approach
The application of discipline in analyzing and
specifying software requirements can address the
accidental difficulties. While there is now general
agreement on the desirable qualities of a software
development approach, the field is insufficiently mature
to have standardized the development process.
Nonetheless, it is useful to examine the characteristics
of an idealized process and its products to understand
where current approaches are weak and which current
trends are promising. In general, a complete
requirements approach will define:
• Process: The (partially ordered) sequence of
activities, entrance and exit criteria for each
activity, which work product is produced in
each activity, and what kind of people should
do the work.
• Products: The work products to be produced
and, for each product, the resources needed to
produce it, the information it contains, the
expected audience, and the acceptance criteria
the product must satisfy.
Currently, there is little uniformity in different author’s
decomposition of the requirements phase or in the
terminology for the activities. Davis [Davis 88]
8
provides a good summary of the variations. Following
Davis’s integrated model and terminology [Davis 93],
the requirements phase consists of two conceptually
distinct but overlapping activities corresponding to the
first two goals for requirements enumerated previously:
1. Problem analysis: The goal of problem analysis is
to understand precisely what problem is to be
solved. It includes identifying the exact purpose of
the system, who will use it, the constraints on
acceptable solutions, and the possible tradeoffs
between conflicting constraints.
2. Requirements specification: The goal of
requirements specification is to create a document,
the Software Requirements Specification (SRS),
describing exactly what is to be built. The SRS
captures the results of problem analysis and
characterizes the set of acceptable solutions to the
problem.
In practice, the distinction between these activities is
conceptual rather than temporal. Where both are
needed, the developer typically switches back and forth
between analysis of the problem and documentation of
the results. When problems are well understood, the
analysis phase may be virtually non–existent. When the
system model and documentation are standardized or
based on existing specifications, the documentation
paradigm may guide the analysis [Hester 81].
5.1 Problem Analysis
Problem analysis is necessarily informal in the sense
that there is no effective, closed end procedure that will
guarantee success. It is an information acquiring,
collating, and structuring process through which one
attempts to understand all the various parts of a
problem and their relationships. The difficulty in
developing an effective understanding of large,
complex software problems has motivated considerable
effort to structure and codify problem analysis.
The basic issues in problem analysis are:
• How to effectively elicit a complete set of
requirements from the customer or other
sources?
• How to decompose the problem into
intellectually manageable pieces?
• How to organize the information so it can be
understood?
• How to communicate about the problem with
all the parties involved?
• How to resolve conflicting needs?
• How to know when to stop?
5.2 Requirements Specification
For substantial developments, the effectiveness of the
requirements effort depends on how well the SRS
captures the results of analysis and how useable the
specification is. There is little benefit to developing a
thorough understanding of the problem if that
understanding is not effectively communicated to
customers, designers, implementors, testers, and
maintainers. The larger and more complex the system,
the more important a good specification becomes. This
is a direct result of the many roles the SRS plays in a
multi–person, multi–version development [Parnas 86]:
1. The SRS is the primary vehicle for agreement
between the developer and customer on exactly
what is to be built. It is the document reviewed by
the customer or his representative and often is the
basis for judging fulfillment of contractual
obligations.
2. The SRS records the results of problem
analysis. It is the basis for determining where the
requirements are complete and where additional
analysis is necessary. Documenting the results of
analysis allows questions about the problem to be
answered only once during development.
3. The SRS defines what properties the system
must have and the constraints on its design and
implementation. It defines where there is, and is
not, design freedom. It helps ensure that
requirements decisions are made explicitly during
the requirements phase, not implicitly during
programming.
4. The SRS is the basis for estimating cost and
schedule. It is management’s primary tool for
tracking development progress and ascertaining
what remains to be done.
5. The SRS is the basis for test plan development.
It is the tester’s chief tool for determining the
acceptable behavior of the software.
6. The SRS provides the standard definition of
expected behavior for the system’s maintainers and
is used to record engineering changes.
For a disciplined software development, the SRS is the
primary technical specification of the software and the
primary control document. This is an inevitable result
of the complexity of large systems and the need to
9
coordinate multi–person development teams. To ensure
that the right system is built one must first understand
the problem. To ensure agreement on what is to be built
and the criteria for success, the results of that
understanding must be recorded. The goal of a
systematic requirements process is thus the
development of a set of specifications that effectively
communicate the results of analysis.
Requirement’s accidental difficulties are addressed
through the careful analysis and specification of a
disciplined process. Rather than developing the
specification as an afterthought, requirements are
understood and specified before development begins.
One knows what one is building before attempting to
build it. The SRS is the primary vehicle for
communicating requirements between the developers,
managers, and customers so the document is designed
to be useful to that purpose. A useful document is
maintained.
6.Requirements for the Software
Requirements Specification
The goals of the requirements process, the attendant
difficulties, and the role of the requirements
specification in a disciplined process determine the
properties of a “good” requirements specification.
These properties do not mandate any particular
specification method but do describe characteristics an
effective method must possess.
In discussing the properties of a good SRS, it useful to
distinguish semantic properties from packaging
properties [Faulk 92]. Semantic properties are a
consequence of what the specification says (i.e., its
meaning or semantics). Packaging properties are a
consequence of how the requirements are written down
- the format, organization, and presentation of the
information. The semantic properties determine how
effectively an SRS captures the software requirements.
The packaging properties determine how useable the
resulting specification is. Figure 4 illustrates the
classification of properties of a good SRS:
SRS Semantic Properties SRS Packaging Properties
Complete Modifiable
Implementation independent Readable
Unambiguous and consistent Organized for reference and review
Precise
Verifiable
Figure 4: Classification of SRS properties
An SRS that satisfies the semantic properties of a good
specification is:
• Complete. The SRS defines the set of
acceptable implementations. It should contain
all the information needed to write software
that is acceptable to the customer and no more.
Any implementation that satisfies every
statement in the requirements is an acceptable
product. Where information is not available
before development begins, areas of
incompleteness must be explicitly indicated
[Parnas 86].
• Implementation independent. The SRS should
be free of design and implementation decisions
unless those decisions reflect actual
requirements.
• Unambiguous and Consistent. If the SRS is
subject to conflicting interpretation, the
different parties will not agree on what is to be
built or whether the right software has been
built. Every requirement should have only one
possible interpretation. Similarly, no two
statements of required behavior should conflict.
• Precise. The SRS should define exactly the
required behavior. For each output, it should
define the range of acceptable values for every
input. The SRS should define any applicable
timing constraints such as minimum and
maximum acceptable delay.
• Verifiable. A requirement is verifiable if it is
possible to determine unambiguously whether a
given implementation satisfies the requirement
or not. For example, a behavioral requirement
is verifiable if it is possible to determine, for
any given test case (i.e., an input and an
output), whether the output represents an
acceptable behavior of the software given the
input and the system state.
10
An SRS that satisfies the packaging properties of a
good specification1 is:
• Modifiable. The SRS must be organized for
ease of change. Since no organization can be
equally easy to change for all possible changes,
the requirements analysis process must identify
expected changes and the relative likelihood of
their occurrence. The specification is then
organized to limit the effect of likely changes.
• Readable. The SRS must be understandable by
the parties that use it. It should clearly relate
the elements of the problem space as
understood by the customer to the observable
behavior of the software.
• Organized for reference and review. The SRS
is the primary technical specification of the
software requirements. It is the repository for
all the decisions made during analysis about
what should be built. It is the document
reviewed by the customer or his
representatives. It is the primary arbitrator of
disputes. As such the document must be
organized for quick and easy reference. It must
be clear where each decision about the
requirements belongs. It must be possible to
answer specific questions about the
requirements quickly and easily.
To address the difficulties associated with writing and
using an SRS, a requirements approach must provide
techniques addressing both semantic and packaging
properties. It is also desirable that the conceptual
structures of the approach treat the semantic and
packaging properties as distinct concerns (i.e., as
independently as possible). This allows one to change
the presentation of the SRS without changing its
meaning.
In aggregate, these properties of a good SRS represent
an ideal. Some of the properties may be unachievable,
particularly over the short term. For example, a
common complaint is that one cannot develop complete
requirements before design begins because the
customer does not yet fully understand what he wants
or is still making changes. Further, different SRS
“requirements” mitigate toward conflicting solutions. A
commonly cited example is the use of English prose to
1. Reusability is also a packaging property and
becomes an attribute of a good specification where
reusability of requirements specifications is a goal.
express requirements. English is readily understood but
notoriously ambiguous and imprecise. Conversely,
formal languages are precise and unambiguous, but can
be difficult to read.
Although the ideal SRS may be unachievable,
possessing a common understanding of what constitutes
an ideal SRS is important [Parnas 86] because it:
• Provides a basis for standardizing an
organization’s processes and products,
• Provides a standard against which progress can
be measured, and,
• Provides guidance - it helps developers
understand what needs to be done next and
when they are finished.
Because it is so often true that (1) requirements cannot
be fully understood before at least starting to build the
system and (2) a perfect SRS cannot be produced even
when the requirements are understood, some
approaches advocated in the literature do not even
attempt to produce a definitive SRS. For example,
some authors advocate going directly from a problem
model to design or from a prototype implementation to
the code. While such approaches may be effective on
some developments, they are inconsistent with the
notion of software development as an engineering
discipline. The development of technical specifications
is an essential part of a controlled engineering process.
This does not mean that the SRS must be entire or
perfect before anything else is done but that its
development is a fundamental goal of the process as a
whole. That we may currently lack the ability to write
good specifications in some cases does not change the
fact that it is useful and necessary to try.
7. State of the Practice
Over the years, a large number of analysis and
specification techniques have evolved. The general
trend has been for software engineering techniques to
be applied first to coding problems (e.g., complexity,
ease of change), then to similar problems occurring
earlier and earlier in the life cycle. Thus the concepts of
structured programming led eventually to structured
design and analysis. More recently, the concepts of
object oriented programming have led to object
oriented design and analysis. The following discussion
characterizes the major schools of thought and provides
pointers to instances of methods in each school. The
general strengths and weaknesses of the various
techniques are discussed relative to the requirements
11
difficulties and the desirable qualities of analysis and
specification methods.
It is characteristic of the immature state of requirements
as a discipline that the more specific one gets, the less
agreement there is. There is not only disagreement in
terminology, approach, and the details of different
methods, there is not even a commonly accepted
classification scheme. The following general groupings
are based on the evolution of the underlying concepts
and the key distinctions that reflect paradigmatic shifts
in requirements philosophy.
7.1 Functional Decomposition
Functional decomposition was originally applied to
software requirements to abstract from coding details.
Functional decomposition focuses on understanding
and specifying what processing the software is required
to do. The general strategy is to define the required
behavior as a mapping from inputs to outputs. Ideally,
the analysis proceeds top down, first identifying the
function associated with the system as a whole. Each
subsequent step decomposes the set of functions into
steps or sub–functions. The result is a hierarchy of
functions and the definitions of the functional
interfaces. Each level of the hierarchy adds detail about
the processing steps necessary to accomplish the more
abstract function above. The function above controls
the processing of its subfunctions. In a complete
decomposition, the functional hierarchy specifies the
“calls” structure of the implementation. One example of
a methodology based on functional decomposition is
Hamilton and Zeldin’s Higher Order Software
[Hamilton 76].
The advantage of functional decomposition is that the
specification is written using the language and concepts
of the implementors. It communicates well to the
designers and coders. It is written in terms of the
solution space so the transition to design and code is
straightforward.
Common complaints are that functional specifications
are difficult to communicate, introduce design
decisions prematurely, and difficult to use or change.
Because functional specifications are written in the
language of implementation, people who are not
software or systems experts find them difficult to
understand. Since there are inevitably many possible
ways of decomposing functions into subfunctions, the
analyst must make decisions that are not requirements.
Finally, since the processing needed in one step
depends strongly on what has been done the previous
step, functional decomposition results in components
that are closely coupled. Understanding or changing
one function requires understanding or changing all the
related functions.
As software has increased in complexity and become
more visible to non–technical people, the need for
methods addressing the weaknesses of functional
decomposition has likewise increased.
7.2 Structured Analysis
Structured analysis was developed primarily as a means
to address the accidental difficulties attending problem
analysis and, to a lesser extent, requirements
specification, using functional decomposition.
Following the introduction of structured programming
as a means to gain intellectual control over increasingly
complex programs, structured analysis evolved from
functional decomposition as a means to gain
intellectual control over system problems.
The basic assumption behind structured analysis is that
the accidental difficulties can be addressed by a
systematic approach to problem analysis using
[Svoboda 90]:
• a common conceptual model for describing all
problems,
• a set of procedures suggesting the general
direction of analysis and an ordering on the
steps,
• a set of guidelines or heuristics supporting
decisions about the problem and its
specification, and
• a set of criteria for evaluating the quality of the
product.
While structured analysis still contains the
decomposition of functions into subfunctions, the focus
of the analysis shifts from the processing steps to the
data being processed. The analyst views the problem as
constructing a system to transform data. He analyzes
the sources and destinations of the data, determines
what data must be held in storage, what transformations
are done on the data, and the form of the output.
Common to the structured analysis approaches is the
use of data flow diagrams and data dictionaries. Data
flow diagrams provide a graphic representation of the
movement of data through the system (typically
represented as arcs) and the transformations on the data
(typically represented as nodes). The data dictionary
supports the data flow diagram by providing a
repository for the definitions and descriptions of each
data item on the diagrams. Required processing is
captured in the definitions of the transformations.
12
Associated with each transformation node is a
specification of the processing the node does to
transform the incoming data items to the outgoing data
items. At the most detailed level, a transformation is
defined using a textual specification called a
“MiniSpec”. A MiniSpec may be expressed in a
number of different ways including English prose,
decision tables, or a procedure definition language
(PDL).
Structured analysis approaches originally evolved for
management information systems (MIS). Examples of
widely used strategies include those described by
DeMarco [DeMarco 78] and Gane and Sarson [Gane
79]. “Modern” structured analysis was introduced to
provide more guidance in modeling systems as data
flows as exemplified by Yourdon [Yourdon 89].
Structured analysis has also been adapted to support
specification of embedded control systems by adding
notations to capture control behavior. These variations
are collectively known as structured analysis/real–time
(SA/RT). Major variations of SA/RT have been
described by Ward and Mellor [Ward 86] and Hatley
and Pirbhai [Hatley 87]. A good summary of structured
analysis concepts with extensive references is given by
Svoboda [Svoboda 90].
Structured analysis extends functional decomposition
with the notion that there should be a systematic (and
hopefully predictable) approach to analyzing a
problem, decomposing it into parts, and describing the
relationships between the parts. By providing a well
defined process, structured analysis seeks to address, at
least in part, the accidental difficulties that result from
ad hoc approaches and the definition of requirements as
an afterthought. It seeks to address problems in
comprehension and communication by using a common
set of conceptual structures a graphic representation of
the specification in terms of those structures, based on
the assumption that a decomposition in terms of the
data the system handles will be clearer and less inclined
to change than one based on the functions performed.
While structured analysis techniques have continued to
evolve and have been widely used, there remain a
number of common criticisms. When used in problem
analysis, a common complaint is that structured
analysis provides insufficient guidance. Analysts have
difficulty deciding which parts of the problem to model
as data, which parts to model as transformations, and
which parts should be aggregated. While the gross steps
of the process are reasonably well defined, there is only
very general guidance (in the form of heuristics) on
what specific questions the analyst needs to answer
next. Similarly, practitioners find it difficult to know
when to stop decomposition and addition of detail. In
fact, the basic structured analysis paradigm of modeling
requirements as data flows and data transformations
requires the analyst to make decisions about
intermediate values (e.g., form and content of stored
data and the details of internal transformations) that are
not requirements. Particularly in the hands of less
experienced practitioners, data flow models tend to
incorporate a variety of detail that properly belongs to
design or implementation.
Many of these difficulties result from the weak
constraints imposed by the conceptual model. A goal of
the developers of structured analysis was to create a
very general approach to modeling systems; in fact, one
that could be applied equally to model human
enterprises, hardware applications, software
applications of different kinds, and so on.
Unfortunately, such generality can be achieved only by
abstracting away any semantics that are not common to
all of the types of systems potentially being modeled.
The conceptual model itself can provide little guidance
relevant to a particular system. Since the conceptual
model applies equally to requirements analysis and
design analysis, its semantics provide no basis for
distinguishing the two. Similarly, such models can
support only very weak syntactic criteria for assessing
the quality of structured analysis specifications. For
example, the test for completeness and consistency in
data flow diagrams is limited to determining that the
transformations at each level are consistent in name and
number with the data flows of the level above.
This does not mean one cannot develop data flow
specifications that are easy to understand, communicate
effectively with the user, or capture required behavior
correctly. The large number of systems developed using
structured analysis show that it is possible to do so.
However, the weakness of the conceptual model means
that a specification’s quality depends largely on the
experience, insight, and expertise of the analyst. The
developer must provide the necessary discipline
because the model itself is relatively unconstrained.
Finally, structured analysis provides little support for
producing an SRS meeting our quality criteria. Data
flow diagrams are unsuitable for capturing
mathematical relations or detailed specifications of
value, timing, or accuracy so the detailed behavioral
specifications are typically given in English or as
pseudo–code segments in the Mini-specs. These
constructs provide little or no support for writing an
SRS that is complete, implementation independent,
unambiguous, consistent, precise, and verifiable.
Further, the data flow diagrams and attendant
dictionaries do not, themselves, provide support for
organizing an SRS to satisfy the packaging goals of
readability, ease of reference and review, or reusability.
In fact, for many of the published methods, there is no
explicit process step, structure, or guidance for
13
producing an SRS, as a distinct development product,
at all.
7.3 Operational Specification
The operational2 approach focuses on addressing two
of the essential requirements dilemmas. The first is that
we often do not know exactly what should be built until
we build it. The second is the problem inherent in
moving from a particular specification of requirements
(what to build) to a design that satisfies those
requirements (how to build it). The closer the
requirements specification is to the design, the easier
the transition, but the more likely it is that design
decisions are made prematurely.
The operational approach seeks to address these
problems, among others, by supporting development of
executable requirements specifications. Key elements
of an operational approach are: a formal specification
language and an engine for executing well–formed
specifications written in the language. Operational
approaches may also include automated support for
analyzing properties of the formal specification and for
transforming the specification into an equivalent
implementation. A good description of the operational
approach, its rationale, and goals is given by Zave
[Zave 82].
The underlying reasoning about the benefits of the
operational approach is as follows:
Making the requirements specification itself
executable obviates the dilemma that one must
build the system to know what to build. The
developer writes the requirements specification
in a formal language. The specification may
then be executed to validate that the customer’s
needs have been captured and the right system
specified (e.g., one can apply scenarios and test
cases). The approach is presumed to require
less labor and be and more cost effective than
conventional prototyping because a separate
requirements specification need not be
produced, the specification and the
“prototype” are the same thing.
2. We use the term “operational” here specifically to
denote approaches based on executable specifications
in the sense of Zave [Zave 82]. The term is sometimes
used to contrast with axiomatic specification - that is
not the meaning here.
• Operational specifications allow the developer
to abstract from design decisions while
simplifying the transition from requirements to
design and implementation. Transition to
design and implementation is both simple and
automatable because the behavioral
requirements are already expressed in terms of
computational mechanisms. Design decisions
concerning efficiency, resource management,
and target language realization are abstracted
from in the computational model.
For general applications, operational approaches have
achieved only limited success. This is at least in part
due to the failure to achieve the necessary semantic
distinction between an operational computational
model and conventional programming. The benefits of
the approach are predicated on the assumption that the
operational model can be written in terms of the
problem domain, without the need to introduce
conceptual structures belonging to the solution domain.
In practice, this goal has proven elusive. To achieve
generality, operational languages have typically had to
introduce implementation constructs. The result is not a
requirements specification language but a higher–level
programming language. As noted by Parnas [Parnas
85b] and Brooks [Brooks 87], the specification ends up
giving the solution method rather than the problem
statement. Thus, in practice, operational specifications
do not meet the SRS goal of implementation
independent.
The focus of operational specification is on the benefits
of early simulation rather than on the properties of the
specification as a reference document. Since
executability requires formality, operational
specifications necessarily satisfy the SRS semantic
properties of being unambiguous, consistent, precise,
and verifiable. The ability to validate the specification
through simulation also supports completeness.
However, as discussed, these properties have not been
achieved in concert with implementation independence.
Fruther, the methods discussed in the literature put little
emphasis on the communication or packaging qualities
of the specification, except as these qualities overlap
with desirable properties of a design. Thus, there may
be some support for modifiability but little for
readability or organizing an SRS for reference and
review.
7.4 Object Oriented Analysis (OOA)
There is currently considerable discussion in the
literature, and little agreement, on exactly what should
and should not be considered “object oriented.” OOA
has evolved from at least two significant sources,
14
information modeling and object oriented design. Each
has contributed to current views of OOA, and the
proponents of each emphasize somewhat different sets
of concepts. For the purposes of this tutorial, we are not
interested in which method is by some measure “more
object oriented” but in the distinct contributions of the
object oriented paradigm to analysis and specification.
For an overview of OOA concepts and methods see
Balin’s article [Balin 94]; Davis’ book [Davis 93]
includes both discussion and examples. Examples of
recent approaches self–described as object oriented
include work by Rumbaugh [Rumbaugh 91], Coad and
Yourdon [Coad 91], Shlaer and Mellor [Shlaer 88],
and Selic, Gullekson, and Ward [Selic 94].
OOA techniques differ from structured analysis in their
approach to decomposing a problem into parts and in
the methods for describing the relationships between
the parts. In OOA, the analyst decomposes the problem
into a set of interacting objects based on the entities
and relationships extant in the problem domain. An
object encapsulates a related set of data, processing,
and state (thus, a significant distinction between object
oriented analysis and structured analysis is that OOA
encapsulates both data and related processing together).
Objects provide externally accessible functions,
typically called services or methods. Objects may hide
information about their internal structure, data, or state
from other objects. Conversely, they may provide
processing, data, or state information through the
services defined on the object interface. Dynamic
relationships between objects are captured in terms of
message passing (i.e., one object sends a message to
invoke a service or respond to an invocation). The
analyst captures static relationships in the problem
domain using the concepts of aggregation and
classification. Aggregation is used to capture
whole/part relationships. Classification is used to
capture class/instance relationships (also called “is–a”
or inheritance relationships).
The structural components of OOA (e.g., objects,
classes, services, aggregation) support a set of analytic
principles. Of these, two directly address requirements
problems:
1. From information modeling comes the
assumption that a problem is easiest to understand
and communicate if the conceptual structures
created during analysis map directly to entities and
relationships in the problem domain. This principle
is realized in OOA through the heuristic of
representing problem domain objects and
relationships of interest as OOA objects and
relationships.. Thus an OOA specification of a
vehicle registration system might model vehicles,
vehicle owners, vehicle title, and so on [Coad 90]
as objects. The object paradigm is used to model
both the problem and the relevant problem context.
2. From early work on modularization by Parnas
[Parnas 72] and abstract data types, by way of
object oriented programming and design, come the
principles of information hiding and abstraction.
The principle of information hiding guides one to
limit access to information on which other parts of
the system should not depend. In an OO
specification of requirements, this principle is
applied to hide details of design and
implementation. In OOA, behavior requirements are
specified in terms of the data and services provided
on the object interfaces; how those services are
implemented is encapsulated by the object.
The principle of abstraction says that only the
relevant or essential information should be
presented. Abstraction is implemented in OOA
by defining object interfaces that provide
access only to essential data or state
information encapsulated by an object
(conversely hiding the accidentals).
The principles and mechanisms of OOA provide a basis
for attacking the essential difficulties of
comprehension, communication, and control. The
principle of problem domain modeling helps guide the
analyst in distinguishing requirements (what) from
design (how). Where the objects and their relationships
faithfully model entities and relationships in the
problem, they are understandable by the customer and
other domain experts; this supports early
comprehension of the requirements.
The principles of information hiding and abstraction,
with the attendant object mechanisms, provide
mechanisms useful for addressing the essential
problems of control and communication. Objects
provide the means to divide the requirements into
distinct parts, abstract from details, and limit
unnecessary dependencies between the parts. Object
interfaces can be used to hide irrelevant detail and
define abstractions providing only the essential
information. This provides a basis for managing
complexity and improving readability. Likewise objects
provide a basis for constructing reusable requirements
units of related functions and data.
The potential benefits of OOA are often diluted by the
way the key principles are manifest in particular
methods. While the objects and relations of OOA are
intended to model essential aspects of the application
domain, this goal is typically not supported by an
corresponding conceptual model of the domain
behavior. As for structured analysis, object modeling
mechanisms and techniques are intentionally generic
15
rather than application specific. One result is
insufficient guidance in developing appropriate object
decompositions. Just as structured analysis practitioners
have difficulty choosing appropriate data flows and
transformations, OOA practitioners have difficulty
choosing appropriate objects and relationships.
In practice, one finds the notion that one can develop
the structure of a system, or a requirements
specification, based on physical structure is often
oversold. It is true that the elements of the physical
world are usually stable (especially relative to software
details) and that real–world based models have intuitive
appeal. It is not, however, the case that everything that
must be captured in requirements has a physical analog.
An obvious example is shared state information.
Further, many real world structures are themselves
arbitrary and likely to change (e.g., where two
hardware functions are put on one physical platform to
reduce cost). While the notion of basing requirements
structure on physical structure is a useful heuristic,
more is needed to develop a complete and consistent
requirements specification.
A further difficulty is that the notations and semantics
of OOA methods are typically based on the conceptual
structures of software rather than those of the problem
domain the analyst seeks to model. Symptomatic of
this problem is that analysts find themselves debating
about object language features and their properties
rather than about the properties of the problem. An
example is the use of message passing, complete with
message passing protocols, where one object uses
information defined in another. In the problem domain
it is often irrelevant whether information is actively
solicited or passively received. In fact there may be no
notion of messages or transmission at all. Nonetheless
one finds analysts debating about which object should
initiate a request and the resulting anomaly of passive
entities modeled as active. For example, to get
information from a book one might request that the
book “read itself” and “send” the requested information
in a message. To control an aircraft the pilot might “use
his hands and feet to ‘send messages’ to the aircraft
controls which in turn send messages to the aircraft
control surfaces to modify themselves” [Davis 93].
Such decisions are about OOA mechanisms or design,
not about the problem domain or requirements.
A more serious complaint is that most current OOA
methods inadequately address our goal of developing a
good SRS. Most OOA approaches in the literature
provide only informal specification mechanisms,
relying on refinement of the OO model in design and
implementation to add detail and precision. There is no
formal basis for determining if a specification is
complete, consistent, or verifiable. Further, none of the
OOA techniques discussed directly address the issues
of developing the SRS as a reference document. The
focus of all of the OOA techniques cited is on problem
analysis rather than specification. If the SRS is
addressed at all, the assumption is that the principles
applied to problem understanding and modeling are
sufficient, when results are written down, to produce a
good specification. Experience suggests otherwise. As
we have discussed, there are inherently tradeoffs that
must be made to develop a specification that meets the
need of any particular project. Making effective
tradeoffs requires a disciplined and thoughtful
approach to the SRS itself, not just the problem. Thus,
while OOA provide the means to address packaging
issues, there is typically little methodological emphasis
on issues like modifiability or organization of a
specification for reference and review.
7.5Software Cost Reduction (SCR) Method
Where most of the techniques thus far discussed focus
on problem analysis, the requirements work at the
United States Naval Research Laboratory (NRL)
focused equally on issues of developing a good SRS.
NRL initiated the Software Cost Reduction (SCR)
project in 1978 to demonstrate the feasibility and
effectiveness of advanced software engineering
techniques by applying them to a real system, the
Operational Flight Program (OFP) for the A–7E
aircraft. To demonstrate that (then academic)
techniques such as information hiding, formal
specification, abstract interfaces, and cooperating
sequential processes could help make software easier to
understand, maintain, and change, the SCR project set
out to re–engineer the A–7E OFP.
Since no existing documentation adequately captured
the A–7E’s software requirements, the first step was to
develop an effective SRS. In this process, the SCR
project identified a number of properties a good SRS
should have and a set of principles for developing
effective requirements documentation [Heninger 80].
The SCR approach uses formal, mathematically based
specifications of acceptable system outputs to support
development of a specification that is unambiguous,
precise, and verifiable. It also provided techniques for
checking a specification for a variety of completeness
and consistency properties. The SCR approach
introduced principles and techniques to support our
SRS packaging goals including the principle of
separation of concerns to aid readability and support
ease of change. It also includes the use of a standard
structure for an SRS specification and the use of tabular
specifications that improve readability, modifiability,
and facilitate use of the specification for reference and
review.
16
While other requirements approaches have stated
similar objectives, the SCR project is unique in having
applied software engineering principles to develop a
standard SRS organization, a specification method,
review method [Parnas 85a], and notations consistent
with those principles. The SCR project is also unique in
making publicly available a complete, model SRS of a
significant system [Alspaugh 92].
A number of issues were left unresolved by the original
SCR work. While the product of the requirements
analysis was well documented, the underlying process
and method were never fully described. Since the
original effort was to re–engineer an existing system, it
was not clear how effective the techniques would be on
a new development. Since the developers of the A–7E
requirements document were researchers, it was also
unclear whether industrial developers would find the
rather formal method and notation useable, readable, or
effective. Finally, while the A–7E SRS organization is
reasonably general, many of the specification
techniques are targeted to real–time, embedded
applications. As discussed in the following section,
more recent work by Parnas [Parnas 91], NRL
[Heitmeyer 95a,b], and others [Faulk 92] has addressed
many of the open questions about the SCR approach.
8. Trends and Emerging Technology
While improved discipline will address requirement’s
accidental difficulties, addressing the essential
difficulties requires technical advances. Significant
trends, in some cases backed by industrial experience,
have emerged over the past few years that offer some
hope for improvement:
• Domain specificity: Requirements methods will
provide improved analytic and specification
support by being tailored to particular classes
of problems. Historically requirements
approaches have been advanced as being
equally useful to a wide variety of types of
applications. For example, structured analysis
methods were deemed to be based on
conceptual models that were “universally
applicable” (e.g., [Ross 77]); similar claims
have been made for object oriented approaches.
Such generality comes at the expense of ease of
use and amount of work the analyst must do for
any particular application. Where the
underlying models have been tailored to a
particular class of applications, the properties
common to the class are embedded in the
model. The amount of work necessary to adapt
the model to a specific instance of the class is
relatively small. The more general the model,
the more decisions that must be made, the more
information that must be provided, and the
more tailoring that must be done. This provides
increased room for error and, since each
analyst will approach the problem differently,
makes solutions difficult to standardize. In
particular, such generality precludes
standardization of sufficiently rigorous models
to support algorithmic analysis of properties
like completeness and consistency.
Similar points have been expressed in a recent
paper by Jackson [Jackson 94]. He points out
that some of the characteristics separating real
engineering disciplines from what is
euphemistically described as “software
engineering” are well understood procedures,
mathematical models, and standard designs
specific to narrow classes of applications.
Jackson points out the need for software
methods based on the conceptual structures and
mathematical models of behavior inherent in a
given problem domain (e.g., publication,
command and control, accounting, and so on).
Such common underlying constructs can
provide the engineer guidance in developing
the specification for a particular system.
• Practical formalisms: Like so many of the
promising technologies in requirements, the
application of formal methods is characterized
by an essential dilemma. On one hand, formal
specification techniques hold out the only real
hope for producing specifications that are
precise, unambiguous, and demonstrably
complete or consistent. On the other, industrial
practitioners widely view formal methods as
impractical. Difficulty of use, inability to scale,
readability, and cost are among the reasons
cited. Thus, in spite of significant technical
progress and a growing body of literature, the
pace of adoption by industry has been
extremely slow.
In spite of the technical and technical transfer
difficulties, increased formality is necessary.
Only by placing behavioral specification on a
mathematical basis will we be able to acquire
sufficient intellectual control to develop
complex systems with any assurance that they
satisfy their intended purpose and provide
necessary properties like safety. The solution is
better formal methods - methods that are
17
practical given the time, cost, and personnel
constraints of industrial development.
Engineering models and the training to use
them are de rigueur in every other discipline
that builds large, complex, or safety–critical
systems. Builders of a bridge or skyscraper
who did not employ proven methods or
mathematical models to predict reliability and
safety would be held criminally negligent in the
event of failure. It is only the relative youth of
the software discipline that permits us to get
away with less. But, we cannot expect great
progress overnight. As Jackson [Jackson 94]
notes, the field is sufficiently immature that
“the prerequisites for a more mathematical
approach are not in place.” Further, many of
those practicing our craft lack the background
required of licensed engineers in other
disciplines [Parnas 89]. Nonetheless, sufficient
work has been done to show that more formal
approaches are practical and effective in
industry. For an overview of formal methods
and their role in practical developments, the
reader is referred to Rushby’s summary work
[Rushby 93].
• Improved tool support: It remains common to
walk into the office of a software development
manager and find the shelves lined with the
manuals for CASE tools that are not in use. In
spite of years of development and the contrary
claims of vendors, many industrial developers
have found the available requirements CASE
tools of marginal benefit.
Typically, the fault lies not so much with the
tool vendor but with the underlying method or
methods the tool seeks to support. The same
generality, lack of strong underlying conceptual
model, and lack of formality that makes the
methods weak limits the benefits of
automation. Since the methods do not
adequately constrain the problem space and
offer little specific guidance, the corresponding
tool cannot actively support the developer in
making difficult decisions. Since the model and
SRS are not standardized, its production eludes
effective automated support. Since the
underlying model is not formal, only trivial
syntactic properties of the specification can be
evaluated. Most such tools provide little more
than a graphic interface and requirements data
base.
Far more is now possible. Where the model,
conceptual structures, notations, and process
are standardized, significant automated support
becomes possible. The tool can use information
about the state of the specification and the
process to guide the developer in making the
next step. It can use standardized templates to
automate rote portions of the SRS. It can use
the underlying mathematical model to
determine to what extent the specification is
complete and consistent. While only the
potential of such tools has yet been
demonstrated, there are sufficient results to
project the benefits (e.g., [Heitmeyer 95b],
[Leveson 94]).
• Integrated paradigms: One of the Holy Grails
of software engineering has been the integrated
software development environment. Much of
the frustration in applying currently available
methods and tools is the lack of integration, not
just in the tool interfaces, but in the underlying
models and conceptual structures. Even where
an approach works well for one phase of
development, the same techniques are either
difficult to use in the next phase or there is no
clear transition path. Similarly tools are either
focused on a small subset of the many tasks
(e.g., analysis but not documentation) or
attempt to address the entire life cycle but
support none of it well. The typical
development employs a hodgepodge of
software engineering methodologies and ad hoc
techniques. Developers often build their own
software to bridge the gap between CASE
platforms.
In spite of a number of attempts, the production
of a useful integrated set of methods and
supporting environment has proven elusive.
However, it now appears that there is sufficient
technology available to provide, if not a
complete solution, at least the skeleton for one.
.
The most significant methodological trend can be
described as convergent evolution. In biology,
convergent evolution denotes a situation where
common evolutionary pressures lead to similar
characteristics (morphology) in distinct species. An
analogous convergence is ongoing in requirements. As
different schools of thought have come to understand
and attempt to address the weaknesses and omissions in
their own approaches, the solutions have become more
similar. In particular, the field is moving toward a
common understanding of the difficulties and common
assumptions about the desired qualities of solutions.
This should not be confused with the bandwagon effect
that often attends real or imaginary paradigm shifts
(e.g., the current rush to object oriented everything).
18
Rather it is the slow process of evolving common
understanding and changing conventional practices.
Such trends and some preliminary results are currently
observable in requirements approaches for embedded
software. In the 1970’s the exigencies of national
defense and aerospace applications resulted in demand
for complex, mission critical software. It became
apparent early on that available requirements
techniques addressed neither the complexity of the
systems being built nor the stringent control, timing,
and accuracy constraints of the applications.
Developers responded by creating a variety of domain
specific approaches. Early work by TRW for the U.S.
Army on the Ballistic Missile Defense system produced
the Software Requirements Engineering Method
(SREM) [Alford 77] and supporting tools. Such
software problems in the Navy led to the SCR project.
Ward, Mellor, Hatley, and Pirbhai ([Ward 86], [Hatley
87]) developed extensions to structured analysis
techniques targeted to real time applications. Work on
the Israeli defense applications led Harel to develop
statecharts [Harel 87] and the supporting tool
Statemate.
The need for high–assurance software in mission and
safety critical systems also led to the introduction of
practical formalisms and integrated tools support. TRW
developed REVS [Davis 77] and other tools as part of a
complete environment supporting SREM and other
phases of the life cycle. The SCR project developed
specification techniques based on mathematical
functions and tabular representations [Heninger 80].
These allowed a variety of consistency and
completeness checks to be performed by inspection.
Harel introduced a compact graphic representation of
finite state machines with a well–defined formal
semantics. These features were subsequently integrated
in the Statemate tool that supported symbolic execution
of statecharts for early customer validation and limited
code generation. All of these techniques began to
converge on an underlying model based on finite state
automata.
More recent work has seen continuing convergence
toward a common set of assumptions and similar
solutions. Recently, Ward and colleagues have
developed the Real–Time Object Oriented Modeling
(ROOM) method [Selic 94]. ROOM integrates
concepts from operational specification, object oriented
analysis, and statecharts. It employs an object oriented
modeling approach with tool support. The tool is based
on a simplified statechart semantics and supports
symbolic execution and some code generation. The
focus of ROOM currently remains on problem
modeling and the transition to design, and execution
rather than formal analysis.
Nancy Leveson and her colleagues have adapted
statecharts to provide a formally based method for
embedded system specification [Jaffe 91]. The
approach has been specifically developed to be useable
and readable by practicing engineers. It employs both
the graphical syntax of statecharts and a tabular
representation of functions similar to those used in the
SCR approach. Its underlying formal model is intended
to support formal analysis of system properties, with an
emphasis on safety. The formal model also supports
symbolic execution. These techniques have been
applied to develop a requirements specification for
parts of the Federal Aviation Administration’s safety
critical Traffic Alert and Collision Avoidance System
(TCAS) [Leveson 94].
Extensions to the SCR work have taken a similar
direction. Parnas and Madey have extended the SCR
approach to create a standard mathematical model for
embedded system requirements [Parnas 91]. Heitmeyer
and colleagues at NRL have extended the
Parnas/Madey work by defined a corresponding formal
model for the SCR approach [Heitmeyer 95b]. This
formal model has been used to develop a suite of
prototype tools supporting analysis of requirements
properties like completeness and consistency
[Heitmeyer 95a]. The NRL tools also support
specification–based simulation and are being integrated
with other tools to support automated analysis of
application specific properties like safety assertions.
Concurrent work at the Software Productivity
Consortium by Faulk and colleagues [Faulk 92] has
integrated the SCR approach with object oriented and
graphic techniques and defined a complete
requirements analysis process including a detailed
process for developing a good SRS. These techniques
have been applied effectively in development of
requirements for Lockheed’s avionics upgrade on the
C–130J aircraft [Faulk 94]. The C–130J avionics
software is a safety–critical system of approximately
100K lines of Ada code.
Other recent work attempts to increase the level of
formality and the predictability of the problem analysis
process and its products. For example, Potts and his
colleagues are developing process models and tools to
support systematic requirements elicitation that include
a formal structure for describing discussions about
requirements [Potts 94]. Hsai and his colleagues,
among others are investigating formal approaches to
the use of scenarios in eliciting and validating
requirements [Hsai 94]. Recent work by Boehm and his
colleagues [Boehm 94] seeks to address the accidental
difficulties engendered by adversarial software
procurement processes.
While none of the works mentioned can be considered
a complete solution it is clear that (1) the work is
19
converging toward common assumptions and solutions,
(2) the approaches all provide significantly improved
capability to address both accidental and essential
requirements difficulties, and (3) the solutions can be
effectively applied in industry.
9. Conclusions
Requirements are intrinsically hard to do well. Beyond
the need for discipline, there are a host of essential
difficulties that attend both the understanding of
requirements and their specification. Further, many of
the difficulties in requirements will not yield to
technical solution alone. Addressing all of the essential
difficulties requires the application of technical
solutions in the context of human factors such as the
ability to manage complexity or communicate to
diverse audiences. A requirements approach that does
not account for both technical and human concerns can
have only limited success. For developers seeking new
methods, the lesson is caveat emptor. If someone tells
you his method makes requirements easy, keep a hand
on your wallet.
Nevertheless, difficulty is not impossibility and the
inability to achieve perfection is not an excuse for
surrender. While all of the approaches discussed have
significant weaknesses, they all contribute to the
attempt to make requirements analysis and specification
a controlled, systematic, and effective process. Though
there is no easy path, experience confirms that the use
of any careful and systematic approach is preferable to
an ad hoc and chaotic one. Further good news is that, if
the requirements are done well, chances are much
improved that the rest of the development will also go
well. Unfortunately, ad hoc approaches remain the
norm in much of the software industry.
A final observation is that the benefits of good
requirements come at a cost. Such a difficult and
exacting task cannot be done properly by personnel
with inadequate experience, training, or resources.
Providing the time and the means to do the job right is
the task of responsible management. The time to
commit the best and brightest is before, not after,
disaster occurs. The monumental failures of a host of
ambitious developments bear witness to the folly of
doing otherwise.
10 . Further Reading
Those seeking more depth on requirements
methodologies than this tutorial can provide should
read Alan Davis’ book Software Requirements:
Objects, Functions, and States [Davis 93]. In addition
to a general discussion of issues in software
requirements, Davis illustrates a number of problem
analysis and specification techniques with a set of
common examples and provides a comprehensive
annotated bibliography. For a better understanding of
software requirements in the context of systems
development, the reader is referred to the book of
collected papers edited by Thayer and Dorfman, System
and Software Requirements Engineering [Thayer 90].
This tutorial work contains in one volume both original
papers and reprints from many of the authors discussed
above. The companion volume, Standards, Guidelines,
and Examples on System and Software Requirements
Engineering [Dorfman 90] is a compendium of
international and U.S. government standards relating to
system and software requirements and provides some
illustrating examples.
Acknowledgements
C. Colket at SPAWAR, E. Wald at ONR and A. Pyster
at the Software Productivity Consortium supported the
development of this report. The quality of this paper
has been much improved thanks to thoughtful reviews
by Paul Clements, Connie Heitmeyer, Jim Kirby, Bruce
Labaw, Richard Morrison, and David Weiss.
REFERENCES
[Alford 77] Alford, M., “A Requirements
Engineering Methodology for Real–Time Processing
Requirements,” IEEE Transactions on Software
Engineering, v. 3, no. 1, January 1977, pp. 60-69.
[Alford 79] Alford, M. and J. Lawson, “Software
Requirements Engineering Methodology
(Development),” RADC–TR–79–168, U.S. Air Force
Rome Air Development Center, June 1979.
[Alspaugh 92] Alspaugh, T., S. Faulk, K. Britton, R.
Parker, D. Parnas, and J. Shore, Software Requirements
for the A–7E Aircraft, NRL/FR/5530–92–9194.
Washington, D.C.: Naval Research Laboratory, 1992.
[Balin 94] Balin, S., “Object–Oriented
Requirements Analysis,” in Encyclopedia of Software
Engineering, J. Marciniak ed., John Wiley & Sons,
N.Y., 1994, pp.740-756.
[Basili 81] Basili, V., and D. Weiss, “Evaluation
of a Software Requirements Document by Analysis of
Change Data,” Proceedings of the Fifth International
20
Conference on Software Engineering, San Diego,
California, March 1981, pp. 314-323.
[Boehm 81] Boehm, B., Software Engineering
Economics, Prentice Hall, New Jersey, 1981.
[Boehm 94] Boehm, B., P. Bose, E. Horowitz,
and M. Lee, “Software Requirements as Negotiated
Win Conditions,” in Proceedings of the First
International Conference on Requirements
Engineering, Colorado Springs, Colorado, April 18-22,
1994, pp. 74-83.
[Brooks 75] Brooks, F., The Mythical Man–
Month, Addison–Wesley, 1975.
[Brooks 87] Brooks, F., “No Silver Bullet:
Essence and Accidents of Software Engineering,” IEEE
Computer, April 1987, pp. 10-19.
[CECOM 89] Software Methodology Catalog:
Second Edition, Technical report C01–091JB–0001–
01, U.S. Army Communications–Electronics
Command, Fort Monmouth, New Jersey, March, 1989.
[Clements 95] Clements, P., private communication,
May, 1995.
[Coad 90] Coad, P., and E. Yourdon, Object
Oriented Analysis, Prentice Hall, New Jersey, 1990.
[Davis 77] Davis, C. and C. Vick, “The Software
Development System,” IEEE Transactions on
Software Engineering, v. 3, no. 1, January, 1977, pp.
69-84.
[Davis 88] Davis, A., “A Taxonomy for the
Early Stages of the Software Development Life Cycle,”
Journal of Systems and Software, September, 1988, pp.
297-311.
[Davis 93] Davis, A., Software Requirements
(Revised): Objects, Functions, and States, Prentice
Hall, New Jersey, 1993.
[DeMarco 78] DeMarco, T., Structured Analysis
and System Specification, Prentice Hall, New Jersey,
1978.
[Dorfman 90] Dorfman, M., and R. Thayer, eds.,
Standards, Guidelines, and Examples on System and
Software Requirements Engineering, IEEE Computer
Society Press, Los Alamitos, California, 1990.
[Faulk 92] Faulk, S., J. Brackett, P. Ward, and J.
Kirby, Jr., The Core Method for Real–Time
Requirements, IEEE Software, Vol. 9, No. 5,
September 1992.
[Faulk 93] Faulk, S., L. Finneran, J. Kirby Jr.,
and A. Moini, Consortium Requirements Engineering
Guidebook, Version 1.0, SPC–92060–CMC, Software
Productivity Consortium, Herndon, Virginia, 1993.
[Faulk 94] Faulk, S., L. Finneran, J. Kirby, S.
Shah, and J. Sutton, “ Experience Applying the CoRE
Method to the Lockheed C–130J,” Proceedings of the
Ninth Annual Conference on Computer Assurance,
IEEE 94CH3415–7, Gaithersburg, Maryland, June
1994, pp. 3-8.
[GAO 79] U.S. General Accounting Office,
Contracting for Computer Software Development-
Serious Problems Require Management Attention to
Avoid Wasting Additional Millions, Report FGMSD–
80–4, November 1979.
[GAO 92] U.S. General Accounting Office,
Mission Critical Systems: Defense Attempting to
Address Major Software Challenges, GAO/IMTEC–
93–13, December 1992.
[Gane 79] Gane, C., and T. Sarson, Structured
Systems Analysis, Prentice Hall, New Jersey, 1979.
[Hamilton 76] Hamilton, M. and S. Zeldin, “Higher
Order Software-A Methodology for Defining
Software,” IEEE Transactions on Software
Engineering, v. 2, no. 1, January 1976, pp 9-32.
[Harel 87] Harel, D., “Statecharts: a Visual
Formalism for Complex Systems,” Science of
Computer Programming 8, 1987, pp. 231-274.
[Hatley 87] Hatley, D., and I. Pirbhai, Strategies
for Real–Time Specification, Dorset House, New York,
New York, 1987.
[Heitmeyer 95a] Heitmeyer, C., B. Labaw, and D.
Kiskis, “Consistency Checking of SCR–Style
Requirements Specifications,” in Proceedings, IEEE
International Symposium on Requirements
Engineering, March 1995.
[Heitmeyer 95b] Heitmeyer, C., R. Jeffords, and B.
Labaw. Tools for Analyzing SCR–Style Requirements
Specifications: A Formal Foundation, NRL Technical
Report NRL-7499, U.S. Naval Research Laboratory,
Washington, DC, 1995.
21
[Heninger 80] Heninger, K., “Specifying Software
Requirements for Complex Systems: New Techniques
and Their Application”, IEEE Transactions on
Software Engineering, v. 6, no. 1, January, 1980.
[Hester 81] Hester, S. , D. Parnas, and D. Utter,
“Using Documentation as a Software Design Medium”,
Bell System Technical Journal, v. 60, no. 8, October
1981, pp 1941-1977.
[Hsai 94] Hsai, P., J. Samuel, J. Gao, D. Kung,
Y. Toyoshimi, and C. Chen, “Formal Approach to
Scenario Analysis,” IEEE Software, March 1994, pp.
33-41.
[Jackson 83] Jackson, M., System Development,
Prentice Hall, New Jersey, 1983.
[Jackson 94] Jackson, M., “Problems, Methods,
and Specialization,” IEEE Software, November 1994,
pp. 57-62.
[Jaffe 91] Jaffe, M., N. Leveson, M. Heimdahl,
and B. Melhart, “Software Requirements Analysis for
Real–Time Process–Control Systems”, IEEE
Transactions on Software Engineering, Vol. 17, No. 3,
March 1991, pp. 241–257.
[Leveson 94] Leveson, N., M. Heimdahl, H.
Hildreth, and J. Reese, “Requirements Specification for
Process–Control Systems,” IEEE Transactions on
Software Engineering, Vol. 20, No. 9, September 1994.
[Lutz 93] Lutz, R., “Analyzing Software
Requirements Errors in Safety–Critical Embedded
Systems,” Proceedings, IEEE International Symposium
on Requirements Engineering, January 4-6, 1993, pp.
126-133.
[Parnas 72] Parnas, D., “On the Criteria to be
Used in Decomposing Systems into Modules,”
Communications of the ACM, v. 15, no. 12, December
1972, pp. 1053-1058.
[Parnas 85a] Parnas, D. and D. Weiss, “Active
Design Reviews: Principles and Practices,” in
Proceedings of the Eighth International Conference on
software Engineering, London, England, August 1985.
[Parnas 85b] Parnas, D., “Software Aspects of
Strategic Defense Systems,” American Scientist,
September 1985, pp. 432-440.
[Parnas 86] Parnas, D., and P. Clements, “A
Rational Design Process: How and Why to Fake It,”
IEEE Transactions on Software Engineering, v. 12, no.
2, February 1986, pp. 251-257.
[Parnas 89] Parnas, D., Education for Computing
Professionals, Technical Report 89-247, Department of
Computing and Information Science, Queens
University, Kingston, Ontario, 1989.
[Parnas 91] Parnas, D., and J. Madey, Functional
Documentation for Computer Systems Engineering
(Version 2), CRL Report No. 237,. McMaster
University, Hamilton, Ontario, Canada, September
1991.
[Potts 94] Potts, C., K. Takahashi, A. Anton,
“Inquiry–Based Requirements Analysis,” IEEE
Software, March 1994, pp. 21-32.
[Shlaer 88] Shlaer, S. and S. Mellor, Object-
Oriented Systems Analysis: Modeling the World in
Data, Prentice Hall, New Jersey, 1988.
[Ross 77] Ross, D. and K. Schoman Jr.,
“Structured Analysis for Requirements Definitions,”
IEEE Transactions on Software Engineering, v. 3, no.
1, January 1977, pp. 6-15.
[Rumbaugh 91] Rumbaugh, M. Blaha, W.
Premerlani, F. Eddy, and W. Lorensen, Object–
Oriented Modeling and Design, Prentice Hall, New
Jersey, 1991.
[Rushby 93] Rushby, J., Formal Methods and the
Certification of Critical Systems, CSL Technical
Report SRI–CSL–93–07, SRI International, Menlo
Park, California, November, 1993.
[Selic 94] Selic, B., G. Gullekson, and P. Ward,
Real–Time Object–Oriented Modeling, John Wiley &
Sons, 1994.
[Svoboda 90] Svoboda, C., “Structured Analysis,”
in in Tutorial: System and Software Requirements
Engineering, R. Thayer and M. Dorfman, eds., IEEE
Computer Society Press, Los Alamitos, California,
1990, pp. 218-237.
[Thayer 90] Thayer, R. and M. Dorfman, eds.,
Tutorial: System and Software Requirements
Engineering, IEEE Computer Society Press, Los
Alamitos, California, 1990.
[Ward 86] Ward, P., and S. Mellor, Structured
Development for Real–Time Systems, Volumes 1, 2,
and 3, Prentice–Hall, Englewood Cliffs, New Jersey,
1986.
22
[Yourdon 89] Yourdon, E. Modern Structured
Analysis, Yourdon Press/Prentice Hall, 1989.
[Zave 82] Zave, P., “An Operational Approach
to Requirements Specification for Embedded Systems,”
IEEE Transactions on Software Engineering, v. 8, no.
3, May 1982, pp. 292]]> Wed, 30 Apr 2008 16:17:09 +0900 <![CDATA[요구조건 왜 중요한가?]]> http://blog.paran.com/blueyellow/25412969

 “하나의 소프트 시스템을 만드는 것 중 가장 힘든 부분은 정확히 무엇을 만들지 결정하는 것이다.”


 다른 개념적 일도 상세한 기술적 requirement를 만드는 것 만큼 어렵지 않다. 만약 잘못된다면 requirement 이외에 다른 부분도 그렇게 결과 시스템을 절름발이로 만들 수 없다. 시스템 구축 후에 requirement를 고치는 것이 가장 어렵다.[Brooks 87]


 1. 소개

 정확히 무엇을 만들지 결정하고 결과를 문서화 하는 것은 소프트 개발의 요구 조건의 목표이다. 대용량, 복합 소프트웨어 시스템의 많은 개발자에게, 요구조건은 그들의 가장 큰 소프트 공학의 문제이다. 심각한 불일치 문제를 풀기 위한 방법에 있어서 많은 사람들이 Brooks 평가에 동의한다. (Brooks가 제일 앞에서 했던 말) 이러한 지도서의 목적은 무엇을 만들지 결정하는 것이 실전에서 왜 어려운지를 이해시키는데 도움을 준다.


 이 논문은 학문을 연구하는 것이 아니라 근본적인 이슈에 대한 이해를 독자에게 준다. 현재 요구조건에 대한 많은 접근법이 있다. 이러한 다양성은 다른 관점에 의해 만들어진 생성물이다. 이 논문은 하나의 해결책을 시도하는데 관련된 tradeoff와 요구조건 문제를 이해시키는데 있다. 그러므로 이미 사전지식이 있는 독자는 다른 요구조건 방법과 그것들의 실현 가능한 효과성에 대해 나름대로 평가를 내려 보아도 좋을 것이다.


 우리는 요구조건에 대한 기본 전문용어와 역사적 데이터와 함께 시작한다. 우리는 요구조건의 목적과 문제를 조사한다. Brook의 논문[Brooks 87]에 따르면 많은 논의는 완성하려고 시도하고(근본적인 어려움), 부적당한 실행(사고적 어려움)을 통해서 생기는 본질적 어려움간의 차이에 의해서 야기된다. 잘 훈련 된 소프트 공학 과정이 많은 어려움을 해결하는 방법과 자세한 기술적 요구조건의 명세서에 집중하는 이유를 의논해 보자. 마지막으로 미래의 어디에서 중요한 진보가 일어날지 토론하고, 기술적 경향을 조사한다.


2. 요구조건과 소프트웨어 생명 주기

 다양한 소프트웨어 생명 주기 모델은 다양한 전문용어로 제안되었다. Davis[Davis 88]은 괜찮은 요약을 제공한다. 그 단계 구체적인 분해와 주변 관리와 제약 구조를 분류하면서 그 모델 핵심요소에서 일반적인 동의가 있다. Figure 1 [Davis 93]은 소프트웨어 개발 단계와  관계된 테스팅 그리고 수용 단계 사이의 관계를 묘사하는 일반적인 모델 버전이다.


 소프트웨어가 큰 하드웨어와 소프트웨어 시스템의 문맥에서 탄생될 때, 시스템 요구사항은 시스템 디자인 보다 먼저 온다. 시스템 디자인은 시스템 요구사항의 부분들이 하드웨어 그리고 소프트웨어에 할당되는 결정을 포함한다. 단지 소프트웨어 시스템에서는, 생명 주기 모델은 소프트웨어 요구사항의 분석과 함께 시작된다, 이러한 관점에서부터, 개발 모델 안에서 소프트웨어 요구사항은 소프트웨어가 대규모 시스템의 일부인지 아니지 상관없이 그림-2[Davis 93.]과 같다. 이러한 이유에서, 우리의 토론의 나머지 부분은 소프트웨어가 대규모 시스템의 부분으로서 개발 될 수 있는지 아닌지 구별할 수 없다. 시스템 대 소프트웨어 논쟁의 개요에서, 독자는 Dorfman 과 Thayer의 조사를 읽어보아라.[Thayer 90]

 대규모 시스템 개발에서, 소프트웨어 요구사항 명세서는 다양한 역할을 한다. :

  # 고객들에게, 전형적으로 요구사항은 무엇이 전달되어져야 하는지를 기술하고, 개발을 위해 계약상의 기초를 제공한다.

  #  관리자에게 그것은 스케줄링에 대한 기초를 제공할 지도 모른다. 그리고 진행을 측정하는 척도가 될 지도 모른다.

  #  소프트 디자이너에게, 그것은 디자인 방향 명세서를 제공할 지도 모른다.

  #  코더에게 그것은 수용가능한 구현의 범위를 제공하고 생산되어져야만 하는 결과에 최종  권한이다.

  #  품질 보증 직원에게는  그것은 유효성, 테스트 계획 그리고 검증을 위한 기초가 된다.


 요구사항은 역시 마케팅과 정부 규제가들 같은 다양한 그룹에 의해 사용되어 진다.


 "기능적“ 또는 ”비기능적“ 같은 소프트웨어 요구사항을 분류하는 상식적인 관례이다. 정의가 구체적으로 어떠한 것을 바꾸더라도 ”기능적“ 시스템 입력 값과 대응되는 출력값 사이의 알맞은 매핑을 정의하는 요구조건을 참조한다.  ”비기능적“은 성능, 의존성, 유지성, 재사용성, 안전성과 같은 제약들을 무제한으로 참조한다.


 널리 사용되어지지만, 기능적, 비기능적으로서의 요구조건의 구분은 전문용어이고 요구조건의 일반적인 다양하고 상식적인  properties, attributes를 이해하는데 도움이 안되서 혼동된다. 좀 더 쓸모있는 구분은 다음 정의를 따르는 ‘행동적 요구조건’과 ‘개발 품질 속성’로서 설명될 수 있다.


  #행동적 요구조건 - 행동적 요구조건은 제공된 구연의 실행시간 행위가 옳은지 그른지 판단하기 위하여 필요한 모든 정보를 포함한다. 행동적 제약 조건은 시스템 결과물(예: 실질값, 정확도, 타이밍) 그리고 모든 사용 가능한 입력, 시스템 상태에 관한 상태의 결과에 대해서 제약들을 정의한다. 보안, 안전, 성능, 타이밍 그리고 예외 허용도는 모두 행동적 요구조건이다.

 

  # 개발 품질 속성 - 개발 품질 속성은 정적인 구조 속성에 관한 제약을 포함한다. 테스트 가능성, 변화 가능성, 유지 가능성, 재사용성의 특징을 포함한다.


 행위적 요구조건은 실행시간 행동의 속성과 비슷한 점이 있고 실행중인 시스템의 행동을 구현 방법에 상관없이 유지함으로서 명백하게 인정된다. 그러나 개발 품질 속성은 정적인 구조(예 : 모듈화)나 표현의 특성이다. 개발 품질 속성은 개발 과정, 생성 방법의 기능과 비슷하다. 개발 품질 속성의 평가는 상대적이다. - 예를 들면, 우리는 디자인이 지속적인지 아닌지에 관해 말하지 않고 어떤 디자인 더 지속적이라고 말한다.


3 . 큰 문제

 요구조건 문제는 널리 퍼져있고 비용이 많이 든다. 그 결과가 정부 문서의  문제이기 때문에 미국 정부를 위한 대규모 소프트 시스템 개발로 인해서 가장 반대 없이 받아드려진다. 소프트웨어가 점점 중대한 부분으로 인식됨으로써, 개발자들은 요구조건의 주요한 원인을 찾았다. 예로서, 미사일 방어 시스템의 개발자가 아래에 있는 말을 했다.

 

  거의 모든 소프트웨어 프로젝트가 성능과 비용 목표를 만족시키는데 실패해서, 요구조건은  프로젝트 실패에 중요하고 값비싼 역할을 부적절하게 수행했다.


  몇 년 동안 문제는 수그러들지 않았다. 미사일 방어 시스템 미션에 대한 문제의  최근 연구는 요구조건이 시스템의 2/3의 큰 문제를 일으켰고 밝혔다.[GAO 92]. 이것은 요구조건이 가장 중요한 소프트웨어 개발 문제로 밝힌  우주항공 회사의 조사와 일치한다.[Faulk 92]의 연구는 NASA의 voyager and gali대 우주선의  소프트웨어 오류와 관련된 안전성의 커다란 원인으로 기능적 인터페이스 요구조건이라 밝혔다.

Boehm[Boehm 81]에 의해 서술되고 여러 번 재발행 되어진 1970년 산업 연구의 결과는 요구조건 오류가 가장 값이 비용이 많이 소요 됨 보여준다. 이러한 연구들은 같은 기본적인 결과를 나타낸다 : 개발과정의 초반에 에러가 나면 나중에 에러가 발견되었을 때 고치는데 많은 비용이 든다. 더구나 관련된 비용은 급속히 상승한다. 그림 3에서 보이는 것처럼 요구조건 단계에서 1달러로 고칠 수 있는 에러가 시스템이 완성되거나 유지보수 단계까지 바로잡히지 않으면 고치는데 100에서 200달러가 들 수 있다.

이러한 실패의 비용은 거대하다. 예를 들면, 1992년 GAO 보고서는 the Chyenny Mountain Upgrade라는 시스템이 요구조건과 관련된 문제에 기인하여 8년이나 늦고 예산을 6억달러 초과하고 원래 계획된 것보다 더 적은 성능을 갖게 될 것이라고 언급했다. 이에 앞선 GAO[GAO 79] 보고서는 그런 문제들이 예외이기 보다는 사실이라는 것을 말해준다. 사 기업으로부터의 결과라서 반대없이 수용하기는 어렵더라도 이 상황이 명백하게 별개의 문제는 아니다. 소프트웨어 공학 방법론과 도구의 지원으로 진보에도 불구하고 요구조건문제는 줄어들지 않았다. 이것은 소프트웨어 공학의 명백한 진보가 환영받는 다는 것은 아니다. 문제의 성격이 바뀌지 않더라도 응용프로그램의 양적, 질적, 복잡성에서 명백하게 증가해왔다. 바람직한 결론은 우리의 소프트웨어 시스템의 대규모 성장은 실제로 적용되는 요구조건 적용 기술로부터 얻는 것보다 앞서가고 있다는 것이다.(소프트웨어 시스템 성장이 요구조건 적용 기술보다 더 빠르게 성장한다).


4. 왜 요구 조건은 어려운가?

 상식적으로 요구조건 단계의 목표가 소프트웨어가 어떻게 하는지가 아니라 무엇을 해야 하는지에 대해서 명백하게 기술하고 확립하는 것이다. 만약 우리가 이루기를 원하는 것이 쉽게 해결된다면 이것은 왜 어려운 것일까? 이것을 이해하기 위해서 우리는 어디서 에러가 발생하는지 알아야 하고 그 일의 성질이 왜  어려움으로 이끄는 이유를 요구조건 단계의 목적을 더 면밀히 고찰해서 알아야 한다.


많은 저자들은 요구조건 단계가 “어떻게”보다는 “무엇을” 서술해야 한다는 것에 대해 전적으로 동의한다. 다른 말로 하면, 요구조건의 목적이 해결이기 보다는 해결되어질 문제를 구체적이고 특수하게 이해하는데 있다. 예를 들자면, ATM system을 위한 요구조건은 소프트웨어 알고리즘과 데이터 구조 대신에 고객 계좌, 예금, 그리고 출금에 대해 언급할 것이 없다. 이것에 관한 가장 기본적인 이유는 문제의 관점에서 볼 때 상세화가 다음의 디자인 또는 구현을 제외한 현재의 요구조건을 얻는다는 것이다. 게다가 소프트웨어 용어의 sol해결은 문제의 상세화보다 전형적으로 더 복잡하고 더 이해하기 힘들다(특히 고객에게).


 불행히도 ‘어떻게’로부터 ‘무엇을’ 구분하는 것은 딜레마다. Davis에 따르면, 다른 것들 사이에서 무엇과 어떻게 사이의 구분은 필연적으로 기능적 관점이라고 했다. 시스템 분해의 어느 선택된 레벨에 상세화를 다음 수준을 위한 ‘무엇’을 기술하는 것으로서 여겨질 수 있다. 따라서 고객은 ‘무엇’과 ‘어떻게’에 대응하는 하드웨어와 소프트웨어로의 dec분해를 정의하기를 원할 수 있다. 그 후, 행동적 요구조건은 소프트웨어 구성 요소를 이것의 ‘무엇’으로 정의하고, 소프트웨어 디자인을 이것의 ‘어떻게’로 정의하는데 배분한다. 요약하면 요구조건이 어느 시스템에 대해서 이야기 하는지, 분해의 어떤 레벨에 대한 것인지에 사전의 동의 없이는 전혀 효과적이지 못하다. 무엇이 문제 영역을 구성하는지, 무엇이 해결 영역을 구성하는지 반드시 동의해야 한다. 요구조건의 분석 그리고 상세화는 해결 공간, 특성은 문제 영역에 속한다.




    

]]> Sat, 5 Apr 2008 00:41:42 +0900 <![CDATA[소프트공학 회의록]]> http://blog.paran.com/blueyellow/25195291

“소프트웨어를 디자인할 때 저는 건축가입니다. 유저 인터페이스를 디자인할 때는 예술가이며, 구현할 때는 장인이 됩니다. 하지만 테스트를 할 때는 아마 쳐죽일 놈이 될 것입니다.”

 소프트웨어 개발은 과학인가? 예술인가? 아니면 단지 장인의 기술인가? 아니면 그 어떤 다른 것인가?


 프로그램을 예술의 관점에서 보는 사람들은 소프트웨어 개발의 심미적인 관점을 부각하고, 과학이 영감에 의한 착상과 창조적인 자유를 허용하지 않는다는 점을 비난한다. 반대로 프로그래밍을 과학의 관점에서 보는 사람들은 많은 소프트웨어들이 믿을 수 없을 만큼 많은 에러를 내포한다는 점을 지적하고, 소프트웨어를 개발할 때 지나친 창조적 자유는 소프트웨어를 믿을 수 없게 만드는 주원인이라고 비난한다. 그러나 두 관점은 모두 불안전하고, 서로 잘못된 질문을 던진다.

 소프트웨어 개발은 예술이며 과학이다. 소프트웨어 개발은 기술이고, 고고학이며, 사회학인 동시에 다른 모든 활동을 포함할 수도 있다. 또, 소프트웨어의 어떤 분야는 아직 미숙할 수도 있고, 어떤 분야은 아주 전문적일 수 있다.


  “무엇이 소프트웨어 개발인가?”가 아니라 “전문적인(professional) 소프트웨어 개발은 어떤 모습이어야 하는가?”여야 한다. 위 질문에 대한 필자의 의견은 다음과 같다.

 “진정한 소프트웨어 개발은 반드시 공학이어야 한다.”

 현재는 그렇지 않지만, 반드시 그렇게 되어야 한다.


소트웨어공학 VS 컴퓨터과학


 과학자는 무엇이 진실인지, 만들어 놓은 가설을 어떻게 테스트할 수 있는지, 또 어떻게 지식을 더 확장할 수 있는지 배운다. 엔지니어는 무엇이 진실인지, 어떤 것이 쓸모가 있는지, 받아들은 지식을 사용하여 실무상의 문제를 어떻게 해결하는지에 대해 배운다.

 과학자는 항상 최근의 논문이나 연구에 촉각을 곤두세워야 한다. 그러나 엔지니어는 효율적이고 믿을 수 있다고 증명된 지식에 익숙해 져야 한다.

 과학을 전공한다면 특정 전문 지식만을 연구해도 되지만, 공학을 전공한다면 현재 만드는 제품에 관계되는 모든 분야의 지식을 두루 익혀야 한다.


소프트웨어공학이라는 단어 뒤에 숨겨진 의미


"공학“의 사전적인  의미는 수학의 원리와 과학을 응용하여 실세계의 문제를 해결하는 것이다. 이야말로 대부분의 프로그래머가 추구하는 것이다. 즉, 과학적으로 발전하고 발전하고 수학적으로 잘 정의한 알고리즘, 실용적으로 디자인한 방법론, 이미 안전하다고 알려진 방법 등을 실세계에 적용해서 소프트웨어 제품과 서비스를 개발하는 것이다.


 실세계의 문제를 해결하기 위해 과학의 원리를 응용하는 것이 공학이다. 공학이 현실적이지 않다면 그것은 공학이 아니다.


 소프트웨어를 만드는 것을 공학으로 간주하면 모든 문제는 명확해진다. 각각의 프로젝트에 적절한 개발 방법론을 적용하면 된다.

 소프트웨어 프로젝트는 물리적인 물체를 다루는 다른 공학 분야와 다르다. 타 공학 분야는 평균적으로 재료비가 전체 프로젝트 비용의 50% 이상 소요되고, 어떤 분야에서는 인건비 비율이 전체 프로젝트 비용의 50%가 넘어가도 위험도가 큰 프로젝트로 간주한다. 그러나 전형적인 소프트웨어 프로젝트의 경우 전체 프로젝트 비용 대부분이 인건비에서 소요된다.


 의학장비, 항공 전자 기기등에 포함되는 소프트웨어는 거의 결함이 없는, 완벽에 가까운 정확성을 요한다. 이러한 분야말로 모든 소프트공학을 적용시킬 수 있는 적절한 곳이다. 하지만 다른 몇몇 프로젝트에서는 어는 정도 믿을 수 있을 만큼의 신뢰도만을 갖추는 대신, 비용을 별로 들이지 않고 프로젝트를 빠른 기간 내에 끝내기를 원하는 곳도 있다. 엄밀하게 이것도 소프트웨어공학에 포함시키자.


 비용을 높이고 스케줄을 엉망으로 만드는 주범인 일단 작성하고 고쳐보자는 개발은 절대 소프트웨어공학의 결과가 아니다.


                         Chaper 5

                 지식체계


 브룩스는 소프트웨어 개발에서 가장 어려운 것은 한 컨셉을 특정 프로그래밍 언어로 충실하게 표현하는 것(코딩)이나, 그 표현이 정확한지 확인하는 것(테스팅)이 아니라고 말했다. 그의 관점에서 코딩과 테스팅은 소프트웨어 개발에서 단지 우유적 속성일 뿐이고, 소프트웨어 개발의 본질은 서로 맞물려 돌아가는 여러 컨셉들을 명세화하고 설계하며 검증하는 것이라고 주장했다.

 

 브룩스는 웅적 속성에서는 더 이상 발전될 게 없다고 말했다. 예를 들어 고수준 언어나 통합 개발 환경 등이 이미 소프트웨어 개발에 적용돼, 우유적 속성(코딩/테스팅)이 많은 부분 개선됐다는 것이다.


 그는 앞으로 대규모 생산성 증가는 오직 소프트웨어 본질적 어려움(복합성, 일치성, 변화 가능성, 비가시성등)들을 해결할 때만 이루어진다고 주장하였다.


  변하지 않는 핵심 잡기


 브룩스가 소프트웨어 개발의 “본질적 어려움”이라 부른 것들을 극복하기 위해 필요한 지식은 바로 소프트웨어공학 지식체계의 핵심을 이루는 “소프트웨어공학 원칙”들이다.

 

  SWEBOK은 전문 소프트웨어 엔지니어가 반드시 갖추어야 할 능력을 구성하는 지식영역을 식별하였다.

 * 소프트웨어 요구사항(Software Requirements)  : 소프트웨어에서 구현될 기능들의 발견, 기록, 분석


* 소프트웨어 설계(Software Design) : 아키택처 레벨 또는 상세 레벨에서의 시스템 기본 구조 정의, 모듈별 분할, 모듈의 인터페이스 정의, 모듈 내의 알고리즘 선택


* 소프트웨어 구축 (software construction) : 상세 설계, 코딩, 디버깅, 단위 테스트, 테크니컬 리뷰, 성능 최적화를 포함하는 소프트웨어 구현, 이 영역은 소프트웨어 설계, 테스팅 영역과 조금은 겹친다.

 * 소프트에어 테스팅(Software Testing) : 결점을 발견하고, 기능을 평가하기 위한 소프트웨어 실행과 관련한 모든 활동, 테스팅은 테스트 계획, 테스트케이스 설계 이외에 개발 테스트, 단위 테스트, 컴포넌트 테스트, 통합 테스트, 시스템 테스트, 회기 테스트(regression test), 스트레스 테스트, 인수 테스트 등


* 소프트웨어 유지보수(Software Maintenance ) : 소프트웨어 , 관련 문서들의 개정 및 개선


* 소프트웨어 형성 관리(Softwore configuration Management) : 소스 코드, 컨텐츠(그래픽, 사운드, 텍스트, 비디오), 요구상항, 설계, 테스트 자료, 추정 ,계획, 사용자 설명서 드의 소프트웨어 프로젝트에서 생성된 지적 재산에 대한 식별, 기록, 변경 통제

*소프트웨어 품질  *소프트웨어 공학 관리  * 소프트웨어공학 툴과 방법론 * 프로세스


 

토론 


임준혁 : 자 그럼 지금부터 소프트웨어개발에서 소프트웨어공학이 왜 필요한지에 대해 토론해 보죠.


조민준 : 소프트웨어을 개발하는 목적은 현실적으로 이상적인 알고리즘을 구현하기 위함이 아니라 최종적인 물건을 만들어서 판매하는데 목적이 있는 것 같습니다. 따라서 소프트웨어 를 개발하는 것도 공학적인 마인드가 필요하고 결국 소프트웨어라는 것은 이익을 창출하기 위한 도구로 생각되어져야 한다고 생각합니다. 다른 공학과는 다르게 소프트웨어를 개발하는데는 인건비가 프로젝트 비의 대부분을 차지하게 됩니다. 따라서 책에 나온것과 같이 소프트웨어를 개발하는데는 있어서는 완벽한 소프트웨어를 만드는 것 외에도 짧은 일정 예측, 가능한 납품기한, 저비용, 소규모 팀, 프로젝트 도중에 변할수 있는 유연성 이라는 목표들을 만족해야합니다. 이러한 목표를 만족하기 위해서는 막무가내식 프로그램을 만드는 것보다는 전체적인 방향제시가 필요할 것입니다. 이러한 방향제시를 효율적으로 해줄 수 있도록 배우는 학문이 소프트웨어 공학이라고 생각한다.


고세영 : 책에 보면 ‘진정한 소프트웨어 개발은 반드시 공학이어야 한다’라는 구절이 나옵니다. 그리고 현재는 아니라고 대답을 하고 있습니다. 현실적으로 학부 수준의 교육을 받은 대학생이 사회로 진출하면 제대로 된 교육을 받지 못하고 학자적인 마인드를 갖춘 상태에서 공학적인 업무를 수행해 나가야 합니다. 실무 세계에서는 이러한 상태로 업무를 수행하게 된다면 생각지도 못한 많은 벽에 부딪힐 가능성이 큽니다. 왜냐하면 소프트웨어를 개발함에 있어서는 반드시 최고의 효율성을 가진 알고리즘을 가지고 코드를 만들어야만 하는 것이 아니기 때문입니다. 개발 비용, 기간, 신뢰성 등이 현재 프로젝트마다 요구하는 수준이 달라질 수 있기 때문입니다. 즉, 이론과 실제가 다르기 때문에 소프트웨어를 개발함에 있어서 어떠한 적절한 개발 방법론이 있어야 한다고 생각을 하고, 바로 이런 부분이 소프트웨어공학이 필요한 이유라고 생각합니다.


임준영 :  소프트공학은 컴퓨터과학과 달리 어느 한 분야만 전문적으로 하는 것이 아니에요. 공학적인 특징인 경제성, 고객의 만족성, 정확성 등은 고려해야 하기 때문입니다. 어느 한 부분이 잘 되었다고 해서 그 프로젝트가 성공한 것이 아니기 때문입니다. 그래서 프로젝트를 공학적인 방법으로 관리하자는 것입니다. 그래야 프로젝트가 성공할 수 있기 때문입니다. 비록 소프트공학이라는 학문이 미완성 이지만, 이러한 공학적 방법이 프로젝트를 성공시킬 수 있기 때문입니다.


사회자(임준영) : 소프트공학자 되기 위한 방안이 무엇인지 토론해 봅시다.


고세영 : 의학, 과학 등과 같은 학문은 소프트웨어 공학에 비해서 학문적 체계가 정립된지 더 오래 되었습니다. 때문에 이 분야의 전문가가 되려고 할 때는 어느 정도 학문적인 코스라던지 자격증등 필수적으로 밟아가야 하는 길이 있습니다. 하지만 5장 지식체계에 나와있듯이 소프트웨어 공학 분야는 그 역사가 짧고 어느 것이 본질적인 속석의 지식인지 우유적인 속석의 지식인지가 불분명하고 교육체계 또한 제대로 정립이 되어있지 않습니다. 때문에 오늘 배운 지식이 당장 내일은 필요 없어지게 될 수도 있습니다. 가령 코볼이나 알골 포트란 같은 프로그램 지식은 오늘날에도 여전히 쓰이고 있지만 과거에 비해서 그 중요도와 사용이 많이 줄어들었습니다. 소프트웨어 공학자가 되기 위해서는 이렇게 가변적이고 우유적인 지식보다 평생 도움이 되는 본질적인 지식을 반드시 배워야 합니다. 그러나 현실적으로는 이러한 요소들이 혼재하고 있고, 시장 변화상황에 따라서 교육이 그것을 쫓아가기 바쁩니다. 때문에 소프트웨어 공학 분야에서도 지식체계를 확실히 정립하고 그것을 제대로 이수한 인재를 양성하는 것이 중요하다고 생각합니다. 이와 같은 이유로 저는 소프트웨어 공학자가 되기 위한 방안으로 학문적 체계의 정립을 꼽겠습니다.


조민준 : 일단 기본적으로 인지해야 할 사항이 소프트웨어 공학과 컴퓨터 과학과 다르다는 것입니다. 소프트공학이 필요한 이유에서 언급해야 했듯이 소프트웨어를 개발하는데 있어서 가장 효율적인 방향을 제시해 주는데 있습니다. 소프트웨어 공학자는 획기적인 새로운 알고리즘을 만들어내는데 목적이 있는것이 아니고, 현실적으로 최대의 이익을 창출해 낼 수 있는 프로젝트를 진행하는데 목적이 있는 것입니다. 따라서 소프트웨어 공학자가 되기 위해서는 프로젝트를 진행하는데 효율적인 방향을 제시 할수 있어야 하며, 그러기 위해서는 소프트웨어 개발에서 필요한 많은 지식을 알고 있어야 합니다. 이 지식을 바탕으로 현제 자신이 진행하고 있는 프로젝트에서 가장 적합한 기술을 적용시킬 수 있어야 합니다. 소프트웨어 개발에 있어 얼마나 많은 지식을 가지고 있고 이를 얼마나 효과적으로 사용할 수 있는냐가 소프트웨어 공학자의 역량이라고 생각합니다. 결국 소프트웨어 공학자가 되기 위해서는 소프트웨어 개발에 필요한 많은 지식을 알고 있어야 하며, 이러한 지식은 특수한 곳에서 사용되어지는 전문적인 기술이 아니라 일반적으로 사용되어지는 기술이어야 합니다. 또한 이러한 기술을 가장 경제적으로 적재 적소에 잘 적용시킬 수 있는 공학적인 마인드도 필요하다고 생각합니다.



임준영 : 우선 프로젝트를 성공시키기 위해서는 전체를 보아야 한다고 생각합니다. 어느 한 부분만 잘했다고 해서 성공한 프로젝트가 아니기 때문입니다. 먼저 고객의 요구사항을 정확히 아는 것입니다. 그러기 위해서는 많은 대화가 필요합니다. 그리고 프로젝트가 고객들이 요구하는 변화를 수용할 수 있도록 융통성 있게 만들어져야 합니다. 그리고 뒤부분에도 나와 있지만, 공학자는 전체에 대한 설계 기술을 향상시켜야 합니다. 그러한 설계를 바탕으로 세부적인 구현과 서로 간에 설계도를 보고 의사소통을 할 수 있기 때문입니다. 구현에 있어서는 막상 설계해 놓고 구현할 수 있는 알고리즘이나 최적화 문제들을 해결하기 위해 전문 서적들을 많이 보아야겠습니다. 막상 구현했다고 해서 오류가 없는 것이 아니기 때문에 합리적인 테스팅 시스템을 개발해야 겠습니다. 또, 이미 많은 테스팅 방법이 나와있기 때문에 적합한 테스팅 방법을 선택해야 겠습니다.

 프로젝트는 혼자 하는 것이 아니라, 여러 사람이 하는 것이기 때문에 관리(Management)가 중요합니다. 이러한 관리 방법을 숙지해야겠죠.

 책에도 나와 있듯이 너무 많은 범위를 포함하고 있지만, 이러한 것을 만족해야 무결한 소프트가 나온다니 꾸준히 노력해야 겠습니다.



]]> Sat, 22 Mar 2008 00:05:05 +0900 <![CDATA[단어]]> http://blog.paran.com/blueyellow/25195015

return

환불


repository

저장소

ephemeral

하루살이의 


ternary

3진의


proposition

제안, 계획


propagate 

널리 퍼지다. 선동하다.


at odds with

~ 와 다투다. 싸우다.


fledgl


미숙한 , 깃털이 막 난


foothold 

발판


momentum

추진력


make comply with

순응하다.


delegation

대표단.


]]> Fri, 21 Mar 2008 23:37:56 +0900 <![CDATA[3장 끝 - 해커스 토익]]> http://blog.paran.com/blueyellow/24977566

retreat 

후퇴, 피난, 퇴각

물러나다.


hammer out

(문제, 곤경 따위를) 해결하다. 타개하다.


stubborn

완고한


at the earliest

빨라도


crony

친구, 옛벗


colony

식민지


exodus

대이동, 이주, 탈출


tray

쟁반


blanket

담요


bill

계산서, 지폐


arrange for a shuttle

셔틀버스를 준비시키다.


loan application

대출 신청서


savings account

저축 구좌


deposit

잔고


balance

차액


overdraw

잔고 이상으로 인출하다.


filling

충전재(치과에서)


scaling

치석 제거


optometrist

검안사 (시력을 검사하는 사람)


eyesight 

시력


dimmed

침침한,


blurred

흐릿한

+

tablet

정제


dose

일회 복용량


pill

알약


departure

출발지


carrousel

회전식 컨베이어 벨트


baggage claim area에서


baggage receipt

가방 수령증


insurance agency

보험회사


coverage

보상범위


cover

보상하다.


policy

보험증권


breajkage

파손


real estate agency

부동산 중개소


property

재산, 토지


payroll department

급여 지불 부서


paycheck

급료


payroll

임금 대장


pay day

급여일 


service station 정비소


fill up the tank

연료를 채우다.


run out of the gas

가스가 떨어지다.


electricity usage

전력 사용량


take the expressway

고속도로를 타다.


meter goes up

미터기기 올라가다.


take 

데려다 주다


cabin

오두막집, 객실


overhead compartment

좌석 위 짐칸


pull over

~ 을 대다.


deck

갑판

dock

부두


overview

개요


review

조사하다. 깊이 생각하다. 평론하다.


packet

소포.


generator 

발전기


cord 

코드


regimen

식이, 운동요법


slacks 

(복수 형태) 바지.


submission

제출물, 제출


delicate

맛있는, 섬세한, 깨지기 쉬운


function 

모임


nail

못, 나사

wrench

스패너

back order

이월하다.

in bulk

대량으로

mail forwarding service

우편물 수령지 변경 서비스

resume

다시 재개하다.

typo

인쇄상의 오류

formula

제조법

redo

다시 변경하다.

transaction

거래

the other day

며칠 전

reserve the charge

비용을 보존하다. 되돌려 받다.

get ahold of

와 연락이 되다.

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\


return

환불

]]> Fri, 7 Mar 2008 07:44:10 +0900 <![CDATA[1.1.1 ~2]]> http://blog.paran.com/blueyellow/24975239

1.1.1  1.1.2


 인텔 IA - 32 프로세서 계열에 속하는 마이크로프로세서를 위한 프로그래밍에 초점을 두었다.


 어셈블리언어는 가장 오래된 프로그래밍 언어이자 모든 언어 중에서 컴퓨터 본래의 언어에 가장 가까운 언어


 어셈블리 언어는 컴퓨터 하드웨어 직접적인 액세스를 가능하게 함.


 컴퓨터의 구조와 운영체제에 대하여 아주 많이 이해해야 함.


  여러분은 오늘날 가장 폭넓게 사용 중인 마이크로프로세서에서 자신의 지식을 테스트할 정도로 어셈블리 언어를 배울 것이다. 프로그래머의 관점에서 인텔 IA - 32 프로세서 계열의 구조를 배울 것이다.


Some Good Question to Ask


어셈블러란 무엇이냐? 어셈블러(assembler)는 어셈블리 언어로 작성된 소스 코드를 기계어로 변환하는 프로그램이다. 어셈블러는 옵션에 따라서 소스 일람 파일을 생성할 수 있다. 라인 번호, 메모리 주소, 소스 코드문, 프로그램에서 사용되는 심벌과 변수들의 상호참조 등을 함께 만들 수 있다. linker는 어셈블러에 의하여 생성된 각각의 파일들을 하나의 실행 파일로 합친다. 세 번째 프로그램으로서 debugger는 프로그래머가 프로그래머가 프로그램의 실행을 추적하고 메모리의 내용을 살펴보기 위한 수단으로 사용된다. 인텔 계열을 위한 가장 유명한 어셈블러 두 개는 MASM(microsoft Assembler)과 TASM(Borland Turbo Assembler)이다.


 어떤 하드웨어와 소프트웨어가 필요한가?  인텔386, 인텔486, 혹은 펜티엄 프로세서를 갖는 컴퓨터가 있어야 한다. 이런한 프로세서는 모두 IA - 32 프로세서 계열에 속함.


  * 편집기 :  아스키 문자 파일을 만들 수 있는 어떤 편집기 또한 사용 가능함.

  * 어셈블러 : 이 책의 CD - ROM에 있는 무료로 제공되는 마이크로소프트 어셈블러(MASM)가 필요함.

  * 링커 : 실행 파일을 생성하기 위하여 링커가 필요하다. 우리는 이 책의 CD - ROM에 LINK.EXE라는 이름의 마이크로소프트 16비트 링커와 LINK32.EXE라는 마이크로 소프트 32비트 링커 두 개를 제공한다.


  * 어떤 유형의 프로그램을 만들까?

    32비트 보호 모드 : 마이크로소프트 윈도를 사용한다면, 여러분은 문자와 그래픽을 함께 표시하는 32비트 보호 모드 프로그램을 작성할 수 있다.


 * 책에서 제공하는 링크 라이브러리의 소스 코드들, 하나는 MS 윈도 하에서의 32비트 부호 모드를 위한 것이고 다른 하나는 MS - DOS나 DOS 애뮬레이터 하에서의 실제 주소 프로그래밍을 위한 것이다.(주의 : MS 윈도는 실제 주소 모드 프로그램 또한 수행할 수 있다.)


무엇을 배울까?

 

 인텔 IA -32프로세서 계열에 응용되는 컴퓨터 구조에 대한 몇 가지 기본적 원리를 배운다.


 몇 가지 부울 논리를 배우고 어떻게 그것을 프로그래밍과 컴퓨터 하드웨어에 응용하는지를 배울 것이다.


 IA-32 프로세서가 어떻게 실제 모드, 보호 모드, 그리고 가상 모드를 사용하여 메모리를 관리하는지 배울 것임.

 

 여러분은 어떻게 고급 언어 컴파일러가 그들의 언어로 기술된 문장으로부터 어셈블리 언어와 기계어로 번역하는지를 배울 것임.


 어떻게 고급언어가 수식, 루프, 그리고 논리적인 구조를 구현하는지를 기계어 수준에서 배울 것임. 부호 있는 정수와 부호 없는 정수, 실수, 그리고 문자 데이터를 포함하는 데이터 표현에 대하여 배울 것이다.


 여러분은 기계어 수준의 디버깅 기술을 습득할 것이다. C++에서조차 프로그램이 포인터나 메모리 할당 오류를 가질 때 기계어 수준으로 문제를 파고들어 무엇이 잘 못되었는지를 발견할 수 있다. 고급 언어는 기계어 수주의 상세한 것을  일부로 숨기지만, 가끔 이러한 상세한 것들이 오류를 추적하는데 중요하다.

 

 여러분은 어떻게 응용 프로그램이 인터럽트 핸들러, 시스템 호출, 공통 메모리 영역을 통하여 컴퓨터의 운영체제와 통신하는지 배울 것임.  또한 운영체제가 어떻게 응용 프로그램을 적재하고 실행하는지를 배울 것임.


 * 어셈블리 언어는 기계어와 어떻게 연관 ?


 기계어(machine language)는 컴퓨터의 프로세서가(CPU)가 이해하는 숫자 언어이다. 인텔 프로세서는 다른 인텔 프로세서가 이해할 수 있는 기계어를 가지고 있다. 기계어는 완전히 수로 이루어져있다.

 

  어셈블리 언어(assembly language)는 ADD, MOV, SUB, CALL등과 같은 짧은 니모닉을 사용한 문장들로 이루어져 있다. 어셈블리 언어는 기계어와 일대일(one - to -one)의 대응관계를 갖는다. 이는 어셈블리 언어 명령 ‘하나’가 기계어 명령 ‘하나’와 대응함을 뜻함.

(레지스터는 연산의 중간 결과를 저장하는 데 사용되는 CPU내의 저장공간이다.)


 어셈블리 언어 문장들은 기계어와 일대일로 대응한다. 기계어는 프로세서에 특별한 의미를 갖는 코드화된 숫자이다.


 어셈블리 언어는 이식 가능한가? 어떤 언어의 소스 프로그램이 다양한 컴퓨터 시스템 상에서 컴파일 되어 수행될 수 있을 때 이식성이 있다(portable)이라 말한다. 어셈블리 언어에서 명령어들은 컴퓨터 명령어 집합과 일치한다. 이 책에서 소개하는 어셈블리 언어는 인텔 IA -32 계열에 하는 프로세서 상에서 동작한다.


 왜 어셈블리 언어를 배우는가? embedded system 컴퓨터 게임 전용 기기는 프로그램의 저장 공간과 실행 속도를 최적화하기 위하여 메모리 제약이 엄격하다. 게임 프로그래머는 특정한 하드웨어 특성을 최대한 활용하는 코드를 작성하는 데 전문가다. 게임 프로그래머들은 기계어 코드 이상으로 어셈블리 언어가 기계를 완전히 제어하기 때문에 어셈블리 언어를 사용한다. 일반적으로 프로그래머들은 데이터 암호화와 비트 처리 등 문자 연산에 있어서 C++나 어셈블리 언어로 작성된 동적 링크 라이브러리(DLL :Dynamic link library)에 의존한다.


 하드웨어 제조회사에서 일한다면, 장치 드라이버를 만들어야만 할지도 모른다. 장치 드라이버(device driver)는 일반적인 운영체제 명령어를 세부적인 하드웨어 동작으로 변환해 주는 프로그램이다.


 어셈블리 언어에는 어떤 규칙이 있는가? 프로세스의 물리학적인 한계와 명령어 집합에 기인하는 몇 가지 규칙이 있다. 예를 들어, 같은 명령에서 사용되는  두 개의 피 연산자는 같은 크기여만 한다.

  어셈블리 언어는 고급 언어의 제한을 쉽게 피할 수 있다. 예를 들어, C++언어는 한 형식의 포인터를 다른 형식의 포인터로 할당할 수 없다. 보통 이것은 프로그램에서 논리오류를 피하게 해주기 때문에 좋은 제한이다. 어셈블리 언어는 포인터와 관련하여 어떤 제한점도 없다. 포인터의 할당은 프로그래머의 재량이다. 물론 어셈블리 언어 프로그래머는 기계 수준의 프로그램 디버깅을 위해 많은 시간을 소비해야 하는 등 그러한 자유에 대한 대가가 매우 크다.

]]> Thu, 6 Mar 2008 23:22:52 +0900 <![CDATA[테이블 생성 문법]]> http://blog.paran.com/blueyellow/24739164

테이블을 생성하기 위해서는 테이블 이름, 하나 이상의 열 이름과 데이터 타입이 와야 한다. 나머지는 모두 옵션이다.

CREATE TABLE 테이블명(

{열이름 데이터 타입 [NOT NULL] [DEFAULT 기본값], .....}


[PRIMARY KEY 열이름],

{[UNIQUE 열이름]},

{[FOREIGN KEY 열이름 REFERENCES 테이블명(열이름)]

[ON DELETE　옵션]

[ON UPDATE 옵션]},

[CONSTRAINT 이름] [CHECK(조건식)]}

]]> Wed, 20 Feb 2008 04:51:23 +0900