Gannon UniversityRequirement Engineering

A Case Study: “Why Requirement Engineering Fails: A Survey Report from China” by Liu et al.

Presented by: Ibrahim Helal Alzahrani

Mohamed Mahtab Ahmed Alfrraj

Murtada B. TunisProfessor: Frank Xu

Date: 4/8/2013.

• As software work becomes more intensive, requirement engineering has gained attention in both academia and industry.

• The question arises: under what situations RE is not working well?

• Liu et al have tried to investigate some of these issues by studying the way RE is practiced across industries in China and the current paper is a result of one of such studies conducted in 2009.

Forecast:

• Motivation and problem statement: 2 slides• Related work: 1 slide• Methods: 1 slide• Results: 6 slides• Summary: 1 slide• Future Work: 1 slide• Backup Slides: 1

Outline:

• Requirement Engineering techniques have had no common standards across companies, countries, cultures, and continents

• As companies get more globalized, the need to understand RE techniques used across boundaries and borders cannot be more apparent.

• Successful requirement engineering is a function of successful ELICITATION, ORGANIZATION, and DOCUMENTATION techniques.

• Understanding RE in China as an emerging economy could be the key to understanding RE as practiced in other emerging economies like the rest of the BRIC.

Motivation:

• “Understanding how the general software practitioners elicit and represent requirements in organizations in China to design better methods, target suitable training, and avoid recurring problems.”

Problem Statement:

• Earlier Studies:– El Emam et al: “A field study of

Requirements Engineering Practices in Information Systems Development,” K. El Emam and N.H. Madhavji. 2nd IEEE Int’l Symp. RE, 1995. • Studied RE practices in information

Systems development• 60 cases analysed• Discovered 7 technical/non-technical

issues that influence RE processes in information systems

– Sadraei et al: “A field study of RE practice in Australian Software Industry,” RE Journal, July, 2007.• Surveyed RE practice from 28

software projects• Used 16 Australian companies

– Aranda et al: “Requirements in the Wild: How Small Companies Do It,” Aranda J., Easterbrook S., Wilson G., 17th IEEE Int’l RE Conf., 2007. • Investigated how small companies

conduct RE activity.

• Ali Babar et al: “Establishing and Maintaining Trust in Software outsourcing Relationships: an empirical Investigation,” Journal of Systems and Software, 2007.

• Zowghi Et al: “The impact of stakeholders. Geographical distribution on managing requirements in a multi-site organization,” 10th IEEE Int’l RE Conf., 2002.

• Current Research:– Different in that it takes into

account a large number of practitioners’ general experiences and observations across various projects.

– And whilst most of the above focus on specific problems than understanding the general status quo of the industry, this paper try to focus on state-of-practice of RE in Chinese companies.

Related Work:

• Mostly web survey-based• Used face-to-face interivews• Used stories and testimonials • Ran survey in 2007, 2008, and 2009. Surveyed:

– State-owned enterprises– Multi-national corporations– Domestic private companies– Universities

• Collected data on respondents status and organization

• 2007-2008 survey: – Published in a separate paper:

“understanding the Chinese Characteristics of Requirement Engineering, , Liu et al., 2009.”

• Current article: Results of 2009 survey

• 377 survey subjects• 237 software companies/research

organizations• Business sectors: banking,

healthcare, power generation, telecom, retail, and electronics.

• Surveyed only software practitioners• Over 400 contacted; 377 responded• Over 200 also provided observations

and success/failure stories and observations.

• Age demographics: 25-35• Over 30% have 5-10 years of work

experience.• Subject roles: senior managers,

general managers, architects, etc.

Methods:

Results: A: Elicitation Techniques

• Question 1: “In your organization, which kinds of work are performed during requirements engineering?”

• Q2: “How much efforts are spent on RE-related activities in terms of percentage of project time?”– 42% of organizations spend more than 10% on RE for

entire project duration– 25% of organization spend >20%– 21% of organizations spend <10%– 12% of organizations spend very little time

• Q3: “Would your customers like to spend time on requirements-related activities?”– 120/377 participants: “customers are happy to be involved

in RE-related activities– 185 participants: “No…although they value the importance

of requirements and believed that sufficient time should be spent on delivering a high quality document.”

– 72 participants: Neutral

• Q4: “Do you think there are direct relationships between requirements specification and software quality?”– 68%: “believe that the quality of requirement documents

has strong impact on the quality of final software system.”– 3%: “believe no relationship between spec and software

quality– 29%: “believe only a moderate impact of spec on software

quality.

• Q5: “Which requirement elicitation method do you use?”

• Q7: “What is the knowledge and skills background of people performing RE tasks?”– 45%: Taken RE classes in university– 29%: Short RE courses – 17%: Self-learning– 9%: No training at all

• Q8: “Who do you communicate with during the phase of requirements elicitation?”– 57%: Leaders of related business department– 53%: Leaders of IT department– 19%: Leaders in customer organization– 14%: IT staff– 16%: Marketing staff– 5%: Others

• Q9: “The customer keep changing requirements even after the development contract has been signed. How do you deal with this situation?”– 90%: “Changes are normal.”– 80%: will renegotiate the terms of contract– 7%: Will do whatever the customer says– 14%: Simply follow the contract

Q6: “What are some of the roles of the people who performed the requirement elicitation activities.”

54%: Project Managers47%: General Manager25%: Marketing staff12%: System designer5%: Other

Results: A: Elicitation Techniques

• Q10: “Which representation technique do you use?”

• Q11: “What are the RE tools that are used in your daily practices?”– 40%: Use tools such as DOORS– 60%: Do not use any RE tools.

• Q12: “What are the actual contents included in the requirement specifications?”– 78%: Project and goal description– 99%: Functional requirements

description– 74%: Overall scheme– 64%: Non-functional requirements

description– 50%: Change log. – “Risk analysis, changes and schedule

receive less attention.”

Results: B: Representation Techniques

• 203/373 stories. – 15%: MNCs– 17%: Government sponsored enterprises– 53%: Domestic private companies– 8%: Universities– 7%: Anonymous

• 1. RE status in MNCs:– Interviewees from 33 MNCs– HQ: US, Japan, Sweden, Germany, Finland, and

India. – RE advanced and cutting-edge technology is being

used. – PM tools used for RE particularly DOORS and

Team Center.

• 2. Government Owned Enterprise(GOEs):– Interviewees from 31 GOEs– Sectors: Energy, pharmaceutical, IT, home

electronics. – RE status depends on how developed the

geography is and also the sector concerned.

• 3. RE status for Domestic Private Companies(DPCs):– Interviewees from 32 DPCs– Sectors: telecom and

software– Too much time spent on

understanding requirements– Often nervous in meeting

government officials– Trusted less by customers

because they lack formal management and QA procedures.

Results: C: RE Failure and Success Stories and Findings.

• 10%: Out-sourcing products• 16%: Mass marketed products• 74%: Customized products

• RE status in mass marketed products:– Very difficult– Questionnaire often used in elicitation– Email strategy for elicitation was dismal– Face-to-face relatively successful– Higher quality data when customers more

familiar with software functionality

• RE status for out-sourcing products:– Most are vague– Communication gaps exists– RE processes for international

projects greatly affected by language, geography, cultural differences, and barriers.

Results: D: RE Status on Different Product Types

• Customers do not have a clear understanding of system requirements themselves, including scope of the system, major functional features and nonfunctional attributes

• Users’ needs and understanding constantly change

• Software engineers do not have access to sufficient domain knowledge and expertise

• Project schedule too tight to allow sufficient interaction and learning period between customer and development team.

• Reuse existing design in wrong context and environment

• RE decision makers lack of technical and domain expertise

• Broken communication between customer, analyst, and developer

• Lack of standardized domain data definition and system-environment interface.

Summary:

• Future work could look at organizing and documenting techniques to determine causes of failure.

• Future work could use the same techniques studied for customized products which are not elaborated on in the report.

• Future work could adopt workshop methods to gain the benefit of workshop advantages.

Future Work:

• The research successfully provided an understanding of RE practice in Chinese industries

• Elicitation and representation of RE methods clearly needs to several failures in RE

Conclusions:

Thank You For Listening

• 1. Improve project management processes to facilitate communication, documentation, elicitation, and change control and management.

• 2. Domain knowledge and prototype are necessary conditions for successful RE practice

• 3. Making the customer feel their ownership and responsibility to the requirements and the future system

• 4. Be proactive in RE process and predict potential changes and future requirements.

• 5. Link RE with testing and adopt a test-driven design process

Recommendations: