At a technical level, software engineering begins with a series of modeling tasks that lead to a complete specification of requirements and...
At a technical level, software engineering begins with a series of modeling tasks that lead to a complete specification of requirements and a comprehensive design representation for the software to be built. The analysis model, actually a set of models, is the first technical representation of a system. Over the years many methods have been proposed for analysis modeling.
However, two now dominate. The first, structured analysis, is a classical modeling method .Structured analysis is a model building activity. Applying the operational analysis principles, we create and partition data, functional, and behavioral models that depict the essence of what must built. Structured analysis is not a single method applied consistently by all who use it. Rather, it is an amalgam that evolved over more than 30 years.
In his seminal book on the subject, Tom DeMarco describes structured analysis in this way:
Looking back over the recognized problems and failings of the analysis phase, I suggest that we need to make the following additions to our set of analysis phase goals:
• The products of analysis must be highly maintainable. This applies particularly to the Target Document [software requirements specifications].
• Problems of size must be dealt with using an effective method of partitioning. The Victorian novel specification is out.
• Graphics have to be used whenever possible.
• We have to differentiate between logical [essential] and physical [implementation] considerations . . . At the very least, we need . . .
• Something to help us partition our requirements and document that partitioning before
specification . . .
• Some means of keeping track of and evaluating interfaces . . .
• New tools to describe logic and policy, something better than narrative text . . .
• Problems of size must be dealt with using an effective method of partitioning. The Victorian novel specification is out.
• Graphics have to be used whenever possible.
• We have to differentiate between logical [essential] and physical [implementation] considerations . . . At the very least, we need . . .
• Something to help us partition our requirements and document that partitioning before
specification . . .
• Some means of keeping track of and evaluating interfaces . . .
• New tools to describe logic and policy, something better than narrative text . . .
There is probably no other software engineering method that has generated as much interest, been tried (and often rejected and then tried again) by as many people, provoked as much criticism, and sparked as much controversy. But the method has prospered and has gained a substantial following in the software engineering community.
