Which approach is better suited for analyzing a basic manual ongoing system? Structured Analysis or Object Oriented Analysis?

Question

My task is to analyze a system used in our office which is based on Excel for storing data. The data is entered manually by a person.

So when we need to update or edit the data, we use Excel's standard features, when new data comes in and we need to print it in a form, we use another Excel sheet to type and print it.

I need to analyze that ongoing system but I am still confused between using "Structured Analysis" approach or Object Oriented Analysis. I have been reading papers that compares between these two but couldn't comprehend which approach is better suited for this task.

Answer 1

The analysis aims to give a better understanding of what’s needed. It is not clear in your question if you need to automate a manual activity with a new system, or if you just need to document the activity and perhaps optimise some steps.

If you’re in the second case:

• you could opt for structured analysis : it is based on one side on functional decomposition (i.e. what people do and how the Excel sheets are used as input or as output of these activities) and on the other on data structures (i.e. how the rows and columns of data are related).
• you could even be very pragmatic and simply use swim lane diagrams or a process model and just document the excel sheets better

If you’re in the first case, you could of course use the same approach. You should then relate the different sheets/columns to the different activities. This makes especially sense if you are in data-rich context and if the activities at the origin of the data are rather simple. In the design stage you’d then rearrange the rows and columns in the Excel sheets into smaller tables for a database.

You may however prefer to opt for a use-case driven approach:

• use cases identify the roles of the users, and their goals when they use the system.

• you then identify the entities (business objects) that are involved in the use case, and continue with an object oriented analysis for example following the ECB decomposition.

• interestingly, at some stage of this analysis, you’ll also try to understand activities and their decomposition

I mentioned these approaches first, since the requirements seem already partially automated and well known, and you seem to have to do an up-front analysis and this is what you asked for. But if any if these condition is not met, you may opt for a more agile approach using use-case 2.0 or user story mapping, starting with real requirements expressed by the users and trying to understand what they really need instead of starting with historical Excel sheets that might be obsolete workarounds that do not fully correspond to the current needs.

Answer 2

You want to produce a high-level description of the roles & their responsibilities, which interact by providing and consuming (mostly information) with each other to accomplish work of the business.  I don't think you need to follow a formal methodology for that, but if I had to choose between those two, I'd pick SA since it focuses more on components, their kinds, and flow; I don't think you'll need to detail classes and encapsulation for this initial analysis.  There are many others, such as DDD, but again, I don't think you need this level of formalism to get started, and further, there is a layer of analysis above what DDD addresses that will be helpful, namely, the role & responsibility-based description of how the business accomplishes work.

Such an analysis would describe who accepts/approves orders, who maintains orders, who processes orders, maintains customer records, supplier contracts, etc.. Along with what information flows between these roles to accomplish work of the business.