Academia.eduAcademia.edu

Outline

Title
Abstract
Conclusion
References
All Topics
Computer Science

Requirements Engineering for Transactional Systems

Profile image of Deepika PrakashDeepika Prakash

2018, Data Warehouse Requirements Engineering

https://doi.org/10.1007/978-981-10-7019-8_1
visibility

…

description

17 pages

link

1 file

Abstract

Transactional systems have been the forte of Information Systems/Software Engineering. These systems deal with automating the functionality of systems, to provide value to the users. Initially, up to the end of the decade of the 1960s, transactional systems were simple, single-function systems. Thus, we had payroll systems that accounts people would use to compute the salary of employees and print out salary. Information Systems/Software Engineering technology graduated to multi-functional systems that looked at the computerization of relatively larger chunks of the business. Thus, it now became possible to deal with the accounts department, the human resource department, customer interface, etc. Technology to deal with such systems stabilized in the period 1960-1980. Subsequently, attention shifted to even more complex systems, the computerization of the entire enterprise, and to inter-organization information systems. The demand for engineering of ever more complex systems led to the "software crisis", a term widely used in the 1990s to describe the difficulties that industry of that time faced. A number of studies were carried out and some of the problems highlighted were systems failure/rejection by clients, inability to deliver complex and large software well. The Standish Group's "Chaos" reports [1] presented software industry's record in delivering large-sized systems using traditional development methods. The Group conducted a survey of 8380 projects carried out by 365 major American companies. The results showed that projects worth up to even $750,000 exceeded budget and time. Further, they failed to deliver the promised features more than 55% of the time. As the size of the applications grew, the success rate fell to 25% for efforts over $3 million and down to zero for projects over $10 million. Bell labs and IBM [2] found that 80% of all defects in software products lie in the requirements phase. Boehm and Papaccio [3] said that correcting requirements errors is 5 times more expensive when carried out during the design phase; the cost of correction is 10 times during implementation phase; the cost rises to 20 times for corrections done during testing and it becomes an astronomical 200 times after the system has been delivered. Evidently, such corrections result in expensive products

Related papers

The cost of errors in software development: evidence from industry
J. Christopher Westland

Journal of Systems and Software, 2002

The search for and correction of errors in software are often time consuming and expensive components of the total cost of software development. The current research investigates to what extent these costs of software error detection and correction contribute to the total cost of software. We initiated the research reported here with the collection of a sample of transactions recording progress on one phase of development of a set of software programs. Each of these projects represented the completion of an identical phase of development (i.e., country localisation) for a different country. This enabled each project to be compared with the other, and provided an unusually high degree of control over the data collection and analysis in real-world empirical study. The research findings relied on programmers' self-assessment of the severity of errors discovered. It found that serious errors have less influence on total cost than errors that were classified as less serious but which occurred with more frequency once these less serious errors are actually resolved and corrected. The research suggests one explanation -that programmers have greater discretion in how and when to resolve these less severe errors. The data supports the hypothesis that errors generate significant software development costs if their resolution requires system redesign. Within the context of the research, it was concluded that uncorrected errors become exponentially more costly with each phase in which they are unresolved, which is consistent with earlier findings in the literature. The research also found that the number of days that a project is open is a log-linear predictor of the number of software errors that will be discovered, implying a bias in error discovery over time. This implies that testing results need to be interpreted in light of the length of testing, and that in practice, tests should take place both before and after systems release.

View PDFchevron_right
Influences of Requirement Change on Software Failure
Syed Adnan Afaq

TEST Engineering & Management, 2020

Most of the software requirements are not unfurnished in the initial level of development procedure of software. Software requirements are usually unavoidable due to frequent changes in user needs, changes in market and business policy and operating environment. Basically, requirement change management is also an important and challenging part of the software development process. Changing requirements are one of the main reasons of project failure or cancelled. The success and failure of any software project mostly depend upon project manager that how he manages the requirement change. Several Requirement change management models and methods are introduced and performed different activities for mitigating the impacts of requirement changes. The paper explores research effort done in the field of requirement change and helps to identify the goal of the study.

View PDFchevron_right
A study to investigate the impact of requirements instability on software defects
talha javed

ACM SIGSOFT Software Engineering Notes, 2004

Software development is a dynamic process and is characterized by change. Software projects often begin with unclear, ambiguous, and incomplete requirements which give rise to intrinsic volatility. Constant change in requirements is one of the main causes of software defects and a major issue faced by the software industry. This paper describes the findings of our research-based study that investigates the impact of both the pre-release and post-release requirements changes on overall defects by defining measures, collecting data against those measures and analyzing the collected data through statistical techniques. Our findings, based on industry data from 4 software projects consisting of 30 releases, all in e-commerce domain, indicate that there is a significant relationship between pre/post release change requests initiated by the client and software defects. In addition, our data analysis indicates that changes in the design of the system at the later stages of software develop...

View PDFchevron_right
Introduction to software engineering
Osama Rayis

Crossroads, 2001

View PDFchevron_right
Requirement Engineering Errors: Errors and Ambiguities of Visualization
Shail Dinkar

International Journal of Computer Applications, 2014

Requirement Engineering encompasses the tasks that go into identifying, determining and understanding the customer needs as well as the expectations from the proposed software system or an application, taking account of possibly conflicting requirements of various stakeholders. Requirement Engineering, also referred to by names like requirement gathering or requirement analysis or requirement specification, is a well-defined stage in the software development life cycle. This stage is not only well defined but also very crucial to the success of software development. Most of the project failures have been attributed to this stage only. It"s a general and very often heard statement: "Requirements were not clear or Requirements were ambiguous". So, what does this word "Requirement" is all about, those requirement analysts try to establish and still, most of the projects fail due to lack of clarity in requirements. Requirements describe the behavior of the proposed software system but the roots of the same lie in the original real-time system for which software system has been proposed. Requirements engineering, in this manner, encompasses both the problem domain of the system as well as the solution domain of the system. The process of establishing the requirements is not an easy task as it is crossing over the boundaries of problem and the solution domain on a regular basis, and is bound to have errors. Errors in requirement engineering stage have many sources, ambiguous and unclear requirements are only a part of the problem. Having explored a number of common types of errors to find their source and strategies for dealing with them, Kurt Bittner [1] categorized requirement errors into three major groups: Errors of conceptualization (the ones that arise because of poorly conceived problem); Errors of specification (the ones that arise because of poor specification) and Error of implementation (the ones that arise because of poor coding and testing). This paper is an attempt to put forward an idea of one more category of requirement errors: Errors of visualization. The difference between errors of conceptualization and error of visualization though apparently seems vague but is as clear as the boundaries between problem and the solution domain. The paper attempts to study the differences between these two types of errors and also studies the symptoms and possible solution strategies for errors of visualization.

View PDFchevron_right
Preventing Requirement Defects
Søren Lauesen

Inadequate requirements cause many problems in software products. This paper is a case study of requirement defects in a real-life product. We analyzed the cause of the defects and estimated the likely effect of about 50 prevention techniques. We had hoped a novel combination of techniques would come up, but facts suggested that the best approach was quite traditional, although new to the company: Study the user tasks better, make early prototypes of the user interface, and test them for usability. This approach was tried out in a new development project in the same company. Since the two projects differed in many ways, it was harder than expected to compare development costs and defect statistics. However, two unexpected results turned up: We could observe a drastic decrease in the number of usability problems per screen. Further, the new project was the first and only one among scores of other projects that was completed on time, without stress, and with high customer satisfaction...

View PDFchevron_right
Software needs engineering: a position paper
Hans-Jürgen Kugler

2000

When the general press refers to 'software' in its headlines, then this is often not to relate a success story, but to expand on yet another 'software-risk-turned-problem-story.' For many people the term 'software' evokes the image of an application package running either on a PC or some similar stand-alone usage. Over 70% of all software, however, are not developed in the traditional software houses as part of the creation of such packages. Much of this software comes in the form of products and services that end users would not readily associate with software. These can be complex systems with crucial connections made through software, such as telecommunications or banking systems, or the logistics systems of airports. Or these can be end-user products with software embedded, ranging from battery management systems in electric shavers, over mobile phones to engine management and safety systems in cars. e-Commerce systems fall into this category, too.

View PDFchevron_right
IMPACT OF BAD REQUIREMENTS AND COMMUNICATION ISSUES ON SOFTWARE AND SELECTION OF OPTIMAL REQUIREMENT ELICITATION TECHNIQUES
Journal of Software Engineering & Intelligent Systems

Journal of Software Engineering & Intelligent Systems, 2020

Software has covered almost every aspect of human life, from airplanes to smart phones, everything is dependent on software now a days. As software covers lot of our work and make our work a lot easier but at the same time it is to be sure that lot of effort goes into making a software. Software failure has cost lot of money and human life as well. There are many factors which cause software to fail and most of the time it happens right at the end of the completion of the development of a software. In this paper, we will discuss several factors that why software fails and how it can cause companies to face major loss in terms of finance. This research paper mainly focuses on bad requirements, elicitation techniques and the issues faced due to communication.

View PDFchevron_right
A systematic literature review to identify and classify software requirement errors
Josphat Chirimu

Information & Software Technology, 2009

Most software quality research has focused on identifying faults (i.e. information is incorrectly recorded in an artifact). Because software still exhibits incorrect behavior, a different approach is needed. This paper presents a systematic literature review to understand whether using information about the source of a fault (i.e. and error) can be helpful. Once the usefulness of errors is established, then it is important to identify and classify errors. The review identified 149 papers from software engineering, psychology and human cognition that provided information about the sources of requirements faults. A major result of this paper is a categorization of the sources of faults into a formal taxonomy that provides a starting point for future research into error-based approaches to improving software quality.

View PDFchevron_right
Tracing Requirements Errors to Problems in the Requirements Engineering Process
Alistair Sutcliffe

Requirements Engineering, 1999

A case study of requirements engineering practice is reported. The application, a decision support system for the Greek Ministry of Health, was investigated by studying the process of requirements analysis through to design and implementation. A usability analysis was then conducted on the designed system with the users. Several usability problems were discovered, and interviews uncovered further problems with the system that could be attributed to failure in requirements engineering. Even though requirements were explicitly stated and the system was an evolution from an existing legacy system, functionality was defective and usability was poor. The client's prime concern for redeveloping the system was to improve usability; unfortunately communications problems in the RE process meant that the developers did not appreciate this. The implications for RE methods and understanding the RE process are discussed.

View PDFchevron_right

References (41)

  1. Chaos Report, Standish Group. (1994).
  2. Hooks, I. F., & Farry, K. A. (2001). Customer-centered products: Creating successful products through smart requirements management. New York: AMACOM Div American Mgmt Assn.
  3. Boehm, B. W., & Papaccio, P. N. (1988). Understanding and controlling software costs. IEEE Transactions on Software Engineering, 14(10), 1462-1477.
  4. Standish Group. (2003). Chaos Chronicles Version 3.0. West Yarmouth, MA.
  5. Charette, R. N. (2005). Why software FAILS. IEEE Spectrum, 42(9), 42-49.
  6. Wake, W. C. (2003). INVEST in good stories and SMART tasks. Retrieved December 29, 2005. From http://xp123.com/xplor/xp0308/index.shtml.
  7. IEEE Standard, IEEE-Std 610. (1990).
  8. Robertson, S., & Robertson, J. (2012). Mastering the requirements process: Getting requirements right. MA: Addison-wesley.
  9. Kotonya, G., & Sommerville, I. (1998). Requirements engineering: Processes and techniques. New York: Wiley.
  10. Sutcliffe, A. (2002). User-centred requirements engineering. Berlin: Springer.
  11. Mylopoulos, J., Chung, L., & Yu, E. (1999). From object-oriented to goal-oriented requirements analysis. Communications of the ACM, 42(1), 31-37.
  12. Zave, P. (1997). Classification of research efforts in requirements engineering. ACM Computing Surveys (CSUR), 29(4), 315-321.
  13. van Lamsweerde, A. (2000, June). Requirements engineering in the year 00: A research perspective. In Proceedings of the 22nd International Conference on Software Engineering (pp. 5-19). New York: ACM.
  14. Nuseibeh, B., & Easterbrook, S. (2000, May). Requirements engineering: A roadmap. In Proceedings of the Conference on the Future of Software Engineering (pp. 35-46). New York: ACM.
  15. Yu, E. S. (1997, January). Towards modelling and reasoning support for early-phase requirements engineering. In Proceedings of the Third IEEE International Symposium on Requirements Engineering (pp. 226-235). IEEE.
  16. Goguen, J. A., & Linde, C. (1993). Techniques for requirements elicitation. Requirements Engineering, 93, 152-164.
  17. Suchman, L., & Jordan, B. (1990). Interactional troubles in face-to-face survey interviews. Journal of the American Statistical Association, 85(409), 232-241.
  18. Hickey, A., & Davis, A. (2003). Barriers to transferring requirements elicitation techniques to practice. In 2003 Business Information Systems Conference.
  19. Leffingwell, D., & Widrig, D. (2000). Managing software requirements. MA: Addison-Wesley.
  20. Davis, G. B. (1982). Strategies for information requirements determination. IBM Systems Journal, 21, 4-30.
  21. Burton, A. M., Shadbolt, N. R., Rugg, G., & Hedgecock, A. P. (1990). The efficacy of knowledge elicitation techniques: A comparison across domains and levels of expertise. Journal of Knowledge Acquisition, 2, 167-178.
  22. Lapouchnian, A. (2005). Goal-oriented requirements engineering: An overview of the current research. University of Toronto.
  23. Antón, A. I. (1996, April). Goal-based requirements analysis. In Proceedings of the Second International Conference on Requirements Engineering (pp. 136-144). IEEE.
  24. van Lamsweerde, A. (2004, September). Goal-oriented requirements engineering: A roundtrip from research to practice engineering. In Requirements Engineering Conference, 2004. Proceedings. 12th IEEE International (pp. 4-7). IEEE.
  25. Dardenne, A., van Lamsweerde, A., & Fickas, S. (1993). Goal-directed requirements acquisition. Science of Computer Programming, 20(1), 3-50.
  26. Pohl, K. (2010). Requirements engineering: Fundamentals, principles, and techniques. Berlin: Springer.
  27. van Lamsweerde, A. (2001). Goal-oriented requirements engineering: A guided tour. In Proceedings. Fifth IEEE International Symposium on Requirements Engineering, 2001 (pp. 249-262). IEEE.
  28. Haumer, P., Pohl, K., & Weidenhaupt, K. (1998). Requirements elicitation and validation with real world scenes. IEEE Transactions on, Software Engineering, 24(12), 1036-1054.
  29. Antón, A. I., & Potts, C. (1998, April). The use of goals to surface requirements for evolving systems. In Proceedings of the 1998 International Conference on Software Engineering, 1998 (pp. 157-166). IEEE.
  30. Horkoff, J., & Yu, E. (2010). Interactive analysis of agent-goal models in enterprise modeling. International Journal of Information System Modeling and Design (IJISMD), 1(4), 1-23.
  31. Horkoff, J., & Yu, E. (2012). Comparison and evaluation of goal-oriented satisfaction analysis techniques. Requirement Engineering Journal, 1-24.
  32. Matulevičius, R., & Heymans, P. (2007). Comparing goal modelling languages: An experiment. Requirements engineering: Foundation for software quality (pp. 18-32). Berlin Heidelberg: Springer.
  33. Castro, J., Kolp, M., & Mylopoulos, J. (2002). Towards requirements-driven information systems engineering: The Tropos project. Information Systems, 27(6), 365-389.
  34. Sutcliffe, A. G., Maiden, N. A., Minocha, S., & Manuel, D. (1998). Supporting scenario-based requirements engineering. IEEE Transactions on Software Engineering, 24 (12), 1072-1088.
  35. Holbrook, H., III. (1990). A scenario-based methodology for conducting requirements elicitation. ACM SIGSOFT Software Engineering Notes, 15(1), 95-104.
  36. van Lamsweerde, A., & Willemet, L. (1998). Inferring declarative requirements specifications from operational scenarios. IEEE Transactions on Software Engineering, 24(12), 1089-1114.
  37. Plihon, V., Ralyte, J., Benjamen, A., Maiden, N. A., Sutcliffe, A., Dubois, E., & Heymans, P. (1998). A reuse-oriented approach for the construction of scenario bases methods. In Proceedings of International Conference on Software Process (pp. 1-16).
  38. Liu, L., & Yu, E. (2004). Designing information systems in social context: A goal and scenario modelling approach. Information Systems, 29(2), 187-203.
  39. CREWS Team. (1998). The CREWS glossary, CREWS report 98-1. http://SUNSITE. informatik.rwth-aachen.de/CREWS/reports.htm.
  40. Pohl, K., & Haumer, P. (1997, June). Modelling contextual information about scenarios. In Proceedings of the Third International Workshop on Requirements Engineering: Foundations of Software Quality REFSQ (Vol. 97, pp. 187-204).
  41. Cockburn, A. (1997). Structuring use cases with goals, 1997. Journal of Object-Oriented Programming.

Related papers

Requirements development, verification, and validation exhibited in famous failures
Terry Bahill

Systems Engineering, 2005

Requirements Development, Requirements Verification, Requirements Validation, System Verification, and System Validation are important systems engineering tasks. This paper describes these tasks and then discusses famous systems where these tasks were done correctly and incorrectly. This paper shows examples of the differences between developing requirements, verifying requirements, validating requirements, verifying a system, and validating a system. Understanding these differences may help increase the probability of success of future system designs.

View PDFchevron_right
Preventing Requirement Defects: An Experiment in Process Improvement
Søren Lauesen

Requirements Engineering, 2001

Inadequate requirements cause many problems in software products. This paper reports on an experiment to reduce the number of requirement defects. We analysed the present defects in a real-life product and estimated the likely effect of 44 prevention techniques. We had hoped a novel combination of techniques would come up, but the best approach was quite well known, although new to the company: study the user tasks better, make early prototypes of the user interface, and test them for usability. This approach was tried out in a new development project in the same company. Due to the new approach, there was no doubt about requirements during programming, and as a result it became the first project in the company that was completed on time and without stress. Usability was drastically improved, and as a result the product sold twice as many units as similar products, and at twice the unit price.

View PDFchevron_right
52. Sanjay Mohapatra, Requirement Management – Controlling Quality At The Upstream In Commercial Software Project Management, International Journal of Applied Engineering Research, 2015, Volume 10, Number 3, pp. 8203-8219.
Dr. Sanjay Mohapatra

Requirement Management in commercial software application development not only talks of gathering requirements from the customer it also highlights the need for a scientific step by step approach for eliciting requirement. Without thorough understanding of the requirements from customer point of view at this stage will lead to a cascading effect later on as it would involve rework and extra cost. Hence a complete scientific management approach is needed for this stage which is known as requirement management. Requirement Management takes the accountability of not only meeting the technical specifications of the customers but also involves defining an approach to take care of any change in the requirement needed later on. In addition to that requirement management takes care of tracing back each and every functionality requirement to the final delivered output. In this paper, based on experience, tools and techniques that can be used to gather requirements for commercial software application development have been presented. The process needed for managing change requests have also been discussed. Using this approach, the author has been successful in meeting customer requirements and reducing rework effort due to less defects being injected during project life cycle.

View PDFchevron_right
A Survey of Failures in the Software Development Process
Rita Marques

2017

Software development is one of the most important worldwide industries and continues to grow. To deal with this challenge, organizations are adopting ever more tools and methodologies. However, software development projects are still failing in meeting time, budget and functional requirements. This study provides insights on the failures faced by software development organizations regarding their processes, the reasons leading to these failures, and initiatives taken to cope with them. A research methodology was used to gather and compare results from a literature review and semi-structured interviews. We learnt that there are more failures in Management activities, although they were not often reported , while failures in Requirements Engineering and Software Testing are less in number but more frequently reported. Lack of communication, lack of time for improvements and appropriate testing, and poor requirements and functionalities specification were the mostly reported failures. Furthermore, we learnt that organizations are not implementing any initiative to address these failures, although they suggested solutions.

View PDFchevron_right
Scaling of Critical success factors for Requirements engineering in the development of Large Scale Systems
ikram asghar

The development of large scale software systems is a complex and lengthy activity. The development of large scale systems different types of stockholders (e.g. customers, system users, system analysts, designers, and software developers) have to take part and work with one another. Requirement engineering is considered to be the most important activity in the development of software systems [6]. If the system under development is a large and complex system, then the importance of the requirement engineering becomes even more important and necessary. There are many problems and challenges that the development organizations are facing in the requirement engineering phase for large scale systems. The software engineering community is working day and night in this area and they have proposed many solutions and lessons for addressing these problems and challenges faced. This paper presents the main contribution of the research work that have been conducted in recent years to identify the requirement challenges faced in large scale development systems and proposed lessons learned addressing these challenges. In this paper we have presented two challenges that were observed by us in [LSS] projects. This paper also identifies issues and questions which are still open for further research and thus it will serve the future researchers as a guide map for doing research in requirement engineering.

View PDFchevron_right

Related topics

  • Computer Science
    • 580 California St., Suite 400
    San Francisco, CA, 94104
    © 2025 Academia. All rights reserved