A Formal Knowledge Level Process Model of Requirements Engineering.

In current literature few detailed process models for Requirements Engineering are presented: usually high-level activities are distinguished, without a more precise specification of each activity. In this paper the process of Requirements Engineering has been analyzed using knowledgelevel modelling techniques, resulting in a well-specified compositional process model for the Requirements Engineering task

RGML: A Markup Language for Characterizing Requirements Generation Processes

In this paper we present the Requirements Generation Markup Language (RGML). The RGML supports the formal characterization of (a) the physical structure of a requirements generation process, (b) individual activities inherent to that process, and (c) artifacts produced and consumed during the generation process. The inclusion of templates, application instantiation, and the expression of temporally-based pre- and post-conditions increase the flexibility of RGML and its ability to capture variations in requirements generation processes. We envision the RGML as providing the specification basis for (automatically) producing interactive environments that lead (or guide) the requirements engineer through a structured set of integrated activities that foster the evolution of quality requirements

A Compositional Knowledge Level Process Model of Requirements Engineering

Contains fulltext : 62850.pdf (publisher's version ) (Closed access

Non-functional requirements for locomotives : a South African rail study

M.Ing. (Engineering Management)Abstract: A South African freight rail company aims to become one of the top 5 railway companies in the world. In the 2012/13 financial year, the company set aside over R7.5 billion for the procurement of new locomotives and rolling stock. This is the largest procurement event that the company has ever undertaken (Molefe, 2012; Crompton, et al., 2016). The requirements development process of the locomotives had to be done as detailed as possible so that they can be designed and built for purpose. Errors made in determining requirements can be costly in terms of revenue, time, system performance, reputation and even survival (Beecham, et al., 2005). When a specification for a new locomotive is being developed, the non-functional requirements are not always identified and defined. This can cause reliability issues once the locomotive is commissioned for operation. Railway companies do not use a standardized non-functional requirements classification model for the development of their locomotives. The examined literature indicated that there are numerous non-functional requirement classification models dating as far back as 1978. However, throughout the development and evolution of these classification models, none of them is a “fit all situations”. 84 unique non-functional requirements were identified in literature and these were compared to what is being specified in locomotive specifications. The findings from the literature review along with the specifications from railway companies was then collated into a format that could be used in research. The study undertook a quantitative research approach whereby the research methodology is descriptive and a questionnaire was used as the data collection tool. The questionnaire was administered to employees of a South African freight railway company in order to determine their view regarding which non-functional requirements are being considered by this organisation when it develops locomotives. The findings of the study showed that the most important non-functional requirements are reliability, maintainability, usability, stability, functionality, fault tolerance, efficiency, performance, predictability and testability. These non-functional requirements are also found in industry and also are dominant in literature. In addition, the results showed that these non-functional requirements should not be observed in isolation, other activities such as adherence to maintenance schedules, quality of..

A business analysis methodology

Synopsis Business analysis is defined as the process in which business needs are identified and solutions proposed. This process is regarded as one of the most important parts of systems development because no other part is more difficult to rectify later. However, current business analysis methodologies are inadequate because they are at a too high level and only address portions of the complete business analysis process. In particular, the lack of clear objectives, relevance and outcomes of the phases make business analysis methodologies inadequate. Moreover, activities, techniques and tools not mapped to those phases are also problematic. The aim of this research was to develop a business analysis methodology for business analysts in the South African financial services environment. The intentions were to identify the phases, as well as objectives, relevance and outcomes for each of these phases. Furthermore, this research intended to identify appropriate activities, techniques and tools to address the objectives of each phase of a methodology. This was done by presenting a literature review of previous research relating to business analysis methodologies. For information gathering, 45 participants (comprising of business analysts, project managers, IS managers and CIOs) contributed to this research, 22 of whom were interviewed individually while 23 participated in focus group interviews. The data from each of these methods was analysed independently and did not influence or feed into any of the other methods. Once the individual interviews and focus group interviews had been transcribed, content analysis and analysis within and between interviews (Merriam, 1998; Strauss, 1987) was used to analyse the information gathered independently. The phases of a business analysis methodology identified by the research are the: • feasibility phase; • business case phase; • analysis and design phase; and • post-implementation evaluation phase. Objectives, relevance and outcomes of these phases were also identified. In addition, activities, techniques and tools were mapped to each of these phases