Survey on Requirements Reuse and Patterns

If you are working as Requirements Analyst in some organization or you are a researcher or teacher of this subject in university, you can help us in our research answering our survey on Requirements Reuse and Patterns. It it open from April 1th.

Goals of the Survey

• To know current requirements engineering practices related with essential aspects for the definition of requirement patterns.
• To analyze the current and potential use of patterns in industry.

Target Audience
Any practitioner and academic with different levels of experience on requirement engineering.

• Requirements engineer working in  Industry
• Academic with significant experience in Industry 
• Academic with some knowledge of Industry practices  
• Academic without any exposure to Industry  

Access to the Survey

Requirements Reuse and Patterns Online Survey (closed)

Flow of the Survey

 

Software Requirement Patterns

There are many approaches to reuse in software engineering. Among them, patterns hold a prominent position. "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice" (Alexander, 1979).
We are interested in the use of patterns for the requirements analysis stage, namely Software Requirement Patterns. The patterns applicability to this context is clear, since requirements that appear over and over in requirements books could be identified as the solution to particular problems in a given context (the classical context-problem-solution scenario of patterns).
In the PABRE framework we have currently defined a software requirements pattern catalogue with 66 patterns: 29 to be applied as non-functional requirements and 38 as non-technical ones. The catalogue is currently evolving to add functional patterns of certain software domains and also more specific patterns on information security.
The patters are available under a creative commons license schema (CC 3.0 BY-NC-ND) that restrict some usages.. For other specific agreements do not hesitate to contact us. Also relevant information can be found in the post Interested in Improving your Requirements Engineering Process: Try Requirement Patterns!.

Interested in Improving your Requirements Engineering Process? Try Requirement Patterns!

As explained in previous posts, the we are interested in the validation of our PABRE approach and the tools that support it.

What do we want from industry? We distinguish three different collaboration scenarios, depending on the desired interaction among all the parties and the exploitation of the offered assets:

• Free experimentation. For organizations interested on exploring our framework. We would provide demo versions of the catalogue and the tool, the method and off-line training support. The organization will be allowed to use these assets for an established period of time. At the end, the organization will fill a feedback form (short questionnaire) and present in a 2-hour wrap-up meeting.  
• Guided experimentation. For organizations interested on using our framework in a specific project without any modification. We would provide the catalogue, the tool and the method and a 4-hour training to the project team. The organizations will be allowed to use the assets for an established project, and during it we will provide support under request and agreed terms. At the end of the project there will be an assessment meeting and an assessment report of the experience will be written by the organization. Also the requirement book resulting from the project will be made available to us.
• Assets customization. For organizations that want to customize our assets for their specific context. The scope both in domain and time will be negotiable. The assets to customize may be: 
• The catalogue, both by: a) including new patterns or modifying the existing ones, b) changing the shape that a pattern may take (e.g., to link requirement patterns to test suites or test strategies), 
• The tool, adding or modifying existing functionalities or import/export capabilities (e.g., to export the requirements to some requirement management tool), 
• The method, by thinking on a specific context of use. 

In all of these situations, an individual study will be made to determine the details of the collaboration (e.g., schedule, charging schema, etc.), and the collaboration would be formalized with a signed agreement.

PABRE-Proj use during Requirements Elicitation

Here we include a video presenting the process of use of PABRE-Proj tool during a Requirements Elicitation meeting. This process has been simplified in some aspects in order to facilitate the comprehension of the tool use.
PABRE-Proj may be used through a browser or using a client program.  It is part of the PABRE System.

PABRE System How to Contribute

The PABRE software system is a support for the PABRE framework. It is composed by two tools: PABRE-MAN and PABRE-PROJ.

PABRE-MAN is a tool that can be used by the requirement manager of the catalogue to maintain and evolve the software requirement patterns (SRP) catalogue. Its main functionalities are: patterns management, browsing, importation/exportation, printing and catalogue evolution.

PABRE-PROJ is a tool that can be used by requirements analysts during the elicitation of requirements in a software development project, use of external software components, or acquisition of software systems. Its main functionalities are: project management, browsing, importation/exportation, requirements management document generation, or call for tenders document generation and patterns use statistics exportation. Currently, there is also a web version of this tool, in a way that requirements analysts can access and edit software requirements projects from everywhere.

The following slides were used during the last GESSI Pizza Day. They describe the projects open to students that are interested to contribute to the PABRE development.

Requirements Elicitation using Software Requirement Patterns

Requirements elicitation is the process of acquiring system requirements from system stakeholders. The quality of this process is critical to make information technology (IT) projects a success.

When a company runs many elicitation processes over time, it is often the case that a significant proportion of requirements is recurrent and belongs to a relatively small number of categories, especially in the case of Non-Functional and Non-Technical requirements. Capitalizing on knowledge acquired in previous projects seems in this way an adequate strategy to improve the quality of requirements, and then increase the changes of project success; as well as to increase the efficiency of the requirements elicitation process. Our PABRE framework proposes an application of the concept of software requirement pattern as a means to capture and capitalize requirements knowledge in the context of IT systems and services procurement projects.

Currently our framework includes:

·  A metamodel that describes the structure of patterns and the catalogue.

·  A method for the process of use of the catalogue in the requirements engineering stage.

·  Two tools (see below) helping in the use, management and evolution of the catalogue.

·  A software requirement patterns (SRP) catalogue with 29 Non-Functional SRP and 37 Non-Technical SRP. These two catalogues are generic and apply to every kind of software domain (although of course every domain may have in addition some particular NF-reqs and NT-reqs). We are also interested in the construction of Functional SRP for several domains as for instance: Content Management Systems (CMS) or Cloud Computing and specifically in Software as a Service (SaaS).

We have defined several collaboration scenarios, but we are open to other collaboration ideas. If you are interested just contact us.   

 

Try Requirements Patterns!
Software Requirement Patterns
Requirements Patterns Tools Support
PABRE System: How to contribute?

DesCOTS: A System for Selecting COTS Components

DesCOTS is a system that has an aim to help clients in the selection of COTS components. This system is based in the use of quality models associated to a software domain for evaluating the products in that domain, and for defining in a formal way the requirements of the clients for finding a suitable product in that domain. The evaluation and the formal definition of requirements are facilitated by metrics of each quality entity in the quality models. Our ISO/IEC 9126-1 based quality models are a set of quality entities structured in hierarchies of characteristics, subcharacteristics and attributes; with possible intermediate hierarchies of sub-characteristics and attributes.

DesCOTS is constituted by 4 subsystems. Two of them were presented in past RE conferences: QM, which supports the construction of quality models and EV, which supports the evaluation of products. In this conference we present SL that supports the definition of requirements and the selection of products. Finally, the system administration and the taxonomy construction and management is provided by the subsystem AD.

If you are interested in the  DesCOTS-QM and DesCOTS-EV. you can ask for the trial versions sending us a mail message with your name, organization, e-mail address and postal address. In QM you can search a domain in our hierarchy of software domains, and browse the existent and validated quality models (i.e. Web Content Management, Versioning and Concurrent Control or Mail Server). In EV you can create the product evaluation corresponding to the domains of Web Content Management or Reference Management Tools. The manuals for using the tools can be found in manual DesCOTS-QM and manual DesCOTS-EV.

Non-technical criteria added in the Extended ISO 9126-1 quality model

Non-technical criteria such as administrative, economical or political are often significant in software selection, sometimes even more important than technical ones.
However, these criteria have not been included in most quality models proposals. Specifically, this occurs in the case of the ISO/IEC 9126-1 standard.
We proposed some time ago a hierarchy of 141 sub-characteristics and attributes that constitute an extension of this standard. These sub-characteristics and attributes decompose 3 high-level characteristics (supplier, business, and product), each one with its corresponding metrics.
Now this quality model extension can be consulted interactively by means of QMS tool. Here you have a capture of how this quality model is consulted through QMS.

Use of quality models in the selection of software products

The growing importance of commercial off-the-shelf software products requires adapting some software engineering practices, such as requirements elicitation, to this emergent framework. Also, some specific new activities arise, among which selection of software packages plays a prominent role. There are different types of requirements, such as managerial, political, and, of course, quality requirements. Quality requirements are often difficult to check. This is partly due to their nature, but there is another reason that can be mitigated, namely the lack of structured and widespread descriptions of product domains (that is, categories of software products such as ERP systems, graphical or data structure libraries, and so on). This absence hampers the accurate description of software products and the precise statement of quality requirements, and consequently overall product selection and confidence in the result of the process. Our methodology for building structured quality models helps solve this drawback. Slides here.

 

A new tool for look up quality models

Using the Quality Models Browser it is possible to navigate through our taxonomy of software domains. Browsing this taxonomy you may find the domains for which we have a defined quality model. Once selected the domain in the taxonomy, it is possible to look up the quality attributes of the quality model, their definition, their metrics (assignations), the relationships with other quality attributes, and if they participate in the definition of some requirement pattern.