This week's discussion topic focuses on functional requirements. These need to be clearly written so the people who are developing the system or evaluating a system for use, can discern whether or not the functional requirements are met. The functional requirements statement: Is a complete sentence, with a subject (system) and predicate (intended result, action or condition) Identifies only one requirement; does not include the words "and," "also," "with," and "or." States what tasks the system will support or perform Includes a measure or metric that can be used to determine whether the functional requirement is met (time or quantity), where appropriate Is stated in positive terms and uses "must" (not "may" or "should"); e.g., "the system must xxxx" not "the system must not xxx" Avoids the use of terms that cannot be defined and measured, such as "approximately," "robust," "user friendly," etc. Must be testable; that is, there must be some way to test the system to determine whether the requirement is met. Requirements for post: Drawing from your own experience, select a process used at your place of work or other interactions with an organization that you would like to see improved. Explain why you picked that process. Imagine that a system is to be implemented (or an existing system improved) to make that process better, and write five (5) functional requirements for the system to perform. Each requirement is one sentence in length and addresses one thing the system must do. We are interested in functional requirements – the activities the system must perform to support the identified process. Use the information above to create your functional requirements statements. A student answered: Process: The Defense Travel System (DTS) is a government-wide computer program to book travel. As a federal employee who travels, I book all facets of travel through DTS. Why DTS needs improvement: According to UMGC (n.d.), functional requirements are the tasks the user needs the system to perform. DTS lacks simple, functional requirements for problems affecting most users. The system goes down at the busiest times of day is one. DTS also allows the user to select flights, hotels, or cars, and if the cheapest selection changes before the user submits the request, DTS still allows the selection to go through. While DTS does not alert the user of the conflict, the approval authority sees that the user did not select the lowest priced and is required to notify the user, and they need to amend the approval, wasting time. Another system flaw is if a voucher is created and the user accidentally clicks the wrong button when amending it, the voucher cannot be fixed and has to be deleted along with the original approval, wasting the time of the user and approval authority. Functional requirements for DTS: The system must be able to handle 2,000,000 users simultaneously. The system must have a help icon that opens the help menu next to all tasks. The system must alert users if flight, hotel, or car pricing has changed before allowing the user to submit approval. The system must disable any function not necessary for submitting a voucher. The system must display all travel options from cheapest to most expensive. Questions. 1. Should the process identified actually be considered a "process"? That is, does it meet the definition of "a set of specified steps to accomplish a task"? Why or why not? 2. Do the functional requirements listed support the selected process? 3. Are the functional requirements clearly stated such that system testers will be able to ascertain whether or not the requirement has been implemented? 4. Provide an example of a rewritten functional requirement that improves one of the existing user requirements in the information provided above.