0. About 〝Requirements〞 尹守紀 國防工業發展協會 科技顧問 E-mail:alexsj.yin@msa.hinet.net
2005年11月
國防工業發展協會
科技顧問
尹守紀
May/25/2006
(尹守紀整理)

1. About 〝REQUIREMENT〞 based on DoD-STD-2167A MIL-STD IEEE INCOSE TUTORIAL CMMI TUTORIAL
May/25/2006
(尹守紀整理)

2. 摘要
系統上線之後將隨着硬體衰退以及軟體市場需求的遞變，經常會在Operation與Maintenance階段發生使用者(1)產生操作不方便(non-friendly)、(2)感覺準確度不足(insufficient accuracy)、(3)運算無法及時處理(non-real time)、(4)使用技能不足(skill level gap)、或維護者發現(5)零件消失造成修護不易(parts obsoleting)、(6)維修檢測不易(stupid test equipment)、(7)可靠度不佳(insufficient reliability)、(8)人力不足(insufficient human resource)、…等問題。管理單位一般處理方式可包括(a)加強訓練以改善操作熟練度、(b)更改操作程序、(c)調整系統任務配賦角色、(d)採購並更換系統。當發生(d)之情形，即進入買方的Acquisition Process，這也是一般對於系統發展或軟體發展最有興趣之部分。
但在進入Acquisition Process之前，事實上尚包括多項有關需求 (requirements)的釐清與分析程序，通常使用單位/操作單位需要以Mission Need Statement (SON)、Operational Requirement (ORD)、..等文件表述現有問題以及需要什麼性能與功能的需求（包含操作環境以及外部介面），也是所謂的requirements engineering中所謂的requirements elicitation程序；user表述之後，acquirer對於此等敘述或需求應進行
May/25/2006
(尹守紀整理)

3. 摘要(續)
分析，此包括成本、效益、可行方式、籌獲方式、技術分析、…等，即所謂的requirements analysis。可行requirements確定之後即進行functional analysis，應將此等requirements 配賦(allocated)到不同的function執行，如何再將function配賦(allocated)到不同的component或subsystem，即是承約商必需於PDR階段完成之事項。在RFP package中的specification，最基本的表達方式就是將functional requirement轉換為functional specification文件，即所謂的documentation程序，較佳的是寫成performance specification，但要避免採用撰寫“how to manufacture”的design specification格式。
Acquisition Process可以Contract Award點區分為Pre-acquisition與Post-acquisition。要執行Contract，就要有RFP之程序，RFP Package包含有三份基本文件(1)Specification、(2)Statement of Works (SOW)或Statement of Objects (SOO)、(3)Contract Data Requirements List (CDRL)、以及以下幾項補充資訊(4)Contract Schedule、(5)保密切結書（視需要）、(6)Program WBS （Down to Level-3），前三份資料（僅敘述“what”，其中specification用以表示涵蓋硬體與軟體的
May/25/2006
(尹守紀整理)

4. 摘要(續)
“goods”，SOW用以表示“service”，將要買的實體物件與服務分開敘述），將組合出合約應完成的Products與Procedures；賣方競標(bids)的Cost Proposal或CWBS即依據此三份文件逐項報價。其中的Specification即是籌獲者（acquirer）依據SON與ORD轉換為Technical Requirements，此部份可稱之為requirements generating system。
RFP內容即涵蓋全部requirements，在前述 “1”-(1)至(8)舉例的情形即所謂的User Needs，通常可以由SON與ORD文件敘述，所敘述的內容可包括Functions to be performed (what)、Performance required (how well)、Essential physical characteristics (environmental/interfaces)；Acquirer或PM在收到有關Requirements的Statements of Needs即可進行Requirements Analysis動作，可大致包括What does the yet to be identified item have to do? 、How well does it have to do it? 、Where will it be used? 、Under what conditions will it be used? 、How often? How long? 、Who will use it? 、When is it needed? 、How many are needed? ，即所謂的requirements validation；此等問題澄清之後即可以撰寫Specification。以Performance Specification而言，其用意應將“Operational Requirements”轉換為承約商
May/25/2006
(尹守紀整理)

5. 摘要(續)
可以執行的“Technical language”且以定量方式敘述而非定性方式敘述，文件中應包括未來所交付產品相關性能的條件（results）、可承受之環境條件（operational environment condition）、以及買方決定允收（verify compliance）之方法。
簽約之後可舉行System Requirement Review (SRR)，SRR係用以確認承約商確實了解買方之Specification、SOW、SOO、Contract Schedule、… 等需求，以避免日後賣方交出不是買方所需要的系統。
RFP package能否涵蓋SON與ORD事項，acquirer即應採用traceability方式表達、若有需求變更即應依循configuration management程序提出change request，即所謂的requirements management。
需求訂定不完整、不正確、或不可行，將會有5-50倍的cost-to-fix之penalty。
May/25/2006
(尹守紀整理)

6. Topics     About 〝Requirement〞 Guideline to define〝Requirement〞
Checklist of 〝Requirement〞
Real Practice Case   
May/25/2006
(尹守紀整理)

7. Crosby: Quality as “Conformance to Requirement”.
1.0-What is Quality?
Watts Humphrey: To improve “Product Quality”, you must improve “Process Quality”.
Crosby: Quality as “Conformance to Requirement”.
First, a software product must provide functions of a type and a time when the user needs them.
Second, the product must work.
May/25/2006
(尹守紀整理)

8. 1.1-5 Common Problems in Software Development
Poor requirements- unclear, incomplete, too general, or not testable.
Unrealistic schedule - if too much work is crammed in too little time.
Inadequate testing - no one will know whether or not the program is any good until the customer complains or systems crash.
Featurities -requests to pile on new features after development is underway.
Miscommunication
May/25/2006
(尹守紀整理)

9. 1.2- Interrelationship between Requirement and WBS
Requirements要能與WBS及SOW相匹配
May/25/2006
(尹守紀整理)

10. 1.3- Why Are Requirements Important?
Software Bugs
Percentage of Bugs by Source
Percentage of Cost of Fixing
Bugs by Source
8 2 13 56 27 7 10
Requirements
Design
Code
Other
Poor Requirements或不將Requirements當一回事將引致〝焦油坑〞
May/25/2006
(尹守紀整理)

11. 50 10 5 Requirement階段的Defect最高需50倍的支出予以矯正，若能在design phase矯正，可降為5倍
May/25/2006
(尹守紀整理)

12. 1.4-Who is in charge of Requirement?
Customer
Marketing /
Proj Mgmt SE
Tester
Rel, Mfg, HFE... HW SW
Translating Customer Requirements to
HW, SW, Specialty, and Test requirements
May/25/2006
(尹守紀整理)

13. 1.6- What is Requirement? (1)
Based on CMMI as
(1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a product or product component to satisfy a contract, standard, specification, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2). [IEEE ] 〞
…, these requirements address the needs of relevant stakeholders, including those pertinent to various product life-cycle phases (e.g., acceptance testing criteria) and product attributes (e.g., safety, reliability, maintainability). Requirements also address constraints caused by the selection of design solutions (e.g., integration of commercial off-the-shelf products).
May/25/2006
(尹守紀整理)

14. 1.6- What is Requirement? (2)
Based on DICTIONARY (article on Wikipedia.org ) as
In software engineering, a requirement is a description of what a system should do. Very few systems have a single requirement, and most have hundreds. A collection of requirements then define the characteristics of the desired (required) system, but do not say how the system should implement those requirements.
In a classical software engineering approach, requirements are used as input into the design stages (functional design followed by technical design) of the development process.
The requirements phase may have been preceded by a feasibility study, or a conceptual phase of the project.
All requirements should be testable. If this is not the case, then offending requirements should be altered or dropped.
May/25/2006
(尹守紀整理)

15. 1.7- “Requirement” in V model
Client’s Understanding
Level of Detail
Developer’s Understanding
Requirements
Elicitation
Acceptance
Testing
Low
“Acceptance testing” against “Requirements”
Problem with V-Model:
Client’s Perception is the same as the
Developer’s Perception
System
Testing
Analysis
The V-model is a variation of the waterfall model that makes explicit the dependency between development activities and verification activities. The difference between the waterfall model and the V model is that the latter makes explicit the notion of level of abstraction. Allactivities from requirements to implementation focus on building more and more detailed representation of the system, whereas all activities from implementation to operation focus on validating the system.
Design
Integration Testing
Object Design
Unit Testing
High
Project Time
May/25/2006
(尹守紀整理)

16. 1.7- “Requirement” in waterfall model (applying 12207)
Process Implementation Activity
SRS
SARAD
SRD, UDD
SAD, SIDD, DBDD, T/VP
EOCR, SCR,T/VPr, T/VRR
SIP,T/VPr
T/VPr
T/VRR
SCR
SCR, T/VRR
DPP, SDSD
SCMP, SCMR, SCIR, SQAP, SQAR, SVRR, PR/PRR
Software Item 1:
Sys Arch Design
System Reqts Analysis
Software Qual Test
Software Integra- tion
Software Code & Test
Software Detailed Design
Software Arch. Design
Software Reqts. Analysis
Software Item 2:
Software Qual Test
Software Integra- tion
Software Code & Test
Software Detailed Design
Software Arch. Design
Software Reqts. Analysis
System Qual Test
System Integra-tion
Software Installation
Software Acceptance Support
Hardware items
A flow chart of Activities of the Development process looks similar to the 498 flow chart.
Animation: takes 6 mouse clicks:
1. “Process Implementation activity” - start to finish of life cycle
2. The other 12 activities of Development Process
3. Software item 2 - in parallel, but not exactly
4. Other items - e.g., Hardware items
5. Other Supporting and Organizational Processes (colored boxes)
6. Associated information items (documents)
The Development process has 13 activities, shown above in the white boxes. Supporting and Operational Processes at the bottom in colored boxes.
Document acronyms are part of the 84, not the 30 with specific info.
Supporting Processes: Documentation, CM, QA, Verification, Validation, Joint Review, Audit, Problem resolution
Organizational Processes: Management, Infrastructure, Improvement, Training
May/25/2006
(尹守紀整理)

17. 1.8- The relationship between “Requirement” and life cycle model
Define All
Requirements First?
Multiple
Development
Cycles
Distribute
Interim
Software?
Program Strategy
Once-Through (Waterfall)
Yes No
Incremental (Preplanned
Product Improvement)
Yes
Maybe
Evolutionary No
Yes
Animation - three strategies appear with three mouse clicks
Managers must choose their life-cycle strategy, so you must understand it.
This table drawn from IEEE Annex I shows three
strategies for acquisition - however the world is not limited
to three. Annex I provides guidance (risk analysis) in helping you understand the factors to consider in selecting one of its recommended strategies.
Please note key difference in the areas of requirements and
in interim distribution - critical aspects in selecting a strategy.
Model of Software Life Cycle goes from concept and Requirement thru retirement. (CMM, IEEE)
IEEE says “this does not prescribe a specific life cycle model or software development method.”
CMM SPP Activity 5: A software life cycle with predefined stages of manageable size is identified or defined. Examples of software life cycles include waterfall, overlapping waterfall, spiral, serial build, single prototype/overlapping waterfall.
Strategies recommended in SSC “Description of the SSC Software Process Assets”
“Requirements Freeze”動作，將隨Life Cycle Model而異
Life Cycle Model不可亂定
May/25/2006
(尹守紀整理)

18. 1.9- The interrelationship between “Requirement” and other’s Process
Continuous屬性的Supporting Process
Discrete屬性的Primary Process
May/25/2006
(尹守紀整理)

19. 1.10- Your〝Requirement〞 from CMMI’s view
REQM PA 僅負責維護Requirements
REQM
Requirements
由RD PA產生Requirements
Product & product component requirements
Alternative solutions RD TS
Product components PI
Product
Customer
Require- ments
Product components, work products, verification and validation reports
Ver
Val
Customer needs
May/25/2006
(尹守紀整理)

20. What is Systems Engineering? (cont)
Key Terms and Relationships
JOC
Requirements
System/Subsystem Specification (SSS)
System Requirements Document (SRD)
System Requirements Specification (SRS)
System/Subsystem Design Description (SSDD)
System Specification (SS) (MIL-STD-961D)
Functions
Components
(SSDD/SS)
Requirement: “Noun shall verb.” Example: The car shall stop within 100 feet at 50 mph.
Functional Performance
Function: “Verb Noun.” Example: Stop Car or “Verb-ing.” Example: Stopping.
Component: “Noun.” Example: Brake.
May/25/2006
(尹守紀整理)
“REQUIREMNTS”包括有Functionality、Performance、Attributes

21. Requirements Engineering Process
OPERATIONAL
REQUIREMENTS
NEEDS AND
ENVIRONMENT
1. DEFINE
2. DEFINE
BOUNDRIES
SYSTEM
TO SUPPORT OBJECTIVES
3. IDENTIFY ATTRIBUTES
4. ESTABLISH
FUNCTIONAL
BASELINE
RQMTS. REVIEW
5. CONDUCT
REFERENCE
MISSION
DESIGN
SYSTEM DESCRIPTION
SYSTEM ANALYSIS
INTERFACES
PERFORMANCE
TOP LEVEL
ALTERNATIVES
GEO-ECOMONIC
AFFORDABILITY
ID KEY COST ATTRIBUTES
AND RELATIONSHIPS
CONDUCT LCC AND
CAIV TRADE-OFFS
Requirements Engineering
Process
Allocation將決定出CSCI與HWCI的requirements內容
Program
Requirements
Rules, Orders,
Regulations,
Standards
Outputs
Politics &
Market Place
Top Level System Requirements
Requirements Traceability Matrix
System Concept of Operations
Functional Architecture
System Functional Block Diagram
System External Interfaces
Life Cycle Cost Objectives
Verification Methodology
Programmatic Risks
Technical Performance Measures
Logistics
Program Systems Engineering Master Schedule
Preliminary Models / Simulations
Inputs
Perform Systems Requirements Analysis and Functional Allocation
Customer / User Needs
Performance Requirements
System External Interfaces
Environmental Requirements
External Influences
Federal Regulations
Navy Orders
Standards
Available Funding
Define customer needs
Identify requirements
Decompose requirements to appropriate working level
Identify top-level functions
Decompose functions to appropriate working level
Integrate functional interfaces
Define performance measures of effectiveness
Identify Systematic Risks
May/25/2006
(尹守紀整理)

22. Topics     About 〝Requirement〞 Guideline to define〝Requirement〞
Checklist of 〝Requirement〞
Real Practice Case   
May/25/2006
(尹守紀整理)

23. An Example - Requirements Development
SP Establish Product and Product Component Requirements
Establish and maintain, from the customer requirements, product and product component requirements essential to product and product component effectiveness and affordability
ISO/IEC 15288, System Life Cycle Processes
Clause Requirements Analysis Process
IEEE/EIA , Software Life Cycle Processes
Clause System Requirements Analysis
Clause Software requirements analysis
IEEE 1233, Guide for Developing System Requirements Specifications
IEEE 830, Software Requirements Specifications
May/25/2006
(尹守紀整理)

24. An Example - Requirements Development
SP Establish Product and Product Component Requirements
Establish and maintain, from the customer requirements, product and product component requirements essential to product and product component effectiveness and affordability
ISO/IEC 15288, System Life Cycle Processes
Clause Requirements Analysis Process
IEEE/EIA , Software Life Cycle Processes
Clause System Requirements Analysis
Clause Software requirements analysis
IEEE 1233, Guide for Developing System Requirements Specifications
IEEE 830, Software Requirements Specifications
5.5.3 Requirements Analysis Process
Purpose of the Requirements Analysis Process
The purpose of the Requirements Analysis Process is to transform the stakeholder, requirement-driven view of desired services into a technical view of a required product that could deliver those services.
This process builds a representation of a future system that will meet stakeholder requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable system requirements that specify, from the developer’s perspective, what characteristics it is to possess and with what magnitude in order to satisfy stakeholder requirements.
Requirements Analysis Process Outcomes
As a result of the successful implementation of the Requirements Analysis Process:
a) The required characteristics, attributes, and functional and performance requirements for a product solution are specified.
b) Constraints that will affect the architectural design of a system and the means to realize it are specified.
c) The integrity and traceability of system requirements to stakeholder requirements is achieved.. . .
Source: ISO/IEC CD FDIS, © ISO/IEC2002.
May/25/2006
(尹守紀整理)

25. An Example - Requirements Development
The specific intended use of the system to be developed shall be analyzed to specify system requirements. The system requirements specification shall describe: functions and capabilities of the system; business, organizational and user requirements; safety, security, human-factors engineering (ergonomics), interface, operations, and maintenance requirements; design constraints and qualification requirements. The system requirements specification shall be documented.
The developer shall establish and document software requirements, including the quality characteristics specifications, described below
a) Functional and capability specifications, including performance, physical characteristics, and environmental conditions under which the software item is to perform;
b) Interfaces external to the software item;
c) Qualification requirements;
d) Safety specifications, including those related to methods of operation and maintenance, environmental influences, and personnel injury;
e) Security specifications, including those related to compromise of sensitive information . . .
SP Establish Product and Product Component Requirements
Establish and maintain, from the customer requirements, product and product component requirements essential to product and product component effectiveness and affordability
ISO/IEC 15288, System Life Cycle Processes
Clause Requirements Analysis Process
IEEE/EIA , Software Life Cycle Processes
Clause System Requirements Analysis
Clause Software requirements analysis
IEEE 1233, Guide for Developing System Requirements Specifications
IEEE 830, Software Requirements Specifications
Source: IEEE/EIA , © IEEE 2001.
May/25/2006
(尹守紀整理)

26. An Example - Requirements Development
7.2 Build a well-formed requirement
The analysts carry out this subphase by doing the following:
a) Ensuring that each requirement is a necessary, short, definitive statement of need (capability, constraints);
b) Defining the appropriate conditions (quantitative or qualitative measures) for each requirement and avoiding adjectives such as “resistant” or “industry wide;”
c) Avoiding requirements pitfalls (see 6.4);
d) Ensuring the readability of requirements, which entails the following:
1) Simple words/phrases/concepts;
2) Uniform arrangement and relationship;
3) Definition of unique words, symbols, and notations;
4) The use of grammatically correct language and symbology.
e) Ensuring testability.
Example:
Capability: Move people between Los Angeles and New York
Condition: Cruising speed of 200 km/hr
Constraint: Maximum speed of 300 km/hr
Well-formed requirement: This system should move people between Los Angeles and New York at an optimal cruising speed of 200 km/hr with a maximum speed of 300 km/hr.
SP Establish Product and Product Component Requirements
Establish and maintain, from the customer requirements, product and product component requirements essential to product and product component effectiveness and affordability
ISO/IEC 15288, System Life Cycle Processes
Clause Requirements Analysis Process
IEEE/EIA , Software Life Cycle Processes
Clause System Requirements Analysis
Clause Software requirements analysis
IEEE 1233, Guide for Developing System Requirements Specifications
IEEE 830, Software Requirements Specifications
Source: IEEE , © IEEE 1998.
May/25/2006
(尹守紀整理)

27. An Example - Requirements Development
SP Establish Product and Product Component Requirements
Establish and maintain, from the customer requirements, product and product component requirements essential to product and product component effectiveness and affordability
ISO/IEC 15288, System Life Cycle Processes
Clause Requirements Analysis Process
IEEE/EIA , Software Life Cycle Processes
Clause System Requirements Analysis
Clause Software requirements analysis
IEEE 1233, Guide for Developing System Requirements Specifications
IEEE 830, Software Requirements Specifications
Source: IEEE , © IEEE 1998.
May/25/2006
(尹守紀整理)

28. An Example - Requirements Development
5.3.2 Functions
Functional requirements should define the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating the outputs. These are generally listed as “shall” statements starting with “The system shall”
These include:
a) Validity checks on the inputs
b) Exact sequence of operations
c) Responses to abnormal situations, including:
1) Overflow
2) Communication facilities
3) Error handling and recovery
d) Effect of parameters
e) Relationship of outputs to inputs . . .
1) It may be appropriate to partition the functional requirements into subfunctions or subprocesses. This does
not imply that the software design will also be partitioned that way.
5.3.3 Performance requirements
This subsection should specify both the static and the dynamic numerical requirements placed on the soft-
ware or on human interaction with the software as a whole. Static numerical requirements may include the
following:
a) The number of terminals to be supported;
b) The number of simultaneous users to be supported;
c) Amount and type of information to be handled.
SP Establish Product and Product Component Requirements
Establish and maintain, from the customer requirements, product and product component requirements essential to product and product component effectiveness and affordability
ISO/IEC 15288, System Life Cycle Processes
Clause Requirements Analysis Process
IEEE/EIA , Software Life Cycle Processes
Clause System Requirements Analysis
Clause Software requirements analysis
IEEE 1233, Guide for Developing System Requirements Specifications
IEEE 830, Software Requirements Specifications
Source:
IEEE , © IEEE 1998.
May/25/2006
(尹守紀整理)

29. An Example - Requirements Development
SP Establish Product and Product Component Requirements
Establish and maintain, from the customer requirements, product and product component requirements essential to product and product component effectiveness and affordability
ISO/IEC 15288, System Life Cycle Processes
Clause Requirements Analysis Process
IEEE/EIA , Software Life Cycle Processes
Clause System Requirements Analysis
Clause Software requirements analysis
IEEE 1233, Guide for Developing System Requirements Specifications
IEEE 830, Software Requirements Specifications
Source: IEEE , © IEEE 1998.
May/25/2006
(尹守紀整理)

30. Topics     About 〝Requirement〞 Guideline to define〝Requirement〞
Checklist of 〝Requirement〞
Real Practice Case   
May/25/2006
(尹守紀整理)

31. System Requirement Checklist
Sect No
Section Title
Activities 1
Introduction
Overview of the SR document and description of what is to be produced and delivered for the Project,
all applicable and reference documents, Definitions, acronyms and abbreviations 2
Background
Information about the general factors that affect the product(s) and their requirements,
physical, hardware, operating environments Relation to other systems, state whether the system is independent, subsystem of a larger one or a replacement 3
Specific requirements
Information about project requirements:
Detailed requirements structured top-down, Feasibility study, Benchmarking study, Requirements Analysis, Project Planning, Evaluation of available products, Technological trials, Development of demonstrator (system mock-up) 4
Hardware requirements
If the contract delivers hardware, specify requirements for each item of equipment; specify: type, number, functionality, standards, interfaces, performance, capacity, expansibility, reliability, availability, durability, maintainability, running cost limitations, operational requirements etc
May/25/2006
(尹守紀整理)

32. System Requirement Checklist5
Tele-communication services
Specify requirements if telecommunication facilities are to be delivered by the project. Omit this section if the project makes use of existing telecommunication facilities 6
System capability
Functional (6.1) – purpose of system
Interfaces (6.2)
Software: e.g., software environments, file formats, database management systems and other software applications·
Hardware: hardware configurations·
Communications: use of a particular network protocol·
External interface requirements should be described or referenced in Interface documents. User interface requirements should be specified under ‘Operational requirements’ (see below). Interface requirements can be illustrated with system block diagrams·
Operational (6.3)·
Security (6.4)·
Safety (6.5)
Quality (6.6)
May/25/2006
(尹守紀整理)

33. System Requirement Checklist7
System management
Installation support (7.1)
Diagnostic tools (7.2)
Configuration, release control and faults (7.3)
Instrumentation (7.4)
Tuning (7.5)
Back-up and recovery (7.6)
Operational control (7.7) 8
Operational characteristics
Capacity (8.1) –eg processing power, memory, disc space etc; include expansibility·
Performance (8.2) – must be quantitative, not qualitative, statements; possibly include worst/best cases and nominal value to be used for planning·
Availability (8.3) – details of days/times, tolerable breaks, system failure notification, usage during failure and availability monitoring ·
Reliability (8.4) – acceptable mean time between failure (MTBF), minimum acceptable MTBF; reliability verification
May/25/2006
(尹守紀整理)

34. System Requirement Checklist9
System architecture
Maintainability (9.1) – fault repair and adaptability in quantitative terms; influence of user availability/adaptability·
Portability (9.2) – software ability to work on other (named) systems ·
Prescribed components (9.3) – applications, tools and techniques available from other projects and OSNs; consider Horizontal Actions and Measures·
Software constitution and structure (9.4) – name actual products 10
Documentation
Documents may include user training, user reference, system management, operational support, release notes, configuration control files, system maintenance, supplier reference, warranties 11
Other services
·Training (11.1), Installation processes (11.2) , Data set-up (11.3), Parallel running (11.4), Operational support (11.5), Warranty (11.6) Maintenance (11.7)
May/25/2006
(尹守紀整理)

35. System Requirement Checklist12
Developmental requirements
Roles and responsibilities (12.1)
Phases (12.2)
Verification (12.3) A
Requirements traceability matrix B
Services provided by the Commission
Specify any tools, services or facilities to be provided by or on behalf of the European Commission. Examples are equipment, software licences, telecommunication facilities, software from earlier systems, office facilities and services, staff time.(These are not requirements and are therefore shown in an appendix)
May/25/2006
(尹守紀整理)

36. Topics     About 〝Requirement〞 Guideline to define〝Requirement〞
Checklist of 〝Requirement〞
Real Practice Case   
May/25/2006
(尹守紀整理)

37. One real case –for “feasibility”
1. 通則
1.1 本章概要
1.2 工作範圍
1.3 相關章節
1.4 相關準則
1.5 一般要求
1.5.1 概述
1.5.2 工作概述
1.5.3 廠商之設計責任
1.5.4 送審清單
1.5.5 設計、圖說、
配置圖與示意圖
1.5.6 界面作業
1.5.7 一般特性與保証
1.5.8 定義
1.5.9 縮寫
1.6 設計參數
1.6.1 一般要求
1.6.2 設備之獨立運作
1.6.3 處理機系統設施之使用
1.6.4 保全
1.6.5 電源供應
1.6.6 接地與聯結
1.6.7 電磁干擾
1.6.8 通風
1.6.9 資訊年序
1.7 技術要求
1.7.1 概述
1.7.2 實體要求
1.7.3 修護
1.7.4 佈纜與配線
1.8 軟體
1.8.1 概述
1.8.2 軟體設計
1.8.3 軟體設計之核准
1.8.4 擴充文件
1.9 相容性
1.9.1 概述
1.9.2 車票規格
1.9.3 票箱
1.9.4 非法使用偵測系統
1.9.5 地板下方線槽之位置
1.9.6 中央資料處理機系統與台北智慧卡公司清算中心之相容性
1.10 特殊工具與測試設備 概述
印刷電路板測試設備
可消除可程式唯讀記憶體之程式編寫設備
測試裝置手冊／軟體要求
特殊工具與測試設備
標準工具
1.11 管理系統 概述
設計審查
1.12 系統保證 概要
可靠度
維修度
系統安全
人因工程
1.13 系統支援 概述
技術支援
技術、操作與維修手冊 訓練 備品
2. 產品
3. 施工
3.1 拆移
3.2 安裝
4. 計量與計價
May/25/2006
(尹守紀整理)

38. Question 1: Feasibility of “Testable”
WORK (需求內容) - 可靠度需求；
項 目
MTBF需求(小時)
中央資料處理系統
20,000
車站處理機系統
APPLICABLE STANDARD -
VERIFICATION REQUIREMENT -
可靠度/維修度驗證；
….調整期終了後，應開始執行180天之營運可靠度/維修度驗證，….
就全部已安裝之設備，廠商均應製作監視及性能報告，在各項之平均故障間隔週期／平均故障間隔時間／平均修復時間(MCBF) /(MTBF) /(MTTR)值，應經確證已達90%之可信度（confidence）。….
May/25/2006
(尹守紀整理)

39. Question 1: “Feasibility” of Testable
IMPACT-可信度90%之GEM (General Exponential Model) table：
No. of Failure(r)
Test Ratio(M)
Total Test Time(hr)
2.3026
20,000*2.3026=46,052(hr) 1
3.8897
20,000*3.8897=77,794 2
5.3223
20,000*5.3223=106,446 3
6.6808
20,000*6.6808=133,616 4
7.9936
159,872 5
9.2747
185,494 6
210,642 7
235,418 8
259,894 9
204,120 10
308,176
依據上述MTBF需求、180天(4320 hours)Demonstration Test與GEM表格，單一中央資料處理系統(20,000 hours MTBF)要達到46,052 hours “0” failure之允收標準將是一項non-feasible之test item
在簽約前即需將此requirement予以修訂為可行的諸如5,000小時
軟體可靠度上無法同硬體以MTBF表示(應改寫為諸如1.5defets per 50 CPU operating hours)
May/25/2006
(尹守紀整理)

40. Question 2: “Incompleteness” of Requirement
WORK (需求內容)- “電磁干擾- 電力及電子系統與子系統在其預定之操作環境下運作應不受捷運工程局之其他操作設備所發出有害之電磁干擾影響，亦不得發出有害之電磁干擾而影響捷運工程局之其他操作設備。廠商須確保儲存或傳輸之資料能完全防禦電磁干擾而不致有所錯誤或遺漏。”
APPLICABLE STANDARD- 於該Requirement之相關準則中並未引用可依循之標準(包含EMI與EMC)。
DELIVERY DOCUMENT – None
VERIFICATION REQUIREMENT - None
IMPACT-(1)設計文件、成本、風險、測試標準失去參考依據(特別是頻譜)、(2)無法在WBS Level 5之“DATA” element列示出相關文件(NDI或DI)、(3)將影響繞線設計、(4)將影響未來測試之“fault isolation”
此項問題適用於“通風”、“電源供應” 需求
在需求文件未於applicable standard中訂定參用標準，將造成後續ATP之爭議
May/25/2006
(尹守紀整理)

41. Question 3: “Ambiguous” of LAN Requirement
WORK (需求內容)- “區域網路(LAN)及網路電纜(Network Cables)另依IEEE802國際標準之相關規定辦理 ”
APPLICABLE STANDARD-IEEE802，但未細訂至
Gigabit Ethernet 以光纖為傳輸介質的IEEE 802.3z 標準、或
以銅線為傳輸媒介的1000 Base-T 規格之制訂，即IEEE 802.3ab、或
IEEE802.3u Fast Ethernet standard、或
IEEE802.11無線區域網路 ….
DELIVERY DOCUMENT – None
VERIFICATION REQUIREMENT – None
IMPACT-(1)區域網路介面卡之選用、(2)線材選用、(3)衰減率、有效距離允收規格、…..
在需求文件未於applicable standard中訂定參用標準，將造成後續ATP之爭議
May/25/2006
(尹守紀整理)

42. Question 4: “Ambiguous” of Software Requirement
WORK (需求內容)- “針對中央資料處理機系統、車站處理機系統和每一個別設備應用軟體，及個別設備微處理機軟體（個別設備微處機不包含非為本契約專用研發之軟體）之所有軟體文件，皆應提送予工程司”
APPLICABLE STANDARD- SDG 2.0 、特別技術規範第1.8節
System Mode- None
DELIVERY DOCUMENT –軟體發展計劃書、軟體需求規格書、介面規格書、軟體設計文件、軟體細步設計文件、軟體測試計劃、軟體整合測試步驟、軟體測試紀錄、軟體問題報告
VERIFICATION REQUIREMENT – None (Without TESTING BED)
IMPACT-(1)REWORK、(2)hard to perform ATP、(3)hard to plan test procedure、…..
在需求文件中未於VCRI (Verification Cross Reference Table)中訂定參用允收方法，將造成後續ATP之爭議
May/25/2006
(尹守紀整理)

43. Question 5: “Ambiguous” of Test Equipment
WORK (需求內容)-廠商應基於收費子系統內電子與機械及機電元件之測試、故障排除（troubleshooting）、程式校準（program calibrating）、編寫可程式唯讀記憶體程式及重新編寫可消除可程式唯讀記憶體程式之需要來提供測試設備。
APPLICABLE STANDARD- None (if for Automatic Test Equipment)
Test Coverage- None
DELIVERY DOCUMENT – 測試裝置軟體手冊清單、標準工具
VERIFICATION REQUIREMENT –
IMPACT- (1)難以規劃O、I、D Level 之support equipment、(2)未定定test coverage因此將造成允收認知之困擾、(3)無從得知對於hardware fault isolation之需求、(3)無從得知對於software fault isolation之需求
May/25/2006
(尹守紀整理)

44. Question 6: “Feasibility” of Software MTBF
WORK (需求內容)-包含軟體錯誤之所有關聯故障均應納入驗證平均故障間隔週期／平均故障間隔時間之計算中。
APPLICABLE STANDARD- None
DELIVERY DOCUMENT – None
VERIFICATION REQUIREMENT –
MTBF=設備運轉時間(總數)/設備關聯故障次數(總數)
IMPACT- (1) 此公式僅適用於純硬體件、
May/25/2006
(尹守紀整理)