Gannon University Requirement Engineering

1. Gannon University Requirement Engineering A Case Study: “Why Requirement Engineering Fails: A Survey Report from China” by Liu et al. Presented by: Ibrahim HelalAlzahrani Mohamed Mahtab Ahmed Alfrraj Murtada B. Tunis Professor: Frank Xu Date: 4/8/2013.

2. Forecast: • 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.

3. Outline: • 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

4. Motivation: • 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 DOCUMENTATIONtechniques. • 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.

5. Problem Statement: • “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.”

6. Related Work: • 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. • 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.

7. Methods: • 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. • 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.”

8. 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.

9. Results: A: Elicitation Techniques • 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 Managers • 47%: General Manager • 25%: Marketing staff • 12%: System designer • 5%: Other

10. Results: B: Representation Techniques • 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.” • Q10: “Which representation technique do you use?”

11. Results: C: RE Failure and Success Stories and Findings. • 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. • 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.

12. Results: D: RE Status on Different Product Types • 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. • 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

13. Summary: • 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. • 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.

14. Future Work: • 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.

15. Conclusions: • The research successfully provided an understanding of RE practicein Chinese industries • Elicitation and representation of RE methods clearly needs to several failures in RE

16. Thank You For Listening

17. Recommendations: • 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