Discover millions of ebooks, audiobooks, and so much more with a free trial

Only $11.99/month after trial. Cancel anytime.

System Verification: Proving the Design Solution Satisfies the Requirements
System Verification: Proving the Design Solution Satisfies the Requirements
System Verification: Proving the Design Solution Satisfies the Requirements
Ebook660 pages7 hours

System Verification: Proving the Design Solution Satisfies the Requirements

Rating: 1 out of 5 stars

1/5

()

Read preview

About this ebook

System Verification: Proving the Design Solution Satisfies the Requirements, Second Edition explains how to determine what verification work must be done, how the total task can be broken down into verification tasks involving six straightforward methods, how to prepare a plan, procedure, and report for each of these tasks, and how to conduct an audit of the content of those reports for a particular product entity.

This process-centered book is applicable to engineering and computing projects of all kinds, and the lifecycle approach helps all stakeholders in the design process understand how the verification and validation stage is significant to them. In addition to many flowcharts that illustrate the verification procedures involved, the book also includes 14 verification form templates for use in practice.

The author draws on his experience of consulting for industry as well as lecturing to provide a uniquely practical and easy to use guide which is essential reading for systems and validation engineers, as well as everyone involved in the product design process.

  • Includes 14 real life templates for use in verification tasks
  • Explains concepts in the context of the entire design lifecycle, helping all project stakeholders engage
  • Contains a process-focused approach to design model verification that can be applied to all engineering design and software development projects
LanguageEnglish
Release dateMay 7, 2016
ISBN9780128042229
System Verification: Proving the Design Solution Satisfies the Requirements
Author

Jeffrey O. Grady

Jeffrey O. Grady is the Owner of JOG System Engineering, a consulting and teaching company, and an Adjunct Professor at the University of California, San Diego. He was formerly the manager of systems development at GD Space Systems. He is the author of ten books in the systems engineering field. Jeff is an INCOSE Fellow, Founder, and ESEP. Jeff worked as an employee for Librascope, Ryan Aeronautical, General Dynamics Convair, and General Dynamics Space Systems. He has consulted in systems engineering for many companies, developing military and commercial products. He has taught hundreds of system engineering courses for universities, short course companies and for his own company.

Related to System Verification

Related ebooks

Security For You

View More

Related articles

Related categories

Reviews for System Verification

Rating: 1 out of 5 stars
1/5

2 ratings0 reviews

What did you think?

Tap to rate

Review must be at least 10 words

    Book preview

    System Verification - Jeffrey O. Grady

    management.

    Chapter 1

    Setting the Stage

    Abstract

    Chapter 1 provides an introduction to the subject of verification and the book.

    Keywords

    Compliance; Department of Defense Architecture Framework; Matrix Management; Ministry of Defence Architecture Framework; Principal Engineer; Program Classes; Specialist; Specification; System; System Architecture Models; System Development; System Engineer; Universal Architecture Description Framework; Validation; Verification; Verification Classes; Verification Levels; Verification Methods

    1.1 The Enduring Truth That Need Not Be

    It is a sad truth that many system development programs fail to deliver a system to the customer with understandable evidence of system compliance with the content of program specifications. In order to be successful in doing so, the developer must begin early in the program to develop a good set of specifications in which the content has been derived through the application of an effective modeling method accomplished by people who know what they are doing. Then, the content of the specifications must be applied as the basis for design of the product. This same content of the specifications must also be used as the basis for the design of a verification process that produces evidence in a comprehensive series of verification task reports from which any reader will reach the same understanding of the degree of requirements compliance achieved. This is the third book on this subject the author has had published and it is the first time he has included the details about how to accomplish verification successfully and affordably, based on some recent program experiences in which a correction for the sad story became obvious to him but was not possible to achieve, because the driving specifications were not well-crafted by the customer and contractor and the remaining program budget, schedule, and customer goodwill were in insufficient supply to support correction of past errors. It should be said, however, that despite this past history the product system delivered was superb. The point of this book is that it is possible to deliver both a great product along with understandable verification evidence that truthfully reveals that the delivered product complies with the content of the program specifications.

    The road to success is simple but it appears not to be easy to accomplish. In this book we will identify a simple prescription that any program can follow to succeed in system verification, but you must begin the prescription fairly early in the program and management must follow the plan through with determination and management skill.

    1.2 Overview of This Chapter

    This chapter collects in Section 1.3 general information about verification, intended to prepare the reader with background information that it is hoped will help the reader place the information provided in the other chapters in context. Section 1.4 continues the overview of the remaining chapters of the book.

    We begin the introductory ideas in Section 1.3.1.1 with some fundamentals about the verification process definition, scope, and goals. In Section 1.3.1.2 we identify the customer relationship and the important role it plays in the verification process whether the sale is through a contract or a commercial sale. In Section 1.3.1.3 we emphasize the importance the words truth and integrity play in the verification process.

    Section 1.3.1.4 correlates specific sets of specifications with particular verification classes and provides a checklist of specific actions that are necessary related to these specifications and classes. Section 1.3.1.5 discusses the partitioning of classes into product entities that focus our verification work, which is further partitioned into tasks of six kinds.

    In Section 1.3.1.6 the meanings of two important words starting with the letter v are covered as these words are used in the book. Finally, a foundation of systems engineering is provided based on the limited capacity of the individual human mind relative to the amount of information that mankind has accumulated. This will lead to the importance of human communication to link the minds of several (maybe hundreds of) human beings who have each focused their knowledge capacity on a narrow field deeply. It will also show the need for people called system engineers. The management challenge is to form the equivalent of one great mind that has the capability to solve problems that no single person can possibly deal with successfully. Hopefully, this discussion will reveal to the reader why management is the most difficult task on a program and why all of us who are managed should do our best to support managers trying to do their best in a very difficult activity.

    Section 1.3.1.7 offers ideas about attaching responsibility for the verification work to program personnel. This can be a complicated relationship on a program but the fundamentals are that one person should be identified as responsible for every verification task and these tasks should be managed through a well-defined management structure. A particular structure is offered but there are many reasonable ways to set this up on a program. Section 1.3.1.8 notes a need to assemble all of the parts of the verification process into an overall program plan that is further discussed in detail in Chapter 6.

    Section 1.3.2 defines a system and provides an overview of the systems development process focused on the three fundamental phases of a program: (1) define the problem in a set of specifications; (2) solve the problem through synthesis of the requirements contained in the specifications in the three steps of design, procurement, and manufacture; and (3) determine the extent to which the resulting product complies with the content of the specifications. This book focuses on the third phase, verification. A fourth important area of interest is to provide good management across the complete program and within the enterprise across its active programs. The case is made for an enterprise possessing a single common process applied to all programs and covers four development environments within which an enterprise can apply this common process on programs: (1) waterfall, (2) V, (3) spiral, and (4) agile. In all cases the three-step development focus overlaid by good management is applied, being completed in the verification phase that actually extends throughout production, however long that may last. A program can continue far beyond its initial production phase of course, as in the case of the Boeing B-52 program, and very often parts of the four verification phases may have to be implemented relative to major modifications.

    Section 1.3.2 also summarizes the work that should precede the synthesis and verification work to prepare a set of specifications deriving the content of those specifications through the application of a comprehensive modeling approach that the enterprise has prepared its engineers to employ. Four universal architecture description frameworks (UADF) are offered from which an enterprise can select to be applied on every program, no matter how it is determined that the problem should be solved through a design implemented in some combination of hardware, software, and people doing things. The reader is encouraged to consult the author’s book titled System Requirements Analysis, Elsevier, 2014 for full details on the methods summarized in this section.

    Section 1.3.3 provides a description of the author’s preferred organizational structure that is assumed throughout the book, involving a matrix management structure. In this structure a set of functional departments, each specializing in a particular discipline, provides programs with the resources they need to accomplish planned work. The program organizational structures, each under a program manager, then organize these resources into cross-functional teams oriented around the product entities the program system will require.

    Section 1.3.4 covers program phasing possibilities, describing three specific phasing concepts. The application of these phasing approaches tends to be fairly rigid in practice, and on some programs where it is very difficult to define the requirements comprehensively in a timely way program managers have applied what is called rapid prototyping or agile development in an attempt to speed up the process and avoid late recognition of serious problems, in some cases with success. Finally, the section covers three different program cases in terms of the number of systems delivered.

    1.3 Introductory Ideas Included in Chapter 1

    This section offers important introductory ideas referred to in the preceding paragraphs, while Section 1.4 provides an overview of the other chapters of the book.

    1.3.1 Our Verification Objective

    1.3.1.1 What Is Important?

    This book is titled System Verification. Therefore, the reader would expect that it concerns establishing the truth or correctness of a proposition and that expectation will be fulfilled. But what do we seek to verify and how shall we go about it? The assertion we will deal with is primarily of the kind, product entity X complies with content Y of document Z where: (1) the entity X is a product design and/or manufacture for a system or part thereof; (2) content Y may be restricted to a paragraph, a collection of paragraphs, or the content of a complete specification; (3) the document in question Y is a specification for that entity; and (4) compliance means that the design and/or manufacture of the entity is in complete agreement with the content of the document, often phrased as being in compliance with that content.

    We should recognize that a product entity has many representations including the physical entity itself, a collection of engineering drawings and corresponding parts lists, a collection of analysis and test reports, a specification, procurement documentation, and manufacturing documentation. It is insufficient to be able only to say that the physical product complies with the specification content. We need all of the representations to also agree one with the other but we focus most of the energy of verification on the physical product entity that will be delivered relative to the content of its specification on the theory that any noncompliance contained in the supporting documentation should result in a failure of the product to successfully complete verification. It would still be possible, of course, that one error in supporting documentation in combination with an error in verification planning could produce an inappropriate compliance conclusion, but that occurrence would have a low probability.

    Verification occurs in the systems development process at the tail end of a trio of processes begun by requirements and synthesis. In the systems development process we first must determine what the system will consist of in terms of product entities and relationships between them through a process some, including the author, like to refer to as architecture and requirements engineering, concluding with what the essential characteristics of all of those entities must be. We must then accomplish synthesis of the requirements for any of those entities to create a physical reality representing the product entity through design, acquisition or procurement of the resources needed to produce or manufacture the entity using those resources. The apparatus within which the manufacturing work takes place can be as complicated as the product entity being manufactured (or more so) and may require the same development process that is applied to the product design – an automobile or commercial aircraft final assembly plant are two cases in point.

    The product entity in question may be software, instructions for human beings to perform in a prescribed fashion toward a particular end, or a hardware product. In some cases it will be possible to reach a proper conclusion about compliance without possessing an example of the product entity, but in most cases we will find it necessary to inspect an article of the product entity in some detail. The word inspection in this case is commonly applied as embracing five different methods: (1) analysis of representations of the product entity such as drawings or data; (2) test of the product entity using special test equipment; (3) examination of the product entity using human senses and simple devices; (4) demonstration; and (5) special, which is reserved in this book to apply to the use of modeling and simulation. We will tag on a none method, meaning that no verification is necessary. This method is appropriate in the case where a paragraph in a specification includes no requirement. An organizing title-only paragraph is an example of the latter. In all cases these methods are applied with the expectation that the product entity can accomplish some particular activity under specific conditions and within a specific time frame.

    For a product entity that follows this path through a well-managed system development process staged by a program operating within an enterprise in accordance with a well-designed plan, we may say that the development for that entity has been successful and articles of that product entity can be delivered to a customer where they are operated and maintained in accordance with instructions agreed upon between developer and customer. The word customer used in this book may include a pair of organizations in cases where one agency of the customer’s organization acquires the system under a contract between that acquisition agent and the developing enterprise and another uses it during its life cycle. Most systems developed for the U.S. Department of Defense are examples.

    The important distinction for the reader to take away from this discussion is the need to preserve full life expectancy for every manufactured article delivered to the customer while ensuring that each will satisfy the requirements in the related specifications.

    1.3.1.2 Customer Relationship

    It is possible to partition most system development situations into: (1) those that take place in accordance with a contract between a customer and a developer where the developing enterprise delivers the system in accordance with the contract; and (2) those that take place within an enterprise for commercial sale to a customer base either through direct sale or some form of retail distribution. In either case the developer should seek to verify that the product entities delivered comply with the requirements defined as a precursor to design. In the first case, it may be a part of the contract that the developer must supply the customer with verification reports. In the second case, access to the requirements respected and proof of requirements compliance are not commonly consciously expected by the customers but, in the author’s view, a developer with integrity would include verification cost and schedule impact in the development of its

    Enjoying the preview?
    Page 1 of 1