Problem-Oriented Requirements in Practice: A case study

[Context and motivation] Traditional requirements describe what the system shall do. This gives suppliers little freedom to use what they have already. In contrast, problem-oriented requirements describe the customer’s demands: what he wants to use the system for and which problems he wants to remove. The supplier specifies how his system will deal with these issues. The author developed the problem-oriented approach in 2007 on request from the Danish Government, and named it SL-07. [Question/problem] SL-07 has been used in many projects – usually with success. However, we had no detailed re¬ports of the effects. [Princi¬pal ideas/results] This paper is a case study of SL-07 in acquisition of a complex case-management system. The author wrote the requirements and managed the supplier selection. Next, he was asked to run the entire acquisition project, although he was a novice project manager. Some of the results were: The problem-oriented requirements were a factor 5 shorter than traditional requirements in the same domain. Stakeholders understood them and identified missing demands. Suppliers could write excellent proposals with a modest effort. The requirements were a good basis for writing test cases and resolving conflicts during development. The delivery was 9 months late, but this was not related to the requirements. [Contribution] This is a publication of a full, real-life, complex requirements specification, the selection document, error lists, etc. The full texts are available on the author’s web-site. The paper discusses the results and illustrates them with samples from the full texts.