Looking for a California Legal Forms And Templates? Download it for free!

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

SIMM Section 170A

General Requirements Guidelines

July 2016

General Requirements Guidelines - Simm Section 170a - California Department Of Technology Page 17

Related Articles

Related forms

Related Categories