Requirements - CL1 Flashcards
Requirement definition
Software Requirements Defined
One problem with the software industry is the lack of common definitions
for terms we use to describe aspects of our work. Different observers
might describe the same statement as being a user requirement,
software requirement, functional requirement, system requirement,
technical requirement, business requirement, or product requirement. A
customer’s definition of requirements might sound like a high-level
product concept to the developer. The developer’s notion of requirements
might sound like detailed user interface design to the user. This diversity
of definitions leads to confusing and frustrating communication problems.
True Stories A key concept is that the requirements must be
documented. I was on a project once that had experienced a rotating cast
of developers. The primary customer was sick to tears of having each
new requirements analyst come along and say, “We have to talk about
your requirements.” The customer’s reaction was, “I already gave your
predecessors the requirements. Now build me a system!” In reality, no
one had ever documented the requirements, so every new analyst had to
start from scratch. To proclaim that you have the requirements is
delusional if all you really have is a pile of e-mail and voice-mail
messages, sticky notes, meeting minutes, and vaguely recollected
hallway conversations
Some Interpretations of Requirement
Consultant Brian Lawrence suggests that a requirement is “anything that
drives design choices” (Lawrence 1997). Many kinds of information fit in
this category. The IEEE Standard Glossary of Software Engineering
Terminology (1990) defines a requirement as
1. A condition or capability needed by a user to solve a problem or
achieve an objective.
2. A condition or capability that must be met or possessed by a
system or system component to satisfy a contract, standard,
specification, or other formally imposed document.
3. A documented representation of a condition or capability as in 1
or 2.
This definition encompasses both the user’s view of the requirements
(the external behavior of the system) and the developer’s view (some
under-the-hood characteristics). The term user should be generalized to
stakeholder because not all stakeholders are users. I think of a
requirement as a property that a product must have to provide value to a
stakeholder. The following definition acknowledges the diversity of
requirements types (Sommerville and Sawyer 1997):
Requirements are…a specification of what should be implemented.
They are descriptions of how the system should behave, or of a
system property or attribute. They may be a constraint on the
development process of the system.
Clearly, there’s no universal definition of what a requirement is. To
facilitate communication, we need to agree on a consistent set of
adjectives to modify the overloaded term requirement, and we need to
appreciate the value of recording these requirements in a shareable form.
Trap Don’t assume that all your project stakeholders share a
common notion of what requirements are. Establish definitions
up front so that you’re all talking about the same things.
What Requirements Are Not
Requirements specifications do not include design or implementation
details (other than known constraints), project planning information, or
testing information (Leffingwell and Widrig 2000). Separate such items
from the requirements so that the requirements activities can focus on
understanding what the team intends to build. Projects typically have
other kinds of requirements, including development environment
requirements, schedule or budget limitations, the need for a tutorial to
help new users get up to speed, or requirements for releasing a product
and moving it into the support environment. These are project
requirements but not product requirements; they don’t fall within the
scope of this book.
Link:
https://en.wikipedia.org/wiki/Requirement
Levels of Requirements: Business, User, and Functional requirements
Most common requirements risks
Characteristics of Excellent Requirements
Benefits from a High-Quality Requirements Process
Levels of Requirements
This section presents definitions that I will use for some terms commonly
encountered in the requirements engineering domain. Software
requirements include three distinct levels—business requirements, user
requirements, and functional requirements. In addition, every system has
an assortment of nonfunctional requirements. The model in Figure 1-1
illustrates a way to think about these diverse types of requirements. As
with all models, it is not all-inclusive, but it provides a helpful organizing
scheme. The ovals represent types of requirements information and the
rectangles indicate containers (documents, diagrams, or databases) in
which to store that information.
Business requirements represent high-level objectives of the organization
or customer who requests the system. Business requirements typically
come from the funding sponsor for a project, the acquiring customer, the
manager of the actual users, the marketing department, or a product
visionary. Business requirements describe why the organization is
implementing the system—the objectives the organization hopes to
achieve. I like to record the business requirements in a vision and scope
document, sometimes called a project charter or a market requirements
document. Creating such a document is the subject of Chapter 5,
“Establishing the Product Vision and Project Scope.” Defining the project
scope is the first step in controlling the common problem of scope creep.
User requirements describe user goals or tasks that the users must be
able to perform with the product. Valuable ways to represent user
requirements include use cases, scenario descriptions, and eventresponse tables. User requirements therefore describe what the user will
be able to do with the system. An example of a use case is “Make a
Reservation” using an airline, a rental car, or a hotel Web site.
Functional requirements specify the software functionality that the
developers must build into the product to enable users to accomplish
their tasks, thereby satisfying the business requirements. Sometimes
called behavioral requirements, these are the traditional “shall”
statements: “The system shall e-mail a reservation confirmation to the
user.” As Chapter 10 (“Documenting the Requirements”) illustrates,
functional requirements describe what the developer needs to implement.
The term system requirements describes the top-level requirements for a
product that contains multiple subsystems—that is, a system (IEEE
1998c). A system can be all software or it can include both software and
hardware subsystems. People are a part of a system, too, so certain
system functions might be allocated to human beings.
True Stories My team once wrote software to control some laboratory
apparatus that automated the tedious addition of precise quantities of
chemicals to an array of beakers. The requirements for the overall
system led us to derive software functional requirements to send signals
to the hardware to move the chemical-dispensing nozzles, read
positioning sensors, and turn pumps on and off.
Business rules include corporate policies, government regulations,
industry standards, accounting practices, and computational algorithms.
As you’ll see in Chapter 9, “Playing By the Rules,” business rules are not
themselves software requirements because they exist outside the
boundaries of any specific software system. However, they often restrict
who can perform certain use cases or they dictate that the system must
contain functionality to comply with the pertinent rules. Sometimes
business rules are the origin of specific quality attributes that are
implemented in functionality. Therefore, you can trace the genesis of
certain functional requirements back to a particular business rule.
Functional requirements are documented in a software requirements
specification (SRS), which describes as fully as necessary the expected
behavior of the software system. I’ll refer to the SRS as a document,
although it can be a database or spreadsheet that contains the
requirements, information stored in a commercial requirements
management tool—see Chapter 21, “Tools for Requirements
Management”—or perhaps even a stack of index cards for a small
project. The SRS is used in development, testing, quality assurance,
project management, and related project functions.
In addition to the functional requirements, the SRS contains
nonfunctional requirements. These include performance goals and
descriptions of quality attributes. Quality attributes augment the
description of the product’s functionality by describing the product’s
characteristics in various dimensions that are important either to users or
to developers. These characteristics include usability, portability, integrity,
efficiency, and robustness. Other nonfunctional requirements describe
external interfaces between the system and the outside world, and
design and implementation constraints. Constraints impose restrictions
on the choices available to the developer for design and construction of
the product.
People often talk about product features. A feature is a set of logically
related functional requirements that provides a capability to the user and
enables the satisfaction of a business objective. In the commercial
software arena, a feature is a group of requirements recognizable to a
stakeholder that aids in making a purchase decision—a bullet item in the
product description. A customer’s list of desired product features is not
equivalent to a description of the user’s task-related needs. Web browser
favorites or bookmarks, spell check, macro recording, automobile power
windows, online update of tax code changes, telephone speed-dialing,
and automatic virus signature updating are examples of product features.
A feature can encompass multiple use cases, and each use case
requires that multiple functional requirements be implemented to allow
the user to perform the task.
To get a better grasp on some of the different kinds of requirements I’ve
been discussing, consider a word processing program. A business
requirement might read, “The product will allow users to correct spelling
errors in a document efficiently.” The product’s box cover announces that
a spell checker is included as a feature that satisfies this business
requirement. Corresponding user requirements might include tasks—use
cases—such as “Find spelling errors” and “Add word to global dictionary.”
The spell checker has many individual functional requirements, which
deal with operations such as finding and highlighting a misspelled word,
displaying a dialog box with suggested replacements, and globally
replacing misspelled words with corrected words. The quality attribute
called usability would specify just what is meant by the word “efficiently”
in the business requirement.
Managers or marketing define the business requirements for software
that will help their company operate more efficiently (for information
systems) or compete successfully in the marketplace (for commercial
products). All user requirements must align with the business
requirements. The user requirements permit the analyst to derive the bits
of functionality that will let the users perform their tasks with the product.
Developers use the functional and nonfunctional requirements to design
solutions that implement the necessary functionality and achieve the
specified quality and performance objectives, within the limits that the
constraints impose.
Although the model in Figure 1-1 shows a top-down flow of requirements,
you should expect cycles and iteration between the business, user, and
functional requirements. Whenever someone proposes a new feature,
use case, or functional requirement, the analyst must ask, “Is this in
scope?” If the answer is “yes,” the requirement belongs in the
specification. If the answer is “no,” it does not. If the answer is “no, but it
ought to be,” the business requirements owner or the funding sponsor
must decide whether to increase the project scope to accommodate the
new requirement. This is a business decision that has implications for the
project’s schedule and budget.
Benefits from a High-Quality Requirements
Process
Organizations that implement effective requirements engineering
processes can reap multiple benefits. A great reward comes from
reducing unnecessary rework during the late development stages and
throughout the lengthy maintenance period. The high leveraging effect of
quality requirements isn’t obvious, and many people mistakenly believe
that time spent discussing requirements simply delays delivery by the
same duration. A holistic cost-of-quality perspective reveals the value of
emphasizing early-stage quality practices (Wiegers 1996a).
Sound requirements processes emphasize a collaborative approach to
product development that involves multiple stakeholders in a partnership
throughout the project. Collecting requirements enables the development
team to better understand its user community or market, a critical
success factor for any project. It’s far cheaper to reach this understanding
before you build the product than after your customers receive it.
Engaging users in the requirements-gathering process generates
enthusiasm for the product and builds customer loyalty. By emphasizing
user tasks instead of superficially attractive features, the team can avoid
writing code that won’t ever be used. Customer involvement reduces the
expectation gap between what the user needs and what the developer
delivers. You’re going to get the customer feedback eventually. Try to get
it early rather than late, perhaps with the help of prototypes that stimulate
user feedback. Requirements development takes time, but it takes less
time than correcting a lot of problems in beta testing or after release.
There are additional benefits, too. Explicitly allocating selected system
requirements to various software, hardware, and human subsystems
emphasizes a systems approach to product engineering. An effective
change-control process will minimize the adverse impact of requirements
changes. Documented, unambiguous requirements greatly facilitate
system testing, which in turn increases your chances of delivering highquality products that satisfy all stakeholders.
No one can promise a specific return on investment from an improved
requirements process. You can go through an analytical thought process
to imagine how better requirements could help you, though. First,
consider the cost of investing in a better process. This includes the cost
of assessing your current practices, developing new procedures and
document templates, training the team, buying books and tools, and
perhaps using outside consultants. Your greatest investment is the time
your teams spend gathering, documenting, reviewing, and managing
their requirements. Next, think about the possible benefits you might
enjoy and how much time or money they could save you. It’s impossible
to quantify all the following benefits, but they are real:
Fewer requirements defects
Reduced development rework
Fewer unnecessary features
Lower enhancement costs
Faster development
Fewer miscommunications
Reduced scope creep
Reduced project chaos
More accurate system-testing estimates
Higher customer and team member satisfaction
Characteristics of Excellent Requirements
How can you distinguish good requirements specifications from those
with problems? Several characteristics that individual requirement
statements should exhibit are discussed in this section, followed by
desirable characteristics of the SRS as a whole (Davis 1993; IEEE
1998b). The best way to tell whether your requirements have these
desired attributes is to have several project stakeholders carefully review
the SRS. Different stakeholders will spot different kinds of problems. For
example, analysts and developers can’t accurately judge completeness
or correctness, whereas users can’t assess technical feasibility.
Requirement Statement Characteristics
In an ideal world, every individual user, business, and functional
requirement would exhibit the qualities described in the following
sections.
Complete
Each requirement must fully describe the functionality to be delivered. It
must contain all the information necessary for the developer to design
and implement that bit of functionality. If you know you’re lacking certain
information, use TBD (to be determined) as a standard flag to highlight
these gaps. Resolve all TBDs in each portion of the requirements before
you proceed with construction of that portion.
Correct
Each requirement must accurately describe the functionality to be built.
The reference for correctness is the source of the requirement, such as
an actual user or a high-level system requirement. A software
requirement that conflicts with its parent system requirement is not
correct. Only user representatives can determine the correctness of user
requirements, which is why users or their close surrogates must review
the requirements.
Feasible
It must be possible to implement each requirement within the known
capabilities and limitations of the system and its operating environment.
To avoid specifying unattainable requirements, have a developer work
with marketing or the requirements analyst throughout the elicitation
process. The developer can provide a reality check on what can and
cannot be done technically and what can be done only at excessive cost.
Incremental development approaches and proof-of-concept prototypes
are ways to evaluate requirement feasibility.
Necessary
Each requirement should document a capability that the customers really
need or one that’s required for conformance to an external system
requirement or a standard. Every requirement should originate from a
source that has the authority to specify requirements. Trace each
requirement back to specific voice-of-the-customer input, such as a use
case, a business rule, or some other origin.
Prioritized
Assign an implementation priority to each functional requirement, feature,
or use case to indicate how essential it is to a particular product release.
If all the requirements are considered equally important, it’s hard for the
project manager to respond to budget cuts, schedule overruns, personnel
losses, or new requirements added during development.
Unambiguous
All readers of a requirement statement should arrive at a single,
consistent interpretation of it, but natural language is highly prone to
ambiguity. Write requirements in simple, concise, straightforward
language appropriate to the user domain. “Comprehensible” is a
requirement quality goal related to “unambiguous”: readers must be able
to understand what each requirement is saying. Define all specialized
terms and terms that might confuse readers in a glossary.
Verifiable
See whether you can devise a few tests or use other verification
approaches, such as inspection or demonstration, to determine whether
the product properly implements each requirement. If a requirement isn’t
verifiable, determining whether it was correctly implemented becomes a
matter of opinion, not objective analysis. Requirements that are
incomplete, inconsistent, infeasible, or ambiguous are also unverifiable
(Drabick 1999).
Requirements Specification Characteristics
It’s not enough to have excellent individual requirement statements. Sets
of requirements that are collected into a specification ought to exhibit the
characteristics described in the following sections.
Complete
No requirements or necessary information should be absent. Missing
requirements are hard to spot because they aren’t there! Chapter 7
suggests some ways to find missing requirements. Focusing on user
tasks, rather than on system functions, can help you to prevent
incompleteness.
Consistent
Consistent requirements don’t conflict with other requirements of the
same type or with higher-level business, system, or user requirements.
Disagreements between requirements must be resolved before
development can proceed. You might not know which single requirement
(if any) is correct until you do some research. Recording the originator of
each requirement lets you know who to talk to if you discover conflicts.
Modifiable
You must be able to revise the SRS when necessary and to maintain a
history of changes made to each requirement. This dictates that each
requirement be uniquely labeled and expressed separately from other
requirements so that you can refer to it unambiguously. Each requirement
should appear only once in the SRS. It’s easy to generate
inconsistencies by changing only one instance of a duplicated
requirement. Consider cross-referencing subsequent instances back to
the original statement instead of duplicating the requirement. A table of
contents and an index will make the SRS easier to modify. Storing
requirements in a database or a commercial requirements management
tool makes them into reusable objects.
Traceable
A traceable requirement can be linked backward to its origin and forward
to the design elements and source code that implement it and to the test
cases that verify the implementation as correct. Traceable requirements
are uniquely labeled with persistent identifiers. They are written in a
structured, fine-grained way as opposed to crafting long narrative
paragraphs. Avoid lumping multiple requirements together into a single
statement; the different requirements might trace to different design and
code elements.
When Bad Requirements Happen to Nice People
The major consequence of requirements problems is rework—doing over
something that you thought was already done. Rework can consume 30
to 50 percent of your total development cost (Boehm and Papaccio
1988), and requirements errors account for 70 to 85 percent of the
rework cost (Leffingwell 1997). As illustrated in Figure 1-4, it costs far
more to correct a defect that’s found late in the project than to fix it shortly
after its creation (Grady 1999). Preventing requirements errors and
catching them early therefore has a huge leveraging effect on reducing
rework. Imagine how different your life would be if you could cut the
rework effort in half! You could build products faster, build more and
better products in the same amount of time, and perhaps even go home
occasionally.
Shortcomings in requirements practices pose many risks to project
success, where success means delivering a product that satisfies the
user’s functional and quality expectations at agreed-on cost and
schedule. Chapter 23, “Software Requirements and Risk Management,”
describes how to manage such risks to prevent them from derailing your
project. Some of the most common requirements risks are described in
the following sections.
Insufficient User Involvement
Customers often don’t understand why it is so essential to work hard on
gathering requirements and assuring their quality. Developers might not
emphasize user involvement, either because working with users isn’t as
much fun as writing code or because they think they already know what
the users need. In some cases, it’s difficult to gain access to people who
will actually use the product, and user surrogates don’t always
understand what users really need. Insufficient user involvement leads to
late-breaking requirements that delay project completion. There’s no
substitute for having the development team work directly with actual
users throughout the project, as described in Chapter 6.
Creeping User Requirements
As requirements evolve and grow during development, projects often
exceed their planned schedules and budgets. Such plans aren’t always
based on realistic understandings of the size and complexity of the
requirements; constant requirements modifications make the problem
worse. The problem lies partly in the users’ frequent requests for
changes in the requirements and partly in the way that developers
respond to these requests.
To manage scope creep, begin with a clear statement of the project’s
business objectives, strategic vision, scope, limitations, success criteria,
and expected product usage. Evaluate all proposed new features or
requirements changes against this reference framework. An effective
change process that includes impact analysis will help the stakeholders
make informed business decisions about which changes to accept and
the associated costs in time, resources, or feature trade-offs. Change is
often critical to success, but change always has a price.
As changes propagate through the product being developed, its
architecture can slowly crumble. Code patches make programs harder to
understand and maintain. Added code can cause modules to violate the
solid design principles of strong cohesion and loose coupling (McConnell
1993). To minimize this type of quality degradation, flow requirements
changes through the architecture and design rather than implementing
them directly into code.
Ambiguous Requirements
Ambiguity is the great bugaboo of requirements specifications (Lawrence
1996). One symptom of ambiguity is that a reader can interpret a
requirement statement in several ways. Another sign is that multiple
readers of a requirement arrive at different understandings of what it
means. Chapter 10 lists many words and phrases that contribute to
ambiguity by placing the burden of interpretation on the reader. Ambiguity
also results from imprecise and insufficiently detailed requirements that
force developers to fill in the blanks.
Ambiguity leads to different expectations on the part of various
stakeholders. Some of them are then surprised with whatever is
delivered. Ambiguous requirements result in wasted time when
developers implement a solution for the wrong problem. Testers who
expect the product to behave differently from what the developers
intended waste time resolving the differences.
One way to ferret out ambiguity is to have people who represent different
perspectives formally inspect the requirements. (See Chapter 15,
“Validating the Requirements,” for more on this subject.) Simply passing
around the requirements document for comments isn’t sufficient to reveal
ambiguities. If different reviewers interpret a requirement in different ways
but it makes sense to each of them, the ambiguity won’t surface until late
in the project, when correcting it can be expensive. Writing test cases
against the requirements and building prototypes are other ways to
discover ambiguities. Gause and Weinberg (1989) describe additional
ambiguity-detection methods.
Gold Plating
Gold plating takes place when a developer adds functionality that wasn’t
in the requirements specification but that the developer believes “the
users are just going to love.” Often users don’t care about this excess
functionality, and the time spent implementing it is wasted. Rather than
simply inserting new features, developers and analysts should present
the customers with creative ideas and alternatives for their consideration.
Developers should strive for leanness and simplicity, not for going
beyond what the customer requests without customer approval.
Customers sometimes request features or elaborate user interfaces that
look cool but add little value to the product. Everything you build costs
time and money, so you need to maximize the delivered value. To reduce
the threat of gold plating, trace each bit of functionality back to its origin
so that you know why it’s included. The use-case approach for eliciting
requirements helps to focus requirements elicitation on the functionality
that lets users perform their business tasks.
Minimal Specification
Sometimes marketing staff or managers are tempted to create a limited
specification, perhaps just a product concept sketched on a napkin. They
expect the developers to flesh out the spec while the project progresses.
This might work for a tightly integrated team that’s building a small
system, on exploratory or research projects, or when the requirements
truly are flexible (McConnell 1996). In most cases, though, it frustrates
the developers (who might be operating under incorrect assumptions and
with limited direction) and disappoints the customers (who don’t get the
product they envisioned).
Overlooked User Classes
Most products have several groups of users who might use different
subsets of features, have different frequencies of use, or have varying
experience levels. If you don’t identify the important user classes for your
product early on, some user needs won’t be met. After identifying all user
classes, make sure that each has a voice, as discussed in Chapter 6,
“Finding the Voice of the Customer.”
Inaccurate Planning
“Here’s my idea for a new product; when will you be done?” Don’t answer
this question until you know more about the problem being discussed.
Vague, poorly understood requirements lead to overly optimistic
estimates, which come back to haunt us when the inevitable overruns
occur. An estimator’s off-the-cuff guess sounds a lot like a commitment to
the listener. The top contributors to poor software cost estimation are
frequent requirements changes, missing requirements, insufficient
communication with users, poor specification of requirements, and
insufficient requirements analysis (Davis 1995). When you present an
estimate, provide either a range (best case, most likely, worst case) or a
confidence level (“I’m 90 percent sure I can have that done within three
months”).
Root Causes of Project Success and Failure
The Root Causes of Project Success and Failure
The first step in resolving any problem is to understand the root causes. Fortunately, the Standish
Group survey went beyond the assessment phase and asked survey respondents to identify the most
significant factors that contributed to projects that were rated “success,” “challenged” (late and did not
meet expectations), and “impaired” (canceled), respectively.
Here we discover that the emphasis in this book on requirements management is not frivolous or
arbitrary; it’s a response to accumulating evidence that many of the most common, most serious
problems associated with software development are related to requirements. The 1994 Standish Group
study noted the three most commonly cited factors that caused projects to be “challenged”:
1. Lack of user input: 13 percent of all projects
2. Incomplete requirements and specifications: 12 percent of all projects
3. Changing requirements and specifications: 12 percent of all projects
Thereafter, the data diverges rapidly. Of course, your project could fail because of an unrealistic
schedule or time frame (4 percent of the projects cited this), inadequate staffing and resources (6
percent), inadequate technology skills (7 percent), or various other reasons. Nevertheless, to the extent
that the Standish figures are representative of the overall industry, it appears that at least a third of
development projects run into trouble for reasons that are directly related to requirements gathering,
requirements documentation, and requirements management.
Although the majority of projects do seem to experience schedule/budget overruns, if not outright
cancellation, the Standish Group found that 9 percent of the projects in large companies were delivered
on time and on budget; 16 percent of the projects in small companies enjoyed a similar success. That
leads to an obvious question: What were the primary “success factors” for those projects? According to
the Standish study, the three most important factors were
1. User involvement: 16 percent of all successful projects
2. Executive management support: 14 percent of all successful projects
3. Clear statement of requirements: 12 percent of all successful projects
The two largest problems, appearing in about half the responses, were
1. Requirements specifications
2. Managing customer requirements
Again, corroborating the Standish survey, coding issues were a “nonproblem,” relatively speaking.
It seems clear that requirements deserve their place as a leading root cause of software problems, and
our continuing personal experiences support that conclusion. Let’s take a look at the economic factors
associated with this particular root cause.
