1. As a System Analyst, after you gathered systems requirement, how are you going to analyze these data? Are you starting with business process first or start with data directly? Explain each approach and why or why not?
2. Once the data analysis is complete, how are you going to start with design portion? What kind of tools can help you to accomplish that? Are you or aren't you taking physical constraints as part of the design consideration?
Note: Physical constraints --limited budget, two seconds of response time, read-only access to non-Corporate employees, relational database vs. Object-relational database.© BrainMass Inc. brainmass.com March 4, 2021, 8:00 pm ad1c9bdddf
"1. As a System Analyst, after you gathered systems requirement, how are you going to analyze these data? Are you starting with business process first or start with data directly? Explain each approach and why or why not? "
- Business analysis and top-down database design are often neglected, or shortcuts are taken, especially when the developer is eager to "get his hands dirty" and start building a system with row data directly. But rushing into system development is like building a house without an architect: you're lacking the overall, but detailed, picture of what you're trying to achieve.
Most databases are built with a business need in mind, and the satisfactory delivery of that need?perhaps the satisfaction of your client?is the primary goal.
If you build a system that's either inadequate or too sophisticated, the client is unlikely to thank you. Either it will fail to solve his problem or it will be too expensive to build. By better analysis of the requirement and careful design, you should be able to get the system to precisely fit the need.
The business need has to be studied to outline the following characteristics:
- The business process, or what actually goes on in the business
- The business rules, or what is allowed to happen, and what isn't
- The business objects, the actual things that exist in the business
Together, these things describe the goings-on within the business and in the business function you're trying to model. Some organizations have these things written down as formal procedures, whereas in other scenarios people just get on and do things; the procedures only existing in people's knowledge.
Whichever is the case, start by studying the information that's there by asking questions and forming a picture of what goes on.
* Business Processes
Identifying business processes is often a good time for drawing a process flow of what you think is going on:
- It helps you form a picture in your own mind of what's going on.
- You can show it to other people who know the process and talk it through, reconfirming it to make sure that you have it right.
- It may uncover missing links in your understanding, or even failings in the process as it's been described.
- It provides a reference point to look back on as the project moves forward. By compiling notes and process diagrams as things develop, you have an audit trail of the development of your ideas and understandings.
A process diagram can be as formal as you want, created with special software, or can be a pencil-and-paper sketch. Attached picture "simple_business.JPG" shows a simple process diagram.
Inherent in the language used to describe events in the process is the concept of transactions. A transaction is an essential part ...
Database design based on systematic approach is discussed.