[WIEGERS-2003], Chapter 1 [WIEGERS-2003], Chapter 2 [WIEGERS-2003], Chapter 3 [WIEGERS-2003], Chapter 5

1. ************ [WIEGERS-2003], Chapter 1 **************************************************************
Many software problems arise from shortcomings in the ways that people gather, document, agree on, and modify the
product's requirements. The problem areas might include informal information gathering, implied functionality,
erroneous or uncommunicated assumptions, inadequately defined requirements, and a casual change process.
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
(Sommerville 1997). Requirements must be documented, they are the foundation for both the software development
and the project management activities, all stakeholders must be committed to following an effective requirements
process.
Software requirements include three distinct
levels—business requirements, user
requirements, and functional requirements.
In addition, every system has an assortment
of nonfunctional requirements.
Business requirements describe why the
organization is implementing the system—
the objectives the organization hopes to
achieve.
User requirements describe user goals or
tasks that the users must be able to perform
with the product.
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. Functional
requirements are documented in a software requirements specification (SRS). System requirements describes the top-
level requirements for a product that contains multiple subsystems—that is, a system.
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.
Requirements specifications do NOT include design or implementation details (other than known constraints), project
planning information, or testing information. These are project requirements but not product requirements;
These sub disciplines encompass all the
activities involved with gathering, evaluating,
and documenting the requirements for a
software or software-containing product.

2. Requirements management entails
"establishing and maintaining an
agreement with the customer on the
requirements for the software
project".
It costs far more to correct a defect
that's found late in the project than
to fix it shortly after its creation.
Preventing requirements errors and
catching them early therefore has a
huge leveraging effect on reducing
rework.
When Bad Requirements Happen to Nice People
 Insufficient user involvement leads to late-breaking requirements that delay project completion.
 Creeping User Requirements
 Ambiguous Requirements
 Gold Platting, when a developer adds functionality that wasn't in the requirements specification
 Minimal Specification
 Overlooked User Classes
 Inaccurate Planning
Benefits from a High-Quality Requirements Process
 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
Requirement Statement Characteristics
 Complete
 Correct
 Feasible
 Necessary
 Prioritized
 Unambiguous
 Verifiable
Requirements Specification Characteristics
 Complete
 Consistence
 Modifiable
 Traceable

3. ************ [WIEGERS-2003], Chapter 2 **************************************************************
Customer is an individual or organization who derives either direct or indirect benefit from a product.
Signing off on the requirements document is the mark of customer approval of the requirements. Don't use sign-off as a
weapon. Use it as a project milestone, with a clear, shared understanding of the activities that lead to sign-off and its
implications for future changes

4. ************ [WIEGERS-2003], Chapter 3 **************************************************************

6. A Requirements Development Process
************ [WIEGERS-2003], Chapter 5 **************************************************************
Establishing the Product Vision and Project Scope
The business requirements represent the top level of abstraction in the requirements chain: they define the vision and
scope for the software system. The user requirements and software functional requirements must align with the context
and objectives that the business requirements establish. Requirements that don't help the project achieve its business
objectives shouldn't be included.
Defining the Vision through Business Requirements

7. Business Requirements and Use Cases
The business requirements determine both the set of business tasks (use cases) that the application enables (the
application breadth) and the depth or level to which each use case is implemented. If the business requirements help
you determine that a particular use case is outside the project's scope, you're making a breadth decision. The depth of
support can range from a trivial implementation to full automation with many usability aids. The business requirements
will imply which use cases demand robust, comprehensive functional implementation and which require merely
superficial implementation, at least initially.
Vision and scope document collects the business requirements
into a single document that sets the stage for the subsequent
development work.
Business Opportunity: Exploit the poor security record of a
competing product.
Business Objective: Capture a market share of 80 percent by
being recognized as the most secure product in the market
through trade journal reviews and consumer surveys.
Customer Need: A more secure product.
Feature: A new, robust security engine.
The scope description establishes the boundary and
connections between the system we are developing
and everything else in the universe. The context
diagram graphically illustrates this boundary. It
identifies terminators outside the system that
interface to it in some way, as well as data, control,
and material flows between the terminators and the
system.
The purpose of tools such as the context diagram is to
foster clear and accurate communication among the
project stakeholders.