Writing an SOW

Review forms to be created: Determine what information goes on the form that will be filled out/created, and how it gets there.
To determine how it gets there: Either it already exists in 1staff, or the user will be typing it in.
If it comes from 1staff, you can use the level up tool, and click Logical Names. Then you will be able to see all of the Logical Names that the developers will need to do what they do.

Custom Rules: Consider whether any of the information on the form will arrive from eApp or eConsent, if it does, then the eApp/eConsent will need to be set as the parent rule for the task's custom rule. Either reference the current rule, or if there is a new rule that is being made, create and then reference that new custom rule.

Mock-ups: Decide based on the type of the forms whether the mock-up needs to reference the SOW for fields.
On sign only forms it may not be needed.
If the mock-up is going to populate information from 1staff, then it needs to reference the fields on the mock-up to the SOW.
Always have as much information as possible collected from 1staff.
If there is information that may or may not be in 1staff, then note to the developer, “this data may or may not be there, if the data is not there, please make it field that the candidate can fill in”. 
The mock-up is just for the look, and not to display the logical names. So the mock-up just needs to be a PowerPoint that represents what the form will look like.
Screenshots do not tend to render well. Try to use previous mock-ups.
Using Word instead of PowerPoint might be a good solution to keep the mock-up from being blurry. Although it is not very important if the image is blurry because it is just to give the developers a general idea of what the form will look like.
At this point, Michael should have an example of a previous mock-up to go from and should not have to create a mock-up from scratch. When there needs to be a mock-up made from scratch, then Jenny will provide further training.

General Advice: You are writing instructions and assuming that the developers know nothing about the form or what the forms are supposed to do.

To proofread a SOW: Try to follow your own instructions and see where the gaps are. Go through the form, field by field and make sure that everything is noted.