|
What's
New?
|
Paper
|
Group
|
Date
|
|
Requirements Information Strategies: Does One Size Fit All? V13
|
Avoid Mistakes
|
5/24/10
|
|
What's It Mean? Eliminating Vagueness with Precising Definitions V1
|
Minimize Comm
|
4/9/09
|
The papers are grouped as follows:
|
Requirements Risk
Management (RRM)
|
Top
|
Identifying
and Controlling Requirements Risk (v44 1.4M Posted:
5/24/10)
Developing a strategy to deal with the actual and potential
problems in requirements development, can reduce the number and
severity of the problems that do occur. This presentation describes
a set of tactics that you can use to develop your risk management
strategy.
RRM Tactics Checklist and References (v37 110kb
Posted: 6/15/09)
A list of tactics that you can use to compose your requirements
risk management strategy and a list of references for several of
the tactics.
The Myth of
Risk Management (v01 847K Posted: 6/04/09)
Pete McBreen examines the nature of risk on software development
projects. He concludes that most risk management is misguided and
ineffective. This is partially due to the politics or culture in
some organizations that make risk unmentionable. It is also due to
a failure to openly acknowledge project uncertainty and
unpredictability.
|
Monitor Feasibility
Tactics
|
Top
|
Prioritizing Requirements (v01 160kb Posted:
9/20/07)
Don Firesmith describes the challenges and risks of prioritizing
requirements and provides a survey of prioritizing techniques.
Project
Termination Doesn't Equal Project Failure (v01 49kb
Posted: 1/31/07)
Barry Boehm argues that project cancellation may be due to good
project management. He discusses organizational risk taking and
states that no project cancellations may mean too little risk
taking.
Better Management of Development Risks (v01 891kb
Posted: 5/20/10)
Barry Boehm presents a development model to integrate system
acquisition, system engineering, and software engineering. The
model provides points at which the risks going forward can be
better assessed and fit into a risk-driven stakeholder resource
commitment process.
The Only Winning Move (v01 72kb Posted:
12/04/03)
Organizations that don't expect and encourage about 20 percent of
their projects to be stopped, may either be wasting resources or
implementing only the safest bets. Denying reality or always
playing it safe may be the riskiest strategy of all.
|
Avoid Mistakes
Tactics
|
Top
|
Safety
Check (v01 92Kb Posted: 3/19/08)
Steven Smith discusses the importance of personal safety and
describes a way to measure it.
Human
Requirements Engineering
(v01 287kb Posted: 10/26/07)
Paul-Roux Wentzel and his coauthors describe the way people are
different and how those differences should be handled in a
requirements engineering context to tap their full potential.
Controlling Prototype Development Through Risk
Analysis (v01 657kb Posted: 06/11/09)
Baskerville and Stage describe a new approach to the management of
evolutionary prototyping projects. The main unsolved problem in
prototyping is the difficulty in controlling such projects. The
article uses an explicit risk mitigation model and management
process. This approach enables appropriate risk resolution
strategies to be placed in effect before the prototyping process
breaks down. It facilitates consensus building through
collaborative decision making and is consistent with a high degree
of user involvement.
Overview of Cooperative Learning
(v01 231kb Posted: 5/20/10)
Roger and David Johnson describe how learners may perceive and interact with one another. They can compete to see who is "best", they can
work individualistically toward a goal without paying attention to others, or they can work cooperatively with a vested
interest in each other's learning as well as their own. They describe the advantages of a cooperative environment.
Agile Requirements for Stepsister Projects (v01 336kb
Posted: 4/01/06)
Many projects don't fit the criteria for an efficicient, effective
requirements process. Language barriers, large teams, and tunnel
vision are all things that can turn your project from Cinderella
into a stepsister. Find out what Jennitta Andrea suggests to help
you overcome these obstacles.
Requirements Information Strategies: Does One Size Fit All? (v13 147kb Posted:
5/24/10)
In this paper, we define the requirements information that should
be elicited and communicated on a specific project as "just enough"
based on the risk of inadequate understanding of higher priority
requirements. We show that this risk primarily depends on the
initial understanding of stakeholders i.e., that "just enough"
decisions are context-dependent. We show that no context-free
approach to requirements (e.g. comprehensive or Agile) is best in
all situations and that the "just enough" approach entails these
context-free approaches as special cases. We identify risk
mitigation tactics to deal with "not enough" requirements. Finally,
we describe the "just enough" selection process and provide four
examples.
Agile
Requirements Methods (v01 136Kb Posted: 1/30/07)
Dean Leffingwell discusses the formulation of requirements methods
that reflect the types of risks inherent in your environment. He
describes Extreme, Agile, and Robust Requirements Methods as
examples.
Individualizing Requirements Information (v02 45kb
Posted: 2/14/06)
Requirements Engineering should have its own requirements -
specifically the types and forms of information to be communicated.
Information choices should be individualized to the many contexts
associated with a project. Different types of systems need
different types of information.
Template tailoring is the commonly suggested approach to
information selection, but is only useful when there is little
variance in the customer base and the type of system. A more
powerful approach is individualization using components. This paper
describes a process for individualizing requirements
information.
Sheets to Individualize Requirements
Information (v01 21kb Posted: 2/14/06)
This spreadsheet contains lists of information types that can help
you create your own comprehensive menu from which your individual
projects will make their selections i.e., individualize.
|
Minimize
Communication Tactics
|
Top
|
What's It
Mean? - Eliminating Vagueness with Precising Definitions
(v01 717kb Posted: 4/9/09)
Imprecise language makes understanding and, therefore, verification
more difficult. This article describes techniques for detecting and
repairing vague and ambiguous software requirements.
Let
Me Be Perfectly Clear
(v07 350kb Posted: 1/06/08)
This presentation shows why standard approaches to defining terms
are ineffective and then describes 7 types of rich definitions that
are both precise and contextual .
Just
Enough Precision
(v01 300kb Posted: 1/06/08)
This presentation shows why standard approaches to defining terms
are ineffective and then describes 3 types of rich definitions that
are both precise and contextual. [Short form of Let Me Be Perfectly
Clear]
Just Enough Precision Webinar Q and A
(v01 23kb Posted: 1/31/08)
The questions and answers resulting from a webinar on Just Enough
Precision
Rich
Glossary Template for Word
(v04 222kb Posted: 12/4/07)
This Word file can be used as a template for a Rich Glossary (i.e.
a glossary filled with rich definitions).
Clearly
Specifying System Requirements (v29 1.6Mb Posted:
5/22/06)
This PowerPoint presentation is an introduction to practical
detailing techniques for requirements specification. Precision is
inevitable in software development. Both code and tests are precise
specifications. This presentation focuses on techniques that add
essential details to risky requirements using precise models. The
detailing techniques include (a) precise use cases, (b) test specs,
(c) entity specs, (d) derived conditions, (e) action contracts, (f)
derived values, and (g) quality specs. Each technique has its
domain of effective application and can be applied incrementally.
In many situations, several techniques should be used.
Using
Requirements Specification Patterns (v01 49kb Posted:
5/29/05)
In this paper, we recommend minimum sets of specification patterns
for different types of systems. First we describe a comprehensive
set of spec patterns and a classification scheme of system types.
Then we identify the spec patterns to use for each type of
system.
Requirements and Business Rules (v01 44kb
Posted: 5/29/05)
This paper explores the relationship between a detailed
classification of requirements information and a detailed
classification of business rule information.
The
Clear Specs Challenge (v06 52kb Posted: 5/12/04)
This paper defines the challenge process and shows how the
ClearSpecs techniques (detailed definitions and precise use cases)
could be used to specify the Merchandise Return capability of a
Sales Support System.
Building a
Business Case for Detailed Specs
(v01 38kb Posted: 6/26/03)
This paper describes a cost-benefit analysis for the use of
detailed system specifications. The presentation begins with
assumptions about the requirements process and then provides a
formula for the Return on Investment (ROI) in moving from one
specification strategy to another. We demonstrate the formula by
comparing the minimal specing in Extreme Programming to detailed
specification using the ClearSpecs techniques.
Adding Bits of
Precision to Usage Models (v01 146kb Posted:
3/6/03)
For interactive systems, usage models are an important component of
the requirements specification. In the spirit of agile methods and
"just enough" written communication, well-understood user
activities might be communicated by XP user stories and subsequent
discussions. In cloudier areas, more details should be written to
reduce the risk of misunderstanding. This paper describes nine
techniques that you can use to increase the precision of your usage
models. Each technique can be used alone or in combination to
supplement your current practice. Readers are assumed to
have a basic understanding of use cases.
A
Q&A Intro to ClearSpecs Usage Modeling (v05 130kb
Posted: 5/22/04)
This article gives the components of a ClearSpecs usage model;
explains how ClearSpecs models relate to UML models; and details
where ClearSpecs modeling can be effectively used. There is also a
list of references.
ClearSpecs
Model of a Library Management System (v02 111kb
Posted: 5/12/04)
This is an example of a precise model of a familiar system. This
usage model for a library management system covers book
transactions such as check out, return, add, remove, and the
displaying of various sorted lists. It covers constraints such as
book status (checked out or available) and staff user vs. ordinary
borrower, among others. The system also includes retinal scan and
bar code scanning.
Precise Use
Cases (v05 129kb Posted: 5/22/04)
This paper describes a precise form of use case that promotes the
specification of inter-actor options and alternative course
conditions. Precise cases use an activity description language with
a Structured English grammar. The design goals for the notation
were to maximize understandability by application experts, not
familiar with formal object-oriented concepts, and to supply
sufficient information and structure to support both manual and
automated test design. In addition to a detailed example, a
development process, and guidelines for modeling and test coverage
are provided. The appendix contains a substantial use case example.
The reader is assumed to have a basic understanding of use
cases.
Use Cases: Give More to Get More (v02 500kb
Posted: 11/15/05)
This Powerpoint presentation describes the elements of a Precise
Use Case.
Modeling
Alternative Courses in Detailed Use Cases
(v03 75kb Posted: 2/15/04)
Real-life interactions between systems and users entail decisions
and alternative courses of action. Within detailed use cases, there
are many categories of alternative courses each having a distinct
semantics. This paper describes an integrated framework for
categorizing alternative courses and provides modeling
recommendations for each category. The paper also examines the
impact of alternative courses on use case conditions (i.e.,
constant conditions, preconditions, and post-conditions) and
recommends a three-level strategy for specifying conditions.
Specifying
Consequences with Action Contracts (v02 182kb Posted:
3/3/03)
This paper describes a technique, action contracting, for the
specification of goal-directed actions. Contracting can be used to
specify consequential action rules, rather than algorithms, for any
goal-directed entity (e.g., person, system, product, component,
class, or object). If an entity can be effectively tested for
functionality, that functionality can be contracted. Action
contracts are readable by clients and writeable by most software
professionals, with minimal training.
Quality
Specs
(v02 38kb Posted: 2/28/04)
This paper provides a template for the precise specification of
quality (non-functional) requirements. Four examples are
included.
Quantifying Quality Requirements
(v01 82kb Posted: Live2/17/04)
Erik Simmons describes Intel's use of Planguage, created by Tom
Gilb. Planguage is a keyword-driven language that allows
measurable, testable quality requirements to be written. Planguage
is easy to learn, flexible, compact, extensible, and prevents
omissions by providing a consistent set of parameters for quality
requirements. In this paper, Planguage keywords and syntax are
introduced. Examples of quality requirements before and after using
Planguage are given, and the experiences of introducing Planguage
within a product engineering environment are discussed.
Periodic Table of Vizualization Methods (v01
500Kb Posted: 9/20/07)
Lengler and Eppler provide a periodic table of 100 visualization
methods and describe how to use it. Examples of each method can be
found in pop-up frames by mousing-over the table enties at
http://www.visual-literacy.org/periodic_table/periodic_table.html#
Visual Requirements (v01 164Kb Posted: 7/1/08)
Becky Winant describes 3 types of diagrams and how to turn them
into powerful requirements tools. Becky discusses turning diagrams
into models that help illustrate software's 3 dimensions: function,
information, and behavior.
|
Minimize Other
Tactics
|
Top
|
Collaborate for Quality (v01 158Kb Posted:
7/1/08)
Ellen Gottesdiener provides advise on using workshops to determine
your project's requirements. Ellen describes how to apply proven
patterns for effective collaboration and provides examples from
successful efforts.
Know
What's at Stake (v01 800Kb Posted: 5/30/07)
Harty, Evans, and Reid describe the need for and an approach to
explicit non-functional requirements (NFR). They see NFRs treated
as second-class requirements and illustrate the consequences of
this.
Discovering Early Aspects (v01 262Kb Posted: 5/20/10)
Baniassad et. al. define early aspects as concerns that crosscut a system’s dominant functional decomposition. Quality characteristics, such as reliability, are examples of early aspects. These aspects should be identified during requirements elicitation to support effective architectural design.
Early Aspects (v01 41Kb Posted: 5/20/10)
Rashid et. al. propose a model for aspect-oriented requirements engineering that ensures the consistency of functional requirements with
global requirements and constraints.
|
Detect Requirements Defects
|
Top
|
HIgh Impact Inspections (v01 500kb Posted:
8/28/05)
This PowerPoint presentation describes the details of High-Impact
Inspections. This form of technical review is a powerful
alternative to Fagan Inspections.
Detecting Missing Requirements (v06 750kb Posted:
5/23/06)
Requirements development is difficult for many reasons including
the challenge of detecting missing requirements information. This
PowerPoint presentation catalogs over a dozen techniques for this
task and provides details on four of them.
Detecting Defects in Existing Requirements (v04 500kb
Posted: 5/24/06)
It is difficult to uncover defects in existing requirements. This
PowerPoint presentation surveys the range of requirements
information and the set of issues that need to be checked for
individual requirements and for the entire suite.
Will It
Work (v01 510kb Posted: 10/31/07)
Hammond, Rawlings, and Hall describe approaches to reducing the
requirements risk in large heterogenous distributed systems. In
particular, they describe the use of "rich traceability" as a
framework for verifying that the allocation of a requirement to
multiple processes is sound.
Test-Driven
Requirements (v01 303Kb Posted: 1/30/07)
Roland Cuellar describes the power of designing test cases
early.
Use
of Satisfaction Arguments (v01 298Kb Posted:
11/30/07)
Attwood, Kelly, and McDermid illustrate the use of satisfaction
arguments to support the derivation of requirements.
Spec Quality Control (v01 526Kb Posted: 3/19/08)
Tom Gilb describes a relatively inexpensive sampling technique to
assess the number of major defects in a requirements spec.
Learning
From Mistakes (v01 132kb Posted: 10/10/07)
David Card describes Defect Causal Analysis, a process for culling
systematic errors from problem reports in order to develop
strategies for preventing defects or detecting them earlier.
Stop the Insanity (v01 582Kb Posted: 7/1/08)
Ed Weller discusses using root cause analysis (RCA) to understand
mistakes and avoid repeating them. Ed distinguishes errors, faults,
and failures and describes common problems with RCA.
Incremental and Iterative Development (v01
2.51M Posted: 6/8/08)
Alistair Cockburn clears up the confusion about the relationship
between incremental and iterative development.
Developing a Reqts Team (v01 52kb Posted:
12/28/06)
Forming, Storming, Norming, and Performing. No, they are not a law
firm, but the stages of team development proposed by Bruce Tuchman
in 1965. It may help your requirements team.
Overcoming Reqts Modeling Challenges (v01 82kb
Posted: 10/10/07)
Scott Ambler suggests what to do when an organizations culture is
not condusive to effective software development efforts or project
stakeholders do not understand the implications of their
decisions.
Brainstorming Fraud Risks (v01 170kb Posted:
10/26/07)
Mark Beasley and Gregory Jenkins provide a readable primer on
brainstorming risks. Although written for accountants, it describes
a brainstorming process that can be used for all types of risks.
The article discusses how a team can avoid pitfalls inherent in
brainstorming sessions while maximizing their benefits.
Common
Requirements Problems (v01 96kb Posted: 11/2/07)
Donald Firesmith summarizes 12 of the most common requirements
problems, describes their negative consequences, and relates the
industry best practice to help solve them.
Requirements Risks Can Drown Software Projects
(v01 241kb Posted: 10/10/07)
Theron Leishman and David Cook describe several requirements risks
and consider strategies to help mitigate them.
Building a Reqt Fault Taxonomy (v01 101kb Posted:
1/31/07)
Jane Hayes describes her work in creating a requirements taxonomy
based on a sample of incident reports for NASA space station
software.
Ongoing
Requirements Discovery (v01 358kb Posted:
1/31/07)
Robyn Lutz analyzed anomaly reports from 8 spacecraft projects and
found several patterns of requirements discovery. She demonstates
the value of analyzing requirements-based issue logs.
The Ritual of Retrospectives (v01 89Kb Posted:
7/1/08)
Norm Kerth describes how to maximize group learning by
understanding past projects. Norm discusses how to structure the
meeting and 3 precautions to consider.
|
Other Requirements
Stuff
|
Top
|
Maybe
We Shouldn't "Write" Requirements (v01 50kb Posted:
2/21/03)
In this column, David presents a problem familiar to many of
us--what is the best way to record requirements? Given the
limitations of static templates, how can we best manage
high-volume, multidimensional requirements information?
Exploring
Agile (v01 50kb Posted: 3/29/08)
Bob attempts to figure out exactly what Agile development is and
where it works by analyzing the Agile Manifesto and its supporting
principles. He proposes changes to some troubling statements.
Aphorisms about
Requirements (v01 56kb Posted: 2/21/03)
"The requirements puzzle will have pieces missing...Expect
requirements development to be a shared learning experience...For
wicked problems, the picture keeps changing...Right the first time
can be the enemy of good enough...Risk requires higher resolution."
This paper explains these aphorisms related to requirements
development and management.
Testing
Complex Logic (v01 63kb Posted: 8/06/03)
Choosing effective tests for complex logical expressions can be
difficult. This paper describes a black box strategy for choosing
such tests. The strategy is shown to be a natural generalization of
current methods for choosing tests for simpler expressions. The
strategy chooses combinations that are not only effective at
revealing implementation defects but, perhaps more important, are
effective at helping detect defects in the requirements
themselves.
In addition, if there are dependencies between variables in the
required logic, a variant of the strategy excludes those
truth-value combinations that are "impossible" because of the
dependencies. It extends the required expression to include
dependency information and then derives tests from this extension.
This strategy is the only test selection method that smoothly
incorporates dependency information. It also permits the dependency
information itself to be partially validated through analysis of
the "impossible" cases developed by the basic strategy, but
excluded by the variant.
What Test Designers Wish from Software Models (v01
253kb Posted: 12/08/06)
Testing is getting harder. To keep up with ever growing complexity
of software and the testing task, new approaches to test
development must be used. One of these approaches is automated test
design based on precise models of software behavior and usage.
Today, commercial support in this area is weak. There is a current
and growing need for a variety of commercial tools supporting
automated design. The purpose of this presentation is to provide
insight into the information requirements for automated test design
to (current and potential) vendors of software modeling tools. It
is hoped that this information will catalyze a number of commercial
development efforts.
How to
support better software testing (v01 1.7Mb Posted:
8/17/03)
This paper describes the elements of a Testability Maturity Model
(TMM) that addresses the issues that support or retard project
testing. The TMM covers information availability and relationships
as well as best practices in support of test. It is a pragmatic
model that can be used to assess and improve testability.
What's
your testability maturity? (v01 1.1Mb Posted:
8/17/03)
This paper contains a testability score card based on the
Testability Maturity Model. The scorecard entries are described
along with a strategy for maximizing the impact of the
evaluation.
The
Growth of Software Testing (v01 2.4Mb Posted:
8/17/03)
This paper traces the evolution of software test engineering by
examing changes in the testing process model and the level of
professionalism. The current definition of best testing practice
aims for defect preventation as well as detection.
Vol. 2005 No. 3 Cooperation
and Learning Styles (Posted: 9/24/05)
Vol. 2005 No. 2 Survey
Says ... (Posted: 8/22/05)
Vol. 2005 No. 1 Good
Requirements are UnAmerican (Posted: 4/20/05)
Vol. 2004 No. 3 Why
So Difficult? (Posted: 11/25/04)
Vol. 2004 No. 2 No
Hows? (Posted: 08/10/04)
Vol. 2004 No. 1 Requirements
Team Development (Posted: 04/01/04)
Vol. 2003 No. 2 RD
is a team game (Posted: 10/21/03)
Vol. 2003 No. 1 Effective
Involvement of Stakeholders (Posted: 7/30/03)
|
