If you think about it, there are numerous examples in our professional and private lives where the lack of communication or unclear terminology has created misunderstandings, problems and a myriad of other issues. As in any worthwhile pursuit, effective communication is critical in the cost-effective and efficient interactions between various parties seeking a mutually beneficial relationship or partnership. At every step of product development, it is critical to understand and meet user needs. The Commercialization Office has created a Product Realization Chart that is a useful
guide that shows the due diligence necessary for the productive development of products or services (See Appendix H).
Product development is not a trivial effort; but with proper planning, tracking and communication, successful product development can yield measurable positive results and provide DHS operating components with resources necessary to carry out their mission-critical objectives to protect our country. The initial phase of product realization is a mission needs assessment. This assessment should be conducted relative to the overall mission for a given organization.
This exercise identifies capabilities needed to perform required functions, highlights deficiencies in a functional capability and documents the results of the analysis. Some of these capabilities may already be addressed with existing products, systems or services currently accessible by an organization.
Additionally, a mission needs assessment serves
to identify deficiencies in current and projected capabilities. In the event that current products are not able to address a particular capability; a capability gap exists. Briefly, capability gaps are defined by the difference between current operational capabilities and those necessary capabilities needed to perform mission-critical objectives that remain unsatisfied. Capability gaps must be listed in terms of an overall need to perform a specific task and should avoid explaining how that task should be achieved. See appendix G for further reading. For example, faced with the problem of potential intruders to a sensitive facility, we might define the requirement as “build a wall” whereas the real requirement is “detect, thwart, and capture intruders.” Our wall might “thwart” intruders (or might not, if they’re
adept at tunneling), but it would not detect them or facilitate their capture. In short, the solution would not solve the problem.
Replaced/Superseded by document(s)
The purpose of this guide is simple and straightforward: to enable the reader to
articulate detailed requirements or needs and effectively communicate them (either
internally within DHS or externally to other Federal agencies or the private sector)
through an Operational Requirements Document (ORD) vehicle. Often, we have heard
expressions like “It all boils down to a lack of communications,” or “We’re not sure what
you need,” or “DHS has been difficult to work with because they really don’t have a clear
picture of their problems, needs or requirements.” We can remedy this situation by
implementing some fundamental practices in a disciplined manner.
A well-written ORD can be an effective vehicle or tool to relay the needs of a given
component, group or agency in an easily understood format to sedulously avoid the
countless hours of time and other resources wasted speculating needs. Research
conclusively shows that the foremost reason why programs or projects do not succeed is
due to the lack of detailed requirements at the initiation of a program or project. Efforts
invested up front to develop a clear understanding of the requirements pay dividends in
the positive outcome of programs -- not to mention the savings in both time and money in
corrective actions taken to get a program back on track (if it is even possible!).
We intend to make writing an ORD simple and easy. To that end, we have provided
in this book an easy-to-follow ORD template, along with several real world examples of
ORDs. In the numerous appendixes accompanying this book, you will find articles and
briefings that provide additional context to the role that creating detailed operational
requirements play in effective product realization. For your convenience, we have also
included Appendix J, which contains the original Requirements Development Guide
(April 2008) for those interested in a more detailed discussion on requirements
development and product development life cycles.