ISO 15504 subdivides the software development processes in 3 Process Categories. Each Category is further subdivided in Process Groups.

Primary [PLC]

Primary [PLC]

Acquisition [ACQ]   Processes performed by the customer in order to acquire a product and/or a service.   Acquisition [ACQ]   Processes performed by the customer in order to acquire a product and/or a service.   Acquisition Preparation [ACQ.1]   The purpose of the process is to establish the needs and goals of the acquisition and to communicate these with the potential suppliers. Acquisition Preparation [ACQ.1]   The purpose of the process is to establish the needs and goals of the acquisition and to communicate these with the potential suppliers.   Outcomes   [1] The concept or the need for the acquisition, development, or enhancement is established. [2] The needed acquisition requirements defining the project needs are defined and validated. [3] The customer's known requirements are defined and validated. [4] An acquisition strategy is developed. [5] Supplier selection criteria are defined.   Input Workproducts Output Workproducts   5.2 Business Goals [1]                 15.4 Market Analysis Report [2] 15.19 Product Needs Assessment [1, 3, 4]                         8.2 Acquisition Plan [4] 12.1 Request for Proposal [4, 5] 13.19 Review Record [3] 15.1 Analysis Report [1, 2]     15.19 Product Needs Assessment [2, 3] 17.3 Customer Requirements [3] 17.9 Product Requirements [3] 17.10 Service Requirements [3] 18.1 Acceptance Criteria [2, 4] 18.8 Supplier Selection Criteria [5] Establish the need. [ACQ.1.BP1]   Establish a need to acquire, develop or enhance a system, software product or service.   Define the requirements. [ACQ.1.BP2]   Identify the customer / stakeholder requirements for a system and/or software product or service.   Review requirements. [ACQ.1.BP3]   Analyze and validate the defined requirements against the identified needs. Validate the requirements to reduce risk of misunderstanding by the potential suppliers.   Develop acquisition strategy. [ACQ.1.BP4]   Develop a strategy for the acquisition of the product according to the acquisition needs.   Define selection criteria. [ACQ.1.BP5]   Establish and agree on supplier selection criteria and the means of evaluation to be used.   Communicate the need. [ACQ.1.BP6]   Communicate the need for acquisition to interest parties through the identified channels.   Supplier Selection [ACQ.2]   The purpose of the process is to choose the organisation that is to be responsible for the delivery of the requirements of the project. Supplier Selection [ACQ.2]   The purpose of the process is to choose the organisation that is to be responsible for the delivery of the requirements of the project.   Outcomes   [1] The supplier selection criteria are established and used to evaluate potential suppliers. [2] The supplier is selected based upon the evaluation of the supplier's proposals, process capabilities and other factors. [3] An agreement is established and negotiated between the customer and the supplier.   Input Workproducts Output Workproducts           9.4 Supplier Selection Policy [2] 12.1 Request for Proposal [2] 12.4 Supplier Proposal Response [2, 3]         13.9 Meeting Support Record [3]             15.13 Assessment Report [2]     15.24 Audit Report [1] 17.9 Product Requirements [2] 17.10 Service Requirements [2] 18.8 Supplier Selection Criteria [2] 2.1 Commitment / Agreement [3] 8.2 Acquisition Plan [1] 9.4 Supplier Selection Policy [1, 3]         13.4 Communication Record [3] 13.5 Contract Review Record [3] 13.9 Meeting Support Record [3] 13.19 Review Record [2] 14.5 Preferred Suppliers Register [2] 15.1 Analysis Report [2] 15.13 Assessment Report [1] 15.21 Supplier Evaluation Report [1, 2] 15.24 Audit Report [1]         18.8 Supplier Selection Criteria [1] Evaluate stated or perceived supplier capability. [ACQ.2.BP1]   Evaluate stated or perceived supplier capability against the stated requirements, according to the supplier selection criteria.   Evaluate supplier's proposal. [ACQ.2.BP2]   Evaluate supplier's proposal against the stated requirements, according to the supplier selection criteria.   Prepare and negotiate agreement. [ACQ.2.BP3]   Negotiate a supplier agreement that clearly expresses the customer expectations that clearly expresses the customer expectation and the relative responsibilities of the supplier and customer.   Contract Agreement [ACQ.3]   The purpose of process is to negotiate and approve a contract / agreement that clearly and unambiguously specifies the expectations, responsibilities, work products / deliverables and liabilities of both the supplier(s) and the acquirer. Contract Agreement [ACQ.3]   The purpose of process is to negotiate and approve a contract / agreement that clearly and unambiguously specifies the expectations, responsibilities, work products / deliverables and liabilities of both the supplier(s) and the acquirer.   Outcomes   [1] A contract or agreement is negotiated, reviewed, approved and awarded to the supplier(s). [2] Mechanisms for monitoring the capability and performance of the supplier(s)and for mitigation of identified risks are reviewed and considered for inclusion in the contract conditions. [3] Proposers/tenderers are notified of the result of proposal/tender selection.   Input Workproducts Output Workproducts           8.19 Risk Management Plan [2] 12.1 Request for Proposal [1] 12.4 Supplier Proposal Response [1]         14.8 Tracking System [2] 15.8 Risk Analysis Report [2] 15.18 Process Performance Report [2] 17.9 Product Requirements [1] 17.10 Service Requirements [1] 2.0 Contract [1] 2.1 Commitment / Agreement [1, 3]             13.4 Communication Record [1, 3] 13.5 Contract Review Record [1]     15.8 Risk Analysis Report [2]             Negotiate the contract / agreement. [ACQ.3.BP1]   Negotiate all relevant aspects of the contract / agreement with the supplier.   Approve contract. [ACQ.3.BP2]   The contract is approved by relevant stakeholders.   Review contract for supplier capability monitoring. [ACQ.3.BP3]   Review and consider a mechanism for monitoring the capability and performance of the supplier in the contract conditions.   Review contract for risk mitigation actions. [ACQ.3.BP4]   Review and consider a mechanism for the mitigation of identified risk in the contract conditions.   Award contract. [ACQ.3.BP5]   The contract is awarded to the successful proposer / tenderer.   Communicate results to tenderers. [ACQ.3.BP6]   Notify the results of the proposal / tender selection to proposers / tenders. After contract award, inform all tenderers of the decision.   Supplier Monitoring [ACQ.4]   The purpose of the process is to track and assess performance of the supplier against agreed requirements. Supplier Monitoring [ACQ.4]   The purpose of the process is to track and assess performance of the supplier against agreed requirements.   Outcomes   [1] Joint activities between the customer and the supplier are performed as needed. [2] Information on technical progress is exchanged regularly with the supplier. [3] Performance of the supplier is monitored against the agreed requirements. [4] Agreement changes, if needed, are negotiated between the acquirer and the supplier and documented in the agreement.   Input Workproducts Output Workproducts   2.0 Contract [1] 2.1 Commitment / Agreement [3, 4]         13.9 Meeting Support Record [1] 13.14 Progress Status Record [2] 13.16 Change Request [4]     14.8 Tracking System [3]             2.1 Commitment / Agreement [4] 13.1 Acceptance Record [3] 13.4 Communication Record [1] 13.9 Meeting Support Record [1] 13.14 Progress Status Record [2]     13.19 Review Record [2]     15.1 Analysis Report [3] 15.21 Supplier Evaluation Report [3] Establish and maintain communications. [ACQ.4.BP1]   Establish and maintain communications between customer and supplier (i.e. define interfaces, schedule, messages, documents, meetings, joint review).   Exchange information on technical progress. [ACQ.4.BP2]   Use the communication link to exchange information on technical progress of the supply, also covering costs and risks to successful completion.   Review development with supplier. [ACQ.4.BP3]   Review the aspects of the development (technical, quality, cost and schedule) on a regular basis with the supplier, against the agreed requirements.   Monitor the acquisition. [ACQ.4.BP4]   Monitor the acquisition against the agreed acquisition documentation so that progress can be reviewed and audited to ensure that specified constraints such as cost, schedule and quality are met.   Agree on changes. [ACQ.4.BP5]   Changes proposed by either party are negotiated and the results are documented in the agreement.   Customer Acceptance [ACQ.5]   The purpose of the process is to approve the supplier's deliverable when all acceptance criteria are satisfied. Customer Acceptance [ACQ.5]   The purpose of the process is to approve the supplier's deliverable when all acceptance criteria are satisfied.   Outcomes   [1] The delivered software product and/or service are evaluated with regard to the agreement. [2] The customer's acceptance is based on the agreed acceptance criteria. [3] The software product and/or service is accepted by the customer.   Input Workproducts Output Workproducts   2.0 Contract [1] 2.1 Commitment / Agreement [1] 8.1 Acceptance Test Plan [1, 2] 8.2 Acquisition Plan [1] 11.0 Product [1, 3]             17.3 Customer Requirements [2] 18.1 Acceptance Criteria [2]                     13.1 Acceptance Record [3] 13.7 Problem Record [1] 15.10 Test Incident Report [2]         Define acceptance criteria. [ACQ.5.BP1]   Acceptance criteria are defined on the basis of agreed requirements.   Evaluate the delivered product. [ACQ.5.BP2]   Carry out the evaluation of the product and/or service using the defined acceptance criteria.   Compliance with agreement. [ACQ.5.BP3]   Resolve any acceptance issues in accordance with the procedures established in the agreement and confirm that delivered product or service complies with the agreement.   Accept product. [ACQ.5.BP4]   Accept the delivered product or service and communicate acceptance to the supplier.

Supply [SPL]   Processes performed by the supplier in order to propose and deliver a product and/or a service.   Supply [SPL]   Processes performed by the supplier in order to propose and deliver a product and/or a service.   Supplier Tendering [SPL.1]   The purpose of process is to establish an interface to respond to customer inquiries and requests for proposal, prepare and submit proposals, and confirm assignments through the establishing of a relevant agreement / contract. Supplier Tendering [SPL.1]   The purpose of process is to establish an interface to respond to customer inquiries and requests for proposal, prepare and submit proposals, and confirm assignments through the establishing of a relevant agreement / contract.   Outcomes   [1] A communication interface is established and maintained in order to respond to customer inquiries and requests for proposal. [2] requests for proposal are evaluated according to defined criteria to determine whether or not to submit a proposal. [3] The need to undertake preliminary surveys or feasibility studies is determined. [4] suitable resources are identified to perform the proposed work. [5] A supplier proposal is prepared and submitted in response to the customer request. [6] Formal confirmation of agreement is obtained.   Input Workproducts Output Workproducts           5.2 Business Goals [2] 12.1 Request for Proposal [1, 2, 3, 4, 5]     13.4 Communication Record [1]     13.11 Personnel Performance Review Record [4]     2.0 Contract [5, 6] 2.1 Commitment / Agreement [6]         12.4 Supplier Proposal Response [5] 13.4 Communication Record [1] 13.5 Contract Review Record [6]     13.15 Proposal Review Record [2, 3] Establish communication interface. [SPL.1.BP1]   A communication interface is established and maintained in order to respond to customer inquiries or requests for proposal.   Perform customer enquiry screening. [SPL.1.BP2]   Perform customer enquiry screening to ensure source of lead is genuine, the nature or type of product or service is clearly established, and the right person is quickly identified to progress the lead.   Establish customer proposal evaluation criteria. [SPL.1.BP3]   Establish evaluation criteria to determine whether or not to submit a proposal based on appropriate criteria.   Evaluate customer request for proposal. [SPL.1.BP4]   Requests for proposal are evaluated according to appropriate criteria.   Determine need for preliminary evaluations or feasibility studies. [SPL.1.BP5]   Determine need for preliminary evaluations or feasibility studies to ensure that a firm quotation can be made based on available requirements.   Identify and nominate staff. [SPL.1.BP6]   Identify and nominate staff with appropriate competency for the assignment.   Perform preliminary overall estimation. [SPL.1.BP7]   Estimate total costs, resources, and needed delivery date.   Prepare supplier proposal or tender response. [SPL.1.BP8]   A supplier proposal or tender is prepared in response to the customer request.   Negotiate contract / agreement with acquirer. [SPL.1.BP9]   Negotiate all relevant aspects of the contract / agreement with the acquirer.   Establish confirmation of contract / agreement. [SPL.1.BP10]   Formally confirm the contract / agreement to protect the interests of both parties.   Product Release [SPL.2]   The purpose of process is to control the availability of a product to the intended customer. Product Release [SPL.2]   The purpose of process is to control the availability of a product to the intended customer.   Outcomes   [1] The contents of the product release are determined. [2] The release is assembled from configured items. [3] The release documentation is defined and produced. [4] The release delivery mechanism and media is determined. [5] Release approval is effected against defined criteria. [6] Release products are made available to the intended customer. [7] Confirmation of release is obtained.   Input Workproducts Output Workproducts   1.0 Configuration Item [2]     8.16 Release Plan [3] 11.0 Product [1]                     17.3 Customer Requirements [1]     18.6 Product Release Criteria [1, 5] 19.4 Product Release Strategy [4]     8.11 Logistics Maintenance Plan [4] 8.16 Release Plan [3]     11.3 Product Release Information [1] 11.4 Product Release Package [2, 3] 13.6 Delivery Record [6, 7] 13.13 Product Release Approval Record [5] 15.3 Configuration Status Report [2]     17.4 Delivery Instructions [3] 18.6 Product Release Criteria [7]     Define release products [SPL.2.BP1]   The products associated with the release are defined, on the basis of agreement or development strategy.   Prepare product for delivery [SPL.2.BP2]   Update and prepare the deliverable product. Establish baseline for the product including user documentation, designs and the product itself.   Establish a product release classification and numbering scheme [SPL.2.BP3]   A product release and classification is established based upon the intended purpose and expectations of the release.   Define the build activities and build environment [SPL.2.BP4]   A consistent build process isestablished and maintained.   Build the release from configured items [SPL.2.BP5]   The release is built from configured items to ensure integrity.   The type, level and duration of support for a release are communicated [SPL.2.BP6]   The type, level and duration of a release is identified and communicated.   Determine the delivery media type for the release [SPL.2.BP7]   The media type for product delivery is determined in accordance with the needs of the end user.   Identify the packaging for the release media. [SPL.2.BP8]   The packaging for different types of media is identified.   Define and produce the software product release documentation. [SPL.2.BP9]   Ensure that all documentation to support the release is produced, reviewed, approved and available.   Ensure product release approval before delivery. [SPL.2.BP10]   Criteria for the product release are satisfied before release takes place.   Deliver the release to the intended customer. [SPL.2.BP11]   The product is delivered to the intended customer, with positive confirmation of receipt.   Product Acceptance Support [SPL.3]   The purpose of process is to assist the customer to achieve confidence in taking ownership of the product. Product Acceptance Support [SPL.3]   The purpose of process is to assist the customer to achieve confidence in taking ownership of the product.   Outcomes   [1] The product is completed and delivered to the customer. [2] The product is put into operation in the customer's environment. [3] Customer acceptance tests and reviews are supported.   Input Workproducts Output Workproducts       2.0 Contract [1] 6.3 Installation Guide [2] 8.1 Acceptance Test Plan [3] 8.24 Training Plan [3] 10.3 Customer Support Procedure [3] 11.4 Product Release Package [1]                 17.3 Customer Requirements [2] 1.1 Product Configuration [1]         8.1 Acceptance Test Plan [3]     10.3 Customer Support Procedure [3]     13.1 Acceptance Record [3] 13.6 Delivery Record [1] 13.8 Installation Record [2] 13.19 Review Record [3]     Deliver product [SPL.3.BP1]   The product is completed and delivered to the customer with detailed configurations and technical / operational documents.   Adapt product to customer's environment. [SPL.3.BP2]   The product shall be adapted and evaluated in parallel with the existing systems or processes until the acceptance test is passed.   Support customer product evaluation. [SPL.3.BP3]   Provide support for customer reviews and product testing.   Provide training to customer. [SPL.3.BP4]   Provide training and support to the customer as specified in the contract.

Engineering [ENG]   Processes that directly elicit and manage the customer's requirements, specify, implement, and/or maintain the software product and it’s relation to the system.   Engineering [ENG]   Processes that directly elicit and manage the customer's requirements, specify, implement, and/or maintain the software product and it’s relation to the system.   Requirements Elicitation [ENG.1]   The purpose of the process is to gather, process and track evolving customer needs and requirements throughout the life of the product and/or service so as to establish a requirements baseline that serves as the basis for defining the needed work products. Requirements Elicitation [ENG.1]   The purpose of the process is to gather, process and track evolving customer needs and requirements throughout the life of the product and/or service so as to establish a requirements baseline that serves as the basis for defining the needed work products.   Outcomes   [1] Continuing communication with the customer is established. [2] Agreed customer requirements are defined and baselined. [3] A change mechanism is established to evaluate and incorporate changes to customer requirements into the baselined requirements based on changing customer needs. [4] A mechanism is established for continuous monitoring of customer needs. [5] A mechanism is established for ensuring that customers can easily determine the status and disposition of their requests. [6] Enhancements arising from changing technology and customer needs are identified and their impact is managed.   Input Workproducts Output Workproducts   2.1 Commitment / Agreement [2]         13.16 Change Request [3, 6] 13.17 Customer Request [1, 3]         17.3 Customer Requirements [3]     13.0 Record [4, 5] 13.4 Communication Record [1, 4]         13.21 Change Control Record [3, 4] 15.1 Analysis Report [2, 3, 6] 17.3 Customer Requirements [2, 3] Obtain customer requirements and requests. [ENG.1.BP1]   Obtain and define customer requirements and requests through direct and continuous solicitation of customer and user input.   Understand customer expectations. [ENG.1.BP2]   Ensure that both supplier and customer understand each requirement in the same way. Review with customers their requirements and requests to better understand their needs and expectations and to check the feasibility and appropriateness of their requirements.   Agree on requirements. [ENG.1.BP3]   Obtain agreement across teams on the customer requirements, obtaining the appropriate sign-offs by representatives of all teams and other parties contractually bound to work to these requirements.   Establish customer requirements baseline. [ENG.1.BP4]   Formalize the customer requirements and establish as a baseline for project use and monitoring against customer needs.   Manage customer requirements changes. [ENG.1.BP5]   Manage all changes made to the customer requirements against the customer requirements baseline to ensure enhancements resulting from changing technology and customer needs are identified and that those who are affected by the changes are able to assess the impact and risks and initiate appropriate change control and risk mitigation actions.   Establish customer query mechanism. [ENG.1.BP6]   Provide a means by which the customer can be aware of the status and disposition of their requirements changes.   System Requirements Analysis [ENG.2]   The purpose of the process is to transform the defined stakeholder requirements into a set of desired system technical requirements that will guide the design of the system. System Requirements Analysis [ENG.2]   The purpose of the process is to transform the defined stakeholder requirements into a set of desired system technical requirements that will guide the design of the system.   Outcomes   [1] A defined set of system functional and non-functional requirements describing the problem to be solved are established. [2] The appropriate techniques are performed to optimise the preferred project solution. [3] System requirements are analysed for correctness and testability. [4] The impact of the system requirements on the operating environment are understood. [5] The requirements are prioritised, approved and updated as needed. [6] Consistency and traceability are established between the system requirements and the customer's requirements baseline. [7] Changes to the baseline are evaluated for cost, schedule and technical impact. [8] The system requirements are communicated to all affected parties and baselined.   Input Workproducts Output Workproducts       13.16 Change Request [7] 13.17 Customer Request [7]             17.3 Customer Requirements [1, 6]         13.4 Communication Record [8]         13.21 Change Control Record [7] 13.22 Traceability Record [6] 15.1 Analysis Report [2, 3, 4, 7]     17.8 Interface Requirements [4] 17.12 System Requirements [1, 5] Establish system requirements. [ENG.2.BP1]   Use the stakeholder requirements as the basis for defining the required functions and capabilities of the system and document in a system requirements baseline. Consider feasibility of the project solution using appropriate techniques.   Optimize project solution. [ENG.2.BP2]   Appropriate techniques are performed to optimize the preferred solution. Consider and analyze alternate solutions to achieve an optimum project solution.   Analyze system requirements. [ENG.2.BP3]   Prioritize requirements and analyze the prioritized requirements for correctness, completeness, consistency, feasibility and testability, identifying the necessary elements of the system. Identify changes to the operating environment.   Evaluate and update system requirements. [ENG.2.BP4]   Evaluate the impact of proposed changes and new requirements for cost, schedule, risk and technical impact, approve or reject changes and new requirements, and update the system requirements baseline.   Ensure consistency. [ENG.2.BP5]   Ensure consistency of requirements elicitation to system requirements analysis. Consistency is supported by establishing and maintaining traceability between customer requirements and the system requirements when needed.   Communicate system requirements. [ENG.2.BP6]   Establish communication mechanisms for dissemination of system requirements, and updates to requirements to all parties who will be using them.   System Architectural Design [ENG.3]   The purpose of the process is to identify which system requirements should be allocated to which elements of the system. System Architectural Design [ENG.3]   The purpose of the process is to identify which system requirements should be allocated to which elements of the system.   Outcomes   [1] A system architecture design is defined that identifies the elements of the system and meets the defined requirements. [2] The system's functional and non-functional requirements are addressed. [3] The requirements are allocated to the elements of the system. [4] internal and external interfaces of each system element are defined. [5] Verification between the system requirements and the system architecture is performed. [6] The requirements allocated to the system elements and their interfaces are traceable to the customer's requirements baseline. [7] Consistency and traceability between the system requirements and system architecture design is maintained. [8] The system requirements, the system architecture design and their relationships are baselined and communicated to all affected parties.   Input Workproducts Output Workproducts   1.1 Product Configuration [1]                     17.3 Customer Requirements [6] 17.8 Interface Requirements [6] 17.12 System Requirements [1,2,3,5, 6, 7, 8]     4.6 System Architecture Design [1, 2, 3, 4] 11.8 System Element [1, 3, 6] 13.4 Communication Record [8] 13.22 Traceability Record [6, 7, 8] 13.25 Verification Results [5]             Describe system architecture. [ENG.3.BP1]   Establish the top-level system architecture that identifies elements of hardware, software and manual-operations.   Allocate requirements. [ENG.3.BP2]   Allocate all system requirements to the elements of the top-level system architecture.   Define interfaces. [ENG.3.BP3]   Develop and document the internal and external interfaces of each system element.   Verify system architecture. [ENG.3.BP4]   Ensure that the system architecture meets all stakeholder and system requirements.   Evaluate alternative system architectures. [ENG.3.BP5]   Define evaluation criteria for architecture design. Evaluate alternative system architectures according to the defined criteria. Record the rationale for choosing the current system architecture.   Ensure consistency. [ENG.3.BP6]   Ensure consistency of system requirements analysis to system architectural design. Consistency is supported by establishing and maintaining traceability between system requirements and the system architecture design when needed.   Communicate system architecture design. [ENG.3.BP7]   Establish communication mechanisms for dissemination of the system architecture design to all parties who will be using them.   Software Requirements Analysis [ENG.4]   The purpose of the process is to establish the requirements of the software elements of the system. Software Requirements Analysis [ENG.4]   The purpose of the process is to establish the requirements of the software elements of the system.   Outcomes   [1] The requirements allocated to the software elements of the system and their interfaces are defined. [2] Software requirements are analysed for correctness and testability. [3] The impact of software requirements on the operating environment are understood. [4] Consistency and traceability are established between the software requirements and system requirements. [5] Prioritisation for implementing the software requirements is defined. [6] The software requirements are approved and updated as needed. [7] Changes to the software requirements are evaluated for cost, schedule and technical impact. [8] The software requirements are baselined and communicated to all affected parties.   Input Workproducts Output Workproducts   4.6 System Architecture Design [1]     13.16 Change Request [6, 7] 13.17 Customer Request [6, 7]                     17.12 System Requirements [1, 4]     13.4 Communication Record [8]         13.21 Change Control Record [7] 13.22 Traceability Record [4] 15.1 Analysis Report [2, 3, 7] 17.8 Interface Requirements [1] 17.11 Software Requirements [1, 2, 4, 5, 6]     Specify software requirements. [ENG.4.BP1]   Specify software requirements. Define and prioritize functional and nonfunctional requirements of the software elements of the system and their interfaces and document in a software requirements specification. Analyze the software requirements for correctness, completeness, consistency, feasibility and testability. Identify any derived requirements.   Determine operating environment impact. [ENG.4.BP2]   Determine the interfaces between the software requirements and other elements of the operating environment, and the impact that the requirements will have.   Develop criteria for software testing. [ENG.4.BP3]   Use the software requirements to define acceptance criteria for the software product tests. Software product tests should demonstrate compliance with the software requirements.   Ensure consistency. [ENG.4.BP4]   Ensure consistency of system requirements analysis to software requirements analysis. Consistency is supported by establishing and maintaining traceability between system requirements and the software requirements when needed.   Evaluate and update software requirements. [ENG.4.BP5]   Evaluate the requirements with the customer, evaluate the impact of proposed changes for cost, schedule and technical impact, approve or reject changes, and update the software requirements specification.   Communicate software requirements. [ENG.4.BP6]   Establish communication mechanisms for dissemination of software requirements, and updates to requirements to all parties who will be using them.   Software Design [ENG.5]   The purpose of the process is to provide a design for the software that implement and can be verified against the requirements. Software Design [ENG.5]   The purpose of the process is to provide a design for the software that implement and can be verified against the requirements.   Outcomes   [1] A software architectural design is developed and baselined that describes the software elements that will implement the software requirements. [2] Internal and external interfaces of each software elements are defined. [3] A detailed design is developed that describes software units that can be built and tested. [4] Consistency and traceability are established between software requirements and software design.   Input Workproducts Output Workproducts                       17.8 Interface Requirements [2] 17.11 Software Requirements [1, 4]     4.1 Database Design [3, 4] 4.4 High Level Software Design [1, 2, 4] 4.5 Low Level Software Design [2, 3, 4] 11.2 Software Element [1] 13.22 Traceability Record [4]         17.13 Test Design Specification [3] Describe software architecture. [ENG.5.BP1]   Transform the software requirements into a software architecture design that describes the top-level structure and identifies its major software elements.   Define interfaces. [ENG.5.BP2]   Specify and document the external and internal interfaces between the software elements.   Develop detailed design. [ENG.5.BP3]   Decompose the software architectural design into a detailed design for each software element describing all software units to be produced and tested. Document software units and interfaces in a software design document.   Evaluate alternative software architectures. [ENG.5.BP4]   Define evaluation criteria for software architecture design. Evaluate alternative software architectures according to the defined criteria. Record the rationale for choosing the current software architecture.   Analyze the design for testability. [ENG.5.BP5]   Analyze the design for correctness and testability to ensure that the software units can be built and tested.   Ensure consistency. [ENG.5.BP6]   Ensure consistency of software requirements analysis to software design. Consistency is supported by establishing and maintaining traceability between software requirements and the software design when needed.   Software Construction [ENG.6]   The purpose of the process is to produce executable software units that properly reflect the software design. Software Construction [ENG.6]   The purpose of the process is to produce executable software units that properly reflect the software design.   Outcomes