Topic 2 - Introduction to Requirements_Engineering - Tagged.pdf

Software Engineering Fundamentals - CSY1064 Introduction to Requirements Engineering  By way of an introduction to the assignment and core concepts required for this term's work, we need to examine the idea of requirements engineering.  As an essentia...

Software Engineering Fundamentals - CSY1064 Introduction to Requirements Engineering  By way of an introduction to the assignment and core concepts required for this term's work, we need to examine the idea of requirements engineering.  As an essential part of any computing project, formulating a comprehensive understanding of the problem that is to be solved and the required characteristics of the solution is essential. The material presented in this lecture should provide a good introduction to this underpinning concept. What is Requirements Engineering?  Alan Davis defines requirements engineering as “All activities up to but not including the decomposition of software into its actual architectural components” [Davis, 1988] (i.e. the internal system design)  Bray expands upon this definition: - “An investigation and description of the problem domain and requirements. Followed by the design and documentation of the characteristics for a solution system that will meet those requirements” [Bray, 2002]  Kovitz provides a similar definition when he describes requirements engineering as “the process of converting an open-ended problem into a well-defined problem” with an appropriate solution. [Kovitz, 1999]  It should be clear from each of these definitions that the process of requirements engineering involves significantly more than simply formulating a list of required system functionality for a proposed application solution. Why is Requirements Engineering so Important?  Appropriate requirements engineering is fundamental to the success of any software engineering project because it provides the foundation upon which the rest of the project is built.  inaccuracies, errors and omissions during this pivotal stage can result in problems that can significantly increase the cost and duration of the project.  A project designed and built around an incorrect understanding of the original problem domain will result in the production of a system that does not fulfil the needs of the planned user group or client.  Examples that illustrate project failure caused by poor requirements engineering are illustrated below. Page 1  Software Engineering Fundamentals - CSY1064 1) Performing Rights Society (PROMS) Project: This project, aimed at upgrading the system for handling music royalties, was abandoned in 1992 after an investment of £11 million. The primary cause of failure was poor requirements engineering. The system requirements were written in such a way that the user group could not understand or validate the functionality. The project was further derailed by ambiguous requirements and a lack of communication between stakeholders and the development team, leading to misinterpretations of the intended system behaviour. The lack of clarity and involvement of end-users early in the process significantly contributed to its downfall (Glass, 1998). 2) London Stock Exchange TAURUS Project: The TAURUS (Transfer and Automated Registration of Uncertified Stock) project, initiated by the London Stock Exchange, was cancelled in 1993, resulting in an estimated total failure cost of £480 million. The core issue was conflicting system requirements that were never fully reconciled. The project had multiple stakeholders, each with differing needs, and the requirements documentation could not harmonise these conflicting interests. Additionally, scope creep and constant changes to the requirements without adequate re- evaluation of the project timeline and resources led to the project’s collapse (Ward, 1996). 3) London Ambulance Service Despatch System: This system, implemented in 1992, was shut down after only two days of operation. Sutcliffe’s analysis pointed out that poor requirements analysis was a significant contributing factor. The despatch system was intended to improve response times by automating the allocation of ambulances. However, the requirements failed to account for the practical constraints of real-world operations, including the need for human oversight and the complex routing and coordination tasks that an automated system could not adequately handle. Furthermore, inadequate user involvement during the design and testing phases exacerbated the system’s failure when it was deployed (Sutcliffe, 1994). 4) BBC Digital Media Initiative (DMI): A more recent failure was the BBC's Digital Media Initiative (DMI), which was cancelled in 2013 after £98.4 million was spent. The DMI was supposed to create a digital production and archiving system, but it failed due to unclear and poorly defined requirements. The initial requirements were not properly communicated, leading to a system that failed to meet the operational needs of the BBC. The project suffered from scope creep, and the development team could not adjust the system design to match evolving requirements. Ultimately, the system was deemed unusable, and the entire project was scrapped, resulting in a significant financial loss (BBC, 2014; Collins, 2013).  Glass comes to the following conclusion: - “There is little doubt that project requirements are the single biggest cause of trouble on the software project front. Study after study has found that, where there is a failure, requirements problems are usually at the heart of the matter.” [Glass, 1998] Why is Requirements Engineering so Difficult? Page 2  Software Engineering Fundamentals - CSY1064  We can assume, in its simplest form, that requirements engineering is about solving problems.  Logically, this implies that in order to solve the problem appropriately, we must first fully understand it.  Thus, the task of requirements engineering is doubly difficult, as the engineer needs to:- Gather the domain of knowledge from a variety of sources for any given system and superimpose this upon the expertise required for the requirements engineering itself.  As the best source of domain knowledge will usually be the existing or potential system users, this also introduces the difficulties of communication and knowledge transfer. Basic Terminology and Concepts  In order to fully understand the requirements engineering process, we need to be familiar with some basic terminology and concepts:- The problem domain  The problem domain can be defined as the part of the universe within which the problems exist.  It can equally be regarded as the part of the world within which the new system solution (or application) will operate in order to produce the required effects. Page 3  Software Engineering Fundamentals - CSY1064 Example Problem: “We want a system to increase the effectiveness of our current stock control system, used to monitor the flow of stock coming in and out of our warehouse”  The problem domain would include, to name but a few: - a) The current stock control system. b) The employees/job responsibilities/roles involved in the process. c) The clerical documents used/required during the process. d) The process inputs and outputs and any associated procedures, including stock suppliers, transport methods and delivery schedules. e) Comparable stock control software systems available on the market f) Any relevant legislation related to the stock control process or the proposed software solution system.  A problem domain can sometimes be regarded as a set of sub- systems, known as terminators, which will eventually interface with the new proposed solution system. The Solution System  The solution system is the system that will eventually be built to solve the problem(s) within the problem domain. (Also called the application or product)  The problem domain and the solution system are interfaced by the system specification.  Where: - Analysis concerns the problem domain and the problems that exist within it. Specification concerns the interaction between the problem and the system solution. Design (Not a part of the requirements engineering process) concerns the internal workings of the solution. Page 4  Software Engineering Fundamentals - CSY1064 Requirements  The following definition of system requirements stresses the difference between the problem domain and the solution system. “Requirements are the effects that the client wishes to be brought about in the problem domain.” [Bray, 2002]  An alternative definition by the IEEE also gives additional insight into the purpose of system requirements:- “A condition or capability that must be met by the system to solve a problem or achieve an objective.”  System solution requirements should include four key elements:- 1) Functional Requirements  Functional requirements describe the required behaviour (functionality) on the part of the solution system. 2) Performance Requirements  Performance requirements may be regarded as parameters of functionality in that they determine how quickly, how reliably, etc. functions must operate.  Typical performance requirements include a measure of :- Speed This can be viewed in terms of throughput or response times. (E.g. The time taken to process 100 transactions) Capacity Gives an indication of the quantity of data that can be stored within the system and/or the number of operations that can be performed concurrently. (E.g. The number of users that can access an online system simultaneously or the maximum number of data records the system can store) Reliability The mean time between failure or an indication of system availability. (E.g. An online system will be available for 165 hours, out of a possible 168 hours each week) Page 5  Software Engineering Fundamentals - CSY1064 Usability Page 6  Software Engineering Fundamentals - CSY1064 Usability evaluation criteria are sometimes difficult to define, but they should give some indication of how ‘easy’ the system is to operate. (E.g. An experienced computer user should be able to learn how to input records into the system, at a rate of 20 per hour, with no more than an hours training) 3) Design Constraints  Design constraints are the non-functional requirements that affect (constrain) how the system is built but NOT what the system does.  Clients (not the requirements engineer) should impose design constraints  Common design constraints include:- Target operation system. Distributed or local architecture. Available memory size. Front-end graphic styles. (e.g. consistent company format) Programming languages to be used. Application packages that must be integrated with the proposed solution system Development standards that must be applied. Design approaches that must be used. 4) Commercial Constraints  Considerations such as the cost and project time scales must also be considered.  A variety of project management techniques have been developed to support potentially difficult cost/time scale estimations. Figure 1.1 (below) summarises the fundamental sections to be included in a typical system solution requirement documentation. Page 7  Software Engineering Fundamentals - CSY1064 Fig 1.1 - The fundamental sections to be included in any system solution requirement documentation References British Broadcasting Corporation, 2014. DMI: A disaster in digital. [online] Available at: https://www.bbc.co.uk/news/technology-22781573 [Accessed 20 Sept. 2024]. Bray, I. K. (2002). An Introduction to Requirements Engineering. Harlow, London, New York, Addison-Wesley. Collins, T., 2013. BBC scraps £100m Digital Media Initiative. Computer Weekly, [online] Available at: https://www.computerweekly.com/news/2240185537/BBC-scraps-100m- Digital-Media-Initiative [Accessed 20 Sept. 2024]. Davis, A. (1988). A comparison of techniques for the specification of external system behaviour. Communications of the ACM, 31 (9),pp 1098-1115. Glass, R.L., 1998. Software Runaways: Lessons Learned from Massive Software Project Failures. Prentice Hall. Glass, R. L et al. (1992), Software Tasks - Intellectual or Clerical. Information & Management (23:4) Oct 1992, pp 183-191 Kovitz. B. L. (1999), Practical Software Requirements: A Manual of Content and Style. Manning Publications Company Sutcliffe, A., 1994. The Failure of the London Ambulance Service Dispatch System. In Case Studies in Software and System Failure. Springer, pp. 64-74. Page 8  Software Engineering Fundamentals - CSY1064 Ward, J., 1996. TAURUS: An IT failure study. Journal of Information Technology, 11(4), pp. 327-336. Additional Wider Reading on the Topic of Requirements Engineering Lauesen, S., 2002. Software requirements: Styles and techniques. Addison-Wesley. Pohl, K., 2010. Requirements engineering: Fundamentals, principles, and techniques. Springer. Robertson, S. and Robertson, J., 2012. Mastering the requirements process: Getting requirements right. 3rd ed. Addison-Wesley. Sommerville, I., 2011. Software engineering. 9th ed. Addison-Wesley. Wiegers, K. and Beatty, J., 2013. Software requirements. 3rd ed. Microsoft Press. Page 9