Transcript PowerPoint 簡報

About 〝REQUIREMENT〞
國防工業發展協會
尹守紀
科技顧問
2005年11月
E-mail:[email protected]
0
About 〝REQUIREMENT〞
based on
- DoD-STD-2167A
- MIL-STD-490
- IEEE 12207
- INCOSE TUTORIAL
- CMMI TUTORIAL
1
Topics




1.
2.
3.
4.
About 〝Requirement〞
Guideline to define〝Requirement〞
Checklist of 〝Requirement〞
Real Practice Case
2
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.
3
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
4
1.2- Interrelationship between Requirement and
WBS
Requirements要能與WBS及
SOW相匹配
Requirement
Requirement
WBSElements
Elements
WBS
1000 Air Vehicle
1100 Airframe
1110 Wing
System Specification
1000 Air Vehicle
o
o
1100 Airframe
1110 Wing
1189 Landing Gear
SOWTask
Task
SOW
3.1 Air Vehicle (WBS 1000)
Design, develop, produce and
verify, complete air vehicles,
defined as airframe propulsion,
avionics and other installed
equipment.
IntegratedManagement
ManagementPlan
Plan
Integrated
Management Plan
Events
Accomplishment Criteria
PDR
1.a. Duty Cycle Defined
b. Preliminary Analysis Complete
1. Preliminary Design Review
IntegratedManagement
ManagementSchedule
Schedule
Integrated
Detailed Tasks
Program Events
1. Preliminary Design Complete
Duty Cycle Defined
19XX
PDR
19XY
CDR
19XZ
5
Relative Cost to Fix Defects per Phase Found
50
50
45
40
35
30
25Relative
Defect
Type
10
5
20
Cost
to Fix
15
Requirements
Design
10
5
Code
0
Test
nts
e
em
uir
q
Re
n
s ig
e
D
de
Co
st
Te
Phase Found
Test
Code
Design
Requirement階段的
Defect最高需50倍的
支出予以矯正，若能
在design phase矯正，
可降為5倍
Requirements
7
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
8
1.6- What is Requirement? (1)
1.
Based on CMMI as
a)
b)
(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 610.12-1990] 〞
…, 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).
9
1.6- What is Requirement? (2)
2.
Based on DICTIONARY (article on Wikipedia.org ) as
a)
b)
c)
d)
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.
10
1.7- “Requirement” in V model
Client’s Understanding
Developer’s Understanding
Level of Detail
Low
Requirements
Elicitation
Acceptance
Testing
Problem with V-Model:
Client’s Perception is the same as the
Developer’s Perception
“Acceptance
testing” against
“Requirements”
System
Testing
Analysis
Design
Object Design
Integration Testing
Unit Testing
High
Project Time
11
1.7- “Requirement” in waterfall model (applying
12207)
Process Implementation Activity
DPP, SDSD
Software Item 1:
SARAD
Sys Arch
Design
System
Reqts
Analysis
Software
Detailed
Design
Software
Qual Test
Software
Integra- tion
Software
SCR, T/VRR
Code
Software
Installation
& Test
SIP,T/VPr
Software
EOCR, SCR,T/VPr, T/VRR
Arch.
Software
Design
Reqts.
SRD, UDD
Analysis
Software
SAD, SIDD, DBDD, T/VP
Qual
Test
SRD, UDD
Software
Integra- tion
Software
Code
Software Item 2:
Software
& Test
Software Detailed
Design
Arch.
Software
Design
Reqts.
Analysis
System
Qual
System
Test
Integra-tion
T/VRR
SCR
T/VPr
T/VRR
SRS
Hardware items
Software
Acceptance
Support
T/VRR
SCR
Supporting Processes: Documentation, CM, QA, Verification, Validation, Joint Review, Audit, Problem resolution
SCMP, SCMR, SCIR, SQAP, SQAR, SVRR, PR/PRR
Organizational Processes: Management, Infrastructure, Improvement, Training
12
1.8- The relationship between “Requirement” and
life cycle model
Define All
Requirements
First?
Multiple
Development
Cycles
Distribute
Interim
Software?
Once-Through (Waterfall)
Yes
No
No
Incremental (Preplanned
Product Improvement)
Yes
Yes
Maybe
Evolutionary
No
Yes
Yes
Program Strategy
1. “Requirements Freeze”動作，
將隨Life Cycle Model而異
2. Life Cycle Model不可亂定
13
1.9- The interrelationship between “Requirement”
and other’s Process
Continuous屬性的
Supporting Process
14
Discrete屬性的Primary
Process
1.10- Your〝Requirement〞 from CMMI’s view
Requirements
REQM
REQM PA 僅負
責維護
Requirements
由RD PA產生
Requirements
Product & product
component requirements
Alternative
solutions
Product
components
TS
RD
Product
PI
Customer
Requirements
Product components, work products,
verification and
validation reports
Ver
Customer needs
Val
15
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
Requirement: “Noun shall verb.”
(SSDD/SS)
Components
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.
“REQUIREMNTS”包括有Functionality、
Performance、Attributes
16
Requirements Engineering Process
Program
Requirements
Requirements Engineering
Process
Rules, Orders,
Regulations,
Standards
CONDUCT LCC AND
CAIV TRADE-OFFS
ID KEY COST ATTRIBUTES
AND RELATIONSHIPS
Politics &
Market Place
AFFORDABILITY
BOUNDRIES
GEO-ECOMONIC
ALTERNATIVES
SYSTEM DESCRIPTION
INTERFACES
SYSTEM ANALYSIS
DESIGN
REFERENCE
MISSION
5. CONDUCT
SYSTEM
RQMTS. REVIEW
FUNCTIONAL
BASELINE
TOP LEVEL
PERFORMANCE
REQUIREMENTS
4. ESTABLISH
FUNCTIONAL
BASELINE
1. DEFINE
ENVIRONMENT
Inputs
Perform Systems Requirements
Analysis and Functional Allocation
•
•
•
•
•
•
•
•
Outputs
3. IDENTIFY ATTRIBUTES
TO SUPPORT OBJECTIVES
2. DEFINE
SYSTEM
BOUNDRIES
OPERATIONAL
NEEDS AND
REQUIREMENTS
• Customer / User
Needs
- Performance
Requirements
- System
External
Interfaces
- Environmental
Requirements
• External
Influences
- Federal
Regulations
- Navy Orders
- Standards
- Available
Funding
Allocation將決定出CSCI與
HWCI的requirements內容
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
• 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
17
Topics




1.
2.
3.
4.
About 〝Requirement〞
Guideline to define〝Requirement〞
Checklist of 〝Requirement〞
Real Practice Case
18
An Example - Requirements Development
SP 2.1-1 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
–
•
IEEE/EIA 12207.0, Software Life
Cycle Processes
–
–
•
•
Clause 5.5.3 - Requirements Analysis
Process
Clause 5.3.2 - System Requirements
Analysis
Clause 5.3.4 - Software requirements
analysis
IEEE 1233, Guide for Developing
System Requirements Specifications
IEEE 830, Software Requirements
Specifications
19
An Example - Requirements Development
SP 2.1-1 Establish Product and
Product Component Requirements
•
ISO/IEC 15288, System Life Cycle
Processes
– Clause 5.5.3 - Requirements Analysis
Establish and maintain, from the
Process
customer requirements, product
and
product component
5.5.3
Requirements
Analysis Process
• IEEE/EIA 12207.0, Software Life
requirements
essential
to product
5.5.3.1
Purpose of the
Requirements
Analysis Process Cycle Processes
Theand
purpose
of the Requirements
product
componentAnalysis Process is to transform
5.3.2 - System Requirements
the effectiveness
stakeholder, requirement-driven
view of desired services –
into Clause
a
and affordability
Analysis
technical view of a required product that could deliver those services.
This process builds a representation of a future system that will
– meet
Clause 5.3.4 - Software requirements
stakeholder requirements and that, as far as constraints permit, does
analysis
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
• IEEE 1233, Guide for Developing
order to satisfy stakeholder requirements.
System Requirements Specifications
5.5.3.2 Requirements Analysis Process Outcomes
As a result of the successful implementation of the Requirements
• IEEE 830, Software Requirements
Analysis Process:
Specifications
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.
20
c) The integrity and traceability of system requirements to
Source: ISO/IEC CD 15288 FDIS, © ISO/IEC2002.
stakeholder requirements is achieved.. . .
An Example - Requirements Development
5.3.2.1 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.
SP 2.1-1
Establish
Product
The system
requirements
specification
shall beand
documented. •
5.3.4.1
The developer
shall establishRequirements
and document software
Product
Component
requirements, including the quality characteristics specifications,
– below.
Establish
and maintain, from the
described
...
customer
requirements,
productperformance,
a) Functional
and capability
specifications, including
physical characteristics,
andcomponent
environmental conditions under •
and product
which the software
item is to perform;
requirements
essential to product
b) Interfacesand
external
to
the
software
item;
product component
c) Qualification requirements;
effectiveness and affordability
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 . . .
•
•
ISO/IEC 15288, System Life Cycle
Processes
–
Clause 5.5.3 - Requirements Analysis
Process
IEEE/EIA 12207.0, Software Life
Cycle Processes
–
–
Clause 5.3.2 - System Requirements
Analysis
Clause 5.3.4 - Software requirements
analysis
IEEE 1233, Guide for Developing
System Requirements Specifications
IEEE 830, Software Requirements
Specifications
Source: IEEE/EIA 12207.0-1997, © IEEE 2001.
21
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
SP 2.1-1
Product
measures)
for eachEstablish
requirement and
avoiding and
adjectives such•as ISO/IEC 15288, System Life Cycle
“resistant”
or “industry
wide;”
Processes
Product
Component
Requirements
c) Avoiding requirements pitfalls (see 6.4);
– Clause 5.5.3 - Requirements Analysis
– Establish
and
maintain, from
d) Ensuring
the readability
of requirements,
which the
entails the following:
Process
customer requirements, product
1) Simple words/phrases/concepts;
2) Uniformand
arrangement
and
relationship;
product
component
• IEEE/EIA 12207.0, Software Life
3) Definition
of unique words,essential
symbols, and
requirements
to notations;
product
Cycle Processes
4) The useand
of grammatically
correct language and symbology.
product component
e) Ensuring testability.
– Clause 5.3.2 - System Requirements
effectiveness and affordability
Example:
Analysis
Capability: Move people between Los Angeles and New York
– Clause 5.3.4 - Software requirements
Condition: Cruising speed of 200 km/hr
analysis
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
• IEEE 1233, Guide for Developing
with a maximum speed of 300 km/hr.
•
Source: IEEE 1233-1998, © IEEE 1998.
System Requirements Specifications
IEEE 830, Software Requirements
Specifications
22
An Example - Requirements Development
SP 2.1-1 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
–
•
IEEE/EIA 12207.0, Software Life
Cycle Processes
–
–
•
•
Clause 5.5.3 - Requirements Analysis
Process
Clause 5.3.2 - System Requirements
Analysis
Clause 5.3.4 - Software requirements
analysis
IEEE 1233, Guide for Developing
System Requirements Specifications
IEEE 830, Software Requirements
Specifications
23
Source: IEEE 1233-1998, © IEEE 1998.
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
• ISO/IEC 15288, System Life Cycle
SP 2.1-1
Establish
b) Exact
sequence
of operationsProduct and
c) Responses
abnormal situations,
including:
Processes
Productto Component
Requirements
1) Overflow
– Clause 5.5.3 - Requirements Analysis
– Establish
and maintain, from the
2) Communication
facilities
Process
customer
product
3) Error handling
and requirements,
recovery
d) Effect ofand
parameters
product component
• IEEE/EIA 12207.0, Software Life
e) Relationship
of
outputs toessential
inputs . . . to product
requirements
Cycle Processes
1) It mayand
be appropriate
partition the functional requirements into
producttocomponent
subfunctions or subprocesses. This does
– Clause 5.3.2 - System Requirements
effectiveness and affordability
not imply that the software design will also be partitioned that way.
Analysis
5.3.3 Performance requirements
– Clause 5.3.4 - Software requirements
This subsection should specify both the static and the dynamic
analysis
numerical requirements placed on the software or on human interaction with the software as a whole. Static
numerical requirements may include the
• IEEE 1233, Guide for Developing
following:
a) The number of terminals to be supported;
System Requirements Specifications
b) The number of simultaneous users to be supported;
• IEEE 830, Software Requirements
c) Amount and type of information to be handled.
Specifications
Source:
IEEE 830-1998, © IEEE
1998.
24
An Example - Requirements Development
SP 2.1-1 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
–
•
IEEE/EIA 12207.0, Software Life
Cycle Processes
–
–
•
•
Clause 5.5.3 - Requirements Analysis
Process
Clause 5.3.2 - System Requirements
Analysis
Clause 5.3.4 - Software requirements
analysis
IEEE 1233, Guide for Developing
System Requirements Specifications
IEEE 830, Software Requirements
Specifications
25
Source: IEEE 830-1998, © IEEE 1998.
Topics




1.
2.
3.
4.
About 〝Requirement〞
Guideline to define〝Requirement〞
Checklist of 〝Requirement〞
Real Practice Case
26
System Requirement Checklist
Sect
No
1
Section Title
Introduction
Activities
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
4
Specific
requirements
Information about project requirements:
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
– 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)
27
System Requirement Checklist
5
Tele-communication •Specify requirements if telecommunication facilities are to be
delivered by the project. Omit this section if the project makes use of
services
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)
28
System Requirement Checklist
7
8
System management •Installation support (7.1)
Operational
characteristics
•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)
•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
29
System Requirement Checklist
9
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
11
Other services
Documents may include user training, user reference, system
management, operational support, release notes, configuration
control files, system maintenance, supplier reference, warranties
·Training (11.1), Installation processes (11.2) , Data setup (11.3), Parallel running (11.4), Operational support
(11.5), Warranty (11.6) Maintenance (11.7)
30
System Requirement Checklist
12
Developmental
requirements
A
Requirements
traceability matrix
Services provided
by the Commission
B
•Roles and responsibilities (12.1)
•Phases (12.2)
•Verification (12.3)
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)
31
Topics




1.
2.
3.
4.
About 〝Requirement〞
Guideline to define〝Requirement〞
Checklist of 〝Requirement〞
Real Practice Case
32
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.10.1
概述
1.10.2
印刷電路板測試設備
1.10.3
可消除可程式唯讀記憶
體之程式編寫設備
1.10.4
測試裝置手冊／軟體要
求
1.10.5
特殊工具與測試設備
1.10.6
標準工具
1.11管理系統
1.11.1
概述
1.11.2
設計審查
1.12系統保證
1.12.1
概要
1.12.2
可靠度
1.12.3
維修度
1.12.4
系統安全
1.12.5
人因工程
1.13系統支援
1.13.1
概述
1.13.2
技術支援
1.13.3
技術、操作與維修手冊
1.13.4
訓練
1.13.5
備品
2. 產品
3. 施工
3.1 拆移
3.2 安裝
4. 計量與計價
33
Question 1: Feasibility of “Testable”
1.
WORK (需求內容) - 可靠度需求；
項
目
MTBF需求(小時)
中央資料處理系統
20,000
車站處理機系統
20,000
2.
APPLICABLE STANDARD -
3.
VERIFICATION REQUIREMENT
-
可靠度/維修度驗證；
•
….調整期終了後，應開始執行180天之營運可靠度/維修
度驗證，….
•
就全部已安裝之設備，廠商均應製作監視及性能報告，在
各項之平均故障間隔週期／平均故障間隔時間／平均修復
時間(MCBF) /(MTBF) /(MTTR)值，應經確證已達90%
之可信度（confidence）。….
34
Question 1: “Feasibility” of Testable
4.
IMPACT-可信度90%之GEM (General Exponential Model) table：
•
No. of Failure(r)
Test Ratio(M)
Total Test Time(hr)
0
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
10.5321
210,642
7
11.7709
235,418
8
12.9947
259,894
9
14.2060
204,120
10
15.4088
308,176
依據上述MTBF需求、180天(4320 hours)Demonstration Test與GEM表格，
單一中央資料處理系統(20,000 hours MTBF)要達到46,052 hours “0” failure
之允收標準將是一項non-feasible之test item
1.
在簽約前即需將此requirement予以修訂為可行的諸如5,000小時
2.
軟體可靠度上無法同硬體以MTBF表示(應改寫為諸如1.5defets per 50 CPU
operating hours)
35
Question 2: “Incompleteness” of Requirement
1.
WORK (需求內容)- “電磁干擾- 電力及電子系統與子系統在其預定之操作環境
下運作應不受捷運工程局之其他操作設備所發出有害之電磁干擾影響，亦不得發
出有害之電磁干擾而影響捷運工程局之其他操作設備。廠商須確保儲存或傳輸之
資料能完全防禦電磁干擾而不致有所錯誤或遺漏。”
2.
APPLICABLE STANDARD- 於該Requirement之相關準則中並未引用可依循
之標準(包含EMI與EMC)。
DELIVERY DOCUMENT – None
VERIFICATION REQUIREMENT - None
3.
4.
5.
IMPACT-(1)設計文件、成本、風險、測試標準失去參考依據(特別是頻譜)、(2)
無法在WBS Level 5之“DATA” element列示出相關文件(NDI或DI)、(3)將影
響繞線設計、(4)將影響未來測試之“fault isolation”
•
此項問題適用於“通風”、“電源供應” 需求
1.
在需求文件未於applicable standard中訂定參用標準，將造成後續ATP之
爭議
36
Question 3: “Ambiguous” of LAN Requirement
1.
WORK (需求內容)- “區域網路(LAN)及網路電纜(Network Cables)另依IEEE802國
際標準之相關規定辦理 ”
2.
APPLICABLE STANDARD-IEEE802，但未細訂至
•
Gigabit Ethernet 以光纖為傳輸介質的IEEE 802.3z 標準、或
•
以銅線為傳輸媒介的1000 Base-T 規格之制訂，即IEEE 802.3ab、
或
•
IEEE802.3u Fast Ethernet standard、或
•
IEEE802.11無線區域網路
•
….
3.
4.
DELIVERY DOCUMENT – None
VERIFICATION REQUIREMENT – None
5.
IMPACT-(1)區域網路介面卡之選用、(2)線材選用、(3)衰減率、有效距離允收規
格、…..
1.
在需求文件未於applicable standard中訂定參用標準，將造成後續ATP之
爭議
37
Question 4: “Ambiguous” of Software Requirement
1.
WORK (需求內容)- “針對中央資料處理機系統、車站處理機系統和每一
2.
個別設備應用軟體，及個別設備微處理機軟體（個別設備微處機不包含
非為本契約專用研發之軟體）之所有軟體文件，皆應提送予工程司”
APPLICABLE STANDARD- SDG 2.0 、特別技術規範第1.8節
3.
4.
5.
1.
1. 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之爭議
38
Question 5: “Ambiguous” of Test Equipment
1.
WORK (需求內容)-廠商應基於收費子系統內電子與機械及機電元件之測
2.
試、故障排除（troubleshooting）、程式校準（program
calibrating）、編寫可程式唯讀記憶體程式及重新編寫可消除可程式
唯讀記憶體程式之需要來提供測試設備。
APPLICABLE STANDARD- None (if for Automatic Test Equipment)
3.
4.
5.
1. 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之需求
39
Question 6: “Feasibility” of Software MTBF
1.
2.
3.
4.
WORK (需求內容)-包含軟體錯誤之所有關聯故障均應納入驗證平均故障
間隔週期／平均故障間隔時間之計算中。
APPLICABLE STANDARD- None
DELIVERY DOCUMENT – None
VERIFICATION REQUIREMENT –
MTBF=設備運轉時間(總數)/設備關聯故障次數(總數)
5.
IMPACT- (1)
此公式僅適用於純硬體件、
40