What's a good way to extract what's needed programatically from business logic? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

I'm new to programming and I've discovered something that causes me confusion and frustration: Translating business logic into actual code. I'm trying to develop a set of questions I can ask myself that will help me get to the level of detail I'm going to need to meet the logic requirement.

Do programmers have a set of questions they ask themselves when they're given business logic?

For example, in a test exercise:

• There must be at least two weeks of paid time between assignments.

Questions I've come up with so far.

• What specifc piece(s) of data must you know?
• Is calculation needed?
• Should this be stored as a variable?

In the above example, the answers are below.

• I must know at least the begin date, and a second date.
• A calculation is needed between the dates to see if it's less than 14 days.
• The total days can be stored as a variable and used in an error for those less than 14 days, etc.

Does my goal make sense? I'm trying to make it easier to see what's needed programatically by having a template of questions I can ask myself once a business rule is given to me.

Thanks for your help.

Answer 1

The way I've learned it is, a use case is an English translation of what will eventually become programming logic. Thus, in OOP, the nouns generally become objects (classes), the verbs become methods, and the adjectives are boundary conditions or invariants.

In your use case example:

• There must be at least two weeks of paid time between assignments.

The nouns are weeks, time, and assignments. The mention of weeks indicates we're looking at an interval, and 'at least' sets a minimum value for that interval (in this case, two weeks). Intervals mean you need a start and end value.

Then I notice that 'time' isn't standing alone; it's modified by 'paid'. That tells me that there are at least two types of time, 'paid' and, most likely, 'unpaid'. Specifying the type of time will require modifications to the interval calculations to account for potentially non-sequential time. Do we need to account for, say, someone having one week of paid time, one week of vacation, and then a second week of paid time?

This isn't a rigid template, I should point out, because there's no way a template can fit every single use case out there. Looking at the structure of a use case, though, and breaking it down a little bit, can be very helpful in constructing the programmatic logic.

Answer 2

It's really something that comes with experience. A lot of programming problems (especially the ones like in your example) are commonly occurring. And the ones that are not, can be broken down to problems that are. Solving such problems enough times will make solving them your second nature and you will not even think about how to translate such business requirements into code. So just keep programming and soon enough you will break your abstraction barrier between real world and code.

Answer 3

This answer takes a slightly wider view - my take on this is that the key to understanding how to program a solution to a requirement is to gain a deeper understanding of the requirement itself and it's rationale. Once you've reached this point then the implementation should be a lot easier to visualise.

I feel that there are many ways to approach this; it often depends on the kind of methodology you are following - but the ultimate goal is generally the same; i.e, to deliver a working solution which meets the expectations of your 'customer' within their expected time-frame, and their expected budget.

I would suggest aiming for the following:

1. Ensure that you (and your co-workers) have sufficient understanding and clarity of the requirements.
2. Ensure your "customer" (end users/managers/stakeholders/QA testers/etc.) understand their own requirements.
3. Ensure the customer understands the costs, implications and consequences of their requirements
4. Ensure that everybody involved in the software development process shares the same understanding and vision of the underlying motivations and end-goals.
5. Ensure that potential risks have been explored and discussed.
6. Ensure that possible constraints and limitations have been explored and discussed.
7. Ensure your technical limitations (or that of your team) have been explored - does the requirement suggest technologies or parts of an existing system which you are unfamiliar with?
8. Most importantly - ensure that everybody has their expectations managed; make sure the agreement between you/your team and the customer includes (as far as reasonably possible) a set of clear, concise and comprehensive acceptance criteria which everybody understands.

Here are the points which I like to remember when looking at a requirement:

1. Does the requirement sound like it solves a real-world problem or does it sound like a (possibly naive) customer's attempt to partially solve the problem themselves? i.e. is the customer trying to 'design' part or all of the solution for you? If so, be wary because that's a typical red-flag for a "bad" requirement.
2. Why has the customer asked for this requirement? What are their motivations?
3. What real-world/business problem are they trying to solve?
4. is it a real problem? does it provide cost-benefit? does it eliminate some kind of risk? is there a regulatory/legal/safety reason? or is it a perceived/imaginary problem which doesn't really need solving?
5. What are the costs to the business or customer if the problem remains unsolved? (Sometimes the best way to address a requirement is to abandon it!)
6. What are the risks involved in abandoning the requirement altogether? How important is it really?
7. How does the requirement affect any existing systems or user workflows?
8. What are the Acceptance Criteria for the requirement?
9. Once the requirement is implemented, how do I verify that the acceptance criteria has been met? i.e. Before i have even written a line of code, do I have a crystal-clear understanding of exactly how I am going to test it?
10. What external/third-party systems (Libraries, hardware, external servers, etc.) or businesses/customers/suppliers are involved if any? Do they affect the requirements (i.e. is there some additional unwritten "hidden" work involving the 3rd party which the customer hasn't considered)?
11. Are there any additional non-development costs implied? (hardware, extra tools/software, etc.)
12. What is the impact on the installation and deployment process; include the Upgrade and Downgrade procedures if applicable - don't just focus on a fresh/clean install.
13. What is expected to be delivered and when? How early will the customer get to review progress and provide feedback to refine or evolve the requirement with you?
14. How confident are you in your estimate for delivery (Best-case and worst-case scenarios). Has the customer accepted your worst-case-scenario?

I may have deviated somewhat from the question, although I feel that the issues surrounding requirements overlap heavily to the broader picture of project management (managing customer expectations); with all the best will in the world you can believe you have a good handle on a requirement (and your estimate) and still get it hopelessly wrong or break the deadline/budget.