In addition to functional requirements, also define nonfunctional requirements, business rules, and assumptions on use case documents. Define business rules in a parametric way. This will let the project team easily design, develop, and change business rules when needed. For example, in the View and Order a Product use case, User is notified with a message indicating that 1 percent commission will be charged for express deliveries is a wrong functional requirement definition. Instead it should be defined as User is notified with a message indicating that a commission rate will be charged for express deliveries (BR1). Business rules in this scenario should be defined in the business rules section of the same use case document. The business rule in this example should be defined as follows: BR1: Express Delivery Commission = 1 percent Define nonfunctional requirements, such as usability, performance, and privacy,

For example, After the customer confirms the payment, an Order Confirmation Report should be displayed fast is not a correct performance requirement definition. It should be defined as After the customer confirms the payment, an Order Confirmation Report should be displayed within two seconds. Limit assumptions to the conditions in which the user has no control.

For example, Product availability data received from the ERP inventory module is up to date and accurate may be an assumption for the View and Order a Product use case. But the items that will be ordered by the customer are in stock is not a correct assumption. The behavior of the customer and the CEC mobile application, in case the customer attempts to order an out-of-stock item, should be defined as an exception scenario on the use case document. Otherwise unclarified assumptions will create many issues at the user interface design, technical design, and development stages and result in waste due to unplanned work. Benefit from flow charts to visualize use case scenarios.

In history, people first used drawings to communicate with one another. Even after the invention of letters, they continued to use drawings as an easy way of expressing themselves. Similarly, using diagrams such as flow charts is an effective way of visualizing use case scenarios and clarifying the ambiguities in narrative requirement definitions on plaintext, use case documents Flow charts are useful for modeling and describing work flows with simple diagramming conventions. A flow chart should be created for each use case. Each branch on a flow chart represents the main, alternative, or exception scenario of a use case. The flow chart below represents the View and Order a Product use case of the CEC mobile application. The branches on the chart show scenarios of that specific use case.