State of California
Department of Technology
General Requirements Guidelines
Statewide Information Management Manual – Section 170A
August 2016
Table of Contents
1. Introduction
................................
.....................................................................................
......................................................................................................................
..................................................................................................................
2
1
.1 Overview 2
1.2 Background 2
1.3 References
................................
...................................................................................
................................................................................
......................................................................................
........................................................................................................
......................................................................................................................
3
2. I
T Solicitation Documentation Guide 3
2.1 Capitalization and Punctuation 4
2.2 Grammatical Mood 4
2.3 Grammar 5
2.4 Vocabulary
................................
...................................................................................
..............................................................
....................................................................................................................
.............................................................................................................
............................................................................................
6
2
.5 Cross-referencing and Information Placement 10
2.6 Audience 10
2.7 Workmanship 10
2.8 Contractor Responsibility 11
2.9 Deliverables................................................................................................................
.....................................................................................................
11
3. Requirements Guide 13
3.1 FOUR “C’S”................................................................................................................
..........................................................................
..............................................................................
............................................................................................
13
3.2 Requirements: Do, Do Not and Avoid 14
3.3 Assigning Priority to Requirements 16
3.4 Requirement Traceability 16
List of Tables
Table 1: Grammatical Mood
................................
...................................................................
.......................................................................................
........................................................................................................
5
Ta
ble 2: Examples of Grammar Use 6
Table 3: Vocabulary Use 7
Table 4: Deliverables
................................
...........................................................................
12
Ta
ble 5
: Requirements Do, Do Not and Avoid ................................
.......................................
14
California Department of Technology
SIMM Section 170A
General Requirements Guidelines August 2016
1
California Department of Technology 2
SIMM Section 170A
General Requirements Guidelines August 2016
GENERAL GUIDELINES
1. I
ntroduction
The General Requirements Guidelines are designed to assist Agencies/state entities with the
development of requirements for the Project Approval Lifecycle (PAL). These guidelines are
based on proven industry practices, methods and experience from California information
technology (IT) projects. These guidelines support Statewide Information Management Manual
(SIMM) Section 170B Project Requirements Development Instructions which include a step by
step approach for developing and managing solution requirements. Agencies/state entities may
use as much or as little of these guidelines as appropriate.
Document Format Information:
Guidance is provided in normal text.
Samples are provided in italicized text.
1.1 Overview
These guidelines provide the elements needed to develop strong IT solicitation documentation,
effective mid-level and detailed solution requirements, and will help reduce difficulties
encountered while writing IT solicitation documentation and solution requirements. Leveraging
this tool will help improve requirement consistency, quality, and usability throughout the PAL
process, during IT project implementation and into maintenance and operations.
1.2 Background
Development of IT solicitation documentation and solution requirements for IT projects is
inherently difficult, many times resulting in high stress for staff during
implementations. Oftentimes solution requirements appear to ask for exactly what is needed
but are written too broadly or in a generic manner. For example, consider this:
“The solution shall be robust and very user-friendly”
In the above requirement, it appears the solution needs to be robust and user-friendly.
However, the terms “robust” and “user-friendly” cannot be objectively and fairly evaluated.
Because solicitation documents effectively become legally enforceable contract documents,
requirement documents should be prepared with concern and respect for their potential legal
status. Every sentence should provide value to the objective of the document
section. Therefore, it is critical that the documents are written using effective practical
communication practices.
According to IEEE 24765:2010, a requirement is defined 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, system component, product, or service to satisfy an agreement,
standard, specification, or other formally imposed documents 3. a documented representation of
a condition or capability as in (1) or (2) 4. a condition or capability that must be met or
possessed by a system, product, service, result, or component to satisfy a contract, standard,
specification, or other formally imposed document. ”
California Department of Technology 3
SIMM Section 170A
General Requirements Guidelines August 2016
The state’s newly implemented PAL process includes additional clarity in project procurement
methods. As the lifecycle is further refined, the state is simultaneously working on improving
the quality of IT project requirements, which ultimately become biddable specifications.
Understanding these guidelines is the first step in a comprehensive set of documents that will
assist staff with the development of useful IT solicitation requirements.
Note: The guidelines, instructions and exhibits are for instructional purposes and not intended
to mandate how requirements are created.
1.3 References
In addition to this document, the following documents and exhibits will assist state IT project and
procurement staff in understanding what well-written requirements consist of:
DOCUMENT REFERENCES
SIMM Section 170A Exhibit A: Strong Requirement Samples
SIMM Section 170B Project Requirements Development Instructions
SIMM Section 170B Exhibit B1 – B6: Expanded Requirement Samples
SIMM Section 170B Exhibit C: Glossary Sample
SIMM Section 170B Exhibit D: Requirements Development Workflow
SIMM 19B.3 – Mid-Level Solution Requirements
http://www.cio.ca.gov/Government/IT_Policy/SIMM_19/SIMM19.html
SIMM 19.C Stage 3 Solution Development
SIMM 19C.3 Stage 3 Solution Development Template (Part A)
SIMM 19C.5 Stage 3 Solution Development Requirement Template
2. IT Solicitation Documentation Guide
Application of the following basic language practices will improve practicality and fluidity of IT
solicitation documentation and requirements. Documents should be consistent and subject to
uniform interpretations. Writing style and sentence structure matter and the conceptual integrity
presented is important to its interpretation. Extra unnecessary words increase the risk of
confusion, misinterpretation, and contradiction.
2.1 Capitalization and Punctuation
Capitalization should be consistent throughout the
solicitation document and resulting contract
documents. Capitalization of the initial letter of
certain specific nouns and proper names defined
in a contract is appropriate.
Because IT solicitation documents can become
legal documents, the formal rules of punctuation
must be observed. Sentences should be
constructed so that the misplacement or
elimination of a punctuation mark will not change
the meaning. Commas should be used after each
item in a series, including the item preceding a
conjunction, and in other locations where the
clarity of the statement will be improved.
Specify capitalization and punctuation
requirements when using lists.
Capitalization Examples:
Change Order: When issued as a
modification to a
contract (time and/or
sum).
Contract:
When referring to the
specific contract or
agreement.
Contractor: When referring to the
contractor who is party
to the state-contractor
agreement.
Diagrams: When referring to
graphic portions of the
contract work.
Government: When a government
agency is a party to the
contract.
Paragraph:
When referring to a
paragraph in
deliverables or other
contract documents.
Project: When referring to the
specific project of which
the work is a part.
Work:
When referring to the
work of a specific
contract.
No capitalization is required when the
preceding examples are used in the
general sense.
2.2 Grammatical Mood
Strive to maintain the same grammatical mood throughout. Consistent use of terminology and
language contributes to good communication. Whereas, two basic grammatical sentence moods
can be used to convey requirements; using the imperative mood results in requirements that
are shorter, crisper, and easier to understand. Mood conveys the attitude about the state of
being of what the sentence describes. (e.g., as a fact, a command, a wish, an uncertainty):
Imperative mood: The imperative mood gives direction where the subject is implied and
the verb expresses command or direction. The examples below imply that the subject is
the “solution”, “system” or “contractor” and does not need to be stated. The imperative
mood expresses a command or a request. For example:
“Accept transactions from clients through the on-line portal.”
California Department of Technology
SIMM Section 170A
General Requirements Guidelines August 2016
4
California Department of Technology 5
SIMM Section 170A
General Requirements Guidelines August 2016
Indicative mood: The indicative mood refers to actions, events, or states that are
believed to be true. For example:
“Provide the capability to accept transactions from clients via the web.”
Table 1: Grammatical Mood
Imperative
Mood
Examples:
• “Respond to a communication request
using an adapter.”
• “Install equipment in accordance with
manufacturer instructions.”
• “Encode the message node within the
message structure.”
Indicative
Mood
Examples:
• “Adapters shall respond to a
communication request. “
• “Equipment shall be installed in
accordance with the manufacturer
instructions.”
• “Each message shall be encoded within
the message node.”
2.3 Grammar
When applicable, IT solicitation documents and requirements should be written in second-
person language and in active voice. Second-person is often appropriate for e-mail messages,
presentations, and business and technical writing. When using the second person, the subject
of the sentence is the person/thing being addressed. Documents are written as though the
writer is talking to the person as they carry out the instructions. This last point is easily
identifiable where the results of the instructions are described. These descriptions should be
given as if the results have just happened.
California Department of Technology 6
SIMM Section 170A
General Requirements Guidelines August 2016
Table 2: Examples of Grammar Use
Poor Grammar
Better Grammar
The user presses the Delete key.
(Result: The customer details will be
displayed.)
Press the Delete key.
(Result: The customer details are displayed.)
Starting the batch job starts the report. (This
is Indicative, not imperative)
The report is generated by starting the batch
job. (This is Passive voice; not Active)
The operator starts the batch job to generate
the report. (This is Third-person; not Second-
person)
Start the batch job to generate the report.
(This is imperative mood, active voice, and in
second-person)
Subject/Verb Agreement
Th
e subject and verb must always agree in number. Singular verbs should be used with singular
subjects and plural verbs with plural subjects. An error in number is easy to make when a
sentence is long and complicated. The singular subject of a sentence can be confused with a
plural identifier.
P
arallel Construction
G
ood grammar also requires the use of identical style in both parts of a compound subject or
predicate. The use of identical style in a series of nouns, adverbs, or prepositional phrases is
also recommended.
2.4 Vocabulary
Select words carefully and use them for their precise meaning. Use conventional terminology
when defining requirements. When unique terms are used, provide the definition of said term(s)
and appropriately submit the terms to the project glossary. Once a word is selected, use it
consistently throughout the solicitation document whenever the same meaning is intended. The
following are some examples of commonly misused or ambiguous terms along with guidelines
for their recommended usage in project documentation and resulting contracts.
California Department of Technology 7
SIMM Section 170A
General Requirements Guidelines July 2016
Table 3: Vocabulary Use
Selected Word
Do Not Use
Do Use
Any
The word “any” is imprecise in
number permitting discretion by
the reader/bidder.
Example
“Data published to the queue is
received by the client subscribers”
This clearly means all client
subscribers.
And, Or,
And/Or
The word "and" connects
elements that are to be taken
jointly. It may also mean plus, or
added to a preceding quantity.
"Or" is used to introduce any of
the possibilities in a series.
Two words together (and/or)
represent a hybrid term often used
in legal and business documents
as a grammatical shortcut.
Avoid using the term "and/or".
Example
“Clients with child dependents and
positive employment status will receive
notifications”
This clearly means that the client
needs both conditions to receive
notifications.
Example
“Clients with child dependents or
positive employment status will receive
notifications”
This clearly means that the client only
needs to satisfy one of the two
conditions to receive notifications.
California Department of Technology 8
SIMM Section 170A
General Requirements Guidelines August 2016
Selected Word
Do Not Use
Do Use
Either and
Both
The word “either" implies a choice
between two options, while the
word "both" is inclusive. Make
clear whether the intent is to have
"either” or “both” but not both.
Example
“Provide advance notice of hearings
that may result in either paternity
establishment, or establishment of an
order.”
“Provide advance notice of hearings
that may result in both paternity
establishment, and establishment of an
order.”
Furnish,
“Furnish" means to supply and
These definitions should be placed in
Install, and
deliver to the project, ready for
the conditions of the contract.
Provide
use.
“Install" means to place in position
for service or use.
“Provide" is commonly accepted
in IT project documentation to
mean furnish and install, complete
and ready for intended use.
Observe
“Observe" means to watch or view
and
the execution or performance of
Supervise
work, while “supervise" means to
oversee and to have control and
direction of the work.
California Department of Technology 9
SIMM Section 170A
General Requirements Guidelines August 2016
Selected Word
Do Not Use
Do Use
Party and
The word “party" refers to a signer
Entity
of a contract, such as the
Agency/state entity and contractor
in a state contract. When the
intent is to refer to persons or
firms, such as subcontractors and
others who are involved in the
construction process, but are not
signers of the contract, the
generic term “entity" is
recommended.
Shall and
“Shall" is used as an imperative in
Will
reference to work required to be
done by a party.
“Will" is optional and is used in
connection with acts and actions
required of parties to the contract.
California Department of Technology 10
SIMM Section 170A
General Requirements Guidelines July 2016
2.5 Cross-referencing and Information Placement
Information should be stated ONE time and in the correct place. Information in one document should
not be repeated in other documents or multiple places within the same document; rather they should be
cross-referenced. Each document has a specific purpose and should be used precisely for that
purpose. This simplifies the retrieval of information and substantially reduces the possibility of conflicts
and discrepancies. Everyone involved with a project benefits from this standardized approach to the
placement of information within the document(s).
Specific sections of the solicitation document should be referenced as needed for proper coordination.
References should be made to section numbers rather than to a document, article or page numbers,
which may change with subsequent revisions to the specifications.
2.6 Audience
Instructions should be addressed to the party responsible for the work being specified. Words, such as
"the {contractor} shall," should be omitted but may be added for clarity when more than one party is
mentioned in the same section or paragraph.
Avoid addressing individual subcontractors or disciplines. References to a specific responsibility should
be made to the appropriate specification section. For example, "Data transformation is specified in
Section 123456," rather than, "The Database administrator is responsible for all data transformation."
The intent is to avoid unnecessary words and potential confusion.
2.7 Workmanship
Although quality does depend on software products, it is also affected by the workmanship of humans.
Thus, it is a combination of quality of software products and quality of workmanship that results in the
final quality of the product. Workmanship relating to the design, build, integration, and testing is equally
important to ensure good project outcomes. IT projects are made up of many interrelated products and
each product may require specialized skills to make it a functional part of the project solution.
Specify workmanship requirements, referred to as non-functional requirements, in a manner
appropriate to the needs of the project. These specification statements should be reasonable.
Solicitation document requirements should be specified without demanding conformance to
unattainable measures.
Workmanship statements can be ambiguous if not properly worded. Make positive statements and
avoid broad generalities such as "best possible" or “best practice.” The word "best" can be open to
many interpretations by those reading the solicitation document (future contract).
Appropriate methods for achieving desired workmanship include:
Requiring that work be tested according to an applicable standard or some previously agreed and
documented measure recorded in the appropriate project or contract document
Requiring samples, prototypes, or mock-ups, when necessary, to establish an acceptable level of
quality and a basis for judging subsequent work
Establishing inspection requirements
Referring to applicable standards
California Department of Technology 11
SIMM Section 170A
General Requirements Guidelines August 2016
2.8 Contractor Responsibility
Also referred to as project/transition requirements, contractor requirements clearly identify the
responsibilities, activities, and deliverables provided by the contractor.
Do not use generalized statements, such as:
"The contractor will work in concert with the State to provide/develop/design the solution."
This statement suggests that the activities for the development/design provided by both the contractor
and the State will be combined. This langue has the potential for miscommunication once the vendor
contract is signed, as it suggests that the state hasn’t figured out exactly what their requirement is but
plans to discover it later. Statements such as this can spawn finger pointing and expensive change
orders and schedule delays.
Provide specific boundaries around both contractor and state responsibilities. The separate
responsibilities may be combined to produce an expected outcome, however, specific tasks and
activities should be accountable to one and only one party. Additionally, language such as, “including
but not limited to….” fosters ability to object, confusion, and misunderstanding and should not be used
when describing deliverable contents.
2.9 Deliverables
Solicitations for IT systems should always pay for performance or outcomes as opposed to paying for
paper deliverables. This is usually the result of an excessive numbers of plans required by the state for
vendors to produce without requiring that the vendor’s solution perform at various stages of delivery.
Oftentimes project plans call upon execution of processes and procedures that fall outside the scope of
the vendor's contract leaving the state empty handed. Instead, focus vendor payments on the validation
of solution milestone performance; if the solution doesn't perform as required and documented in the
requirements then payment is not issued.
This allows the project to focus on fundamentals – including professional services, labor, software and
equipment; as well as responsibility for cost, schedule, quality, and management. By focusing on
performance or outcomes the project also avoids considerable administrative effort managing materials
of limited value (short or long term).
Deliverables should be functional and as few as possible. Attempt to limit the number of deliverables to
be provided after contract award and require coordination of those few deliverables with the submitted
proposal. Consider converting many, if not all, administrative deliverables into “general requirements.”
California Department of Technology 12
SIMM Section 170A
General Requirements Guidelines August 2016
Table 4: Deliverables
Deliverables that can
be included with a
proposal
Deliverable Examples
Administrative
•
•
•
•
•
•
Professional services detail
Labor detail
Materials and equipment schedules (lists)
Cost control estimate
Schedule addressed in general requirements (the bidder has to do /
prepare these things to make a proposal)
Architectural Design (AD)
Derived from and directly related to requirements (solicitation
performance specifications) and solicitation reference
materials/standards (e.g., CAEAF & related RA’s); this includes
diagrams and architect’s specifications
Design
• Outline Schematic Design (SD) for Business, Application, and
Information
Each specifically coordinated with the AD
Each specifically coordinated with the others
Includes diagrams and engineering specifications/calculations
if needed
Each to be refined during the design development phase(s) of
work
Additionally, direct the contractor to submit diagrams that contain:
• Standard notation (i.e. ArchiMate 2.0 Specification)
• Sheet identification
• Standard sheet sizes and layout
• A title block
Both diagrams and design specifications are needed to fully describe an IT project. The diagrams are a
graphic representation of the proposed work showing form, relationship, generic type, and identification
of the system being constructed. Design specifications define the qualitative requirements for software,
software products, and workmanship upon which the project proposal is based.
Caution: Design specifications supplement, but should not repeat, information shown on diagrams, nor
should the diagrams repeat information contained in design specifications. If a requirement is repeated
on the diagrams and in the specifications, an opportunity arises for a discrepancy between the two.
Last-minute changes are likely to create discrepancies and cause misunderstandings, oftentimes
resulting in extra work.
California Department of Technology 13
SIMM Section 170A
General Requirements Guidelines August 2016
3. Requirements Guide
3.1 FOUR “C’S”
It is important to strive for simplicity when documenting requirements. Compound requirements are
more difficult to score, implement, and verify. In order to ensure simplicity, requirements should adhere
to the four “C’s” (IEEE standards practice), as follows:
• Clear - Use correct grammar and simple sentence construction to avoid ambiguity. Carefully
select words that convey exact meaning.
• Correct - Present information accurately and precisely.
• Complete - Include important information.
• Concise - Eliminate unnecessary words, but not at the expense of clarity, correctness, or
completeness.
Avoid duplicating or contradicting requirements contained elsewhere in project documents. Refer to
Section 2.5 Cross-referencing and Information Placement above. Inconsistencies discovered should be
corrected, and corrections should be broadcast to all personnel working on the project.
California Department of Technology 14
SIMM Section 170A
General Requirements Guidelines July 2016
3.2 Requirements: Do, Do Not and Avoid
This table contains information that should be referenced when creating IT solicitation documentation and when writing requirements. The
application of this quick-use guide will help create clear and concise requirements. Refer to SIMM Section 170A Exhibit A: Strong
Requirement Samples.
Table 5: Requirements Do, Do Not and Avoid
Do
Do Not
Avoid
Document requirements in a
Use the nouns: “ability” or “capability”.
Compound requirements.
sequential (and not duplicative)
numbering schema.
Write requirements that make reference to
future “deliverables.”
Unclear terms such as "real-time." If
the intent is to set a minimum amount
Use simple sentences.
Use the term "workflow,"
of time allowable for a process or
function to occur, consider specifying
Choose words and terms that are
“seamless/seamlessness,” or “performance”
a measurable limit (e.g., number of
simple and clearly understood.
without first formally defining.
milliseconds). If you must use terms
Select words carefully and use them
Use the term “proven practice" – unless
like "real-time", be sure to add a
for precise meaning. Once a word is
there is written “proof” attached/provided.
glossary item for the term so that the
selected, use it consistently
project's expectations are defined.
throughout the document(s)
whenever the same meaning is
intended.
Rely on a bidder’s/contractor’s subjective
opinion as how a requirement was
intended.
Complicated sentences in which
omission or insertion of punctuation
could change the meaning or create
Use positive expression to convey
Use negative expression to convey ideas.
ambiguity.
ideas. Example: “Applies to all claims
that have not been modified.... “
Example: “Does not apply to claims with
modification <X>”.
Abbreviations with more than one
meaning whenever possible—“When
Spell out acronyms on first use.
Use the word “same" as a pronoun. For
in doubt, spell it out."
Subsequent use of the acronym in
the document is preferred.
example, “The interface must be user
friendly and the application the same.”
Abbreviations of short words that
save one or two characters.
Capitalize the initial letter of certain
project specific nouns and proper
names defined in a solicitation.
Use adjectives like "excessive," "adequate,"
and "sufficient.” These words are
problematic.
Using words that have missing
objects like “as appropriate,” “as
indicated,” “as necessary,” “as
Omit unnecessary words.
Use ambiguous words like "support,"
"open," "consider," or “avoid."
required,” or “as directed.”
Do
Do Not
Avoid
California Department of Technology 15
SIMM Section 170A
General Requirements Guidelines August 2016
Repeat nouns as opposed to using
pronouns to minimize the possibility
of misunderstanding.
Consider each requirement as
having a monetary value. They
represent actual project costs.
Consider whether a court of law
would side with how the requirement
asked for the work to be conducted.
Write self-contained requirements
that avoid references to diagrams,
charts, other sections of the
contract/solicitation document.
Provide accurate metrics where
available. It is helpful if these align
with metrics provided in PAL Stages
1 Business Analysis and Stage 2
Alternatives Analysis.
Specify how ‘in use’ will be defined.
Does the bidder’s solution need to be
fully deployed with no additional
implementation phases in the future,
or will pilot phases be considered “in
use”? A fully vetted system may be
desired, not a system in pilot.
Refer to standards for which
solutions must comply by identifying
the standard sections and/or parts of
the standard for which compliance is
required. Also provide purpose for
the adherence.
Broad brush the solution to adhere to an
entire standard set. The project will
accurately be able to identify
compliance/noncompliance.
Using terms “any or all,” “etc.,” and
“such as.”
Using the terms and expressions like
“to the satisfaction of [entity],” “shall
function as intended,” “best practice,”
and “best practices.” Best is only
“best” according to those that wrote
them.
Using “a" and “an"; as they need not
be used in most cases.
Using adverbs like “hereinafter,”
“hereinbefore,” “herewith,” and
“wherein.”
California Department of Technology 16
SIMM Section 170A
General Requirements Guidelines July 2016
3.3 Assigning Priority to Requirements
Assigning priority to a set of requirements is no easy task. Stakeholders may compete for and assign
priority to requirements that affect their discipline, while other requirements may have no proponents,
yet are equally if not more important. To establish and determine requirement priorities:
Communicate how the requirements development process will work with stakeholders.
Schedule and conduct both working and review requirements development meetings with
stakeholders.
Establish a set of rules and a strategy for dealing with conflict. Without rules of governance,
meetings will not produce effectual results. Maintaining control, while listening to stakeholder
concerns, is critical to proper requirements development.
Determine how many requests are actually being made in the requirement.
If business requirements specify more than one request, determine if it can or should be broken
down further. A specification in a requirement should not be coupled with unlike requests. For
instance, asking for an online submission form while requesting internet protocol (IP) security
controls may involve very separate disciplines (and costs). Focus on the area of business need,
which will become more important later when organizing requirements into logical groups.
Determine if the requirement states environmental or temporary conditions that may not affect
or be pertinent to the request. For example, “The department needs to enable engineers to
assess levy satellite imagery during a category 4 storm, in real-time.” A web programmer
probably isn’t going to write code for a service that only works well during poor weather. They
may provide safeguards to make sure the service performs under extreme conditions, but the
real requirement is simply to state the criticality of the need for the service or the minimum
expectations of the service. An improvement might be, “Engineers must have access to at least
three different weather satellite feeds.”
3.4 Requirement Traceability
During requirements development, it becomes increasingly important, if not critical or mandatory, to
keep track of changes to the original requirements. Generally this is referred to as “traceability” of the
requirements. Determine responsibility level needed and assign staff to maintain accurate requirement
traceability information. Use of tracked changes can be very helpful but if the requirements will go
through multiple iterations, filters, approvers and reviewers, then tracked changes documents can
become nearly impossible to manage. Refer to SIMM Section 170B Project Requirements
Development Instructions for additional assistance applying requirements traceability.
Though some requirement statements appear to be clear, under further scrutiny it may become obvious
that more information is needed to describe what is being requested. Review requirements as if being
asked of someone who has no prior knowledge of the business. For instance, would someone who’s
never submitted a form online understand what a “web submission” is? There is a point where a
requirement can be further defined; however, at times a specific term may be accepted to explain the
requirement. Avoid making assumptions, even the word “form” should face scrutiny as to whether it
should be further defined. When a term looks as if it could be up for interpretation, it’s best to define it in
a glossary or elsewhere as appropriate.
Various methods are used for requirements traceability. Some projects use tracked changes cyclically
until some point in time, accept all changes (with the stakeholder’s and working group’s approval), and
then start over with fresh tracked changes. Other projects with a large number of requirements, or that
have a large number of stakeholders to review requirements, may use a requirements development
tool. These tools can be costly, but when the cost of the project is in the millions of dollars, the expense
may be feasible for achieving project success.
California Department of Technology 17
SIMM Section 170A
General Requirements Guidelines August 2016
Many mid-sized to smaller projects will be successful using basic tools like MS Excel or Word to
manage requirements. Choosing an enterprise requirements tool to manage a small project may be too
burdensome and have too steep of a learning curve. Select the right tool for the right requirements task.
Whichever method is selected, the goal should be to manage the requirement changes with accuracy
and efficiency, while providing everyone involved the chance to participate in or be advised of the
changes.
Requirements tracking may also provide an opportunity to perform initial cleanup of out-of-scope, out-
of-budget, and time consuming requirements. For example, asking for super-cooled, gold plated mouse
pads may improve staff’s work performance, however, if it’s unrealistic for the project, it may be
removed or be reduced to asking for BPA-free, ergonomic mouse pads.
Refer to SIMM 170B Project Requirements Development Instructions for additional step-by-step
requirements development information and details as they relate to the PAL process.