摘要:

AbstractRisk management and cost of quality are two management methodologies that are receiving increasing attention from organizations concerned with the management of large, complex design, development, manufacturing, and operational programs. Typically these two methodologies are treated as separate functions and are executed independently of each other. In fact, cost of quality determines information critical in identifying and assessing risks in a program, and risk management provides procedures for monitoring and mitigating the risks that are identified with that information. Program management will be enhanced by the coordinated application of cost of quality and risk management. Clear program management responsibilities among the system engineer, program control manager, and program manager ensure effective, coordinated application of the two methodologies.

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1994.tb01674.x

年代:1994

数据来源: WILEY

摘要:

AbstractThis paper describes a risk management program that Computer Sciences Corporation (CSC) developed for a NASA Goddard Space Flight Center (GSFC) task‐order contract. The program uses a closed‐loop risk management process, supported by a spreadsheet‐based tool to standardize the information that task managers must enter and to facilitate risk impact calculations. The paper addresses the challenges of developing and deploying a risk management program for a diverse task‐order contract. The paper also describes process improvement actions taken to maximize program acceptance among CSC task m

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1994.tb01675.x

年代:1994

数据来源: WILEY

摘要:

AbstractRisk management is a hot topic that most Systems Engineers consider important, however, many differ in the strategy of implementation. Most Systems Engineers use different ad hoc methods, based on their own experience, along with structured methodologies to implement risk management This paper describes a general structure for risk management in a development environment. The paper also describes the implementation of this general risk management plan for a specific development project extended over two years. The paper presents the lessons learned on doing risk management for this project along with a strategy for implementing risk management on future problems.

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1994.tb01676.x

年代:1994

数据来源: WILEY

摘要:

AbstractThis paper documents an effective, formal risk management process that is based on cost impact. The process is used in current programs. Key to the process is the objective ranking of risks based on more detailed subjective identification of cost impact. Higher‐ranking risks have mitigation action plans, receive emphasis at monthly reviews, and are tracked in a planned manner. Lower‐ranking risks stay on the overall list for later evaluation without expending inordinate time and effort. The paper provides the process, methods to identify risks, methods to assess the risks, and methods to review and track the ri

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1994.tb01677.x

年代:1994

数据来源: WILEY

摘要:

AbstractA proper Systems Engineering approach to aircraft requirements allocation demands that upper‐level performance requirements be flowed down and allocated to lower‐level subfunctions in a logical, traceable, structured process. Normally it is not in the customer's best interest to contractually specify suballocated values developed from the top requirement because such action borders on dictating hardware design solutions instead of focusing on communicating customer overall needs to the contractor. Because of this, the requirement flowdown process appears to offer opportunities for multiple feasible solutions which are all capable of meeting the customers top level requirement. Thus, there is need for a systems engineering process which is capable of identifying a “best choice” among these selections. At McDonnell Douglas, a creative approach to resolve this requirements flowdown issue has been developed. The approach provides guid‐ance identifying and rank ordering preferred design choices, developing requirements flowdown, and documenting rationale behind identification and selection of optimal choices. The process focuses on a guidance philosophy which identifies customer needs using Quality Function Deployment assessments in combination with linear optimization analyses to perform numerical suballocation of top requirements. The approach provides guidance towards solutions which protect the customer's interests without the need for the customer to dictate design solutions and contractual requirements at these suballocated levels of detail. An application of this process to the diagnostic requirements area has been packaged by McDonnell Douglas as a single integrated set of software modules which fit on a floppy disk capable of operating on a d

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1994.tb01678.x

年代:1994

数据来源: WILEY

摘要:

AbstractThis paper (1) describes what the current literature identifies as qualities of good software requirements, (2) identifies and examines different categories of software requirement methods, and (3) concludes that methods used to develop software requirements, though not perfect, have advantages that can improve the development of requirements for any type of system. Twelve requirement qualities were identified from the literature and these were used to establish evaluation criteria for software requirement development methods. Three methods selected for evaluation were the Hatley‐Pirbhai method (1988), the CoRE (Consortium Requirements Engineering, SPC, 1992), and Requirements State Machine Language (RSML) develop by Leveson (1990). None of these method stands out as being superior and each have strengths and weaknesses depending upon the application, but each offers improvements over the text based methods used in traditional systems engineering efforts to create function/requirement set

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1994.tb01679.x

年代:1994

数据来源: WILEY

摘要:

AbstractThis paper presents specific recommendations that have been found effective within IBM (now Loral) Federal Systems for teaching the process of generating operations‐based requirements. Specific recommendations include:Base the workshop on a holistic, flexible processBase exercises on a problem the students can relate to as a userEnsure the students understand the needs the entity addresses before allowing them to begin requirements analysisHave all exercises involve teamsHave at least two exercises using each critical method or technique covered in the workshopHave multiple teams work the same problemConstruct class requirements definition examples such that there is at least one with a clearly superior resolution, and one with number of nearly equivalent “okay” resol

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1994.tb01680.x

年代:1994

数据来源: WILEY

摘要:

AbstractImproved requirements traceability would result in significant cost savings since more requirements problems are due to failures in requirements management than failures in technical functions. Without adequate requirements traceability, errors are found late in system development and are expensive to repair.Our research identifies problems with industry's capability to trace product and process information, and offers some solutions1. We have defined a unique method, Concurrent Stimulus‐Response Threads (CSRT), that traces complex system behavior. Based on CSRT and Entity‐Relationship modeling, we make recommendations that will improve traceability in two requirements methods, Requirements Driven Design (RDD), and Real‐Time Structured Analysis (R

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1994.tb01681.x

年代:1994

数据来源: WILEY

摘要:

AbstractEvery customer wants good requirements traceability when they start a new program. They want to ensure their contractor provide “tops down” traceability when deriving lower‐level requirements to ensure the original customer requirements are met thus avoid what is commonly called “requirements creep”. However, most customers are soon disappointed about the methodology their contractors use when trying to actually implement requirements traceability. After a while most contractors persuade their customers to relax their expectations and finally drop the requirements traceability task and say “Let's just design and build it, we're just wasting time.”This paper will present a “how‐to‐do” requirements traceability more efficiently as well as “how‐to‐use” the information more effectively once you've done all that work. Topics include customer requirements traceability; derived requirements traceability; requirements allocation traceability; design compliance traceability; verification traceability; product sell‐off traceability; and operational lessons learned traceability. Real experience and lessons learned from many programs are revealed to help avoid some of the pitfalls and provide more efficient methods for performing these tasks. A generic, multi‐user requirements traceability database is discussed to describe how to automate the requirements traceability p

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1994.tb01682.x

年代:1994

数据来源: WILEY

摘要:

AbstractThe integration of systems to create a stable, robustsystem of systemsposes challenges to systems engineering management when the individual systems already exist, are numerous and rapidly evolving. The Dynamic Object Oriented Requirements System (DOORSTM) introduces advanced object‐oriented techniques to manage the complexity of large numbers of inter‐linked requirements. DOORS provides an easy‐to‐use, online environment. Different on‐line views of the project status are available in both text and hierarchical graphical formats by filtering and sorting on the attributes of the objects. This object‐oriented approach to requirements management is extended to provide agroupwaresystems engineering management environment in support of the U.S. Army's program todigitizethe battlefield of the future. The Army's intent is to improve their comparative advantage in combat effectiveness over that of potential adversaries. The magnitude and complexity of the effort to manage the project compared to classical requirements management methodologies and tools ar

ISSN:2334-5837    

DOI:10.1002/j.2334-5837.1994.tb01683.x

年代:1994

数据来源: WILEY