IEEE WG 12 Software Meeting 11

August 16, 2001

Meeting Minutes – Approved

The eleventh meeting of the working group was held on August 14 and 15, 2001 at the Port Authority Transit offices in Pittsburgh, PA.

The meeting was called to order on August 14, 2001 at 9:30 AM

Participants

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

Agenda

The agenda was revised to correct the correct standard number. See attachment.

Minutes

The committee approved the minutes from meeting 09 and 10. The final meeting minutes will be posted on the website.

Standard Number Correction

The correct standard number is P1558 not P1588. The website has been updated by Tom Sullivan. A clerical error was made when the number was originally distributed.

Assignment Reports

1. P1558 Feasibility Usage by NYCT (08.07) Tibor Simon

NYCT referenced the draft standard in the R160 car procurement technical specification. As the car procurement award has been postponed until the first quarter 2002. This time frame matches the completion of the standard. George Hacken made this report.

2. Standard Reference Listing (09.01) Paul Jamieson

The reference standard listing document was revised to correct the ATA 102 status and spelling corrections. The listing was emailed on 05/31/01.

3. Standard Documents in PDF (09.02) John Corvin

PDF files of various reference documents were distributed to the meeting attendees. These files include some DOD documents.

4. Process Flow Diagram (09.04) Paul Jamieson

The process flow diagram was revised to include reference to safety activities that are outside the scope of this standard. The diagram was emailed on 05/24/01.

5. Outline Postings and Comments (10.05) Paul Jamieson

All document outlines (strawman) were forwarded on 08/10/01 for posting on the website for comment. The outline authors received a copy of the email.

6. SRTM – Software Requirements (10.01) Lori Karr

The task force met on July 18, 2001 and developed the SRTM outline.

7. SRTM Outline Review (10.02) Lori Karr

Lori Karr presented the revised outline from the July meeting.

The parent-child relationship is maintained starting with the SRS document and maintained through testing. If the parent –child relationship needs to be maintained to the source document with 100% traceability. The authority having jurisdiction shall specify that the traceability shall be implemented.

The requirement description shall be provided as a summary or complete text as defined by the authority having jurisdiction.

The outline was revised during the meeting and the revision is attached.

8. SPMP Outline Review (10.04) Shanti Morar

Discussed the outline revision and no changes were made. Concerns were expressed that the budget should not be stated as dollars but as hours.

9. SCMP Outline Review (10.03) John Corvin

No comments were received to the outline presented at the last meeting.

10. STP, STPr & STR Outline Review Denise Edgecomb -Cope

A review of the STP and SVVP were reviewed for potential combination of the related activities. The SVVP will call the STP. Therefore, the two documents need to exist as separate items.

The process flow diagram was revised to recognize that tests and results are an artifact of the software code and test, and software integration activities.

11. Maintenance Document Graphics (09.05) Tom Tougas

No report was provided.

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

No report was provided.

13. Software Item Definition (06.01) Paul Jamieson

These definitions were discussed and will be incorporated into the standard based that J-Std-016 is no longer support.

software item

An aggregation of software, such as a computer program or database, that satisfies an end use function and is designated for purposes of specification, qualification testing, interfacing, configuration management, or other purposes. Software items are selected based on tradeoffs among software function, size, host or target computers, developer, support strategy, plans for reuse, criticality, interface considerations, need to be separately documented and controlled, and other factors. A software item is made up of one or more software units.

Note: This definition was taken from J-Std-016.

software unit

An element in the design of a software item; for example, a major subdivision of a software item, a component of that subdivision, a class, object, module, function, routine, or database. Software units may occur at different levels of a hierarchy and may consist of other software units. Software units in the design may or may not have a one-to-one relationship with the code and data entities (routines, procedures, databases, data files, etc.) that implement them or with the computer files containing those entities.

Note: This definition was taken from J-Std-016.

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

No report was provided.

Draft Standard Review (09.06) Paul Jamieson

Tables for each document will appear in the normative annex of the standard. An example follows:

Section	Changes	Content List	Applicability	Comments
Cover	A	Date of issue and document status	Mandatory	Added to satisfy requirements of IEEE 12207
Inside Cover	A	SQAP Change History	Mandatory	Added to satisfy requirements of IEEE 12207
1.0		Purpose	Mandatory
1.6		SQA Life Cycle	Recommended
1.1.3	M	Project Work Product	Mandatory	The content list title was renamed.
1.1.3.1	A	Work Products		This sub-clause shall state all the work products produced using this plan. It shall summarize when each of the work products is produced.
1.1.3.2	A	Deliverable Work Products		This sub-clause shall identify software products delivered to the customer and any specific or special requirements for these documents (Format, Content, Schedule, Acquirer Approval, etc.)
5.2.1	NR	Documentation Standards		Removed since content is included in SPMP.
5.2.5		Testing Standards And Practices	Recommended

Legend:

A Additions

M Modified

NR Not Required

The authors of each outline will revise their respective documents to this format.

Action Item Review Paul Jamieson

Action items were assigned. (wg12ail12.doc)

Next Meeting

The working group meeting 12 will be on October 23 and 24, 2001 at New York City Transit – Brooklyn, NY.

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

Adjournment

The meeting was adjourned on August 15, 2001 at 1:45 PM

Attachments

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

Agenda – separate file (wg12agn11.doc)

Roster – separate file (wg12roster.xls)

Software Requirement Traceability Matrix version 02

Process Flow Diagram 03 – separate file (process flow 03.doc)

Action Item Listing – separate file (wg12ail11.xls)

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 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