Using parameters and discriminants for product line requirements

Mannion, Mike; Kaindl, Hermann

doi:10.1002/sys.20086

Cited by 26 publications

(13 citation statements)

References 25 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Based upon the notion of variability proposed in domain engineering. Whilst common requirements are necessary in any system of the domain, other requirements can be chosen or not for a specific system [8]. In some of these proposals, rules are provided to establish dependencies among variable parts of the requirements specifications.…”

Section: Patterns In Requirements Engineeringmentioning

confidence: 99%

Constructing and Using Software Requirement Patterns

Franch

Quer

Renault³

et al. 2013

Managing Requirements Knowledge

View full text Add to dashboard Cite

Software requirement reuse strategies are necessary to capitalize and reuse knowledge in the requirements engineering phase. The PABRE framework is designed to support requirement reuse through the use of software requirement patterns. It consists of a meta-model that describes the main concepts around the notion of pattern; a method to conduct the elicitation and documentation processes; a catalogue of patterns; and a tool that supports the catalogue's management and use. In this chapter all these elements are presented in detail making emphasis on the construction, use and evolution of software requirement patterns. Furthermore, the chapter includes the construction of a catalogue of non-technical software requirement patterns for illustration purposes. catalogue of patterns for non-technical requirements. Finally, Section 5.7 presents some conclusions and future work. ContextThe work presented in this paper stems from the needs of the Public Research Centre Henri Tudor (TUDOR) at Luxembourg when conducting IT procurement projects over time. Since 2004, TUDOR works in collaboration with freelance and independent consultants. These consultants are federated in a business network that we refer as CASSIS. They are trained to innovative methods produced by research projects and they use these methods in industrial contexts. TUDOR monitors their activity to ensure that they do not deviate over the time. One of the main methodologies delivered to consultants is a requirement engineering method used to design Software Requirements Specification documents (SRS) for IT procurement projects in small and medium size companies [3].Consultants work in collaboration with customers to help them in identifying their needs for a new IT system supporting their business activities, and then selecting the most relevant system accordingly to their needs. In this particular context, requirements engineers' consultants define SRS for external customers and not for their internal purpose. Consultants' customers are usually looking both for an IT system and for its implementation. In other words, they have requirements towards an IT system and towards additional services. For this reason, the scope of the SRS often encompasses functional, non-functional and non-technical requirements.The initial goal of the SRS is to serve as a basis for a competitive procurement process. So their primary use is for IT sales managers to understand the needs of the customer and to propose a commercial bid. Only when this process is achieved, the SRS is used in second intend as source for the design or the customization of the selected IT system. So far, consultants and TUDOR have performed more than 40 projects in compliance with the methodology. The initial approach for capitalising requirements knowledge among the consultants was quite basic. It consisted in re-using fragments of a former SRS as a basis to build the new SRS. This approach was simple to use but required to be aware of the former projects, which was not easy for the consultants due to t...

show abstract

Section: Patterns In Requirements Engineeringmentioning

confidence: 99%

Constructing and Using Software Requirement Patterns

Franch

Quer

Renault³

et al. 2013

Managing Requirements Knowledge

View full text Add to dashboard Cite

show abstract

“…FODA is commonly used as feature model by researcher, however in this research, feature metamodel MRAM/TRAM is used as it has already proposed an extension of SysML profile (Mannion and Kaindl 2008). The metamodel contains discriminants which are features that differentiate one system from another.…”

Section: A Functional Mappingmentioning

confidence: 99%

An Approach for Representing Domain Requirements and Domain Architecture in Software Product Line

Halim¹,

Jawawi²,

Ibrahim³

et al. 2012

Software Product Line - Advanced Topic

View full text Add to dashboard Cite

“…A formal basis for the creation of an automated reasoning system is also supported for creative engineering design by Sushkov et al, 1995. Mannion andKaindle, 2008 developed a formal logic-based approach to deal with the VOC in term of product requirement. Sivaloganathan et al, 2000 carried out a study for the effectiveness of systematic and conventional approaches to design.…”

Section: Literature Reviewmentioning

confidence: 99%

A Numerical Kano Model for Compliance Customer Needs with Product Development

Rashid¹,

Tamaki²,

Ullah³

et al. 2011

Industrial Engineering and Management Systems

View full text Add to dashboard Cite

Abstract. Functional form and dysfunctional form of Kano model are considered as customer need regarding attribute of product. Both functional and dysfunctional forms are: Like, Must-be Neutral, Live-with and Dislike. The answers of customer regarding a product of functional and dysfunctional forms have been applied for selection of customer needs regarding product attribute (Kano evaluation). Filling-up and returning the Questionnaires by the individuals are essential for determining Kano evaluation. But many Questionnaires have not been returned in that case. Moreover, many possible consumers could not get opportunity to fill-up questionnaire. These uncertain or unknown consumers' opinions are also essential for product development. The choices of Kano evaluations have been outlined by: Attractive, One-dimensional, Must-be, Indifferent and Reverse. In this study, choices of evaluation of unknown customer are considered uniform cumulative vector probability (scenario 1). This study is based on the Monte Carlo simulation method, concept of probability and Kano model. This model has also been tested for its soundness and found fairly consistent including existing Kano model (scenario 2) and case survey for headlight of bicycle (scenario 3).

show abstract

Using parameters and discriminants for product line requirements

Cited by 26 publications

References 25 publications

Constructing and Using Software Requirement Patterns

Constructing and Using Software Requirement Patterns

An Approach for Representing Domain Requirements and Domain Architecture in Software Product Line

A Numerical Kano Model for Compliance Customer Needs with Product Development

Contact Info

Product

Resources

About