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.<\/p>\n
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.<\/p>\n
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 \u00be 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.<\/p>\n
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.<\/p>\n
The term structured analysis, within the domain of the software development, describes a set of techniques used in design of computer\u00a0applications. 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.<\/p>\n
Software\u00a0engineering\u00a0is 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.<\/p>\n
Structured analysis and design are broken into four primary domains within\u00a0application 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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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<\/p>\n
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.<\/p>\n
Structured Analysis is the part of series of structured methods that \u201crepresents 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 \u201cModern Structured Analysis\u201d. The availability of CASE tools in the 1990s enabled analysts to develop and modify the graphical SASD models.<\/p>\n
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.<\/p>\n
De Marco\u2019s approach consists of the following objects :<\/p>\n
Context diagram<\/p>\n
Dataflow diagram<\/p>\n
Process specifications<\/p>\n
Data dictionary<\/p>\n
Highlights the boundary between the system and the outside world<\/p>\n
Highlights the people, organizations, and outside systems that interact with the system under development<\/p>\n
Special case of the data flow diagram<\/p>\n
Process \u2013 Represents the proposed system<\/p>\n
Terminator \u2013 Represents the external entities<\/p>\n
Flow \u2013 Represents the in and out data flows<\/p>\n
Provides a black box overview of the system and the environment<\/p>\n
\u00e2\u20ac\u00a2 Does not provide a specific means to determine the scope of the system<\/p>\n
Provides a means for functional decomposition<\/p>\n
Primary tool in analysis to model data transformation in the system<\/p>\n
Represents functions in the system<\/p>\n
Represents the external entities<\/p>\n
Represents data flows<\/p>\n
Represents data stores<\/p>\n
Ability to represent data-flows<\/p>\n
Functional decomposition \u2013 divide and conquer<\/p>\n
Weak display of input\/output detail<\/p>\n
Users find it confusing initially<\/p>\n
Do not represent time<\/p>\n
No implied sequencing<\/p>\n
Assign data stores early in the analysis with little deliberation<\/p>\n
Shows process details, which are implied but not shown in a Data Flow Diagram<\/p>\n
Specifies the input, output, and algorithm of a module in the DFD<\/p>\n
Normally written using pseudo-code<\/p>\n
Apply Payment<\/p>\n
For all payments<\/p>\n
If payment is to be applied today or earlier and has not yet been applied<\/p>\n
Read account<\/p>\n
Read amount<\/p>\n
Add amount to account\u2019s open to buy<\/p>\n
Add amount to account\u2019s balance<\/p>\n
Update payment as applied<\/p>\n
Express the process specifications in a form that can be verified<\/p>\n
They may be too technical for the users<\/p>\n
Difficult to stay away from the current \u2018How\u2019<\/p>\n
Defines data elements to avoid different interpretations<\/p>\n
\u2018 = \u2018 Is composed of<\/p>\n
\u2018 + \u2018 And<\/p>\n
\u2018 ( ) \u2018 Element is optional<\/p>\n
\u2018 { } \u2018 Interation<\/p>\n
\u2018 [ ] \u2018 Select one of a list of elements<\/p>\n
\u2018 | \u2018 Separates choices of elements<\/p>\n
\u2018 ** \u2018 Comments<\/p>\n
\u2018 @ \u2018 Identifier for a store (unique id)<\/p>\n
Element Name = Card Number<\/p>\n
Definition = Uniquely identifies a card<\/p>\n
Alias = None<\/p>\n
Format = LD+LD+LD+LD+SP+\u00e2\u20ac\u00a6LD<\/p>\n
SP = \u201d \u201d Space<\/p>\n
LD = {0-9} Legal Digits<\/p>\n
Range = 5191 0000 0000 0000 to 5191 9999 9999 9999<\/p>\n
Simplifies data requirements<\/p>\n
Used at high or low level analysis<\/p>\n
No functional details<\/p>\n
Formal language is confusing to users<\/p>\n
Functional Decomposition (Divide and Conquer)<\/p>\n
Information hiding<\/p>\n
Modularity<\/p>\n
Low coupling<\/p>\n
High internal cohesion<\/p>\n
Modules<\/p>\n
Library Modules<\/p>\n
Module Call<\/p>\n
Data<\/p>\n
Flag<\/p>\n
Function \u2013 Elements are combined to complete one specific function<\/p>\n
Sequential \u2013 Elements are combined because data flows from one step to another<\/p>\n
Communicational \u2013 Elements are combined because they all act on one data store<\/p>\n
Procedural \u2013 Elements are combined because control flows from one step to another<\/p>\n
Temporal \u2013 Statements are together because they occur at the same time<\/p>\n
Logical \u2013 Elements are together because of their type of function such as all edits<\/p>\n
Coincidental \u2013 Elements are grouped together randomly<\/p>\n
Indirect relationship \u2013 Modules are independent and there is no way to communicate<\/p>\n
Data \u2013 Only necessary data is passed between two modules<\/p>\n
Stamp \u2013 A data structure is passed to a module but the module only needs a portion of the data in the data structure<\/p>\n
Control \u2013 Flags are passed between modules<\/p>\n
Modularity improves system maintainability<\/p>\n
Provides a means for transition from analysis to design<\/p>\n
Provides a synchronous hierarchy of modules<\/p>\n
Does not work well for asynchronous processes such as networks<\/p>\n
Could be too large to be effectively understood with large programs<\/p>\n
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.<\/p>\n
Some suggest that a \u201cstandard template\u201d [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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[147],"tags":[494],"class_list":["post-454","post","type-post","status-publish","format-standard","hentry","category-information-technology","tag-the-structured-analysis-and-system-specification-information-technology-essay"],"_links":{"self":[{"href":"https:\/\/glowriters.com\/wp-json\/wp\/v2\/posts\/454"}],"collection":[{"href":"https:\/\/glowriters.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/glowriters.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/glowriters.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/glowriters.com\/wp-json\/wp\/v2\/comments?post=454"}],"version-history":[{"count":0,"href":"https:\/\/glowriters.com\/wp-json\/wp\/v2\/posts\/454\/revisions"}],"wp:attachment":[{"href":"https:\/\/glowriters.com\/wp-json\/wp\/v2\/media?parent=454"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/glowriters.com\/wp-json\/wp\/v2\/categories?post=454"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/glowriters.com\/wp-json\/wp\/v2\/tags?post=454"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}