Finish gathering requirements

Solution development best practice guide

  1. Build a development team
  2. Start the discovery process
  3. Build a proof-of-concept
  4. Finish gathering requirements
  5. Develop the solution
  6. Support and maintain the solution

At this point in development, you should have a thorough understanding of the following:

  • The overall problem and the solution
  • What T-Codes/SAP Tables will be used
  • What each Winshuttle Transaction/Query Script will do/how it will work
  • Who will participate in the workflow and what tasks each participant will be completing, such as:
    • Approve/Reject
    • Data Entry
  • What the User Experience (UX) will be like.
  • What the form will look like (mockup) and the style guide governing it.
  • Time Frames for each task/process in the workflow.
  • The type of content displayed to each user as the form is routed through the workflow, including:
    • Form Views
    • What content can be edited, and what content will be read-only.
    • What content will be hidden or displayed (based on form views)
  • Rejection scenarios for when an item is rejected, including:
    • When/how to end the process if it is rejected
    • When/how to send a task/form back to the originator for corrections
    • When/how to restart an approval process, and loops to complete until something is approved
  • Escalation scenarios (if required)
  • Email Notifications

    Changes in requirements can be difficult to integrate later in the development phase. Finalize and lock your requirements to ensure a successful and speedy development process. Any requirement changes that are not ‘show stoppers’ should be handled as a revision after the initial Solution is completed.

It is also important to understand each of the different requirements for each role. Also, it is perfectly acceptable to have different documents for script requirements, form requirements, and workflow requirements. Script developers (for example) have different requirements than form designers.

The end result of this phase should be a completed and detailed requirements document.

The requirements document should be detailed enough to provide specifications down to the field and task level. Ideally, it should include the following elements:

  • A description of each field
  • How each field will be labeled
  • What logic or calculations (if any) are performed when data is entered into each field
  • The field type for each field (drop down, text box, etc..),
  • What data connection (if any) each field requires (SharePoint, SQL, etc.)
  • Whether or not the field is displayed/hidden

Detailed requirements help the Form Designer understand exactly what needs to be developed in the form and workflow. Missing or unspecified elements can extend development time.