Process of developing an NLG system
The stages summarized in Stages of developing an NLG system can be done in sequence. In software engineering, this is known as the waterfall model for developing software. Arria, however, does not recommend developing NLG projects in this way.
NLG is a new technology – managers, users, and stakeholders often do not understand it well. When stakeholders have limited understanding of the capabilities of NLG, they may not be able to predict its impact on workflows. So, it can be challenging to specify accurate requirements at the beginning of a project. For this reason, Arria recommends taking an iterative, or agile, approach when developing an NLG system. Agile development means repeatedly cycling through the development stages to incrementally improve the system.
Agile development can include the following steps:
Rapid prototyping. An initial simplified version of the NLG system is developed quickly and given to users and other stakeholders. This enables everyone involved to develop a much better understanding of what NLG can do, of the data sources required, and of how the solution will impact existing workflows.
Full development. Based on the improved understanding gained from prototyping, a full system is implemented, again going through the stages of requirements analysis, design, development, testing, and support.
Refinement. The system is shown to users and perhaps deployed in a limited fashion. Feedback from users and stakeholders is used to improve it. Arria’s experience is that refinement can dramatically improve the quality and usefulness of an NLG system.
If using an agile approach, the above steps can be carried out in a structured development process that uses individual user stories that are completed during sprints. For more information on agile software development and its associated terminology, see this Wikipedia article.
Some organizations (including Arria’s internal development teams) take an agile approach; others do not. NLG systems can be developed either way. If your organization's developers are most comfortable with a non-agile approach, it may be best to stick with your existing development model.
