Work product identifier

Work product characteristics

• Item which is maintained under configuration control:
  • may include components, subsystems, libraries, test cases, compilers, data, documentation, physical media, and external interfaces
• Version identification is maintained
• Description of the item is available including the:
  • type of item
  • associated configuration management library, file, system
  • responsible owner
  • date when placed under configuration control
  • status information (i.e., development, baselined, released)
  • relationship to lower level configured items
  • identification of the change control records
  • identification of change history

• Integrated software consisting of:
  • source code
  • software elements
  • executable code
  • configuration files
• Documentation, which:
  • describes and identifies source code
  • describes and identifies software elements
  • describes and identifies configuration files
  • describes and identifies executable code
  • describes software life-cycle status
  • describes archive and release criteria
  • describes compilation of software units
  • describes building of software item

• An aggregate of software items
• A set of executables for a specific ECU configuration and possibly associated documentation and data

• Name
• Description
• Value domain, threshold values, characteristic curves
• Owner
• Means of data application (e.g. flashing interfaces)
• If necessary a grouping/a categorization:
  • name of the category/group/file name
  • description
• Actual value or characteristic curve applied

• Defines what is to be purchased or delivered
• Identifies time frame for delivery or contracted service dates
• Identifies any statutory requirements
• Identifies monetary considerations
• Identifies any warranty information
• Identifies any copyright and licensing information
• Identifies any customer service requirements
• Identifies service level requirements
• References to any performance and quality expectations / constraints / monitoring
• Standards and procedures to be used
• Evidence of review and approval
• As appropriate to the contract the following are considered:
  • references to any acceptance criteria
  • references to any special customer needs (i.e., confidentiality requirements, security, hardware, etc.)
  • references to any change management and problem resolution procedures
  • identification of any interfaces to independent agents and subcontractors
  • identification of customer's role in the development and maintenance process
  • identification of resources to be provided by the customer

• Signed off by all parties involved in the commitment / agreement
• Establishes what the commitment is for
• Establishes the resources required to fulfill the commitment, such as:
  • time
  • people
  • budget
  • equipment
  • facilities

• Result of applying a measure

• Results of measurement of current performance that allow comparison against historical or target values
• Relates to key goals / process / product / market need criteria and information to be benchmarked

• Determines levels of customer satisfaction with products and services
• Mechanism to collect data on customer satisfaction:
  • results of field performance data
  • results of customer satisfaction survey
  • interview notes
  • meeting minutes from customer meetings

• Data comparing process performance against expected levels
• Defined input and output work products available
• Meeting minutes
• Change records
• Task completion criteria met
• Quality criteria met
• Resource allocation and tracking

• Describes the overall product / system structure
• Identifies the required product / system elements
• Identifies the relationship between the elements
• Consideration is given to:
  • any required performance characteristics
  • any required interfaces
  • any required security characteristics

• Identified domain model(s) tailored from
• Identified asset specifications
• Definition of boundaries and relationships with other domains (Domain Interface Specification)
• Identification of domain vocabulary
• Identification of the domain representation standard
• Provide an overview of the functions, features capabilities and concepts in the domains

• Must provide a clear explanation and description, on usage and properties, for reuse purposes
• Identification of the management and structures used in the model

• Describes the overall software structure
• Describes the operative system including task structure
• Identifies inter-task/inter-process communication
• Identifies the required software elements
• Identifies own developed and supplied code
• Identifies the relationship and dependency between software elements
• Identifies where the data (such as application parameters or variables) are stored and which measures (e.g. checksums, redundancy) are taken to prevent data corruption
• Describes how variants for different model series or configurations are derived
• Describes the dynamic behavior of the software (Start-up, shutdown, software update, error handling and recovery, etc.)
• Describes which data is persistent and under which conditions
• Consideration is given to:
  • any required software performance characteristics
  • any required software interfaces
  • any required security characteristics required
  • any database design requirements

• Provides detailed design (could be represented as a prototype, flow chart, entity relationship diagram, pseudo code, etc.)
• Provides format of input / output data
• Provides specification of CPU, ROM, RAM, EEPROM and Flash needs
• Describes the interrupts with their priorities
• Describes the tasks with cycle time and priority
• Establishes required data naming conventions
• Defines the format of required data structures
• Defines the data fields and purpose of each required data element
• Provides the specifications of the program structure

design

• Provides an overview of all system design
• Describes the interrelationship between system elements
• Describes the relationship between the system elements and the software
• Specifies the design for each required system element, consideration is given to things like:
  • memory / capacity requirements
  • hardware interfaces requirements
  • user interfaces requirements
  • external system interface requirements
  • performance requirements
  • commands structures
  • security / data protection characteristics
  • settings for system parameters (such as application parameters or global variables)
  • manual operations
  • reusable components
• Mapping of requirements to system elements
• Description of the operation modes of the system components (startup, shutdown, sleep mode, diagnosis mode, etc.)
• Description of the dependencies among the system components regarding the operation modes
• Description of the dynamic behaviour of the system and the system components

• Identifies the objective to be achieved
• Identifies who is expected to achieve the goal
• Identifies any incremental supporting goals
• Identifies any conditions / constraints
• Identifies the timeframe for achievement
• Are reasonable and achievable within the resources allocated
• Are current, established for current project, organization
• Are optimized to support known performance criteria and plans

Takes account of:

• Identifies:
• external documents
• internal documents
• current site distribution and maintenance list maintained
• Documentation kept synchronized with latest product release
• Addresses technical issues

• audience and task profiles

• the environment in which the information will be used

• convenience to users

• the range of technical facilities, including resources and the product, available for developing and delivering on-screen documentation

• information characteristics

• cost of delivery and maintainability

• product and version information

• instructions for handling the system

• initial familiarisation information

• long examples

• structured reference material, particularly for advanced features of the software

• checklists

• guides to use input devices

• Defines the tasks to perform in handling and storing products including:
  • providing for master copies of code and documentation
  • disaster recovery
  • addressing appropriate critical safety and security issues
• Provides a description of how to store the product including:
  • storage environment required
  • the protection media to use
  • packing materials required
  • what items need to be stored
  • assessments to be done on stored product
• Provides retrieval instructions

• Updated and available for new releases
• Coverage of system, application, operations, maintenance as appropriate to the application
• Courses listings and availability

• Understood by those expected to use them
• Provides value to the organization / project
• Non-disruptive to the work flow
• Appropriate to the process, life cycle model, organization:
  • is accurate
  • source data is validated
  • results are validated to ensure accuracy
• Has appropriate analysis and commentary to allow meaningful interpretation by users

• Identification of customer and customer information
• Date requested
• Target date for responses
• Identification of associated hardware / software / product configuration
• Ability to record feedback

• Measures attributes of the performance of system's operation at field locations, such as:
  • field defects
  • performance against defined service level measures
  • system ability to meet defined customer requirements
  • support time required
  • user complaints (may be third party users)
  • customers requests for help
  • performance trends
  • problem reports
  • enhancements requested

• Real time measures of personnel performance or expected service level
• Identifies aspects such as:
  • capacity
  • throughput
  • operational performance
  • operational service
  • availability

• Measures about the process' performance:
  • ability to produce sufficient work products
  • adherence to the process
  • time it takes to perform process
  • defects related to the process
• Measures the impact of process change
• Measures the efficiency of the process

• Monitors key processes and critical tasks, provides status information to the project on:
  • project performance against established plan
  • resource utilization against established plan
  • time schedule against established plan
  • process quality against quality expectations and/or criteria
  • product quality against quality expectations and/or criteria
  • highlight product performance problems, trends
• Measures the results of project activities:
  • tasks are performed on schedule
  • product's development is within the resource commitments allocated
• References any goals established

Measures quality attributes of the work products defined:

• functionality
• reliability
• usability
• efficiency
• maintainability
• portability
• Measures quality attributes of the "end customer" product quality and reliability

NOTE: Refer ISO/IEC 9126 for detailed information on measurement of product quality.

• Identifies the probability of risk occurring
• Identifies the impact of risk occurring
• Establishes measures for each risk defined
• Measures the change in the risk state

• Real time measures taking while a system is operational, it measures the system's performance or expected service level
• Identifies things like:
  • capacity
  • throughput
  • operational performance
  • operational service
  • service outage time
  • up time
  • job run time

• Identifies what objectives or goals there are to be satisfied
• Establishes the options and approach for satisfying the objectives, or goals
• Identification of the plan owner
• Includes:
  • the objective and scope of what is to be accomplished
  • assumptions made
  • constraints
  • risks
  • tasks to be accomplished
  • schedules, milestones and target dates
  • critical dependencies
  • maintenance disposition for the plan
• Method / approach to accomplish plan
• Identifies:
  • task ownership, including tasks performed by other parties (e.g. supplier, customer)
  • quality criteria
  • required work products
• Includes resources to accomplish plan objectives:
  • time
  • staff (key roles and authorities e.g. sponsor)
  • materials / equipment
  • budget
• Includes contingency plan for non-completed tasks
• Plan is approved

• Defines or references the procedures to control changes to configuration items
• Defines measurements used to determine the status of the configuration management activities
• Defines configuration management audit criteria
• Approved by the configuration management function
• Identifies configuration library tools or mechanism
• Includes management records and status reports that show the status and history of controlled items
• Specifies the location and access mechanisms for the configuration management library
• Storage, handling and delivery (including archival and retrieval) mechanisms specified

• Defines:
  • work products to be developed
  • life cycle model and methodology to be used
  • customer requirements related to project management
  • project resources
• Milestones and target dates
  • estimates
  • quality criteria
  • processes and methods to employ
  • contingency actions

• Objectives / goal for quality
• Defines the activities tasks required to ensure quality
• References related work products
• References any regulatory requirements, standards, customer requirements
• Identifies the expected quality criteria
• Specifies the monitoring timeframe and quality checkpoints for the defined life cycle and associated activities planned
• Defines the methods of assuring quality
• Identifies the quality criteria for work products and process tasks
• Specifies the threshold/tolerance level allowed prior to requiring corrective actions
• Defines quality measurements and timing of the collection
• Specifies mechanism to feed collected quality record back into process impacted by poor quality
• Defines the approach to guaranteeing objectivity
• Approved by the quality responsible organization/function:
  • identifies escalations opportunities and channels
  • defines the cooperation with customer and supplier QA

• Identifies what is to be recovered:
  • procedures / methods to perform the recovery
  • schedule for recovery
  • time required for the recovery
  • critical dependencies
  • resources required for the recovery
  • list of backups maintained
  • staff responsible for recovery and roles assigned
  • special materials required
  • required work products
  • required equipment
  • required documentation
  • locations and storage of backups
  • contact information on who to notify about the recovery
  • verification procedures
  • cost estimation for recovery

• Identifies the functionality to be included in each release
• Identifies the associated elements required (i.e., hardware, software, documentation etc.)
• Mapping of the customer requests, requirements satisfied to particular releases of the product

• Defines the policy about what items to be reused
• Defines standards for construction of reusable objects:
  • defines the attributes of reusable components
  • quality / reliability expectations
  • standard naming conventions
• Defines the reuse repository (library, CASE tool, file, data base, etc.)
• Identifies reusable components:
  • directory of component
  • description of components
  • applicability of their use
  • method to retrieve and use them
  • restrictions for modifications and usage
• Method for using reusable components
• Establishes goal for reusable components

• Defines:
  • what to be reviewed
  • roles and responsibilities of reviewers
  • criteria for review (check-lists, requirements, standards)
  • expected preparation time
  • schedule for reviews
• Identification of:
  • procedures for conducting review
  • review inputs and outputs
  • expertise expected at each review
  • review records to keep
  • review measurements to keep
  • resources, tools allocated to the review

• Project risks identified and prioritized
• Mechanism to track the risk
• Threshold criteria to identify when corrective action required
• Proposed ways to mitigate risks:
  • risk mitigator
  • work around
  • corrective actions activities / tasks
  • monitoring criteria
  • mechanisms to measure risk

• Planned risk treatment activities and tasks:
  • describes the specifics of the risk treatment selected for a risk or combination of risks found to be unacceptable
  • describes any difficulties that may be found in implementing the treatment
• Treatment schedule
• Treatment resources and their allocation
• Responsibilities and authority:
  • describes who is responsible for ensuring that the treatment is being implemented and their authority
• Treatment control measures:
  • defines the measures that will be used to evaluate the effectiveness of the risk treatment
• Treatment cost
• Interfaces among parties involved:
  • describes any coordination among stakeholders or with the project’s master plan that must occur for the treatment to be properly implemented
• Environment / infrastructure:
  • describes any environmental or infrastructure requirements or impacts (e.g., safety or security impacts that the treatment may have)
• Risk treatment plan change procedures and history

• Identifies documents to be produced
• Defines the documentation activities during the life cycle of the software product or service
• Identifies any applicable standards and templates
• Defines requirements for documents
• Review and authorization practices
• Distribution of the documents
• Maintenance and disposal of the documents

• Defines problem resolution activities including identification, recording, description and classification
• Problem resolution approach: evaluation and correction of the problem
• Defines problem tracking
• Mechanism to collect and distribute problem resolutions

• Defines change management activities including identification, recording, description, analysis and implementation
• Defines approach to track status of change requests
• Defines verification and validation activities
• Change approval and implication review

• Improvement objectives derived from organizational business goals
• Organizational scope
• Process scope, the processes to be improved
• Key roles and responsibilities
• Appropriate milestones, review points and reporting mechanisms
• Activities to be performed to keep all those affected by the improvement program informed of progress

• Test Design Specification
• Test Case Specification
• Test Procedure Specification
• Identification of test cases for regression testing
• Additionally for system integration:

• identification of required system elements (hardware elements, wiring elements, settings for parameters (such as application parameters or global variables) , data bases, etc.))
• necessary sequence or ordering identified for integrating the system elements

• Authorized
• Available to all personnel impacted by the policy
• Establishes practices / rules to be adhered to

• Identification of reuse requirements
• Establishes the rules of reuse
• Documents the reuse adoption strategy including goals and objectives
• Identification of the reuse program
• Identification of the name of the reuse sponsor
• Identification of the reuse program participants
• Identification of the reuse steering function
• Identification of reuse program support functions

• A detailed description of the process / procedure which includes:
  • tailoring of the standard process (if applicable)
  • purpose of the process
  • outcomes of the process
  • task and activities to be performed and ordering of tasks
  • critical dependencies between task activities
  • expected time required to execute task
  • input / output work products
  • links between input and outputs work products
• Identifies process entry and exit criteria
• Identifies internal and external interfaces to the process
• Identifies process measures
• Identifies quality expectations
• Identifies functional roles and responsibilities
• Approved by authorized personnel

• Is a result / deliverable of the execution of a process, includes services, systems (software and hardware) and processed materials
• Has elements that satisfy one or more aspects of a process purpose
• May be represented on various media (tangible and intangible)

• Coverage for key elements (as appropriate to the application):
• Description of what is new or changed (including features removed)
• System information and requirements
• Identification of conversion programs and instructions
• Release numbering implementation may include:
  • the major release number
  • the feature release number
  • the defect repair number
  • the alpha or beta release; and the iteration within the alpha or beta release
• Identification of the component list (version identification included):
  • hardware / software / product elements, libraries, etc.
  • associated documentation list
• New/changed parameter information (e.g. for application parameters or global variables) and/or commands
• Backup and recovery information
• List of open known problems, faults, warning information, etc.
• Identification of verification and diagnostic procedures
• Technical support information
• Copyright and license information
• The release note may include an introduction, the environmental requirements, installation procedures, product invocation, new feature identification and a list of defect resolutions, known defects and workarounds

• Includes the hardware / software / product
• Includes and associated release elements such as:
  • system hardware / software / product elements
  • associated customer documentation
  • application parameter definitions defined
  • command language defined
  • installation instructions
  • release letter

• Follows established coding standards (as appropriate to the language and application):
  • commented
  • structured or optimized
  • meaningful naming conventions
  • parameter information identified
  • error codes defined
  • error messages descriptive and meaningful
  • formatting - indented, levels
• Follows data definition standards (as appropriate to the language and application):
  • variables defined
  • data types defined
  • classes and inheritance structures defined
  • objects defined
• Entity relationships defined
• Database layouts are defined
• File structures and blocking are defined
• Data structures are defined
• Algorithms are defined
• Functional interfaces defined

• All elements of the product release are included
• Any required hardware
• Integrated product
• Customer documentation
• Fully configured set of the system elements:
  • application parameters defined
  • commands defined
  • data loaded or converted

• Problem identification
• Release and system information
• Temporary solution, target date for actual fix identified
• Description of the solution:
  • limitations, restriction on usage
  • additional operational requirements
  • special procedures
  • applicable releases
• Backup / recovery information
• Verification procedures
• Temporary installation instructions

• Defines the proposed solution
• Defines the proposed schedule
• Identifies the coverage identification of initial proposal:
  • identifies the requirements that would be satisfied
  • identifies the requirements that could not be satisfied, and provides a justification of variants
• Defines the estimated price of proposed development, product, or service

• Reference to the requirements specifications
• Identifies supplier selection criteria
• Identifies desired characteristics, such as:
  • system architecture, configuration requirements or the requirements for service (consultants, maintenance, etc.)
  • quality criteria or requirements
  • project schedule requirements
  • expected delivery / service dates
  • cost / price expectations
  • regulatory standards / requirements
• Identifies submission constraints:
  • date for resubmitted of the response
  • requirements with regard to the format of response

• Identifies the project name
• Identifies the project contact
• Identifies the reuse goals and objectives
• Identifies the list of reuse assets
• Identifies the issues / risks of reusing the component including specific requirements (hardware, software, resource and other reuse components)
• Identifies the person who will be approving the reuse proposal

• Defines the suppliers proposed solution
• Defines the suppliers proposed delivery schedule
• Identifies the coverage identification of initial proposal:
  • identifies the requirements that would be satisfied
  • identifies the requirements that could not be satisfied, and provides a justification of variants
• Defines the estimated price of proposed development, product, or service

• Work product stating results achieved or provides evidence of activities performed in a process
• An item that is part of a set of identifiable and retrievable data

• Record of the receipt of the delivery
• Identification of the date received
• Identification of the delivered components
• Records the verification of any customer acceptance criteria defined
• Signed by receiving customer

• All forms of interpersonal communication, including:
  • letters
  • faxes
  • e-mails
  • voice recordings
  • podcast
  • blog
  • videos
  • forum
  • live chat
  • wikis
  • photo protocol
  • meeting support record

• Scope of contract and requirements
• Possible contingencies or risks
• Alignment of the contract with the strategic business plan of the organization
• Protection of proprietary information
• Requirements which differ from those in the original documentation
• Capability to meet contractual requirements
• Responsibility for subcontracted work
• Terminology
• Customer ability to meet contractual obligations.

• Record of items shipped / delivered electronically to customer
• Identification of:
  • who it was sent to
  • address where delivered
  • the date delivered
• Record receipt of delivered product

• Identifies the name of submitted and associated contact details
• Identifies the group / person(s) responsible for providing a fix
• Includes a description of the problem
• Identifies classification of the problem (criticality, urgency, relevance etc.)
• Identifies the status of the reported problem
• Identifies the target release(s) in which the problem will be fixed
• Identifies the expected closure date
• Identifies any closure criteria
• Identifies re-review actions

• Identifies the name of submitted and associated contact details
• Identifies a state of one or a set of work products and artifacts which are consistent and complete
• Basis for next process steps
• Is unique and may not be changed

  NOTE: This should be established before a release to identify consistent and complete delivery

• Agenda and minutes that are records that define:
  • purpose of meeting
  • attendees
  • date, place held
  • reference to previous minutes
  • what was accomplished
  • identifies issues raised
  • any open issues
  • next meeting, if any

• Status of the work products / items and modifications
• Identifies items under configuration control
• Identifies activities performed e.g. backup, storage, archiving, handling and delivery of configured items
• Supports consistency of the product

• Content information of what is to be shipped or delivered
• Identification of:
  • for whom it is intended
  • the address where to deliver
  • the date released
• Record of supplier approval

• Record of the status of a plan(s) (actual against planned) such as:
  • status of actual tasks against planned tasks
  • status of actual results against established objectives / goals
  • status of actual resource allocation against planned resources
  • status of actual cost against budget estimates
  • status of actual time against planned schedule
  • status of actual quality against planned quality
• Record of any deviations from planned activities and reason why

• Scope of proposal and requirements
• Possible contingencies or risks
• Alignment of the proposal with the strategic business plan of the organization
• Protection of proprietary information
• Requirements which differ from those in the original documentation
• Capability to meet contractual requirements
• Responsibility for subcontracted work
• Terminology
• Supplier ability to meet obligations
• Approved

• Identifies purpose of change
• Identifies request status (e.g., open, allocated, implemented, closed)
• Identifies requester contact information
• Impacted system(s)
• Impact to operations of existing system(s) defined
• Impact to associated documentation defined
• Criticality of the request, due date

• Identifies request purpose, such as:
  • new development
  • enhancement
  • internal customer
  • operations
  • documentation
  • informational
• Identifies request status information, such as:
  • date opened
  • current status
  • date assigned and responsible owner
  • date verified
  • date closed
• Identifies priority / severity of the request
• Identifies customer information, such as:
  • company / person initiating the request
  • contact information and details
  • system site configuration information
  • impacted system(s)
  • impact to operations of existing systems
  • criticality of the request
  • expected customer response / closure requirements
• Identifies needed requirements / standards
• Identifies information sent with request (i.e., RFPs, dumps, etc.)

• Identifies what information to keep
• Identifies what tasks / activities / process produce the information
• Identifies when the data was collected
• Identifies source of any associated data
• Identifies the associated quality criteria
• Identifies any associated measurements using the information
• Identifies any requirements to be adhered to create the record, or satisfied by the record

• Provides the context information about the review:
  • what was reviewed
  • lists reviewers who attended
  • status of the review
• Provides information about the coverage of the review:
  • check-lists
  • review criteria
  • requirements
  • compliance to standards
• Records information about:
  • the readiness for the review
  • preparation time spent for the review
  • time spent in the review
  • reviewers, roles and expertise
• Review findings:
  • non-conformances
  • improvement suggestions
• Identifies the required corrective actions:
  • risk identification
  • prioritized list of deviations and problems discovered
  • the actions, tasks to be performed to fix the problem
  • ownership for corrective action
  • status and target closure dates for identified problems

• Date of initiation
• Scope
• Subject
• Request originator
• Risk management process context:
  • this section may be provided once, and then referenced in subsequent action requests if no changes have occurred
  • process scope
  • stakeholder perspective
  • risk categories
  • risk thresholds
  • project objectives
  • project assumptions
  • project constraints
• Risks:
  • this section may cover one risk or many, as the user chooses
  • where all the information above applies to the whole set of risks, one action request may suffice
  • where the information varies, each request may cover the risk or risks that share common information
  • risk description(s)
  • risk probability
  • risk consequences
  • expected timing of risk
• Risk treatment alternatives:
  • alternative descriptions
  • recommended alternative(s)
  • justifications
• Risk action request disposition:
  • each request should be annotated as to whether it is accepted, rejected, or modified, and the rationale provided for whichever decision is taken

• Used as a mechanism to control change to baselined products / products in official project release libraries
• Record of the change requested and made to a baselined product (work products, software, customer documentation, etc.):
  • identification of system, documents impacted with change
  • identification of change requester
  • identification of party responsible for the change
  • identification of status of the change
• Linkage to associated customer requests, internal change requests, etc.
• Appropriate approvals
• Duplicate requests are identified and grouped

• All requirements (customer and internal) are to be traced
• Identifies a mapping of requirements to life cycle work products
• Provides the linkage of requirements to work product decomposition
• Provides forward and backwards mapping of requirements to associated work products throughout all phases of the life cycle
• NOTE: this may be included as a function of another defined work product (example: A CASE tool for design decomposition may have a mapping ability as part of its features)

• Validation check-list
• Passed items of validation
• Failed items of validation
• Pending items of validation
• Problems identified during validation
• Risk analysis
• Recommendation of actions
• Conclusions of validation
• Signature of validation

• Verification check-list
• Passed items of verification
• Failed items of verification
• Pending items of verification
• Problems identified during verification
• Risk analysis
• Recommendation of actions
• Conclusions of verification
• Signature of verification

• A register is a compilation of data or information captured in a defined sequence to enable:
  • an overall view of evidence of activities that have taken place
  • monitoring and analyses
  • provides evidence of performance of a process over time

• Historical records of all changes made to an object (document, file, software module, etc.):
  • description of change
  • version information about changed object
  • date of change
  • change requester information
  • change control record information

• Identifies the initial problem
• Identifies the ownership for completion of defined action
• Defines a solution (series of actions to fix problem)
• Identifies the open date and target closure date
• Contains a status indicator
• Indicates follow up audit actions

• Subcontractor or supplier history
• List of potential subcontractor / suppliers
• Qualification information
• Identification of their qualifications
• Past history information when it exists

• Identifies the tasks to be performed
• dentifies the expected and actual start and completion date for required tasks against progress/completion of tasks
• Allows for the identification of critical tasks and task dependencies
• Identifies task completion status, vs. planned date
• Has a mapping to scheduled resource data

  NOTE: A schedule is consistent with the work breakdown structure, see 14-09

• Ability to record customer and process owner information
• Ability to record related system configuration information
• Ability to record information about problem or action needed:
  • date opened and target closure date
  • severity / criticality of item
  • status of any problem or actions needed
  • information about the problem or action owner
  • priority of problem resolution
• Ability to record proposed resolution or action plan
• Ability to provide management status information
• Information is available to all with a need to know
• Integrated change control system(s) / records

• Defines tasks to be performed, and their amendments
• Documents ownership for tasks
• Documents critical dependencies between tasks
• Documents inputs and output work products
• Documents the critical dependencies between defined work products

  NOTE: A work breakdown structure may be integrated into/part of the schedule, see 14-06

• Identifies:
  • name of work product
  • work product reference ID
  • work product revision
  • when updated
  • work product status
  • when approved
  • reference to approval source
  • file reference

• Identifies:
  • relevant stakeholder groups
  • weight/importance of each stakeholder group
  • representative(s) for each stakeholder group
  • information needs of each stakeholder group

• A work product describing a situation that:
  • includes results and status
  • identifies applicable / associated information
  • identifies considerations / constraints
  • provides evidence / verification

• What was analyzed
• Who did the analysis
• The analysis criteria used:
  • selection criteria or prioritization scheme used
  • decision criteria
  • quality criteria
• Records the results:
  • what was decided / selected
  • reason for the selection
  • assumptions made
  • potential risks
• Aspects of correctness to analyze include:
  • completeness
  • understandability
  • testability
  • verifiability
  • feasibility
  • validity
  • consistency
  • adequacy of content

• Identification of the number of items under configuration management
• Identification of risks associated to configuration management
• Identification of the number of configuration management items lost and reason for their loss
• Identification of problem and issues related to configuration management
• Identification of receiving parties
• Identification of baselines made

• States the purpose of evaluation
• Method used for evaluation
• Requirements used for the evaluation
• Assumptions and limitations
• Identifies the context and scope information required:
  • date of evaluation
  • parties involved
  • context details
  • evaluation instrument (check-list, tool) used
• Records the result:
  • data
  • identifies the required corrective and preventive actions
  • improvement opportunities, as appropriate

• A report of the current status of the project
• Schedule:
  • planned progress (established objectives/goals) or completion (dates/deadlines) of tasks against
  • actual progress of tasks
  • reasons for variance from planned progress
  • threats to continued progress
  • contingency plans to maintain progress
• Resources (human resources, infrastructure, hardware/materials, budget):
  • planned expenditure against actual expenditure
  • reasons for variance between planned and actual expenditure
  • expected future expenditure
  • contingency plans to achieve budget goals
• Quality goals:
  • actual quality measures
  • reasons for variance from planned quality measures
  • contingency plans to achieve quality goals
• Project issues:
  • issues which may affect the ability of the project to achieve its goals.
  • contingency plans to overcome threats to project goals

• Identification of reuse opportunities
• Identification of investment in Reuse
• Identification of current skills and experience
• Identification of reuse infrastructure
• The evaluation report must represent current status in implementation of the reuse program

• Identifies the risks analyzed
• Records the results of the analysis:
  • potential ways to mitigate the risk
  • assumptions made
  • constraints

• Identifies the status of an identified risk:
  • related project or activity
  • risk statement
  • condition
  • consequence
  • changes in priority
  • duration of mitigation, when started
  • risk mitigation activities in progress
  • responsibility
  • constraints

• Presents a summary of problem records
  • by problem categories / classification
• Status of problem solving
  • development of solved vs. open problems

• States the purpose of assessment
• Method used for assessment
• Requirements used for the assessment
• Assumptions and limitations
• Identifies the context and scope information required:
  • date of assessment
  • organizational unit assessed
  • sponsor information
  • assessment team
  • attendees
  • scope / coverage
  • assessees' information
  • assessment Instrument (check-list, tool) used
• Records the result:
  • data
  • identifies the required corrective actions
  • improvement opportunities

• Identifies what the problem is
• Identifies what the cause of a problem is
• Suggest what could be done to fix the problem
• Identifies the value (expected benefit) in performing the improvement
• Identifies the penalty for not making the improvement

• Repository for components
• Storage and retrieval capabilities
• Ability to browse content
• Listing of contents with description of attributes
• Sharing and transfer of components between affected groups
• Effective controls over access
• Maintain component descriptions
• Recovery of archive versions of components
• Ability to report component status
• Changes to components are tracked to change / user requests

• Supports the configuration management strategy
• Correct configuration of products
• Can recreate any release or test configuration
• Ability to report configuration status
• Has to cover all relevant tools

• Contains process descriptions
• Supports multiple presentations of process assets

• Each requirement is identified
• Each requirement is unique
• Each requirement is verifiable or can be assessed (see 17-50)
• Includes statutory and regulatory requirements
• Includes issues / requirements from (contract) reviews

• Identification of aggregates of the software application system
• Identification of required system elements (application parameter settings, macro libraries, data bases, job control languages, etc.)
• Necessary sequence ordering identified for compiling the software release
• Input and output source libraries identified

• Purpose / objectives defined
• Includes issues / requirements from (contract) reviews
• Identifies any:
  • time schedule / constraints
  • required feature and functional characteristics
  • necessary performance considerations / constraints
  • necessary internal / external interface considerations / constraints
  • required system characteristics / constraints
  • human engineering considerations / constraints
  • security considerations / constraints
  • environmental considerations / constraints
  • operational considerations / constraints
  • maintenance considerations / constraints
  • installation considerations / constraints
  • support considerations / constraints
  • design constraints
  • safety / reliability considerations / constraints
  • quality requirements / expectations

• Purpose / objectives defined
• Proposed contents (coverage) defined
• Intended audience defined
• Identification of supported hardware / software / product release, system information
• Identification of associated hardware / software / product requirements and designs satisfied by document
• Identification of style, format, media standards expected definition of the intended distribution requirement
• Includes storage requirements

• Defines relationships between two products, process or process tasks
• Defines criteria and format for what is common to both
• Defines critical timing dependencies or sequence ordering
• Description of the physical interfaces of each system component like
  • bus interfaces (CAN, MOST, LIN, Flexray etc.)
  • transceiver (type, manufacturer, etc.)
  • analogue Interfaces
  • digital Interfaces (PWM, etc.)
  • additional Interfaces (IEEE, ISO, Bluetooth, USB, etc.
• Identification of the software interfaces of software components and other software item in terms of
  • inter-process communication mechanisms
  • bus communication mechanisms

• Identifies standards to be used
• Identifies any software structure considerations / constraints
• Identifies the required software elements
• Identifies the relationship between software elements
• Consideration is given to:
  • any required software performance characteristics
  • any required software interfaces
  • any required security characteristics required
  • any database design requirements
  • any required error handling and recovery attributes
  • any required resource consumption characteristics

• System requirements include: 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. (ISO/IEC 12207)
• Identifies the required system overview
• Identifies any interrelationship considerations / constraints between system elements
• Identifies any relationship considerations / constraints between the system elements and the software
• Identifies any design considerations / constraints for each required system element, including:
  • memory / capacity requirements
  • hardware interfaces requirements
  • user interfaces requirements
  • external system interface requirements
  • performance requirements
  • commands structures
  • security / data protection characteristics
  • application parameter settings
  • manual operations
  • reusable components
• Describes the operation capabilities
• Describes environmental capabilities
• Documentation requirements
• Reliability requirements
• Logistical Requirements
• Describes security requirements
• Diagnosis requirements

• Each requirement is verifiable or can be assessed
• Verification criteria define the qualitative and quantitative criteria for verification of a requirement.
• Verification criteria demonstrate that a requirement can be verified within agreed constraints. (Additional Requirement to 17-00 Requirements specification)

• Identification of whom / what they apply
• Expectations for conformance are identified
• Conformance to requirements can be demonstrated
• Provisions for tailoring or exception to the requirements are included

• Defines expectations for acceptance like e.g.:
  • interfaces
  • schedules
  • messages
  • documents
  • meetings
  • joint reviews

• Defines expectations for product release:
  • release type and status
  • required elements of the release
  • product completeness including documentation
  • adequacy and coverage of testing
  • limit for open defects
  • change control status

• Defines expectations for quality:
  • establishes what is an adequate work product (required elements, completeness expected, accuracy, etc.)
  • identifies what constitutes the completeness of the defined tasks
  • establishes life cycle transition criteria and the entry and exit requirements for each process and/or activity defined
  • establishes expected performance attributes
  • establishes product reliability attributes

• Expectations for conformance, to be fulfilled by competent suppliers, are identified
• Links from the expectations to national/international/domains-specific standards/laws/regulations are described
• Conformance to requirements can be demonstrated by the potential suppliers or assessed by the acquiring organisation
• Provisions for tailoring or exception to the requirements are included

• Identifies what needs and objectives or goals there are to be satisfied
• Establishes the options and approach for satisfying the needs, objectives, or goals
• Establishes the evaluation criteria against which the strategic options are evaluated
• Identifies any constraints / risks and how these will be addressed

• Identify the goals for reuse
• Identify the commitment for creating reusable components
• Determine which product lines and type of artefacts should be supported with reuse
• Identify system and hardware / software / product elements which can be reused within the organization
• Identify the reuse repository and tools

• Verification methods, techniques, and tools
• Work product or processes under verification
• Degrees of independence for verification
• Schedule for performing the above activities
• Identifies what needs there are to be satisfied
• Establishes the options and approach for satisfying the need
• Establishes the evaluation criteria against which the strategic options are evaluated
• Identifies any constraints / risks and how these will be addressed
• Verification ending criteria
• Verification start, abort and re-start criteria

• Validation methods, techniques, and tools
• Work products under validation
• Degrees of independence for validation
• Schedule for performing the above activities
• Identifies what needs there are to be satisfied
• Establishes the options and approach for satisfying the need
• Establishes the evaluation criteria against which the strategic options are evaluated
• Identifies any constraints / risks and how these will be addressed

• Defines the attributes associated with a work product to be created as a consequence of a process execution
• Identifies technical elements typically associated with this product type
• Defines expected form and style

• Defines the attributes associated with an artefact from a process execution:
  • key elements to be represented in the work product