The Process Of Examining A Business

Published Date: 02 Nov 2017

1.0 Introduction:

System Analysis and Design refers to the process of examining a business situation with the intent of improving it through better procedures and methods. System analysis and design relates to shaping organizations, improving performance and achieving objectives for profitability and growth. The emphasis is on systems in action, the relationships among subsystems and their contribution to meeting a common goal. Looking at a system and determining how adequately it functions, the changes to be made and the quality of the output are parts of system analysis. Organizations are complex systems that consist of interrelated and interlocking subsystems. Changes in one part of the system have both anticipated and unanticipated consequences in other parts of the system. The systems approval is a way of thinking about the analysis and design of computer based applications. It provides a framework for visualizing the organizational and environmental factors that operate on a system. When a computer is introduced into an organization, various functions’ and dysfunction’s operate on the user as well as on the organization. Among the positive consequences are improved performance and a feeling of achievement with quality information. Among the unanticipated consequences might be a possible threat to employee’s job, a decreased morale of personnel due to back of involvement and a feeling of intimidation by users due to computer illiteracy. The analyst’s role is to remove such fears and make the system a success. System analysis and design focus on systems, processes and technology.

2.0 Data Flow Diagram:

Data flow diagrams (DFDs) reveal relationships among and between the various components in a program or system. DFDs are an important technique for modeling a system’s high-level detail by showing how input data is transformed to output results through a sequence of functional transformations. DFDs consist of four major components: entities, processes, data stores, and data flows. The symbols used to depict how these components interact in a system are simple and easy to understand; however, there are several DFD models to work from, each having its own symbol-logy. DFD syntax does remain constant by using simple verb and noun constructs. Such a syntactical relationship of DFDs makes them ideal for object-oriented analysis and parsing functional specifications into precise DFDs for the systems analyst.

2.1 Level 0 Diagram:

Level 0 Diagram

Customer Payment

0.0

Shoes department system

Summary Report

Customer

Supply Goods

Receive Money

Receive Product

Provide

Management

2.2 Level 1Diagram

Customer

Customer Payment

Receive Product

Customer Payment

Take Product

Money Record

Shoes Record

Store Goods

Supplier Payment

Money

Shoes

Summary Report

Management

3.0

Reporting

Supply Goods

Receive Money

2.0

Procurement

Provider

1.0

Accounting

2.3 Level 2 Diagram

1.1

Product

Money

Shoes

Take Product

Customer

Payment

Customer

Payment

Receive Product

Shoes

Money

1.2

Collecting

Customer

Supply Goods

Store Goods

2.1

Supply

Provider

Receive Money

Supplier

Payment

2.2

Transaction

2.4 Data Dictionary:

Level 0 Diagram:

Process

Process Name or Label : Shoes Department System

Process Number : 0.0

Process Description : A system use to sell shoes for customer.

Entities

Entity Name : Customer

Description : The person who buy the product

Input Data Flows : Receive Product

Output Data Flows: Customer Payment

Entity Name : Management

Description : The person who receive the report

Input Data Flows : Summary Report

Entity Name : Provider

Description : The person who provide product for the system

Input Data Flows : Receive Money

Output Data Flows : Supply Goods

Data Flow

Data Flow Name or Label : Customer Payment

Description : Make the payment of the product

Origin : Customer

Destination : Shoes Department System

Data Flow Name or Label : Receive Product

Description : Receive product from the System

Origin : Shoes Department System

Destination : Customer

Data Flow Name or Label : Supply Goods

Description : Provide product to the System

Origin : Provider

Destination : Shoes Department System

Data Flow Name or Label : Receive Money

Description : Make the payment of the product

Origin : Shoes Department System

Destination : Provider

Data Flow Name or Label : Summary Report

Description : Make the report to the management

Origin : Shoes Department System

Destination : Management

Level 1Diagram:

Process

Process Name or Label : Accounting

Process Number : 1.0

Process Description :

Process Name or Label : Procurement

Process Number : 2.0

Process Description :

Process Name or Label : Reporting

Process Number : 3.0

Process Description :

Entities:

Entity Name : Customer

Description : The person who buy the product

Input Data Flows : Receive Product

Output Data Flows : Customer Payment

Entity Name : Provider

Description : The person who provides the products to the system

Input Data Flows : Receive Money

Output Data Flows : Supply Goods

Entity Name : Management

Description : The person who receive the report

Input Data Flows : Summary Report

Data Flow:

Data Flow Name or Label : Customer Payment

Description : Make the payment of the product

Origin : Customer

Destination : Accounting

Data Flow Name or Label : Receive Product

Description : Receive product after payment

Origin : Accounting

Destination : Customer

Data Flow Name or Label : Take Product

Description : Take the product to sell to the customer

Origin : Shoes

Destination : Accounting

Data Flow Name or Label : Customer Payment

Description : Receive Money from the customer

Origin : Accounting

Destination : Money

Data Flow Name or Label : Receive Money

Description : Pay money to the provider for buy the goods

Origin : Procurement

Destination : Provider

Data Flow Name or Label : Supply Goods

Description : Provide goods to the procurement

Origin : Provider

Destination : Procurement

Data Flow Name or Label : Store Goods

Description : Store the product into storeroom

Origin : Procurement

Destination : Shoes

Data Flow Name or Label : Supplier Payment

Description : Pay the money for buy goods

Origin : Money

Destination : Procurement

Data Flow Name or Label : Shoes Record

Description :

Origin : Shoes

Destination : Reporting

Data Flow Name or Label : Money Record

Description :

Origin : Accounting

Destination : Customer

Data Flow Name or Label : Summary Report

Description : Make a report the management

Origin : Reporting

Destination : Management

Data Store:

Data store Name or Label : Shoes

Description : Store the product

Data store Name or Label : Money

Description : Store the money

Level 2 Diagram:

Process

Process Name or Label : Product

Process Number : 1.1

Process Description :

Process Name or Label : Collecting

Process Number : 1.2

Process Description :

Process Name or Label : Supply

Process Number : 2.1

Process Description :

Process Name or Label : Transaction

Process Number : 2.2

Process Description :

3.0 Answer Question 2:

3.1 Requirement Specifications

A requirement specification is something that used to present in the system. The requirement specification is a document that precisely and clearly defines the user needs in such a way that it is possible to test a complete finished system to verify that the system have actually been met the requirement. The System Requirements Specification is the official statement of the system requirements for customers, end-users, and software developers. It details what services the system should provide, the system properties, and the constraints on the operation and development of the system. The requirements are classified into different categories. On the one hand, this facilitates the process of identification because each category can be examined separately and, hence, the cognitive demand is reduced. On the other hand, the multitude of identified requirements can be better explored by the classification.

In the identification process, analysts normally stick to categories and sometimes do not identify requirements besides them. Therefore, it is important that the categories encompass all potential requirements. This problem was addressed by reviewing literature (IEEE Computer Society, 2009; Anon., 2005; The Open Group, 2009; McEwen, 2004) as well as other requirement specifications (Fitzner, 2010) for possible categories.

3.1.2 The Importance of the Requirement Specification

The exact roles of the RS in procurement depend upon the particular procurement strategy employed. However, the RS always fulfils two roles which is the primary input to the design process, the baseline against which acceptance tests are carried out. Thus it has a pivotal role in any major software system.

Perhaps unsurprisingly, experience has shown that purchasers who fail to provide their chosen supplier with an adequate Requirements Specification are likely to find that the supplied system does not adequately meet their needs. Furthermore, the costs of rectifying system deficiencies after installation are likely to be much greater than the cost of preparing an effective RS in the first place, if indeed rectification is practical at all. Any corrective action will also result in delay to the successful utilisation of the system. Thus the preparation of a good RS reduces both cost and risk.

3.1.3 Functional Requirements

The Functional Specification (FS or Functional Requirements Specification) is a formal statement of the functions required to be implemented in a specific physical form or technology for a business proposal.

There are several elements common to the design process. The first is conceptual (logical or essential) planning of requirements: sometimes known as conceptual design, but more usefully referred to as Analysis the detailed conceptual planning that is documented in the Business Requirements Specification. This is significantly different from physical design of the product features, and styling of the product to meet fashion, market, emotional and other drivers. These two elements are the domain of the Functional Specification. Finally, the detailed technical design will specify the construction requirements, documented in the Technical Specification.

Functional requirements describe what the system must do (Behavioral Requirements), the data manipulated by its functions (Data Requirements), and the user interaction with the system (User Interface Requirements).

3.1.4 Behavioural Requirements

Specify the behavioral requirements, which describe what the system must do. These requirements should be supported by Use Cases, and thoroughly describe the behavior of the system. Include requirements for how the system should behave under abnormal circumstances, e.g., missing or invalid data.

3.1.5 Data Requirements

Specify the detailed data requirements for the system, including inputs, internal data, and outputs. Include the sources and destinations of the data, as well as requirements regarding frequency, latency (real-time, near real-time, daily) and volume. Identify data that must be converted, replicated or shared across software components. State the System Logical Data Requirements, Data Input files, Internal Data Files, and Data Output files; State where the System Logical Data Requirements will be stored.

3.1.6 Integration Requirements

Specify requirements for integration with other application systems. Identify the data items or messages coming into the system and going out and describe the purpose of each. Refer to documents that describe detailed application programming interface protocols.

3.1.7 User Interface Requirements

State the detailed user interface requirements. Describe the logical characteristics of each interface between the software system and the users. Define the software components for which a user interface is needed. Details of the user interface design should be documented in a separate user interface specification.

3.1.8 (End) user interface requirements:

The (end) user interface requirements specify the interface between the software and the user. This includes software configuration characteristics (e.g. required screen formats, page or window layouts, content of any reports or menus, etc.) as well as aspects that optimize the ease of use of the interface (e.g. specific layout which is familiar to the user). A subcategory for further specialisation of the requirements could be style of the product respectively of the appearance. Another subcategory can be the ease of use or the ease of learning. Style of the product describes requirements for the appearance of the user interface that are not driven by specific user needs regarding the usability of the system (e.g. requirements based on company guidelines). The latter usability requirements "describe the ease with which the system can be learned or used" (McEwen, 2004).

3.1.9 Performance requirements:

Performance requirements "specify both the static and the dynamic numerical requirements placed on the software or on human interaction with the software as a whole". Dynamic numerical requirements specify an amount of actions that are done in a certain time period, e.g. amount of web pages that are captured in one hour. Hence, dynamic requirements can be encapsulated in the sub-category of speed/performance requirements. Static numerical requirements will be specified mainly under the sub-category of capacity and scalability requirements. They define how much or how many the system must be able to process or to store. Examples are how many users can access the system at the same time, how many blogs can be captured, managed and preserved by the system or how much storage capacity must be managed by the system.

Another subcategory is reliability and availability requirements. Thereby, reliability "specifies the factors required to establish the required reliability of the software system at time of delivery". In other words, it "describes the degree to which the system must work for the users" (McEwen, 2004). Availability requirements "specify the factors required to guarantee a defined availability level for the entire system such as checkpoint, recovery, and restart". Numerical requirements that belong to a specific function should be specified as part of the function requirement and not as part of the performance requirements category or of the sub-categories.

3.2 Availability:

Availability specifies the percentage of time available, hours of use, maintenance access, degraded mode operations such as: Mean Time between Failure (MTBF): MTBF is normally specified in hours, but it also can be specified in terms of years, month and days. Mean Time to Repair (MTTR): mean how long the system permitted to be out of operation after it has unsuccessful?

3.2.1User requirements specifications:

One of the critical success factors in the development of a high quality software product is the deep understanding of the user's real requirements, as opposed to their perceived requirements. This is where many projects fail; they do not correctly specify what the system should do.

The user requirements stage is crucial for the development of any application. Especially for innovative tools where the users do not have a clear idea of what they would like the system to do for them, there is the risk of creating a tool that does not meet actual and important user requirements. User Requirements Capture is the process by which user desires, needs and expectations are gathered in order to establish what the users will actually use the software for and recorded in a way that will be meaningful both to users and developments.

3.2. 2 Customer:

To be able to better understand the requirements of the customer, background reading is required in the domain of the business system as well as in technical concepts relating to hardware and software platforms, language etc. which are relevant to the system being developed. If the customer follows a particular methodology or uses certain tools, familiarization with them is required. When standard information and answers to closed-ended questions are to be gathered from many users, questionnaires become very useful. Hence the analyst should prepare questionnaires relating to the customer's business and operating environment. The analyst should also identify the user groups and other people that need to be interviewed. The organization structure can help in identifying the interviewees. Usually, the time the users can devote to giving information and requirements is limited. Hence a plan for interviewing should be made to make effective use of the time available for requirements gathering, keeping in mind the order of information gathering and the availability of people.

Gathering requirements involves obtaining all relevant information that will help in understanding the customer's requirements. Customer's requirements can be classified as business, functional, interface, operating environment, performance, standards, and special requirements. Business requirements establish the goals and scope of the system. Functional requirements are the end-users' view of required business functionality, and implementing them is the basic purpose of the project. The business system basically responds to and processes a set of events. Hence understanding the business functions, for the most part, involves understanding the various events that take place and the business processing that happens in response to these events. Events can be of two types – external events which are triggered by external entities or temporal events which are triggered by time. Besides identifying the events, it is necessary to identify inputs and outputs for all events. The relationship between inputs and outputs of an event is really the processing that needs to be performed by the system in response to a business event.

3.2. 3 Development

As stated earlier, it is important that the requirement specification be used as the baseline for the subsequent stages of development and acceptance testing. However, as work proceeds, the requirement may change even if only to cover points which are exposed by the development process. It is therefore essential that the specification be kept up-to-date, particularly during the development and testing phases and, to do this effectively, disciplined configuration control procedures are required.

4.0 Conclusion and Recommendation:

System analysis and design is used to analyse, design and implement improvements in the functioning of businesses that can be accomplished through the use of computerized information systems. In my opinion, SAD is useful and important in every system development.

The dataflow diagram is one of the most commonly used systems-modelling tools, particularly for operational systems in which the functions of the system are of paramount importance and more complex than the data that the system manipulates.

In my opinion, that system and software requirements are part of a dynamic and complex world. Requirements are targeted at multiple audiences. Many stakeholders need readable and understandable requirements, while the product creation crew needs SMART requirements. Software requirements tend to have much more detail than system requirements. A requirements specification drives the project plan and the product creation process. A "good" requirements specification facilitates a focused and smooth development process.