about 〝 requirement 〞 based on - dod-std-2167a - mil-std-490 - ieee 12207 - incose tutorial -...
TRANSCRIPT
About 〝 REQUIREMENT 〞 based on - DoD-STD-2167A - MIL-STD-490 - IEEE 12207 - INCOSE TUTORIAL - CMMI TUTORIAL
Alex Yin ( 尹守紀 ext-7861)
Dec.20.2004
Topics
1. About 〝 Requirement〞2. Guideline to define〝 Requirement〞3. Checklist of 〝 Requirement〞4. Real Practice Case
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.
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
RequirementRequirement WBS ElementsWBS Elements SOW TaskSOW Task
Integrated Management PlanIntegrated Management Plan
Integrated Management ScheduleIntegrated Management Schedule
System Specification
1000 Air Vehicle
1100 Airframe
1110 Wing
1000 Air Vehicle 1100 Airframe 1110 Wing o o 1189 Landing Gear
3.1 Air Vehicle (WBS 1000)Design, develop, produce andverify, complete air vehicles,defined as airframe propulsion,avionics and other installedequipment.
Management Plan EventsPDR
Accomplishment Criteria1.a. Duty Cycle Defined b. Preliminary Analysis Complete1. Preliminary Design Review
Detailed Tasks 19XX 19XY 19XZProgram Events
1. Preliminary Design CompleteDuty Cycle Defined
PDR CDR
1.2- Interrelationship between Requirement and WBS
Test
Code
Design
Requirements
0
5
10
15
20
25
30
35
40
45
50
Relative Cost to Fix
Phase Found
De
fec
t
Ty
pe
Relative Cost to Fix Defects per Phase Found
Test Code Design Requirements
1.4-Who is in charge of Requirement?
Translating Customer Requirements toTranslating Customer Requirements toHW, SW, Specialty, and Test requirementsHW, SW, Specialty, and Test requirements
SE
SW
Tester
HW
Rel, Mfg, HFE...
Marketing /Proj Mgmt
Customer
BAConcept
RefinementSystem Development
& DemonstrationProduction &Deployment
Systems Acquisition
Operations &Support
C
User Needs &Technology Opportunities
Sustainment
FRP DecisionReview
LRIP/IOT&EDesign
ReadinessReview
TechnologyDevelopment
(ProgramInitiation)
ConceptDecision
BAConcept & Technology
DevelopmentSystem Development
& DemonstrationProduction &Deployment
Systems Acquisition
Operations &Support
C
User Needs &Technology Opportunities
Sustainment
FRP DecisionReview
LRIP/OT&EInterim
ProgressReview
Pre-Systems Acquisition
DecisionReview
DoDI 5000.2, Oct 2000
DoDI 5000.2, May 2003
(ProgramInitiation)
1.5- When should have Requirement?
Pre-Systems Acquisition
1.6- What is Requirement? (1)
1. Based on CMMI asa) (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] 〞
b) …, 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).
1.6- What is Requirement? (2)
2. Based on DICTIONARY (article on Wikipedia.org ) asa) In software engineering, a requirement is a description of wha
t 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.
b) 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.
c) The requirements phase may have been preceded by a feasibility study, or a conceptual phase of the project.
d) All requirements should be testable. If this is not the case, then offending requirements should be altered or dropped.
Level of Detail
Project Time
Low
High
AcceptanceTesting
Problem with V-Model: Client’s Perception is the same as the Developer’s Perception
Client’s UnderstandingDeveloper’s Understanding
RequirementsElicitation
Analysis
Design
System Testing
Object Design Unit Testing
Integration Testing
1.7- “Requirement” in V model
Process Implementation Activity
Supporting Processes: Documentation, CM, QA, Verification, Validation, Joint Review, Audit, Problem resolution
Organizational Processes: Management, Infrastructure, Improvement, Training
SystemQual Test
System Integra-tion
Software Installation
Software Acceptance Support
Software Item 1:
Sys ArchDesign
System Reqts An
alysis
SoftwareQual TestSoftware
Integra- tionSoftware
Code & TestSoftware
Detailed Design
Software Arch.
DesignSoftware Reqts.
Analysis
SRS
SARADSRD, UDD
SAD, SIDD, DBDD, T/VP
SRD, UDD
EOCR, SCR,T/VPr, T/VRR
SIP,T/VPr
T/VPrT/VRR
T/VRRSCR
T/VRRSCR
SCR, T/VRR
DPP, SDSD
SCMP, SCMR, SCIR, SQAP, SQAR, SVRR, PR/PRR
Software Item 2:
SoftwareQual TestSoftware
Integra- tionSoftware
Code & TestSoftware
Detailed Design
Software Arch.
DesignSoftware Reqts.
Analysis
Hardware items
1.7- “Requirement” in waterfall model (applying 12207)
Program StrategyDefine All
RequirementsFirst?
MultipleDevelopment
Cycles
DistributeInterim
Software?
Once-Through (Waterfall) Yes No No
Incremental (PreplannedProduct Improvement)
Yes Yes Maybe
Evolutionary No Yes Yes
1.8- The relationship between “Requirement” and model
1.9- The interrelationship between “Requirement” and other’s Process
RD PI
Val
CustomerTS
Ver
REQMRequirements
Customer needs
Product & product component requirements
Product components, work products, verification and validation reports
Productcomponents
Alternativesolutions
Require-ments
Product
1.10- Your 〝 Requirement 〞 from CMMI’s view
System/Subsystem Design Description (SSDD)System Specification (SS) (MIL-STD-961D)
Requirements
Requirement: “Noun shall verb.” Example: The car shall stop within 100 feet at 50 mph.
Functional PerformanceFunction: “Verb Noun.” Example: Stop Car or “Verb-ing.” Example: Stopping.
Component: “Noun.” Example: Brake.
Functions Components
System/Subsystem Specification (SSS)System Requirements Document (SRD)System Requirements Specification (SRS)
(SSDD/SS)
What is Systems Engineering? (cont)
JOCKey Terms and Relationships
Requirements Engineering Process
Inputs
• Customer / User Needs
Performance Requirements
System External Interfaces
Environmental Requirements
• External Influences
Federal Regulations
Navy Orders Standards Available
Funding
• 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
Perform Systems Requirements Analysis and Functional Allocation
OutputsPolitics &Market Place
Rules, Orders, Regulations,Standards
Program Requirements
OPERATIONALNEEDS AND
REQUIREMENTS
1. DEFINEENVIRONMENT
2. DEFINESYSTEM
BOUNDRIES
3. IDENTIFY ATTRIBUTESTO SUPPORT OBJECTIVES
4. ESTABLISHFUNCTIONAL
BASELINE
5. CONDUCTSYSTEM
RQMTS. REVIEW
DESIGNREFERENCE
MISSION
SYSTEM DESCRIPTIONINTERFACES
SYSTEM ANALYSIS
TOP LEVELPERFORMANCEREQUIREMENTS
FUNCTIONALBASELINE
GEO-ECOMONICALTERNATIVES
AFFORDABILITYBOUNDRIES
ID KEY COST ATTRIBUTESAND RELATIONSHIPS
CONDUCT LCC ANDCAIV TRADE-OFFS
Requirements EngineeringProcess
• 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
• 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
Topics
1. About 〝 Requirement〞2. Guideline to define〝 Requirement〞3. Checklist of 〝 Requirement〞4. Real Practice Case
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
– 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
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– Clause 5.5.3 - Requirements
Analysis Process• IEEE/EIA 12207.0, Software Life Cycl
e Processes– Clause 5.3.2 - System Requirements
Analysis– Clause 5.3.4 - Software requirement
s analysis
• IEEE 1233, Guide for Developing System Requirements Specifications
• IEEE 830, Software Requirements Specifications
5.5.3 Requirements Analysis Process5.5.3.1 Purpose of the Requirements Analysis ProcessThe 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.5.5.3.2 Requirements Analysis Process OutcomesAs 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 15288 FDIS, © ISO/IEC2002.
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– Clause 5.5.3 - Requirements
Analysis Process• IEEE/EIA 12207.0, Software Life Cycl
e Processes– Clause 5.3.2 - System Requirements
Analysis– Clause 5.3.4 - Software requirement
s analysis
• IEEE 1233, Guide for Developing System Requirements Specifications
• IEEE 830, Software Requirements Specifications
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. The system requirements specification shall be documented.5.3.4.1 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 . . .
Source: IEEE/EIA 12207.0-1997, © IEEE 2001.
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– Clause 5.5.3 - Requirements
Analysis Process• IEEE/EIA 12207.0, Software Life Cycl
e Processes– Clause 5.3.2 - System Requirements
Analysis– Clause 5.3.4 - Software requirement
s analysis
• IEEE 1233, Guide for Developing System Requirements Specifications
• IEEE 830, Software Requirements Specifications
7.2 Build a well-formed requirementThe 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.
Source: IEEE 1233-1998, © IEEE 1998.
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– Clause 5.5.3 - Requirements
Analysis Process• IEEE/EIA 12207.0, Software Life Cycl
e Processes– Clause 5.3.2 - System Requirements
Analysis– Clause 5.3.4 - Software requirement
s analysis
• IEEE 1233, Guide for Developing System Requirements Specifications
• IEEE 830, Software Requirements Specifications
Source: IEEE 1233-1998, © IEEE 1998.
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– Clause 5.5.3 - Requirements
Analysis Process• IEEE/EIA 12207.0, Software Life Cycl
e Processes– Clause 5.3.2 - System Requirements
Analysis– Clause 5.3.4 - Software requirement
s analysis
• IEEE 1233, Guide for Developing System Requirements Specifications
• IEEE 830, Software Requirements Specifications
5.3.2 FunctionsFunctional 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 inputsb) Exact sequence of operationsc) Responses to abnormal situations, including: 1) Overflow 2) Communication facilities 3) Error handling and recoveryd) Effect of parameterse) Relationship of outputs to inputs . . . 1) It may be appropriate to partition the functional requirements into subfunctions or subprocesses. This doesnot imply that the software design will also be partitioned that way.5.3.3 Performance requirementsThis 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 thefollowing: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.
Source:IEEE 830-1998, © IEEE 1998.
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– Clause 5.5.3 - Requirements
Analysis Process• IEEE/EIA 12207.0, Software Life Cycl
e Processes– Clause 5.3.2 - System Requirements
Analysis– Clause 5.3.4 - Software requirement
s analysis
• IEEE 1233, Guide for Developing System Requirements Specifications
• IEEE 830, Software Requirements Specifications
Source: IEEE 830-1998, © IEEE 1998.
Topics
1. About 〝 Requirement〞2. Guideline to define〝 Requirement〞3. Checklist of 〝 Requirement〞4. Real Practice Case
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
System Requirement Checklist
5 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)
System Requirement Checklist
7 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
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 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)
System Requirement Checklist
12 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 licenses, telecommunication facilities, software from earlier systems, office facilities and services, staff time.(These are not requirements and are therefore shown in an appendix)
Topics
1. About 〝 Requirement〞2. Guideline to define〝 Requirement〞3. Checklist of 〝 Requirement〞4. Real Practice Case
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.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. 計量與計價
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 測試裝置手冊/軟
體要求
Question 1: Feasibility of “Testable”
1. WORK ( 需求內容 ) - 可靠度需求;項 目 MTBF 需求 (小時 )
中央資料處理系統 20,000
車站處理機系統 20,000
2. APPLICABLE STANDARD -3. VERIFICATION REQUIREMENT -
可靠度 / 維修度驗證;• …. 調整期終了後,應開始執行 180 天之營運可靠度 / 維
修度驗證,… .• 就全部已安裝之設備,廠商均應製作監視及性能報告,在
各項之平均故障間隔週期/平均故障間隔時間/平均修復時間 (MCBF) /(MTBF) /(MTTR) 值,應經確證已達 90% 之可信度( confidence )。… .
Question 1: “Feasibility” of Testable
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
4. IMPACT- 可信度 90% 之 GEM (General Exponential Model) table :
Question 2: “Incompleteness” of Requirement
1. WORK ( 需求內容 )- “ 電磁干擾 - 電力及電子系統與子系統在其預定之操作環境下運作應不受捷運工程局之其他操作設備所發出有害之電磁干擾影響,亦不得發出有害之電磁干擾而影響捷運工程局之其他操作設備。廠商須確保儲存或傳輸之資料能完全防禦電磁干擾而不致有所錯誤或遺漏。”
2. APPLICABLE STANDARD- 於該 Requirement 之相關準則中並未引用可依循之標準 (包含 EMI 與 EMC) 。
3. DELIVERY DOCUMENT – None4. VERIFICATION REQUIREMENT - None5. IMPACT-(1) 設計文件、成本、風險、測試標準失去參考依據 ( 特別是頻譜 ) 、
(2)無法在 WBS Level 5 之“ DATA” element列示出相關文件 (NDI或 DI) 、(3) 將影響繞線設計、 (4) 將影響未來測試之“ fault isolation”
• 此項問題適用於“通風”、“電源供應” 需求
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. DELIVERY DOCUMENT – None4. VERIFICATION REQUIREMENT – None5. IMPACT-(1)區域網路介面卡之選用、 (2) 線材選用、 (3)衰減率、有效距離允收
規格、… ..
Question 4: “Ambiguous” of Software Requirement
1. WORK ( 需求內容 )- “針對中央資料處理機系統、車站處理機系統和每一個別設備應用軟體,及個別設備微處理機軟體(個別設備微處機不包含非為本契約專用研發之軟體)之所有軟體文件,皆應提送予工程司”
2. APPLICABLE STANDARD- SDG 2.0 、特別技術規範第 1.8 節1. System Mode- None
3. DELIVERY DOCUMENT – 軟體發展計劃書、軟體需求規格書、介面規格書、軟體設計文件、軟體細步設計文件、軟體測試計劃、軟體整合測試步驟、軟體測試紀錄、軟體問題報告
4. VERIFICATION REQUIREMENT – None (Without TESTING BED)5. IMPACT-(1)REWORK 、 (2)hard to perform ATP 、 (3)hard to plan test proce
dure 、… ..
Question 5: “Ambiguous” of Test Equipment
1. WORK ( 需求內容 )- 廠商應基於收費子系統內電子與機械及機電元件之測試、故障排除( troubleshooting)、程式校準( program calibrating)、編寫可程式唯讀記憶體程式及重新編寫可消除可程式唯讀記憶體程式之需要來提供測試設備。
2. APPLICABLE STANDARD- None (if for Automatic Test Equipment)1. Test Coverage- None
3. DELIVERY DOCUMENT – 測試裝置軟體手冊清單、標準工具4. VERIFICATION REQUIREMENT – 5. IMPACT- (1)難以規劃 O 、 I 、 D Level 之 support equipment 、 (2)
未定定 test coverage 因此將造成允收認知之困擾、 (3)無從得知對於hardware fault isolation 之需求、 (3)無從得知對於 software fault isolation 之需求
Question 6: “Feasibility” of Software MTBF
1. WORK ( 需求內容 )-包含軟體錯誤之所有關聯故障均應納入驗證平均故障間隔週期/平均故障間隔時間之計算中。
2. APPLICABLE STANDARD- None3. DELIVERY DOCUMENT – None4. VERIFICATION REQUIREMENT –
MTBF=設備運轉時間 (總數 )/設備關聯故障次數 (總數 )5. IMPACT- (1) 此公式僅適用於純硬體件、