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

2. 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. 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

3. 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 are 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

4. Requirements engineering processes
Chapter 4 Requirements engineering

5. Chapter 4 Requirements engineering
The requirements engineering process
Chapter 4 Requirements engineering

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

7. 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?
هل تحتاج الى تكنولوجيا جديدة ؟
What facilities must be supported by the proposed system?
ما هي التسهيلات التي يمكن ان يدعمها النظام المقترح؟

8. 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

9. 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

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

11. 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

12. Requirements discovery
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.

13. 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.

14. 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

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

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

17. 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

18. 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

19. 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

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

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

22. 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

23. LIBSYS viewpoint hierarchy
Chapter 4 Requirements engineering

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

25. 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.

26. Interview questionnaires
Chapter 4 Requirements engineering

27. Interview questionnaires
Chapter 4 Requirements engineering

28. 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.

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

30. Chapter 4 Requirements engineering
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 use- cases by showing the sequence of event processing in the system.
Chapter 4 Requirements engineering

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

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

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

34. 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 times the cost of fixing an implementation error.
Chapter 4 Requirements engineering

35. 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

36. 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

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

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

39. 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

40. 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

41. 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

42. Requirements evolution
Chapter 4 Requirements engineering

43. 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 database systems.
Chapter 4 Requirements engineering

44. 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

45. Chapter 4 Requirements engineering
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 of the same sub-system) 45
Chapter 4 Requirements engineering

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

47. 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

48. Requirements change management
Chapter 4 Requirements engineering

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