IEEE WG 12 Software Meeting 12

October 26, 2001

Meeting Minutes - Draft

The twelfth meeting of the working group was held on October 16 and 17, 2001 at the New York City Transit offices in Brooklyn, NY.

The meeting was called to order on October 16, 2001 at 9:30 AM

Participants

A listing of participants is attached. Nine members attended the meeting.

Agenda

The agenda was accepted. See attachment.

Minutes

The committee approved the minutes from meeting 11. The final meeting minutes will be posted on the website. See attachment.

NYCT has expressed a strong desire to utilize this standard in any procurement that utilizes software. The working group needs to bring the standard forward for full committee action in early 2002.

Assignment Reports

1. Outline Submittals (11.01) John Corvin

SQAP Outline Review

The SQAP outline was reviewed and updated. Changes were made to define the software items (1.5), responsibilities – customer (3.3.3), governing documentation (4.1.1), documentation validation (4.1.2), minimum documentation requirements (4.2), standards, practices and conventions, metrics (5.0), tests (7.0), and software problem and corrective action (8.0)

The quality audits between the SPMP and SQAP need to be resolved between John Corvin and Shanti Morar. Sections 6.1 and 6.2 are involved.

The updated SQAP outline is included in these minutes.

2. SVD & SUM Outline Review (10.06) Tom Tougas

No report was provided. Tom committed to completed the requested outlines

3. SRS, IRS, SDD, IDD & DBDD Outline Review (10.07) Bill MacArthur

No report was provided. Action items were assigned for creation of these outlines.

Draft Standard Review (11.04) Paul Jamieson

The standard was updated to include the latest information developed from the various outlines.

Action Item Review Paul Jamieson

Action items were assigned. See attachments.

The SRS, SDD, IRS, IDD and DBDD were reassigned to other individuals to complete for the next meeting.

Tom Tougas has committed to complete the SVD and SUM outlines.

The sample outline is contained within these meeting minutes.

Next Meeting

The working group meeting 13 will be on December 11 and 12, 2001 at Safetrans – Rancho Cucamonga, CA.

Adjournment

The meeting was adjourned on October 17, 2001 at 2:30 PM.

Attachments

Agenda – separate file (wg12agn12.doc)

Roster – separate file (wg12roster.xls)

Meeting 11 Minutes – separate file (wg12mom11final.doc)

Draft Standard – separate file (D-P1558D2.0.doc)

Action Item Listing – separate file (wg12ail12.xls)

The following information distributed at the meeting appears on the following pages:

SQAP Outline

SCMP Outline

SRTM Outline

Outline Table Sample

Software Quality Assurance Plan Straw Man – Revision 2

Legend:

A Additions

M Modified

NR Not Required

Section	Changes	Content List	Applicability	Comments
Cover	A	Date of issue and document status	Mandatory	Added to satisfy 12207.1 - 1997
Inside Cover	A	SQAP Change History	Mandatory	Added to satisfy 12207.1 - 1997
1.0		Purpose	Mandatory
1.1		SQAP Purpose	Mandatory
1.2		Scope	Mandatory
1.3	M	SQA Objectives	Mandatory	Documents motivating the SQAP shall be referenced - Added to satisfy 12207.1 - 1997
1.4		Software Items Covered	Mandatory	Highest level aggregate(s) of software elements covered by this plan
1.5		SQA Life Cycle	Recommended
1.6		SQAP Standards	Mandatory
1.7	A	SQAP Maintenance	Mandatory	Added to satisfy 12207.1 - 1997
2.0		References	Mandatory
2.1		Document References	Mandatory
2.2	A	Acronyms	Mandatory	Added to satisfy 12207.1 - 1997
2.3	A	Definitions	Mandatory	Added to satisfy 12207.1 - 1997
3.0		Management	Mandatory
3.1		Organization	Mandatory	Identify SQA / issuing organization
3.1.1		Quality Element Description	Mandatory
3.1.2.1	A	SQA Project Estimates	Mandatory	Include cost, effort, size, etc. Added to satisfy 12207.1 - 1997
3.1.2.2	A	SQA Independence	Mandatory	Added to satisfy 12207.1 - 1997
3.1.n	A	Organizational Element n	Recommended	List all elements that interact with or approve the SQAP
3.2		Tasks	Mandatory
3.2.1		SQA Task 1	Mandatory
3.2.1.1	A	Life Cycle Portion	Mandatory	Added to satisfy 12207.1 - 1997
3.2.1.2	A	Task Milestones and Schedule	Mandatory	Added to satisfy 12207.1 - 1997
3.2.2		SQA Task n	Mandatory
3.2.2.1	A	Life Cycle Portion	Mandatory	Added to satisfy 12207.1 - 1997
3.2.2.2	A	Task Milestones and Schedule	Mandatory	Added to satisfy 12207.1 - 1997
3.3		Responsibilities	Mandatory
3.3.1		Software Quality Assurance Engineer	Mandatory
3.3.2		Project Software Engineer	Mandatory
3.3.3	A	Customer	Mandatory
3.3.4	A	Project System Engineer	Recommended
3.3.5		Organizational Element n	Recommended
4.0		Documentation	Mandatory
4.1		Purpose	Mandatory
4.1.1		Governing Documentation	Mandatory	Limit to process guidance for SQA
4.1.2		Document Validation	Mandatory	Limit discussion to SQA document validation
4.2	NR	Minimum Documentation Requirements		Omit from SQAP, include content in SPMP
4.2.1	NR	Software Requirements Specification (SRS)		Omit from SQAP, include content in SPMP
4.2.2	NR	Software Design Description (SDD)		Omit from SQAP, include content in SPMP
4.2.3	NR	Software Verification and Validation Plan (SVVP)		Omit from SQAP, include content in SPMP
4.2.4	NR	Software Verification and Validation Report (SVVR)		Omit from SQAP, include content in SPMP
4.2.5	NR	User Documentation		Omit from SQAP, include content in SPMP
4.2.6	NR	Software Configuration Management Plan (SCMP)		Omit from SQAP, include content in SPMP
4.3	NR	Other Documentation		Omit from SQAP, include content in SPMP
4.3.1	NR	Software Development Plan (SPMP)		Omit from SQAP, include content in SPMP
4.3.2	NR	Software and Procedures Manual		Omit from SQAP, include content in SPMP
4.3.3	NR	Software Project Management Plan (SPMP)		Omit from SQAP, include content in SPMP
4.3.4	NR	Software Maintenance Manual (SMM)		Omit from SQAP, include content in SPMP
5.0		Standards, Practices, Conventions And Metrics	Mandatory	Include other SQA S, P, & C not previously discussed in section 4
5.1		Purpose	Mandatory
5.1.1		Application of S, P, C, & M	Mandatory	Limit discussion to SQA
5.1.2		Compliance Verification of S, P, C, & M	Mandatory	Limit discussion to SQA
5.2		Content	Mandatory
5.2.1	NR	Documentation Standards		Omit from SQAP, include content in SPMP
5.2.2	NR	Logic Structure Standards		Omit from SQAP, include content in SPMP
5.2.3	NR	Coding Standards And Conventions		Omit from SQAP, include content in SPMP
5.2.4	NR	Commentary Standards		Omit from SQAP, include content in SPMP
5.2.5		Testing Standards And Practices	Recommended	Limit discussion to SQA
5.2.6		Software Quality Assurance Product Metrics	Mandatory
5.2.7		Software Quality Assurance Process Metrics	Mandatory
6.0		Reviews And Audits	Mandatory
6.1		Purpose	Mandatory
6.1.1		Technical Reviews and Audits	Recommended
6.1.2		Managerial Reviews and Audits	Recommended
6.1.3		Additional Reviews and Audits	Recommended
6.2		Minimum Requirements	Mandatory
6.2.1	M	Software Requirements Review (SRR)	Mandatory	Limit discussion to SQA Involvement, move rest to SPMP
6.2.2	M	Preliminary Design Review (PDR)	Mandatory	Limit discussion to SQA Involvement, move rest to SPMP
6.2.3	M	Critical Design Review (CDR)	Mandatory	Limit discussion to SQA Involvement, move rest to SPMP
6.2.4	M	Software Verification And Validation Plan (SVVP) Review (SVVPR)	Mandatory	Limit discussion to SQA Involvement, move rest to SPMP
6.2.5	M	Functional Audit (FA)	Mandatory	Limit discussion to SQA Involvement, move rest to SPMP
6.2.6	M	Physical Audit (PA)	Mandatory	Limit discussion to SQA Involvement, move rest to SPMP
6.2.7	M	In-Process Audits	Mandatory	Limit discussion to SQA Involvement, move rest to SPMP
6.2.7.1	M	Code Verification Audit	Mandatory	Limit discussion to SQA Involvement, move rest to SPMP
6.2.7.2	M	Interface Specification Audit	Mandatory	Limit discussion to SQA Involvement, move rest to SPMP
6.2.7.3	M	Design Verification Audit	Mandatory	Limit discussion to SQA Involvement, move rest to SPMP
6.2.7.4	M	Test Procedure Functional Audit	Mandatory	Limit discussion to SQA Involvement, move rest to SPMP
6.2.8	M	Managerial Reviews	Mandatory	Limit discussion to SQA Involvement, move rest to SPMP
6.2.9	M	Software Configuration Management Review (SCMPR)	Mandatory	Limit discussion to SQA Involvement, move rest to SPMP
6.2.10	M	Post Mortem Review	Mandatory	Limit discussion to SQA Involvement, move rest to SPMP
6.3	M	Other Reviews and Audits	Mandatory	Limit discussion to SQA Involvement, move rest to SPMP
6.3.n	M	Other Review/Audit n	Mandatory	Limit discussion to SQA Involvement, move rest to SPMP.
6.4	A	Review and Audit Schedules	Mandatory	Added to satisfy 12207.1 - 1997
7.0	NR	Test		Development activity may require other tests. Include here if applicable.
7.1.1	NR	Tests Omitted in SVVP		Development activity may require other tests, such as site acceptance tests. Include here if applicable.
8.0	M	Problem Reporting And Corrective Action	Mandatory	Limit discussion to SQA Involvement, move rest to SCMP
8.1	M	Software Problem Reporting	Mandatory	Limit discussion to SQA Involvement, move rest to SCMP
8.2	M	Software Problem Tracking	Mandatory	Limit discussion to SQA Involvement, move rest to SCMP
8.3	M	Software Problem Resolution	Mandatory	Limit discussion to SQA Involvement, move rest to SCMP
8.4	M	Software Problem Corrective Action	Mandatory	Limit discussion to SQA Involvement, move rest to SCMP
9.0		SQA Tools, Techniques, And Methodologies	Mandatory
9.1		Tools	Mandatory
9.2		Techniques	Mandatory
9.3		Methodologies	Mandatory
10.0	NR	Code Control		Omit from SQAP, include content in SCMP
11.0	NR	Media Control		Omit from SQAP, include content in SCMP
12.0		Supplier Control	Mandatory
12.1		Supplier SQA Provisions	Mandatory
12.2		Management of supplier requirements	Mandatory
12.3		Software Reuse SQA Validation	Recommended
12.4		Supplier SQA Verification	Mandatory
13.0		SQA Records Collection, Maintenance And Retention	Mandatory
13.1		Collection	Mandatory
13.2		Maintenance	Mandatory
13.3		Retention	Mandatory
14.0	M	Training	Mandatory	Limit discussion to SQA activities
14.1		SQAP Training Requirements	Mandatory	Project Team Training
14.2	A	SQA Training	Mandatory	SQA Process Training
15.0		Risk Management	Mandatory

Note: Items highlighted in yellow note discussion points that exist that are not yet resolved.

Software Configuration Management Plan Straw Man – Revision 1

Legend:

A Additions

M Modified

NR Not Required

Section	Changes	Content List	Applicability	Comments
Cover	A	Date of issue and document status	Mandatory	12207.1-1997
Inside Cover	A	SCMP Change History	Mandatory	12207.1-1997
1.0		INTRODUCTION	Mandatory
1.1		Purpose	Mandatory
1.2		Scope	Mandatory
1.2.1		Software items covered	Mandatory
1.2.1.1		Lowest Entity Covered	Recommended
1.2.1.2		Other Entities Covered (e.g. Test or Support S/W)	Recommended
1.2.2		SCM Relationships to Other CM	Mandatory
1.2.3		Life Cycle	Mandatory
1.2.4		Specific Limitations and Constraints	Recommended
1.3		Assumptions	Mandatory
1.3.1		Internal	Recommended
1.3.2		Tools	Recommended
1.3.3		Customer Participation	Recommended
1.4		Acronyms and definitions	Mandatory
1.4.1		Acronyms	Mandatory
1.4.2		Definitions	Mandatory
1.5		References	Mandatory
2.0		SCM MANAGEMENT	Mandatory
2.1		Organization	Mandatory
2.2		SCM Responsibilities	Mandatory
2.2.1		SCM Roles	Mandatory
2.2.1.1		Group 1 (e.g., SCCB)	Mandatory
2.2.1.1.1		Purpose and objectives	Mandatory
2.2.1.1.2		Membership and affiliations	Mandatory
2.2.1.1.3		Period of effectivity	Mandatory
2.2.1.1.4		Scope of authority	Mandatory
2.2.1.1.5		Operational procedures.	Mandatory
2.2.1.2		Group 2 (e.g., Quality Assurance)	Recommended
2.2.1.2.x		As above
2.2.1.3		Role n (e.g. Customer)	Recommended
2.3		Applicable External Plan Policies, Directives, and Procedures	Mandatory
2.4		SCM Risk and Abatement	Mandatory
2.4.1	A	Risk Identification	Mandatory	12207.1-1997
2.4.2	A	Risk Management	Mandatory	12207.1-1997
3.0		SCM ACTIVITIES	Mandatory
3.1		Configuration Identification	Mandatory
3.1.1		Configuration Item Identification	Mandatory
3.1.1.1		Configuration Items	Mandatory
3.1.1.2		Baseline Definition	Mandatory
3.1.2		Configuration Item Naming	Mandatory
3.1.2.1		Documentation	Mandatory
3.1.2.2		Source Code	Mandatory
3.1.2.3		Executable Code	Mandatory
3.1.2.4		Media (e.g. EPROM, Flash, Diskette, PCMCIA,…	Mandatory
3.1.2.5		Subcontracted or Commercial Software Identification	Mandatory
3.1.2.6		Other Configuration Item Identification	Recommended
3.1.3		Configuration Item Acquisition	Mandatory
3.1.3.1		Documentation Acquisition	Mandatory
3.1.3.2		Source Code Acquisition	Mandatory
3.1.3.3		Library and Component Code Acquisition	Mandatory
3.1.3.4		Physical Storage	Mandatory
3.1.3.5		Configuration Item Retention and Recovery	Mandatory
3.1.3.6		Configuration Item Distribution	Mandatory
3.2		Configuration Control	Mandatory
3.2.1		Requesting Changes	Mandatory
3.2.2		Evaluating Changes	Mandatory
3.2.2.1		Change Requests (CR)	Mandatory
3.2.2.2		Requirements Changes	Recommended
3.2.2.3		Change n	Recommended
3.2.3		Approving Changes	Mandatory
3.2.3.1		Change Approval	Mandatory
3.2.3.1.1		Software Configuration Control Board	Mandatory
3.2.3.1.2		Product Configuration Control Board	Recommended
3.2.3.1.3		Document Configuration Control Board	Mandatory
3.2.3.1.4		Other Configuration Control Board	Recommended
3.2.4		Implementing Changes	Mandatory
3.2.4.1		Change Process	Mandatory
3.2.4.2		Release Process	Recommended
3.3		Configuration Status Accounting	Mandatory
3.3.1		SCI Status Accounting	Mandatory
3.3.2		SCI Baseline Accounting	Mandatory
3.4		Configuration Audits and Reviews	Mandatory
3.4.1		Formal SCM Audits	Mandatory
3.4.2		In-process SCM Audits	Mandatory
3.5		Interface Control	Mandatory
3.5.1		Dependencies	Mandatory
3.5.1.1		System	Recommended
3.5.1.2		Hardware	Recommended
3.5.1.3		Support Software	Recommended
3.5.1.4		Other	Recommended
3.5.2		Interface Configuration Control	Mandatory
3.6		Subcontractor and Vendor Control	Mandatory
3.6.1		Third-Party Software	Mandatory
3.6.2		Subcontracted Software Design	Mandatory
3.6.3		Engineering Subcontractors	Recommended
4.0		SCM SCHEDULES	Mandatory
4.1		SCM Sequence and Dependencies	Mandatory
4.2		SCM Milestones and Schedule	Mandatory
5.0		SCM RESOURCES	Mandatory
5.1		Tools	Mandatory
5.1.1		Configuration Management of Tools	Mandatory
5.2		Techniques	Mandatory
5.3		Methodologies	Mandatory
5.4		Personnel	Mandatory
5.5		Training	Mandatory
5.6	A	Environment and Infrastructure	Mandatory	12207.1-1997
5.7	A	SCM Cost Management	Recommended	12207.1-1997
6.0		SCMP MAINTENANCE	Mandatory
6.1		SCMP Monitoring	Mandatory
6.2		SCMP Revision and Approval	Mandatory
6.3		SCMP Change Distribution and Training	Mandatory

Software Requirements Traceability Matrix

Definition of a Requirement

As per IEEE Std 610.12-1990, A requirement is defined as a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. Desirable qualities of requirements include the following:

· Correct – Each requirement should be stated without error

· Complete – The set of requirements are considered to be complete when if all possible states, state changes, inputs, products and constraints are described by some requirement.

· Consistent – There should be no conflicting or ambiguous requirements

· Realistic – can the requirement actually be implemented

· Verifiable – A test must be able to be written that demonstrates that the requirement has been met

· Traceable – Each system function must be traced to a set of requirements that mandates it.

System requirements are obtained from any or all of the following customer artifacts:

· Statement of Work (SOW)

· Change Requests

· Customer Meeting Minutes

· Operations Requirements Documents (ORD)

· Proposal/Request For Proposal (RFP)

During System Requirements Analysis and System Architectural Design the system level requirements are analyzed. The system requirements are then documented in the System/Subsystem Requirements Specification (SSS). The SSS:

· Contains the System Level Requirements

· Defines the overview of the system’s behavior

· Includes the requirements for hardware, software, program management, operators and networks, etc.

Also during this timeframe, the system analyst creates a Requirements Traceability Matrix (RTM) that allocates all requirements into categories such as the following: hardware, software, documentation, quality assurance, testing, project management, etc.

Definition of the SRTM

The Software Requirements Traceability Matrix (SRTM) is a tool that will be used to trace software requirements back to the Source Document(s) and forward to the software requirements, software design and software test documents. The software requirements are derived from the System Requirements Analysis and System Design activity. Only those requirements, which have been allocated to software will be carried through to the SRTM.

Add text here to address COTS, MOTS, and legacy code

Source Document Reference

Source Requirement Description

SRS / IRS Reference

SDD / IDD / DBDD Reference

Software Test Procedure

Other Reference /

Comments

Parent document identifier and specific section number (and paragraph number if necessary) (lowest resolution possible) of the requirement that was assigned to software during the System Requirements Analysis and System Design.

Description of the requirement from the parent document (summary or complete text)

The unique requirement identifier and document identifier (SRS / IRS) for this software requirement.

The design entity(ies) identifier(s) and document identifier (SDD / IDD / DBDD) for the design which implements this software requirement.

The software test procedure identifier(s) for the tests which validate this software requirement.

References to other documents or additional comments

DEFINITION OF EACH COLUMN:

Source Document Reference

This column shall contain a backward reference to appropriate Source Document and the specific section from which this requirement was derived. The Source Document may be the Scope of Work, the Operations Requirement Document, the Request for Proposal, the System Specification, etc. The section reference should provide a reference to each sentence within the Source Document that represents a software requirement.

Source Requirement Description

This column shall contain either the exact requirement text from the Source Document or shall contain an abbreviated description of the requirement. The content of this column shall be defined by the Authority having jurisdiction. When deciding whether to break a statement into individual requirements, the analyst should consider how the requirement would be tested. If the requirement will be tested by a single test procedure, then the requirement probably does not need to be broken down further. If the requirement will be tested by multiple test procedures, then the requirement should be broken down into multiple requirements. It is important to follow a consistent and documented methodology for breaking down requirements.

SRS/IRS Ref.

The software supplier may elect to create an IRS in addition to the SRS. This column shall contain a forward reference to the document identifier (SRS/IRS) and a requirement identifier within the document. All software requirements must be mapped to one or more section(s). The reference to the SRS/IRS section number shall correspond to the lowest level of detail defined within the SRS/IRS Table of Contents.

SDD/IDD/DBDD Ref.

The software supplier may elect to create an IDD and/or DBDD in addition to the SDD. According to IEEE Std 1016, “In a complete SDD, each requirement must be traceable to one or more design entities... Entities can exist as a system, subsystems, data stores, modules, programs and processes.” This column shall contain a forward reference to the document identifier (SDD/IDD/DBDD) and a unique reference to one or more design entity(ies).

Software Test Procedure

This column will provide a forward reference to the Software Test Procedure identifier in which this software requirement will be validated.

Other Reference/Comments

This column will provide references to other documents or free-form comments as necessary.

EXAMPLES

This section will address different ways of viewing the information contained in an SRTM.

Source Document Reference	Source Requirement Description	SRS / IRS Reference	SDD / IDD / DBDD Reference	Software Test Procedure	Other Reference / Comments
Springfield TS 17XB.1.3-12	The automatic restoration mode shall be the default mode of operation.	CDRL010-SRS-0567	CDRL008 -HLSDS -0144	CDRL021 & 019 TEST FAT 03-02-01-03-1
Springfield TS 17XB.1.3-7	An authorized user shall be able to place each FCU individually into either a manual or automatic restoration mode.	CDRL010-SRS-0567	CDRL008 -HLSDS -0144	CDRL021 & 019 TEST FAT 03-02-01-03-1

ES-3.1.3	External Output Signals
ES-3.1.3.1	Speedometer	SRS-P-3.2.1.3.10
ES-3.1.3.2	Odometer	SRS-P-3.2.1.3.9
ES-3.1.3.3	Sanding Control	SRS-P-3.2.1.3.19
ES-3.1.3.4	Propulsion Fault
ES-3.1.3.5	Dynamic Brake Fault
ES-3.1.3.6	Ventilation Fault	SRS-P-3.2.1.2.20
ES-3.1.3.7	Maintenance Required Fault	SRS-P-3.2.1.2.15

here’s another example: note that document identifier is in the column header. In this example there is no IRS, and there is only one SRS.

Subsystem SFD Ref. 999-ABC-0000	Requirements Description (From SFD)	SRS Ref. 999-ABC-xxxx	SDD Ref. 999-ABC-xxxx	Software Test Procedure(s) 999-ABC-xxxx	Comments
	Interfaces
7.2, 8	Serial	0004 - 3.1.1	0005 - 6.2	0042 - 9.1.7, 9.1.8
7.2, 8	Digital Module Interface	0004 - 3.1.2.1	0005 - 6.2	0042 - 9.1.9
7.2, 8	Slave B	0004 - 3.1.3	0005 - 6.2	0042 - 9.2.8
7.2, 8	Slave P	0004 - 3.1.4	0005 - 6.2	0042 - 9.1.10, 9.1.11
7.2, 8	SPI HMM	0004 - 3.1.5.1	0005 - 6.2	0042 - 9.1.12
7.2, 8	SPI RTC	0004 - 3.1.5.2	0005 - 6.2	0042 - 8.2.1
7.2, 8	LVDT Signal	0004 - 3.1.6	0005 - 6.2	0042 - 9.1.4
7.2, 8	Sensor Power Supply	0004 - 3.1.7	0005 - 6.2	0042 - 9.3.2.2, 9.4.2.2
7.2, 8	Self test push button	0004 - 3.1.8	0005 - 6.2	0042 - 9.1.6
7.2, 8	Fault Status Indicator	0004 - 3.1.9	0005 - 6.2	0042 - 9.1.6, 7.8