Business rule in a personal system

Question

Concept of business rule

They are statements about how the company does business. They reflect business policies. Organizations with this have policies for meet business objectives, satisfy customers, make good use of of the resources, and obey the general laws or conventions of the business.

https://en.wikipedia.org/wiki/Business_rule

Trying to understand what business rules are:

"These are statements about how the company does business. "

I can develop a personal system for myself, and that concept still applies to this case?

For example, let’s assume that I developed a system for my walks or races. This system records the distance travelled. This distance can be in meters or kilometers. The system records the time spent in walking. This time can be in seconds, minutes or hours. The system records the date and time of the walk. I can access my walks through a history.

"This system records the distance travelled."

"This distance can be in meters or kilometers."

"The system records the time spent walking."

Those are business rules?

If yes, back to the concept: are they statements that represent how the company (in this case, myself) does (do) its (my) business? If that’s correct, what does "business" mean? In a commercial scope I imagine that it is product sale, payment, discounts, etc., which does not apply in this my example of walking system.

In my walking system example, I realize that business rules are what the system does: "This system records the distance travelled. " ; and they are also details, restrictions or conditions of what it does: "This distance can be in meters or kilometers. ". That’s what I understand as a business rule. I’m wrong about something?

Answer 1

Understand business rules as what defines what your program will do. Whether or not you have a business.

It’s the way the system will behave. In the case of your personal system to control the walks, the rules will be to calculate the time traveled, transform the time from hours to minute or vice versa, etc.

In short, it is what gives meaning to the software.

Answer 2

In your personal system you may not allow, for example, that the registered email is from GMAIL or that the user is over 18 years old or requires verification of the phone number, anyway; these are business rules.

The restrictions that your system imposes on the user to achieve the goal are the rules of your business.

Answer 3

In short, the definition of a system goes through some phases. After this definition is that the system goes into "production". The academic part that takes care of this part is called Software Engineering. When I say summarized it is because the whole process is quite complex and with many details.

Although your question is for a personal system, what changes is that you end up playing all the roles in the process. The fact that the system is personal does not change the methodology you employ in development, it changes only the complexity and effort you need to employ and allows you to shorten the time to reach the end.

I will describe these first phases because I understand that it is easier to understand having a context rather than just talking about business rules.

Vision

The vision of a system determines what the system is, what it should do, what the goal, what problem it intends to solve, what audience it intends to address, and other issues related to the system’s business and its viability. These characteristics determine a boundary and give a chance to those involved in the construction of the system to understand the investment that will need to be made for its complete development and so decide whether or not it is worth continuing with the endeavor. It is the most important part of the system because that part determines the limits of the system.

Usually small entrepreneurs don’t do that. People have ideas based on needs or to automate some business that already works manually or to create solutions to problems in a different, innovative way. Sometimes the solution is quite simple and it is not necessary to understand the whole scope to start, but sometimes it is fundamental not to get lost in the way.

When this part is not considered, system designs usually begin and usually do not end because their boundaries have not been delimited. The vision is important to give a clear direction to the project that will bring the system to life.

Analyzing

That is the most controversial part, in my opinion, in the process of developing the system. It is a part where it is necessary to employ some techniques that can be scientific (according to people who use Software Engineering) or empirical (according to people who do not know Software Engineering) in trying to understand the problem that the system wants to solve. Sometimes when talking to users who have the problem to be solved one may find that the solution is not a system, or much worse, one may misunderstand the problem and give a solution to a problem that did not exist. =)

Requirements

The requirements are the transformation of the ideas and the analysis of the problems that the system wants to solve into parts that determine "what" the system should have to meet the needs of users and thus solve the problems proposed in the vision. Some methodologies follow with a direct analysis of business needs and others try to map existing processes, in an attempt to extract these needs and at the same time direct the development of the solution. This second approach is usually used more often when a business process already works or has already been analyzed/improved. The first approach can also serve not only the development of the system but also the development of a process when it does not exist.

When thinking about those requirements, the programmer, who is usually a person who understands the part about how to develop, what languages to use, what components are needed, what database is better, what technologies are more suitable, what development platform is more agile, what kind of test needs to be done, etc., usually does not focus on the "what" the system needs to do but "how" it should do.

That’s where the business rules come in. That is, whenever a system is built to solve a problem it will have constraints that it must meet in order to achieve the goal effectively. Usually the people who write these business rules are people who understand the business itself and what needs to be solved and is not always the developer himself. Sometimes these rules are not just for the system to work properly, but also for it to meet some rule, some law.

Business rules will be derived from this "list" of requirements because in trying to understand the requirement there will be questions like "how is this calculated?" , "What format should this report have?" "What format should I send this to the government?" , "what is the relationship between this percentage and this data that the user informed?" , "what information is requested first?" etc..

All these questions arise as the requirements are understood and detailed and these business rules can be more or less complex as those involved explore the technological possibilities. Therefore, often these rules are not clear at the beginning of the system and are emerging as people understand the business and requirements. Sometimes the business is already very clear at the beginning of development and some rules are already known and only need to be met.

Other Phases

Implementation, Testing, Installation and other phases arise in sequence. Of course, each methodology explores these phases with a different view, in different cycles, with different approaches, but overall these are the phases that are systematized in a "Software Manufacturing".