Introduction To Sad

Published Date: 02 Nov 2017

Systems analysis informs the development of large or small, but often complex, systems and the interactions within those systems. It provides structured processes that help to ensure designs are reliable. In this chapter, participants will gain an understanding of the principles and steps involved in systems analysis and documentation involved in the analysis and design stages. A key step is to determine the requirements and writing the requirements specification. Clear statements and understanding of the requirements are essential to ensure that an appropriate solution is designed. In addition, the specification will provide the basis for later testing and evaluation.

The unit looks at why organizations undertake systems analysis as well as the benefits of carrying out such a formal process. A wide variety of methodologies are used, however they are all based on similar fundamental principles.

Learners will become familiar with a limited number of lifecycle models and the associated terminology involved in the analysis and investigation of a system. Learners will develop a detailed knowledge and understanding of different methodologies and their benefits and uses in particular situations.

System analysis and design focus on systems, processes and technology.

Define Question 1

A two-dimensional diagram explaining how data is processed and transferred in a system. The graph identifies each data source and how it interacts with other data sources to arrive at a common output. People looking to develop a data flow diagram must identify the external inputs and outputs, determine the inputs and outputs are interrelated, and explain how they relate to graphics and what these connections will result in. This type of diagram that helps development companies and design teams to visualize how data is processed and identify or improve certain aspects.Intro to Data Flow Diagram

As its name suggests, a dataflow diagram depicts the data flow. DFD aid in creating a structural representation of what happens to the data as it is processed through an information system. In simpler terms, the DFD track data from an original source, the transported through a process then flows to a final destination. A DFD is a visual guide to how a system works and what takes place, and implementation details.

The exact details of the process, including issues such as the calendar, there are factors in the design of a DFD. The focus is on the movement of data. But like other structural tools, such as algorithms and flowcharts, DFD often occur with increasing levels of detail.

Answer Question 1

I will use a transportation system for explanation. I will draw a data flow diagram. I will us DFD level-0 until level-2. In this explanation I will briefly talk about this transportation system. You will easily get understand, data flow diagram (DFD) will explain you in step by step.

Please refer to the diagram below:-

*Data Flow Diagram-Level 0*

Diagram above, is showing you how Transportation system process. Customer will give destination and item info, at the same time also will make payment. We will give receipt to customer for proof. At last, we will make a summary report.

*Data flow Diagram-Level 1*

Data flow diagram-Level 1 will show you an briefly transportation process.

*Data Flow Diagram-Level 2*

Data flow diagram-level 2 will show you a transportation process in details.

-1.0

-2.0

Data Dictionary

Process name or label : Destination & Item

Description : Giving destination & Item info

Process number : 1.1

Process description : Collect destination & Item info*Process*

Process name or label : Checking Item

Description : Identify the Item

Process number : 1.2

Process description : Verifying or identify the Item info

Process name or label : Calculate weight & distance

Description : Calculate the item weight & distance

Process number : 2.1

Process description : Calculate the item price

Process name or label : Print Receipt

Description : Print the receipt for customer

Process number : 2.2

Process description : Giving a proof for customer

Process name or label : Summary report

Description : Make a report

Process number : 3.1

Process description : Make a report for QM

Entities

Entity name : Customer

Description : A people who expense in this system

Input data flows : Customer Order and Payment

Output data flows : Receipt

Entity name : QM

Description : A people to making decision

Input data flows : Check Report

Data Store

Data store name or label : Record Destination & Item

Description : Used to store the item info

Data store number : D1

Data store

Data store name or label : Record Profit

Description : Used to store the profit

Data store number : D2

Data Flows

Data flow name or label : Destination & item info

Description : Give destination & item info

Origin : Customer

Destination : 1.1 Collect item

Record :

Data flow name or label : Detail info

Description : The customer order list recording in database

Origin : 1.1 collect item

Destination : D1 Destination & item info

Record :

Data flow name or label : Payment

Description : making transaction

Origin : customer

Destination : 2.0 Billing

Record :

Data flow name or label : Receipt

Description : Give proof for customer

Origin : 2.0 Billing

Destination : Customer

Record :

Data flow name or label : Profit Detail

Description : Profit info

Origin : 2.0 Billing

Destination : D1 Profit Record

Record :

Data flow name or label : weight & distance Info

Description : Identify item weight & distance

Origin : D1 Record Destination & Item

Destination : 2.0 Billing

Record :

Data flow name or label : Profit Info

Description : Profit infromation

Origin : D2 Profit Record

Destination : 3.0 Record

Record :

Data flow name or label : Summary Report

Description : Making report

Origin : 3.0 Report

Destination : QM

Record :

Data flow name or label : Cost item

Description : Calculate the price of item

Origin : 2.1 calculate weight and item

Destination : 2.2 Print result

Record :

Define Question 2

The requirements specification is a document that clearly and precisely defined logical requirements of the customer (or needs) so that you can test the finished system to verify that these needs are met in fact. The aim is to ensure that customer needs are properly defined ahead of time, money and resources are wasted working on the wrong solution. Generally, writing formal requirements specification is the final step in the analysis phase of the development life cycle of the system.

Answer Question 2

What is requirement specification?

Requirement specification is part of the planning phase. Since it is the most important part, is discussed separately in this conference. Requirements specification is the basis for all engineering activities. Despite having the greatest impact on the analysis referred to in all subsequent stages

SRS (System Requirements Specification) is a formal document that is usually an addendum to the contract. It differs from the vision of the system as a formality, so that all vagueness is judged based on the statements of SRS. It can be a problem if the contract was signed early and does not include clauses on possible changes of SRS. The first version of the SRS is usually written without deep reflection. Simply customer statements are observed. However customers usually do not have computer skills and have a bad experience in software systems. So you probably can skip some important requirements. Developers should get some education on the problem domain with them may authorize the SRS in the second version. As can be seen the SRS may be changed during the development process. However careful (but time consuming) the requirement specification results in more stable base for the whole project.

According to the Kano’s model [3], there are three classes of requirements:-

Basic requirements– they are explicitly expressed by customers and may be simply placed into the SRS,

Implicit but expected requirements – they are regarded by customers as obvious and rarely are placed in the first version of the SRS, however if they are not fulfilled, the customers are dissatisfied,

Implicit and unexpected requirements– the customers may be not aware of them, but if they are fulfilled, the customers even may be excited.

A simple example can show that not only the basic requirements should be placed in the SRS. Imagine hanging system software daily. Customers will not be satisfied. System vendors can defend in court that there was no requirement on MTBF (mean time between failures) in the SRS. You can even win but will lose customers and reputation. Therefore also the implicit requirements should be inserted into the SRS to create benchmarks for developers as not to forget some important issues. However, the realization of all they need the time and cost. Prioritize requirements can be applied to judge which of them will be fulfilled first, and that future versions.

System Requirements Specification (SyRS)

A typical computer application includes a combination of software components, hardware and networks. System Requirements Specification (SyRS) is a detailed description of the requirements needed to create complete system. These requirements are documented in an effort to define the full functionality, availability, performance, security and system requirements

The Institute of Electrical and Electronics Engineers (IEEE) is the largest technical society at now dedicated to the rules in the field of electronics and computers. IEEE has established a set of standard procedures as a specification of system requirements must be documented. This documentation includes guidance on the establishment, organization and modifications of the system requirements.

Creating a system requirements specification is typically completed by a business analyst. The business analyst is a professional who is responsible for converting business jargon in technical solutions. She is the liaison between the company and the technical community. A good business analyst is a good communicator who can articulate the business needs a technical team.

There are many benefits in following the guidelines on best practices for system requirements specification. The requirements specification is the basis of the architecture, design and implementation to be built. These requirements are used to determine the level of effort required to complete a project. Bad requirements are comparable to a bad foundation for a building, which always lead to none.

All systems have performance requirements that must be documented in the system requirements specification. These requirements define the response time, availability and productivity of a system for specific tasks. For example, an insurance company could have a requirement to process 100,000 insurance claims per day. This requirement is considered a performance requirement.

A functional requirement is a property of a system based on specific business processes. A functional requirement could be as simple as the rules for how an application must create and save data on the system. For example, a company might require that all individuals should have an address for the system to save the data to a storage device. This functional requirement is documented in the requirements specification.

Security requirements are often the most important aspects of a system. These requirements are documented to describe how data will be accessed and policies should be used to encrypt data within the application. With the constant threat of hackers and online predators, cyber security has become an increasingly important requirement for most computer systems.

How is the layout of a formal requirement specification?

We will distinguish specification of the requirements. There activities interact in a iterative process. The specification of the requirements consists of building three views or models: the information model, Function model and Control model.

The information model describes the static aspects of the system, whereas the function model and control model describe the behavior. In the function model, the various operations on the state are defined. The control model specifies the actual interaction with the system, and the order in which the operations occur, in response to the input.

This means that informal and formal requirements are interleaved. Intermediate documents also contain a list of unsolved questions. An additional advantage of a literate specification is, that is allows to circumvent the rigid order imposed by formal languages; the specification can now be presented in a top-down way.

Specification of the models

Information model

The information model describes the static part of the specification. It can be seen as an abstraction of the global state of the system. In command and control system, the information model describes the abstract picture of the environment.

Typically, the information model consists of a number of entities, together with certain relations between them. A number of constraints can restrict the set of allowed states. These constraints specify the invariant properties that the state should have. For each entity, its attributes are specified, by declaring their names and the range of values they can take. Attributes can have special properties, such as being optional.

Function model

The function model defines the manipulations that change the state. These manipulations can be seen as a relation between succeeding states. The manipulations carry additional arguments, representing the input to the system. Only when the system is deterministic, the manipulations can be described as functions.

Control model

The control model specifies the interaction of the system, for example as the set of valid sequences of atomic actions. We focus on input actions. The interaction protocol induced by the set of valid input sequences represents the assumptions about the environment.

In addition, the control model specifies how the input actions trigger the manipulations defined by the function model. In this sense, the control model defines in which order the manipulations shall be performed. It also indicates the initial state

Layout of requirement specification

Introduction

Purpose

Document conventions

Project scope