Requirements Elicitation from BPMN Models

Tarkvarasüsteemi loomiseks on väga oluline mõista, millised on tegelikud vajadused ja nende rahuldamist takistavad piirangud. Nõuete tuvastamise käigus õpitakse tundma ümbritsevat keskkonda ja tehakse kindlaks kasutajate ning teiste osapoolte vajadused. Üheks peamiseks kohaks, kust nõudeid leida, on hetkel kasutatavad süsteemid (protsessid, organisatsioon, keskkond ja kasutatavad infosüsteemid). Kasutusel olevaid protsesse kujutatakse tihti graafiliselt mudelitena ja need mudelid kujutavad endast väga olulist informatsiooniallikat nõuete tuvastamisel. BPMN mudelid on saanud väga populaarseks ja neid kasutatakse tihti süsteemide kirjeldamiseks, kuid vaatamata sellele, et nad on väärtuslikud teadmiste allikad, kasutatakse neid nõuete tuvastamisel siiski harva. Üheks selliseks põhjuseks on asjaolu, et puuduvad konkreetsed ja põhjalikud juhised, mis aitavad süstemaatiliselt mudelist nõudeid tuvastada. Selles töös esitletakse meetodit funktsionaalsete nõuete tuvastamiseks BPMN mudelitest. Meetod läbib süsteemselt kõiki nõude komponente ja annab juhised, kuidas BPMN mudelist komponendi kohta informatsiooni leida ning annab lisaks kogumi küsimusi, mida valdkonna spetsialistidele esitada, et nõue oleks põhjalik, järjepidev, piiritletud ja nõutava detailsusega. Loodud meetodit rakendati ka juhtumiuuringu käigus ja tõestati, et uus meetod on rakendatav ning on struktureeritud lähenemine nõuete tuvastamiseks. Meetod tuvastas rohkem nõudeid kui meetod, mis oli algselt kasutusel juhtumi organisatsiooni poolt ja tuvastatud nõuded olid ka parema kvaliteediga. Meetodi rakendamine võttis märkimisväärselt vähem aega, tuvastamise protsess oli hästi kontrollitav, see võimaldas täpsemalt hinnata tuvastamisele kuluvat aega ja seeläbi on meetodit kasutades lihtsam protsessi planeerida ja ülesandeid delegeerida.When building a software system, it is crucial to understand the actual needs and the interfering constraints that apply in the surrounding environment. Elicitation of requirements is all about learning the environment and discovering the needs of users and other stakeholders. One of the primary sources for requirement elicitation is the system (processes, organization, environment and legacy systems) currently being used. The system is often captured in the form of graphical models, which are an important source of information for requirements elicitation. BPMN models are gaining popularity and are frequently used to model systems. Despite the fact that they are a valuable source of knowledge, they are rarely used as a source for eliciting requirements. One reason for this is the lack of concrete and comprehensive guidelines that would assist a systematic requirements elicitation from such models. This thesis presents a method for eliciting functional requirements from BPMN models. The method covers all components of a requirement and gives guidelines where in the BPMN model the information about the components can be found. It also provides a set of questions to be asked from domain experts to make sure that the requirement specification is complete, consistent, bounded and on the required level of granularity. The method was applied on a case study and it was proved that the method is applicable and provides a structured approach to eliciting requirements. The method elicited more requirements than the method previously used by the case organization, and the elicited requirements were also of better quality. The method took considerably less time to apply, it gave better control over the elicitation process, it was easier to evaluate the needed effort, and it enabled to better plan the process. The structured approach makes it easier to delegate work, and there are less situations where something might be overlooked

Contribution to Software Development Method based on Generalized Requirement Approach

Requirements’ gathering is one of the first steps in the software development process. Gathering business requirements, when the final product requirements are dictated by a known client, can be a difficult process. Even if the client knows their own business best, often their idea about a new business product is obscure, and described by general terms that contribute very much to common misunderstandings among the participants. Business requirement verification when the requirements are gathered using text and graphics can be a slow, error-prone, and expensive process. Misunderstandings and omitted requirements cause the need for revisions and increase project costs and delays. This research work proposes a new approach to the business software development process and is focused on the client’s understanding of how the business software development process works as well as a demonstration of the business requirement practices during requirement negotiation process. While the current software development process validates the business requirement at the end of the development process, this method implementation enables business requirement validation during the requirement negotiation phase. The process of the business requirement negotiation is guided by a set of predefined questions. These questions are guidelines for specifying a sufficient level of requirement details for generating executable code that is able to demonstrate each requirement. Effective implementation of the proposed method requires employment of the GRA Framework. Besides providing guidelines for requirement specification, the Framework shall create executable and provide the test environment for a requirement demonstration. This dissertation implements an example framework that is built around a central repository. Stored within the repository is the data collected during the requirement negotiations process. Access to the repository is managed by a Web interface that enables a collaborative and paperless environment. The result is that the data is stored in one place and updates are reflected to the stakeholders immediately. The executable code is generated by the Generator, a module that provides general programming units that are able to create source code files, databases, SQL statements, classes and methods, navigation menus, and demo applications, all from the data stored in the data repository. The generated software can then be used for the business requirement demonstration. This method assumes that any further development process is built around the requirements repository, which can provide continuous tracking of implementation changes. Besides readily documenting, tracking, and validating the requirements, this method addresses multiple requirement management syndromes such as the insufficient requirements description details provision, the IKIWISI (“I’ll know it when I see it”) Syndrome, the Yes, But Syndrome (“That is not exactly what I mean”), and the Undiscovered Ruins Syndrome (“Now that I see it, I have another requirement to add”).

Software Engineering: Factors Affect on Requirement Prioritization

Software engineering research is yet in its early stages hence it needs evaluation. So, software engineers think about experimental research and try to adopt analytical approaches to validate results like in other sciences. It should be asserting that requirement engineering process is to use requirements prioritization. The use of requirements prioritization helps the anatomy of requirements and isolates the most important requirements. A lot of prioritization techniques, practices and methodologies are used in software requirements. But lack of empirical search program and proficient methodology, was not decide which should be implemented. In this research, the requirement prioritization for systematical reviews was carried out. Based on systematic review, a framework is introduced for further research within requirement prioritization. This paper described a framework for scrutinize the discussion that take place during requirements elicitation and requirements prioritization. The survey presented in the paper gives a practical view how to prioritize the requirements. It also reflects the requirements prioritization in the industries needs. Which factors of the requirements engineering affect the requirements prioritization

Evaluation of a specification approach for vehicle functions using activity diagrams in requirements documents

Rising complexity of systems has long been a major challenge in requirements engineering. This manifests in more extensive and harder to understand requirements documents. At the Daimler AG, an approach is applied that combines the use of activity diagrams with natural language specifications to specify vehicle functions. The approach starts with an activity diagram that is created to get an early overview. The contained information is then transferred to a textual requirements document, where details are added and the behavior is refined. While the approach aims at reducing efforts needed to understand a function’s behavior, the application of the approach itself causes new challenges on its own. By examining existing specifications at Daimler, we identified nine categories of inconsistencies and deviations between activity diagrams and their textual representations. This paper extends a previous case study on the subject by presenting additional data we acquired. Our analysis indicates that a coexistence of textual and graphical representations of models without proper tool support results in inconsistencies and deviations

Challenges and Practices in Aligning Requirements with Verification and Validation: A Case Study of Six Companies

Weak alignment of requirements engineering (RE) with verification and validation (VV) may lead to problems in delivering the required products in time with the right quality. For example, weak communication of requirements changes to testers may result in lack of verification of new requirements and incorrect verification of old invalid requirements, leading to software quality problems, wasted effort and delays. However, despite the serious implications of weak alignment research and practice both tend to focus on one or the other of RE or VV rather than on the alignment of the two. We have performed a multi-unit case study to gain insight into issues around aligning RE and VV by interviewing 30 practitioners from 6 software developing companies, involving 10 researchers in a flexible research process for case studies. The results describe current industry challenges and practices in aligning RE with VV, ranging from quality of the individual RE and VV activities, through tracing and tools, to change control and sharing a common understanding at strategy, goal and design level. The study identified that human aspects are central, i.e. cooperation and communication, and that requirements engineering practices are a critical basis for alignment. Further, the size of an organisation and its motivation for applying alignment practices, e.g. external enforcement of traceability, are variation factors that play a key role in achieving alignment. Our results provide a strategic roadmap for practitioners improvement work to address alignment challenges. Furthermore, the study provides a foundation for continued research to improve the alignment of RE with VV

Information extraction from high-level activity diagrams to support development tasks

As the complexity of systems continues to increase, the use of model-driven development approaches becomes more widely applied. One of our industry partners (Daimler AG) uses UML activity diagrams as the first step in the development of vehicle functions, mainly for the purpose of communication and overview. However, the contained information is also valuable for further development tasks. In this paper, we present an automated approach to extract information from these high-level activities. We put a focus on aspects of activities such as propositional logic relations, sequences of actions, and differentiability of execution paths. The extracted parts are needed for the compilation of requirements and the creation of test cases. Also, this approach supports stakeholders unfamiliar with the notations of activities as implicit information is made explicit and hence more accessible. For this purpose, we provide a formalism for the kind of activities our industry partner uses. Based on that formalism, we define properties that express the contained sequences and execution paths. Furthermore, the formalism is used to derive the underlying propositional logic relations. We show how the approach is applied to eliminate hundreds of existing quality issues in an existing requirements document

Coexisting graphical and structured textual representations of requirements : insights and suggestions

[Context & motivation] Many requirements documents contain graphical and textual representations of requirements side-byside. These representations may be complementary but oftentimes they are strongly related or even express the same content. [Question/problem] Since both representation may be used on their own, we want to nd out why and how a combination of them is used in practice. In consequence, we want to know what advantages such an approach provides and whether challenges arise from the coexistence. [Principal ideas/results] To get more insights into how graphical and textual representations are used in requirements documents, we conducted eight interviews with stakeholders at Daimler. These stakeholders work on a system that is speci ed by tabular textual descriptions and UML activity diagrams. The results indicate that the di erent representations are associated with di erent activities. [Contribution] Our study provides insights into a possible implementation of a speci cation approach using mixed representations of requirements. We use these insights to make suggestions on how to apply the approach in a way that pro ts from its advantages and mitigates potential weaknesses. While we draw our conclusions from a single use case, some aspects might be applicable in general

Removal of redundant elements within UML activity diagrams

As the complexity of systems continues to rise, the use of model-driven development approaches becomes more widely applied. Still, many created models are mainly used for documentation. As such, they are not designed to be used in following stages of development, but merely as a means of improved overview and communication. In an effort to use existing UML2 activity diagrams of an industry partner (Daimler AG) as a source for automatic generation of software artifacts, we discovered, that the diagrams often contain multiple instances of the same element. These redundant instances might improve the readability of a diagram. However, they complicate further approaches such as automated model analysis or traceability to other artifacts because mostly redundant instances must be handled as one distinctive element. In this paper, we present an approach to automatically remove redundant ExecutableNodes within activity diagrams as they are used by our industry partner. The removal is implemented by merging the redundant instances to a single element and adding additional elements to maintain the original behavior of the activity. We use reachability graphs to argue that our approach preserves the behavior of the activity. Additionally, we applied the approach to a real system described by 36 activity diagrams. As a result 25 redundant instances were removed from 15 affected diagrams

A case study on a specification approach using activity diagrams in requirements documents

Rising complexity of systems has long been a major challenge in requirements engineering. This manifests in more extensive and harder to understand requirements documents. At the Daimler AG, an approach is applied that combines the use of activity diagrams with natural language specifications to specify system functions. The approach starts with an activity diagram that is created to get an early overview. The contained information is then transferred to a textual requirements document, where details are added and the behavior is refined. While the approach aims to reduce efforts needed to understand a system’s behavior, the application of the approach itself causes new challenges on its own. By examining existing specifications at Daimler, we identified nine categories of inconsistencies and deviations between activity diagrams and their textual representations. In a case study, we examined one system in detail to assess how often these occur. In a follow-up survey, we presented instances of the categories to different stakeholders of the system and let them asses the categories regarding their severity. Our analysis indicates that a coexistence of textual and graphical representations of models without proper tool support results in inconsistencies and deviations that may cause severe maintenance costs or even provoke faults in subsequent development steps