Introduction
When I first started studying requirements specifications and teaching
classes on them in the late 1970s, .I recognized that writing good
requirements was very difficult. I worked hard to remove and help others to
remove every trace of ambiguity from each and every requirement. I was
convinced back then that a polished word-processed requirements document was
the only right way to record requirements. As I gained more and more
experience, I started to realize that ambiguity could never be entirely removed
from a requirements document as long as it was written in natural language. So,
I started to explore alternate ways of documenting requirements.
By the mid-1980s, my solution to the problem of ambiguity in
requirements was to use more and more formalism. Formalism allows requirements
writers to remove some of the ambiguity by replacing natural language with
notations that possess unambiguous semantics. By 1990, I had written a book
titled Software Requirements that explored many of the rich notations
that had been developed to help people write requirements less ambiguously.
By the mid-1990s, I was experiencing more and more pushback from
customers. Computer science savvy customers embraced the notations. Of course
the software engineers loved the formalisms such as finite state machines,
decision tables, Petri nets, statecharts, and so on. However, a very large
majority of customers I was meeting were not computer science savvy. And they
had no interest in being educated in computer science. What they wanted was
very simple: to have their real-world problems solved.
Around the turn of the millennium, I realized that there is a reason
that we communicate on a day-to-day basis in our natural languages. It works.
One secret of writing good requirements then is to write them primarily in the
language of the customers. What language is spoken and understood by the
hospital administrator looking for a new patient records system? What language
is spoken and understood by the military officer interested in procuring a new
weapon control system? What language is spoken and understood by the marketing
person looking for a new way to build a website quickly? What language is
spoken by the employee in an operating division of any company? Answer: natural
language.
However, the days of large word-processed requirements documents are
over. There are now too many things that a manager needs to do quickly and
which a word-processed document simply cannot provide quickly. For example, a
manager needs to know:
7
How many requirements are there?
7
How many high-priority
requirements have been delayed to Release 3.0?
7
What percent of the requirements
for Release 2.0 are low priority?
7
Which requirements in Release 2.0
are high priority, being built for Customer X and are the responsibility of
Sally?
It is the need for quick
answers to questions like these that help me reach the conclusion that the only
way to record requirements when pressed for time is as a list of discrete
requirements, each annotated with multiple attributes.
Having a list of requirements solves many problems, but it misses a
major purpose of creating requirements in the first place. We create
requirements to address needs, or markets. Without a thorough understanding of
those needs, we are wasting our time. What good are perfect requirements,
nicely worded, and nicely laid out in a table, if they fail to address the
customers needs?
What Is a Requirement?
The primary purpose for writing requirements is to document the common
understanding of what system is to be built.
A requirement is an externally
observable characteristic of a desired system.
To determine if a candidate requirement is a valid requirement, it
simply must pass two tests: (1) is it possible to observe the satisfaction of
the requirement from a point of view external to the system, and (2) does the
requirement help to satisfy some need of the potential customer or other
stakeholder. Lets look at some examples and determine if they are in fact
valid requirements. Lets imagine that we are at a company in the 1980s and we
want to define requirements for the first remote mouse. Somebody suggests,
The system shall have three buttons.
To determine if that a valid
requirement, we need to look at the two criteria:
7
Externally observable. Yes. Clearly, when the mouse is
built, we can easily observe (with our eyes in this case) that the mouse does
or does not have three buttons.
7
Desired. To determine this, we need to ask the customer(s)
and/or user(s). It is possible that the customer would be satisfied with any
method of moving slides forward, moving slides backward, and displaying a menu,
in which case, having three buttons is not a requirement; the right requirement
would be,
The system shall provide a means to
enable users to move slides forward, move slides backward, and display a menu.
On the other hand, the
customer may really want three buttons! In which case, the original statement
of the requirement is valid.
Next somebody suggests,
One of the systems three buttons
shall be 2 long, 1 .1; .5
wide 1 .0125; and .0625
tall, 1 .00001.
To determine if this a valid
requirement, we need to look at the same two criteria:
7
Externally observable. Yes. Clearly, when the mouse is
built, we can easily observe (in this case, using a linear measuring device)
that a mouse button does or does not have these dimensions.
7
Desired. To determine this, we need to ask the customer(s)
and/or user(s). If the user was planning to use a thumb to push the button,
then this level of detail seems too restrictive. On the other hand, the
customer may really need precisely these dimensions, e.g., the plan might be
for the button to be pressed by an already-built robot., and the robotic finger
has precisely the accuracy indicated in this requirement! In this case, the
statement of the requirement is valid, and nothing less specific will do.
What we see from the above examples is that nobody but the customers
and/or users can determine if a candidate requirement is a valid requirement.
Furthermore, it is impossible for anybody to walk into your office, examine
a requirement and tell you that it is either too detailed or too vague. The
correct level of detail is completely dependent on the needs of the customers.
Requirements
management is the set of activities
of gathering requirements, deciding which are the right ones to satisfy, and
documenting them. Requirements elicitation is that subset of
requirements management dealing with gathering candidate requirements from
customers, users, subject matter experts, and other stakeholders. Requirements
triage is that subset of requirements management dealing with determining
which requirements should be satisfied when analyzed within the context of
available development resources, time to market, revenue goals, and return on
investment. Requirements specification is that subset of requirements
management dealing with documenting the external behavior of the desired
system.
Until the popularity of the Capability Maturity Model (CMM) [PAU93],
software companies had no yardstick for measuring how mature their software
development process was. Although far from perfect, the CMM does at least give
us that yardstick. And its use has become fairly widespread. Through level 3 of
CMM (There are five levels of maturity in CMM numbered 1 to 5), an organization
strives to make its software process more repeatable and more measurable
through documentation and institutionalization of specific process
improvements. Although CMM does not demand that the institutionalized process
be heavy, many companies on the CMM path (and many of the assessors) seem to
think that it does. The result is that organizations are both gaining (via
improved repeatability and measurability) and losing (via adopting excessively
slow and tedious methods). In a "time to market economy, this can be
deadly.
On the other extreme, since the mid-1990s, many companies have
reverted to the practices of the 1960s, where little or no process exists.
Initiated by the dot-coms, these organizations believe that new applications
such as eCommerce, web sites, and portals are somehow so unique that they need
not apply even the most basic principles of software engineering learned over
30 years [DAV95]. Many factors led to the crash of the dot-coms at the turn of
the millennium, but one factor certainly was the lack of intelligent requirements
management. Symptomatic of such a company is the wanton and random inclusion of
requirements by coders, with no thought about how such changes affect product
quality, product usability, customer satisfaction, or probability of completing
on schedule or budget. A variant of this is agile development [HIG01, COC02] in
which requirements are not documented, but are instead imparted in real-time by
the customer to the developer as needed. The problems with this are many: (a)
the customer has his/her own job to perform and cannot be at the beck and call
of the development team, (b) customers come and go, and if the only contracts
are oral, havoc and disappointment can result, (c) one customer cannot be
expected to be able to speak for all stakeholders, except under the most
trivial of circumstances, and (d) developers come and go, so expectations must
be written.
Neither of these two
extremes represents the right amount of requirements process for all
companies, or even for all projects within any one company. The right place to
be on this scale depends on many factors including the corporate culture,
time-to-market pressure, criticality of the application, and so on. The right
place to be on the scale is the place where you have just enough process
to minimize your risks sufficiently.
Requirements Errors
Three general classes
of requirements errors exist:
7
Knowledge errors. A knowledge error occurs when a
requirement is not known. It may be known by the customers but not the
development organization, or it may be unknown by all parties. If a requirement
is known by the customers, but the development organization fails to learn
about it, it is a clear indication of poor elicitation. Some requirements
however are not known by anybody. In such cases, techniques like prototyping
may be helpful because the more functionality that the customer sees, the more
requirements the customer will think of. However, often the best way to uncover
requirements that nobody knows yet is to plan to deliver the product incrementally.
Each time customers receive a release, they will quickly think of dozens of
more functions they would like to have. Some developers find this upsetting;
they complain that the customers are never happy. I prefer to think of this as
healthy. It is a fact that the number of new requirements the customers will
think of is proportional to the number of requirements that are satisfied
[BEL76]. This is not unlike Maslow's hierarchy of needs [MAS70]; if you provide
a bicycle to a starving child, she will not appreciate it. As soon as you
provide her with food, she will then desire a bicycle. So, developers should be
pleased when new requirements emerge soon after product delivery. It means they
are satisfying real needs with the current system.
7
Triage errors. A triage error occurs when a requirement or
set of requirements is selected for inclusion in a release, but the resources
available to that release are insufficient to address them. After learning a
requirement that needs to be satisfied, one needs to be realistic relative to
the practicality of satisfying it given available time, money and other
resources. Repeated late deliveries of products can be a symptom of a process
that disregards triage errors.
7
Specification errors. A specification error occurs when a
requirement is known, is correctly selected for inclusion in the product, but
is documented in a manner than does not ensure a common understanding by all
parties. If a requirement is stated in an ambiguous fashion, for example,
customers may expect a function to behave in a manner different than as
implemented by the development team. If a requirement is stated in an ambiguous
fashion, for example, two developers may make different assumptions about what
the requirement means, and can waste considerable resources in resolving the
conflict, or worse, the resulting system may behave in an unreliable or
unpredictable manner.
Requirements Elicitation
Requirements elicitation is known by many other names, including
systems analysis [COU73, KEN01], problem analysis [DAV93], inception [ROY98],
analysis [MCL01], needs analysis [FLE02], and mission needs assessment [USA97].
Although there are likely subtle differences among the meanings of these terms,
they are basically the same concepts.
The process of elicitation usually includes involvement with
stakeholders. Stakeholders are people (and perhaps organizations and other
systems) who will in some way be affected by the presence of a new system.
Stakeholders include customers, users, marketing, development, testers, loser
users [GAU89], and customer support personnel. This heterogeneous set of
stakeholders highlights that determining requirements is non-trivial. Extreme
Programming [BEC99], one example of agile development, [COC02, HIG01]
recommends that a customer be present at all times to guide development.
Unfortunately one customer cannot speak for all the diverse stakeholders.
Elicitation is not just a phase that a project goes through.
Elicitation is something that can never stop occurring. After all, when can you
ever afford to stop listening to the customer? It is true, however, that in a
typical product development, elicitation activities accelerate dramatically
soon after the parties agree to the need of a new product or a new release of
an existing product.
In an attempt to do "just enough"
requirements management, you might be tempted to dispense with elicitation.
After all, it could take a long time to meet stakeholders and learn their
needs. The trade-off is one of risk. If you do not do elicitation, you run the
risk of building the wrong system. A "wrong system" implies unhappy
users, unsatisfied customers, a product that is not used by the intended users,
a product that does not provide an adequate return on investment, and if a
commercial product, one that will not sell. For me building a wrong system is
the ultimate project failure.
On the other hand, doing elicitation may result in a delay to
the delivery. However, it is more than likely that doing elicitation will not
result in a delay greater than if elicitation is not performed. Of course, if
you spend a ridiculous amount of effort doing elicitation, the project
inception will be unduly delayed, and of course the product will be delivered
late. On the other hand, if you do not do elicitation, requirements changes
during development are likely to be more insidious and more persistent.
Not doing elicitation is equivalent to saying "I am not going to
find out from my customers what they need. This might make sense to an
individual who lives in a closet. But the reason we build software is not
mental exercise; it is to solve real problems. And the only way to solve real
problems is to understand those problems.
The trick to performing elicitation in a "just enough"
manner, it to (1) select the right techniques, and (2) use them intelligently.
Unfortunately, many of the requirements methodologies prescribed today advocate
an elicitation technique. The rules of good elicitation are not much different
than the rules of any process that involves communication:
7
Care
7
Show the Stakeholders How Smart You Think They Are
7
Listen
7
Prepare for Change
7
Don't Worry So Much About the Method
7
Maintain a Glossary
Given the above caveats, it is still useful to be aware of basic
elicitation techniques, and when to apply them. For any technique you are
considering, if you have to take a week-long course on how to perform it, you
are doing it all wrong. These techniques should be instinctive once you hear
about their basics. Selecting the most appropriate technique is less instinctive,
and is a function of a wide variety of situational characteristics [HIC02].
Techniques that may be appropriate include interviewing [WEI88, GAU89, GAU90],
facilitated group meetings [GOT00], computer supported cooperative work
[SPR82], observation [GOG94], questionnaires [FOW93], prototyping [DAV95a],
scenarios [ARM01], and modeling notations [DAV93, RAM78].
The result of elicitation is a list of candidate requirements. It is
likely that some (or perhaps many) of the requirements will appear in
hierarchies. These hierarchies are the natural byproducts of investigating the
meanings of candidate requirements. After all, whenever a question is asked
about the meaning of requirement X, the explanations often imply
additional more-refined requirements, X1, X2, and X3.
If you perform too little elicitation, you run the risk of building the
wrong system. If you perform too much elicitation, you run the risk of spending
so much time worrying about the problem you want to solve, that there is
insufficient time left to solve it. The secrets of accomplishing just enough
elicitation are:
7
Never lose sight of your goal: understanding enough of the
problem so you can proceed with minimal risk
7
Never think you understand the problem better than the customer.
7
Never assume that one stakeholder can speak for all stakeholders.
7
Maintain a glossary of terms.
7
Avoiding elicitation altogether will significantly lengthen the
overall development time, not reduce it.
7
Prepare for change. The more the stakeholders discuss, the more
they will want. Dont solve this problem by cutting off the stakeholder. An
involved stakeholder is a happy stakeholder.
7
Stakeholders have the right to change their minds.
7
Prepare for active, explicit, and overt triage.
Requirements Triage
After eliciting requirements and gathering those requirements in a
list, you will likely want to establish (or learn) the desired schedule and/or
the available budget. No matter how ample either of these appears to be, one or
both will be insufficient to address all the requirements. To solve this
problem, you will need to find some way to balance desired requirements,
available budget, and desired schedule. Triage is the art of selecting the
right requirements to include in the next release of your product. Although
many people with many diverse titles are assigned the task of performing
elicitation, very few individuals in very few companies acknowledge that they
have been given the job to perform triage. In most organizations, triage is not
performed explicitly; instead it is performed by some combination of
intimidation, inertia, osmosis, and incompetence.
Synonyms for requirements triage include release planning [CAR02],
requirements prioritization [WIE03], optimal attainment of requirements
[FEA02], requirements negotiation [IN01], requirements selection [KAR96], and
requirements allocation.
Of all these choices, I have selected "triage" because the analogy to
triage in medicine is so close. As I described in [DAV03], after a medical
disaster, medical personnel
"systematically categorize victims into three groups: those who will die
whether treated or not, those who will resume normal lives whether treated or
not, and those for whom medical treatment may make a significant difference.
Each group requires a different strategy. The first group receives palliative
care, the second group waits for treatment, and the third requires some ranking
in light of available resources. As new victims appear, personnel must repeat
the categorization." Notice how similar this is to the software world.
Some requirements are "no-brainers;" we absolutely must address them
or the product won't be the product. Others are also "no-brainers;"
they are just dreams and should remain unfulfilled until appropriate resources
are available. And the third set requires ranking in light of available
resources. As new requirements emerge or resources change, new rankings must be
done.
Triage is the most interdisciplinary of the three areas of requirements
management. Successful triage requires close interplay between those
responsible for understanding the needs and timing of needs of customers,
those responsible for expending resources to satisfy requirements,
those responsible for the allocation of money to the project,
and those responsible for overall project success.
Successful triage requires knowledge of:
7
The needs of the customers
7
The relative importance of requirements
7
Market window
7
Relationships among requirements
7
Sensible subsetting [PAR76]
7
Cost to satisfy each requirement.
In an attempt to do "just enough" requirements management,
you might be tempted to dispense with triage. After all, most organizations
dont do it anyway. And it is difficult to do. Furthermore, in most companies,
the constituents of development, finance, and marketing rarely get along with
each other. So why bother? The answer lies in the fact that most systems built
today do not meet customer expectations. Perhaps the lack of triage is the very
reason for this. Not doing triage guarantees that your organization is taking
huge risks, e. g., the risk of satisfying the wrong requirements, the risk of
promising to meet a schedule only to miss it significantly, the risk of
agreeing to satisfy requirements for a given budget only to exceed it
significantly, and so on.
Performing
triage is the most important way to achieve just enough requirements
management. It is triage that enables the rest of system development to proceed
on schedule, while still providing a quality product. Not performing triage is
really not an option. If you do not do it explicitly, it will occur implicitly.
And if performed implicitly, you are leaving the success of your project to
pure chance.
A thorough discussion of the following triage techniques appears in
[DAV03, DAV04a]:
7
Prioritizing candidate requirements
7
Resolving conflicts concerning relative priority
7
Determining the effort necessary to address a requirement [DAV04]
7
Resolving conflicts concerning necessary effort
7
Determining and documenting relationships between requirements
[CAR01]
7
Determining risk inherent in addressing a requirement
7
Simultaneously triage multiple releases
7
Ideas on reaching triage closure
7
Talking apples and apples when discussing delivery dates
7
Performing triage in a business content (e.g., considering price,
revenue, profit, cash, ROI)
Triage is completed when the organization has determined which subset
of the complete list of candidate requirements will be satisfied in the next
release of the product.
Secrets of Just Enough Triage
If you pay too little attention to triage, you run the risk of trying
to build a system that cannot be built within time and resource constraints. If
you spend too much time on triage, priorities will change before you even start
doing requirements specification, resulting in a never-ending delay to project
initiation. The secrets of accomplishing just enough requirements triage are:
7
There is no so just thing as a perfect solution to the triage
dilemma. Compromise is necessary.
7
Always annotate your candidate features/requirements with a
relative priority and an estimated cost.
7
Record interdependencies between requirements.
7
Plan more than one release at a time.
7
Plan to replan before each new release.
7
If the voices
of "add more functionality" are allowed to overcome the voices of
moderation, late delivery is guaranteed.
7
If the voices
of "we can't implement that much functionality" are allowed to
overcome the voices of moderation, a weak product is guaranteed.
7
Never lose sight of your goal: selecting a subset of the full set
of desired requirements so that the product can be delivered on time and
within budget.
7
Agreeing to a set of requirements that are impossible to satisfy
in the time constraint guarantees failure.
7
Avoiding explicit triage altogether means that triage issues will
be addressed through intimidation and politics, and will guarantee failure.
7
Stakeholders have the right to change their minds.
Requirements Specification
After elicitation and triage, it would be nice to just start building
the product. Unfortunately, great risks remain. In particular, requirements are
still ambiguous and open-ended. If not improved, these requirements would
necessitate that developers make decisions concerning external behavior of the
system. If development personnel immediately start product construction,
problems are likely to arise: (a) developers will make different assumptions
than customers, resulting in a system that is likely to disappoint customers,
and (b) some developers are likely to make different assumptions than other
developers, resulting in an inconsistent and perhaps nonfunctional system. The
deliberate documentation of requirements to a degree of detail to make
associated risks tolerable is called requirements specification. Since specification
means documentation, then requirements specification is simply the
documentation of desired external behavior of the system.
Requirements specification is that activity associated with creating
the final documentation of a systems requirements, but requirements
specification is actually conducted throughout requirements activities.
Obviously, as candidate requirements are suggested during elicitation, they are
documented. During elicitation and during triage, disagreements concerning the
meaning of various requirements arise, and these are resolved by providing more
detail to existing requirements. In general, requirements are transformed from
the beginning of elicitation to the end of requirements specification in a wide
variety of ways, including levels of,
7
Agreement [POH94]
7
Completeness [POH94]
7
Detail
7
Precision [POH94]
7
Augmented.
Of the three primary aspects of requirements management, requirements
specification has received the most attention. Many corporate and
organizational standards even suggest that documentation of desired external
behavior of the system should be the first activity performed. Dozens of
standards [DOR90] exist to control how individual requirements should be
organized into a polished document. More recently, the Robertsons [ROB99]
introduced the Volere specification template. This is the first de facto
standard that provides a reasonable checklist for specifiers to help them
decide what belongs in the document and what does not. After many years of
consulting for organizations adhering to such standards, I have become
convinced that such organizations spend an inordinate amount of time polishing
requirements documents with relatively little gain. Remember, the goal is not a
perfect requirements document. The goal is an ideal product, and
the requirements document is just a means to that end.
The most common ways to
document requirements today are: (a) they are not document at all, (b) they are
documented in large novels, as described in the previous paragraph, (c) they
are documented using formal specification languages, (d) they are documented
using modeling diagrams, and (e) they are documented as (perhaps hierarchical)
bulleted lists. I am a strong believer on the last option. However, when
customers demand the creation of a large novel, the best thing to do is to
also create a bulleted list, and cross reference it to the novel. And in some
cases, it makes a great deal of sense to describe some requirements in more
formal models, in which case the best thing is to also create a bulleted list,
and cross reference it to elements of the models.
A requirements document serves a variety of important roles [DAV93].
First it serves as a basis of communication among customers, marketing,
development, sales, finance, testing, and management. These individuals each
has his/her own job to do, and for the most part their tasks can be performed
fairly independently. However, the success of their collective actions is only
ensured if they are all working toward the same goal, i.e., the same system.
None of these parties can do their job without a common understanding of the
systems intended external behavior. Notice how developer-centric the extreme
programming movement is. Extreme programming was invented by developers to optimize
their activities with little regard for the entire orchestra of players
whose work also affects the success or failure of the final product.
Second, requirements serve as the primary driver of the design team.
Third, requirements serve as the primary driver of the system test team.
Fourth, requirements serve as a reference for project managers. Fifth, the
requirements document serves as the basis for controlling the evolution of the
system. When release 1.0 of the system development is complete, it should
satisfy all the requirements defined in the 1.0 release of the requirements
document. When triage is performed for the 2.0 release, the requirements
document is updated to reflect the new requirements, and then the system is
built to satisfy those requirements. Thus, at any time during the life of a
system, the latest version of the requirements document always defines the
current system being built, and the previous version of the requirements
document always defines the system most recently released.
Requirements specification techniques vary depending on characteristics
of the problem being solved. For example, [DAV93, DAV04a] describe what to do
when the problem is:
7
Feature intense
7
State intensive
7
Decision intense
7
One that has non-behavioral requirements (most of them!)
The result of the activity of specifying requirements is a document,
called either a requirements specification or a requirements document. It
should contain a list of all requirements that stakeholders have agreed to
include in the product. To indicate which of the requirements are to be
included in the next release, the document is either pruned to exclude those
not to be included, or are annotated by intended release so parties can quickly
determine which requirements will be included and which will be excluded.
Requirements may appear hierarchically, and may be augmented by more formal
models.
Secrets of Just Enough Specification
If you pay too little
attention to requirements specification, you run the risk of building the wrong
system because of incompleteness and ambiguity. If you spend too much time on
specification, you run the risk of never getting around to building the system
at all. The secrets of accomplishing just enough requirements specification
are:
7
Never lose sight of your goal: specifying the desired behavior of
a system to sufficient detail that system developers, marketing, customers,
users, and management, are all likely aligned in their interpretation.
7
All stakeholders will understand natural language. The customer
wants his/her problem solved. He/She does not want to take a course on
understanding some computer notation.
7
Construct models for those parts of the system where natural
language introduces intolerable risk.
7
Use the right model for the right job.
7
Avoiding specification altogether will significantly lengthen the
overall development time, not reduce it.
7
Include a glossary of terms used in the document.
7
You may want to create an auxiliary list of "bonus"
requirements that should be worked on only if all other requirements have been
met within budget and schedule.
7
Stakeholders have the right to change their minds.
Summary
Requirements management is a means to an end; it is not a goal itself.
The goal is to build (or acquire) a system that solves some real problem or
leverages some real business opportunity. No shortage exists of ways that we
can spend enormous amounts of our time performing requirements management. We
need to develop the discipline of avoiding such quagmires. On the other hand,
the solution is not the other extreme; eliminating requirements management
dooms us to a guaranteed project failure.
Happy customers and users are the primary indicators of a successful
product-development project. To raise our chances of creating happy customers, we
7
Must understand the customers' and
users' view of their problems and opportunities.
7
Must not attempt to address more
problems and opportunities than we have the time and resources for.
7
Must record our understandings so
that all parties understand up front what to expect at the end.
7
Must remain flexible as customer
and user needs evolve.
References
[ARM01] Armour,
F., and G. Miller, Advanced Use Case Modeling, Reading, MA: Addison
Wesley, 2001.
[BEC99] Beck, K., Extreme
Programming Explained, Reading, MA: Addison-Wesley, 1999.
[BEL76] Belady, L.,
and M. Lehman, "A Model of Large Program Development," IBM Systems
Journal, 15, 3 (March 1976), pp. 225-252.
[CAR01] Carlshamre, P.,
et al., "An Industrial Survey of Requirements Interdependencies in
Software Product Release Planning," Fifth International Symposium on
Requirements Engineering, Los Alamitos, CA: IEEE Computer Society Press,
2001, pp. 84-91.
[CAR02] Carlshamre, P.,
"Release Planning in Market-Driven Software Product Development: Provoking
an Understanding," Requirements Engineering Journal, 7, 3 (May
2002), pp. 139-151.
[COC02] Cockburn, A., Agile Software Development, Reading,
MA: Addison-Wesley, 2002.
[COU73] Couger, D.,
"Evolution of Business Systems Analysis Techniques," ACM Computing
Surveys, 5, 3 (September 1973), pp. 167-198.
[DAV93] Davis, A., Software
Requirements: Objects, Functions, and States, Upper Saddle River, NJ:
Prentice Hall, 1993.
[DAV95] Davis, A., 201
Principles of Software Development, New York: McGraw Hill, 1995.
[DAV95a] Davis, A.,
"Software Prototyping," Advances in Computers, 40, M.
Zelkowitz, ed., New York: Academic Press, 1995, pp. 39-63.
[DAV03] Davis, A., The
Art of Requirements Triage, IEEE Computer, 36, 3 (March 2003),
pp. 42-29.
[DAV04] Davis, A.,
"Thoughts on Software Estimation," in Software Lemmings and Other
Uncomfortable Tales, Los Alamitos, CA: IEEE Computer Society Press,
2004.
[DAV04a] Davis, A., Just
Enough Requirements Management, New York: Dorset House, 2004.
[DOR90] Dorfman, M.,
and R. Thayer, Standards, Guidelines, and Examples of System and
Software Requirements Engineering, Los Alamitos, CA: IEEE Computer Society
Press, 1990.
[FEA02] Feather,
M., and T. Menzies, "Converging on the Optimal Attainment of
Requirements," Tenth Joint International IEEE Conference on
Requirements Engineering, Los Alamitos, CA: IEEE Computer Society Press,
2002.
[FLE02] Fleisher, C.,
and B. Bensoussan, Strategic and Competitive Analysis: Methods and
Techniques for Analyzing Business Competition, Upper Saddle River, NJ:
Prentice Hall, 2002.
[FOW93] Fowler, Jr., F.,
Survey Research Methods, 2nd edition, Sage Publications,
1993.
[GAU89] Gause, D., and
J. Weinberg, Exploring Requirements: Quality Before Design, New York:
Dorset House, 1989.
[GAU90] Gause,
D., and J. Weinberg, Are Your Lights On?, New York: Dorset House, 1990.
[GOG94] Goguen, J.,
and M. Jirotka, eds., Requirements Engineering: Social and Technical Issues,
Boston, MA: Academic Press, 1994.
[GOT00] Gottesdiener,
E., Requirements by Collaboration, Reading, MA: Addison-Wesley, 2000.
[HIC02] Hickey, A.,
and A. Davis, "The Role of Requirements Elicitation Techniques in
Achieving Quality," Workshop on Requirements Engineering: Foundations
for Software Quality, Essen, Germany, September 2002.
[HIG01] Highsmith,
J., and A. Cockburn, Agile Software Development: The Business of Innovation, Computer
(September 2001), pp. 120-122.
[IN01] In,
H., et al., "A Requirements Negotiation Model Based on Multi-Criteria
Analysis," Fifth International Symposium on Requirements Engineering, Los
Alamitos, CA: IEEE Computer Society Press, 2001, pp. 312-313.
[KAR96] Karlsson,
J., and K. Ryan"Supporting the Selection of Requirements," Eighth
International Workshop on Software Specification and Design, Los Alamitos,
CA: IEEE Computer Society Press, 1996, pp. 146-149.
[KEN01] Kendall, K.,
and J. Kendall, Systems Analysis and Design, Upper Saddle River, NJ:
Prentice Hall, 2001.
[MAS70] Maslow, A., Motivation
and Personality, New York: Harper and Row, 1970.
[MCL01] McLeod, R., and
G. Schell, Management Information Systems, Upper Saddle River, NJ:
Prentice Hall, 2001.
[PAR76] Parnas, D.,
"On the Design and Development of Program Families," IEEE
Transactions on Software Engineering, 2, 1 (March 1976), pp. 1-9.
[PAU93] Paulk, M., et al., Capability Maturity Model 1.1, IEEE
Software, 10, 4 (July 1993), pp. 18-27.
[POH94] Pohl, K., The Three Dimensions of Requirements
Engineering: A Framework and its Application, Information Systems, 3,
19 (June 1994), pp. 243-258.
[RAM78] Ramamoorthy,
C.V., and H. So, Software Requirements and Specifications: Status and
Perspectives, University of California at Berkeley Electronics Research
Laboratory Report #M78/44, June 1978.
[ROB99] Robertson, J.,
and S. Robertson, Mastering the Require-ments Process, Reading,
MA: Addison-Wesley, 1999.
[ROY98] Royce, W., Software
Project Management: A Unified Framework, Reading, MA: Addison Wesley, 1998.
[SPR82] Sprague, R.,
and E. Carlson, Building Effective Decision Support Systems, Upper
Saddle River, NJ: Prentice Hall, 1982.
[USA97] U.S. Army, Requirements
Generation System, Memorandum of Policy CJCSI 3170.01, 1997.
[WEI88] Weinberg, J., Rethinking
Systems Analysis and Design, New York: Dorset House, 1988.
[WIE03] Wiegers, K., Software Requirements,
Redmond, WA: Microsoft Press, 2003.
