The marketing driven requirement engineering

Published:

1. Gap between the Marketing Departments and Development Team

Introduction

The Marketing Driven Requirement Engineering has been facing one of the problem is Gap between the Product Management and Product Development because of communication and coordination problems between these two teams [1] and multi-site development [2] and also difference in knowledge and skills of both teams. The product development organizations to separate the roles like as sales department, marketing department, development department. In this each department have special skills and sometimes to reduce the development cost and early to release the product the development organization globally work and teams will be separated while to provide effective communication and coordination between the teams is very difficult to the product development organization.

According to [3] this gap between the departments is a big problem and a challenge in market driven. In [3] a small survey is conducted in a company with two persons in the same company. The survey is reported that the view and ideas of both the departments in the company are different for example from the product management department says that the requirements from different customers are easily understood and it is not difficult to understand. But the development department says that the development team regards as a big challenge. Generally there is no cooperation between the two departments which will lead to the damage of the company's goals.

Lady using a tablet
Lady using a tablet

Professional

Essay Writers

Lady Using Tablet

Get your grade
or your money back

using our Essay Writing Service!

Essay Writing Service

For example we take the view on what is good requirement. According to the product management department perspective the good requirement which will give benefit and money to the company but according to the developer's perspective the good requirement is that which is written correctly and easily understood and easy to be implemented [3].

And take an another example given in [3] that writing a requirement in the perspective of the marketing department is that writing down the requirements for the next release but in the developers point of view the requirements should be written down clearly enough to start the code. But here also we can see the difference.

And also from my practical experience of Global Software engineering practical exercise; practical exercise have requirement team and development team. In this two team's keep in two separate rooms and the management give a task to requirements team those teams communicate to development team through the video chat and voice chat. Requirement team propose requirements to development team but the development team did not understanding their requirements because of lack structrednees and ambiguous in requirements. They give requirements to development team their own language and their perspectives.

Common Representation and understanding of requirements:

Generally we have seen in the organizations are separated to departments, each departments have its own responsibility to achieve that responsibility they are using different tools, techniques and also different goals in mind. In [2], as the survey is conducted it came into light that the views of the developers and market department persons are different from each other. Marketing departments collect product requirements, the CEO reads the requirements, CEO tasks a product manager to build a product, product manager informs the analysts of what the product should do, Analysts inform the designers of how the product will work Designers inform coders of what the product will do Coders agree with testers how the product should behave. In this case many"errors" have been introduced in the message through this chain, at least 264 (or 18 446 744 073 709 551 616 for those that don't think in binary). [] In this way they can lose the common goal of the organization because of misunderstanding of teams work while lack of communication co-ordination between teams and myths of teams. And also there is lack of formal proof in practical sense. The product development department requirements can requirements to be fully documented, and reviewed so that the development team knows what needs to be done.

Multi-site development:

Communication and Coordination

In [2] the trend toward leaner, flatter organizations enhances the need for communication and cooperation between the product management team and the development team functions. Product management team specialists are hired to sell the product, talk to customers, and communicate product benefits. Over time these groups grow apart, each expert at their own function, but less aware of the other's contribution. Developers also knowledge only in functionality and development language because of them will also face the same problem when schedule comes into action. In a market driven development, most of the requirements come from marketing department by doing huge market analysis. Marketing people demand the development team that all the requirements that are mentioned by marketing team should be included in the product and tells them that if we don't include these requirements we cannot produce a good product. On the other hand the development people after seeing the set of requirements from the marketing department they mention that we cannot give the requirements in reasonable time. When there is no proper agreement between these requirements what marketing department mentions and what the development people need will make the product delivery very late. There will be a lot of misunderstandings between the development people and the marketing people, both of them do not agree on a set of requirements.

Solution for these problems:

Lady using a tablet
Lady using a tablet

Comprehensive

Writing Services

Lady Using Tablet

Plagiarism-free
Always on Time

Marked to Standard

Order Now

We are proposing a solution according to the solution given in [3], that as there is a gap between the two departments regarding the view on requirements a better and good collaboration and coordination is important which will increase the quality of the requirement and also the quality of the product. For better communication now a day's many companies are using a common means of understandable language UML. This is a best language tool which is used to represent everything into pictorial representation. When this UML notation is used then everybody the company can understand what exactly we need and what exactly we do not need [5]. And also we supported that a good co-ordination and understanding nature between the departments will help to resolve the gap between the departments. This understanding nature and co-ordination should be given by the organization. Hence, organizational support also plays a major role to fill this gap.

Analysis and conclusion

After doing a good literature study and understanding on the current knowledge of the market driven requirement engineering, we supported one of big challenge is the gap between product management and product development. We have seen most of the failure projects cause of the lack of communication and coordination and lack of common goal between two teams. The product management team and the development team communication gap come from they have think different perspectives with different goals mind we have seen from survey [3] the both departments does not cooperate each other because there is no good communication tools and sometimes both departments geographically separated. The development organizations want to success the product development that can provide good communication and cooperation between the management department and development department. So by reading the literature we come to know that UML base communication and goal-oriented requirement communication [4] is effective as it is pictorial representation. So by improving the communication, coordination and collaboration we can reduce the gap between the two departments and overcome this challenge.

2. Lack of elaborate and evolved process and simple tools for basic needs

Introduction

The organizations developing the software in market driven perspective still the organization have been facing many unique problems that are struggle in establishing process that lead to proper requirements handling, obtain an assessment of RE practices and quick made assessment that lead to deviation of product. The market driven requirement engineering does not have specific process development tool, quality standard tools these tools are very help full to develop the small and medium size organizations. A MDRE process or method that is developed in the academia needs to satisfy the resources in the industry. Sometimes a too elementary process may be insufficient to a large organization, in other case a too elaborate process may sometimes lead to ambiguity in the software development process. Also, in a market driven requirement engineering, due to its dynamic nature it needs to establish proper tools, which helps in a requirement development process. There is a need to establish a simple good software tool and a process model that supports the development of a software process [20]. That standard tools and process models to helpful basic needs of customers and also provide good communication between the customers, product management, and development departments. Example from the survey [3] all the interviewed companies are using natural language to define the requirements, manage the requirements they did not follow the certain standards while to understand the requirements and write completely is very difficult task because of they did not use the basic process model and basic tools.

Context of tools in MDRE

In the organization include different departments they have different views while using specific tools is big challenge in survey [5] some of the major challenges that were proposed by many software organizations. From the survey they described most of the companies used the RUP for define the requirements. Initially the requirement engineers and the developers satisfied but after processing they faced some problems. The cause of the problem is RUP is use case driven approach but the company wants work in future driver-manner for using this tool face workload problem and time consuming, Some of them include, lack of support for better coordination and flow of information between the requirement engineers and development engineers. Some staff also not satisfied with RUP, as they wanted to work in a feature oriented approach. In some companies, the people in the organization find RUP as were complex and time consuming. Sometimes integrating the tools was also a problem. So to understanding the requirements and completeness to user requirements and to avoid gap between the requirement engineers and development engineers the development organization feel to there is a need to establish a simple good software tool and a process model that supports the development of a software process. If the Organization is managerial based, they prefer more sophisticated tools that tries to provide early customer feedback, for examples tools like DOORS, which are requirement engineering based tools are used. So there needs to be developed a tool for MDRE, the helps in easy development process in the context of MDRE. These problems are more aware in smaller organization, as the need for basic and simple tools is more important [5].

Context of process in MDRE

Lady using a tablet
Lady using a tablet

This Essay is

a Student's Work

Lady Using Tablet

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Examples of our work

Rome does not built single day as like small or large organization does not get success with our follow the good process model the good process model to help full the organization. The organization to develop software in market driven perspective it should use the right type of process implementation. In survey [5] Many of the organizations were interviewed from that they describe many of the organizations failed to deal with right type of process implementation in to the organization. So everything must be planned incremental and evolved. In some organizations the management was to establish a detailed process. With a detailed process, as the process gets more matured, it was found very difficult to deal with the process in an effective manner and some organizations try to work on development process in order to achieve substantial development progress, however they feel that there is lack of flexibility in the process to deal with certain specific situations. So from this literature it is noticeable that there is no specific standard process that is incorporated in the software organization. Many of the time process are adhoc, there is no standardized way of implementing a process. So this may lead to many defects leading to bad software development [5].

Analysis and conclusion

From my class study and literature on Market driven Requirement Engineering we notice the organization have been facing one of the big challenge is the lack of elaborate and evolution process and simple tools for understanding of the requirements and completeness to the requirements. Some of the organizations does not have right kind of process models and tools while which may be mislead the direction of development and growth. Some organizations use a very adhoc process to keep up with the space of the market. So organization prefers elementary process, which may not guarantee appropriate results in the market driven environment. Also, very detailed process may not work in a proper sense. Thus a need for special process that suits the market driven requirement engineering was needed. Thus we supported that REPEAT and goal oriented communication are helpful to avoid these problems in organization. These are mainly developed for perspective of the market driven requirement engineering process and communication. Our opinion is the organization should use REPEAT and Goal oriented communication can solve these problems. Also, basic and simple tools that are clearly understandable and complete specification need to be developed in order to redirect the misguided requirements. Thus we feel that a simple UML based modeling based on natural language specification with linguistic techniques can solve the problem.

3. Requirements overload

From my literature study we find out one of the major challenge is requirements overloading in market driven perspective developed products are off the self products in this way eliciting requirements from different sources such as market segments, different users, different customers, competitor pressure, internal staff etc while market driven development process is the handling of heavy inflow of requirements. So it is important to manage all eliciting requirements in an understanding and useful manner [7]. The implementation of the market product get requirements more than the number of requirements is relatively more, it is not possible to prioritize the requirements and to select the requirements , in order to implement the software product. It is very important for the product management to select the requirements that are useful in achieving the overall business goals of the organization. And also, it is an important to remove the requirements that are out of scope from the business goals [8]. According to market requirement engineering process it is not a single step process, it is a continuous and evolving process, which means the products are developed for multiple releases. So in a market driven requirement engineering process, the product management should deal with the requirements in an appropriate and effective way, as the inflow of requirements are more and more, the right kind of requirement must be selected and which requirements must satisfy the end customer and market needs. We feel handling of continuous requirements is a real problem in a market driven requirement organizations, most of the companies fail to handle the large flow of requirements. Due to this they fail to prioritize the right kind of requirements needed to meet the market needs.

Implications:

In market driven product development process to gathered more suggestions from different stake holders for requirements are obviously important, but too many suggestions may really have an impact on product release planning [3]. Like there is a simple proverb , which says "too many cooks may spoil the dish", according to proverb too many people involved in making requirement selection decision may obviously lead to ambiguous , un understandability and failure of the product that is launched in the market. Also, if the inflow of requirements is relatively more, we follow the an appropriate method to prevent data bases from being flooded it may lead the problem more inflow of requirements in market development process.

Test and validity criteria:

This technological MERTS tool was implemented and validated in organization point of view, its understanding is difficult but once understand the method effectively we can use the very easily in organization it was proved to be easy to used, once the method is understood. In this One of the major prerequisite is requirement abstraction doesn't seem to have any impact on the outcome of the results. In fact many of the organizations interested to implement MERTS. Also organizations find it relatively easier to MERTS. From an organization perspective, it gives a clear focus and direction for the organization to have a clear vision [8].

Our Analysis:

From my class study and literature on Market driven Requirement Engineering we notice the organization have been facing one of the big challenge is the requirements over loading the product manager face big challenge in his job is the product manager to select and prioritize and select right type of requirement to successfully establish the product in the market. Due to the requirements are continuously flowing and over loading the right quality selection is not possible to make with the requirements. From my literature study we supported that MERTS is an appropriate tool that needs to be incorporated in organizations for successful evolution of a product. It combines technical management as well as strategic decisions into consideration, it provides an optimum solution to the product managers in the organization for making correct decision on selecting the appropriate requirement; it's also help in to priorities the large number of requirements. It can shows a road map to managers in the organization and help making right choices for the next product release and provides a strong vision for different stake holders in the organization to achieve their goals.

References:

  1. A. Griffin, and J. Hauser, "Integrating R&D and Marketing: A Review and Analysis of the Literature", Journal of Product Innovation Management 13 (1996), 191-215.
  2. Samuel Fricker Tony Gorschek, and Petri Myllyperkiö," Handshaking between Software Projects and Stakeholders Using Implementation Proposals" Springer-Verlag Berlin Heidelberg 2007
  3. Lena Karlsson, Åsa G. Dahlstedt, Johan Natt och Dag, Björn Regnell, Anne Persson, "Challenges in Market-Driven Requirements Engineering - an Industrial Interview Study", Proceedings of Eighth International Workshop on Requirements Engineering: Foundation for Software Quality, Sept 9-10th, 2002 Essen Germany.
  4. Samuel Fricker, Tony Gorschek, Martin Glinz. "Goal-Oriented Requirements Communication in New Product Development", 2nd International Workshop on Software Product Management (IWSPM'08).
  5. Karlsson. L et.al. (2007) "Requirements engineering challenges in market-driven software development - An interview study with practitioners", Lund University, Sweden
  6. lecture slides
  7. C. Potts, "Invented requirements and imagined customers: requirements engineering for off-the- shelf software," in Proceedings of the Second IEEE International Symposium on Requirements Engineering, pp. 128-130, 1995
  8. M. Khurum, K. Aslam, and Tony Groschek"A Model for Early Requirements Triage and Selection Utilizing Product Strategies,"Blekinge Institute ofTechnology, APS, 37225, Ronneby, Sweden