FINAL.pdf
Document Details
Uploaded by AppreciativeRadiance
Tags
Full Transcript
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 opti...
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. Chapter 2 Software Processes 33 Benefits of prototyping Improved system usability. A closer match to users’ real needs. Improved design quality. Improved maintainability. Reduced development effort. Chapter 2 Software Processes 34 The process of prototype development Chapter 2 Software Processes 35 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 Chapter 2 Software Processes 36 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. Chapter 2 Software Processes 37 Chapter 3 – Agile Software Development Lecture 1 Chapter 3 Agile software development 1 Topics covered Agile methods Plan-driven and agile development Extreme programming Agile project management Scaling agile methods Chapter 3 Agile software development 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. Rapid software development Specification, design and implementation are inter-leaved 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. Chapter 3 Agile software development 3 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 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. Chapter 3 Agile software development 4 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 over following a plan That is, while there is value in the items on the right, we value the items on the left more. Chapter 3 Agile software development 5 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. Chapter 3 Agile software development 6 Agile method applicability Product development where a software company is developing a small or medium-sized product for sale. 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 not a lot of external rules and regulations that affect the software. Because of their focus on small, tightly-integrated teams, there are problems in scaling agile methods to large systems. Chapter 3 Agile software development 7 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 characterises agile methods. Prioritising 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. Chapter 3 Agile software development 8 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 original development team cannot be maintained. Chapter 3 Agile software development 9 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 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. Chapter 3 Agile software development 10 Plan-driven and agile specification Chapter 3 Agile software development 11 Extreme programming 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. Chapter 3 Agile software development 12 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. Chapter 3 Agile software development 13 The extreme programming release cycle Chapter 3 Agile software development 14 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’. See Figures 3.5 and 3.6. 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. Chapter 3 Agile software development 15 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. Chapter 3 Agile software development 16 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 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. Chapter 3 Agile software development 17 A ‘prescribing medication’ story Chapter 3 Agile software development 18 Examples of task cards for prescribing medication Chapter 3 Agile software development 19 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. Chapter 3 Agile software development 20 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. Chapter 3 Agile software development 21 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. Chapter 3 Agile software development 22 Key points 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 the development team. Chapter 3 Agile software development 23 Chapter 3 – Agile Software Development Lecture 2 Chapter 3 Agile software development 24 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. Chapter 3 Agile software development 25 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. Chapter 3 Agile software development 26 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. Chapter 3 Agile software development 27 Test case description for dose checking Chapter 3 Agile software development 28 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. Chapter 3 Agile software development 29 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. Chapter 3 Agile software development 30 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. Chapter 3 Agile software development 31 Pair programming 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. Chapter 3 Agile software development 32 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. Chapter 3 Agile software development 33 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. Chapter 3 Agile software development 34 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. Chapter 3 Agile software development 35 The Scrum process Chapter 3 Agile software development 36 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. Chapter 3 Agile software development 37 The Sprint cycle Once these are agreed, the team organize themselves to develop the software. During this stage the team is isolated from the customer and the organization, with all communications channelled 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. Chapter 3 Agile software development 38 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. Chapter 3 Agile software development 39 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. Chapter 3 Agile software development 40 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. Chapter 3 Agile software development 41 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. Chapter 3 Agile software development 42 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. Chapter 3 Agile software development 43 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. Chapter 3 Agile software development 44 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. Chapter 3 Agile software development 45 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. Chapter 3 Agile software development 46 Key points 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. Chapter 3 Agile software development 47 Chapter 4 – Requirements Engineering Lecture 1 Chapter 4 Requirements engineering 1 Topics covered Functional and non-functional requirements The software requirements document Requirements specification Requirements engineering processes Requirements elicitation and analysis Requirements validation Requirements management Chapter 4 Requirements engineering 2 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. Chapter 4 Requirements engineering 3 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. Chapter 4 Requirements engineering 4 Types of requirement User requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. 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. Chapter 4 Requirements engineering 5 User and system requirements Chapter 4 Requirements engineering 6 Readers of different types of requirements specification Chapter 4 Requirements engineering 7 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 Chapter 4 Requirements engineering 8 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. Chapter 4 Requirements engineering 9 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. Chapter 4 Requirements engineering 10 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. Chapter 4 Requirements engineering 11 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. Chapter 4 Requirements engineering 12 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. Chapter 4 Requirements engineering 13 Types of nonfunctional requirement Chapter 4 Requirements engineering 14 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 have to organize the system to minimize communications between components. 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. It may also generate requirements that restrict existing requirements. Chapter 4 Requirements engineering 15 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. External requirements Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc. Chapter 4 Requirements engineering 16 Examples of nonfunctional requirements in the MHC-PMS Product requirement The MHC-PMS 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 MHC-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. Chapter 4 Requirements engineering 17 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. Verifiable non-functional requirement A statement using some measure that can be objectively tested. Goals are helpful to developers as they convey the intentions of the system users. Chapter 4 Requirements engineering 18 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) 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) Chapter 4 Requirements engineering 19 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 Chapter 4 Requirements engineering 20 Domain requirements The system’s operational domain imposes requirements on the system. For example, a train control system has to take into account the braking characteristics in different weather conditions. Domain requirements be new functional requirements, constraints on existing requirements or define specific computations. If domain requirements are not satisfied, the system may be unworkable. Chapter 4 Requirements engineering 21 Domain requirements problems Understandability Requirements are expressed in the language of the application domain; This is often not understood by software engineers developing the system. Implicitness Domain specialists understand the area so well that they do not think of making the domain requirements explicit. Chapter 4 Requirements engineering 22 Key points Requirements for a software system set out what the system should do and define constraints on its operation and implementation. Functional requirements are statements of the services that the system must provide or are descriptions of how some computations must be carried out. Non-functional requirements often constrain the system being developed and the development process being used. They often relate to the emergent properties of the system and therefore apply to the system as a whole. Chapter 4 Requirements engineering 23 Chapter 4 – Requirements Engineering Lecture 2 Chapter 4 Requirements engineering 24 The software requirements document The software requirements document is the official statement of what is required of the system developers. Should include both a definition of user requirements and a specification of the system requirements. It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it. Chapter 4 Requirements engineering 25 Agile methods and requirements Many agile methods argue that producing a requirements document is a waste of time as requirements change so quickly. The document is therefore always out of date. Methods such as XP use incremental requirements engineering and express requirements as ‘user stories’ (discussed in Chapter 3). This is practical for business systems but problematic for systems that require a lot of pre-delivery analysis (e.g. critical systems) or systems developed by several teams. Chapter 4 Requirements engineering 26 Users of a requirements document Chapter 4 Requirements engineering 27 Requirements document variability Information in requirements document depends on type of system and the approach to development used. Systems developed incrementally will, typically, have less detail in the requirements document. Requirements documents standards have been designed e.g. IEEE standard. These are mostly applicable to the requirements for large systems engineering projects. Chapter 4 Requirements engineering 28 The structure of a requirements document Chapter Description Preface This should define the expected readership of the document and describe its version history, including a rationale for the creation of a new version and a summary of the changes made in each version. Introduction This should describe the need for the system. It should briefly describe the system’s functions and explain how it will work with other systems. It should also describe how the system fits into the overall business or strategic objectives of the organization commissioning the software. Glossary This should define the technical terms used in the document. You should not make assumptions about the experience or expertise of the reader. User requirements Here, you describe the services provided for the user. The nonfunctional definition system requirements should also be described in this section. This description may use natural language, diagrams, or other notations that are understandable to customers. Product and process standards that must be followed should be specified. System architecture This chapter should present a high-level overview of the anticipated system architecture, showing the distribution of functions across system modules. Architectural components that are reused should be highlighted. Chapter 4 Requirements engineering 29 The structure of a requirements document Chapter Description System This should describe the functional and nonfunctional requirements in more detail. requirements If necessary, further detail may also be added to the nonfunctional requirements. specification Interfaces to other systems may be defined. System models This might include graphical system models showing the relationships between the system components and the system and its environment. Examples of possible models are object models, data-flow models, or semantic data models. System evolution This should describe the fundamental assumptions on which the system is based, and any anticipated changes due to hardware evolution, changing user needs, and so on. This section is useful for system designers as it may help them avoid design decisions that would constrain likely future changes to the system. Appendices These should provide detailed, specific information that is related to the application being developed; for example, hardware and database descriptions. Hardware requirements define the minimal and optimal configurations for the system. Database requirements define the logical organization of the data used by the system and the relationships between data. Index Several indexes to the document may be included. As well as a normal alphabetic index, there may be an index of diagrams, an index of functions, and so on. Chapter 4 Requirements engineering 30 Requirements specification The process of writing don the user and system requirements in a requirements document. User requirements have to be understandable by end- users and customers who do not have a technical background. System requirements are more detailed requirements and may include more technical information. The requirements may be part of a contract for the system development It is therefore important that these are as complete as possible. Chapter 4 Requirements engineering 31 Ways of writing a system requirements specification Notation Description Natural language The requirements are written using numbered sentences in natural language. Each sentence should express one requirement. Structured natural The requirements are written in natural language on a standard form or language template. Each field provides information about an aspect of the requirement. Design description This approach uses a language like a programming language, but with more languages abstract features to specify the requirements by defining an operational model of the system. This approach is now rarely used although it can be useful for interface specifications. Graphical notations Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used. Mathematical These notations are based on mathematical concepts such as finite-state specifications machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract Chapter 4 Requirements engineering 32 Requirements and design In principle, requirements should state what the system should do and the design should describe how it does this. In practice, requirements and design are inseparable A system architecture may be designed to structure the requirements; The system may inter-operate with other systems that generate design requirements; The use of a specific architecture to satisfy non-functional requirements may be a domain requirement. This may be the consequence of a regulatory requirement. Natural language specification Requirements are written as natural language sentences supplemented by diagrams and tables. Used for writing requirements because it is expressive, intuitive and universal. This means that the requirements can be understood by users and customers. Chapter 4 Requirements engineering 34 Guidelines for writing requirements Invent a standard format and use it for all requirements. Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements. Use text highlighting to identify key parts of the requirement. Avoid the use of computer jargon. Include an explanation (rationale) of why a requirement is necessary. Problems with natural language Lack of clarity Precision is difficult without making the document difficult to read. Requirements confusion Functional and non-functional requirements tend to be mixed-up. Requirements amalgamation Several different requirements may be expressed together. Example requirements for the insulin pump software system 3.2 The system shall measure the blood sugar and deliver insulin, if required, every 10 minutes. (Changes in blood sugar are relatively slow so more frequent measurement is unnecessary; less frequent measurement could lead to unnecessarily high sugar levels.) 3.6 The system shall run a self-test routine every minute with the conditions to be tested and the associated actions defined in Table 1. (A self-test routine can discover hardware and software problems and alert the user to the fact the normal operation may be impossible.) Chapter 4 Requirements engineering 37 Structured specifications An approach to writing requirements where the freedom of the requirements writer is limited and requirements are written in a standard way. This works well for some types of requirements e.g. requirements for embedded control system but is sometimes too rigid for writing business system requirements. Chapter 4 Requirements engineering 38 Form-based specifications Definition of the function or entity. Description of inputs and where they come from. Description of outputs and where they go to. Information about the information needed for the computation and other entities used. Description of the action to be taken. Pre and post conditions (if appropriate). The side effects (if any) of the function. A structured specification of a requirement for an insulin pump Chapter 4 Requirements engineering 40 A structured specification of a requirement for an insulin pump Chapter 4 Requirements engineering 41 Tabular specification Used to supplement natural language. Particularly useful when you have to define a number of possible alternative courses of action. For example, the insulin pump systems bases its computations on the rate of change of blood sugar level and the tabular specification explains how to calculate the insulin requirement for different scenarios. Tabular specification of computation for an insulin pump Condition Action Sugar level falling (r2 < r1) CompDose = 0 Sugar level stable (r2 = r1) CompDose = 0 Sugar level increasing and rate of CompDose = 0 increase decreasing ((r2 – r1) < (r1 – r0)) Sugar level increasing and rate of CompDose = increase stable or increasing round ((r2 – r1)/4) ((r2 – r1) ≥ (r1 – r0)) If rounded result = 0 then CompDose = MinimumDose Chapter 4 Requirements engineering 43 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. Chapter 4 Requirements engineering 44 A spiral view of the requirements engineering process Chapter 4 Requirements engineering 45 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. Chapter 4 Requirements engineering 46 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. Chapter 4 Requirements engineering 47 Requirements elicitation and analysis 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, Requirements classification and organization, Requirements prioritization and negotiation, Requirements specification. Chapter 4 Requirements engineering 48 The requirements elicitation and analysis process Chapter 4 Requirements engineering 49 Process activities Requirements discovery Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage. Requirements classification and organisation Groups related requirements and organises them into coherent clusters. Prioritisation 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 elicitation 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 change. Key points The software requirements document is an agreed statement of the system requirements. It should be organized so that both system customers and software developers can use it. The requirements engineering process is an iterative process including requirements elicitation, specification and validation. Requirements elicitation and analysis is an iterative process that can be represented as a spiral of activities – requirements discovery, requirements classification and organization, requirements negotiation and requirements documentation. Chapter 4 Requirements engineering 52 Chapter 4 – Requirements Engineering Lecture 3 Chapter 4 Requirements engineering 53 Requirements discovery 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. Chapter 4 Requirements engineering 54 Stakeholders in the MHC-PMS 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. Chapter 4 Requirements engineering 55 Stakeholders in the MHC-PMS 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. Chapter 4 Requirements engineering 56 Interviewing Formal or informal interviews with stakeholders are part of most RE processes. Types of interview Closed interviews based on pre-determined list of questions Open interviews where various issues are explored with stakeholders. Effective interviewing Be open-minded, avoid pre-conceived ideas about the requirements 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. Chapter 4 Requirements engineering 57 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 Scenarios are real-life examples of how a system can be used. They should include A description of the starting situation; A description of the normal flow of events; A description of what can go wrong; Information about other concurrent activities; A description of the state when the scenario finishes. 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. Chapter 4 Requirements engineering 60 Use cases for the MHC-PMS Chapter 4 Requirements engineering 61 Requirements validation Concerned with demonstrating that the requirements define the system that the customer really wants. Requirements error costs are high so validation is very important Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error. Chapter 4 Requirements engineering 62 Requirements checking Validity. Does the system provide the functions which best support the customer’s needs? Consistency. Are there any requirements conflicts? Completeness. Are all functions required by the customer included? Realism. Can the requirements be implemented given available budget and technology Verifiability. Can the requirements be checked? Chapter 4 Requirements engineering 63 Requirements validation techniques Requirements reviews Systematic manual analysis of the requirements. Prototyping Using an executable model of the system to check requirements. Covered in Chapter 2. Test-case generation Developing tests for requirements to check testability. Chapter 4 Requirements engineering 64 Requirements reviews Regular reviews should be held while the requirements definition is being formulated. Both client and contractor staff should be involved in reviews. Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage. Chapter 4 Requirements engineering 65 Review checks Verifiability Is the requirement realistically testable? Comprehensibility Is the requirement properly understood? Traceability Is the origin of the requirement clearly stated? Adaptability Can the requirement be changed without a large impact on other requirements? Chapter 4 Requirements engineering 66 Requirements management Requirements management is the process of managing changing requirements during the requirements engineering process and system development. New requirements emerge as a system is being developed and after it has gone into use. You need to keep track of individual requirements and maintain links between dependent requirements so that you can assess the impact of requirements changes. You need to establish a formal process for making change proposals and linking these to system requirements. Chapter 4 Requirements engineering 67 Changing requirements The business and technical environment of the system always changes after installation. New hardware may be introduced, it may be necessary to interface the system with other systems, business priorities may change (with consequent changes in the system support required), and new legislation and regulations may be introduced that the system must necessarily abide by. The people who pay for a system and the users of that system are rarely the same people. System customers impose requirements because of organizational and budgetary constraints. These may conflict with end-user requirements and, after delivery, new features may have to be added for user support if the system is to meet its goals. Chapter 4 Requirements engineering 68 Changing requirements Large systems usually have a diverse user community, with many users having different requirements and priorities that may be conflicting or contradictory. The final system requirements are inevitably a compromise between them and, with experience, it is often discovered that the balance of support given to different users has to be changed. Chapter 4 Requirements engineering 69 Requirements evolution Chapter 4 Requirements engineering 70 Requirements management planning Establishes the level of requirements management detail that is required. Requirements management decisions: Requirements identification Each requirement must be uniquely identified so that it can be cross-referenced with other requirements. A change management process This is the set of activities that assess the impact and cost of changes. I discuss this process in more detail in the following section. Traceability policies These policies define the relationships between each requirement and between the requirements and the system design that should be recorded. Tool support Tools that may be used range from specialist requirements management systems to spreadsheets and simple database systems. Chapter 4 Requirements engineering 71 Requirements change management Chapter 4 Requirements engineering 72 Key points You can use a range of techniques for requirements elicitation including interviews, scenarios, use-cases and ethnography. Requirements validation is the process of checking the requirements for validity, consistency, completeness, realism and verifiability. Business, organizational and technical changes inevitably lead to changes to the requirements for a software system. Requirements management is the process of managing and controlling these changes. Chapter 4 Requirements engineering 73 Chapter 5 – System Modeling Lecture 1 Chapter 5 System modeling 1 Topics covered Context models Interaction models Structural models Behavioral models Model-driven engineering Chapter 5 System modeling 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. System modeling has now come to mean representing a system using some kind of graphical notation, which is now almost always based on notations in the Unified Modeling Language (UML). System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers. Chapter 5 System modeling 3 UML diagram types Activity diagrams, which show the activities involved in a process or in data processing. Use case diagrams, which show the interactions between a system and its environment. Sequence diagrams, which show interactions between actors and the system and between system components. Class diagrams, which show the object classes in the system and the associations between these classes. State diagrams, which show how the system reacts to internal and external events. Chapter 5 System modeling 4 Use of graphical models As a means of facilitating discussion about an existing or proposed system ▪ Incomplete and incorrect models are OK as their role is to support discussion. As a way of documenting an existing system ▪ Models should be an accurate representation of the system but need not be complete. As a detailed system description that can be used to generate a system implementation ▪ Models have to be both correct and complete. Chapter 5 System modeling 5 Context models Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries. Social and organisational concerns may affect the decision on where to position system boundaries. Architectural models show the system and its relationship with other systems. Chapter 5 System modeling 6 System boundaries System boundaries are established to define what is inside and what is outside the system. ▪ They show other systems that are used or depend on the system being developed. The position of the system boundary has a profound effect on the system requirements. Defining a system boundary is a political judgment ▪ There may be pressures to develop system boundaries that increase / decrease the influence or workload of different parts of an organization. Chapter 5 System modeling 7 The context of the MHC-PMS Chapter 5 System modeling 8 Process model of involuntary detention Chapter 5 System modeling 9 Interaction models Modeling user interaction is important as it helps to identify user requirements. Modeling system-to-system interaction highlights the communication problems that may arise. Modeling component interaction helps us understand if a proposed system structure is likely to deliver the required system performance and dependability. Use case diagrams and sequence diagrams may be used for interaction modelling. Chapter 5 System modeling 10 Use case modeling Use cases were developed originally to support requirements elicitation and now incorporated into the UML. Each use case represents a discrete task that involves external interaction with a system. Actors in a use case may be people or other systems. Represented diagrammatically to provide an overview of the use case and in a more detailed textual form. Chapter 5 System modeling 11 Transfer-data use case A use case in the MHC-PMS use case actor actor Chapter 5 System modeling 12 Tabular description of the ‘Transfer data’ use- case MHC-PMS: Transfer data Actors Medical receptionist, patient records system (PRS) Description A receptionist may transfer data from the MHC-PMS to a general patient record database that is maintained by a health authority. The information transferred may either be updated personal information (address, phone number, etc.) or a summary of the patient’s diagnosis and treatment. Data Patient’s personal information, treatment summary Stimulus User command issued by medical receptionist Response Confirmation that PRS has been updated Comments The receptionist must have appropriate security permissions to access the patient information and the PRS. Chapter 5 System modeling 13 Use cases in the MHC-PMS involving the role ‘Medical Receptionist’ Chapter 5 System modeling 14 Sequence diagrams Sequence diagrams are part of the UML and are used to model the interactions between the actors and the objects within a system. A sequence diagram shows the sequence of interactions that take place during a particular use case or use case instance. The objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these. Interactions between objects are indicated by annotated arrows. Chapter 5 System modeling 15 Sequence diagram for View patient information actor objects Chapter 5 System modeling 16 Sequence diagram for Transfer Data interaction Chapter 5 System modeling 17 Structural models Structural models of software display the organization of a system in terms of the components that make up that system and their relationships. Structural models may be static models, which show the structure of the system design, or dynamic models, which show the organization of the system when it is executing. You create structural models of a system when you are discussing and designing the system architecture. Chapter 5 System modeling 18 Class diagrams Class diagrams are used when developing an object- oriented system model to show the classes in a system and the associations between these classes. An object class can be thought of as a general definition of one kind of system object. An association is a link between classes that indicates that there is some relationship between these classes. When you are developing models during the early stages of the software engineering process, objects represent something in the real world, such as a patient, a prescription, doctor, etc. Chapter 5 System modeling 19 UML classes and association Chapter 5 System modeling 20 Classes and associations in the MHC-PMS Chapter 5 System modeling 21 The Consultation class Chapter 5 System modeling 22 Key points A model is an abstract view of a system that ignores system details. Complementary system models can be developed to show the system’s context, interactions, structure and behavior. Context models show how a system that is being modeled is positioned in an environment with other systems and processes. Use case diagrams and sequence diagrams are used to describe the interactions between users and systems in the system being designed. Use cases describe interactions between a system and external actors; sequence diagrams add more information to these by showing interactions between system objects. Structural models show the organization and architecture of a system. Class diagrams are used to define the static structure of classes in a system and their associations. Chapter 5 System modeling 23
