Developing Applications with Use Cases and Requirements

In Text-to-Software, creating use cases and requirements is optional. You can skip the process of making them entirely.

But use cases and requirements are powerful tools for accelerating Text-to-Software application development. If you choose to use them, you will have to do more work up front, but using them in the right way means you can skip some of the repetitive steps when you create your software… If you learn a little about use cases and how to make the best use of them, you can create screens, activities, forms, and fields out of use cases with a couple mouse clicks. In the end, creating substantial and correct use cases and requirements will let you create software faster and easier.

Developing use cases and requirements and using them to make software is a four-step process:

• Define the use cases;
• Define the requirements;
• Add the use cases and requirements to Text-to-Software; and
• Instantiate the use cases and requirements to make screens, activities, forms, fields, and the relationships between them.

For example, let’s say that your business is making four different espresso drinks. You want to create an application that will walk a new employee through the process of making each drink. To properly train a new employee in each drink, the application will tell the employee what is involved in each step of the drink and they will enable a check box when they complete it. This way, even a new employee can make a favorite drink for a long-time customer and it will taste the same as if you made it yourself.

To find out how to create software using use cases and requirements, go to Defining Use Cases.

Defining Use Cases

This step is the first stage in the process of creating software using use cases and requirements.

The first thing you would do is investigate and record the use cases for an application. Identify the different processes in your business. Each process will be a different use case with steps within it.
Each work process is its own use case. In Text-to-Software, by default, one use case becomes one screen (you can change edit that later). A use case is a single process that contains a series of steps to accomplish a single end goal. A use case satisfies a business process.
So, in the case of our espresso drink example (see the Developing Applications with Use Cases and Requirements Help topic), you would have a use case for each drink—because each drink has different steps to make it. You wouldn’t need multiple use cases for making different espressos, because when the employee makes an espresso, the steps are always the same. On the other hand, you couldn’t have one use case for making both lattes and espressos because these two things are made differently.

If we wanted our espresso-drink application to train employees on every aspect of working at a coffee shop, we would also have use cases for taking orders, running the cash register, opening for the day, closing for the night, cleaning the espresso machine, and every other task that has to be accomplished in the business.

The next step in the Creating Software with Use Cases and Requirements process is Defining Requirements.

Defining Requirements

This step follows Defining Use Cases in the Creating Software With Use Cases and Requirements process.

The second thing is to investigate the individual steps within each use case/process.
This could be a huge job, probably requiring extensive interviews with your employees, drilling down into their roles and responsibilities.
Break things down into the tiniest steps you can. The espresso example (see Creating Software with Use Cases and Requirements) is pretty high-level, not very detailed, but you want to get as low-level as possible. In the end, each requirement will become a single field in the software. So, if you were writing an application to help business development reps manage their sales leads, a requirement that says “contact info” wouldn’t be as helpful as “first name,” “last name,” “company,” and “cell number.”

Document these requirements as steps in each use case. For example, the use case for making espresso might look like this:

To make espresso:
• Grind beans
• Pack grounds into portafilter
• Tamp down grounds
• Fit portafilter into machine
• Place shot glasses on machine
• Press button
• Wait for espresso to dispense
• Pour espresso into cup
• Serve to customer

Each requirement (in this case, each bullet point) will become a field.

The next step in the Creating Software with Use Cases and Requirements process is Creating Use Cases and Requirements in Text-to-Software.

Creating Use Cases and Requirements in Text-to-Software

This step follows Defining Requirements in the Creating Software with Use Cases and Requirements process.

There are two ways you can create use cases and requirements in Text-to-software®. You can input them on the Requirements Analysis tab or you can create them using Text-to-software®.

To find out how to create use cases and requirements onscreen in Text-to-software®, see the Adding, Renaming, Reordering, and Deleting Use Cases and the Adding, Renaming, and Deleting Requirements Help topics.
To find out how to create use cases and requirements using Text-to-software, see the Creating Use Cases with Text-to-software and the Creating Requirements with Text-to-software Help topics.

The next step in the Creating Software with Use Cases and Requirements process is Instantiating Use Cases and Requirements.

Instantiating Use Cases and Requirements

Instantiating takes the use cases and requirements you’ve created, and generates screens, activities, forms, fields, and the relationships between them.

Each use case becomes:

• One screen
• One activity
• One form
• One field

Each requirement becomes one field. All the requirements in a use case are organized in the form named after the use case. Each form appears in the activity named after the use case. Each activity appears on the screen named after the use case.

You end up with a screen for each use case in the application, and every requirement will appear as a field on that screen.

TO INSTANTIATE REQUIREMENTS
1. Click the Requirements Analysis tab.
2. In the Software Lifecycle box, right-click a use case and click Instantiate.
3. Repeat steps 1-2 until all your use cases are instantiated.

From here, you will have to edit your fields, forms, activities, and screens in order to have them look the way you want them to, and to edit the appearance of your application.