| A requirement is a desired feature, property, attribute, or behavior of a system. Defining requirements is the most important factor in the success of the project. Tatam System Consultants has experienced a number of different approaches to the requirements phase. In the company's experience, it is best to keep the requirements as simple as possible without misrepresenting the functionality. The bottom line of a requirements document is to determine and communicate what a system is supposed to do. Once completed, this document should describe the core of the final product. Demanding a perfect and complete system specification at this point is unnecessary, as time constraints are very evident (as in most if not all projects you will encounter). Silicon Coast's goal is for staff members to communicate directly with each other on a system that provides real-time or almost-real-time messaging. As you have seen, Tatam System Consultants's approach was to start a brainstorming session on what features might be included in this chat application. This initial wish list evolved into a reasonably large feature set. Based on the multitude of concepts, models, and characteristics of existing chat applications, multiplied by the number of different technologies that delivered them, the requirements were very large. They needed to be culled due to the time restriction. Further requirement gathering consisted of researching other competing systems, which enabled Tatam System Consultants to assess the strengths and weaknesses of its proposed product. This particular requirements process was unusual. A traditional process is to collect functionality information and requirements from the business and end users of an existing system to determine new functionality or to automate an existing process. This approach consisted of analyzing existing products to foresee what functionality the client may require. This perceived functionality could assist the client in identifying or further refining their own requirements. Security was a concern and was discussed. The client was not too security conscious and believed that their current IT infrastructure was sufficient enough for the Chat system. 
Once Tatam System Consultants produced a document that described the chat application, the project plan was revisited and refined to determine resources needed and to identify tasks and how they would be assigned. Requirements Document This requirements document was presented to Silicon Coast, which signed and accepted it. Once this document was signed the test plan was composed. Each test was directly related to a requirement or group of requirements. Both parties must accept this plan at this stage to ensure how the project's success may be measured. The document will be a formal part of the acceptance criteria of the system at the end of the project. A Requirements Document for Silicon Coast Corporation Chat Project was created, but instead of inserting the document completely, I've included a synopsis of the information that would be included. Background Refer document WA 02126 001 project plan for Silicon Coast chat system. The proposal for the project required a project plan, a requirements document, a test plan, and if acceptable then training documentation, and a functional system. The initial brainstorming session evolved into an informal-requirements gathering exercise. Purpose of this document The purpose of this document is to convey an understanding of the requirements for developing a chat system for Silicon Coast Corporation. It will attempt to generally describe the core functionality and processes required by the proposed chat system. Product functions defined as a result of the requirements gathering were the following: log-in, view other users online, request a chat, deny a chat, ability to view and have a one-on-one dialog with another user. Audience Silicon Coast business managers Silicon Coast end users Tatam System Consultants analysts/architects Tatam System Consultants developers Constraints Time was acknowledged to be a major contributing factor driving the completion of this project. The restructure that this application will support is due in four weeks. Budget was not discussed; however, a daily rate has been set within the contract document.  TIP Tatam System Consultants believes that using a general diagram to visualize the functionality assists in the overall understanding and acceptance of this section in the project plan (Figure IV-1.4). If the client only browses this document, the diagram stands out from the text and will grab the reader's attention.
Figure IV-1.4. Objectives the user will be able to interact with the system in the following general manner:
NOTE A data-flow diagram represents a visual description of a process and the flow of data within that process. The boxes are processes, and the diamonds are conditional branches (if statements). One-on-one communication is the goal. The client and server must interact. There must be a log-in and the ability to associate a log-in with a user and a session. The system has the following features: Change Control Version number will be structured as follows: Not only the previous version, but also all older versions of any document or codes will be preserved. This will ensure that if the need to revert back to more than one version arises, the necessary version is available. Attached to this document is a change-request template that will be used throughout the chat project. It will record Silicon Coast's requests for any perceived alterations. This document is to be submitted by Silicon Coast if this situation arises. Any communication on modifications must be formally submitted using this change-request form. Tatam System Consultants will officially respond to these requests with an acknowledgement that consists of an acceptance or non-acceptance with advice on the decision. Functional Requirements The following is what the user will experience when using the system. This section is ranked in order. User-account administration An administrator is able to log in through a browser to the server and add, edit, or delete users who have access to the chat server. Anonymous log-in will not be allowed, as the system holds client and company details that may be confidential. Critical: Yes Perceived technical issues AuthenticationFunctional dependency: Database schema implemented Log-in A user opens up the chat user interface. He is presented with his current user name, which has been stored since the previous session was terminated. At this point he can also see any other users or chat rooms that are currently active. These users and chat rooms are displayed separately from each other. Users have a password box in which they can enter their password to log in. A log-in button sends the user name and password to the server. When the server receives the log-in user name and password, it authenticates them against a user account. If the name and password are authenticated, then the user is added to the list of current users that all other online users can view. The logged-in user can now request a chat with another user online. Others online can also chat with this online user. The user session may have a time-out period. Critical: Yes Perceived technical issues: Authentication Functional dependency: Database schema implemented Chat request Once a user is logged in, she has the ability to start chatting with another user. If she would like to chat with a user online, she selects the user and asks the user to chat. This chat request then appears on the online respondent's user interface. If the respondent declines the invitation, a message is sent to reflect the response. If the respondent accepts the request, then a chat user interface appears that displays information required to participate in a chat dialog. Critical: Yes Perceived technical issues: Storage of request, notifying the intended recipient in acceptable time Functional dependency: Log-in Responding to a chat request Once a user has logged in, he appears on all other user interfaces. When an initiator requests a chat the user is notified of the invitation. He then has the option to accept or decline the invitation. The initiator is notified of the response. If the respondent accepts the request, then a chat user interface is created. Critical: Yes Perceived technical issues: Notifying the intended recipient in acceptable time Notifying the requestor in acceptable time Functional dependency: Log-in, request a chat Chat process An interface is created once a respondent accepts a chat invitation. The server then monitors the individual chat session. This interface has an area showing the dialog history. It also displays the details of the participants who are associated with this chat session. To send a message, the user types the message in the message-text area and then clicks the send button. The dialog history shows the message, and the message is sent to the other participant. When a message is received, it immediately appears in the dialog-history area. To terminate a chat session, either participant can send a message to the other by clicking the end-chat button. The server is notified of the termination of the individual chat session. An individual chat session will have a time-out period. Critical: Yes Perceived technical issues: Transmission of chat dialog in acceptable time. Functional dependency: Log-in, request a chat, accept a chat Logging out When a user wants to log off or terminate her current chat session, she must click the log-off button. This notifies the server, which then terminates any active individual sessions and notifies their participants. Critical: Yes, but time-out may end session Perceived technical issues: Transmission of termination to other users in acceptable time. Functional dependency: Log-in Changing modes The user may be able to be viewed as off-line even though he has not logged out. The user can select his current mode and then send the status to the server. The server then updates individual sessions (if applicable) as well as updating the current session, which will be reflected on other participants' "users online" display. Critical: No Perceived technical issues: Transmission of status change in acceptable time. Functional dependency: Log-in, or could be called from within the log-in procedure Chat rooms The user selects a chat room, which causes a chat-room user interface to pop up. This allows the user to view the dialog that is currently available. The user can enter a message and send this message to the chat room. The dialog history area is continually updated with the chat room's dialog. The users within the chat room may be displayed in the chat-room interface. To leave the chat room, the user clicks a button to exit the session. This notifies the other chat-room participants. Critical: No Perceived technical issues: Broadcasting of chatroom dialog in acceptable time. Functional dependency: Log-in Interface Requirements This chat application needs a number of client user interfaces: Log-in Displays user name on screen. Text box to edit user name and button to update user name. A password box will receive the user's password. A log-in button sends the user name and password to the server. Chat center List of current users online. List of currently active chat rooms. May have an area that displays the current user's status for example, online/offline. Request a chat Accept a chat Individual chat-session user interface Has an area that displays the dialog history. Displays remote user name. Displays local user name. Input box for message text. Button for sending the message entered. Button to terminate this chat instance Logging out Changing nodes Chat room Area for chat-room dialog history. Displays current users within the chat room. Input box for message. Button to send the message. Button to exit chat room. Message for new participants. Administration user interface Lists all registered users. Has input boxes to allow editing of user and chat-room details. Has buttons to update, edit, add, or delete the currently selected user. Security considerations Security has been discussed, but there has been no further interest in implementing it. The current security consists of a user name and password transferred over a nonsecure connection. This concern has been formally expressed via correspondence. Implementation The client-side application can be easily installed. It will run on both the Windows and Macintosh platforms. The server-side code must be able to work on a Windows 2000 operating system. This interface should be browser based, as the server administration can be accessed independently of the client-side chat application. Approval Approval of this document will be a contract to build the said functionality. Any modifications will be formally proposed through the use of a change-control form. In order for a project to be deemed a success, a project's functionality, performance, and scalability must fall within acceptable limits. As Silicon Coast has no recognized quality- assurance system, the testing document does not have to conform to any internal policy or procedural process. Tatam System Consultants has a complete test- plan template that can be customized to suit the current project. As this project appears to be a small standard project, a summary test plan will be presented to the Silicon Coast Corporation. Tatam System Consultants will be responsible for implementing all testing and recording of test results. Tatam System Consultants will endeavor to complete all functionality testing; however, Tatam System Consultants it will take no responsibility for test failure that is of test as the result of external circumstances beyond their its control. The project will not be completed by June 30. It appears that it will take longer than Silicon Coast has initially planned for. At this stage, it must be brought to the company's attention. In Tatam System Consultants's experience it is better to under-commit and over-deliver rather than having to have a disappointed client. Upon realizing the project may not be delivered within the specified time, Tatam System Consultants notified Silicon Coast. 
Now that the test-plan format and the test features have been approved, TSC will have to wait to see if they have been successful in securing the development contract. Once the project has been authorized to continue the next phase it enters is the design phase. In this phase, the system architect will attempt to create a design document that illustrates the requirements and functionality for the development team. The next chapter will discusses in depth the initial design and the application architecture. |
