Chapter 7 R equirements E ngineering Processes Haya Sammaneh

1. Chapter 7Requirements Engineering ProcessesHaya Sammaneh

2. Objectives • To describe the principal of requirements engineering activities and their relationship • To introduce techniques for requirements elicitation and analysis • To understand the importance of requirements validation

3. Topics covered • Feasibility studies • Requirements elicitation and analysis • Requirements validation • Requirements management

4. Requirements Engineering processes • The processes used for RE vary widely depending on the application domain, the people involved and the organization developing the requirements • However, there are a number of generic activitiescommon to all processes • Feasibility study • Requirements elicitation and analysis • requirements specification and system modeling. • Requirements validation • Requirements management

5. The requirements engineering process

6. The Spiral model of requirements engineering Process

7. 7.1 Feasibility studies • A feasibility study decides whether or not the proposed system is worthwhile • A short focused study that checks • If the system contributes to organizational 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

8. Feasibility study implementation • Based on information assessment , information collection and report writing • Questions for people in the organization • 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 facilities must be supported by the proposed system?

9. 7.2 Requirements Elicitation (discovery) and analysis • Involvestechnical staff working with customers, the services that the system should provide and the system’s operational constraints • May involveend-users, managers, engineersThese are called stakeholders

10. 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 • Organizational and politicalfactors may influence the system requirements • The requirements change during the analysis process. New stakeholders may emerge and the business environment change

11. The requirements analysis process

12. The requirements Analysis Spiral

13. requirements analysis Process (activities) • Requirements collection, interact with stakeholders, domain requirements (understanding). • Classification and organization, organize requirement in a structure one (coherent cluster). • Conflict resolution, resolving the conflict. • Prioritization, prioritize requirements. • Requirements checking and documentation, checking for completion, consistency, and in accordance with what stakeholder really wants, then documented for the next phase.

14. 7.2.1 Requirements discovery(Viewpoints, interview , scenario, use case) • The process of gathering information about the proposed and existing systems and eliciting the user and system requirements from this information. • Sources of information include documentation, system stakeholders and the specifications of similar systems.

15. a. Viewpoint-oriented approach • Stakeholdersrepresent different ways of looking at a problem • Viewpoints are a way of structuring the requirements to represent the perspectives of different stakeholders.. • This multi-perspective analysisis important as there is no single correct way to analyze system requirements.

16. Example - Banking (auto-teller system )ATM system • The example used here is an auto-teller system which provides some automated banking services • we use a very simplified system which offers some services to customers of the bank who own 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

17. Auto-tellerviewpoints • Bank customers • Representatives of other banks: allow other ATM to be used • Hardware and software maintenance engineers • Marketing department • Bank managers and staff • Database administrators and security staff • Communications engineers • Personnel department Stakeholder + domain + system can be represented as system viewpoints

18. Types (Models) of viewpoint • Interactor viewpoints • People or other systems that interact directly with the system. • In an ATM, the customer’sand the account database are interactor VPs. • Indirect viewpoints • Stakeholders who do not use the system themselves but who influence the requirements. • In an ATM, managementand security staff are indirect viewpoints. • Domain viewpoints • Domain characteristics and constraintsthat influence the requirements. • In an ATM, the standards for inter-bank communications.

19. LIBSYS viewpoint hierarchy

20. Viewpoint process model • Viewpoint identification: discover viewpoints which receive system services and identify the services provided to each viewpoint using: • Providers and receivers of system services; • Systems that interact directly with the system being specified; • Regulations and standards; • Engineers who have to develop and maintain the system; • Marketing and other business viewpoints.

21. Viewpoint process model, cont • Viewpoint structuring, group related viewpoints into a hierarchy. Common services are provided at higher-levels in the hierarchy • Viewpoint documentation, refine the description of the identified viewpoints and services • Viewpoint-system mapping, transform the analysis to an object-oriented design

22. Viewpoint identification

23. b. Interviewing • In formal or informal interviewing, the RE teamputs questions to stakeholdersabout the system. • There are two types of interview • Closed interviews where a pre-defined set of questions are answered. • Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.

24. 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 interact with the system.

25. Effective interviewers • Interviewers should be open-minded, willing to listen to stakeholders and should not have pre- ideas about the requirements. • They should prompt the interviewee with a question or a proposal and should not simply expect them to respond to a question such as ‘what do you want’.

26. c. Scenarios • Scenarios are descriptions ofhow a system is used in practice, a real-life examples of how a system can be used. • Scenarios are particularly useful for adding detail to an outline requirements description

27. Scenario include: • description of the system state at the beginning of the scenario • Normal flow of events in the scenario • What can go wrong and how this is handled • Other concurrent activities • description of the System state on completion of the scenario

28. Event scenarios • Event scenarios may be used to describe how a system responds to the occurrence of some particular event such as ‘start transaction’

29. Event scenarios, cont… • The diagrammatic notations used in event scenarios are: • Data provided and deliveredfrom/to a viewpoint is shown in ellipses. • Control information, enter and leave at the top of each box. • Exception processing, shown at the bottom of the box. • Name of the next expected event is shown in a shaded box

30. Event scenario - start transaction

31. Exception description • In the previous example, exceptions are: • Timeout, customer fails to enter a PIN within the allowed time limit • Invalid card, the card is not recognized and is returned • Stolen card, the card has been registered as stolen and is retained by the machine

32. c. Use cases • Use-cases are a scenario based technique for requirement elicitation in the UML notations that used in object-oriented system model (Unified Modelling Language) 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 • Sequence diagrams may be used to add detail to use-cases by showing the sequence of event in the system

33. Use cases, cont.. • The sequence diagram (ch 6) is used to add information to use-case. • The sequence diagram shows the: 1- actors used in the interaction 2- objects that the actors interact with. 3- operation associated with these objects.

34. Library system , example. • Interaction for downloading and printing article. • Objects used in this interaction are: 1. Article 2. Form 3. workspace 4. printer

35. Lending use-case

36. use-cases for Library system

37. Example of sequence diagram of Printing article.

38. 7.3 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 errorafter deliverymay cost up to 100 times the cost of fixing an implementation error • Change requirement error means change system design and implementation

39. Requirements checking(types of checks should be carried out on requirements) • 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? In order to reduce potential dispute نزاع between customers. Should be write a set of test that can be demonstrate that the delivered system meet each specified requirements.

40. Requirements validationtechniques • 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 of requirement. • Automated consistency analysis , checking the consistency of a structured requirements description, if the requirements are expressed in structured or formal notation, then CASE tool may be used to check the consistency.

41. 6.3.1 Requirementsreviews • 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 can resolve problems at an early stage

42. Review checks: • Verifiability. Is the requirement realistically testable? • Comprehensibility. Is the requirement properly understood? • Trace-ability. Is the source of the requirement clearly stated? • Adaptability. Can the requirement be changed without a large impact on other requirements?

43. 7.4 Requirements management • Requirements management is the process of managing changing requirementsduring the requirements engineering process andsystem development • Requirements are inevitably incomplete and inconsistent because: • New requirements emerge during the process because business needs change and a better understanding of the system is developed • Different viewpoints have different requirements and these are often contradictory

44. Requirements change because of: • Thepriority of requirements from different viewpoints changes during the development process • System customers may specify requirements from a business perspective that conflict with end-user requirements. • (customers-people who pay for the system- and end-user - people who use the system- usually different) • The business and technical environment of the system changes during its development

45. 7.4.1 Enduring and volatile requirements • Enduring requirements.Stable requirements derived from the core activity of the customer organization. E.g. a hospital will always have doctors, nurses, etc. • Volatile requirements. Requirements which changeduring development or when the system is in use. In a hospital, requirements derived from health-care policy

46. Classification of Volatile requirements • Mutable متقلب requirements, requirements that change due to the changing of system’s environment • Emergent requirements, requirements that emerge as understanding of the system develops during the system development.

47. Classification of Volatile requirements • Consequential requirements, requirements that result from the introduction of the computersystem that result to new process which may generate new requirements. • Compatibility requirements, requirements that depend on other systems

48. 7.4.2 Requirements management planning • During the requirements engineering process, you have to plan on: • Requirements identification, how requirements are individually identified • A change management process, the process followed when analyzing a requirements change (the impact and cost of change)

49. Requirements management planning, cont.. • Traceability policies, the amount of information about requirements relationships are recorded and how it should be maintained • CASE toolsupport which required to help manage requirements change, using spreadsheets and databases.

50. Traceability • Traceability is concerned with the relationships between requirements, their sources andrelationships between requirements and the system design • There are three types of traceability: • Source traceability, links from requirements to stakeholders who proposed these requirements • Requirements traceability, links between dependent requirements • Design traceability, links from the requirements to the design,