Daniel Kerkow

Non-functional requirements in industry - three case studies adopting an experience-based NFR method

Non-functional characteristics of products can be essential for business success and are a key differentiator between a company and its competitors. This paper presents the application of a systematic, experience-based method to elicit, document, and analyze non-functional requirements. The objective of the method is to achieve a minimal and sufficient set of measurable and traceable non-functional requirements. The method gives clear guidance for the requirements elicitation, using workshops for capturing the important quality aspects and eliciting the non-functional requirements. This paper shows its application in three different settings, reporting the experience and lessons learned from industrial case studies that applied our NFR method. As the case studies were applied in different domains and performed with companies of various maturity, and since different quality attributes were considered, a set of interesting results has emerged. Therefore, each case study tells its own story about how the elicitation of NFR in industry can work. The paper discusses the different settings and gives a comparison of the different lessons we learned from the case studies.

Exploring the characteristics of NFR methods: a dialogue about two approaches

It is not easy to choose a method for eliciting, detailing and documenting non-functional requirements (NFR) among the variety of existing methods. In order to explore typical characteristics of such methods, we compare two approaches which specify NFR: MOQARE and the IESE-NFRmethod. Both aim at deriving detailed requirements from quality attributes, but use different concepts and processes. Our analysis led to ideas for incremental improvement of each method and also to deeper insight into NFR methods.

From business processes to software services and vice versa—an improved transition through service-oriented requirements engineering

Business processes need to be agile and flexible to help organizations stay competitive. For this purpose, SOA promises the reuse of already existing information system functionality for enabling enterprises to change the business processes more quickly. However, many promises made by SOA authors have not found their way into practice, because methodological guidance that constructively assures a more successful SOA application is still missing. In this article, service‐oriented requirements engineering is therefore introduced as a discipline aiming at a better and more systematic handling and alignment of SOA and Business Process Management. Our industrial experience in this regard is also described. Copyright

Captivating patterns: a first validation

Is it possible to motivate users of an application through software elements? Is it also possible to do so for business applications? Having a long lasting, monotone, little challenging work task does not motivate users a lot in continuing a task, especially if this task comes up regularly, like typing numbers or addresses. We found software patterns - design recommendations - that keep a user working on such a task. We validated one of them in an experiment and found out that it is possible to motivate users through captivating software elements.