ISMI Requirements Identification

1
ISMI Requirements Identification

• e-Manufacturing Workshop
• July 20, 2007
• Charisse Nabors

Advanced Materials Research Center, AMRC,
International SEMATECH Manufacturing Initiative,
and ISMI are servicemarks of SEMATECH, Inc.
SEMATECH, the SEMATECH logo, Advanced Technology
Development Facility, ATDF, and the ATDF logo are
registered servicemarks of SEMATECH, Inc. All
other servicemarks and trademarks are the
property of their respective owners .
2
Overview

• Background
• Requirements Infrastructure
• Anatomy
• Unique Identification
• ISMI Activity

3
Background

• History
• Standards are complex and they interact
• Suppliers customers do not agree about the
  requirements, because of interpretation
• Individuals come up with different
  interpretations
• Issue Requirements are not always clear in
  standards and guidelines
• ISMI is taking action to address this

4
ISMI Action

• We are going to identify specific requirements in
  standards and guidelines
• Attempting to conform to SITF guidelines
• We are going to try and take into account the 3
  different user communities
• Supplier who has to implement it
• IC maker who is the end user
• Test to evaluate conformance
• Objective requirements should make it easier and
  less costly

5
Requirements Infrastructure

• Capability
• A grouping of requirements that pertains to a
  functional area
• Hierarchy
• Parent In a collection of requirements for a
  functional component, a requirement that has
  other requirements below it. A Parent has one or
  more Child requirements and can itself be a
  Child.
• Child Describes a sub-component within a
  functional component. A Child requirement can
  belong to only one Parent and can itself be a
  Parent.

6
Requirements Infrastructure

• Properties
• An attribute of a requirement that needs to be
  proven to meet the requirement. A Property can
  belong to only a single base requirement.
• Additional information
• Expected results, linkages, protocol mapping

7
Anatomy of a Requirement

• Source of requirement
• Document
• Stated, Inferred, Relationship
• Type of requirement
• Mandatory
• Conditional
• Criteria
• Chosen by supplier
• Method of execution
• Basic
• Selectable
• Criteria (global or transient)
• Chosen by end user/IC maker

8
Unique Identification

• REQUIREMENT NOTATION
• specowner-specid-RQx-nnnnn-YY-rrr
• e.g., SEMI-E040.00-RQS-00001-MB-000
• Where
• specowner Acronym of organization that produced
  the specification
• specid Specification identifier (version is not
  included)
• RQ Indicates that this is a requirement
  identifier
• x Indicates the Req Found value
• 'S Stated
• 'I Inferred
• 'R Relationship
• nnnnn Unique requirement number within this
  specification for this requirement owner
• YY Indicates the Req Type value
• MB Mandatory Basic
• CB Conditional Basic
• MS Mandatory Selectable
• CS Conditional Selectable
• rrr Requirement version number
• 000 is the first version

9
Unique Identification

• PROPERTY NOTATION
• specowner-specid-RPx-nnnnn-ss-rrr
• e.g., SEMI-E040.00-RPS-00001-01-000
• Where
• specowner Acronym of organization that produced
  the specification
• specid Specification identifier (version is not
  included)
• RP Indicates that this is a property identifier
• x Indicates the Req Found value
• 'S Stated
• 'I Inferred
• 'R Relationship
• nnnnn Number of the requirement to which this
  property belongs
• ss Property sequence number
• 01 is the first sequence number
• rrr Property version number
• 000 is the first version

10
Unique Identification

• Issues encountered
• Needed to extend beyond SITF (Standards
  Improvement Task Force) process
• Different sections of same standard do not align
  with each other
• Standards calling for protocol formats that are
  not specified in protocol definition
• Requirements identified that are only in
  diagrams, not in written text
• Sometimes text and diagrams do not match
• Will feed issues found back to appropriate SEMI
  task forces

11
ISMI Activity

• Keep results as ISMI intellectual property (IP)
• Create objective list of requirements that can be
  commonly agreed to
• Seek consensus endorsement from member companies
• Provide traceability for Advanced Software
  Testers (ASTs)
• Make requirements lists available to public while
  remaining ISMI IP

12
Example
13
Summary

• ISMI pursues clarifying document requirements
• Requirements are identified to the atomic level
• Include properties of each requirement
• Requirements lists to be made available to
  public, while remaining ISMI IP
• Questions?