Requirements Engineering Processes Processes used to discover analysis

Requirements Engineering Processes ² Processes used to discover, analysis and validate system requirements Chapter 4 Requirements engineering 1

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 a number of generic activities common to all processes. These focus on assessing if the system is useful to the business (feasibility study), discovering requirements (elicitation and analysis), converting these requirements into some standard form (specification), and checking that the requirements actually define the system that the customer wants (validation). Chapter 4 Requirements engineering 2

Requirements engineering processes ² The processes used for requirements engineering vary widely depending on the application domain, the people involved and the organization developing the requirements. ² However, there a number of generic activities common to all processes § Requirements elicitation § Requirements specification § Requirements validation § Requirements management ² In practice, requirements engineering is an iterative activity in which these processes are interleaved. Chapter 4 Requirements engineering 3

Requirements engineering processes Chapter 4 Requirements engineering 4

The requirements engineering process Chapter 4 Requirements engineering 5

Feasibility studies A feasibility study is a short, focused study that should take place early in the RE process. For each new system RE starts with this study A short focused study that checks If the system contributes to organisational objectives If the system can be engineered using current technology and within budget If the system can be integrated with other systems that are used If the answer to any of these questions is no, you should probably not go ahead with the project. 6 Chapter 4 Requirements engineering 6

Feasibility study implementation The aims of a feasibility study are to find out whether the system is worth implementing and if it can be implemented, given the existing budget and schedule. Carrying out a feasibility study involves information assessment, information collection and report writing. The information assessment phase identifies the information that is required to answer the three questions set out above. Once the information has been identified, you should question information sources (mangers, software engineers, technology experts, end users) to discover the answers to these questions. Some examples of possible questions that might ask: What if the system wasn’t implemented? ﻣﺎﺫﺍ ﻟﻮ ﻟﻢ ﻳﻨﻔﺬ ﺍﻟﻨﻈﺎﻡ؟ What are current process problems? ﺑﺪﻭﻥ ﺍﻟﻨﻈﺎﻡ ﺍﻟﻤﻘﺘﺮﺡ - ﻣﺎ ﻫﻲ ﺍﻟﻤﺸﺎﻛﻞ ﺍﻟﺤﺎﻟﻴﺔ؟ How will the proposed system help? ﻛﻴﻒ ﺳﻴﺴﺎﻋﺪ ﺍﻟﻨﻈﺎﻡ ﺍﻟﻤﻘﺘﺮﺡ ﻋﻠﻰ ﺣﻞ ﺍﻟﻤﺸﺎﻛﻞ ﺍﻟﺤﺎﻟﻴﻪ؟ What will be the integration problems? ﻣﺎ ﻫﻲ ﻣﺸﺎﻛﻞ ﺍﻻﻧﺪﻣﺎﺝ؟ Is new technology needed? What skills? ﻫﻞ ﺗﺤﺘﺎﺝ ﺍﻟﻰ ﺗﻜﻨﻮﻟﻮﺟﻴﺎ ﺟﺪﻳﺪﺓ ؟ 7 What facilities must be supported by the proposed system? ﻣﺎ ﻫﻲ ﺍﻟﺘﺴﻬﻴﻼﺕ ﺍﻟﺘﻲ ﻳﻤﻜﻦ ﺍﻥ ﻳﺪﻋﻤﻬﺎ ﺍﻟﻨﻈﺎﻡ ﺍﻟﻤﻘﺘﺮﺡ؟

Feasibility study implementation ² When the information is available, you then write the feasibility study report. You should make a recommendation about whether or not the system development should continue. In the report, you may propose changes to the scope, budget and schedule of the system and suggest further high-level requirements for the system. Chapter 4 Requirements engineering 8

Requirements elicitation and analysis ² Sometimes called requirements elicitation or requirements discovery. ² In this activity, software engineers work with customers and system end-users to find out about the application domain, what services the system should provide, the required performance of the system, hardware constraints, and so on. ² May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders. Chapter 4 Requirements engineering 9

Requirements elicitation and analysis ² Stages include: § § Requirements discovery, Requirements classification and organization, Requirements prioritization and negotiation, Requirements specification. Chapter 4 Requirements engineering 10

The requirements elicitation and analysis process • The Figure shows that requirements elicitation and analysis is an iterative process with continual feedback from each activity to other activities. • The process cycle starts with requirements discovery and ends with the requirements documentation. • The analyst’s understanding of the requirements improves with each round of the cycle. • The cycle ends when the requirements document is complete. Chapter 4 Requirements engineering 11

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 Eliciting and understanding requirements from system stakeholders is a difficult process for several reasons: ² 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.

Requirements discovery ² The process of gathering information about the required and existing systems and distilling the user and system requirements from this information. ² Sources of information include documentation, system stakeholders and the specifications of similar systems. ² Interaction is with system stakeholders from managers to external regulators. ² Systems normally have a range of stakeholders. Chapter 4 Requirements engineering 14

Banking ATM system ² The example used here is an auto-teller system which provides some automated banking services ² Usage of a very simplified system which offers some services to customers of the bank that owns the system and a narrower range of services to other customers ² Services include cash withdrawal, message passing (send a message to request a service), ordering a statement and transferring funds Chapter 4 Requirements engineering 15

ATM stakeholders 1. Current bank customers who receive services from the system 2. Representatives from other banks who have reciprocal agreements that allow each other’s ATMs to be used 3. Managers of bank branches who obtain management information from the system 4. Counter staff at bank branches who are involved in the day-to-day running of the system 5. Database administrators who are responsible for integrating the system with the bank’s customer database 6. Bank security managers who must ensure that the system will not pose a security hazard 7. The bank’s marketing department who are likely be interested in using the system as a means of marketing the bank 8. Hardware and software maintenance engineers who are responsible for maintaining and upgrading the hardware and software 9. National banking regulators who are responsible for ensuring that the system conforms to banking regulations Chapter 4 Requirements engineering 16

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 17

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 18

Viewpoint-oriented elicitation ² Different stakeholders have different views on the importance and priority of requirements and, sometimes, these views are conflicting ² Stakeholders represent different ways of looking at a problem or problem viewpoints ² Viewpoints are a way of structuring the requirements to represent the perspectives of different stakeholders. ² A key strength of viewpoint-oriented analysis is that it recognises the existence of multiple perspectives and provides a framework for discovering conflicts in the requirements proposed by different stakeholders. ² Viewpoints can be used as a way of classifying different types of stakeholder and other sources of requirements so that compromises can be reached 19

Types of viewpoint ² Interactor viewpoints § People or other systems that interact directly with the system. § In an ATM, the customers and the account database are interactor VPs. ² Indirect viewpoints § Stakeholders who do not use the system themselves but who influence the requirements. In an ATM, management and security staff are indirect viewpoints. ² Domain viewpoints § Domain characteristics and constraints that influence the requirements. In an ATM, an example would be standards for interbank communications. Chapter 4 Requirements engineering 20

viewpoint ² Typically, these viewpoints will provide different types of requirement. ² Interactor viewpoints provide detailed system requirements covering the system features and interfaces. ² Indirect viewpoints are more likely to provide higher-level organisational requirements and constraints. ² Domain viewpoints normally provide domain constraints that apply to the system. Chapter 4 Requirements engineering 21

Viewpoint identification ² The initial identification of viewpoints that are relevant to a system can sometimes be difficult. To help with this process, you should try to identify viewpoints of different types: ² Providers and receivers of system services ² Systems that should interface directly with the system being specified. ² Regulations and standards that apply to the system. ² The sources of system business and non-functional requirements. ² Engineering viewpoints who have to develop, manage and maintain the system. ² Marketing and other business viewpoints ² Once viewpoints have been identified and structured, you should try to identify the most important viewpoints and start with them when discovering system requirements. Chapter 4 Requirements engineering 22

LIBSYS viewpoint hierarchy Chapter 4 Requirements engineering 23

Interviewing ² Formal or informal interviews with stakeholders are part of most RE processes. ² In these interviews, the requirements engineering team puts questions to stakeholders about the system that they currently use and the system to be developed. ² Requirements are derived from the answers to these questions. ² 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 Chapter 4 Requirements engineering 24 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.

Interview questionnaires Chapter 4 Requirements engineering 26

Interview questionnaires Chapter 4 Requirements engineering 27

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.

Scenario for collecting medical history in MHC-PMS Chapter 4 Requirements engineering 29

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. ² Sequence diagrams may be used to add detail to usecases by showing the sequence of event processing in the system. Chapter 4 Requirements engineering 30

Use cases for the MHC-PMS Chapter 4 Requirements engineering 31

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. Chapter 4 Requirements engineering 32

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. Chapter 4 Requirements engineering 33

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 34

Requirements checking ² During the requirements validation process, different types of checks should be carried out on the requirements in the requirements document. These checks include: ² 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 35

Requirements validation techniques ² Requirements reviews § Systematic manual analysis of the requirements. ² Prototyping § Using an executable model of the system to check requirements. ² Test-case generation § Developing tests for requirements to check testability. § Tests difficult to implement reveal potential difficulty of implementing requirements Chapter 4 Requirements engineering 36

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 37

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 38

Requirements management ² Requirements management is the process of managing changing requirements during the requirements engineering process and system development. ² Requirements are inevitably incomplete and inconsistent ² New requirements emerge during the process as business needs change and a better understanding of the system is developed ² Different viewpoints have different requirements and these are often contradictory Chapter 4 Requirements engineering 39

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 40

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 41

Requirements evolution Chapter 4 Requirements engineering 42

Requirements management planning ² Planning is an essential first stage in the requirements management process. Establishes the level of requirements management detail that is required. ² During the requirements management stage, you have to decide on: § 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. § 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 43 database systems. Chapter 4 Requirements engineering

Traceability ² Traceability is concerned with the relationships between requirements, their sources and the system design ² Source traceability § Links from requirements to stakeholders who proposed these requirements ² Requirements traceability § Links between dependent requirements to assess how many other requirements will be affected ² Design traceability § Links from the requirements to the design modules that implement them Chapter 4 Requirements engineering 44

A traceability matrix Used to represent traceability information (for a small number of reqs) ü A “U” is used when a req. in a row uses the facilities of the req. in the column ü An “R” is used when there is a weaker relationship (e. g. reqs are part 45 of the same sub-system) Chapter 4 Requirements engineering 45

CASE tool support ² Requirements storage § Requirements should be managed in a secure, managed data store ² Change management § The process of change management is a workflow process whose stages can be defined and information flow between these stages partially automated ² Traceability management § Automated retrieval of the links between requirements Chapter 4 Requirements engineering 46

Requirements change management ² Deciding if a requirements change should be accepted § Problem analysis and change specification • During this stage, the problem or the change proposal is analyzed to check that it is valid. This analysis is fed back to the change requestor who may respond with a more specific requirements change proposal, or decide to withdraw the request. § Change analysis and costing • The effect of the proposed change is assessed using traceability information and general knowledge of the system requirements. Once this analysis is completed, a decision is made whether or not to proceed with the requirements change. § Change implementation • The requirements document and, where necessary, the system design and implementation, are modified. Ideally, the document should be organized so that changes can be easily implemented. Chapter 4 Requirements engineering 47

Requirements change management Chapter 4 Requirements engineering 48

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 49