Two new challenges for requirements engineerings

Supplier-side

The first 30 years of software systems engineering, from 1968-1998,
saw the domination of bespoke systems development. However, things
are changing. The next 30 years will see the domination of a different
systems development paradigm based on the procurement of off-theshelf software products which must be configured to meet customer
requirements.
Some people say that requirements engineering will go away. This is
clearly rubbish – customers still have requirements for these systems –
what are needed are new techniques to deliver these systems so that
the customer’s requirements are satisfied.
There are a number of other issues which are important when defining
requirements for off-the-shelf systems. One is that there is considerable
emphasis on peripheral requirements, that is those requirements which
enable the requirements engineer to distinguish between candidate offthe-shelf systems. Another issue is that it is no longer necessary every
time to define all of the system requirements in detail and with
precision. This is because most commercial systems will provide them.
However, the downside at the moment is that there is little method and
tool guidance for defining requirements for off-the-shelf systems.

This slide reviews some of the key differences from bespoke system
requirements engineering and the requirements engineering which is
done by COTS suppliers to deliver new software products to the
market.
One of the most important differences is that, often, the future
customers are not yet known or accessible. This is obviously a problem
for acquiring requirements! One of the consequences from this is that
other types of stakeholders are often driving the requirements
engineering process. These include technical developers who
understand the new opportunities afforded by new technologies, or
marketing people who can see new marketing opportunities to sell the
software product. Acquiring requirements from these new types of
stakeholders poses new challenges for frameworks such as ACRE.
On the technical side requirements have to be batched to support
meaningful product version releases. This new kind of structuring of
requirements is essential if new product versions are to be consistent,
coherent and are to conform to a wider strategy. Another interesting
factor to consider is the need to recognise and model middleware
requirements, since most ERP systems will have to communicate with
different middleware systems. Acquiring and expressing requirements
for middleware systems is an area in need of research to progress it.
Bernhard Deifel from the Technical University of Munchen has proposed a
coarse-grain method for supplier-side requirements engineering. He identifies
the different stakeholder roles that it is important to consider in the process.
Furthermore, he situates these roles in a simple framework shown in the
slide. This portfolio separates the roles into sales-oriented roles and
development-oriented roles to represent the basic split in supplier-side
requirements engineering. Of sales-oriented roles which are aimed at
maximising turnover, sales representatives sell the product to the customer to
maximise customer needs, the requirements co-ordinator co-ordinates
requirements capture from diverse sources, technical marketing takes a
higher-level view of the process and address market sector needs, and
strategic marketing addresses the long-run market success of the delivered
COTS software.
Developer-oriented roles are responsible for implementing the defined
requirements. They have to make sure that with given time, resource and
quality constraints as many demanded requirements as possible are
implemented. The resulting software also has to be flexible to cope with
changing requirements. The system strategist is the equivalent of the market
strategist and has to ensure that software can be developed quickly and
efficiently in the long run. The system module planner is responsible for
setting up version plans for system modules. The design, implementation and
integration of the system is done by software developers. Software testers
are responsible for validating the software product with respect to the defined
requirements.
Deifel also proposes an outline process model of ‘how to do it’. The
process is really an iterative one, but within each iteration the slide
shows the broad sequence of activities to follow, and the information
sources which each activity draws on.
Two iterations are proposed. In the first, called the requirements loop,
requirements are analysed and concretised and finally transformed into
an almost fixed specification. Based on this specification, the concrete
development starts. The quality loop serves for an iterative realisation of
requirements and for controlling and improving their quality. Quality
control is made by alpha-tests and beta-tests. After reaching a certain
quality degree of the software its release for manufacturing and for sale
follows.
To summarise, the need for supplier-side requirements engineering will
grow as the market place for commercial off-the-shelf software systems
grows. However, there is a dearth of methods and software tools to use
to determine the requirements for such products. Deifel’s work
represents one such method, however the method has yet to be
evaluated, so there is still a long way to go before we have understood
and managed supplier-side requirements engineering

Customer-side
The problems and lack of solutions for customer-side requirements
engineering are just as great as those for supplier-side requirements
engineering. One of the biggest problems which practitioners must
address is how to select between software products. Many of these
practitioners see this problem as an evaluation problem, and use
evaluation techniques. It is less often seen as a requirements problem.
However, it is impossible for a customer to select effectively between
two software products if the customer does not know their own
requirements for the chosen product because these requirements act
as the criteria for selection. However, if you make the leap and see
requirements as selection criteria, new opportunities for the
requirements engineer emerge. This lecture presents PORE, an early
requirements engineering method for selecting between COTS software
packages, then describes more recent work on the SCARLET process
and software prototype developed to support component-based
development in the European banking secto

Reference: Neil Maiden (2011) Requirements Engineering Lecture Notes

Advertisements
This entry was posted in Requirements for Software Packages and Web Services and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s