Market driven requirements engineering for software products

This article is AbOUT market driven requirements engineering for software products (MDRE for SP), covering the purposes of MDRE of SP and the processes within MDRE for SP.

What is MDRE for SP?

MDRE for SP is about developing software for a mass market, i.e. packaged off-the shelf computer software that caters for a class of users rather than a particular user. Key factors within MDRE for SP are the requirements for the software product itself.

At the start of the development of packaged software the company doesn’t necessarily know who its prospective customers are. Therefore the requirements are gathered from stakeholders, developers and marketeers. Examples of packaged software include text editors, anti-virus software, development software and graphical design tools.

MDRE for SP and its history

In the decade preceding 2006 there has been a shift from custom-made software to market-driven packaged software. This is because of the fact the development of packaged software occurs one time only, with the exception of new software releases. After this process the packaged software can be sold to lots of potential customers around the whole world.

MDRE for SP Processes

Within this section the various MDRE for SP processes within the meta process model will be described in detail. The grey areas indicate the processes.

Requirement management

This section will describe the software product from a perspective where the software product already exists and a future software release is coming out.

After the first release of an actual software product there will be a need for new features. This means new requirements. The new requirements are being invented and / or gathered from stakeholders, customers, users, developers and marketers. After this the change management process will have to be defined to adjust the software product. The requirements that are gathered and / or being invented by the various parties have to be managed. This is actually the same as the requirements analysis step. There can be a collection of a large amount of requirements. This means not all of the requirements can be implemented within the actual software product. The involved people will have to vote for the requirements to implement. After the vote the chosen requirements will be further analysed. The rejected requirements will be recorded into a database, so the staff can deal with these requirements in a later stage. This will save them time within the sub-process of analyzing requirements.

Requirement management is a continuous process that has to be carried out in the whole lifecycle of the product. The main difference within the very first release and next releases to come is that the future releases always has to deal with a change management process for adjustment within the software product.

Requirement specification

The requirement specification process will describe the software product from a perspective where the software product doesn’t exist yet and has to be developed from scratch.

The first step in the process is to gather and invent requirements for the software product to develop from various persons within the organization:

Stakeholders: they invent requirements for software products based on strategical and tactical decisions for long term management. Developers: they invent requirements based on best practice and experience. They have the actual development experience. Marketers: they gather requirements by a market survey that is being done amongst potential consumers.

Every party (stakeholders, customers, developers and marketers) knows which requirements are wanted in the particular software product. The second step to take is to document the requirements. The documentation process can be done on paper, be entered in a requirements database, or be entered in a requirements prioritizing system that can handle the requirements analysis in the next process automatically.

The requirements document contains at least the following three fields:

1. Why to implement the requirement 2. Description of the requirement 3. Other comments regarding the requirement

Requirement analysis

In this stage the requirements will be analyzed further. Duplicate requirements should be discovered and the requirements should be analyzed based on ambiguity, diversity and feasibility. After this the requirements can be categorized into various groups (i.e. Example category A for feature 1, […]). After the categorization sub process the requirements are prioritized. In example the requirements that are the most important ones will be marked with high priority and requirements that do not have to be implemented right away yet, but are still on hold for an eventual second release will be marked with low priority. Stakeholders, developers and marketers are executing these decisions together. Parallel with the prioritizing sub - process is the execution of the cost estimation sub process for each requirement.

Alternatively, (see the discussion) the entire list of requirements may be used solely to determine (by asking why, repeatedly) the business purposes of each requirement. When the top ten or twelve critical goals have been identified, stakeholders and developers can specify the testing procedures to be used to determine to what level each goal has been achieved. When the purposes (goals) have been found and made measurable, then the project can proceed to navigate towards a successful conclusion which assures delivery of value to stakeholders. Competitive Engineering discusses this approach in massive detail.

Requirement validation

The requirements analysis has been done, but how to validate these requirements if there aren’t actual customers already? Requirements inspections (by auditors), beta version(s) and prototypes are a way to find out what the potential customers think of the software product. The potential customers can use these versions for free and send feedback to the software producer. This way the requirements can be validated.

Process data diagram MDRE for SP

A process data diagram is a diagram that describes processes and data that act as output of these processes. On the left side the meta-process model can be viewed and on the right side the meta concept model can be viewed.

Activity table

The left side of the process data diagram, the meta-process model contains several activities. Within the activity table there will be a detailed description of each of these process activities.

Data table

The right side of the process data diagram, the meta concept model contains data directly related to the process activities. Within the data table there will be a detailed description of the several output data.

Case study Caltroks Educational Software

Within this section an example will be given to clarify the MDRE processes within a fictitious company called Caltroks educational software.

Global information

Caltroks is a company that develops educational software regarding linguistics. It’s a company where at the moment 7 people are working. Its head office is located in the citycentre of Utrecht. Caltroks has a marketshare of 10% in educational linguistics software in the Netherlands. At the moment they are only active on the Dutch market. The 7 people are divided among the following departments:

1 Chief Executive Officer (CEO) and stakeholder, 2 Marketeers and 4 Developers.

All other activities like financial administration, incoming phonecalls etc. are being outsourced.

Caltroks has several educational products:

ABC for kids, Dutch for foreigners and English for everybody.

ABC for kids

We will focus on the ABC for kids software product to analyze how Caltroks deals with the MDRE for SP processes for this product.

ABC for kids is a software product that tells kids how to spell frequently used words. First of all the program will prenounce the word and it tells the kids how to spell the word. Then it’s the kid’s turn to spell the word, using the keyboard. If the kid has spelled the word correctly it will get a new word. The level will increase each time the kid has spelled the word correctly

Requirements management

Caltroks has already released a first version on the market, but the release was not that successful. They estimated to sell 10000 copies within one month. They only sold 5000 copies. The main reason the sale figures were this bad, is because Caltroks hasn’t invested enough in advertisement. Caltroks didn’t even came out with a beta version. This is actually their very first release! Regarding to the functionalities, the kids are complaining about the fact that they can’t adjust the level of difficulty for the words [1] . They always have to start at the lowest possible level. This is very annoying to them. Requirement [1] will get a high priority.

Several (internal) parties want to implement other new requirements too: the developers want to adjust the user interface [2]. They think it is not child friendly enough, the CEO wants to implement new words into the product [3] and the marketing department wants to relate each word with a picture [4].

Caltroks already identified the new requirements. At this moment the change management process starts and it prescribes how to deal with the new requirements, how to implement these requirements within ABC for kids and how to deal with the new deadlines to come. Within the new release to come their are several new requirements, only one with a high priority. A vote is needed to determine which requirements will. Based on the vote requirements [1] and [4] will be analyzed further. The rejected requirements ( [2] and [3]) will be recorded into a database.

Requirements validation

The last thing to do is to validate the new requirements. First of all Caltroks is consulting some external auditors to look at their MDRE for SP processes. The auditors analyze the processes consequently. They complement Caltroks. The processes are very sharp and each process is being executed in detail. Before the new release Caltroks is presenting a prototype to the stakeholders and personnel within the company. Everybody is very satisfied about how the new release is going to look like. Not even the CEO has any comments. Before the new release is being launched on the market, Caltroks brings out a beta version. The beta version is received good by the audience. There aren’t much comments, just some little things about the user interface. Based on these comments, the developers adjust the user interface as suggested by the audience. After a month the actual new release is being launched onto the market. It is a great success. Caltroks sells within one month 13700 copies! This is 2700 more than the estimated 11000 for this second release.

References

Regnell, B., Beremark, P., Eklundh, O. (1998). A Market-Driven Requirements Engineering Process - Results from an Industrial Process Improvement Programme, Journal of Requirements Engineering, Vol. 3, No. 2, 1998, 121-129

Dahlstedt, G., Karlsson, L., Persson, A., Natt och Dag, J., Regnell, B. (2003). Market-Driven Requirements Engineering Processes for Software Products - a Report on Current Practices. Retrieved 6 February, 2006 from the Department of Computer Science University of Skövde & Department of Communication Systems Lund University. Web site: http://www-lsi.upc.es/events/recots/papers/Dahlstedt.pdf

Karlsson, L., Dahlstedt, G., Natt och Dag, Regnell, B., J., Persson, A. (2002). Challenges in Market-Driven Requirements Engineering - an Industrial Interview Study. Essen Germany: Proceedings of Eighth International Workshop on Requirements Engineering: Foundation for Software Quality.

Höst, M., Regnell, B., Natt och Dag, J., Nedstam, J., Nyberg, C. Exploring Bottlenecks in Marketdriven Requirements Management Processes with Discrete Event Simulation, The Journal of Systems and Software, Vol. 59, pp 323-332, 2001.

Yeh, A. (1992) Requirements Engineering Support Technique (REQUEST) – A Market Driven Requirements Management Process. Proc. of Second Symposium of Quality Software Development Tools, New Orleans, USA.

Sawyer, P., Sommerville, I., Kotonya, G., Improving Market- Driven RE Processes. Proceedings of International Conference on Product Focused Software Process Improvement (PROFES’99), Oulu Finland, June 1999.