IEEE WG 12 Software Meeting
10
May 31, 2001
Draft Meeting Minutes
The
tenth meeting of the working group was held on May 16 and 17, 2001 at the LTK
offices in Ambler, PA.
The
agenda was discussed and agreement reached.
(wg12agn10.doc)
No action was taken to approve the meeting minutes from meeting 09 as the minutes were not distributed in time for a through review.
1. Software Requirements Traceability Matrix Lori Karr
A document (attached) was distributed and reviewed by the group. The following comments and direction were established.
Every requirement in the SRS shall appear in the SRTM.
Each requirement shall have a unique identifier.
The project management plan shall how requirements are managed and controlled including the identifier structure.
The matrix shall include the technical requirements
SRTM column changes are as follows:
Column 1 &2 are combined Source Document Reference. Specific reference within the source document shall be provided.
Column 3 heading shall be changed to Source Requirement Description. This description
Column 4 change heading shall be “SRS/IRS Identifier”.
Column 5 change heading shall be “SDD/IDD/DB/DD Identifier”.
Column 6 change heading shall be “Code Identifier”.
Column 4, 5 and 6 shall be a unique identifier.
A sample SRTM was presented by Bombardier and provided as a separate document.
Show different views of the SRTM and make a recommendation of the position to be used in the within the standard. Participants are L. Karr, F. Ouellette and P. Jamieson. Tentative date: June 26th
Updated SRTM to be
prepared for next meeting. - L. Karr
2. Software Configuration Management Plan John Corvin
A document (attached) was distributed and reviewed by the group. The following comments and direction were established.
IEEE 12207.1 specifies section 5.7 SCM Cost shall be included. Consideration needs to be given to replacing cost with resource allocation.
Review 12207 and update
the SCMP requirements for the next meeting. - J. Corvin
3.
Software
Project Management Plan Shanti
Morar
A document (attached) was distributed and reviewed
by the group. The following comments
and direction were established.
Content diagram and functional elements shall appear
in section 1.1.1 purpose, scope and objectives.
Project Deliverables (section 1.1.3) shall include
all work products. Work products that
are deliverable to the acquirer shall be clearly identified. The title shall be changed to “Project Work
Products”.
Reference documents shall be identified but the
revision level is not required. A
change control process shall be addressed in the SCMP.
Review 12207 and update the SPMP requirements for
the next meeting. – S. Morar
4.
General
Comments
Each section straw man including revision level to
be posted on the website for review and comment. - P. Jamieson
The question arose of having our standard specify
that the planning documents should be separate (vs integrated in one document
or combined in some way). The documents
under consideration are
the SQAP, SCMP, SPMP, and SVVP. Some reasons for keeping them separate were
discussed. These are as follows:
a) Audiences - the audiences of each plan may be
slightly different.
b) Opportunities for reuse. In practice, once one of these documents is
created, it is likely that, from project to project, the basic information will
remain the same, with only project specific information changing.
c) Consistency - one of the aims of creating this
standard is to encourage consistency in documentation from different suppliers,
and consistency in the expectations of the customer.
d) Two principles from software design - when
designing a code module, the preference is for high cohesion and well defined
coupling. For documents, cohesion
carries the idea that the document should focus on one specific area (e.g. SQA
or SCM), and be internally cohesive and consistent. Coupling between documents should be limited to pointers from one
document to the other, and not necessarily repeating the same information in
two documents.
Action
Item Review Paul
Jamieson
Action items were assigned and reviewed.
(wg12ail10.doc)
The
next working group meeting will be on August 14 & 15, 2001 at location to
be determined (East Coast).
The
meeting was adjourned on May 17 at 2:30 PM
The
following information distributed at the meeting appears on the following
pages:
Software
Requirements Traceability Matrix (SRTM) Outline
Software
Configuration Management Plan (SCMP) Outline
Software
Project Management Plan (SPDP) Outline
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 derived from the Requirements Traceability
Matrix, which is generated during System
Requirements Analysis and System Architectural Design. Only those requirements, which have been
allocated to software will be carried through to the SRTM. The SRTM shall
provide mapping back to the system level requirements defined in System/Subsystem
Requirements Specification (SSS) or in the Contract Documents if an SSS was not
created. The SRTM shall provide mapping
forwards to the SRS/IRS, SDD/IDD/DBDD, and
Software Test Procedures.
|
Software Requirement Number |
SSS Section or Contract Document(s) (backward
reference) |
Software Requirement Text |
SRS/IRS Ref. (forward reference) |
SDD/IDD/DBDD Ref. (forward
reference). |
Code Ref. (forward reference) |
Software Test Procedure |
Other Ref/ Comments |
|
Unique number that was assigned to the software requirement during
System Requirements Analysis and System Architectural Design. Is derived from the Technical
Specification |
The document name (SSS or Contract Document) and section within the
document in which this software requirement is addressed |
Specific software requirement text from the SSS or Contract Document |
The document name (SRS/IRS) and section within the document in which
this software requirement is addressed |
The document name (SDD/IDD/DBDD) and the design entity(ies) that
implement this software requirement |
The module or object name
that implements this software requirement |
The Software Validation
Test Procedure in which this software requirement is tested. |
References to other documents or free-form comments |
DEFINITION OF EACH COLUMN:
Software Requirement Number:
Each software requirement shall be uniquely numbered. The numbering
system shall consist of a prefix that that denotes the source document from
which this requirement was derived (e.g. SOW, ORD, RFP), followed by a ‘-‘ and
a suffix which denotes the section within the source document from which this
requirement was derived (e.g. 1.01, 4.2). If there are multiple requirements
identified within a section, then each requirement number shall be uniquely
identified with an additional suffix of ‘-‘ followed by a sequential number
starting at 1. The sequential number will restart at 1, within each
section. The following are examples:
SOW-1.01-1
SOW-1.01-2
SOW-1.01-3
SOW-1.02-1
SOW-1.02-2
SSS Section or Contract Document
section
This column shall contain a backward reference to appropriate system
level documentation and the section from which this requirement was
derived. It is assumed that the
supplier has created an SSS and that the software requirements have been
allocated via the RTM.
In the instance that the supplier has not created an SSS or equivalent
system level documentation, then this column shall map back to the Contract
Document (SOW, ORD, RFP) from which this requirement was derived.
The reference to the SSS section number shall correspond to the lowest
level of detail defined within the source document Table of Contents. (can this or should this be
defined further???)
Software Requirement Text:
This column shall contain the software requirement text, which has been extracted from the source document. During the Software Requirements Analysis activity the software analyst shall enter each software requirement into the RTM. Each software requirement shall possess the qualities identified in the “Definition of a Requirement” section within this document. 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.
This column shall contain a forward reference to the document name
(SRS/IRS) and section within the document in which this software requirement is
addressed.
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. (can this or should this be defined further???
Also, will the SRS contain references to the requirement number within the SRS
text?)
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 name (SDD/IDD/DBDD) and one or more design
entity(ies). The reference should denote the section number of the design
entity in which the software requirement is addressed.
The Visio Diagram shows that
we are to provide mapping to the Software Architectural Design and the Software
Detailed Design. I am assuming that the
mapping will not change between these 2 design documents, if we continue to map
to the design entity level. The
information described for each design entity will change among the two
documents, but the mapping will not.
Code Ref.
This column shall contain a forward reference to the module name or
object name that implements this software requirement. (Verify with the team whether we want to map to
code).
Software Test Procedure
(Need to verify with the
team to what level we want to what level we want to map the tests. Unit,
Integration, Validation, Qualification).
This column will provide a forward reference to the Software Validation
Test Procedure identification number in which this software requirement will be
tested.
Other Ref/Comments
This column will provide references to other documents or free-form
comments as necessary.
REPORTS
This section will address reports that are required to be generated as output from the SRTM.
Software Configuration Management Plan
Consider:
IEEE 828 specifies the following:
SCM planning information may be presented in any format, sequence, or location that is meaningful to the intended users of the Plan with the following restrictions:
a) A document with the title “Software Configuration Management Plan”
shall exist either in stand-alone form or embedded in
another project document. Suggest
Rail Transit require a separate SCMP.
b) This document shall contain all SCM planning information either by inclusion or by reference to other locations, such as other documents or automated systems.
c) A format for this document shall be defined.
The writer of the Plan shall use
the sequence of sections specified in 828 Table 1 unless a different format has
been defined in the Introduction of the Plan.
Suggest we require sections as defined in Table 1.
As such, the following sections are proposed:
|
Section |
SCMP Content List |
Applicable to Railway Software Standards |
Amendments For Railway Software Standards |
|
Cover |
Date of issue and
document status |
Mandatory |
12207.1-1997 |
|
Inside Cover |
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 |