Functional requirements section of the business analysis answers the “how” questions, such as “How are we going to change the process? To answer these kinds of questions, your functional requirements should include the following info:
Design area scope: The scope of what will be included in the design. Solution design may take on both non-automated solutions (like adding more people to the business area or redesigning the manual process) or automated solutions (creating a mobile app to allow people to order takeout food from a restaurant, for example). One technique you can use to create the design area scope is a use case diagram.
The design area scope may differ from the project scope because not all aspects of the project scope are completed at the same time. The solution may be split into different phases, each with its own design scope.
System functionality: How the user interacts with the software. Think about the actions you perform and the reactions (or responses) the system provides back to you — this is the expected system functionality. You often document these items with use cases and user interface (UI) specification documents.
Data definitions: What the business data looks like, such as allowable values, default values, and field lengths. For example, you may define that a customer’s shipping state defaults to using the state code on their billing address, such that allowable values are AL, AZ, AK, and so on.
User classes: The groups of people who will be using the new application software or process (internally or externally). Some examples include customers, prospects, guests, employees, senior management, line people, and call center representatives.
User interfaces: Description of screen layouts, report layouts, and procedures. Remember to follow up any pictures with explanations of how the screen operates. For instance, the image below is an example of a user interface prototype of a flight reservation system.
When describing this interface prototype, you’d explain that the “Find Flights” button remains inactive until the users choose an origin, destination, and departure and return dates. This sequence is the behavior surrounding the screen.
![[Credit: Illustration by Wiley, Composition Graphics Services]](https://www.dummies.com/wp-content/uploads/390407.image0.jpg)
Credit: Illustration by Wiley, Composition Graphics Services
When documenting functional requirements, keep the following in mind:
Document how you want the functionality to work rather than what specific tool you plan to use. For example, making sure the flight reservation system displays only return dates that occur after the departure date is a description of functionality; the fact that you’ll use, say, a Java calendar code applet to calculate Today +1 is a description of a tool for execution.
Stick to the interactions between the computer system and the external agent (the user).
Address the look and feel (the observable behaviors) instead of focusing on code design and implementation.
You have to tread a fine line when you’re documenting functional requirements. The language has to be nontechnical enough to communicate to the business subject matter experts so that they understand how the solution is going to operate. However, it still has to be detailed enough so the technical team knows how to create the solution, including all the exceptions/alternate ways to create the solution.