Please review Custom Development Request to understand the overall custom development process. 

This guide will cover the Functional Specification and Build process.

Functional Specifications (FS)

Creating a Functional Specification

Before drafting function specifications, user must create a "Development" card in Jira for each FS as mentioned below. 

1. Create a Development card in the corresponding Jira Build board.
2. Please take note of the Jira ID. It will be used as a prefix for the FS title.
   
3. Update the details under Overview tab. Leave the assigned developer or tech reviewer field empty and the development team will update it. 
4. Dependent Builds (i.e., FS from the same request card) will be lined using linked work item methods.
   
   • Click on "+ Add" and selecting "Linked work item".
     
   • Choose "is related to" relationship and linked to the request and related development card. All development card are expected to be linked to its request card. 
     Please note that the linked work item are not transitive. Meaning if A & B are linked and B & C are linked, A & C are not automatically linked and users will need to create the link between A & C. 
      
5. Related Builds (i.e., different request card) should be group together using the "Custom Development Grouping".
   

   It is the functional consultant's responsibility to link and group dependent and related builds so that the development team can work out the dependency and schedule builds correctly. 

6. After creating the development card, it will be in "FS in Progress" status and user can start drafting their FS in Confluence. Please refer to Creating Functional Specifications.
7. After creating your FS page, link your FS & development card by using "Web Link" as shown below and enter your FS URL. Do not use "Existing Confluence content" as the integration between Jira and Confluence is not configured.
   

Functional Specification Review and Approval Process

The following diagram describes the Spec process and the corresponding statuses (highlighted in blue) in Confluence.

Please note the following:

• Normal Approval flow: 2 Peer endorsement, 1 Tech reviewer endorsement and Pod Lead approval.
  • The Tech Review step will ensure alignment with the Specification Acceptance Checklist. Ensure you review this before submitting a spec to avoid delays. 
  • The Tech Reviewer needs to fill in the FS Tech Review Checklist spreadsheet and store it in the R4 Build Documentation folder.
• If document is updated after Tech review, the status will automatically move to "Edited following Tech Review" and will require tech reviewer endorsement before Pod lead approval.
• After Pod lead approval, FS page is published and is visible to anyone outside SyWay project.
• If the document is updated after Pod lead approval, the status will automatically move to "Edited following Approval". 
  • During this state, the approved version will be visible to everyone. 
  • SyWay project team can view the edited version via the "view" link next to the workflow status
  • Pod lead approval is required to move back to approved status and publish the edited version.  
• Document can also be moved "On Hold" status by design authority and during this status, a spec is not visible to all users except DA. 

Build Process

The following stages will be managed in Jira. 

*) Person who will perform the activity and move the Jira card to the next stage.

During the build process, tech reviewers have the permission to move the cards to the following statuses and reinstantiate.

• On-Hold - If build is to be paused.
• Descope - If build is not required.