Chapter 1

 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.
 Types of requirement

 Business requirements describe why the organization is implementing the system

 record the business requirements in a vision and scope document.

 User requirements describe goals or tasks the users must be able to perform with the
product that will provide value to someone. The domain of user requirements also includes
descriptions of product attributes or characteristics that are important to user satisfaction.
Ways to represent user requirements include use cases (Kulak and Guiney 2004), user
stories.

 the same user requirement might read: “As a passenger, I want to check in for a fight so I
can board my airplane.”

 Functional requirements specify the behaviours the product will exhibit under specific
conditions. They describe what the developers must implement to enable users to
accomplish their tasks (user requirements), thereby satisfying the business requirements.
This alignment among the three levels of requirements is essential for project success.
Functional requirements often are written in the form of the traditional “shall” statements:
“The Passenger shall be able to print boarding passes for all fight segments for which he has
checked in” or “If the Passenger’s profile does not indicate a seating preference, the
reservation system shall assign a seat.

 software requirements specifcation (SRS), which describes as fully as necessary the expected
behavior of the software system. The SRS is used in development, testing, quality assurance,
project management, and related project functions.
 System requirements describe the requirements for a product that is composed of multiple
components or subsystems.

 A good example of a “system” is the cashier’s workstation in a supermarket. There’s a bar

code scanner integrated with a scale, as well as a hand-held bar code scanner. The cashier
has a keyboard, a display, and a cash drawer. You’ll see a card reader and PIN pad for your
loyalty card and credit or debit card, and perhaps a change dispenser. You might see up to
three printers for your purchase receipt, credit card receipt, and coupons you don’t care
about. These hardware devices are all interacting under software control. The requirements
for the system or product as a whole, then, lead the business analyst to derive specifc
functionality that must be allocated to one or another of those component subsystems, as
well as demanding an understanding of the interfaces between them.

 Business rules include corporate policies, government regulations, industry standards, and
computational algorithms.

 Non func requirements Quality attributes are also known as quality factors, quality of
service requirements, constraints, and the “–ilities.” They describe the product’s
characteristics in various dimensions that are important either to users or to developers and
maintainers, such as performance, safety, availability, and portability. Other classes of
nonfunctional requirements describe external interfaces between the system and the
outside world. These include connections to other software systems, hardware components,
and users, as well as communication interfaces.

 Requirement development we subdivide requirements development into elicitation,

analysis, specifcation, and validation.

 Elicitation encompasses all of the activities involved with discovering requirements, such as
interviews, workshops, document analysis, prototyping, and others.

 Analysis Analyzing requirements involves reaching a richer and more precise understanding
of each requirement and representing sets of requirements in multiple ways.

 Following are the principal activities: ■ Analyzing the information received from users to
distinguish their task goals from functional requirements, quality expectations, business
rules, suggested solutions, and other information ■ Decomposing high-level requirements
into an appropriate level of detail ■ Deriving functional requirements from other
requirements information ■ Understanding the relative importance of quality attributes ■
Allocating requirements to software components defned in the system architecture ■
Negotiating implementation priorities ■ Identifying gaps in requirements or unnecessary
requirements as they relate to the defned scop

 Specifcation Requirements specifcation involves representing and storing the collected

requirements knowledge in a persistent and well-organized fashion.
  Validation Requirements validation confrms that you have the correct set of requirements
information that will enable developers to build a solution that satisfes the business
objectives

 Requirement management The object of requirements management is not to stife change

or to make it diffcult. It is to anticipate and accommodate the very real changes that you can
always expect so as to minimize their disruptive impact on the project.

 Creeping user requirements As requirements evolve during development, projects often

exceed their planned schedules and budgets (which are nearly always too optimistic
anyway). To manage scope creep, begin with a clear statement of the project’s business
objectives, strategic vision, scope, limitations, and success criteria. Evaluate all proposed
new features or requirements changes against this reference.

 Gold plating Gold plating takes place when a developer adds functionality that wasn’t in the
requirements specifcation (or was deemed out of scope) but which the developer believes
“the users are just going to love.”

Chapter 2

Reaching agreement on requirements

 Reaching agreement on the requirements for the product to be built, or for a specifc portion
of it, is at the core of the customer-developer partnership. Multiple parties are involved in
this agreement: ■ Customers agree that the requirements address their needs. ■ Developers
agree that they understand the requirements and that they are feasible. ■ Testers agree
that the requirements are verifable. ■ Management agrees that the requirements will
achieve their business objectives
 Many organizations use the act of “signing off” (why not “signing on”?) on the requirements
as the mark of stakeholder approval. All participants in the requirements approval process
should know exactly what sign-off means or problems could ensue. One such problem is the
customer representative or manager who regards signing off on the requirements as a
meaningless ritual: “I was handed a piece of paper with my name on it, so I signed on the
line above my name because otherwise the developers wouldn’t start coding.” This can lead
to future problems when that individual wants to change the requirements or when he’s
surprised by what is delivered: “Sure, I signed off on the requirements, but I didn’t have time
to read them all. I trusted you guys—you let me down!” Equally problematic is the
development manager who views sign-off as a way to freeze the requirements
 Don’t use sign-off as a weapon. Treat it as a milestone, with a clear, shared understanding of
the activities that lead to sign-off and its implications for future changes
 baseline of the requirements agreement
 A requirements baseline is a set of requirements that has been reviewed and agreed upon
and serves as the basis for further development.
 the subtext of that agreement should read something like this:
 “I agree that this set of requirements represents our best understanding of the
requirements for the next portion of this project and that the solution described will meet
our needs as we understand them today. I agree to make future changes in this baseline
through the project’s defned change process. I realize that changes might require us to
renegotiate cost, resource, and schedule commitments.”
 What if you don’t reach agreement? It can be hard to achieve sign-off from all the relevant
stakeholders. Barriers include logistics, busy schedules, and people who are reluctant to
commit and be held accountable later. In such a situation, you’re better off moving forward
—cautiously—with the assumption that you don’t have approval from the recalcitrant
stakeholders. Document the fact that certain stakeholders didn’t sign off on the
requirements in your risk list, along with the likely impact of some of the requirements being
missing or wrong
 Agreement on agile process Agile projects do not include a formal sign-off action. Agile
projects generally maintain requirements in the form of user stories in a product backlog.
The product owner and the team reach agreement on what stories will be developed in the
next iteration in a planning session. The set of stories is chosen based on their priority and
the team’s velocity (productivity). After that set has been established and agreed to, the
stories contained in the iteration are frozen. Requested changes that come in are considered
for future iterations. There’s no attempt on an agile project to achieve stakeholder approval
on the full scope of requirements for the project up front, however. In agile projects the full
set of functionality is identifed over time, although the vision and other business
requirements do need to be established at the outset.