The Systems Analysis And Systems Design

Published Date: 02 Nov 2017

1.0 Introduction

Systems development can generally be thought of as having two major components: Systems analysis and Systems design. System design is the process of planning a new business system or one to replace or complement an existing system. But before this planning can be done, we must thoroughly understand the old system and determine how computers can best be used to make its operation more effective. System analysis, then, is the process of gathering and interpreting facts, diagnosing problems, and using the information to recommend improvements to the system. This is the job of the systems analyst.

In business, 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

A data-flow diagram also known as (DFD) is a graphical representation of the "flow" of data in an information system. DFDs are also able to be utilized for the visualization of data processing like structured design.

Data items will flow from an internal data store or an external data store to an external data store or an internal data store by using an internal process on a DFD.

DFDs doesn’t provide information related to the ordering or timing of processes, or about how processes will operate such as in parallel or in sequence. Therefore, it is not similar from a flowchart, which will show the flow of the control in an algorithm, this allows a reader to decide what operations will be performed, under what circumstances and what orders, but not what kinds of data will be output or input from the system, where the data go to and come from and also where the data will be stored. These are all shown on a DFD.

When it comes to expressing how information data flows through systems and how data is transformed in the process, DFDs are the method of choice instead of choice over technical descriptions for three principal reasons. Firstly, DFDs are not difficult to understand by technical and nontechnical audiences. Secondly, DFDs have the capabilities by providing a high level system of overview that was completed with connections and boundaries to other systems. Third and lastly, DFDs are able to give out a clear and detailed representation of system components.

DFDs assist designers at the period of initial analysis stages visualize a temporary system or the one that may be needed to meet newer requirements. Most of the system analysts favors working with DFDs, when they need a clear understanding of the boundary among postulated and existing systems. DFDs represent the following, external devices and receiving data, data flow themselves, processes that changes data and lastly data storage locations.

The hierarchical DFD has a top level diagram which is (Level 0) underlain by cascading lower level diagrams which is (Level 1, Level 2…) that will represent different parts of the system.

Level 0 Diagram

Ingredient Received Received Received

Food Received

Order System

Kitchen

Customer

Order Delivered

Order Received

Food Delivered

Payment Food Received

Order Received

Order Sent

Payment

Ingredient Received

Supplier

Level 1 Diagram

4.0 Arrangement

AccountTransaction Ingredients Received

Payment Ingredients Received

Order Received

Customer

1.0 Accounting

Kitchen

Payment

Order Received

Food Received Food Delivered

2.0 Service

Food

Ingredients Stored

Payment

3.0 Procurement

Goods Received

Supplier

Order Sent

Level 2 Diagram

1.1 Ordering

Kitchen

Order Received

Order Received

Customer

Payment

1.2 Collection

Transaction Account

3.1 Product

Supplier Order Sent

Ingredients received

Ingredients Stored

Food Payment

3.2 Paying

Payment

Account

Data Dictionary

Level 0 Diagram

Process

Process Name or Label : Order System

Process Number : 0.0

Process Description : A system for customer to order in a restaurant

Entities

Entity Name : Customer

Description : The one who order

Input Data Flows : Food Received

Output Data Flows : Order Received and Payment

Entity Name : Kitchen

Description : The one who get the food cooked

Input Data Flows : Ingredient Received and Order Delivered

Output Data Flows : Food Delivered

Entity Name : Supplier

Description : The one who supplies the ingredients

Input Data Flows : Order Sent and Payment

Output Data Flows : Ingredients Received

Data Flow

A) Data Flow Name or Label : Food received

Description : Foods that received by customers

Origin : Order System

Destination : Customer

B) Data Flow Name or Label : Order Received

Description : Order that received by order system

Origin : Customer

Destination : Order System

C) Data Flow Name or Label : Payment

Description : Money that is paid by customer

Origin : Customer

Destination : Order system

D) Data Flow Name or Label : Ingredients received

Description : Ingredients that received by kitchen

Origin : Order System

Destination : Kitchen

Data Flow Name or Label : Order Delivered

Description : Order that was delivered to the kitchen

Origin : Order System

Destination : Kitchen

Data Flow Name or Label : Food delivered

Description : Foods that was delivered to the Order system

Origin : Kitchen

Destination : Order system

Data Flow Name or Label : Ingredients received

Description : Ingredients that was received by order system

Origin : Supplier

Destination : Order system

Data Flow Name or Label : Payment

Description : Money that was paid to the supplier

Origin : Order system

Destination : Supplier

I) Data Flow Name or Label : Order sent

Description : Orders that were sent by the order system to supplier

Origin : Order System

Destination : Supplier

Level 1 Diagram

Process

Process Name or Label : Accounting

Process Number : 1.0

Process Description : The place that orders or payments go through

Process Name or Label : Service

Process Number : 2.0

Process Description : The place that food delivers to and food received from customer

Process Name or Label : Procurement

Process Number : 3.0

Process Description : The one that deals with supplier

Process Name or Label : Arrangement

Process Number : 4.0

Process Description : The one that arrange ingredients

Entities

Entity Name : Customer

Description : The one who order

Input Data Flows : Foods Received

Output Data Flows : Payment and order received

Entity Name : Kitchen

Description : The one who get the food cooked

Input Data Flows : Order received and ingredients received

Output Data Flows : Food delivered

Entity Name : Supply

Description : The one who supplies the ingredients

Input Data Flows : Payment and order sent

Output Data Flows : Ingredients received

Data Flows

Data Flow Name or Label : Order received

Description : Order received by customer

Origin : Customer

Destination : Accounting

Data Flow Name or Label : Payment

Description : Money that was paid by customer

Origin : Customer

Destination : Accounting

Data Flow Name or Label : Food Received

Description : Food that received by customer

Origin : Service

Destination : Customer

Data Flow Name or Label : Transaction

Description : Money that is paid to procure

Origin : Account

Destination : Procurement

Data Flow Name or Label : Payment

Description : Money that is paid to the account

Origin : Accounting

Destination : Account

Data Flow Name or Label : Order Received

Description : Order that was received by accounting to kitchen

Origin : Accounting

Destination : Kitchen

Data Flow Name or Label : Food Delivered

Description : Food that was delivered by kitchen to service

Origin : Kitchen

Destination : Service

Data Flow Name or Label : Ingredient Stored

Description : Ingredients that is stored to food

Origin : Procurement

Destination : Food

I) Data Flow Name or Label : Ingredients received

Description : Ingredients that are received by kitchen

Origin : Arrangement

Destination : Kitchen

Data Flow Name or Label : Payment

Description : Money that is paid by procurement to supplier

Origin : Procurement

Destination : Supplier

Data Flow Name or Label : Goods Received

Description : Goods that are received by supplier to procurement

Origin : Supplier

Destination : Procurement

Data Flow Name or Label : Order Sent

Description : Order that is sent to the supplier

Origin : Procurement

Destination : Supplier

Data Flow Name or Label : Ingredients received

Description : Ingredients received by the arrangement

Origin : Food

Destination : Arrangement

Data Stores

Data Store Name or Label : Account

Description : To store money, act like a bank.

Data Store Name or Label : Food

Description : Place that store ingredients

Level 2 Diagram

Process

Process Name or Label : Ordering

Process Number : 1.1

Process Description : The process of ordering

Process Name or Label : Collection

Process Number : 1.2

Process Description : The one that collects money

Process Name or Label : Product

Process Number : 3.1

Process Description : The one that gets the ingredients from supplier and stores in food.

Process Name or Label : Paying

Process Number : 3.2

Process Description : The one that arranges money and pay to supplier

What is requirement specification?

The requirements specification is a document that clearly and precisely defines the customer’s logical requirements (or needs) in such a way that it is possible to test the finished system to verify that those needs have actually been met. The point is to ensure that the customer’s needs are correctly defined before time, money, and resources are wasted working on the wrong solution. Typically, writing a formal requirements specification is the final step in the analysis phase of the system development life cycle. A requirement is something that must be present in the system. The requirements specification is a document that clearly and precisely defines the customer’s logical requirements (or needs) in such a way that it is possible to test the finished system to verify that those needs have actually been met. The point is to ensure that the customer’s needs are correctly defined before time, money, and resources are wasted working on the wrong solution.

Strengths, weaknesses, and limitations

The logical models and prototypes prepared during analysis are often less than adequate as a foundation for system design. The requirements specification builds on the logical models, providing an unambiguous, precise definition of the user’s needs. If work is outsourced or subcontracted, the requirements specification can be added to the contract to define the deliverables.

Although a few pages might be enough to define a simple system’s requirements, a complete requirements specification for a significant system can be quite lengthy, and preparing one is both time consuming and expensive. Requirements can change over time, and the requirements specification must be flexible enough to change with them. Often, this is not the case.

Types of requirements

A behavioral requirement defines something the system does, such as an input, an output, or an algorithm. Under this category, a functional requirement identifies a task that the system or component must perform, and an interface requirement identifies a link to another system component.

Non-behavioral requirements define attributes of the system. For example, performance requirements specify such characteristics as speed, frequency, response time, accuracy, and precision. Other non-behavioral requirements might define such parameters as portability, reliability, security, and maintainability.

Such constraints as physical size and weight, environmental factors, ergonomic standards, and the like are listed in design requirements or constraint requirements. Quality requirements, often stated as an acceptable error rate, the mean time between failures, or the mean time to repair, are sometimes grouped with performance requirements, but many organizations list them separately. Firms that have adopted total quality management often include additional measures of quality.

Economic requirements specify such things as performance penalties, limits on development and operating costs, the implementation schedule, and resource restrictions. They are more common in Europe than in the United States. Occasionally, marketing and political requirements are added.

Characteristics of a good requirement

A good requirement is unambiguous, testable (or verifiable), consistent with other requirements, correct (every listed requirement must actually be a requirement), understandable, modifiable (requirements can change), and traceable to both higher-level (parent) and lower-level (child) requirements.

Importance of 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.

SRS requirements

SRS also stands for software requirement specification, is normally the understanding of an organization with the form of writing or blueprint of a client or customer’s system requirements and dependencies at a certain point of time normally due to any development work or actual design. It’s a two-way document that makes sure both the organization and client realize the requirements by others from that perspective at a given point of time.

The SRS document itself uses precise and explicit language that those capabilities and function a software system need to provide, by also stating any constraints that are required by which the system must abide. A blueprint is also what the SRS function as to complete a project with as little cost growth as possible. The SRS is always referred to as a parent document because of all subsequent project management documents for example statements of work, design specifications, software architecture specifications, testing and plans like documentation plans and validation plans that relate to it.

It's fairly important that SRS has functional and nonfunctional requirements only. It doesn't offer design suggestions or possible solutions to technology or business issues, or maybe any other information other than what the development team realizes what are the requirements of customers.

Advantages

 Software SRS establishes the basic for agreement between the client and the supplier on what the software product will do.

 

1.    A SRS provides a reference for validation of the final product.

2.    A high-quality SRS is a prerequisite to high-quality software.

3.    A high-quality SRS reduces the development cost.

 Characteristics of an SRS

1.       Correct

2.       Complete

3.       Unambiguous

4.       Verifiable

5.       Consistent

6.       Ranked for importance and/or stability

7.       Modifiable

8.       Traceable

 

An SRS is correct if every requirement included in the SRS represents something required in the final system. An SRS is complete, if everything the software is supposed to do and the responses of the software to all classes of input data are specified in the SRS. Correctness ensures that what is specified is done correctly, completeness ensures that everything is indeed specified.

 

An SRS is unambiguous if and only if every requirement stated has one and only one interpretation. Requirements are often written in natural language, which are inherently ambiguous.

 An SRS is verifiable if and only if every stated requirement is verifiable. A requirement is verifiable if there exists some cost-effective process that can check whether the final software meets that requirement. An SRS is consistent if there is no requirement that conflicts with another.

 Terminology can cause inconsistencies; for example, different requirements may use different terms to refer to the same object. All the requirements for software are not of equal importance. Some are critical, others are important but not critical, and there are some, which are desirable, but not very important. An SRS is ranked for importance and the stability of the requirement are indicated. Stability of requirement reflects the chances of it changing in future. An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development. Forward traceability means that each requirement should be traceable to some design and code elements. Backward traceability requires that it be possible to trace design and code elements to the requirements they support. Traceability aids verification and validation.

System requirement specification

System requirement specification (SyRS) is a detailed outline of the requirementsnecessary to create a complete system. These requirements are documented in an effort to define the complete functionality, availability, performance, and security needs of a system.

The Institute of Electrical and Electronics Engineers (IEEE) is the largest technical society dedicated to standards in the electronic and computer field. IEEE has created a set of standard procedures on how a system requirement specification should be documented. This documentation includes guidance on the creation, organization, and modifications of the system's requirements.

The creation of a system requirement specification is typically completed by a business analyst. The business analyst is a professional who is responsible for converting business jargon into technical solutions. She is the liaison between the business and the technical community. A good business analyst is an effective communicator who can articulate business needs to a technical team.

There are many benefits in following the best practice guidelines for a system requirement specification. The requirements specification is the foundation of the architecture, design, and implementation that will be built. These requirements are used to determine the level of effort needed to complete a project. Bad requirements are comparable to a bad foundation for a building, which will always lead to a failed implementation.

Conclusion and recommendation

SAD allows us to organize a business’s IT requirements and it will form the blueprint of the software that are built to assist the business operations. Without the techniques of system analysis and design, management of the project will be impossible. Final products will never be manageable.

Data flow diagram is a very simple graphical technique which is easy for us users to understand. It helps us by defining the boundaries of the system. It is also very useful for us to communicating current system knowledge to the users. The biggest benefit to me is it explains clearly about the logic behind the data flow within the system.

A good requirement specification will reflect the real needs of all stakeholders, it will describe a feasible product, answers the most critical design questions, and lastly a good requirement specification is very useful for human product creators.