Software Engineering Software Requirements Specification (SRS) Document

Transcription

1 Software Engineering Software Requirements Specification (SRS) Document Matt Bartyczak, Clayton Kinard, Nick Pierson, Jordan Tallent Radford University April 7, 2015

2 Revisions Version Primary Author(s) Description of Version Date Completed Version 1.3 Clayton Kinard, Jordan Tallent This is the initial version of the Requirements Document. 04/07/15 Review & Approval Requirements Document Approval History Approving Party Version Approved Signature Date Project Manager 1.3 Matt Bartyczak 04/07/15 Dr. T. L. Lewis Requirements Document Review History Reviewer Version Reviewed Signature Date Group Member 1.3 Matt Bartyczak 04/07/15 Group Member 1.3 Clayton Kinard 04/07/15 Group Member 1.3 Nick Pierson 04/07/15 Group Member 1.3 Jordan Tallent 04/07/15 Artificial Living Plants 1

3 Contents 1. Introduction General Description Functional Requirements Interface Requirements Performance Requirements Other non-functional attributes Security Reliability Maintainability Reusability Operational Scenarios Preliminary Use Case Models and Sequence Diagrams Updated Schedule Appendices Artificial Living Plants 2

4 1. Introduction 1.1 Purpose of this document This document contains the system requirements of the FSM Simulator program. The development team will use this document to specify and formalize the requirements of the system. The client, Dr. Edward Okie, will also be able to reference this document in order to ensure that the capabilities of the system align with his idea of how the system should function. 1.2 Scope of this document This document will contain descriptions of both the functional and nonfunctional requirements of the FSM Simulator project. A set of preliminary use case models and sequence diagrams will also be included. The requirements elicitation team includes the Artificial Living Plants development team (Matt Bartyczak, Clayton Kinard, Nick Pierson, and Jordan Tallent) along with the client and intended user (Dr. Edward Okie). The team must develop the FSM Simulator system within the Spring 15 semester. Currently, the team intends to develop the system using HTML and JavaScript. 1.3 Business Context Dr. Edward Okie is sponsoring the FSM Simulator project. Dr. Okie is a professor of computer science at Radford University and teaches Computability Theory and Formal Languages, a class that instructs students in the behavior of finite state machines. 2. General Description 2.1 Product Functions The FSM Simulator will allow users to design a finite state machine using a graphical interface. The user should also be able to input and test strings using the machine. 2.2 Similar System Information The finite state machine simulator found at ivanzuzak.info is a similar system. This finite state machine simulator allows the user to input a FSM definition, consisting of a list of states, the symbols in the alphabet, transitions, starting state, and accept states. The user enters these fields as text and the website generates an image of the FSM. This website also allows the user to test a string in the FSM, either reading the string one symbol at a time or reading the entire string at once. A change in color indicates the current state. This system has several features in common with the FSM Simulator project. The user is able to create a FSM and use that FSM to test strings. Other interesting features are the ability to randomly generate a FSM and the inclusion of nondeterminism. However, the user should enter the FSM as text and cannot edit the visual representation of the machine. The finite state machine simulator found at is a similar system. This finite state machine simulator allows the user to drop states on a canvas, identify initial states, identify final states and create transitions between the states. The alphabet is predefined as {a, b}, and the user cannot edit the existing alphabet. Artificial Living Plants 3

5 It allows the user to run strings on the machine and delete transitions and states. The user input is limited and the machine is limited to the predefined alphabet. The machine will run an input string of your choice but again the string is limited to A and B. The finite state machine simulator found at is a similar system. This machine allows the user to pick whether or not a state is an accept state or reject state. It gives you the ability to transition but only on a predefined alphabet of {0, 1}. The machine will take an input string and return whether it accepts or rejects the string. This system is similar to, but much more restricted than, what our machine will be. 2.3 User Characteristics Users should be able to see a typical web page and use a mouse and keyboard. Some understanding of finite state machines would also be helpful. The intended users are computer science students seeking a better understanding of FSM construction and behavior. 2.4 User Problem Statement Computer science students wanting to design and test finite state machines are currently limited to two options: either drawing the FSM on paper and tracing its behavior by hand, or else dedicating the time to encode a FSM in a programming language. The FSM Simulator will allow students to design and test FSMs quickly and efficiently, allowing students to save time and effort when studying computability. 2.5 User Objectives The user should be able to design and test a finite state machine using a graphical interface. Using a mouse, users should be able to place and move states and transitions on a canvas. The user should also be able to enter the desired characters to be included in the FSM s alphabet. Once the user has created a FSM, the user should be able to input strings and test those strings using the FSM. 2.6 General Constraints The system should respond in less than a second in order to maintain the transparency of the system when solving the user s problem. The system should be compatible with all of the major web browsers, including the latest versions of Google Chrome, Mozilla Firefox, Microsoft Internet Explorer, and Safari. Criticality Scale: 1 = Low to 5 = High 3. Functional Requirements 1. The system shall provide a canvas upon which the user can design a FSM. The GUI shall contain a blank canvas for creating a FSM. The canvas should appear as a plain white rectangle within the GUI. As states and transitions are added to the FSM, they should appear and be persistent on the canvas. 5 Artificial Living Plants 4

6 The canvas should be created using an HTML canvas element. The canvas should be located in the center-left section of the GUI and be the largest element within the GUI. Preconditions 1. The GUI should be visible to the user. 1. The canvas should persist within the GUI. The user s computer may not be able to render the canvas. To mitigate this risk, the GUI will be developed using the current standard version of HTML. N/A 2. The system shall provide a button for enabling the Add State option. The GUI shall contain a button, the Add State button, which the user should be able to click. This button should appear immediately above the canvas. Clicking this button shall enable the user to place states on the canvas by clicking the canvas with the mouse cursor. Once the button is clicked, its color should be altered to indicate that the Add State option is currently active. The color of all other option buttons should be set to the default button color. 5 The Add State button should be created using the HTML button element. When the button is clicked, its color should change to indicate that the Add State option is currently active. While this mode is active, the user should be able to add states to the canvas by clicking the canvas with a mouse. Precondition 1. The GUI should be visible to the user. Postcondition 1. The Add State button should be persistent within the GUI. Once the user clicks the Add State button, the Add State option should be active and the button s color should be altered to indicate that this option is currently active. The user s computer may not be able to render the button. The button s color change may not be rendered within the GUI. To mitigate these risks, the GUI will be developed using the current standard version of HTML. Before the Add State button can be positioned correctly within the GUI, the canvas should be created within the GUI. 3. The system shall provide a button for enabling the Add Transition option. The GUI shall contain a button, the Add Transition button, which the user should be able to click. This button should appear immediately above the canvas. Clicking this button shall enable the user to place transitions between states on the canvas. Once the button is clicked, its color should be altered to indicate that the Artificial Living Plants 5

7 Add Transition option is currently active. The color of all other option buttons should be set to the default button color. 5 The Add Transition button should be created using the HTML button element. When the button is clicked, its color should change to indicate that the Add Transition option is currently active. While this mode is active, the user should be able to add transitions to the canvas by clicking first the starting state then the ending state with a mouse. Precondition 1. The GUI should be visible to the user. Postcondition 1. The Add Transition button should be persistent within the GUI. Once the user clicks the Add Transition button, the Add Transition option should be active and the button s color should be altered to indicate that this option is currently active. The user s computer may not be able to render the button. The button s color change may not be rendered within the GUI. To mitigate these risks, the GUI will be developed using the current standard version of HTML. Before the Add Transition button can be positioned correctly within the GUI, the canvas should be created within the GUI. 4. The system shall provide a button for enabling the Move State option. The GUI shall contain a button, the Move State button, which the user should be able to click. This button should appear immediately above the canvas. Clicking this button shall allow the user to move states on the canvas. Once the button is clicked, its color should be altered to indicate that the Move State option is currently active. The color of all other option buttons should be set to the default button color. 3 The Move State button should be created using the HTML button element. When the button is clicked, its color should change to indicate that the Move State option is currently active. While this mode is active, the user should be able to move states on the canvas by dragging and dropping them with the mouse. Precondition 1. The GUI should be visible to the user. Postcondition 1. The Move State button shall be visible to the user. Once the button is clicked, the Move State option should be active and the button s color should be altered to indicate that this option is currently active. The user s computer may not be able to render the button. The button s color Artificial Living Plants 6

8 change may not be rendered within the GUI. To mitigate these risks, the GUI will be developed using the current standard version of HTML. Before the Move State button can be positioned correctly within the GUI, the canvas should be created within the GUI. 5. The system shall provide a button for enabling the Remove Item option. The GUI shall contain a button, the Remove Item button, which the user should be able to click. This button should appear immediately above the canvas. Clicking this button shall enable the user to remove states and transitions from the canvas. Once the button is clicked, its color should be altered to indicate that the Move State option is currently active. The color of all other option buttons should be set to the default button color. 3 The Remove Item button should be created using the HTML button element. When the button is clicked, its color should change to indicate that the Remove Item option is currently active. While this mode is active, the user should be able to remove states and transitions from the canvas by clicking them with the mouse. Precondition 1. The GUI should be visible to the user. Postcondition 1. The Remove Item button shall be visible to the user. Once the button is clicked, the Remove Item option should be active and the button s color should be altered to indicate that this option is currently active. The user s computer may not be able to render the button. The button s color change may not be rendered within the GUI. To mitigate these risks, the GUI will be developed using the current standard version of HTML. If the user does not have access to a mouse, they may not be able to click the button. To mitigate this risk, the button should be traversable via the Tab key and clickable with the Enter key. Before the Remove Item button can be positioned correctly within the GUI, the canvas should be created within the GUI. 6. The system shall provide a text field for defining the alphabet. A text field should, the Alphabet Field, should be persistent within the GUI. This text field should appear immediately above the option buttons (Add State, Add Transition, etc.). The user should be able to enter characters into the Alphabet Field. 4 The Alphabet Field should be created using the HTML text field element. When Artificial Living Plants 7

9 the user clicks in the Alphabet Field, a cursor should appear, indicating the current entry point for the user s input. Preconditions 1. The GUI should be visible to the user. 1. The Alphabet Field should persist within the GUI. The user s computer may not be able to render the text field. To mitigate this risk, the GUI will be developed using the current standard version of HTML. Before the Alphabet Field can be positioned correctly within the GUI, the option buttons (Add State, Add Transition, etc.) should be persistent within the GUI. 7. The system shall provide a button for setting the alphabet to the currently entered characters in the alphabet text field. The GUI should contain a button, the Set Alphabet button that the user should be able to click. This button should be immediately adjacent to the Alphabet Field. Clicking this button should set the space-delineated characters currently in the Alphabet Field to the alphabet that the FSM will consider. 4 The button shall be created using the HTML button element. When the user clicks the button, all of and only the space-delineated characters in the Alphabet Field should be saved as the alphabet that the FSM will consider. Preconditions 1. The GUI shall be visible to the user. 1. The Set Alphabet button should persist within the GUI. Once the button has been pressed, the FSM s alphabet should be set to all of and only the space-delineated characters in the Alphabet Field. The user s computer may not be able to render the button. To mitigate this risk, the GUI will be developed using the current standard version of HTML. Before the Set Alphabet button can be positioned correctly, the Alphabet Field should be persistent within the GUI. 8. The system shall provide a text field for entering an input string. A text field, the String Field, should be persistent within the GUI below the canvas. The user should be able to enter a string of characters into the String Field. 4 The String Field should be created using the HTML text field element. The user should be able to select the String Field by clicking on it with the mouse. Once the Artificial Living Plants 8

10 String Field has been selected, the user should be able to enter a string of characters into the String Field using the keyboard. Preconditions 1. The GUI should be visible to the user. 1. The String Field should persist within the GUI. The user s computer may not be able to render the text field. To mitigate this risk, the GUI will be developed using the current standard version of HTML. If the user does not have access to a keyboard, they may not be able to enter characters into the String Field. Before the String Field can be position correctly within the GUI; the canvas should be persistent within the GUI. 9. The system shall display the previously ran input strings. The GUI shall contain a table, the Checked Strings table, within the upper-right corner. This table should contain two columns and have entries for all of Input Strings that have been run on the current FSM, up to a maximum of 20 Input Strings. The first column of each entry should have the Input String that was ran, and the second column should contain the letter A if the Input String was accepted by the FSM or the letter R if the Input String was rejected by the FSM. The entries should also appear with a green background in the Input String was accepted or a red background if the Input String was rejected. The Input Strings should be listed with the most recent at the top. 2 After the system has determined the acceptance or rejection of an Input String, the system should add a row into the Checked Strings table. Each row s background color should be either red or green, in accordance with the criteria listed above. If the Checked Strings table already contains the maximum number of Input Strings, the Input String that has been in the table the longest should be removed. N/A Before the system can add an Input String to the Checked Strings table, the user should have either ran an entire input String through the FSM using the Read Character or Read String button or checked the acceptance or rejection of an Input String using the Check String button. 10. The user shall be able to add a state to the canvas using a mouse while the Add State option is active. By clicking the canvas while the Add State option is active, the user shall be able to add a state to the FSM. This state should appear as an empty circle with the state s name in the center. Reject states should appear as single circles. Accept states should appear as a circle within a circle. By default, a newly placed state should be a reject state and its name should be an empty string. Artificial Living Plants 9

11 5 The state should be a persistent element within the canvas. The state should also be added to the internal representation of the FSM. Preconditions 1. The user should have clicked the Add State button to enable the Add State option, and then clicked on the canvas. 1. The new should persist on the canvas, and the state should be added to the internal representation of the FSM. If the user does not have access to a mouse, they may be unable to click the canvas, as adding a state is dependent on clicking the canvas. Before a state can be added, the canvas should be provided and the Add State button should be provided. 11. The first state added to a blank canvas should be assigned as the initial state. The first state added to a blank canvas should be the set as the FSM s initial state. The initial state should have an arrow pointing at it, making contact with the edge of the state. 3 The first state added to a blank canvas should become the initial state within the internal representation of the FSM. An arrow indicating the start state should be made visible on the canvas. Preconditions 1. The user should have added a state to a blank canvas 1. The new state should be the FSM s initial state, with an arrow pointing at the state persisting against the state. If the user does not have access to a mouse, they may be unable to click the canvas, as adding a new state is dependent on clicking the canvas. Before a first state can be added, the canvas should be provided and the Add State button should be provided. 12. The user shall be able to toggle a state's acceptance mode by double-clicking the state. Double-clicking a reject state should convert it to an accept state. Double-clicking an accept state should convert it to a reject state. 1 Each state on the canvas shall react to a double click by toggling its Accept Artificial Living Plants 10

12 boolean value. The state should then be rendered properly, with single circles for reject states and double circles for accept states. Preconditions 1. The user should have double-clicked the state. 1. The state s acceptance mode should be toggle opposite of its previous mode and be rendered according to its new acceptance mode. If the user does not have access to a mouse, they may be unable to access this feature. To mitigate this risk, the user shall also be able to toggle a state s acceptance mode via accessing the state s context menu. Before the state s acceptance mode can be toggled; the state should first be placed on the canvas. 13. The system shall provide the user with a context menu when a state is right-clicked. When the user right-clicks on a state, a context menu should appear with options for altering the state. The options available should consist of removing the state, renaming the state, assigning the state as the initial state, unassigning the initial state, and toggling the state s acceptance mode. The user should be able to select any of these options by clicking on the option within the context menu. The context menu should appear immediately adjacent to the state. The context menu should persist until the user either selects an option or clicks somewhere within the GUI outside of the context menu. 4 The system shall display a context menu containing options to alter a state when the user right-clicks on that state. Clicking any of these options should alter the state, or the entire FSM, according to the option selected. Preconditions 1. The user should have right-clicked a state. 1. The context menu should persist immediately adjacent to the state that it affects. If the user does not have access to a mouse, they may not be able to access the context menu. A state should be visible on the canvas in order for the user to double-click the state and access the context menu. 14. The user shall be able to remove a state from the canvas using the state's context menu. A state s context menu should contain an option for removing the state from the FSM. When the user clicks this option, the state should no longer be visible on the Artificial Living Plants 11

13 canvas and should be removed from the FSM. Any transitions to or from that state should also be removed. 3 When the user selects the remove state option on the context list, the state is no longer rendered on the canvas. The state is also removed from the internal representation of the FSM, along with any transitions from that state. Preconditions 1. The user should have selected the remove state option from a state s context menu. 1. The state should be removed from both the canvas and the internal representation of the FSM. Any transitions to or from the state should also be removed. If the user does not have access to a mouse, they may not be able to select the remove state option from the context menu. Before the remove state option can be selected; both the state and the context menu should be visible. 15. The user shall be able to rename a state using the state's context menu. A state s context menu should contain an option for changing the state s name. Clicking this option should provide the user with a text field where the user may enter the state s new name. Once the state s new name has been entered, the user shall be able to assign the new name by pressing the Enter key. This should change the state s name and render the new name in the center of the state. 1 When the user clicks the change name option from the context menu, the text field should appear in which the user may enter a string. Pressing the Enter key should change the name of the state in the internal representation of the state to the string that is currently in the text field. The state s name value should then be persistent within the state within the GUI. Preconditions 1. The user shall have selected the change name options from the state s context menu, possibly altered the string in the text field, and pressed the enter key. 1. The state s name value should be updated and the new name value should be persistent within the state within the GUI. If the user does not have access to a mouse, they may not be able to select the change name option. If the user does not have access to a keyboard, they may not be able to enter the state s new name. Before the rename state option can be selected; both the state and the context Artificial Living Plants 12

14 menu should be visible. 16. The user shall be able to assign a state as the initial state using the state's context menu. A state s context menu should contain an option to set the state as the initial state. The exception to this rule is the current initial state, for which the set as initial state option should be grayed out and unselectable. Selecting this option should make the currently selected state the new initial state, and the previous initial state should do longer be the initial state. 3 When the user clicks the set as initial state option from the state s context menu, the selected state should become the initial state of the internal representation of the FSM. The previous initial state should remain in the FSM, but should no longer be the initial state. The arrow that represents the initial state should be moved to the new initial state. Preconditions 1. The user should have selected the set as initial state option from the state s context menu and the selected state should not be the current initial state. 1. The selected state should be the current initial state. If the user does not have access to a mouse, they may not be able to select the set as initial state option. Before the user can select the set as initial state option; the state s context menu should be visible. 17. The user shall be able to toggle a state's acceptance mode using the state's context menu. A state s context menu should contain an option for toggling the state s acceptance mode. Clicking the toggle acceptance option should convert accept states into reject states and convert reject states to accept states. 3 Clicking the toggle acceptance option on a state s context menu should toggle the state s Accept boolean value. The state should then be rendered properly, with single circles for reject states and double circles for accept states. Preconditions 1. The user should have selected the toggle acceptance option from the state s context menu. 1. The state s acceptance mode should be toggle opposite of its previous mode and be rendered according to its new acceptance mode. Artificial Living Plants 13

15 If the user does not have access to a mouse, they may not be able to select the toggle acceptance option. Before the user can select the toggle acceptance option; the state s context menu should be visible. 18. The user shall be able to create a transition between two states while the Add Transition option is active. The user should be able to create a transition by clicking the transition s starting state then clicking the transition's ending state with the mouse cursor while Add Transition option is active. Transitions to and from the same state should be loops. Once the transition s starting and ending states have been defined, a dropdown checkbox menu should be provided for selecting the characters that will trigger the transition. 5 When the user clicks a state while the Add Transition option is active, the state should change color to indicate that a transition is being defined from it. Clicking a second state should create a transition between the two states, while licking the first state a second time should create a loop. This transition should be rendered as an arrow leading from the first state to the second state. If the transition is a loop, it should be rendered as an arrow curving back to the state. If the user clicks outside the canvas after clicking the first state but before clicking the second state, the transition creation should be canceled. Preconditions 1. The Add Transition option should be active and at least one state should be visible on the canvas. 1. The transition should be rendered as a persistent arrow leading to the first state to the second state. A dropdown checkbox menu should be visible for selecting the characters that trigger the transition. The transition should also exist in the internal representation of the FSM. If the user does not have access to a mouse, they may be unable to select the starting and ending states of the transition. Before the user can create a transition, the Add Transition button should be available and at least one state should be visible on the canvas. 19. The user shall be able to select the characters that trigger a transition from a dropdown checkbox menu. When the user creates a transition, a character selection menu (a dropdown menu containing checkboxes for each character in the alphabet) should appear immediately below the center of the transition arrow. The user should be able to check any or all of these boxes. Checking a box makes the selected characters Artificial Living Plants 14

16 trigger the transition from the transition s starting state to its ending state. Clicking anywhere within the GUI outside of the character selection menu should set any selected characters as the transition s triggers. 4 The character selection menu should contain a checkbox for each character in the Alphabet. The user should be able to select which characters trigger a transition by clicking the entries to check and uncheck the check boxes. Once the character selection menu has been dismissed, the selected characters should be added to the transition s list of trigger characters. Preconditions 1. The user should have created a transition on the canvas. 1. The transition s trigger characters should be set to all and only the characters that were selected in the character selection menu. N/A Before the character selection menu appears, the user should have created a transition. 20. The system shall display the character selection box for a transition when the user double-clicks the transition. When the user double-clicks a transition, the character selection menu should appear immediately below the center of the transition. All and only the currently selected trigger characters should be checked. The user should be able to select and deselect any character to alter the transition s trigger characters. Clicking anywhere within the GUI outside of the character selection menu should set any selected characters as the transition s trigger characters. 1 Double-clicking a transition should cause that transition s character selection menu to appear. The character selection menu should contain a checkbox for each character in the Alphabet. The user should be able to select which characters trigger a transition by clicking the entries to check and uncheck the check boxes. Once the character selection menu has been dismissed, the selected characters should be added to the transition s list of trigger characters. Any currently unselected characters that are in the transition s list of trigger characters should be removed from that list. Preconditions N/A 1. The user should have double-clicked a transition on the canvas. 1. The transition s trigger characters should be set to all and only the characters that were selected in the character selection menu. Artificial Living Plants 15

17 Before the character selection menu appears, the selected transition should be visible on the canvas. 21. The system shall provide the user with a context menu when a transition is rightclicked. When the user right-clicks on a transition, a context menu should appear with options for altering the transition. The options available should consist of removing the state and resetting the transitions trigger characters. The user should be able to select any of these options by clicking on the option within the context menu. The context menu should appear immediately below the center of the transition. The context menu should persist until the user either selects an option or clicks somewhere within the GUI outside of the context menu. 4 The system shall display a context menu containing options to alter a transition when the user right-clicks on that state. Clicking any of these options should alter the transition, or the entire FSM, according to the option selected. Preconditions 1. The user should have right-clicked a transition. 1. The context menu should persist immediately below the center of the transition it affects. If the user does not have access to a mouse, they may not be able to access the context menu. A transition should be visible on the canvas in order for the user to double-click the transition and access the context menu. 22. The user shall be able to remove a transition from the canvas using the transition's context menu. A transition s context menu should contain an option for removing the transition from the FSM. When the user clicks this option, the transition should no longer be visible on the canvas and should be removed from the FSM. 3 When the user selects the remove transition option on the context list, the transition is no longer rendered on the canvas. The transition is also removed from the internal representation of the FSM. Preconditions 1. The user should have selected the remove transition option from a transition s context menu. 1. The transition should be removed from both the canvas and the internal representation of the FSM. Artificial Living Plants 16

18 If the user does not have access to a mouse, they may not be able to select the remove transition option from the context menu. Before the remove transition option can be selected; both the transition and the context menu should be visible. 23. The user shall be able to access the character selection box for a transition by using the transition's context menu. A transition s context menu should contain an option for altering the transition s trigger characters. When the user selects this option, the character selection menu should appear immediately below the center of the transition. All and only the currently selected trigger characters should be checked. The user should be able to select and deselect any character to alter the transition s trigger characters. Clicking anywhere within the GUI outside of the character selection menu should set any selected characters as the transition s trigger characters. 3 Selecting the alter characters option in a transition s context menu should cause that transition s character selection menu to appear. The character selection menu should contain a checkbox for each character in the Alphabet. The user should be able to select which characters trigger a transition by clicking the entries to check and uncheck the check boxes. Once the character selection menu has been dismissed, the selected characters should be added to the transition s list of trigger characters. Any currently unselected characters that are in the transition s list of trigger characters should be removed from that list. Preconditions 1. The user should have selected the select characters option on a transition s context menu. 1. The transition s trigger characters should be set to all and only the characters that the user selected in the character selection menu. N/A Before the character selection menu appears, the selected transition s context menu should be visible on the canvas. 24. The user shall be able to move a state on the canvas using the mouse while the Move State option is active. The user shall be able to drag and drop states on the canvas using the mouse. When a state is moved, all transitions to and from the state should move to maintain contact with the state. 3 When the user clicks and holds on a state, the state should be movable on the Artificial Living Plants 17

19 canvas. By moving the mouse, the user should be able to change the location of the state. When a state moves, the system should adjust any transitions to or from the state so that these transitions maintain contact with the state. If the user does not have access to a mouse, they may not be able to move the states. Before a state can be moved, a state should be visible on the canvas and the user should have clicked the Move State button. 25. The user shall be able to remove states from the canvas using the mouse while the Remove Item option is active. When the user clicks a state while the Remove Item option is active, the state should no longer be visible on the canvas and should be removed from the FSM. Any transitions to or from that state should also be removed. 3 When the user clicks on a state while the Remove Item option is active, the state is no longer rendered on the canvas. The state is also removed from the internal representation of the FSM, along with any transitions from that state. Preconditions 1. The Remove Item option should be active. 1. The state should be removed from both the canvas and the internal representation of the FSM. Any transitions to or from the state should also be removed. If the user does not have access to a mouse, they may not be able to click the state. Before the state is removed, the user should have clicked the Remove Item button and then clicked the state. 26. The user shall be able to remove transitions from the canvas using the mouse while the Remove Item option is active. 1. When the user clicks a transition while the Remove Item option is active, the transition should no longer be visible on the canvas and should be removed from the FSM. 3 When the user clicks on a transition while the Remove Item option is active, the transition is no longer rendered on the canvas. The transition is also removed from the internal representation of the FSM. Preconditions 1. The Remove Item option should be active. 1. The transition should be removed from both the canvas and the internal representation of the FSM. Artificial Living Plants 18

20 If the user does not have access to a mouse, they may not be able to click the transition. Before the transition is removed, the user should have clicked the Remove Item button and then clicked the transition. 27. The user shall be able to enter characters into the Alphabet Field. The user should be able to enter characters into the Alphabet Field. These characters should be delineated by a space. These characters should become the alphabet that the FSM considers when reading input strings. 4 The user should be able to enter characters into the alphabet text field using the keyboard. Preconditions 1. The alphabet text field should be visible to the user. 1. The alphabet text field should contain the characters that the user has entered. If the user does not have access to a keyboard, they may not be able to enter characters into the text field. Before the user may enter characters into the Alphabet Field; the Alphabet Field should be persistent within the GUI. 28. The system shall indicate the current character in the input string. Characters in the input string should be run through the FSM one-at-a-time, leftto-right. The system should indicate which character will be run through the FSM next by underlining that character within the Input Field As each character is run through the FSM, this indication should move to the next character to the right, until all characters in the input string have been read. 2 The system should display a line under the current character in the Input String. As characters are read from the Input String, the location of this line should be updated to indicate the new current character. N/A Before the current character can be indicated, the user should be able to enter a string of characters into the String Field. 29. The user shall be able to run the remaining characters through the FSM. Artificial Living Plants 19

21 The system shall provide a button, the Read String button, which the user should be able to click. This button should be located immediately to the right of the String Field. Clicking this button should cause all of the unread characters in the Input String to be run through the FSM. 5 When the user clicks the Read String button, each unread character of the Input String should be ran through the FSM, one at a time until all characters in the Input String have been ran through. There should be a half-second delay between running each character. As a character is ran, the current state of the FSM should change depending on the current character s transition from the previous state. The new state should be indicated within the GUI. If the current character is not the last character in the Input Field, the next character to the right should become the next current character. This process should continue until all characters have been run through the FSM. Preconditions 1. The user should have pressed the Read String button. 1. The FSM should be in its final state for reading the input string, this state should be indicated within the GUI, and the input string should be added to the Recent Strings table, with an indication of whether in was accepted or rejected. The system does not support nondeterminism. Therefore, if the current state has more than one transition on the current character, the FSM may not transition correctly from the current state. In order to alleviate this risk, the system shall determine that the current state has one and only one transition for the current character. If this is not the case, the system shall display an error message to the user. Before the Read String button can be positioned correctly within the GUI, the String Field should be persistent within the GUI. 30. The user shall be able to run the current character in the String Field through the FSM. The system shall provide a button, the Read Character button, which the user should be able to click. This button should be located immediately to the right of the Read String button. Clicking this button should cause the current character to be run through the FSM. Once the current character has been run through the FSM, the next character to the right, assuming there is one, should become the new current character. 1 When the user clicks the Read Character button, the current state of the FSM should change depending on the current character s transition from the previous state. The new state should be indicated within the GUI. If the current character is Artificial Living Plants 20

22 not the last character in the Input Field, the next character to the right should become the new current character. Precondition 1. The use should have pressed the Read Character Button Postcondition 1. The FSM should be in the proper state, having transitioned from its previous state according to the character that was ran through. If the character was not the last character in the input string, the next character should be indicated as the new current character. If the character was the last character in the input string, the input string should be added to the Recent Strings table, with an indication of whether in was accepted or rejected. The system does not support nondeterminism. Therefore, if the current state has more than one transition on the current character, the FSM may not transition correctly from the current state. In order to alleviate this risk, the system shall determine that the current state has one and only one transition for the current character. If this is not the case, the system shall display an error message to the user. Before the Read Character button can be positioned correctly within the GUI, the Read String button should be persistent within the GUI. 31. Before a character is ran through the FSM, the system shall check that the character is in the FSM s current alphabet. Only characters in the FSM s current alphabet can be run through the FSM. Before a character is run through the FSM, the system should check that that character is a part of the FSM s current alphabet. 5 When the user selects to run a character from the Input String through the FSM, the system should iterate through the Alphabet and ensure that the character being run through the FSM is in the Alphabet. If the character is in the Alphabet, the character should be run through the FSM. If the character is not in the Alphabet, the system should display a message to the user describing the situation. Preconditions 1. The user should have pressed either the Read String button, the Read Character button, or the Check String button. 1. If each character in the input string is a character in the Alphabet, then the system should execute the action for the respective button. If not, the system should display a message to the user describing the situation. N/A Before the system can check that a character is in the Alphabet, the user should Artificial Living Plants 21

23 have entered an Input String and defined the Alphabet. 32. The system shall indicate the current state of the FSM while reading an input string. As characters are run through the FSM, the current state of the FSM should be indicated. The current state should be indicated by a change in the state s color. 3 After a character has been read by the FSM, the FSM should change to a different state (or the same state if the transition was a loop). The current state should be rendered on the canvas in a different color than the other states. Preconditions 1. The user should have created a FSM on the canvas, entered an input string, and selected to run a character (or the whole string) through the FSM 1. The current state of the FSM should be rendered in a different color from the other states in the FSM. If the user is unable to see the color that indicates the current state, they may not be able to determine the current state of the FSM. Before the FSM s current state changes, the FSM should contain at least one state and the user should have pressed one of the buttons to run a character or string of characters through the FSM. 33. The system shall indicate if the input string is accepted when the final character is ran through the FSM. Once the final character in the Input String has been ran through the FSM, the system shall indicate whether the Input String was accepted or rejected by the FSM. This indication should appear immediately below the Input Field. If the string was accepted, the word Accepted should appear in green text below the Input Field. If the string was rejected, the word Rejected should appear in red text below the Input Field. 3 After the system has ran the final character of the Input String through the FSM, the current state of the FSM should be used to determine if the String was accepted or rejected. If the current state s Accept boolean value is true, the Input String is accepted. If the current state s Accept boolean value is false, the Input String is rejected. Preconditions 1. The final string of the Input Field should have been run through the FSM. 1. The system should display the acceptance or rejection of the Input String below the Input Field. Artificial Living Plants 22

24 If any of the characters in the Input String are not in the Alphabet, the system will be unable to trigger a transition on that character. To mitigate this risk, the system should check each character in the Input Field before any characters are ran through the FSM. If any states are missing transitions for a character in the Input String, the FSM may not be able to transition from the current state when that character is ran through. In order to mitigate this risk, the system should check that all states have on and only one transition for each character in the alphabet. Before the acceptance or rejection of the Input String can be determined; the user should have created a FSM and ran all of the characters in that Input String through the FSM. 34. The user shall be able to check if the FSM accepts the input string without visually running the input string through the FSM. The system shall provide a button, the Check String button that the user can click. This button should be located immediately to the right of the Read Character button. When the user clicks the Check String button, the system should determine if the FSM accepts or rejects the Input String without displaying any changes to the FSM on the canvas. The result of running the Input String through the FSM should appear immediately below the Input Field. If the string was accepted, the word Accepted should appear in green text below the Input Field. If the string was rejected, the word Rejected should appear in red text below the Input Field. 5 When the user clicks the Check String button, the entire Input String should be ran through only the internal representation of the FSM. After the system has ran the final character of the Input String through the FSM, the current state of the FSM should be used to determine if the String was accepted or rejected. If the current state s Accept boolean value is true, the Input String is accepted. If the current state s Accept boolean value is false, the Input String is rejected. The current state of the FSM and the current character should not be indicated on the GUI. Preconditions 1. The user should have created an FSM and clicked the Check String button 1. The system should display the acceptance or rejection of the Input String below the Input Field. If any of the characters in the Input String are not in the Alphabet, the system will be unable to trigger a transition on that character. To mitigate this risk, the system should check each character in the Input Field before any characters are ran through the FSM. If any states are missing transitions for a character in the Input String, the FSM may not be able to transition from the current state when that character is ran through. In order to mitigate this risk, the system should check that all states have on and only one transition for each character in the alphabet. Before the acceptance or rejection of the Input String can be determined; the user Artificial Living Plants 23

25 should have created a FSM. 35. The user shall be able to reload previously ran input strings as the current input string. The user should be able to load any previously ran Input String from the Checked Strings table into the Input Field by double-clicking the Input String in the Checked Strings table. 1 When the user double-clicks a previously ran Input String in the Checked Strings table, that Input String should be loaded into the Input Field. Any string that was in the Input Field should be removed. The FSM should be returned to its initial state. Precondition 1. A previously ran Input String should be visible in the Checked Strings table, and the user should have double-clicked on that Input String with the mouse. Postcondition 1. The previously ran Input String should be in the Input Field. If the user does not have access to a mouse, they may not be able to double-click on a previously ran Input String. Before the user can load a previous Input String into the Input Field, the user should have checked at least one Input String on the FSM. 36. The user shall be able to save strings to a Test Set. In order to facilitate quicker checking of a FSM, the user should be able to create a list of Input Strings and specify whether the FSM should accept or reject each of them. 2 The system shall store a list of Input Strings, called the Test Set. The system shall provide a button, the Add String button, within the GUI. The Add String button should be located immediately to the right of the Check String button. Clicking this button will cause the current Input String to be saved as an entry in the Test Set. Preconditions 1. The user should have clicked the Add String button. 1. The current Input String should be saved in the Test Set. If the user does not have access to a mouse, they may not be able to click the Add String button. Before the user can add an Input String to the Test Set; the Input Field should be Artificial Living Plants 24

26 persistent within the GUI. 37. The system shall display all strings in the Test Set. The GUI shall contain a table, the Test Strings table, within the lower-right corner. This table should contain three columns and have entries for all of the Test Strings that the user has added to the Test Set, up to a maximum of 20 Input Strings. The first column of each entry should contain the Test String, the string that is to be tested. The second column should contain the Test Strings Acceptance Box, a colored box that the user can click to toggle between red and green. Acceptance Boxes for Test Strings that the FSM should accept should be green and Acceptance Boxes for Test Strings that the FSM should reject should be red. The third column should contain a button with an X on it. The Test Strings should be listed with the most recently added string at the top. 2 When the user clicks the Add String button, a new row should be added to the Test Strings table to represent the new Test String. By default, the new Test String s Acceptance Box should be green. If the Test Strings table already contains the maximum number of Test Strings, the Test String that has been in the table the longest should be removed. Preconditions 1. The GUI should be visible to the user. 1. The Test Strings table should be persistent within the GUI. N/A Before the system can add an Input String to the Checked Strings table, the user should have either ran an entire input String through the FSM using the Read Character or Read String button or checked the acceptance or rejection of an Input String using the Check String button. 38. The user shall be able to remove strings from the Test Set. The user should be able to remove Test Strings from the Test Set by clicking the button marked with an X in that Test String s entry in the Test Strings table. 1 When the user clicks the X button in a Test String s entry in the Test Strings table, that Test String should be removed from the Test Set and should no longer have an entry in the Test Strings table. Preconditions 1. The Test Strings is in the Test Set and displayed in the Test Strings table. The user should have clicked the X button in that Test String s entry. Artificial Living Plants 25

27 1. The Test Strings should be removed from the Test Set and should not have an entry in the Test Strings table. If the user does not have access to a mouse, they may not be able to click the X button. Before the user can remove a Test String from the Test Set, the user should be able to add a String to the Test Set and the system should display that Test String in the Test Strings table. 39. The user shall be able to test all of the Test Strings in the Test Set. The GUI shall contain a button, the Test All button, which the user should be able to click. This button should appear immediately below the Test Strings table. Clicking this button should set each Test String s background color to green if the Test String passed the test, or red if the Test String failed the test. 2 The Test All button should be created using the HTML button element. When the button is clicked, the system should determine whether the FSM accepts or rejects each Test String in the Test Set. If the acceptance or rejection of a given Test String matches the color in the Test String s Acceptance Box (green for accept and red for reject), the Test String s background color should become green. Otherwise, the Test String s background color should become green. Precondition 1. The user should have clicked the Test All button. Postcondition 1. The background color of each Test String should be either green or red depending on whether the Test String passed or failed its test. The user s computer may not be able to render the button. The button s color change may not be rendered within the GUI. To mitigate these risks, the GUI will be developed using the current standard version of HTML. If the user does not have access to a mouse, they may not be able to click the Test All button. If the user is unable to distinguish green from red, the user may not be able to determine which Test Strings passed and which Test Strings failed. Before the Test All button can be positioned correctly within the GUI, the Test Strings table should be persistent within the GUI. 40. The system shall provide a colored checkbox for each string in the Test Set to indicate if that string should be accepted by the FSM. Each entry in the Test Strings table should contain a colored checkbox, the Test String s Acceptance Box, in its second column. The use should be able to click a Test String s Acceptance Box to toggle whether the FSM should accept or reject the Test String. The two possible colors for the Acceptance Box are green for acceptance and red for rejection. By default, a new Test String s Acceptance Box is green. Artificial Living Plants 26

28 2 The system should provide a colored text box in the second column of each entry in the Test Strings table. Clicking this checkbox should toggle its color between green and red. Precondition 1. The user should have added at least one Test String to the Test Set. Postcondition 1. A colored checkbox should be persistent within the GUI, in the second column of each entry in the Test Strings table. If the user does not have access to a mouse, they may not be able to toggle the color of the Acceptance Box. Before a Test String s Acceptance Box can be rendered, the Test Strings table should be persistent within the GUI. 41. The system shall indicate whether each string in the Test Set passed or failed the most recent test. After the user clicks the Test All button to check the acceptance or rejection of all the Test Strings, the background color of the Test String s entry in the Test Strings table should indicate whether the Test String passed or failed the test. If the Test String was accepted by the FSM and its Acceptance Box is green, the Test String s background color should be green. If the Test String was rejected by the FSM and its Acceptance Box is red, Test String s background color should be green. Otherwise, Test String s background color should be red. 2 When the user clicks the Test All button, the system should determine use the internal representation of the FSM to determine whether each FSM accepts or rejects each Test String. For each Test String, the image in that Test Strings entry in the Test Strings table should be updated to reflect whether the Test String passed or failed its test, as per the description described above. Precondition 1. The user should have clicked the Test All button. Postcondition 1. The background color of each Test String should indicate whether the Test String passed or failed its most recent test. If the user is unable to perceive the colors red or green, they may not be able to determine whether each Test String passed or failed the Test. Before the system can indicate whether the Test Strings passed their tests, the user should have created at least one Test String, created a FSM, and clicked the Test All button. The Test Strings table should also be persistent within the GUI. Artificial Living Plants 27

29 4. Interface Requirements 4.1 User Interfaces GUI The Graphical User Interface (GUI) should contain the following elements: A canvas where the user may create a FSM o Purpose: allows the user to create a FSM o Location: vertically centered, horizontally left o Largest element in the GUI The Creation Button suite o Purpose: allows the user to add and remove states and transitions from the canvas o Location: immediately above the upper-left corner of the canvas o Elements: An Add State button Purpose: allows the user to add states to the canvas Location: immediately above the upper-left corner of the canvas An Add Transition button Purpose: allows the user to add transitions to the canvas Location: immediately right of the Add State button A Remove Item button Purpose: allows the user to remove states and transitions from the canvas Location: immediately right of the Add Transition button An Alphabet text field o Purpose: allows the user to view and edit the alphabet o Location: immediately above the Creation Button suite o Same width as the canvas A Set Alphabet button o Purpose: sets the alphabet to the space-delineated characters currently in the Alphabet text field o Location: immediately left of the Alphabet text field The Input String suite o Purpose: allows the user to enter and test a string in the FSM o Location: immediately below the canvas o Elements: An Input text field Purpose: allows the user to enter an Input String Location: immediately below the canvas left-bottom corner of the canvas A Read String button Artificial Living Plants 28

30 Purpose: allows the user to run the entire Input String through the FSM Location: immediately right of the Input text field A Read Character button Purpose: allows the user to run a single character of the Input String through the FSM Location: immediately right of the Read String button A Check String button Purpose: allows the user to determine if the Input String is accepted or rejected by the FSM Location: immediately right of the Read Character button An Add String button Purpose: allows the user to add the current Input String to the Test Set Location: immediately right of the Check String button A Test Strings table o Purpose: displays the Test Strings in the Test Set o Location: lower right corner of the GUI o Columns: String: displays the Test String Expected Acceptance: color indicates whether the user expects the Test String to be accepted or rejected by the FSM Green: expected to be accepted by the FSM Red: expected to be rejected by the FSM Remove Button: removes the Test String from the Test Set when clicked A Test All button o Purpose: tests all the Test Strings when clicked o Location: immediately below the lower right corner of the Test Strings table A Checked Strings table o Purpose: displays previously checked Input Strings o Location: upper right corner of the GUI o Columns: String: displays the previously checked Input String Acceptance: contains a single character indicating whether the Input String was accepted A : the Input String was accepted R : the Input String was rejected Expected Acceptance: color indicates whether the user Grey: the Input String was ran from the Input text field, no expectation specified Artificial Living Plants 29

31 Green: the Input String was expected to be accepted by the FSM Red: the Input String was expected to be rejected by the FSM Prototype of GUI: CLI N/A 4.2 Communications Interfaces In order for our system to communicate properly, we need to have an http or https connection between the Radford server and the user for the software to render properly on the user s web browser. 5. Performance Requirements Response Time The system should respond to user input in the Alphabet Field or Input Field within 0.1 seconds. The system should respond to the user moving a state on the canvas within 0.25 second. The system should respond to the user clicking any button within 1.0 second. Artificial Living Plants 30