System Analysis, Design, and Development Concepts, Principles, and Practices phần 5 pot

Author’s Note 29.2 The hierarchy shown is best described as ideal—meaning all requirements are properly aligned to higher level requirements. For discussion purposes, we will restrict the sim- plicity of this diagram to generic requirements. Requirements are derived from and must be trace- able to measures of effectiveness (MOEs), measures of suitability (MOSs), and measures of performance (MOPs) at the system and mission levels. Referral For more information about MOEs, MOS, and MOPs, refer to the Operational Utility, Suitability, and Effectiveness Practices discussion in Chapter 34. The SYSTEM’s mission represents the highest level requirement in Figure 29.2. The mission is scoped, bounded, and described by three high-level capability requirements, R1, R2, and R3. When a single requirement, such as R12, R32, and R33, effectively ends the chain, the term “leaf” require- ment is sometimes used. Guidepost 24.1 From this basic understanding of a theoretical capability requirement hierar- chy we are now ready to investigate common problems with specification requirements. 29.7 COMMON PROBLEMS WITH SPECIFICATION REQUIREMENTS Specifications often have imperfections and are unintentionally released with a number of errors, defects, and deficiencies. To illustrate these conditions, let’s identify a series of undesirable condi- tions that commonly plague specifications. We noted earlier that some people develop specifications as random sets of thoughts or wish lists organized to a standard outline structure. Specifications of this type typically evolve from infor- mal to formal brainstorming sessions. Requirements captured during the session are published for review. During the session reviewers lobby other reviewers to support additions of their respective desires to the structure. 29.7 Common Problems with Specification Requirements 323 System Mission R2R1 R3 R12R11 R112R111 R132R131 R133 R1121 R312 R313 R332 R333 R32R31 R33R21 R1122 R1321 R3121 R3122 R3322 R13212 R31222R31221 R31223 R13211 R311 R311 R13213 R13213 R2 2 R22 = Misplaced Requirements R## R## = Missing Requirements R## = Conflicting Requirements R113 R113 R132 2 R1322 R1 3 R13 R331 R331 R332 1 R3321 Figure 29.2 Requirements Hierarchy Tree Illustrating Conflicting Requirements Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Author’s Note 29.3 Requirements should NOT be added to a specification unless budgetary resources are provided. Remember, each requirement costs money to implement—be it hardware or software. At the SPS level, requirements changes should be managed as contract modifications. Within the System Developer’s organization, any additional requirements should include com- mensurate cost and schedule modification considerations. If you analyze specification work products, you will discover they typically exhibit at least four major types of problems: Problem 1: Missing capability requirements Problem 2: Misplaced capability requirements Problem 3: Conflicting specification requirements Problem 4: Duplicated requirements Figure 29.2 illustrates these conditions that often result in errors, defects, and deficiencies. These four conditions exemplify a few of the common problems specification analysts and SEs encounter. This further illustrates two key points: • WHY it is important to formally train SEs, specification requirements analysts, and stake- holders in HOW to analyze, prepare, and review the specifications before you contractually commit to their implementation. • WHY it is important to conduct specification reviews with all stakeholders. People who casu- ally read specifications in a linear “front to back” or sectional manner for proper grammar and text usage typically overlook or fail to assimilate and recognize these conditions. 29.8 GUIDING PRINCIPLES In summary, our discussions in this section provide the basis with which to establish the several guiding principles that govern specification requirements practices. Principle 29.1 Every specification must specify requirements that address four types of system conditions: 1. Normal operations 2. External system failures 3. Degraded operations 4. Internal system failures 29.9 SUMMARY Our discussion of specification requirements provided an introduction into the types of requirements contained within specifications statements. Later, chapters will use this foundation to determine the requirements for internally developed configuration items (CIs) or the procurement of nondevelopmental items (NDIs) from external vendors. 324 Chapter 29 Understanding Specification Requirements Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com GENERAL EXERCISES 1. Answer each of the What You Should Learn from This Chapter questions identified in the Introduction. 2. Refer to the list of systems identified in Chapter 2. Based on a selection from the preceding chapter’s General Exercises or a new system selection, apply your knowledge derived from this chapter’s topical discussions. Identify and describe the four types operations—NORMAL, ABNORMAL, EMERGENCY, and CATASTROPHIC, as applicable—that apply to the selected system. ORGANIZATION CENTRIC EXERCISES 1. Contact several contract programs within your organization. Request an opportunity to analyze the System Performance Specification (SPS) for each program and answer the following questions: (a) Identify five examples of operational requirements. (b) Identify five examples of capability requirements. (c) Identify five examples of nonfunctional requirements (d) Identify five different examples of verification requirements. (e) Identify five examples of design and construction constraints. (f) Are threshold and objective requirements identified? 2. Interview program technical management and SEs. How were requirements in the System Performance Specification (SPS) elicited and collected from stakeholders? Document your findings and observations? 3. What lessons learned did program personnel learn in the following areas and how did they resolve the issue? (a) Missing requirements (b) Misplaced requirements (c) Conflicting requirements (d) Duplicated requirements (e) Nonfunctional requirements (f) Verification requirements 4. What types of metrics are used to track specification defects and deficiencies? 5. Select a specification on a contract program for analysis. Using the concepts discussed in this chapter, as a consultant to the specification developer, identify defects and deficiencies in the specification and suggest recommendations for improvement. 6. Research contract specifications and identify those that specify the precedence of requirements for deci- sion making. 7. For a contract program, identify who the SPS stakeholders are based on the specified requirements. Based on those stakeholders, prioritize them in terms of an estimate based on requirements count. REFERENCES References 325 DoD 5000.2R (Interim Regulation). 2000. Mandatory Procedures for Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) Acquisition Programs. Washington, DC: Depart- ment of Defense (DoD). Kossiakoff, Alexander, and Sweet, William N. 2003. Systems Engineering Principles and Practice. New York: Wiley-InterScience. SD-15. 1995. Performance Specification Guide. Washington, DC: Department of Defense (DoD). Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 326 Chapter 29 Understanding Specification Requirements IEEE Std 610.12-1990. 1990. IEEE Standard Glossary of Modeling and Simulation Terminology. Institute of Electrical and Electronic Engineers (IEEE). New York, NY. Defense Systems Management College (DSMC). 2001. Glossary: Defense Acquisition Acronyms and Terms, 10th ed. Defense Acquisition University Press. FT, BELVOIR, VA ADDITIONAL READING Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Chapter 30 Specification Analysis 30.1 INTRODUCTION When systems, products, and services are acquired, the Acquirer typically provides a System Requirements Document (SRD) or Statement of Objectives (SOO) with the formal Request for Pro- posal (RFP) solicitation. The SRD/SOO expresses the required set of capabilities and performance Offerors use as the basis to submit solution-based proposals. The challenge for Acquirers and System Developers is to formulate, derive, and negotiate a System Performance Specification (SPS) that: 1. Concisely and completely bounds the solution space. 2. Is well understood by all stakeholders. 3. Establishes the basis for deliverable system, product, or service technical acceptance. Our discussion in this chapter describes various Specification Analysis Practices. We explore various methods and techniques used to analyze specification requirements for completeness from several perspectives. We introduce common specification practice deficiencies and investigate methods for identifying, tracking, and resolving these deficiencies. We also consider semantic ambi- guities such as comply versus conform versus meet that Acquirers and System Developers employ that do have significance in interpretation. What You Should Learn from This Chapter 1. How do you methodically analyze a specification? 2. What are some common types of specification requirements deficiencies? 3. When requirements deficiencies are identified, how should you resolve them? 4. What does it mean to comply with a requirement? 5. What does it mean to conform to a requirement? 6. What does it mean to meet a requirement? 30.2 ANALYZING EXISTING SPECIFICATIONS Our previous discussion focused on HOW an Acquirer might develop their procurement System Requirements Document (SRD) or the System Developer might developer lower level item devel- opment specifications. However, WHAT if a specification already exists? HOW does the Acquirer System Analysis, Design, and Development, by Charles S. Wasson Copyright © 2006 by John Wiley & Sons, Inc. 327 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com or a System Developer candidate analyze the specification for completeness, reasonableness, and feasibility? There are two key contexts regarding analysis of specifications: 1. Acquirer verification PRIOR TO formal solicitation. 2. System Developer analysis during the proposal process and following Contract Award (CA). Let’s investigate these contexts further. Acquirer Perspective Acquirers start by reducing the risk of the procurement action. How can this be accomplished? It is by releasing a high-quality draft specification that accurately, precisely, and completely speci- fies and bounds the solution space system, product, or service. Before release, the Acquirer must thoroughly review the specification for accuracy, completeness, specificity, and legal purposes. Key review questions to ask might include: 1. Have all User System Deployment Phase, System Operations and Support (O&S) Phase, and System Disposal Phase stakeholder requirements been adequately identified, priori- tized, scoped, and specified? 2. Have we bounded the CORRECT solution space within the problem space? 3. Have we identified the RIGHT system to fill the prescribed solution space and cope with OPERATING ENVIRONMENT? 4. Does this specification adequately, accurately, and precisely specify the selected solution space? 5. If we procure a system based on these requirements, will the deliverable product satisfy the User’s intended operational needs? 6. Can the system specified be developed within the total life cycle cost—such as acquisition, operations and support (O&S), and retirement costs—budgets that are available? What happens if you inadequately address these and other questions? Later, if it is determined that the requirements have latent defects such as errors, deficiencies, or omissions, the cost to modify the contract can be very expensive. To minimize specification risk, Acquirers often release a pre- solicitation draft specification for qualified candidate Offeror comments. System Developer Perspective In contrast, the System Developer must reduce contract cost, schedule, and technical risk. To do this, specification analysis must answer many questions. Key review questions might include: 1. Do we fully understand the scope of the effort we are signing up to perform? 2. Do the system requirements, as stated, specify a system that satisfies the User’s operational needs? If not, what approach must we use to inform them? 3. Have we thoroughly investigated and talked with a representative cross section of the User community to validate their requirements and needs? 4. Do we understand the problem the User is attempting to solve by procuring this system? Does the specification bound the problem or a symption of the problem? 5. Can the requirements, as stated, be verified within reasonable expectations, cost, schedule, and risk? 6. Do these requirements mandate technologies that pose unacceptable risks? 328 Chapter 30 Specification Analysis Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 30.3 SPECIFICATION ANALYSIS Given the Acquirer and System Developer perspectives, HOW do they approach analysis of the specification? The answer encompasses the methods and techniques identified in earlier questions in Chapters 3 to 29. Due to the broad scope of this answer, we will briefly address some high level approaches you can apply to specification analysis. Visually “Inspect” the Specification Outline Examine the outline STRUCTURE for missing sections and topics that are crucial to developing a system of the type specified. Perform System Requirements Analysis (SRA) Perform a System Requirements Analysis (SRA) to understand WHAT the system is expected to do. Ask key questions such as: 1. Do the list of requirements appear to be generated as a feature-based “wish list” or reflect structured analysis? 2. Do the requirements follow standard guidelines discussed later in Requirements Statement Development Practices? 3. Do the requirements appear to have been written by a seasoned subject matter expert (SME) or semi-knowledgeable person? 4. Do the requirements adequately capture User operational needs? Are they necessary and sufficient? 5. Do the requirements unnecessarily CONSTRAIN the range of viable solutions? 6. Are all system interface requirements identified? 7. Are there any TBDs remaining in the specification? 8. Are there any critical operational or technical issues (COIs/CTIs) that require resolution or clarification? Perform Engineering Graphical Analysis 1. Based on the requirements, as stated, can we draw a simple graphic of the system and its interactions with its OPERATING ENVIRONMENT? 2. Are there any obvious “holes” in the graphic that are not specified as requirements in the specification? Hierarchical Analysis 1. Are there any misplaced, overlapping, duplicated, or conflicting requirements? 2. Are the requirements positioned and scoped at the right levels? 3. Are there any “holes” in the set of requirements? Technology Analysis Do the specification requirements indicate a willingness or unwillingness by the Acquirer to con- sider and accept new technologies or solutions? 30.3 Specification Analysis 329 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Competitive Analysis Do the specification requirements favor or target a competitor’s products, services, or organiza- tional capabilities? Modeling and Simulation Analysis If appropriate, is it worthwhile to develop models and simulations as decision aids to analyze system performance issues? Verifying Specification Requirements 1. Are there any requirements that are unreasonable, unverifiable, or cost prohibitive using the verification methods specified? 2. Does verification require any special test facilities, tools, equipment, or training? Validating Specification Requirements When SEs analyze specifications, especially those prepared by external organizations, most engi- neers presume the specification has been prepared by someone who: 1. Understands the User’s problem space and solution space(s). 2. Accurately analyzes, translates, and articulates the solution space into requirements that can be implemented economically with acceptable risk, and so forth. Exercise CAUTION with this mindset! AVOID assuming anything UNTIL you have VALI- DATED the specification requirements. 30.4 DEALING WITH CONTRACT SPECIFICATION DEFICIENCIES Human systems, even with the best of intentions, are not perfect. Inevitably, every contract System Performance Specification (SPS) has blemishes, degrees of goodness, strong and weak points. Although the degree of goodness has an academic connotation, “goodness” resides in the minds and perceptions of the Acquirer and System Developer. Remember, one person’s work of art may be viewed by another person as unorganized rambling. Discussions by both parties reach a point whereby willingness to entertain contract modifica- tion to eliminate specification blemishes or deficiencies are rejected. The Acquirer may want changes but is reluctant to request changes due to the System Developer taking advantage of the situation via cost changes. Conversely, the System Developer may WANT changes but the Acquirer is unwilling to allow any changes for FEAR of the unknown that may result from the changes. Even when both parties agree, there may be latent SPS deficiencies that lie dormant and go undiscovered until late in the System Development Phase of the contract. The best that can occur is for both parties to accom- modate each other’s wishes at no cost, assuming that is the appropriate and reasonable solution. Regardless of the scenario you may have a situation where the System Performance Specifi- cation (SPS) contains defects, deficiencies, or errors and the Acquirer refuses to modify the con- tract. What do you do? One solution is to create an electronic System Design Notebook (SDN); some people refer to this as a Design Rationale Document (DRD). Why do you need an SDN or DRD? You need a mech- anism to record design assumptions and rationale for requirements allocations and design criteria. 330 Chapter 30 Specification Analysis Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Under the Terms and Conditions (Ts&Cs) of the contract, the System Developer must perform to the SPS requirements that are flowed down to lower level development specifications. Therefore, lacking a definitive set of SPS requirements, you may want to consider an AT RISK solution that expresses your organization’s interpretation of the ambiguous requirements. A copy of the docu- ment should be provided through contracting protocol to the Acquirer’s Contracting Officer (ACO). Author’s Note 30.1 The point above highlights the need to THINK SMARTLY “up front” about requirements and AVOID this situation. You will find executives and impatient people who insist that you move on and not worry about interpretations. “Besides, it’s perfectly clear to me!” BEWARE! Any time investment and energy spent up front clarifying SPS requirements BEFORE they become contract obligations will be significantly less costly than after Contract Award. When you conduct the System Requirements Review (SRR), SPS defects and deficiencies should be addressed with the Acquirer. The requirements defects and deficiencies discussion and decisions should be recorded in the SRR meeting minutes. If the Acquirer refuses to allow corrections via contract modification, they may acknowledge via the Acquirer Contracting Officer (ACO) your chosen approach. Therefore, document your design assumptions and include open distribution or accessibility of that portion of the SDN to the Acquirer. Author’s Note 30.2 Every contract and situation is different and requires decision making on its own merits. Professionally and technically speaking, the Acquirer and System Developer should emerge from the SRR with no outstanding issues. The reality is: 1. The Acquirer may have to settle for a negotiated acceptance of the system AS IS with known deficiencies at system delivery. 2. The System Developer may be UNABLE to perform to the terms and conditions (Ts&Cs) of the contract. All stakeholders need to emerge from the contract as winners! Therefore, AVOID this problem and resolve it up front during the proposal phase or not later than the SRR and throughout the System Development Phase, as appropriate. 30.5 COMMON SPECIFICATION DEFICIENCIES If you analyze specification requirements practices in many organizations, there are a number of deficiencies that occur frequently. These include: Deficiency 1: Failure to follow a standard outline Deficiency 2: Specification reuse risks Deficiency 3: Lack of specification and requirements ownership Deficiency 4: Specifying broad references Deficiency 5: Reference versus applicable documents Deficiency 6: Usage of ambiguous terms Deficiency 7: Missing normal, degraded, and emergency scenario requirements Deficiency 8: Specification change management Deficiency 9: Over-underspecification of requirements Deficiency 10: References to unapproved specifications 30.5 Common Specification Deficiencies 331 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Deficiency 11: Failure to track specification changes and updates Deficiency 12: Failure to appropriate time for specification analysis Deficiency 13: Requirements applicability–configuration effectivity Deficiency 14: Dominating personality specification writers Deficiency 1: Failure to Follow a Standard Specification Outline Many specification issues are traceable to a lack of commitment to establish and employ standard specification development outlines and guidelines. Standard outlines represent organized lessons learned that reflect problem areas or issues that someone else has encountered and must be cor- rected in future efforts. Over time they incorporate a broad spectrum of topics that may or may not be applicable to all programs. The natural tendency of SEs is to delete nonapplicable sections of a standard specification outline. Additionally, management often dictates that specific topics are to be deleted because “We don’t want to bring it to someone’s attention that we are not going to perform (topic).” The reality is standard outlines include topics that are intended to keep you out of trouble! A cardinal rule of system specification practices requires you to provide rationale as to WHY a standard outline topic is not applicable to your program. The rationale communicates to the reader that you: 1. Considered the subject matter. 2. Determined the topic is not relevant to your system development effort for the stated rationale. Thus, if someone more knowledgeable determines later that “Yes, it is relevant,” you can correct the applicability statement. This is true for plans, specifications, and other types of technical decision-making documents. Problems arise when SEs purposefully delete sections from a standard outline. Once deleted, the section is “out of sight, out of mind.” Since contract success is dependent on delivering a prop- erly designed and developed SYSTEM on schedule and within budget, you are better off identify- ing a topical section as “Not Applicable.” Then, if others determine that it is applicable, at least you have some lead time to take corrective action BEFORE it is too late. If you follow this guideline and go into a System Requirements Review (SRR), any non- applicability issues can be addressed at that time. All parties emerge with a record of agreement via the conference minutes concerning the applicability issue. Author’s Note 30.3 Remember, the cost to correct specification errors and omissions require- ments increases almost exponentially with time after Contract Award. Deficiency 2: Specification Reuse Risks Some engineers pride themselves in being able to quickly “assemble a specification” by duplicat- ing legacy system specifications without due operational, mission, and system analysis. Guess what? Management takes great pride in the practice, as well. AHEAD of schedule, LIFE is ROSY! Later SEs discover that key requirements were overlooked or ignored, were not estimated, and have significant cost to implement. Guess what? Management is very unhappy! Where precedented systems exist and are used as the basis to create new specifications with only minor modifications, the practice of plagiarizing existing specifications may be acceptable. However, be cautious of the practice. Learn WHEN and HOW TO apply specification REUSE effectively. 332 Chapter 30 Specification Analysis Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com [...]... External System #2 System #2 Subsystem B Subsystem A Input #2 A1 A2 A3 A2 - B1 Out #1 B1 B1 - D1 External External System #5 System #5 Out #3 External External System #6 System #6 Subsystem D A4 - C2 D2 Subsystem C Input #3 External External System #3 System #3 Out #2 A4 External External System #4 System #4 B2 C1 C2 C2 - D1 D3 D1 D4 Input #4 C3 Figure 31.2 Architecture-Based Approach to Specification Development. .. Capabilities 3.2.1 Vehicle Frame System 3.2.2 Body System 3.2.3 Propulsion System 3.2.4 Fuel System 3.2 .5 Electrical System 3.2.6 Cooling System 3.2.7 Steering System 3.2.8 Entertainment System 3.2.9 Storage System, etc Implementing the Model–Based Analysis Approach Suppose that a specification development team or developer creates an analytical architecture for a SYSTEM that includes SUBSYSTEM’s A through D,... conceptual system phases and modes of operation and 2) a multi-level logical architecture (i.e., entities and interfaces) as the framework for specifying system capabilities and performance requirements • Performance-Based Approach A specification development approach that analytically treats a system or entity as a box and specifies condition-based inputs, outputs, behavioral capabilities and responses, and. .. through D, as illustrated in Figure 31.2 SUBSYSTEM A consists of capabilities A1 through A4, SUBSYSTEM B consists of capabilities B1 and B2, and so forth The team constructs an architectural model that expresses the relationships between: • The SYSTEM and External Systems 1 through 5 • SUBSYSTEMs A through D • Capabilities A1–A4, B1–B2 and so forth within each SUBSYSTEM Author’s Note 31.2 Note the use of... the System Developer is to demonstrate compliance as a precursor for delivery and acceptance At the highest level, the System Performance Specification (SPS) or Statement of Objectives (SOO) establish a contract’s technical agreement between the Acquirer, as the User’s technical representative, and the System Developer This section introduces Specification Development Practices and expands on the standard... the specification development strategy for the system illustrated in Figure 31.2 For any specification, the SEIT, IPT, and other teams analyze multi-level User requirements such as a Statement of Objectives (SOOs), System Requirements Document (SRD), SPS, and development specifications Based on the analysis, which includes understanding the problem and solution space, use cases, scenarios, and the like,... selects a SYSTEM architecture, allocates capabilities to architectural elements, and flows requirements allocations down to the PRODUCT A3 Development Specification Simpo PDF Merge and Split31.4 Understanding the Specification Development Paradigm 351 Unregistered Version - http://www.simpopdf.com 1 Requirements Representation 2 I/O Model Representation 3 4 Architectural Representation SYSTEM SYSTEM SYSTEM. .. Remember, system safety design issues demand proper consideration to minimize risk to the SYSTEM and its personnel (people) This includes direct or indirect impacts by the system and its operation or lack thereof on the public, physical property, and the environment Deficiency 8: Specification Change Management Once a specification is approved, baselined, and released, changes must be formally approved and. .. and Development Advantages of the Feature-Based Approach The feature-based approach enables developers to quickly elicit and collect requirements inputs with a minimal effort Specification developers spend very little time analyzing and understanding potential implications and impacts of the requirements When time is limited or a new system is being developed from minor modifications of an existing system, ... develop initial prototypes for testing, collecting, and analyzing performance data; selecting a system architecture; and producing a set of requirements as the work product for a Phase 2 follow-on prototype or system There may even be several other spiral development phases, all focused on derisking the final system development As the Phase 1 requirements and system architecture mature over one or more contracts, . technical represen- tative, and the System Developer. This section introduces Specification Development Practices and expands on the standard outline discussion in Chapter 28 System Specification. When. exists? HOW does the Acquirer System Analysis, Design, and Development, by Charles S. Wasson Copyright © 2006 by John Wiley & Sons, Inc. 327 Simpo PDF Merge and Split Unregistered Version. completeness, specificity, and legal purposes. Key review questions to ask might include: 1. Have all User System Deployment Phase, System Operations and Support (O&S) Phase, and System Disposal Phase