How to Plan Software for Your Business Before Hiring a Developer

Summary

Many software projects go over budget because the business owner and the developer picture different things. A simple technique from systems analysis closes that gap: describe your business in plain sentences, list the nouns and verbs, decide which of them the software must remember and do, then test the result with CRC cards.

This guide walks through the technique step by step using one example, an online cinema ticket booking system. The same steps work for a clinic, a shop, a training centre or a delivery service.

Why do software projects for small businesses go wrong?

A business owner usually describes an idea in a few conversations and a short document. The developer then has to turn those words into a structure: what data the software stores, what each part does, and how the parts connect. Every gap in the description becomes a silent decision made by the developer.

Some of those silent decisions are business decisions. Can one customer book several seats at once? Is a booking valid before it is paid? Does the price depend on the seat or on the showtime? If the developer guesses differently from the owner, the mistake is usually discovered after the software is built, and changing a finished structure costs far more than changing a plan on paper.

The fix is not a longer document. The fix is a clearer one, and systems analysis gives a repeatable way to produce it.

What is systems analysis and design, in plain words?

Systems analysis and design is the work of deciding what a piece of software must do and how it should be organised before anyone writes code. It plays the same role as an architect's drawing before construction starts.

The central idea is the class. A class is a kind of thing the software has to remember, together with its details and what it can do. In a cinema system, Movie is a class: each movie has a title, a genre and a duration, and many movies exist. Booking is a class: each booking has a reference number, a total price and a status.

A list of classes, their details and their connections is called a class model. It is usually drawn as a class diagram in UML (Unified Modeling Language), the standard notation developers use. You do not need to draw UML yourself to benefit from the method; you only need to follow the thinking.

Step 1: Describe your business in plain sentences

Start with an honest description of how the business works, written the way you would explain it to a new employee. Short, concrete sentences work best.

Here is the example used in this guide. A cinema company wants an online booking system. Customers register with their name, email, phone number and password. They browse movies, each with a title, genre, duration, language, rating and description. Each movie has one or more showtimes, and each showtime takes place in one cinema hall on a specific date and time. Customers choose a showtime, pick one or more seats and pay online. After a successful payment they receive an electronic ticket by email or SMS.

Administrators add, edit and remove movies, schedule showtimes, set prices for seat categories such as standard, premium and VIP, and view booking reports. Each hall has a seating layout, and a seat that has been booked for a showtime becomes unavailable for that showtime. Movies are grouped as Now Showing, Coming Soon or Archived.

That description is about two hundred words. Everything in the rest of this guide comes from it.

Step 2: List every noun and every verb

Go through the description one paragraph at a time and write down every noun and every verb. Do not judge them yet. Mixing listing and judging is the most common reason important things get missed.

Nouns are candidates for the things the software remembers: customer, movie, showtime, hall, seat, booking, payment, ticket, price, category. Verbs are candidates for actions and connections: register, browse, book, pay, schedule, set price, belong to, contain.

In the cinema description this produces about 45 nouns. Only about a quarter of them will become classes. That ratio is normal, and it shows why a raw description is not yet a plan.

Step 3: Which nouns really matter?

Ask three questions about each noun, in this order.

1. Does it have its own details and behaviour? If it is a single value, such as an email address or a genre, it is a detail of something else, not a class.

2. Does the software need to remember many of them? If there is only one, or the noun is the software itself, drop it.

3. Is it a thing, or a role or type of another thing? Roles and types often become a label on another class instead of a class of their own.

In the cinema example, eight nouns pass all three questions: Customer, Admin, Movie, Showtime, CinemaHall, Seat, Booking and Payment. Words like title, duration, date, seat number and total price become details of those classes.

The dropped nouns are just as instructive. System and software application describe the thing being built. Cinema company is the owner, and nothing is stored about it. Account means the same as customer here, and transaction means the same as payment. Email and SMS are delivery channels with no data of their own. Seat availability is not stored at all, because it is calculated from bookings.

One lesson matters for every business: the description used movie showing, showtime and seat booking for overlapping ideas. Teams that use three names for one concept often end up building three slightly different features. Pick one name per concept and use it everywhere.

Step 4: Turn verbs into actions and connections

A verb becomes an action when one class performs it, and a connection when it describes how two classes relate. The rule for placing an action is simple: put it on the class that holds the data the action needs.

For example, calculating the total price of a booking belongs to Booking, because the booking knows which seats it contains and each seat knows its price category. Checking which seats are still free belongs to Showtime, because a seat is free or taken only for a particular showtime.

Connections come from phrases such as "each movie can have one or more showtimes", "each booking is associated with exactly one showtime" and "a booking can include one or more seats". The counting words in those phrases, one, exactly one, one or more, are called multiplicities. They are business rules written in plain language, and they decide how the database and the screens will work. Writing them down explicitly is one of the most valuable things a business owner can do.

Step 5: Test the plan with CRC cards

A CRC card is a small card, or a row in a table, with three parts: the Class name, its Responsibilities and its Collaborators, meaning the other classes it needs to do its job. The technique is old and very practical, because it turns a static list into a conversation about who does what.

Write responsibilities as duties, not as lists of fields. "Knows its contact details" and "calculates the total price" are responsibilities; "name, email" is not.

The cards test the list from Step 3. A class with no responsibilities should be removed. A responsibility with nowhere to live points to a missing class. In the cinema example the cards revealed three gaps:

- Booking needs a price, and admins set prices per category, so the price needs a home. That adds a SeatCategory class with a name and a price.

- Booking issues an electronic ticket that is created only after payment and sent to the customer. That adds a Ticket class.

- Customer and Admin both have a name, an email and a password and both log in. That adds a shared User class that both build on.

The cards also showed what is not a class. The payment gateway is an outside service; the system only stores the result it returns. A report is calculated from bookings when someone asks for it, so nothing new is stored. The plan grew from eight classes to eleven, and every one of them can be traced back to a sentence in the description.

Which business rules are easy to miss?

Some rules cannot be drawn as boxes and lines, and they are often the ones that cause real damage when they are missing.

In the cinema system the most important one is that a seat can be booked only once for the same showtime. Without it, two customers can pay for the same seat. It should be written as an explicit rule in the plan, not left to the developer's judgement.

Other questions look technical but are actually business decisions. One ticket per booking or one ticket per seat? Can a booking exist before it is paid, for example as a short reservation? Is a seat category a fixed list, or can admins create new ones with new prices? Each answer changes the software. Only the business owner can answer them, so it is far cheaper to answer them during planning than during testing.

Common mistakes when describing software requirements

- Treating every noun as a feature. Email, password or genre are details, not modules to build.

- Describing one giant system that does everything. Good software is a set of clear parts, each with its own duties.

- Adding things the business does not actually do. Refunds, discounts, reviews and snacks are real in many cinemas, but if they are not in the description they should not be in the first version. Scope grows quietly when nobody checks.

- Storing what should be calculated. Seat availability, totals and reports usually come from other data. Storing them separately creates numbers that disagree.

- Leaving out the counting words. "Customers book seats" is vague. "A customer can make many bookings, and each booking includes one or more seats for exactly one showtime" is a specification.

How does this help when you hire a developer or use AI tools?

A plan built this way changes the conversation with a developer. Instead of a vague idea, the developer receives a list of classes, their details, their connections and the business rules. Quotes become easier to compare, because every developer is pricing the same thing, and fewer surprises appear late in the project.

The same plan works well with AI coding assistants. These tools write much better software from a clear, structured description than from a loose paragraph. Giving an AI assistant the class list, the multiplicities and the explicit rules leaves far less room for it to guess.

The plan is also useful after launch. When the business wants a new feature, the owner can check where it fits in the existing classes before asking for a change.

Key takeaways

- Describe the business in short, concrete sentences before thinking about screens or technology.

- List every noun and verb first, judge them second.

- Keep only the nouns that have their own details, exist in many copies and are real things rather than roles.

- Put each action on the class that holds the data it needs, and write down the counting words as business rules.

- Use CRC cards to find missing classes and to remove ones that do nothing.

- Make the business decisions yourself, in the plan, before the developer has to guess.

Need help planning or building your system?

I help business owners turn their ideas into clear software plans and then build the systems, including AI-powered automations and Telegram bots. If you are planning a booking system, an internal tool or an automation for your business, leave a comment under this post or contact me through this website. Describe how your business works, and I will help you turn it into a plan a developer, or an AI tool, can build without guessing.