Skip to main content

Why system modeling; weakness of structured analysis

Short answer

System modeling is important for understanding the problem, enabling communication, providing multiple perspectives, finding missing requirements, serving as design basis, and documenting the system. Structured analysis weaknesses include poor support for non-functional requirements, no suitability guidance, excessive documentation, models difficult for users, separation of data and process models, and difficulty maintaining consistency when requirements change.

Why system modeling is important? Mention the weakness of structured analysis method?

System modeling is the process of building abstract models of a system, where each model shows the system from one perspective (context, interaction, structure or behaviour). Models are usually drawn using notations such as DFD, ER diagram, state diagram or UML.

Why system modeling is important

  1. Understanding the problem – a model removes unnecessary detail so the analyst can focus on the essential functions and data.
  2. Communication – diagrams are easier for customers, analysts and developers to discuss than long text; misunderstandings are caught early.
  3. Different perspectives – context models show the system boundary, behavioural models (DFD, state chart) show processing, and structural models (ER, class diagram) show data, so nothing important is missed.
  4. Finding missing or wrong requirements – incomplete flows, unused data or impossible states show up in the model.
  5. Basis for design and implementation – models evolve into architectural and detailed design; in model-driven engineering code can even be generated from them.
  6. Documentation – models describe the existing system and the proposed system for later maintenance.

Weaknesses of the structured analysis method

Structured methods (DeMarco, Yourdon, SSADM) use DFDs, ER diagrams and data dictionaries. Their main weaknesses are:

  1. Poor support for non-functional requirements – they model functions and data but cannot express performance, security, reliability or usability needs well.
  2. No guidance on suitability – they do not tell the analyst whether the method suits a given kind of problem (e.g. real-time or interactive systems).
  3. Too much documentation – they produce a large number of diagrams and dictionary entries, and the essential requirements can get hidden.
  4. Models are hard for users – detailed, levelled models are difficult for customers to understand and validate.
  5. Separation of data and process – functions (DFD) and data (ERD) are modelled separately, so a change in one is hard to trace to the other and the models do not map directly to object-oriented code.
  6. Difficult to maintain – when requirements change, many levels of diagrams must be updated consistently.

✓ Answer checked by Claude Sonnet 5.5

Related questions

All Software Engineering chapter 2 questions →