Welcome to our new site version. Your web page bookmarks may have changed, please search for pages by title to update them. Having problems ? Please try clearing your web browser cache and hard-reloading your web page first before contacting our webmaster.

BEST PRACTICES IN USER NEEDS/REQUIREMENTS GENERATION

[document] Submitted on 11 September, 2019 - 19:10
Keywords SYSTEMS IN THE US AIR FORCE BEST PRACTICES IN USER NEEDS/REQUIREMENTS GENERATION Research Assistant Center for Innovation in Product Development
Standards groups

The commercial world has by practice refrained from entering into new development projects without understanding the ramifications of such an action. Most companies present the pros and cons of any new venture in some kind of formal document and use it to base their decision. This formal document is known as a ‘business case’. It clearly states the ‘case’ for the ‘business’ of the new venture. Obviously, these business cases do not appear magically. They take time to develop and yet, not too much time that would give a competitor the upper hand. They must be done correctly too, as some companies ‘bet the business’ on new product decisions. In product development “the front end
is inherently fuzzy because it is a crossroads where complex information processing, a broad range of tacit knowledge, conflicting organizational pressures including cross-functional inputs, considerable uncertainty, and high stakes must meet" (Khurana and Rosenthal 1998, pg.72). For the United States
Military, the front-end consists of the initial processes leading towards the development of programs and systems.

The description of this pre-activity in the commercial world is known as the “fuzzy-front end” of product development. In the military, three separate processes participate in the “fuzzy front-end” of the development of a weapon system. These are known as the Programming, Planning, and Budgeting
System (PPBS), the Requirements Generation System (RGS) and the Acquisition System. Each of the services designates particular portions of these processes by different names. The degree of formality and complexity among the services’ portions also vary.

Metadata
Date published
2000-02
Document type
technical white paper
Pages
299
Replaced/Superseded by document(s)
Cancelled by
Amended by
File MIME type Size (KB) Language Download
TH_Wirthlin.pdf application/pdf   1.45 MB English DOWNLOAD!
File attachments
Organisation(s)
Defines standard
Visit also