Software engineers love solutions. They like to play with several ways to solve a problem, compare them, discuss the advantages and disadvantages of each one of them, and explain the trade-offs and compromises taken to reach a particular solution. They feel comfortable in the solution space.
Curiously you can also play in the problem space. It is possible to write nice descriptions of the problem, compare them, and discuss their advantages and disadvantages. However, software engineers do not feel comfortable because it can become a never ending game, a kind of language trap. The description of the problem becomes an end in itself.
The best way to understand a problem is to write a solution to it, but, unfortunately this is not always that simple. It is true that complex problems can be solved by simply writing a solution to them. For instance, the solution for the logic puzzle, When is Cheryl's Birthday? by Peter Norvig is done describing the problem in terms of logic and letting the computer process the answer. These are logical problems but a group of other software engineering problems contain a lot of business logic which people very often argue to be illogical. Business logic is characterized by the lack of a elegant model which synthesizes the main aspects of the business. Actually, it results from the compromise between conflicting requirements from different stakeholders. It contains a large number of rules, each rule has many variations and exceptions which emerge because of the need to combine different situations. For instance, suppose that in a banking application credit card holders receive points whenever they use their credit card. This simple rule can have a lot of variations. The number of points received depends on the type of client, amount expended, the used currency, past use of the card, the period of the year, a marketing campaign, etc. Business logic diverge from nicely formulated logical problems because the complexity is on the number of rules and their variations, and the possibility that some of the rules may be inconsistent, and so the challenge is on how to manage this complexity of size. It is necessary to write a lot of lines of code to solve the problem whereas in the logic puzzle the solution is elegantly written with a few.
Software engineers have to write a description of the problem that has a similar complexity, in terms of size, than the final software artefact. The description needs to be complete, it captures all requirements, and consistent, there are no conflicting requirements, which means that it is necessary to validate the description to guarantee that it satisfies the users's needs. Therefore, the efforts necessary to create problem descriptions is similar to the one necessary to create the solutions. Additionally, it is necessary to maintain the traceability between the problem and solution descriptions to support changes in the requirements and the resulting evolution of the system.
Since software engineers have to repeat their activities in the problem and solution descriptions it raises the question why do we write a problem description? Wouldn't it be possible to focus on the writing of the solution?
There several approaches to this question.
The first approach is that it is necessary to communicate with the stakeholders and natural language needs to be used. Therefore, the next step is to write the result of this communication in a document, the user requirements definition. From this natural language description you can create a more detailed document, a system requirements specification, which can be used to communicate with the development team. This approach follows the strategy of having several small transformations between description in the software development process.
Agile approaches try to avoid the use of written documentation. Actually, it is possible to have descriptions of the problem but they serve as an auxiliary artefact for the communication, they do not substitute the communication. Therefore, it does not need to be maintained nor managed. For instance a list of stories is used as a requirement documents, but each story is only a entry point for a conversation (interaction) between the client and the development team. It is not expected that just by reading the story the team will be able to implement it. Using these approaches software engineers play with code and do not need to repeat the same activities in different artefacts, e.g. validation of the requirements and validation of the final system.
Model-driven engineering approaches intend to use executable models that are closer to the problem space and use code generation techniques to produce the final software artefact. Therefore, software engineers will interact with the client at a level of abstraction that is closer to the problem space. By following these approaches software engineers do not repeat activities because the semantics of the model and the correct implementation of the code generators ensures that the final system will have the same properties that were verified in the model. The agile modeling approach was the first intent to integrate modeling and the agile paradigm.
