Delivering quality processes in e-Builder requires quality requirements gathering. While we strive to eliminate bugs in processes there is always a chance that something will be missed. The following basic guidelines help set the stage for delivering excellence in our business requirements gathering and development processes. We first start with a request. An AI (action item) is prefixed to display the type of work described with the prefix identifiers: DEV – Development of a new process or report MOD – A modification of an existing process or report BFX – break fix of an existing process or report MNT – Maintenance of an existing process, report, user or other eB entity (e.g. a project or some component or sub-component of a project) REV – Review /Analysis of a new or existing process, report, rights or permission, etc. DOC – For all mail merge work (we to track this separately from MOD/DEV/BFX/REV/MNT) ADM – any basic eBAdmin administrative work performed (e.g. setting up new users, projects etc.) The description section of an AI should provide the business challenge, case and a brief statement regarding the analysis done – including who wrote the spec up and who was spoken to elicit the requirements. At this point we haven't actually coded anything in eB. Attachments to the AI: a) This includes the spreadsheet template(provided) screen shots and mock ups all in JPEG's or Visio – not in the product/code, spreadsheets with a proper format. b) The creation of new steps or page layouts need to be identified including: all data fields and their type length, parameters, exclusions, etc., shared page layouts, all conditionals their business rules and their names, all actions a user can take and their names and any special additional , and all flow paths. We also work to identify with a mock-up how a page layout should flow (from data field to data field as if one was tabbing through the page), what the general layout should be, any page layout filed groupings should be, and any help text or tool tip data you require. We identify and label required fields, conditionals on fields (for example, any data entry or language you want flagged or returned back to the actor/user). reporting needs (mock-ups, data fields, etc.). At this time we also check to see if we already have these fields in the system and or consider any fields that may be better suited as global fields rather than simply only found "in a process". c) If this is a rework of an existing workflow we provide a before and after of workflow processes the customer is asking to be changed. Note: The before is a screen shot of the existing workflow or page changing and the after is a Visio mock up. Note: this "mockup" can be done in our eB development sandbox - we call affectionately call T-Rex. We catalog our work in a requirements spreadsheet template. The AI # is identified and this artifact is attached to the AI. Work begins after we have gathered enough requirements to start the coding and testing of the work. The above is intended for processes work that requires change management review. 95% of our work is Administrative, Break Fix, and slight Modifications that do not require the level of detail noted above. However, we do review all BFX, MOD types to find patterns that may result in larger efforts. If you have any questions regarding our business requirements and development practices please don't hesitate to speak to the program manager of Reporting and Analytics. Note: if a customer has something in mind from another organization that he/she has had created or used in the past and would like us to model that, that is OK. Please request a screen shot of it, provided he/she has permission to copy another organizations workflow(s)/property. Any proof of origin or ownership and or permission to use if we are given a screen shot of another organizations workflow is required. | 
