2014 IEEE 4th International Workshop on Requirements Patterns (RePa) 2014
DOI: 10.1109/repa.2014.6894839
|View full text |Cite
|
Sign up to set email alerts
|

A feature modeling approach for domain-specific requirement elicitation

Abstract: In this paper, we presented an approach for domain-specific requirement elicitation. Building domain-specific software requires the expertise of people with very different background and with different levels of experience in software development. This complicates the process of requirement elicitation. The purpose of the approach is twofold. On the one hand, we want to unlock available information on requirement elicitation for particular domains. On the other hand, we want to provide a mechanism for guiding … Show more

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
1
1
1

Citation Types

0
3
0

Year Published

2017
2017
2024
2024

Publication Types

Select...
4
1

Relationship

1
4

Authors

Journals

citations
Cited by 5 publications
(4 citation statements)
references
References 21 publications
0
3
0
Order By: Relevance
“…To our knowledge, there were no previous works on the use of FMs in cyber-incidents management. The works that utilise FMs tackle software engineering problems, such as software maintenance, emergence repair requests, and requirement engineering tasks [29].…”
Section: Related Workmentioning
confidence: 99%
“…To our knowledge, there were no previous works on the use of FMs in cyber-incidents management. The works that utilise FMs tackle software engineering problems, such as software maintenance, emergence repair requests, and requirement engineering tasks [29].…”
Section: Related Workmentioning
confidence: 99%
“…GuideaMaps [9], [10] is a tablet app that supports the early phase of the development process of a serious game, i.e. the requirement elicitation phase.…”
Section: Developing Effective Serious Gamesmentioning
confidence: 99%
“…Software requirements gathering and design activities usually have many members participating in discussions, exchange ideas, and contribute to the design decisions. Usually, a software development team consists of members who belong to a strong technical background and some members who have little technical background [7]. This is one of the reasons why the software team sometimes make decisions based on rationales unstated.…”
Section: Introductionmentioning
confidence: 99%