Techniques are Sources of Questions

The word “technique” comes from ancient Greek: “téchne” means art. Techniques are tools, you can learn to use them at a theoretical level or by experience. Best, if you can, both theoretically and practically.

Analysis and design techniques are sources of questions, useful to treat a problem and to
approach a solution.


The Entity-Relationship technique, created for data modeling, leans on some fundamental questions:

  • which are the main concepts of the application domain (i.e. of the problem) facing us? (in technical jargon: which entities? which attributes?)
  • which are the links among these concepts? (in technical jargon: which relationships?)

These are questions that the developer (or the analyst, if this is a distinct role) makes to herself, when she faces a new problem.
In whatever application domain, from telecoms to military to financial systems. These questions may be asked to problem experts (e.g. customer, users) to clarify requirements. And these questions may be the starting point for the construction of the domain model, the skeleton of the future system.

Structured Analysis

The structured analysis technique, characterized by the usage of Data Flow Diagrams or SADT diagrams, had its peak in the 70s and in the 80s, now it is less used. But its fundamental questions are still useful:

  • which are the boundaries of the system? what is included, what is excluded? with which external systems does our system interact? (in technical jargon: which is the context?)
  • given a process (or system), which are its constituent parts? how are they related? (in technical jargon: how can you decompose it?)

Different questions from those of the Entity-Relationship technique. But generally applicable, and very useful to make to oneself, when facing a new problem. And a source of questions to the stakeholders, to clarify requirements.

Use Cases

Use cases too, as an analysis technique, are based upon some fundamental questions:

  • who will use the system, or will interact with it? (in technical jargon: who are the actors?)
  • what has (each of the actors) to do with the system? how will the actor use the system? (in technical jargon: which are the use cases?)

Again, these are different questions from those of the previously named techniques. But generally applicable, useful to clarify requirements and as a starting point for the design of the system.

Object Oriented analysis and design

Object oriented analysis and design retain and absorb some concept typical of structured approaches.
But there are new fundamental questions for system design:

  • which are the responsibilities of the various system parts?
  • how should the parts collaborate? Which is the best way to link them?
  • how can I make the parts stable?

Mastering the techniques means having tools at our disposal, to use when we need them.
In software development, it means to become able to ask oneself the questions needed to clarify requirements and to design the system.

The most important thing is that these techniques are complementary, they do not exclude each other. Every new technique entering our professional baggage enriches our ability to face new problems in an effective way. In some situations, the new technique will be particularly useful, while in other situations different techniques will be more adequate.