Requirements Engineering

Dealing with the Human Side

by Marcel Simonette

Co-authored with Edison Spinam, PUBLISHED IN THE BOOK: “Software Engineering: Methods, Modeling, and Teaching.”, ISBN: 978-958-8692-32-6. Universidade de Medellín, Medellín, Colombia. 2011. Pg 69-81,

This chapter introduces an approach for reduce the discrepancy between the expected Software System features and the... more This chapter introduces an approach for reduce the discrepancy between the expected Software System features and the ones that will be perceived by the System stakeholders. The human presence, from conception to discard of a Software System, makes the development of these Sociotechnical Systems a complex process. Although humans are the main actors of a Sociotechnical System life cycle, several Requirement Engineering methods do not include the human dimension in the System requirements, treating only the Human Factors. Given the cost involved in System changes after the Requirement Engineering process, it is necessary to include the elicitation of the human dimension in this process, which is a System inside the Software System to be developed, a System where the components are human activities

Dealing with the Human Side

by Marcel Simonette

Co-authored with Edison Spinam, PUBLISHED IN THE BOOK: “Software Engineering: Methods, Modeling, and Teaching.”, ISBN: 978-958-8692-32-6. Universidade de Medellín, Medellín, Colombia. 2011. Pg 69-81,

This chapter introduces an approach for reduce the discrepancy between the expected Software System features and the... more This chapter introduces an approach for reduce the discrepancy between the expected Software System features and the ones that will be perceived by the System stakeholders. The human presence, from conception to discard of a Software System, makes the development of these Sociotechnical Systems a complex process. Although humans are the main actors of a Sociotechnical System life cycle, several Requirement Engineering methods do not include the human dimension in the System requirements, treating only the Human Factors. Given the cost involved in System changes after the Requirement Engineering process, it is necessary to include the elicitation of the human dimension in this process, which is a System inside the Software System to be developed, a System where the components are human activities

3. Formal Verification of Requirements Engineering of Road Traffic Control System using Petri Nets

by Kamruddin Nur

Kamruddin Md. Nur , "Formal Verification of Requirements Engineering of Road Traffic Control System using Petri Nets", Bangladesh Research Publications Journal, vol. 5, issue. 4, pp.402-411, 2011, ISSN: 1998-2003

[ http://www.bdresearchpublications.com/journal/container.php?area=viewArchive&viewID=25 ]

[ [ http://www.bdresearchpublications.com/admin/journal/upload/09250/09250.pdf ]

Data modeling or functional analysis: which comes first? an experimental comparison

by Peretz Shoval

Authors: P. Shoval, J. Kabeli
Journal: Communications of the AIS (2005), Vol. 16, Article 42.

The software analysis process consists of two main activities: data modeling and functional modeling. While... more The software analysis process consists of two main activities: data modeling and functional modeling. While traditional development methodologies usually emphasize functional modeling via dataflow diagrams (DFDs), object-oriented (OO) methodologies emphasize data modeling via class diagrams. UML includes techniques for both data and functional modeling which are used in different methodologies in different ways and orders. This article is concerned with the ordering of modeling activities in the analysis stage. The main issue we address is whether it is better to create a functional model first and then a data model, or vice versa. We conduct a comparative experiment in which the two opposing orders are examined. We use the FOOM methodology as a platform for the experiment as it enables the creation of both a data model (a class diagram) and a functional model (hierarchical OO-DFDs), which are synchronized. The results of the experiment show that an analysis process that begins with data modeling provides better specifications than one that begins with functional modeling.

Uso da Gestão do Conhecimento na Engenharia de Requisitos

by Alexandre Luna

CLEYVERSON P. COSTA, ALEXANDRE J. H. DE O. LUNA, JENEFFER C. FERREIRA, CASTRO, J. F. B. (2008) Uso da Gestão do Conhecimento na Engenharia de Requisitos. In: X Encontro de Estudantes de Informática do Tocantins, 2008, Palmas. ANAIS do X Encontro de Estudantes de Informática do Tocantins, 2008.

This paper intents to describe the main concepts of the Requirements Engineering and Knowledge Management, focusing on... more This paper intents to describe the main concepts of the Requirements Engineering and Knowledge Management, focusing on techniques such as Domain Analysis, Ontology, Analysis Patterns. Will also be presented the results of study about which attention companies are paying to the Requirements Engineering and Knowledge Management areas and if both are been used together.

PROJECT ICARUS: STAKEHOLDER SCENARIOS FOR AN INTERSTELLAR EXPLORATION PROGRAM

by Andreas M. Hein

ANDREAS M. HEIN, ANDREAS C. TZIOLAS AND RICHARD OSBORNE

JBIS, Vol. 64, pp.224-233, 2011

The Project Icarus Study Group’s objective is to design a mainly fusion-propelled interstellar probe. The starting... more The Project Icarus Study Group’s objective is to design a mainly fusion-propelled interstellar probe. The starting point are the results of the Daedalus study, which was conducted by the British Interplanetary Society during the 1970’s. As the Daedalus study already indicated, interstellar probes will be the result of a large scale, decade-long development program. To sustain a program over such long periods, the commitment of key stakeholders is vital. Although previous publications identified political and societal preconditions to an interstellar exploration program, there is a lack of more specific scientific and political stakeholder scenarios. This paper develops stakeholder scenarios which allow for a more detailed sustainability assessment of future programs. For this purpose, key stakeholder groups and their needs are identified and scientific and political scenarios derived. Political scenarios are based on patterns of past space programs but unprecedented scenarios are considered as well. Although it is very difficult to sustain an interstellar exploration program, there are scenarios in which this seems to be possible, e.g. the discovery of life within the solar system and on an exoplanet, a global technology development program, and dual-use of technologies for defence and security purposes. This is a submission of the Project Icarus Study Group.

Start at the end with SMART requirements

by Wim Dijkgraaf

"available as website"

Start At The End is now focussed on Business Analysis and has it's own website at: more Start At The End is now focussed on Business Analysis and has it's own website at: http://www.wimdijkgraaf.com/business-analysts-requirements-analysis/

Have a look and feel free to comment and to participate.

Kind regards,

Wim Dijkgraaf

Registration of Business Entities: Procedures, Application Requirements

by Historically Digitized

Registration of Business Entities: Procedures, Application Requirements

Registration of Business Entities: Procedures, Application Requirements Registration of Business Entities: Procedures, Application Requirements

Data modeling and functional mdeling - examining the preferred order of using UML Class Diagrams and Use Cases

by Peretz Shoval

Authors: P. Shoval, M. Last, A. Yampolsky
In:Innovations in Information Systems Modelong - Methods and Best Practices (2009), IGI, Ch. 7, 122-142.

In the analysis phase of the information system development, the user requirements are studied, and analysis models... more In the analysis phase of the information system development, the user requirements are studied, and analysis models are created. In most UML-based methodologies, the analysis activities include mainly modeling the problem domain using a class diagram, and modeling the user/functional requirements using use cases. Different development methodologies prescribe different orders of carrying out these activities, but there is no commonly agreed order for performing them. In order to find out whether the order of analysis activities makes any difference, and which order leads to better results, a comparative controlled experiment was carried out in a laboratory environment. The subjects were asked to create two analysis models of a given system while working in two opposite orders. The main results of the experiment are that the class diagrams are of better quality when created as the first modeling task, and that analysts prefer starting the analysis by creating class diagrams first.

NL-Based Automated Software Requirements Elicitation and Specification

by Imran Sarwar Bajwa

ACM International Conference on Advances in Computing and Communications (ACC 2011) pp:30-39

This paper presents a novel approach to automate the process of software requirements elicitation and specification.... more This paper presents a novel approach to automate the process of software requirements elicitation and specification. The software requirements elicitation is perhaps the most important phase of software development as a small error at this stage can result in absurd software designs and implementations. The automation of the initial phase (such as requirement elicitation) phase can also contribute to a long standing challenge of automated software development. The presented approach is based on Semantic of Business Vocabulary and Rules (SBVR), an OMG’s recent standard. We have also developed a prototype tool SR-Elicitor (an Eclipse plugin), which can be used by software engineers to record and automatically transform the natural language software requirements to SBVR software requirements specification. The major contribution of the presented research is to demonstrate the potential of SBVR based approach, implemented in a prototype tool, proposed to improve the process of requirements elicitation and specification.

Minimizing Ambiguity in Natural Language Software Requirements Specification

by Imran Sarwar Bajwa

IEEE 6th International Conference on Digital Information Management (ICDIM 2011), Melbourne, Australia

Software requirements are typically captured in natural languages (NL) such as English and then analyzed by software... more Software requirements are typically captured in natural languages (NL) such as English and then analyzed by software engineers to generate a formal software design/model (such as UML model). However, English is syntactically ambiguous and semantically inconsistent. Hence, the English specifications of software requirements can not only result in erroneous and absurd software designs and implementations but the informal nature of English is also a main obstacle in machine processing of English specification of the software requirements. To address this key challenge, there is need to introduce a controlled NL representation for software requirements to generate accurate and consistent software models. In this paper, we report an automated approach to generate Semantic of Business Vocabulary and Rules (SBVR) standard based controlled representation of English software requirement specification. The SBVR based controlled representation can not only result in accurate and consistent software models but also machine process able because SBVR has pure mathematical foundation. We also introduce a java based implementation of the presented approach that is a proof of concept.

What Decision Characteristics Influence Decision Making in Market-Driven Large-Scale Software Product Line Development?

by Jaap Kabbedijk

Time efficiency is crucial for decision making in large scale
market driven software product line development. In... more Time efficiency is crucial for decision making in large scale
market driven software product line development. In order to identify what factors influence the decision lead time and outcome, we conducted a retrospective case study at a large product software manufacturer and statistically analyzed seven possible relationships among decision characteristics.
A large requirements engineering decision log was used to
statistically test all hypotheses. The results show that the number of products affected by a decision has a positive relationship with the time needed to take a decision. Furthermore, more products imply a longer decision lead time. Results also show that when a change request originates from an important customer, the request is sooner accepted than changes requested internally. For efficient requirements management, our findings support that decision making activities can be carefully refined in large scale requirements engineering processes. Our findings, may be useful for Product Managers to understand the consequences of making certain types of decisions and planning actions in order to avoid their negative effects.

Customer Involvement in Requirements Management: Lessons from Mass Market Software Development

by Jaap Kabbedijk

Published in the proceedings of the 17th IEEE international Requirements Engineering conference, 2009.

Product software vendors are regularly challenged with identifying and selecting the requirements of upcoming product... more Product software vendors are regularly challenged with identifying and selecting the requirements of upcoming product releases. Companies struggle to involve their customers and have a hard time selecting the right requirements from the enormous number of candidate requirements. This paper presents a practical approach to overcome these problems by including customers in the requirements management process through different types of involvement. The presented case illustrates how software requirements are gathered from customers, by involving them on three different levels. Based on the industrial experiences we present six lessons from customer involvement in large scale requirements management.

SBVR2UML: A Challenging Transformation

by Imran Sarwar Bajwa

IEEE 9th International Conference on Frontiers of Information Technology (FIT), Islamabad, Pakistan

UML is a de-facto standard used for generating the software models. UML support visualization of the software... more UML is a de-facto standard used for generating the software models. UML support visualization of the software artifacts. To generate a UML diagram, a software engineer has to collect software requirements in a natural language (such as English) or a semi-formal language (such as SBVR), manually analyze the requirements and then manually generate the class diagrams in an available CASE tool. However, by automatically transforming SBVR Software requirements to UML can seriously share burden of a system analyst and can improve the quality and robustness of software modeling phase. The paper demonstrates the challenging aspect of model transformation from SBVR to UML. The presented approach takes input the software requirements specified in SBVR syntax, parses the input specification, extracts the UML ingredients such as classes, methods, attributes, associations, etc and finally generate the visual representation of the extracted information. The presented approach is fully automated. The presented approach is explained via an example.

Improving the measurement of the understandability of requirements

by Joseph Kasser

A proposed research programme for determining a metric for a good requirement

by Joseph Kasser

The Role of Brokering Situations in Data Warehouse Development: Creating Knowledge Fit with Brokers and Boundary Objects

by Christoph Rosenkranz

Co-authored with Helena Vranesic and Roland Holten. Accepted at the 32st International Conference on Information Systems (ICIS 2011), Shanghai, China, 3-7. December 2011.

Due to their complex nature, data warehouse (DWH) development projects often fail or significantly exceed budgets.... more Due to their complex nature, data warehouse (DWH) development projects often fail or significantly exceed budgets. Prior literature has revealed that achieving common understanding in the requirements elicitation phase is a key factor for the successful knowledge transfer and overall success of information systems (IS) development. To closer observe these phenomena, we conducted in-depth interviews with participants of several DWH projects. We propose the concept of 'brokering situations' to examine social interactions between project stakeholders and we analyze multiple brokering situations in reported DWH projects. Brokering situations help to understand the time-dependent development of brokers, the boundary objects, and their relations with regard to knowledge transfer. We augment Carlile’s (2004) classification of the boundary objects according to boundary complexity and development time. We discovered that in case of a low knowledge fit between project participants, involvement of a 'knowledgeable' broker seems important.

A Method and Framework for Domain Knowledge Assisted Requirements Evolution (K-RE)

by Manas Agrawal

A Method and Framework for Domain Knowledge Assisted Requirements Evolution (K-RE)

by Nirav Ajmeri

Domain knowledge edge is crucially important in the requirements definition. Requirement analysts are not necessarily... more Domain knowledge edge is crucially important in the requirements definition. Requirement analysts are not necessarily domain experts and domain knowledge in an organization is not easily visible and accessible to them. The increasing complexity of software requirements coupled with pressures to reduce time to market have underlined the necessity for a structured mechanism to help the requirement analyst ‘jump-start ’ projects (re)using domain knowledge. Most Requirements Engineering (RE) methods treat the requirements engineering exercise as something that begins from nothing and assume a ‘clean slate ’ approach which outlines a series of steps to define, analyze, specify and validate requirements collaboratively with relevant stakeholders. We propose a method and framework to enable Knowledge assisted Requirements Evolution (K-RE). K-RE starts with a seed requirement specification. The seed contains structured domain knowledge as represented by core elements such as business events, actions and decisions (as captured in business processes), constraints, and analysis patterns derived from various resources. Each time a new software application is to be developed; we start with this seed specification and ‘evolve’ it by way of altering and/or adding to the core to get to the final requirement specification. This is done in a semantically assisted way. The semantic assistance comes from ontologies that can be created, maintained and evolved collaboratively and a context-sensitive alert mechanism that provides online alerts as a requirement analyst evolves her specification from the seed. Each new exercise of requirements definition thus, becomes an evolution of a pre-existing structured domain knowledge base tailored to suit specific projects.

Towards Knowledge Assisted Agile Requirements Evolution

by Nirav Ajmeri

This paper presents work on a recommendation system for Knowledge assisted Agile Requirements Evolution (K-gileRE). We... more This paper presents work on a recommendation system for Knowledge assisted Agile Requirements Evolution (K-gileRE). We treat requirements engineering as a special case of knowledge engineering and emphasize the fact that providing a domain knowledge edge can impart agility to the requirements definition exercise. The approach differs from existing agile methods in that it seamlessly incorporates a domain knowledge base into an agile requirements definition framework and explicitly provides to requirement analysts, relevant online domain specific recommendations based on underlying ontologies. The framework presents a 'domain knowledge seed' to requirement analysts. The seed provides a view of core features in a given domain and associated knowledge elements such as business processes, rules, policies, partial data models, use cases and test cases,. These in turn are mapped with agile requirements elements such as user stories, features, tasks, product backlog, sprints and prototype plans. The requirement analyst can evolve the seed to suit her specific project needs. As she modifies and evolves the seed specification, she receives domain-specific online recommendations to improve the correctness, consistency and completeness of her requirement specification documents and executable models. Using the domain knowledge seed as a point of departure provides a jump-start to her project. Each exercise of requirements definition thus becomes an evolution from the seed instead of the traditional 'clean slate' Requirements Engineering (RE) that typically starts from the scratch. Hence, the term K-gileRE. We elaborate how K-gileRE helps in practicing the essence of agile doctrines while defining software requirements by providing just-in-time recommendations.