Software Engineering Lecture 01 PDF

Software Engineering Lecture 01: Introduction Muhammad Haggag, Ph.D. Computer Science Department Faculty of Computers and Information Mansoura University Fall 2024 Course outline Chapter 1: Introduction Chapter 2: Software Processes Chapter 3: Agile Software Development Chapter 4: Requirements Engineering Chapter 5: System Modeling Chapter 6: Architectural Design Brief description of each chapter Chapter 1: Introduction Introduces software engineering, its significance, history, and key concepts. Explains the differences between software engineering and traditional engineering, emphasizing software quality and maintenance. Chapter 2: Software Processes Explores various software development processes and methodologies, such as the Waterfall model and iterative approaches. Discusses stages of development, including planning, coding, testing, and maintenance, highlighting the importance of a structured process. Chapter 3: Agile Software Development It explains key Agile frameworks, such as Scrum and Kanban, and discusses their principles and practices. The chapter highlights the benefits of Agile approaches, including faster delivery of features, responsiveness to change, and improved stakeholder engagement. 3 Brief description of each chapter Chapter 4: Requirements Engineering Examines the process of gathering, analyzing, and validating software requirements. Discusses techniques for eliciting functional and non- functional requirements, emphasizing clear documentation and stakeholder involvement. Chapter 5: System Modeling Covers modeling techniques used to represent software systems, particularly using UML. Discusses various diagrams (e.g., use case, class, sequence) that help visualize system architecture and behavior for better communication among stakeholders. Chapter 6: Architectural Design Focuses on defining the high-level structure of a software system. Discusses architectural patterns (e.g., layered architecture, microservices, client-server), and trade-offs, emphasizing the alignment of architecture with both functional and non-functional requirements for quality and scalability. 4 Topics covered Professional software development What is meant by software engineering. Case studies An introduction to three examples that are used in later chapters in the book. 5 Software engineering The economies of ALL developed nations are dependent on software. More and more systems are software controlled. Software engineering is concerned with theories, methods and tools for professional software development. Expenditure on software represents a significant fraction of the Gross National Product (GNP) in all developed countries. 6 Software costs Software costs often dominate computer system costs. The costs of software on a PC are often greater than the hardware cost. Software costs more to maintain than it does to develop. For systems with a long life, maintenance costs may be several times development costs. Software engineering is concerned with cost-effective software development. 7 Software project failure Increasing system complexity As new software engineering techniques help us to build larger, more complex systems, the demands change. Systems have to be built and delivered more quickly; larger, even more complex systems are required; systems have to have new capabilities that were previously thought to be impossible. Failure to use software engineering methods It is fairly easy to write computer programs without using software engineering methods and techniques. Many companies have drifted into software development as their products and services have evolved. They do not use software engineering methods in their everyday work. Consequently, their software is often more expensive and less reliable than it should be. 8 Professional software development refers to the disciplined process of creating software applications that meet specific requirements and quality standards. 9 Frequently asked questions about software engineering Question Answer What is software? Computer programs and associated documentation. Software products may be developed for a particular customer or may be developed for a general market. What are the attributes of good software? Good software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable. What is software engineering? Software engineering is an engineering discipline that is concerned with all aspects of software production. What are the fundamental software Software specification, software development, software engineering activities? validation and software evolution. What is the difference between software Computer science focuses on theory and fundamentals; engineering and computer science? software engineering is concerned with the practicalities of developing and delivering useful software. What is the difference between software System engineering is concerned with all aspects of engineering and system engineering? computer-based systems development including hardware, software and process engineering. Software engineering is part of this more general process. 10 Frequently asked questions about software engineering Question Answer What are the key challenges facing Coping with increasing diversity, demands for reduced software engineering? delivery times and developing trustworthy software. What are the costs of software Roughly 60% of software costs are development costs, engineering? 40% are testing costs. For custom software, evolution costs often exceed development costs. What are the best software engineering While all software projects have to be professionally techniques and methods? managed and developed, different techniques are appropriate for different types of system. For example, games should always be developed using a series of prototypes whereas safety critical control systems require a complete and analyzable specification to be developed. You can’t, therefore, say that one method is better than another. What differences has the web made to The web has led to the availability of software services software engineering? and the possibility of developing highly distributed service- based systems. Web-based systems development has led to important advances in programming languages and software reuse. 11 Software products Generic products Stand-alone systems that are marketed and sold to any customer who wishes to buy them. Examples – PC software such as graphics programs, project management tools; CAD software; software for specific markets such as appointments systems for dentists. CAD (Computer-Aided Design) software is a type of application used for creating precise drawings, models, and designs in various fields, including engineering, architecture, and manufacturing. Customized products Software that is commissioned by a specific customer to meet their own needs. Examples – embedded control systems, air traffic control software, traffic monitoring systems. Embedded control systems are specialized computing systems that are designed to perform dedicated functions within larger mechanical or electrical systems. They typically consist of hardware and software that work together to control devices and processes. 12 Product specification Generic products The specification of what the software should do is owned by the software developer and decisions on software change are made by the developer. Example: Microsoft Office Suite Customized products The specification of what the software should do is owned by the customer for the software and they make decisions on software changes that are required. Example: Custom Enterprise Resource Planning (ERP) System 13 Essential attributes of good software Product characteristic Description Maintainability Software should be written in such a way so that it can evolve to meet the changing needs of customers. This is a critical attribute because software change is an inevitable requirement of a changing business environment. Dependability and Software dependability includes a range of characteristics security including reliability, security and safety. Dependable software should not cause physical or economic damage in the event of system failure. Malicious users should not be able to access or damage the system. Efficiency Software should not make wasteful use of system resources such as memory and processor cycles. Efficiency therefore includes responsiveness, processing time, memory utilisation, etc. Acceptability Software must be acceptable to the type of users for which it is designed. This means that it must be understandable, usable and compatible with other systems that they use. 14 Software engineering Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use. Key Aspects of Software Engineering Engineering discipline Using appropriate theories and methods to solve problems bearing in mind organizational and financial constraints. All aspects of software production Not just technical process of development. Also project management and the development of tools, methods etc. to support software production. 15 Importance of software engineering More and more, individuals and society rely on advanced software systems. We need to be able to produce reliable and trustworthy systems economically and quickly. [Societal Impact] It is usually cheaper, in the long run, to use software engineering methods and techniques for software systems rather than just write the programs as if it was a personal programming project. For most types of system, the majority of costs are the costs of changing the software after it has gone into use. [Cost of Changes] 16 Software process activities Software specification, where customers and engineers define the software that is to be produced and the constraints on its operation. Software development, where the software is designed and programmed. Software validation, where the software is checked to ensure that it is what the customer requires. Software evolution, where the software is modified to reflect changing customer and market requirements. 17 General issues that affect software Heterogeneity [diversity] Increasingly, systems are required to operate as distributed systems across networks that include different types of computer and mobile devices. Business and social change Business and society are changing incredibly quickly as emerging economies develop and new technologies become available. They need to be able to change their existing software and to rapidly develop new software. 18 General issues that affect software Security and trust As software is intertwined with all aspects of our lives, it is essential that we can trust that software. Scale Software has to be developed across a very wide range of scales, from very small embedded systems in portable or wearable devices through to Internet-scale, cloud-based systems that serve a global community. 19 Software engineering diversity There are many different types of software system and there is no universal set of software techniques that is applicable to all of these. The software engineering methods and tools used depend on the type of application being developed, the requirements of the customer and the background of the development team. 20 Application types Stand-alone applications [Microsoft Word] These are application systems that run on a local computer, such as a PC. They include all necessary functionality and do not need to be connected to a network. Interactive transaction-based applications [Online Banking Application] Applications that execute on a remote computer and are accessed by users from their own PCs or terminals. These include web applications such as e-commerce applications. Embedded control systems [Anti-Lock Braking System (ABS) in Vehicles] These are software control systems that control and manage hardware devices. Numerically, there are probably more embedded systems than any other type of system. 21 Application types Batch processing systems [Payroll Processing System] These are business systems that are designed to process data in large batches. They process large numbers of individual inputs to create corresponding outputs. Entertainment systems [Smart TV] These are systems that are primarily for personal use and which are intended to entertain the user. Systems for modelling and simulation [Flight Simulator] These are systems that are developed by scientists and engineers to model physical processes or situations, which include many, separate, interacting objects. 22 Application types Data collection systems [Survey and Feedback Tools (e.g., SurveyMonkey)] These are systems that collect data from their environment using a set of sensors and send that data to other systems for processing. Systems of systems These are systems that are composed of a number of other software systems. Ex., Healthcare Information Systems Components: Electronic Health Records (EHRs): Store and manage patient medical histories and data. Laboratory Information Systems (LIS): Manage lab tests and results. Telemedicine Platforms: Enable remote consultations between patients and healthcare providers. 23 End of Lecture 01 2024-10-12 24 Software engineering fundamentals Some fundamental principles apply to all types of software system, irrespective of the development techniques used: Systems should be developed using a managed and understood development process. Of course, different processes are used for different types of software. Dependability and performance are important for all types of system. Understanding and managing the software specification and requirements (what the software should do) are important. Where appropriate, you should reuse software that has already been developed rather than write new software. 25 Internet software engineering The Web is now a platform for running application and organizations are increasingly developing web-based systems rather than local systems. Cloud computing is an approach to the provision of computer services where applications run remotely on the ‘cloud’. Users do not buy software buy pay according to use. 26 Web-based software engineering Web-based systems are complex distributed systems but the fundamental principles of software engineering discussed previously are as applicable to them as they are to any other types of system. The fundamental ideas of software engineering apply to web- based software in the same way that they apply to other types of software system. 27 Web software engineering Software reuse Software reuse is the dominant approach for constructing web-based systems. When building these systems, you think about how you can assemble them from pre-existing software components and systems. Incremental and agile development Web-based systems should be developed and delivered incrementally. It is now generally recognized that it is impractical to specify all the requirements for such systems in advance. 28 Web software engineering Service-oriented systems [Loose Coupling] Software may be implemented using service-oriented software engineering, where the software components are stand-alone web services. Rich interfaces [Dynamic Content] Interface development technologies such as AJAX (Asynchronous JavaScript and XML) and HTML5 have emerged that support the creation of rich interfaces within a web browser. 29 Case studies 30 Case studies A personal insulin pump An embedded system in an insulin pump used by diabetics to maintain blood glucose control. A mental health case patient management system Mentcare. A system used to maintain records of people receiving care for mental health problems. 31 Insulin pump control system Collects data from a blood sugar sensor and calculates the amount of insulin required to be injected. Calculation based on the rate of change of blood sugar levels. Sends signals to a micro-pump to deliver the correct dose of insulin. Safety-critical system as low blood sugars can lead to brain malfunctioning, coma and death; high-blood sugar levels have long-term consequences such as eye and kidney damage. 32 Insulin pump hardware architecture 33 Activity model of the insulin pump Activity Models focus on the sequence of activities and interactions within a process. Data Flow Diagrams focus on the movement of data and its processing within a system. 34 Essential high-level requirements The system shall be available to deliver insulin when required. The system shall perform reliably and deliver the correct amount of insulin to counteract the current level of blood sugar. The system must therefore be designed and implemented to ensure that the system always meets these requirements. 35 https://shorturl.at/nx6nD 36 Thank you 37 Software Engineering Lecture 02: Software Processes Muhammad Haggag, Ph.D. Computer Science Department Faculty of Computers and Information Mansoura University Fall 2024 Topics covered Software process models Process activities Coping with change 2 The software process A structured set of activities required to develop a software system. Many different software processes but all involve: Specification – involves defining the functionality and any constraints on its operation; Design and implementation – defining the organization of the system and implementing the system; Validation – checking that it does what the customer wants; Evolution – changing the system in response to changing customer needs. A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. 3 Software process descriptions When we describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing a user interface, etc. and the ordering of these activities. Process descriptions may also include: Products, which are the outcomes of a process activity; Roles, which reflect the responsibilities of the people involved in the process; Pre- and post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced. 4 Plan-driven and agile processes Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan. In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements. In practice, most practical processes include elements of both plan-driven and agile approaches. There are no right or wrong software processes. No One-Size-Fits-All: There is no universally "right" or "wrong" software process. The effectiveness of a particular approach depends on the project context, team dynamics, and customer needs. Choosing the Right Approach: Organizations should evaluate their projects and environments to determine the best blend of plan-driven and agile practices, leveraging the strengths of each to achieve successful outcomes. 5 Software process models 6 Software process models The waterfall model Plan-driven model. Separate and distinct phases of specification and development. Incremental development Specification, development and validation are interleaved. May be plan- driven or agile. Integration and configuration The system is assembled from existing configurable components. May be plan-driven or agile. In practice, most large systems are developed using a process that incorporates elements from all of these models. 7 The waterfall model 8 Waterfall model phases There are separate identified phases in the waterfall model: Requirements analysis and definition Establishes the system's services, constraints, and goals through consultations with users. System and software design Allocates requirements to hardware and software, establishing the overall system architecture. Implementation and unit testing Translates the software design into actual programs or units. Integration and system testing Integrates individual units or programs into a complete system. Operation and maintenance Represents the longest phase, where the system is installed and used in practice. The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. In principle, a phase has to be complete before moving onto the next phase. 9 Waterfall model problems Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. Therefore, this model is only appropriate when the requirements are well- understood and changes will be fairly limited during the design process. Few business systems have stable requirements. 10 Incremental development 11 Example Project: Online Bookstore Incremental Development Goal: Develop an online bookstore in increments. Increment 1: Basic User Authentication Tasks: Create a login and registration page. Increment 2: Product Catalog Tasks: Implement a product listing page to display books with titles, authors, and prices. Increment 3: Shopping Cart Tasks: Add functionality to allow users to add books to a shopping cart and view their selections. Increment 4: Checkout Process Tasks: Implement payment processing and order confirmation. Concurrent Activities Team Structure: Frontend Team: Works on user interface design and implementation. Backend Team: Handles server-side logic and database interactions. QA Team: [Quality Assurance] Conducts testing on features as they’re completed. Concurrent Tasks: While the Frontend Team is working on the product catalog, the Backend Team can develop the API for fetching book data. Meanwhile, the QA Team prepares test cases for user authentication. Incremental Development: Feedback is typically gathered after each increment is completed, influencing future increments. Agile Development: Feedback is collected continuously and can lead to immediate adjustments within the same sprint. 12 Incremental development benefits The cost of accommodating changing customer requirements is reduced. The amount of analysis and documentation that has to be redone is much less than is required with the waterfall model. It is easier to get customer feedback on the development work that has been done. Customers can comment on demonstrations of the software and see how much has been implemented. More rapid delivery and deployment of useful software to the customer is possible. Customers are able to use and gain value from the software earlier than is possible with a waterfall process. 13 Incremental development problems The process is not visible. Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system. System structure tends to degrade as new increments are added. Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly. Refactoring refers to the process of restructuring existing code without changing its external behavior. The primary goal of refactoring is to improve the code's internal structure, making it cleaner, more efficient, and easier to understand and maintain. 14 Integration and configuration Based on software reuse where systems are integrated from existing components or application systems (sometimes called COTS -Commercial-off-the-shelf) systems). Reused elements may be configured to adapt their behaviour and functionality to a user’s requirements Reuse is now the standard approach for building many types of business system. 15 Types of reusable software Stand-alone application systems (sometimes called COTS) that are configured for use in a particular environment. Microsoft Office Suite - These applications can be configured for specific user needs (e.g., setting up templates, customizing toolbars) Collections of objects that are developed as a package to be integrated with a component framework such as.NET or J2EE. Web services that are developed according to service standards and which are available for remote invocation. Amazon Web Services (AWS). AWS provides a range of web services, such as Amazon S3 (for storage) and Amazon EC2 (for computing). 16 Reuse-oriented software engineering 17 Key process stages Requirements specification Software discovery and evaluation Requirements refinement Application system configuration There is an off-the-shelf application system that meets the requirements is available Component adaptation and integration There is no off-the-shelf system. 18 Advantages and disadvantages Reduced costs and risks as less software is developed from scratch Faster delivery and deployment of system But requirements compromises are inevitable so system may not meet real needs of users Loss of control over evolution of reused system elements refers to the challenges and risks associated with integrating and relying on external or previously developed components in software systems. Incompatibility Issues: As the reused components evolve independently, they may become incompatible with other parts of the system or with newer technologies Vendor Lock-In: making it difficult for organizations to switch to alternative solutions if they need to change direction or if the vendor's offerings no longer meet their needs. Impact on Development Agility: The need to manage external components can slow down development processes. Teams may need to spend additional time coordinating updates and ensuring compatibility rather than focusing on building new features. 19 End of Lecture 02 2024-10-20 20 Process activities Process Activities: Concerned with the specific tasks performed during development. Software Process Models: Concerned with the overall framework and structure for managing those tasks. 21 Process activities Real software processes are inter-leaved sequences of technical, collaborative and managerial activities with the overall goal of specifying, designing, implementing and testing a software system. The four basic process activities of specification, development, validation and evolution are organized differently in different development processes. For example, in the waterfall model, they are organized in sequence, whereas in incremental development they are interleaved. 22 The requirements engineering process 23 Software specification The process of establishing what services are required and the constraints on the system’s operation and development. Requirements engineering process Requirements elicitation and analysis What do the system stakeholders require or expect from the system? Conduct interviews, surveys, and workshops with stakeholders. Requirements specification Defining the requirements in detail Create specifications that outline functional and non-functional requirements, user stories, or use cases. Requirements validation Checking the validity of the requirements Perform testing or validation methods (e.g., prototyping , model validation ) to confirm requirements are feasible and achievable. 24 Requirements vs Specification Requirements focus on what the system should achieve. Customer need Specification focuses on how those requirements will be fulfilled Technical description Example 1: User Authentication System Requirements: The system shall allow users to create an account using an email address and password. UML used: Use Case, Activity Diagrams Specification: 1. Account Creation: 1. Input: User inputs email and password. 2. Output: A confirmation email is sent to the user. 3. Validation: Email must be in a valid format, and password must meet complexity requirements (at least 8 characters, one uppercase letter, one number). UML used: Class, Sequence, Component Diagrams 25 Software design and implementation The process of converting the system specification into an executable system. Software design Design a software structure that realises the specification; Create design diagrams (e.g., UML diagrams) to visualize the system's structure. Implementation Translate this structure into an executable program; Write the actual source code based on the design specifications. The activities of design and implementation are closely related and may be inter-leaved. 26 A general model of the design process 27 Design activities Architectural design, where you identify the overall structure of the system, the principal components (subsystems or modules), their relationships and how they are distributed. Online Bookstore System : User Interface Module/Catalog Module/Order Processing Module Database design, where you design the system data structures and how these are to be represented in a database. Users / Books / Orders tables Interface design, where you define the interfaces between system components. Interface between User Interface Module and Catalog Module: Method: getBookList() - Parameters: None - Response: List of available books with details (ID, title, price). Component selection and design, where you search for reusable components. If unavailable, you design how it will operate. Reusable Component: Use a third-party payment processing API (e.g., Stripe) for handling payments. New Component: Design an Inventory Management Component to track stock levels and manage reordering. 28 System implementation The software is implemented either by developing a program or programs or by configuring an application system. Design and implementation are interleaved activities for most types of software system. Programming is an individual activity with no standard process. Debugging is the activity of finding program faults and correcting these faults. 29 Software validation Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer. Involves checking and review processes and system testing. System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system. Testing is the most commonly used V & V activity. 30 Stages of testing 31 Testing stages Component testing Individual components are tested independently; Components may be functions or objects or coherent groupings of these entities. System testing Testing of the system as a whole. Testing of emergent properties is particularly important. Customer testing Testing with customer data to check that the system meets the customer’s needs. 32 Testing phases in a plan-driven software process (V-model) 33 Software evolution Software is inherently flexible and can change. As requirements change through changing business circumstances, the software that supports the business must also evolve and change. Although there has been a demarcation‫ ترسيم الحدود‬between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new. Technology Trends: The shift to microservices allows for more flexible evolution of applications instead of creating entirely new ones. Rapid Prototyping: Creating prototypes and iterating based on user interaction often leads to significant changes. Organizations focus on refining what they have, leading to fewer brand-new systems Refactoring: Refactoring existing code [Legacy system] for better performance or scalability is a common practice, effectively turning maintenance activities into new development efforts. 34 System evolution Rather than two separate processes, it is more realistic to think of software engineering as an evolutionary process Continuous Evolution: Ongoing Changes: Software is not static; it continually evolves to meet changing requirements, adapt to new technologies, and address user feedback. This makes maintenance an integral part of the software lifecycle. 35 36 Coping with change 37 Coping with change Change is inevitable in all large software projects. Business changes lead to new and changed system requirements New technologies open up new possibilities for improving implementations Changing platforms require application changes Change leads to rework so the costs of change include both rework (e.g. re-analysing requirements) as well as the costs of implementing new functionality 38 Reducing the costs of rework Change anticipation, where the software process includes activities that can anticipate possible changes before significant rework is required. For example, a prototype system may be developed to show some key features of the system to customers. Change tolerance, where the process is designed so that changes can be accommodated at relatively low cost. This normally involves some form of incremental development. Proposed changes may be implemented in increments that have not yet been developed. If this is impossible, then only a single increment (a small part of the system) may have be altered to incorporate the change. 39 Coping with changing requirements System prototyping, where a version of the system or part of the system is developed quickly to check the customer’s requirements and the feasibility of design decisions. This approach supports change anticipation. Incremental delivery, where system increments are delivered to the customer for comment and experimentation. This supports both change avoidance and change tolerance. 40 Software prototyping A prototype is an initial version of a system used to demonstrate concepts and try out design options. A prototype can be used in: The requirements engineering process to help with requirements elicitation and validation; In design processes to explore options and develop a UI design; In the testing process to run back-to-back tests. 41 Benefits of prototyping Improved system usability. A closer match to users’ real needs. Improved design quality. Improved maintainability. Reduced development effort. 42 The process of prototype development 43 Prototype development May be based on rapid prototyping languages or tools May involve leaving out functionality Prototype should focus on areas of the product that are not well- understood; Error checking and recovery may not be included in the prototype; Focus on functional rather than non-functional requirements such as reliability and security 44 Throw-away prototypes Prototypes should be discarded after development as they are not a good basis for a production system: It may be impossible to tune the system to meet non-functional requirements; Prototypes are normally undocumented; The prototype structure is usually degraded through rapid change; The prototype probably will not meet normal organisational quality standards. 45 Incremental delivery Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. User requirements are prioritised and the highest priority requirements are included in early increments. Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve. 46 https://shorturl.at/nx6nD 47 Thank you 48 Software Engineering Lecture 03: Software Processes-2 Muhammad Haggag, Ph.D. Computer Science Department Faculty of Computers and Information Mansoura University Fall 2024 Topics covered Software process models Process activities Coping with change 22 Process activities Process Activities: Concerned with the specific tasks performed during development. Software Process Models: Concerned with the overall framework and structure for managing those tasks. 23 Process activities Real software processes are inter-leaved sequences of technical, collaborative and managerial activities with the overall goal of specifying, designing, implementing and testing a software system. The four basic process activities of specification, development, validation and evolution are organized differently in different development processes. For example, in the waterfall model, they are organized in sequence, whereas in incremental development they are interleaved. 24 The requirements engineering process 25 Software specification The process of establishing what services are required and the constraints on the system’s operation and development. Requirements engineering process Requirements elicitation and analysis What do the system stakeholders require or expect from the system? Conduct interviews, surveys, and workshops with stakeholders. Requirements specification Defining the requirements in detail Create specifications that outline functional and non-functional requirements, user stories, or use cases. Requirements validation Checking the validity of the requirements Perform testing or validation methods (e.g., prototyping , model validation ) to confirm requirements are feasible and achievable. 26 Requirements vs Specification Requirements focus on what the system should achieve. Customer need Specification focuses on how those requirements will be fulfilled Technical description Example 1: User Authentication System Requirements: The system shall allow users to create an account using an email address and password. UML used: Use Case, Activity Diagrams Specification: Account Creation: 1. Input: User inputs email and password. 2. Output: A confirmation email is sent to the user. 3. Validation: Email must be in a valid format, and password must meet complexity requirements (at least 8 characters, one uppercase letter, one number). UML used: Class, Sequence, Component Diagrams 27 Software design and implementation The process of converting the system specification into an executable system. Software design Design a software structure that realises the specification; Create design diagrams (e.g., UML diagrams) to visualize the system's structure. Implementation Translate this structure into an executable program; Write the actual source code based on the design specifications. The activities of design and implementation are closely related and may be inter-leaved. 28 A general model of the design process 29 Design activities Architectural design, where you identify the overall structure of the system, the principal components (subsystems or modules), their relationships and how they are distributed. Online Bookstore System : User Interface Module/Catalog Module/Order Processing Module Database design, where you design the system data structures and how these are to be represented in a database. Users / Books / Orders tables Interface design, where you define the interfaces between system components. Interface between User Interface Module and Catalog Module: Method: getBookList() - Parameters: None - Response: List of available books with details (ID, title, price). Component selection and design, where you search for reusable components. If unavailable, you design how it will operate. Reusable Component: Use a third-party payment processing API (e.g., Stripe) for handling payments. New Component: Design an Inventory Management Component to track stock levels and manage reordering. 30 System implementation The software is implemented either by developing a program or programs or by configuring an application system. Design and implementation are interleaved activities for most types of software system. rapid adjustments based on testing and feedback, Programming is an individual activity with no standard process. While programming can be collaborative, it often involves personal coding tasks where developers write and debug their own code. Programming practices can vary significantly between individuals and teams, leading to diverse coding styles and methodologies. Debugging is the activity of finding program faults and correcting these faults. 31 Software validation Verification and validation (V & V) is intended to show that a system conforms ‫ يتوافق‬to its specification and meets the requirements of the system customer. Verification: Ensures the product is built according to specifications (are we building the product right?). Validation: Ensures the product meets user needs and requirements (are we building the right product?). Involves checking and review processes (without executing it), and system testing. System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system. Testing is the most commonly used V & V activity. 32 Stages of testing 33 Testing stages Component testing Individual components are tested independently; Components may be functions or objects or coherent groupings of these entities. System testing Testing of the system as a whole. Testing of emergent properties is particularly important. System Testing is typically performed by QA teams in a controlled testing environment. Customer testing Testing with customer data (Also known as user acceptance testing UAT) to check that the system meets the customer’s needs. (Validation) Customer Testing involves actual users in real-world scenarios and environments. 34 Testing phases in a plan-driven software process (V-model) Verification and Validation: The left side of the "V" represents verification activities (requirements, design, and coding), The right side represents validation activities (integration testing, system testing, and acceptance testing). 35 Software evolution Software is inherently flexible and can change. As requirements change through changing business circumstances, the software that supports the business must also evolve and change. Although there has been a demarcation ‫ ترسيم الحدود‬between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new. Technology Trends: The shift to microservices allows for more flexible evolution of applications instead of creating entirely new ones. Rapid Prototyping: Creating prototypes and iterating based on user interaction often leads to significant changes. Organizations focus on refining what they have, leading to fewer brand-new systems Refactoring: Refactoring existing code [Legacy system] for better performance or scalability is a common practice, effectively turning maintenance activities into new development efforts. 36 System evolution Rather than two separate processes, it is more realistic to think of software engineering as an evolutionary process Continuous Evolution: Ongoing Changes: Software is not static; it continually evolves to meet changing requirements, adapt to new technologies, and address user feedback. This makes maintenance an integral part of the software lifecycle. 37 Coping with change 38 Coping with change Change is inevitable in all large software projects. Business changes lead to new and changed system requirements New technologies open up new possibilities for improving implementations Changing platforms require application changes Change leads to rework so the costs of change include both rework (e.g. re-analysing requirements) as well as the costs of implementing new functionality 39 Reducing the costs of rework Change anticipation ‫توقع‬, where the software process includes activities that can anticipate possible changes before significant rework is required. For example, a prototype system may be developed to show some key features of the system to customers. Change tolerance ‫تحمل‬, where the process is designed so that changes can be accommodated with minimal disruption and cost. This normally involves some form of incremental development. Proposed changes may be implemented in increments that have not yet been developed. 40 Coping with changing requirements System prototyping, where a version of the system or part of the system is developed quickly to check the customer’s requirements and the feasibility of design decisions. This approach supports change anticipation. Incremental delivery, where system increments are delivered to the customer for comment and experimentation. This supports both change avoidance and change tolerance. 41 Software prototyping A prototype is an initial version of a system used to demonstrate concepts and try out design options. A prototype can be used in: The requirements engineering process to help with requirements elicitation and validation; In design processes to explore options and develop a UI design; In the testing process to run back-to-back tests. 42 Benefits of prototyping Improved system usability. A closer match to users’ real needs. Improved design quality. Improved maintainability. Reduced development effort. 43 The process of prototype development 44 Prototype development May be based on rapid prototyping languages or tools May involve leaving out functionality Prototype should focus on areas of the product that are not well- understood; Error checking and recovery may not be included in the prototype; Focus on functional rather than non-functional requirements such as reliability and security 45 Prototype Models Types 1. Throwaway/Rapid Prototyping Description: A quick, low-fidelity prototype created to visualize and test concepts or features. Once feedback is gathered, it is discarded, and the actual system is developed based on the insights gained. Use Case: Useful for clarifying requirements and exploring design ideas without the need for detailed specifications. 2. Incremental Prototyping Description: The final system is built as separate prototypes, or increments, which are developed and integrated over time. Each increment represents a portion of the final product, allowing for early delivery of functional components. Use Case: Suitable for large systems where different features can be developed and tested independently before integration. 46 Prototype Models Types 3. High-Fidelity Prototyping Description: A prototype that closely resembles the final product in terms of design, functionality, and user interface. It is usually interactive and provides a realistic user experience. Use Case: Useful for testing specific features or user interactions in detail, often used in usability testing. 4. Low-Fidelity Prototyping Description: Often consists of sketches, wireframes, or basic mockups that convey layout and functionality without detailed design or interactivity. Use Case: Great for early-stage brainstorming and gathering initial feedback on concepts without extensive investment in development. 47 Always start with low fidelity 48 Throw-away prototypes Prototypes should be discarded after development as they are not a good basis for a production system: It may be impossible to tune the system to meet non-functional requirements; Prototypes are normally undocumented; The prototype structure is usually degraded through rapid change; The prototype probably will not meet normal organizational quality standards. 49 https://shorturl.at/nx6nD 50 Thank you 51 Software Engineering Lecture 04: Agile Software Development Muhammad Haggag, Ph.D. Computer Science Department Faculty of Computers and Information Mansoura University Fall 2024 Topics covered Agile methods Agile development techniques Agile project management Scaling agile methods 2 Rapid software development Rapid development and delivery is now often the most important requirement for software systems Businesses operate in a fast –changing requirement and it is practically impossible to produce a set of stable software requirements Software has to evolve quickly to reflect changing business needs. Plan-driven development is essential for some types of system but does not meet these business needs. Agile development methods emerged in the late 1990s whose aim was to radically reduce the delivery time for working software systems 3 Agile development Program specification, design and implementation are inter- leaved The system is developed as a series of versions or increments with stakeholders involved in version specification and evaluation Frequent delivery of new versions for evaluation Extensive tool support (e.g. automated testing tools) used to support development. Automated Testing Tools: Tools like Selenium for UI testing or [JUnit for unit testing in Java applications], enable the team to quickly validate changes with each new version. Minimal documentation – focus on working code 4 Plan-driven and agile development 5 Plan-driven and agile development Plan-driven development A plan-driven approach to software engineering is based around separate development stages with the outputs to be produced at each of these stages planned in advance. Sequential Stages: Development is organized into distinct stages, such as requirements gathering, design, implementation, testing, and deployment. Risk Management: Extensive upfront planning allows for identifying and mitigating risks early in the project. Not necessarily waterfall model – plan-driven, incremental development is possible The system is divided into smaller modules or increments, with each module representing a functional piece of the overall system. Each increment can follow the waterfall process individually. Iteration occurs within activities. E.g.: Refinement of Requirements: During the requirements analysis phase, teams can iteratively refine requirements through ongoing discussions with stakeholders. Prototyping: Creating prototypes or mock-ups can help clarify requirements and gather feedback early in the process, leading to iterations in the requirements themselves. 6 Plan-driven and agile development Agile development Specification, design, implementation and testing are inter-leaved and the outputs from the development process are decided through a process of negotiation during the software development process. In Agile, specification, design, implementation, and testing are not treated as distinct, sequential phases. Instead, they occur concurrently within short cycles called sprints. This means that feedback from testing can influence ongoing development and design work. 7 Agile methods 8 Agile methods Dissatisfaction with the overheads ‫ النفقات‬involved in software design methods of the 1980s and 1990s led to the creation of agile methods. These methods: Focus on the code rather than the design Solve: Complex design specifications can be hard to manage. Are based on an iterative approach to software development Solve: Slow delivery Are intended to deliver working software quickly and evolve this quickly to meet changing requirements. Solve: Inflexibility The aim of agile methods is to reduce overheads in the software process (e.g. by limiting documentation) and to be able to respond quickly to changing requirements without excessive rework. 9 Agile manifesto ‫بيان‬ We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools o While processes and tools are important, they should not overshadow ‫ يطغى على‬personal interactions. how the team works together. Working software over comprehensive documentation o Focuses on delivering functional software that meets user needs. Customer collaboration over contract negotiation o Build ongoing relationship with the customer, instead of focusing on formal contract terms. how the team works with the customer. Responding to change over following a plan o Adapt to change as it arises, rather than rigidly sticking to a predefined plan. That is, while there is value in the items on the right, we value the items on the left more. The Agile Manifesto, created in 2001 by a group of software developers, outlines the core values and principles of Agile software development. 10 The principles of agile methods Principle Description Customer involvement Customers should be closely involved throughout the development process. Their role is provide and prioritize new system requirements and to evaluate the iterations of the system. Incremental delivery The software is developed in increments with the customer specifying the requirements to be included in each increment. People not process The skills of the development team should be recognized and exploited. Team members should be left to develop their own ways of working without prescriptive processes. Embrace ‫ تقبل‬change Expect the system requirements to change and so design the system to accommodate these changes. Maintain simplicity Focus on simplicity in both the software being developed and in the development process. Wherever possible, actively work to eliminate complexity from the system. 11 Agile method applicability Product development where a software company is developing a small or medium-sized product for sale. Virtually all software products and apps are now developed using an agile approach Custom system development within an organization, where there is a clear commitment from the customer to become involved in the development process and where there are few external rules and regulations that affect the software. Examples of Software with Heavy External Rules and Regulations Financial Services Software: payment security and AML (Anti-Money Laundering) laws. Healthcare Software: patient privacy and data security Examples of Software with Low External Rules and Regulations Tailored to meet specific organizational needs, and the company can decide on its functionalities, design, and deployment without strict external regulations. Internal Business Applications 12 Agile development techniques 13 Extreme programming A very influential agile method, developed in the late 1990s, that introduced a range of agile development techniques. Extreme Programming (XP) takes an ‘extreme’ approach to iterative development. New versions may be built several times per day; Increments are delivered to customers every 2 weeks; All tests must be run for every build and the build is only accepted if tests run successfully. Benefits of XP Higher Quality Software: Through continuous testing, XP helps maintain a high level of code quality. Adaptability: Frequent releases and customer collaboration allow teams to respond quickly to changing requirements. 14 The extreme programming release cycle 15 Extreme programming practices (a) Principle or practice Description Incremental planning Requirements are recorded on story cards and the stories to be included in a release are determined by the time available and their relative priority. The developers break these stories into development ‘Tasks’. Small releases The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release. Simple design Enough design is carried out to meet the current requirements and no more. Test-first development An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented. Refactoring All developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable. 16 Extreme programming practices (b) Pair programming Developers work in pairs, checking each other’s work and providing the support to always do a good job. Collective ownership The pairs of developers work on all areas of the system, so that no islands of expertise develop, and all the developers take responsibility for all of the code. Anyone can change anything. Continuous integration As soon as the work on a task is complete, it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. Sustainable pace Large amounts of overtime are not considered acceptable as ‫الوتيرة المستدامة‬ the net effect is often to reduce code quality and medium term productivity On-site customer A representative of the end-user of the system (the customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation. 17 XP and agile principles Incremental development is supported through small, frequent system releases. [System → smaller modules] Customer involvement means full-time customer engagement with the team. People not process through pair programming, collective ownership and a process that avoids long working hours (Pace). Change supported through regular system releases. [Feedback] Maintaining simplicity through constant refactoring of code. 18 https://shorturl.at/nx6nD 19 Thank you 20 Software Engineering Lecture 05: Agile Software Development-2 Muhammad Haggag, Ph.D. Computer Science Department Faculty of Computers and Information Mansoura University Fall 2024 Influential XP practices Extreme programming has a technical focus and is not easy to integrate with management practice in most organizations. Consequently, while agile development uses practices from XP, the method as originally defined is not widely used. Key practices 1. User stories for specification 2. Refactoring 3. Test-first development 4. Pair programming 22 1. User stories for requirements In XP, a customer or user is part of the XP team and is responsible for making decisions on requirements. User requirements are expressed as user stories or scenarios. These are written on cards and the development team break them down into implementation tasks. These tasks are the basis of schedule and cost estimates. The customer chooses the stories for inclusion in the next release based on their priorities and the schedule estimates. Customer as Part of the Team Decision-Making Responsibility 23 A ‘prescribing medication’ story 24 Examples of task cards for prescribing medication 25 2. Refactoring Conventional wisdom in software engineering is to design for change. It is worth spending time and effort anticipating ‫توقع‬ changes as this reduces costs later in the life cycle. XP, however, maintains that this is not worthwhile as changes cannot be reliably anticipated. Instead of over-engineering for potential future changes, XP emphasizes addressing current requirements and delivering functional software quickly. Rather, it proposes constant code improvement (refactoring) to make changes easier when they have to be implemented. By refactoring regularly, the codebase remains clean, understandable, and flexible, facilitating future modifications. 26 Refactoring Programming team look for possible software improvements and make these improvements even where there is no immediate need for them. [Proactive] ‫استباقي‬ This improves the understandability of the software and so reduces the need for documentation. [logic and structure are apparent] Changes are easier to make because the code is well-structured and clear. [introduce confidence and speed, reducing the risk of introducing bugs] However, some changes requires architecture refactoring and this is much more expensive. Example: Monolithic ‫( العمارة االحادية‬single connected) architecture to a microservices architecture. Cost Consideration: This shift would require significant changes to the system’s core, including how data is stored and how services communicate. These changes could be expensive because they require a complete redesign of the system’s structure. 27 Examples of refactoring Re-organization of a class hierarchy to remove duplicate code. [promote reusability via Inheritance] (classes) Tidying up ‫ تنظيم‬and renaming attributes and methods to make them easier to understand. [understand the code’s intent more quickly] The replacement of inline code with calls to methods that have been included in a program library. [Simplifies maintenance] (functions) 28 3. Test-first development Testing is central to XP and XP has developed an approach where the program is tested after every change has been made. XP testing features: Test-first development. It promotes writing just enough code to pass the test, avoiding unnecessary complexity. Incremental test development from scenarios. It ensures tests stay relevant and aligned with the project's goals. User involvement in test development and validation. This user-driven approach ensures the software meets user needs, minimizes requirement misunderstandings. Automated test harnesses are used to run all component tests each time that a new release is built. Automated testing offers quick feedback, preventing defects and enabling confident code refactoring with validated functionality. 29 Test-driven development Writing tests before code clarifies the requirements to be implemented. Tests are written as programs rather than data so that they can be executed automatically. The test includes a check that it has executed correctly. Usually relies on a testing framework such as Junit, Nunit, Selenium (Web Testing) All previous and new tests are run automatically when new functionality is added, thus checking that the new functionality has not introduced errors. assertEquals(expected, actual) JUnit Test Class Calculator Class 30 Customer involvement The role of the customer in the testing process is to help develop acceptance tests for the stories that are to be implemented in the next release of the system. (Participating in Test Planning) The customer who is part of the team writes tests as development proceeds. All new code is therefore validated to ensure that it is what the customer needs. It's not about verifying whether the system works—it’s about validating that the system meets customer needs. Customers typically have limited time and may hesitate to engage in the testing process, feeling that providing the initial requirements is sufficient. They may not see the value in further involvement and prefer not to dedicate additional time. Solution: Set clear expectations early on about the customer's role in testing and highlight the value of their feedback during the process. 31 Test case description for dose checking 32 Test Cases examples Total daily dosage (single dose × frequency) Assumed Safe Dosage Ranges: Safe single dose range: 50 mg to 200 mg Safe frequency range: 1 to 4 doses/day Safe total daily dosage: 50 mg/day to 800 mg/day 33 Test automation ‫أتمتة االختبارات‬ Test automation means that tests are written as executable components before the task is implemented These testing components should be stand-alone, should simulate the submission of input to be tested and should check that the result meets the output specification. An automated test framework (e.g. Junit) is a system that makes it easy to write executable tests and submit a set of tests for execution. As testing is automated, there is always a set of tests that can be quickly and easily executed Whenever any functionality is added to the system, the tests can be run and problems that the new code has introduced can be caught immediately. 34 Problems with test-first development Programmers prefer programming to testing and sometimes they take short cuts when writing tests. For example, they may write incomplete tests that do not check for all possible exceptions that may occur. Some tests can be very difficult to write incrementally. For example, in a complex user interface (buttons, forms, navigation, it is often difficult to write unit tests for the code that implements the ‘display logic’ and workflow between screens. It difficult to judge the completeness of a set of tests. Although you may have a lot of system tests, your test set may not provide complete coverage. Lack of Edge Case Testing: Many test suites may cover the common use cases well, but may miss out on edge cases Business Logic = Core rules, processes, and decisions that drive the functionality of the system. Display Logic = UI-related code that handles how data is shown to the user and how they interact with it. 35 4. Pair programming Pair programming involves programmers working in pairs, developing code together. Improved Code Quality This helps develop common ownership of code and spreads knowledge across the team. Knowledge Sharing It serves as an informal review process as each line of code is looked at by more than 1 person. Team Collaboration and Communication: Collaboration is working together on tasks, while Communication is sharing information. Example: The team collaborates on coding the feature and communicates through meetings to stay aligned. It encourages refactoring as the whole team can benefit from improving the system code. Refactoring and Code Improvement 36 Pair programming In pair programming, programmers sit together at the same computer to develop the software. One person is typically the "driver," responsible for writing the code, while the other is the "navigator," who reviews the work, offers suggestions. Pairs are created dynamically so that all team members work with each other during the development process. Dynamic pairing is essential for spreading knowledge across the team. The sharing of knowledge that happens during pair programming is very important as it reduces the overall risks to a project when team members leave. 37 https://shorturl.at/nx6nD 38 Thank you 39 Software Engineering Lecture 06: Requirements Engineering Muhammad Haggag, Ph.D. Computer Science Department Faculty of Computers and Information Mansoura University Fall 2024 Topics covered Functional and non-functional requirements Requirements engineering processes Requirements elicitation Requirements specification Requirements validation Requirements change Requirements engineering The process of establishing the services that a customer requires from a system and the constraints under which it operates and is developed. The system requirements are the descriptions of the system services and constraints that are generated during the requirements engineering process. System Services: Functional Requirements: What the system must do (e.g., allowing users to create and manage profiles, send messages). Non-Functional Requirements: How the system must perform (e.g., fast load times, high reliability, user-friendly design). System Constraints: Technical Constraints: Limitations based on hardware, software, or programming language (e.g., compatibility with specific OS or using certain technologies). Business Constraints: Limitations due to budget, time, or resources (e.g., budget of $500,000, project deadline of 6 months). What is a requirement? It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. This is inevitable as requirements may serve a dual function May be the basis for a bid ‫ مزايدة‬- ‫ تقديم عطاء‬for a contract - therefore must be open to interpretation; [Scalability in Terms of Users, Data, or Performance] May be the basis for the contract itself - therefore must be defined in detail; Both these statements may be called requirements. High-Level Detailed Requirements The system must be user-friendly. The system must handle 1000 simultaneous users The service should be scalable. with less than 2 seconds of response time. The application must be built using React for the frontend and Python for the backend. Requirements abstraction (Davis) “If a company (client) wishes to let a contract for a large software development project (seeking to hire a vendor), it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization’s needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.” The idea is that requirements evolve from high-level, abstract concepts to more specific and detailed specifications. Types of requirement User requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. Purpose: To outline the user needs and provide a general idea of what the system should do, without focusing on the technical implementation. Ex., "The system must provide a secure login for users." System requirements A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor. Purpose: To specify the technical and functional details of how the system will operate, and what the system must do, in a way that is precise and measurable. Ex., "The system must use AES-256 encryption for user data." User and system requirements Readers of different types of requirements specification Client Manager: Oversees ‫ يشرف على‬client needs, manage communication with contractors, and ensure project alignment with business goals. System End-User: The person who will use the system after deployment, providing input on functionality. Client Engineer: Assists in defining technical requirements and ensures the solution integrates with the client’s infrastructure. (validation) Contractor Manager: Manages the contractor team, ensuring the project is delivered on time, within budget, and to client specifications. System Architect: Designs the system structure, ensuring it meets technical and business requirements. Software Developer: Writes code, build features, and test the system based on requirements. 9 System stakeholders Any person or organization who is affected by the system in some way and so who has a legitimate ‫ شرعى‬interest Stakeholder types End users System managers System owners External stakeholders The organization of the Mentcare system 11 Stakeholders in the Mentcare system Patients whose information is recorded in the system. Doctors who are responsible for assessing and treating patients. Nurses who coordinate the consultations with doctors and administer some treatments. Medical receptionists who manage patients’ appointments. IT staff who are responsible for installing and maintaining the system. Stakeholders in the Mentcare system A medical ethics manager who must ensure that the system meets current ethical guidelines for patient care. Health care managers who obtain management information from the system. Medical records staff who are responsible for ensuring that system information can be maintained and preserved, and that record keeping procedures have been properly implemented. Agile methods and requirements Many agile methods argue ‫ تجادل‬that producing detailed system requirements is a waste of time as requirements change so quickly. The requirements document is therefore always out of date. Agile methods usually use incremental requirements engineering and may express requirements as ‘user stories’. This is practical for business systems but problematic for systems that require pre-delivery analysis (e.g. critical systems) or systems developed by several teams. Functional and non-functional requirements Functional and non-functional requirements Functional requirements Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. May state what the system should not do. Non-functional requirements Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Often apply to the system as a whole rather than individual features or services. Domain requirements Constraints on the system from the domain of operation Functional requirements Describe functionality or system services. Depend on the type of software, expected users and the type of system where the software is used. Functional user requirements may be high-level statements of what the system should do. Functional system requirements should describe the system services in detail. Mentcare system: functional requirements A user shall be able to search the appointments lists for all clinics. The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day. Each staff member using the system shall be uniquely identified by his or her 8-digit employee number. Requirements imprecision Problems arise when functional requirements are not precisely stated. Ambiguous requirements may be interpreted in different ways by developers and users. Example: Consider the term ‘search’ in requirement 1 User intention – search for a patient name across all appointments in all clinics; Developer interpretation – search for a patient name in an individual clinic. User chooses clinic then search. Requirements completeness and consistency In principle, requirements should be both complete and consistent. Complete They should include descriptions of all facilities required. Consistent There should be no conflicts or contradictions in the descriptions of the system facilities. In practice, because of system and environmental complexity, it is impossible to produce a complete and consistent requirements document. Completeness and Consistency Consider: Online Shopping System Complete Requirement (Ideal): "The system must allow users to register, browse products, add items to the shopping cart, checkout, and make payments." Incomplete Requirement (Real-world issue): "The system should allow users to browse products." Issue: This requirement doesn’t specify whether users should be able to filter or search products, sort by price, view detailed descriptions, etc. Consistent Requirement (Ideal): "The system must handle up to 1,000 concurrent users without crashing." Inconsistent Requirement (Real-world issue): "The system must handle up to 1,000 concurrent users." "The system must only support 100 simultaneous users to keep things simple." Issue: These two requirements conflict, as one specifies a high concurrency limit and the other limits it to a much lower number. 21 Non-functional requirements These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. Process requirements may also be specified mandating a particular IDE, programming language or development method. Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless. Example: If a banking system is very slow or frequently crashes under load, customers may abandon it, even if all the functional features are technically available. The system’s reliability, availability, and response time are critical to user satisfaction and trust. Example: Non-functional and Constraints Key Examples of Non-functional Requirements: Reliability: "The system should have 99.9% uptime." Response Time: "The system should return search results within 2 seconds." Storage Requirements: "The system must be capable of storing at least 1 TB of user data." Scalability: "The system should support up to 100,000 simultaneous users without significant performance degradation." Key Examples of Constraints: I/O Device Capability: "The system should support a maximum of 4K resolution on monitors." System Representations: "The system must use PostgreSQL for data storage." Security Constraints: "All communication must be encrypted using TLS." 23 Types of nonfunctional requirement Non-functional requirements implementation Non-functional requirements may affect the overall architecture of a system rather than the individual components. For example, to ensure that performance requirements are met Organizing components to minimize network latency and reduce communication overhead between them. Using caching mechanisms to avoid repeated access to databases or slow external resources. A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required. Example: Security requirement: "All sensitive data must be encrypted both at rest and in transit.“ – this leads to functional requires such as: The system must include encryption algorithms to handle data encryption and decryption. The system must ensure secure connections (e.g., using TLS/SSL) for all data transmission. Non-functional classifications Product requirements Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. Organisational requirements Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc. Example: "The system must be developed using Agile methodology." External requirements Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc. Example: "The system must be interoperable ‫ متوافق مع‬with third-party payment gateways (e.g., PayPal, Stripe)." Examples of nonfunctional requirements in the Mentcare system Product requirement The Mentcare system shall be available to all clinics during normal working hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not exceed five seconds in any one day. Organizational requirement Users of the Mentcare system shall authenticate themselves using their health authority identity card. External requirement The system shall implement patient privacy provisions as set out in HStan-03-2006-priv. Goals and requirements Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify. Goal A general intention of the user such as ease of use. e.g., The system should be easy to use." Imprecision: Goals can be vague and hard to measure, making them difficult to verify. For example, "ease of use" is subjective and doesn’t provide a clear metric. Verifiable non-functional requirement A statement using some measure that can be objectively tested. e.g., "system uptime must be 99.9% Goals are helpful to developers as they convey the intentions of the system users. But are difficult to test. Usability requirements The system should be easy to use by medical staff and should be organized in such a way that user errors are minimized. (Goal) The goal is broad and aspirational. Medical staff shall be able to use all the system functions after four hours of training. After this training, the average number of errors made by experienced users shall not exceed two per hour of system use. (Testable non-functional requirement) The non-functional requirement is specific, measurable, and provides clear criteria for validation Error Example: A medical staff member selects the wrong patient record due to unclear interface labeling, resulting in incorrect data being entered into the system. This counts as one user error. or entering invalid information Metrics for specifying nonfunctional requirements Property Measure Speed Processed transactions/second User/event response time Screen refresh time Size Mbytes Number of ROM chips Ease of use Training time Number of help frames Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems https://shorturl.at/nx6nD 31 Thank you 32 Software Engineering Lecture 07: System modeling Muhammad Haggag, Ph.D. Computer Science Department Faculty of Computers and Information Mansoura University Fall 2024 Topics covered Context Models: Define the environment and conditions of a system. (Use Case) Interaction Models: Describe how components or users interact. (Sequence) Structural Models: Show the organization and relationships within the system. (Class) Behavioral Models: Depict how the system behaves over time. (Activity / State machine) Model-Driven Engineering (MDE): Uses high levels models to automate system development. (Component) 2 System modeling System modeling is the process of developing abstract models of a system, with each model presenting a different view or perspective of that system. Models serve as a communication bridge between stakeholders (e.g., customers, developers, and designers) to ensure that everyone has a shared understanding of the system’s design, behavior, and structure. System modeli

Software Engineering Lecture 01 PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue