Software Engineering FINALS 2024 PDF

40 Mcq (20 marks) ⁠Week 1-4 (30% emphasis on Software Processes & Agile Methods) & ⁠Week 5-12 (70%) ⁠ 1 structured question - multiple parts (20 marks) - Case format which provides scenarios for interpretation and explanation of concepts in relation to a particular case/context....

40 Mcq (20 marks) ⁠Week 1-4 (30% emphasis on Software Processes & Agile Methods) & ⁠Week 5-12 (70%) ⁠ 1 structured question - multiple parts (20 marks) - Case format which provides scenarios for interpretation and explanation of concepts in relation to a particular case/context. - Example: - John has a supermarket with 10,00 employees and wishes to implement a Management Information System primarily for reporting. Based on the fact that there are 20 middle managers who will be required to provide details on how to build the system to meet their needs, - discuss in your view the appropriateness of agile or planned methods for the development of a system for the supermarket. [5 marks) - Identify one non-functional requirement that could be derived from the description above. [2 marks) Notes 01 - BASICS Engineering: ○ the branch of science and technology concerned with the design, modification, or development of artifacts. ○ Using appropriate theories and methods to solve problems bearing in mind organizational and financial constraints. 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. 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. ○ Essential software product attributes are: ○ Maintainability ○ Dependability and security ○ Efficiency and acceptability Software Process high-level activities: ○ Specification ○ Development ○ Validation ○ Evolution  The fundamental notions of software engineering are universally applicable to all types of system development. There are many different types of systems, and each requires appropriate software engineering tools and techniques for their development. The fundamental ideas of software engineering are applicable to all types of software systems. Software engineers have responsibilities to the engineering profession and society. They should not simply be concerned with technical issues. Professional societies publish codes of conduct which set out the standards of behavior expected of their members Building good software ○ NOT trivial for large enough systems ○ Requires several skills ○ Programming is almost the least of them ○ Strong people and management skills ○ People don’t know what they want ○ Technology changes, and what was is progress won’t work anymore ○ Even the most well-built system has errors ○ Logic errors ○ Hardware issues from which software can’t recover ○ Things Unseen Software product categories ○ Generic products Stand-alone systems that are marketed and sold to any customer who wishes to buy them. The specification of what the software should do is owned by the software developer and decisions on software change are made by the developer. Examples – PC software such as graphics programs, project management tools; CAD software; and software for specific markets such as appointment systems for dentists. ○ Customized products Software that is commissioned by a specific customer to meet their own needs. 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. Examples – are embedded control systems, air traffic control software, and traffic monitoring systems.  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. All aspects of software production ○ Not just the technical process of development. Also project management and the development of tools, methods, etc. to support software production. State of Software and Software Engineering ○ The economies of ALL developed nations are dependent on software. ○ More and more systems are software-controlled Tax Collections, Registration (person & property), Banking, Stock Market ○ Expenditure on software represents a significant fraction of GNP in all developed countries. Software Engineering – History ○ 1968 response to unreliable, late delivery, and excessive cost overruns in Software projects ○ 1970-1980 SE Techniques - structured programming, Object Oriented Development Software engineering is concerned with theories, methods, and tools for professional software development. Is there really a Software Crisis? ○ Software Project Failures (Standish Reports, 1994, 2014) Inability to produce software to leverage: Increase in the volume of data being generated A large amount of computational power offered by current hardware devices Appetite of the newly emerged ‘digital native’  ○ Increasing demands for larger more complex systems Attempt to combine, automate more processes, and integrate resources ○ Low expectations Many are involved in software development without the requisite skills /training Systems developed are often expensive, unreliable, and hard to maintain Key Concepts/Questions ○ Fundamental Software Engineering Activities Software specification, software development, software validation, and software evolution. ○ Software Engineering vs. Computer Science Computer science focuses on theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software. ○ Systems Engineering vs. Software Engineering System engineering is concerned with all aspects of computer-based systems development including hardware, software, and process engineering. Software engineering is part of this more general process. SE Challenges ○ Coping with increasing diversity, demands for reduced delivery times, and developing trustworthy software. SE Best Methods/Techniques ○ Different techniques are appropriate for different types of systems ○ 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. The web has led to the availability of software services 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. Essential Attributes For Good Software  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. ○ 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 systems, the majority of costs are the costs of changing the software after it has gone into use. Software process activities ○ Software specification Customers and engineers define the software that is to be produced and the constraints on its operation. ○ Software development Software is designed and programmed. ○ Software validation Software is checked to ensure that it is what the customer requires. ○ Software evolution Software is modified to reflect changing customer and market reqs. General issues that affect most software ○ Heterogeneity 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. ○ Security and Trust As software is intertwined with all aspects of our lives, it is essential that we can trust that software. Software engineering diversity ○ There are many different types of software systems 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.  Application types ○ Stand-alone applications 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 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 These are software control systems that control and manage hardware devices. Numerically, there are probably more embedded systems than any other type of system. ○ Batch processing systems These are business systems that are designed to process data in large batches. They process large numbers of individual inputs to create corresponding outputs. Eg. Billing Systems, Payroll ○ Entertainment systems These are systems that are primarily for personal use and which are intended to entertain the user. ○ Systems for modeling and simulation These are systems that are developed by scientists and engineers to model physical processes or situations, which include many, separate, interacting objects. ○ Data collection systems 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. ○ Application types are not mutually exclusive ○ Application Examples: Automobile control system – ROM, No UI prototyping Web-based system – needs user feedback, prototypes  Software engineering fundamentals ○ Some fundamental principles apply to all types of software systems, 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 systems. 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. Software engineering and the web ○ The Web is now a platform for running applications 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. Web software engineering ○ 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. ○ 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. ○ User interfaces are constrained by the capabilities of web browsers. Technologies such as AJAX allow rich interfaces to be created within a web browser but are still difficult to use. Web forms with local scripting are more commonly used. 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, discussed in the previous section, apply to web-based software in the same way that they apply to other types of software systems. - ETHICS Software engineering ethics ○ Software engineering involves wider responsibilities than simply the application of technical skills. ○ Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals. ○ Ethical behavior is more than simply upholding the law but involves following a set of principles that are morally correct. Issues of professional responsibility ○ Confidentiality Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed. ○ Competence Engineers should not misrepresent their level of competence. They should not knowingly accept work which is outwith their competence. ○ Intellectual property rights Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is protected. ○ Computer misuse Software engineers should not use their technical skills to misuse other people’s computers. Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to extremely serious (dissemination of viruses). ○ ACM/IEEE Code of Ethics The professional societies in the US have cooperated to produce a code of ethical practice. Members of these organizations sign up to the code of practice when they join. The Code contains eight Principles related to the behavior of and decisions made by professional software engineers, including practitioners, educators, managers, supervisors, and policymakers, as well as trainees and students of the profession.  Rationale for the code of ethics ○ Computers have a central and growing role in commerce, industry, government, medicine, education, entertainment, and society at large. Software engineers are those who contribute by direct participation or by teaching, to the analysis, specification, design, development, certification, maintenance, and testing of software systems. ○ Because of their roles in developing software systems, software engineers have significant opportunities to do good or cause harm, to enable others to do good or cause harm, or to influence others to do good or cause harm. To ensure, as much as possible, that their efforts will be used for good, software engineers must commit themselves to making software engineering a beneficial and respected profession. The ACM/IEEE Code of Ethics ○ Software Engineering Code of Ethics and Professional Practice Ethical principles ○ PUBLIC - Software engineers shall act consistently with the public interest. ○ CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest. ○ PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. ○ JUDGMENT - Software engineers shall maintain integrity and independence in their professional judgment. ○ MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. ○ PROFESSION - Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. ○ COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues. ○ SELF - Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession  Ethical dilemmas ○ Disagreement in principle with the policies of senior management. ○ Your employer acts in an unethical way and releases a safety-critical system without finishing the testing of the system. ○ Participation in the development of military weapons systems or nuclear systems. Case studies ○ A personal insulin pump An embedded system in an insulin pump used by diabetics to maintain blood glucose control 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. ○ A mental health case patient management system A system used to maintain records of people receiving care for mental health problems Privacy It is essential that patient information is confidential and is never disclosed to anyone apart from authorized medical staff and the patients themselves. Safety Some mental illnesses cause patients to become suicidal or a danger to other people. Wherever possible, the system should warn medical staff about potentially suicidal or dangerous patients. ○ A wilderness weather station A data collection system that collects data about weather conditions in remote areas Notes 02 Tools Used by Software Engineers ○ Documentation Tools Diagramming Text editors/word processors ○ Programming Languages (different from editors) Parses source code and generates machine code ○ Integrated Development Environments RAD Tools ○ Testing Frameworks Software Processes ○ A structured set of activities is required to develop a software system ○ Abstract representations of these processes. ○ General process models describe the organization of software processes. Examples of these general models include the ‘waterfall’ model, incremental development, and reuse-oriented development. Many different software processes but all involve: ○ Specification defining what the system should do; is the process of developing a software specification. ○ Design and Implementation defining the organization of the system and implementing the system; processes are concerned with transforming a requirements specification into an executable software system. ○ Validation Checking that it does what the customer wants; Is the process of checking that the system conforms to its specification and that it meets the real needs of the users of the system. ○ Evolution changing the system in response to changing customer needs. takes place when you change existing software systems to meet new requirements. The software must evolve to remain useful A software process model is an abstract representation of a process Way of organizing and managing process activities It presents a description of a process from some particular perspective  Processes should include activities to cope with change. ○ This may involve a prototyping phase that helps avoid poor decisions on requirements and design. Processes may be structured for iterative development and delivery so that changes may be made without disrupting the system as a whole. The Rational Unified Process is a modern generic process model that is organized into phases ○ inception, elaboration, construction, and transition ○ separates activities (requirements, analysis, and design, etc.) from these phases Process activities ○ Real software processes are inter-leaved sequences of: Technical, Collaborative and managerial activities ○ The overall goal of specifying, designing, implementing, and testing a software system Software specification ○ The process of establishing what services are required and the constraints on the system’s operation and development. ○ Requirements engineering process Feasibility study: Is it technically and financially feasible to build the system? Requirements elicitation and analysis What do the system stakeholders require or expect from the system? Requirements specification Defining the requirements in detail Requirements validation Checking the validity of the requirements  Software design and implementation ○ The process of converting the system specification into an executable system ○ Software design Design a software structure that realizes the specification; ○ Implementation Translate this structure into an executable program; ○ The activities of design and implementation are closely related and may be inter-leaved ○ Design activities Architectural design Identify the overall structure of the system, the principal components (sometimes called sub-systems or modules), their relationships, and how they are distributed. Interface design Define the interfaces between system components (or users) Component design Take each system component and design how it will operate. Database design Design the system data structures and how these are to be represented in a database/files  Software validation ○ Verification and validation (V & V) is intended to show that : The system conforms to its specification 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. ○ Testing stages Development or 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. Acceptance testing Testing with customer data to check that the system meets the customer’s needs.  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. Plan-driven and agile processes ○ Plan-driven processes 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  Software process models ○ The waterfall model Plan-driven model Separate and distinct phases of specification and development There are separate identified phases in the waterfall model: Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance 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 completed before moving onto the next phase. Waterfall model problems Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements ○ Only appropriate when the requirements are well understood and Changes will be fairly limited during the design process ○ Few business systems have stable requirements The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites ○ In those circumstances, the plan-driven nature of the waterfall model helps coordinate the work Variations of the Waterfall Model Fountain Model ○ Iterations are built-in ○ Overlaps of activities are allowed Formal Specification ○ Mathematical (formal) model of system specification ○ Specification is refined and transformed into executable code ○ Primarily used to develop safety critical / security critical systems ○ Incremental development Specification, development, and validation are interleaved May be plan-driven or agile Developing initial implementation and exposing this to feedback Evolve versions until the system is adequately developed All activities are interleaved Each increment/version incorporates some functionality needed by the customer 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 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 ○ Build in pieces (prototype) ○ This can lead to poor structure 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  ○ Reuse-oriented software engineering The system is assembled from existing components May be plan-driven or agile Components may not exist, hard to integrate Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. Process stages Component analysis; Requirements modification; System design with reuse; Development and integration. Reuse is now the standard approach for building many types of business system Reuse covered in more depth in Chapter 16. In practice, most large systems are developed using a process that incorporates elements from all of these models Types of software component ○ Web services that are developed according to service standards and which are available for remote invocation ○ Collections of objects that are developed as a package to be integrated with a component framework such as.NET or J2EE. ○ Stand-alone software systems (COTS) that are configured for use in a particular environment 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 requires 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  ○ Reducing the costs of rework Change avoidance, 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 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 ○ Benefits of prototyping Improved system usability A closer match to users’ real needs Improved design quality Improved maintainability Reduced development effort ○ The process of prototype development ○ 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  ○ 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 Prototype structure is usually degraded through rapid change The prototype probably will not meet normal organizational quality standards 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 prioritized 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 Incremental development and delivery ○ Incremental development Develop the system in increments and evaluate each increment before proceeding to the development of the next increment The normal approach used in agile methods Evaluation is done by user/customer proxy ○ Incremental delivery Deploy an increment for use by end-users More realistic evaluation of practical use of software Difficult to implement for replacement systems as increments have less functionality than the system being replaced ○ Incremental delivery advantages Customer value can be delivered with each increment so system functionality is available earlier Early increments act as a prototype to help elicit requirements for later increments Lower risk of overall project failure The highest-priority system services tend to receive the most testing  ○ Incremental delivery problems Most systems require a set of basic facilities that are used by different parts of the system As requirements are not defined in detail until an increment is to be implemented, it can be hard to identify common facilities that are needed by all increments The essence of iterative processes is that the specification is developed in conjunction with the software However, this conflicts with the procurement model of many organizations, where the complete system specification is part of the system development contract Boehm’s spiral model ○ The process is represented as a spiral rather than as a sequence of activities with backtracking ○ Each loop in the spiral represents a phase in the process. ○ No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required ○ Risks are explicitly assessed and resolved throughout the process ○ Plan what will be done in four segments and manage risks ○ Combine Waterfall Phases and Prototyping ○ Spiral model sectors Objective setting Specific objectives for the phase are identified Risk assessment and reduction Risks are assessed and activities put in place to reduce the key risks Development and validation A development model for the system is chosen which can be any of the generic models Planning The project is reviewed and the next phase of the spiral is planned  ○ Spiral model usage The spiral model has been very influential in helping people think about iteration in software processes and introducing the risk-driven approach to development In practice, however, the model is rarely used as published for practical software development. The Rational Unified Process(RUP) ○ A modern generic process derived from the work on the UML and associated process ○ Brings together aspects of the 3 generic process models discussed previously ○ Normally described from 3 perspectives A dynamic perspective that shows phases over time A static perspective that shows process activities A proactive perspective that suggests good practice ○ RUP phases Inception Establish the business case for the system Elaboration Develop an understanding of the problem domain and the system architecture Construction System design, programming, and testing Transition Deploy the system in its operating environment ○ RUP iteration In-phase iteration Each phase is iterative with results developed incrementally Cross-phase iteration As shown by the loop in the RUP model, the whole set of phases may be enacted incrementally  ○ Static workflows in the Rational Unified Process ○ RUP good practice Develop software iteratively Plan increments based on customer priorities and deliver highest priority increments first Manage requirements Explicitly document customer requirements and keep track of changes to these requirements Use component-based architectures Organize the system architecture as a set of reusable components. Visually model software Use graphical UML models to present static and dynamic views of the software. Verify software quality Ensure that the software meet’s organizational quality standards. Control changes to software Manage software changes using a change management system and configuration management tools. ○ NB Processes should include activities to cope with change. This may involve a prototyping phase that helps avoid poor decisions on requirements and design. Processes may be structured for iterative development and delivery so that changes may be made without disrupting the system as a whole. Development / Delivery Approaches ○ Build All, Deliver All ○ Develop in increments ○ Deliver increments  Milestone vs. Deliverable ○ Milestone Significant achievement/event Example: Completion of requirements specification Signing of the contract ○ Deliverable A usable item produced A part of the project that is of use to the customer (can be a milestone, but this must be something that can be handed over) Notes 03 RAPID Application Development (RAD) ○ Form of AGILE Software Development ○ Less emphasis on planning and more emphasis on the process ○ Suited for developing software that is driven by user interface requirements? Interactive Applications | Mobile Apps | Wrapper Applications (eg. Web interfaces) Graphical user interface builders are often called rapid application development tools ○ RAD TOOLS Microsoft.NET Studio Eclipse (with plugins) – JAVA ○ Low-Code Development Platforms (used by RAD professionals) Zoho Creator OutSystems Visual LANSA ColdFusion Builder Spring Boot Angular.io ○ No-Code Development Platforms (used by RAD professionals) Nintex Workflow Platform FileMaker QuickBase Zoho Creator KiSSFLOW - BPM & Workflow Software Salesforce Platform: Force.com 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. ○ Rapid software development Specification, design, and implementation are inter-leaved The system is developed as a series of versions with stakeholders involved in version evaluation User interfaces are often developed using an IDE and graphical toolset. - AGILE METHOD 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. Not necessarily a waterfall model – plan-driven, incremental development is possible Iteration occurs within activities. ○ 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. Problems with agile methods ○ It can be difficult to keep the interest of customers who are involved in the process. ○ Team members may be unsuited to the intense involvement that characterizes agile methods. ○ Prioritizing changes can be difficult where there are multiple stakeholders. ○ Maintaining simplicity requires extra work. ○ Contracts may be a problem as with other approaches to iterative development. Agile methods and software maintenance ○ Most organizations spend more on maintaining existing software than they do on new software development. So, if agile methods are to be successful, they have to support maintenance as well as original development. ○ Two key issues: Are systems that are developed using an agile approach maintainable, given the emphasis in the development process of minimizing formal documentation? Can agile methods be used effectively for evolving a system in response to customer change requests? ○ Problems may arise if the original development team cannot be maintained.  Technical, human, and organizational issues ○ Most projects include elements of plan-driven and agile processes. Deciding on the balance depends on: Is it important to have a very detailed specification and design before moving to implementation? If so, you probably need to use a plan-driven approach. Is an incremental delivery strategy, where you deliver the software to customers and get rapid feedback from them, realistic? If so, consider using agile methods. How large is the system that is being developed? Agile methods are most effective when the system can be developed with a small co-located team that can communicate informally. This may not be possible for large systems that require larger development teams so a plan-driven approach may have to be used. What type of system is being developed? Plan-driven approaches may be required for systems that require a lot of analysis before implementation (e.g. real-time system with complex timing requirements). What is the expected system lifetime? Long-lifetime systems may require more design documentation to communicate the original intentions of the system developers to the support team. What technologies are available to support system development? Agile methods rely on good tools to keep track of an evolving design How is the development team organized? If the development team is distributed or if part of the development is being outsourced, then you may need to develop design documents to communicate across the development teams. Are there cultural or organizational issues that may affect the system development? Traditional engineering organizations have a culture of plan-based development, as this is the norm in engineering.  How good are the designers and programmers in the development team? It is sometimes argued that agile methods require higher skill levels than plan-based approaches in which programmers simply translate a detailed design into code Is the system subject to external regulation? If a system has to be approved by an external regulator (e.g. the FAA approves software that is critical to the operation of an aircraft) then you will probably be required to produce detailed documentation as part of the system safety case. Agile methods ○ Agile methods are incremental development methods that focus on: ‘rapid’ development frequent releases of the software reducing process overheads and producing high-quality code involve the customer directly in the development process ○ The decision on whether to use an agile or a plan-driven approach should depend on: the type of software being developed the capabilities of the development team the culture of the company developing the system ○ 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 Are based on an iterative approach to software development Are intended to deliver working software quickly and evolve this quickly to meet changing requirements. ○ 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. ○ 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 Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change by following a plan That is, while there is value in the items on the right, we value the items on the left more.  ○ Principles of Agile Methods ○ Problems with agile methods It can be difficult to keep the interest of customers who are involved in the process. Team members may be unsuited to the intense involvement that characterizes agile methods. Prioritizing changes can be difficult where there are multiple stakeholders. Maintaining simplicity requires extra work. Contracts may be a problem as with other approaches to iterative development. Popular Agile Methods ○ Xtreme Programming (XP) Perhaps the best-known and most widely used agile method. 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. XP and agile principles Incremental development is supported through small, frequent system releases. 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. Change supported through regular system releases. Maintaining simplicity through constant refactoring of code.  The extreme programming release cycle Extreme programming practices (a) Extreme programming practices (b) User requirements are expressed as scenarios or user stories These are written on cards and the development team breaks them down into implementation tasks  Requirements scenarios 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 scenarios or user stories. These are written on cards and the development team breaks 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. XP and change 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. Rather, it proposes constant code improvement (refactoring) to make changes easier when they have to be implemented. Refactoring Programming team look for possible software improvements and make these improvements even where there is no immediate need for them. This improves the understandability of the software and so reduces the need for documentation. Changes are easier to make because the code is well-structured and clear. However, some changes requires architecture refactoring and this is much more expensive. Examples of refactoring Re-organization of a class hierarchy to remove duplicate code. Tidying up and renaming attributes and methods to make them easier to understand. The replacement of inline code with calls to methods that have been included in a program library.  Testing in XP 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. ○ Incremental test development from scenarios. ○ User involvement in test development and validation. ○ Automated test harnesses are used to run all component tests each time that a new release is built. Test-first 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. All previous and new tests are run automatically when new functionality is added, thus checking that the new functionality has not introduced errors. 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. 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. However, people adopting the customer role have limited time available and so cannot work full-time with the development team. They may feel that providing the requirements was enough of a contribution and so may be reluctant to get involved in the testing process.  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. XP testing difficulties 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, 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. Pair programming In XP, programmers work in pairs, sitting together to develop code. This helps develop common ownership of code and spreads knowledge across the team. It serves as an informal review process as each line of code is looked at by more than 1 person. It encourages refactoring as the whole team can benefit from this. Measurements suggest that development productivity with pair programming is similar to that of two people working independently.  In pair programming, programmers sit together at the same workstation to develop the software. Pairs are created dynamically so that all team members work with each other during the development process. 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. Pair programming is not necessarily inefficient and there is evidence that a pair working together is more efficient than 2 programmers working separately. Advantages of pair programming It supports the idea of collective ownership and responsibility for the system. ○ Individuals are not held responsible for problems with the code. ○ Instead, the team has collective responsibility for resolving these problems. It acts as an informal review process because each line of code is looked at by at least two people. It helps support refactoring, which is a process of software improvement. ○ Where pair programming and collective ownership are used, others benefit immediately from the refactoring so they are likely to support the process. Advantages of pair programming It supports the idea of collective ownership and responsibility for the system. ○ Individuals are not held responsible for problems with the code. Instead, the team has collective responsibility for resolving these problems. It acts as an informal review process because each line of code is looked at by at least two people. It helps support refactoring, which is a process of software improvement. ○ Where pair programming and collective ownership are used, others benefit immediately from the refactoring so they are likely to support the process.  Agile project management The principal responsibility of software project managers is to manage the project so that the software is delivered on time and within the planned budget for the project. The standard approach to project management is plan-driven. ○ Managers draw up a plan for the project showing what should be delivered, when it should be delivered and who will work on the development of the project deliverables. Agile project management requires a different approach, which is adapted to incremental development and the particular strengths of agile methods. ○ Scrum The Scrum approach is a general agile method but its focus is on managing iterative development rather than specific agile practices. There are three phases in Scrum. ○ The initial phase is an outline planning phase where you establish the general objectives for the project and design the software architecture. ○ This is followed by a series of sprint cycles, where each cycle develops an increment of the system. ○ The project closure phase wraps up the project, completes required documentation such as system help frames and user manuals, and assesses the lessons learned from the project. ○ Writing User Stories Option 1: ‘Descriptive Prose’ Describe the steps in sequence and actions required with the expected behavior of the system using story-type description Option 2: Formatted Syntax Gherkin Format  The Scrum process The Sprint cycle Sprints are fixed length, normally 2–4 weeks. ○ They correspond to the development of a release of the system in XP. The starting point for planning is the product backlog, which is the list of work to be done on the project. The selection phase involves all of the project team who work with the customer to select the features and functionality to be developed during the sprint. Once these are agreed, the team organizes themselves to develop the software. During this stage, the team is isolated from the customer, and the organization, with all communications channeled through the so-called ‘Scrum master’. The role of the Scrum master is to protect the development team from external distractions. At the end of the sprint, the work done is reviewed and presented to stakeholders. ○ The next sprint cycle then begins.  Teamwork in Scrum The ‘Scrum master’ is a facilitator who arranges daily meetings, tracks the backlog of work to be done, records decisions, measures progress against the backlog and communicates with customers and management outside of the team. The whole team attends short daily meetings where all team members share information, describe their progress since the last meeting, problems that have arisen and what is planned for the following day. ○ This means that everyone on the team knows what is going on and, if problems arise, can re-plan short-term work to cope with them. Scrum benefits The product is broken down into a set of manageable and understandable chunks. Unstable requirements do not hold up progress. The whole team have visibility of everything and consequently, team communication is improved. Customers see on-time delivery of increments and gain feedback on how the product works. Trust between customers and developers is established and a positive culture is created in which everyone expects the project to succeed. ○ Scaling Agile Methods Considerations for Scaling agile methods Agile methods have proved to be successful for small and medium sized projects that can be developed by a small co-located team. It is sometimes argued that the success of these methods comes because of improved communications which is possible when everyone is working together. Scaling up agile methods involves changing these to cope with larger, longer projects where there are multiple development teams, perhaps working in different locations.  Large systems development Large systems are usually collections of separate, communicating systems, where separate teams develop each system. Frequently, these teams are working in different places, sometimes in different time zones. Large systems are ‘brownfield systems’, that is they include and interact with a number of existing systems. Many of the system requirements are concerned with this interaction and so don’t really lend themselves to flexibility and incremental development. Where several systems are integrated to create a system, a significant fraction of the development is concerned with system configuration rather than original code development. Large system development Large systems and their development processes are often constrained by external rules and regulations limiting the way that they can be developed. Large systems have a long procurement and development time. It is difficult to maintain coherent teams who know about the system over that period as, inevitably, people move on to other jobs and projects. Large systems usually have a diverse set of stakeholders. It is practically impossible to involve all of these different stakeholders in the development process. Scaling out and scaling up ‘Scaling up’ is concerned with using agile methods for developing large software systems that cannot be developed by a small team. ‘Scaling out’ is concerned with how agile methods can be introduced across a large organization with many years of software development experience. When scaling agile methods it is essential to maintain agile fundamentals ○ Flexible planning, frequent system releases, continuous integration, test-driven development, and good team communications.  Scaling up to large systems For large systems development, it is not possible to focus only on the code of the system. You need to do more up-front design and system documentation Cross-team communication mechanisms have to be designed and used. ○ This should involve regular phone and video conferences between team members and frequent, short electronic meetings where teams update each other on progress. Continuous integration, where the whole system is built every time any developer checks in a change, is practically impossible. ○ However, it is essential to maintain frequent system builds and regular releases of the system. Scaling out to large companies Project managers who do not have experience of agile methods may be reluctant to accept the risk of a new approach. Large organizations often have quality procedures and standards that all projects are expected to follow and, because of their bureaucratic nature, these are likely to be incompatible with agile methods. Agile methods seem to work best when team members have a relatively high skill level. ○ However, within large organizations, there are likely to be a wide range of skills and abilities. There may be cultural resistance to agile methods, especially in those organizations that have a long history of using conventional systems engineering processes. Agile methods are incremental development methods that focus on rapid development, frequent releases of the software, reducing process overheads and producing high-quality code. They involve the customer directly in the development process. The decision on whether to use an agile or a plan-driven approach to development should depend on the type of software being developed, the capabilities of the development team and the culture of the company developing the system. Extreme programming is a well-known agile method that integrates a range of good programming practices such as frequent releases of the software, continuous software improvement and customer participation in development team. A particular strength of extreme programming is the development of automated tests before a program feature is created. All tests must successfully execute when an increment is integrated into a system. The Scrum method is an agile method that provides a project management framework. It is centred round a set of sprints, which are fixed time periods when a system increment is developed. Scaling agile methods for large systems is difficult. Large systems need up-front design and some documentation  Cleanroom Approach: reliability is critical ○ Software development based on formal methods Usually done using tools that support mathematical formalism: model checking, process algebras, and Petri nets Verification that the design correctly implements the specification is performed through team review, often with software tool support ○ Incremental implementation under statistical quality control Cleanroom development uses an iterative approach Product is developed in increments The quality of each increment is measured against pre-established standards to verify that the development process is proceeding acceptably A failure to meet quality standards results in the cessation of testing for the current increment, and a return to the design phase ○ Software testing in the cleanroom process is carried out as a statistical experiment Test samples are statistically analyzed to produce an estimate of the reliability of the software, and a level of confidence in that estimate The Software Development Ecosystem ○ CORE ACTIVITIES Requirements, Design & Implementation, Validation, Evolution ○ Models & Approaches Waterfall | Spiral | Prototyping | Cleanroom | Incremental | Agile ○ Methodologies / Frameworks (set of methods) RAD, SCRUM, XP, …..and more ○ Supporting Activities Project Management | Configuration Management Documentation (user & technical) | Quality Assurance Notes 04 - Software Project Management Project & PM ○ Project Temporary endeavor to create product, service or result Definite beginning and end Need or objectives met (success) Need or objectives cannot be met (failure) ○ Project Management Activities geared towards delivering objectives within time schedule, budget quality, and scope. Triple Constraint ○ Change in any three (Schedule, Cost, Scope) impacts the other two & Quality Knowledge Areas ○ Integration Management ○ Scope Management ○ Time Management ○ Cost Management ○ Quality Management ○ Human Resource Management ○ Communications Management ○ Risk Management ○ Procurement Management ○ Stakeholder Management Process Groups ○ Initiating processes Activities to start the project Authorize project High-Level Product Functionality /Detailed Requirements Document ○ Planning processes Determine how things will be done Plan all aspects of project, cost, time etc. Project Scope Statement ○ Executing Processes Start the work SDLC – Design, Implementation, Testing ○ Monitoring and Controlling processes Monitor and manage the work as it is done Ensure compliance with the plans ○ Closing processes End project and deliver product/service/result Release staff, document lessons learned  Initiating ○ Create a Project Charter Do a feasibility study (technical, financial, etc.) In the charter: Identify the main objectives of the system … done Identify stakeholders … patient, hospital staff, government… Determine the key milestones/deliverables ○ Charter sign-off ○ End of planning Project Scope statement ○ Completion of the first release ○ Completion of the second release Planning ○ Develop Project Management Plan Plan Scope Management, Collect Requirements, Define Scope, Create WBS Defining Scope Indicate the inclusions and exclusions of the project Create WBS This is a listing of things to be done in the project Hierarchical / Tabular The Project Schedule ○ The project schedule is the core of the project plan ○ It is used by the project manager to commit people to the project and show the organization how the work will be performed. ○ Schedules are used to communicate final deadlines and, in some cases, to determine resource needs. ○ They are also used as a kind of checklist to make sure that every task necessary is performed. Scheduling ○ Based on WBS Break tasks into assignable sizes Estimate task durations Required effort (man-hours) Determine who will be assigned Work calendars Expertise Outsourcing ○ Procurement Management? HR Management Elapsed Time (calendar days for completion, given resource assigned)  Planning II ○ Plan Schedule Management Define activities Identify the activities required to complete items listed in WBS Activities should be small/large enough to assign to one person Sequence activities Determine what order activities will be done Estimate activity resources What will be required to accomplish the activities in the given sequence? Programmers, solution architects, etc. Planning III ○ Estimate activity durations Required effort vs. Elapsed time ○ Develop schedule PM Software tool ○ Plan Cost Management, estimate costs, determine budget ○ Plan Quality Management ○ Plan human resource management ○ Plan communication management ○ Plan risk management, identify risks, perform risk analysis, plan risk responses Executing ○ Direct and manage project work ○ Perform quality assurance ○ Acquire, develop, and manage project team ○ Manage communications ○ Conduct procurements Monitoring and Controlling ○ Control schedule ○ Control costs ○ Control quality ○ Control communications ○ Control procurements Closing Processes ○ Close project or phase ○ Close procurements Project Management & “Progressive Elaboration” ○ continuously improving and detailing a plan as more detailed and specific information and more accurate estimates become available  Project Managers ○ Competence Knowledge & appropriate application of the PMBOK Sound technical knowledge adept in handling technical tools and have a deep insight in the subject of the project ○ Good Communicator ○ Effective Leadership Skills Notes 05a - Requirements Engineering Requirements engineering ○ The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. ○ The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. 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; May be the basis for the contract itself - therefore must be defined in detail; Both these statements may be called requirements. Types of Requirements ○ Statement of service/function to be performed by the system and or Constraints on the functions on the system User Requirement – usually specified from their perspective of the business and how the user of a particular domain expresses their domain knowledge. System Requirements – What are the system-based steps/activities required to complete the user requirement Requirements Engineering Processes ○ The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements. ○ However, there are a number of generic activities common to all processes Requirements elicitation; Requirements analysis; Requirements validation; Requirements management. In practice, RE is an iterative activity in which these processes are interleaved. ○ Requirements elicitation and analysis Sometimes called requirements elicitation or requirements discovery. Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints. May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders. Software engineers work with a range of system stakeholders to find out about the application domain, the services that the system should provide, the required system performance, hardware constraints, other systems, etc. Stages include: Requirements discovery ○ Interacting with stakeholders to discover their requirements. ○ Domain requirements are also discovered at this stage. ○ The process of gathering information about the required and existing systems and distilling the user and system requirements from this information. ○ Interaction is with system stakeholders from managers to external regulators. ○ Systems normally have a range of stakeholders. ○ Elicitation (discovery) Techniques Observing how the current operations take place Go to a few health centers and observe the processes in action without interfering Document what is observed ○ Meet with stakeholders to get understanding of what was observed to better understand the process ○ Allow Stakeholders to demonstrate activities Document Reviews (reports, current software systems, legal and regulatory) Request copies of documents that were used based on observation Examine regulations and any laws Requirements classification and organization ○ Groups related requirements and organises them into coherent clusters. Requirements prioritization and negotiation  ○ Prioritising requirements and resolving requirements conflicts. Requirements specification. ○ Requirements are documented and input into the next round of the spiral. Problems of requirements analysis Stakeholders don’t know what they really want. Stakeholders express requirements in their own terms. Different stakeholders may have conflicting requirements. Organisational and political factors may influence the system requirements. The requirements change during the analysis process. New stakeholders may emerge and the business environment may change. CASE(MHC-PMS) The MHC-PMS (Mental Health Care-Patient Management System) is an information system that is intended for use in clinics. It makes use of a centralized database of patient information but has also been designed to run on a PC, so that it may be accessed and used from sites that do not have secure network connectivity. When the local systems have secure network access, they use patient information in the database but they can download and use local copies of patient records when they are disconnected. Stakeholders in the MHC-PMS ○ Patients whose information is recorded in the system. ○ Doctors 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. ○ 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. Interviewing Formal/informal interviews with stakeholders are part of most RE processes. Types of interview ○ Closed interviews based on pre-determined list of questions Used to discover initial understanding, allows the user to give details which may not be available via other means ○ Open interviews where various issues are explored with stakeholders. Used primarily when there is already at least a basic understanding of domain and there is need for more specifics Effective interviewing ○ Be open-minded, avoid pre-conceived ideas about therequirements and are willing to listen to stakeholders. ○ Prompt the interviewee to get discussions going using a springboard question, a requirements proposal, or by working together on a prototype system. Interviews in practice ○ Normally a mix of closed and open-ended interviewing. ○ Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system. ○ Interviews are not good for understanding domain requirements Requirements engineers cannot understand specific domain terminology; Some domain knowledge is so familiar that people find it hard to articulate or think that it isn’t worth articulating. Scenarios Describes how the system should work given the assumed current state/situation. ○ Request the user to describe steps to be taken in different circumstances  ○ Ask the user to provide details of how things should happen Scenarios are real-life examples of how a system can beused. They should include ○ Description of the starting situation (Initial assumption) ○ Description of normal flow of events (What should happen) ○ A description of what can go wrong; ○ Information about other concurrent activities; ○ A description of the state when the scenario finishes. Application of this technique requires prior knowledge of the domain such that the software engineer can ask for description of specific tasks / domain activities. Use cases Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself. A set of use cases should describe all possible interactions with the system. High-level graphical model supplemented by more detailed tabular description (see Chapter 5). Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system. Ethnography A social scientist spends a considerable time observing and analysing how people actually work. People do not have to explain or articulate their work.  Social and organisational factors of importance may be observed. Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models. Scope of ethnography ○ Requirements that are derived from the way that people actually work rather than the way I which process definitions suggest that they ought to work. ○ Requirements that are derived from cooperation and awareness of other people’s activities. Awareness of what other people are doing leads to changes in the ways in which we do things. ○ Ethnography is effective for understanding existing processes but cannot identify new features that should be added to a system. Focused ethnography ○ Developed in a project studying the air traffic control process ○ Combines ethnography with prototyping ○ Prototype development results in unanswered questions which focus the ethnographic analysis. ○ The problem with ethnography is that it studies existing practices which may have some historical basis which is no longer relevant. ○ Requirements Analysis - organizing, classifying, prioritizing Determine category of the requirement, which is most important, and ensure the collected requirements are “complete”  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. 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. Functional requirements for the MHC-PMS 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 requirements are not precisely stated. Ambiguous requirements may be interpreted in different ways by developers and users. 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, it is impossible to produce a complete and consistent requirements document. ○ Non-functional requirements Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, 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. Often apply to the system as a whole rather than individual features or services. Examples of non-functional requirements in the PMS Product requirement ○ The PMS shall be available to all clinics during normal working hours (Mon–Fri, 0830–1730). Downtime within normal working hours shall not exceed five seconds in any one day. Organizational requirement ○ Users of the PMS 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 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, you may hav