<Condition after the use case is successfully executed > Main Success Scenario <visit Step Step Make sure Extensions If Condition, then Alternative Steps <List any extended steps/ scenarios that occur, other than the main success scenario.> Priority <indicate priority of high, medium or low) Special Requirements <Any system related special requirements needed to fulfill the use case> Open Questions <Notes and questions> 3.1.3 Mock-up <Provide the mock-up of the functionality or a mock-up of the entire page> 3.1.4 Functional Requirements <Describe the page details that are not captured in section 3.1.5 below. These may include any requirements related to Navigation Menu, Actions, transaction status, verification and validation requirements etc. Make sure each specification has a reference number and is explained in the following format.> Spec ID Specification Description Business Rules/ Data Dependency
<Specification Identifier> <Short explanation of the specification> <Any validation rules or business rules> <Note: Section 3.1.4 and section 3.1.5 may be combined if there are a few functionalities on a particular page> 3.1.5 Field level specifications <Specify all the data elements related to the functional requirement in both tables below.> Form Elements: Field Label UI Control Mand? Editable Data Type Value Set Default Value Data Example Data Source <Label name> what UI control will be on <specify if field is <specify if field is editable> <Specify the data type that will be used for this field> <If value is from the set, specify the entire value set here> <Specify if it should be defaulted to any value> <Provide an example of the data> <Specify the source of the data> 1 User name textbox Yes Yes none NA agujar User entry Form Business Rules and Dependencies: Field Label Validation / Business Rules Error Messages Data Additional Info/ Notes <Label name> <Specify the validation rules and/ or business rules applicable to the form element> <List the error message that should be displayed and under what conditions> <Specify if there are any date <Provide any additional information here> Example: User name User name shall be a valid Stanford Sunet ID For incorrect user name display on setFocusOff: “Please provide a valid user name” None Access prohibited only to Stanford affiliates. For non-Stanford affiliates,
check call-out 3.1 Buttons, Links and Icons: Button, Link, Icon Label OnClick Other Event Visible Enabled Vs Disabled Navigate To Validation Dependencies <Button label name> <Specify the operation that would be performed on an event> <Specify the operation that would be performed on other events> <Specify default visibility of the button> <Specify if button is enabled or disabled and the condition, if any> <Specify the link where the page will be if any> <Specify the validation rules on operation of the button> <Mention if there are any dependencies on other form elements and/ or buttons> Example: Submit Verify if user name and password are correct. If yes, log the user into the system. OnMouseHover display the following message: “Please provide your details to sign in> Yes, always Disabled, by default. Enabled, after first key entered in either username or password field. User Dashboard page Verify if Username is a valid sunet ID and user name and password match with registry data. Disable the New user functionality on subsequent pages if user logs in through this button. System Configurations <Provide an overview of all the steps or the set ups required to configure an application/program. Also state the intent or purpose behind each set up or configuration. Discuss the possible alternatives, customizations, workaround’s, and dependencies in a particular configuration. In case of Oracle applications, please list all applicable BR100’s or Application set up documents>