The Structured Analysis And System Specification Information Technology Essay

This term paper contains the research related to the Structured Analysis and System Specification. It explains about the structure analysis and its history. It also explains about the different approaches used in structured analysis with their purpose, pros and cons.

Software development is a human activity. Like any human activity, it has many facets, and can be analysed from many points of view. Social scientists and experts in human relations examine the interactions among developers and between the development group and its customers. Lawyers and trades unionists see software systems as a means of changing working practices. Business theorists analyse development projects for their profitability, and measure return on investment. Quality control experts see the need for process optimisation based on statistical evidence. Some software developers see themselves as engineers, and want to be judged by the canons of such established disciplines as aeronautical, civil, or electrical engineering.

Software development does have a substance all of its own that gives it its special character. Software development is about the structure and technique of description. The task of the developer is to create transparently clear descriptions of complex systems in which many domains meet and interact ¾ computing machinery and many other things too. But software development is not mathematics any more than bridge building is mathematics. The central emphasis is on description more than on invention, on structure more than on calculation, on achieving self-evident clarity more than on constructing proofs of unobvious truths. Some properties of complex systems will demand and admit formal proof. But most will require a transparent clarity of description, and a separation of concerns by which clarity may be attained.

Development method, therefore, must concentrate on the separation of concerns and on their description once they have been separated: the central questions are what to describe, and how to describe it. Because the systems we develop are complex, there will be many things to describe, and their descriptions will be of many kinds. The relationships among descriptions will form non-trivial structures, and we will be concerned to keep intellectual control of these structures and to know clearly what each description describes and how it is related to the other descriptions. These concerns are not always well served by our present culture of software development.

Structured Analysis

The term structured analysis, within the domain of the software development, describes a set of techniques used in design of computer applications. These techniques help explaining the required steps within the computer application in more humanistic manner. The results of that thorough structured analysis and the design approach typically described both the physical and the logical layers of computer application.

Software engineering is a complex process that requires intricate detail on the specifics about how the software application will function. The early pioneers of software engineering realized that this complexity required a method of formality that would not only document the system, but also explain the process in terms that could be understood by the general public. Structured analysis is the process that is used for documenting this complexity.

Structured analysis and design are broken into four primary domains within application architecture. These are the data flows, data models, structure charts, and state models. All of these domains are typically represented in a manner starting from a summary level and progressing into a detail level of interpretation.

One of the key tools used in structured analysis for this visualization approach are data flow diagrams. Data flow diagrams were first introduced into as a method of capturing the flow of data within an application, explaining how that data moves from process to process. Each process is connected using a line with an arrow, representing the flow of data between the processes.

Data models represent the relationships between data within an application in a logical manner. These models further clarify the data needed to complete the processes defined in the data flow diagrams. There are many tools and techniques used for the creation of data models, but the primary goal is to define the usage of data and the relationships between one data element and another.

Structure charts are used to define the summary structure flow from one process to another. These charts are used as a blueprint on how an application will communicate between processes or modules. Structure charts follow a functional decomposition approach, staring at a high-level design and breaking down into a detail design.

The final component necessary in structured analysis is state models. They define the state or behavior of an application. These models are joined with data flow models to define the events of an application

These four primary domains make up the necessary techniques to define a system with structured analysis and design. While there are other methods that can be used for software development interpretation, structured analysis remains a viable option for defining the complex inner working of a software application.

History

Structured Analysis is the part of series of structured methods that “represents the collection of the analysis, design and programming techniques thatwere developed in response to problems facing the software world from 1960s to 1980s. Structured Analysis is developed in the late 1970s by DeMarco, Yourdon, and Constantine after the emergence of structured programming. IBM incorporated it into their development cycle in the late 1970s and early 1980s. In 1989, Yourdon published “Modern Structured Analysis”. The availability of CASE tools in the 1990s enabled analysts to develop and modify the graphical SASD models.

Different Structured Analysis Approaches

Structured Analysis views the system as the perspective of the data flowing through the system. The function of system is described by processes that transformed the data flows. Structured analysis took advantage of the information hiding through successive decomposition analysis. This allows attention to be focused on relevant details and avoids the confusion from looking at the irrelevant details. As level of detail increases, breadth of the information is reduced. The result of the structured analysis is a set of related graphical diagrams, process descriptions, and the data definitions. The structured analyse approach develops perspectives on both process objects and data objects.

De Marco’s approach consists of the following objects :

Context diagram

Dataflow diagram

Process specifications

Data dictionary

Context diagram

Purpose

Highlights the boundary between the system and the outside world

Highlights the people, organizations, and outside systems that interact with the system under development

Special case of the data flow diagram

Notations

Process – Represents the proposed system

Terminator – Represents the external entities

Flow – Represents the in and out data flows

Example

Pros

Provides a black box overview of the system and the environment

Cons

• Does not provide a specific means to determine the scope of the system

Data Flow Diagram

Purpose

Provides a means for functional decomposition

Primary tool in analysis to model data transformation in the system

Notation

Represents functions in the system

Represents the external entities

Represents data flows

Represents data stores

Leveling

Example

Pros

Ability to represent data-flows

Functional decomposition – divide and conquer

Cons

Weak display of input/output detail

Users find it confusing initially

Do not represent time

No implied sequencing

Assign data stores early in the analysis with little deliberation

Process Specifications

Purpose

Shows process details, which are implied but not shown in a Data Flow Diagram

Specifies the input, output, and algorithm of a module in the DFD

Normally written using pseudo-code

Example

Apply Payment

For all payments

If payment is to be applied today or earlier and has not yet been applied

Read account

Read amount

Add amount to account’s open to buy

Add amount to account’s balance

Update payment as applied

Pros

Express the process specifications in a form that can be verified

Cons

They may be too technical for the users

Difficult to stay away from the current ‘How’

Data Dictionary

Purpose

Defines data elements to avoid different interpretations

Notation

‘ = ‘ Is composed of

‘ + ‘ And

‘ ( ) ‘ Element is optional

‘ { } ‘ Interation

‘ [ ] ‘ Select one of a list of elements

‘ | ‘ Separates choices of elements

‘ ** ‘ Comments

‘ @ ‘ Identifier for a store (unique id)

Examples

Element Name = Card Number

Definition = Uniquely identifies a card

Alias = None

Format = LD+LD+LD+LD+SP+…LD

SP = ” ” Space

LD = {0-9} Legal Digits

Range = 5191 0000 0000 0000 to 5191 9999 9999 9999

Pros

Simplifies data requirements

Used at high or low level analysis

Cons

No functional details

Formal language is confusing to users

Structure Charts

Purpose

Functional Decomposition (Divide and Conquer)

Information hiding

Modularity

Low coupling

High internal cohesion

Structure Charts

Notation

Modules

Library Modules

Module Call

Data

Flag

Example

Cohesion

Function – Elements are combined to complete one specific function

Sequential – Elements are combined because data flows from one step to another

Communicational – Elements are combined because they all act on one data store

Procedural – Elements are combined because control flows from one step to another

Temporal – Statements are together because they occur at the same time

Logical – Elements are together because of their type of function such as all edits

Coincidental – Elements are grouped together randomly

Coupling

Indirect relationship – Modules are independent and there is no way to communicate

Data – Only necessary data is passed between two modules

Stamp – A data structure is passed to a module but the module only needs a portion of the data in the data structure

Control – Flags are passed between modules

Pros

Modularity improves system maintainability

Provides a means for transition from analysis to design

Provides a synchronous hierarchy of modules

Cons

Does not work well for asynchronous processes such as networks

Could be too large to be effectively understood with large programs

System Specification

In the context of computer-based systems (and software), the term specification means different things to different people. A specification can be a written document, a graphical model, a formal mathematical model, a collection of usage scenarios, a prototype, or any combination of these.

Some suggest that a “standard template” [SOM97] should be developed and used for a system specification, arguing that this leads to requirements that are presented in a consistent and therefore more understandable manner. However, it is sometimes necessary to remain flexible when a specification is to be developed. For large systems, a written document, combining natural language descriptions and graphical models may be the best approach. However, usage scenarios may be all that are required for smaller products or systems that reside within well-understood technical environments.

The System Specification is the final work product produced by the system and requirements engineer. It serves as the foundation for hardware engineering, software engineering, database engineering, and human engineering. It describes the function and performance of a computer-based system and the constraints that will govern its development. The specification bounds each allocated system element. The System Specification also describes the information (data and control) that is input to and output from the system.

Acknowledgement

I take this opportunity to present my votes of thanks to all those guidepost who really acted as lightening pillars to enlighten our way throughout this project that has led to successful and satisfactory completion of this study.

We are really grateful to our HOD for providing us with an opportunity to undertake this project in this university and providing us with all the facilities. We are highly thankful to Mr. Munish Kumar for his active support, valuable time and advice, whole-hearted guidance, sincere cooperation and pains-taking involvement during the study and in completing the assignment of preparing the said project within the time stipulated.

Lastly, I am thankful to all those, particularly the various friends , who have been instrumental in creating proper, healthy and conductive environment and including new and fresh innovative ideas for us during the project, their help, it would have been extremely difficult for us to prepare the project in a time bound framework.