Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Requirements Engineering Processes                        Loganathan R
Objectives• To describe the principal requirements  engineering activities and their relationships• To introduce technique...
Requirements engineering processes• The goal of RE Process is to create & maintain a  system requirements documents.• Incl...
The requirements engineering process              RequirementsFeasibility              Elicitation and  Study             ...
Alternative perspective of RE ProcessSpiral Model of RE Process                                                           ...
Feasibility studies• A feasibility study decides whether or not the  proposed system is worthwhile.• A short focused study...
Feasibility study implementation• Feasibility study involves information assessment (what is  required), information colle...
Requirements elicitation and analysis• Involves technical staff working with customers to find out about  the application ...
E&A Process activities• Requirements discovery   – Interacting with stakeholders to discover their requirements.     Domai...
The requirements elicitation & analysis Process                                                 Requirements            Re...
Requirements discovery• The process of gathering information about the proposed and  existing systems and distilling the u...
Example : ATM stakeholders• Bank customers – who receive services• Representatives of other banks – who have reciprocal ag...
Viewpoints• Recognizes multiple perspectives and provides framework for  discovering conflicts in the requirements propose...
Viewpoint identification• Identify viewpoints using following more specific VP  types:  – Providers and receivers of syste...
LIBSYS viewpoint hierarchy                                                  All VPs          Indirect                     ...
Interviewing• Used for getting an overall understanding of what  stakeholders do, how they interact with system  and diffi...
Interviews in practice• Normally a mix of closed and open-ended interviewing.• Interviews are good for getting an overall ...
Effective interviewers Characteristics• Interviewers should be open-minded, willing to  listen to stakeholders and should ...
Scenarios• Scenarios are real-life examples of how a system can  be used.• They should include  – A description of what th...
LIBSYS scenario…Initial assumption: The user has logged on to the LIBSYS system and haslocated the journal containing the ...
LIBSYS scenario…What can go wrong: The user may fail to fill in the copyright form correctly.In this case, the form should...
Use cases• Use-cases are a scenario based technique in the  UML which identify the actors in an interaction  and which des...
Simple Use-case for Article printing• Actors is stick figures, each class of interaction is  named ellipse.               ...
Use cases for library system                  Article search   Library        Article printing    User              User a...
System interactions for article Printing                       item:           CopyrightForm     Myworkspace:         myPr...
Ethnography• Ethnography is an observational technique used to  understand social and organisational requirements.• A soci...
Focused ethnography• Developed in a project studying the air traffic  control process• Combines ethnography with prototypi...
Ethnography and prototypingEthnographic              Debriefing                   Focused  Analysis                Meeting...
Ethnography discovers 2 types of           requirements• Requirements that are derived from the way that  people actually ...
Requirements validation• Concerned with demonstrating that the  requirements define the system that the customer  really w...
Requirements checking• Validity: Does the system provide the functions which  best support the customer’s needs?• Consiste...
Requirements validation techniques• Requirements reviews  – Systematic manual analysis of the requirements.• Prototyping  ...
Requirements reviews• Regular reviews should be held while the  requirements definition is being formulated.• Both client ...
Review checks• Verifiability: Is the requirement realistically  testable?• Comprehensibility: Is the requirement properly ...
Requirements management• Requirements management is the process of managing  changing requirements during the requirements...
Requirements change• The priority of requirements from different  viewpoints changes during the development  process.• Sys...
Requirements evolution     Initial                                      ChangedUnderstanding of                           ...
Enduring and volatile requirements• Enduring requirements: Stable requirements  derived from the core activity of the cust...
Requirements classificationRequirement                                                DescriptionType                Requi...
Requirements management planning• During the requirements engineering process, you  have to plan:  – Requirements identifi...
Traceability• Traceability is concerned with the relationships between  requirements, their sources and the system design•...
A traceability matrixReq. id   1.1 1.2 1.3 2.1              2.2         2.3   3.1   3.2 1.1           D   R 1.2           ...
CASE tool support• Requirements storage  – Requirements should be managed in a secure, managed data    store.• Change mana...
Requirements change management• Should apply to all proposed changes to the  requirements.• Principal stages  – Problem an...
Change managementIdentified                                                                          Revised Problem     P...
Upcoming SlideShare
Loading in …5
×

Requirement engineering process

19,742 views

Published on

Requirement Engineering Process

Published in: Technology
  • Be the first to comment

Requirement engineering process

  1. 1. Requirements Engineering Processes Loganathan R
  2. 2. Objectives• To describe the principal requirements engineering activities and their relationships• To introduce techniques for requirements elicitation and analysis• To describe requirements validation and the role of requirements reviews• To discuss the role of requirements management in support of other requirements engineering processes Prof. Loganathan R, CSE,HKBKCE 2
  3. 3. Requirements engineering processes• The goal of RE Process is to create & maintain a system requirements documents.• Includes 4 High level RE Sub-processes: – Feasibility study : usefulness to the business ; – Elicitation and analysis : discovering requirements; – Specification: conversion of requirement into some standard form; – Validation : check the requirements which defines the system that the customer wants; Prof. Loganathan R, CSE,HKBKCE 3
  4. 4. The requirements engineering process RequirementsFeasibility Elicitation and Study Analysis Requirements SpecificationFeasibility Requirements Report Validation System Models User and System Requirements Requirements Document Prof. Loganathan R, CSE,HKBKCE 4
  5. 5. Alternative perspective of RE ProcessSpiral Model of RE Process Requirements specification System requirements specification and modeling User requirements specification Business requirements specification System requirements Feasibility User study elicitation requirements elicitation Prototyping Requirements elicitation Requirements Reviews validation System requirements document Prof. Loganathan R, CSE,HKBKCE 5
  6. 6. 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 organisational objectives; – If the system can be implemented using current technology, within given cost and schedule constraints; – If the system can be integrated with other systems that are already in place. Prof. Loganathan R, CSE,HKBKCE 6
  7. 7. Feasibility study implementation• Feasibility study involves information assessment (what is required), information collection and report writing.• Questions for people in the organisation for information assessment and collection: – 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?• Feasibility study report should make a recommendation about the development to continue or not. Prof. Loganathan R, CSE,HKBKCE 7
  8. 8. Requirements elicitation and analysis• 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.• Eliciting & understanding stakeholder requirement is difficult due to the following reasons: • Stakeholders don’t know what they really want except in most general. • Stakeholders express requirements in their own terms. • Different stakeholders may have deferent 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. Prof. Loganathan R, CSE,HKBKCE 8
  9. 9. E&A Process activities• Requirements discovery – Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.• Requirements classification and organisation – Group related requirements and organises them into coherent clusters.• Prioritisation and negotiation – Prioritising requirements and finding and resolving requirements conflicts.• Requirements documentation – Requirements are documented and input into the next round of the spiral. Prof. Loganathan R, CSE,HKBKCE 9
  10. 10. The requirements elicitation & analysis Process Requirements Requirements Prioritization & Classification & negotiation Organization Requirements Requirements Documentation Discovery Prof. Loganathan R, CSE,HKBKCE 10
  11. 11. Requirements discovery• The process of gathering information about the proposed 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.• Approaches & Techniques of requirements discovery are: – Viewpoints(approach) – Interviewing – Scenario – Use-cases – ethnography Prof. Loganathan R, CSE,HKBKCE 11
  12. 12. Example : ATM stakeholders• Bank customers – who receive services• Representatives of other banks – who have reciprocal agreements for ATM usage• Bank branch managers –who obtain management information• Counter staff – who involved in day-to-day running of system• Database administrators - who responsible for integrating system with customers database• Bank Security managers• The Bank’s Marketing department• Hardware and software maintenance engineers• Banking regulators Who ensures system conforms to banking regulations Prof. Loganathan R, CSE,HKBKCE 12
  13. 13. Viewpoints• Recognizes multiple perspectives and provides framework for discovering conflicts in the requirements proposed by different stakeholders• Viewpoints(VP) are used as a way of classifying Stakeholders and other sources of requirements.• There are 3 generic types of VP:• Interactor viewpoints – People or other systems that interact directly with the system. In an ATM, the customer’s 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 inter-bank communications. Prof. Loganathan R, CSE,HKBKCE 13
  14. 14. Viewpoint identification• Identify viewpoints using following more specific VP types: – Providers and receivers of system services; – Systems that interact directly with the system being specified; – Regulations and standards that apply to the system; – Sources of business and non-functional requirements. – Engineers who have to develop and maintain the system; – Marketing and other business viewpoints. Prof. Loganathan R, CSE,HKBKCE 14
  15. 15. LIBSYS viewpoint hierarchy All VPs Indirect Interactor DomainLibrary Article Library UI Classificationmanager Finance providers Users staff standards system System Students Staff External managers Cataloguers Prof. Loganathan R, CSE,HKBKCE 15
  16. 16. Interviewing• Used for getting an overall understanding of what stakeholders do, how they interact with system and difficulties they face with current system• In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they use and the system to be developed.• 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. Prof. Loganathan R, CSE,HKBKCE 16
  17. 17. 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. Prof. Loganathan R, CSE,HKBKCE 17
  18. 18. Effective interviewers Characteristics• Interviewers should be open-minded, willing to listen to stakeholders and should not have pre- conceived 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’. Prof. Loganathan R, CSE,HKBKCE 18
  19. 19. Scenarios• Scenarios are real-life examples of how a system can be used.• They should include – A description of what the system & user expect when the scenario starts; – A description of the normal flow of events in the scenario; – A description of what can go wrong and how this is handled; – Information about other concurrent activities; – A description of the state when the scenario finishes. Prof. Loganathan R, CSE,HKBKCE 19
  20. 20. LIBSYS scenario…Initial assumption: The user has logged on to the LIBSYS system and haslocated the journal containing the copy of the article.Normal: The user selects the article to be copied. He or she is thenprompted by the system to either provide subscriber information for thejournal or to indicate how they will pay for the article. Alternative paymentmethods are by credit card or by quoting an organisational accountnumber.The user is then asked to fill in a copyright form that maintains details ofthe transaction and they then submit this to the LIBSYS system.The copyright form is checked and, if OK, the PDF version of the article isdownloaded to the LIBSYS working area on the user’s computer and theuser is informed that it is available. The user is asked to select a printer anda copy of the article is printed. If the article has been flagged as ‘print-only’it is deleted from the user’s system once the user has confirmed thatprinting is complete. Prof. Loganathan R, CSE,HKBKCE 20
  21. 21. LIBSYS scenario…What can go wrong: The user may fail to fill in the copyright form correctly.In this case, the form should be re-presented to the user for correction. Ifthe resubmitted form is still incorrect then the user’s request for the articleis rejected.The payment may be rejected by the system. The user’s request for thearticle is rejected.The article download may fail. Retry until successful or the user terminatesthe session.It may not be possible to print the article. If the article is not flagged as‘print-only’ then it is held in the LIBSYS workspace. Otherwise, the article isdeleted and the user’s account credited with the cost of the article.Other activities: Simultaneous downloads of other articles.System state on completion: User is logged on. The downloaded article hasbeen deleted from LIBSYS workspace if it has been flagged as print -only. Prof. Loganathan R, CSE,HKBKCE 21
  22. 22. 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.• Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system. Prof. Loganathan R, CSE,HKBKCE 22
  23. 23. Simple Use-case for Article printing• Actors is stick figures, each class of interaction is named ellipse. Article printing Prof. Loganathan R, CSE,HKBKCE 23
  24. 24. Use cases for library system Article search Library Article printing User User administration Library Staff Supplier Catalogue services Prof. Loganathan R, CSE,HKBKCE 24
  25. 25. System interactions for article Printing item: CopyrightForm Myworkspace: myPrinter: Article Form Workspace Printer User request request complete return copyright OK deliver article OK print send inform confirm delete Prof. Loganathan R, CSE,HKBKCE 25
  26. 26. Ethnography• Ethnography is an observational technique used to understand social and organisational requirements.• A social scientists 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. Prof. Loganathan R, CSE,HKBKCE 26
  27. 27. Focused ethnography• Developed in a project studying the air traffic control process• Combines ethnography with prototyping• Prototype development results in unanswered questions which focus the ethnographic analysis.• The problem with ethnography is that it studies existing practices which may have some historical basis which is no longer relevant. Prof. Loganathan R, CSE,HKBKCE 27
  28. 28. Ethnography and prototypingEthnographic Debriefing Focused Analysis Meetings Ethnography Prototype Evaluation Generic System System Development Prototyping Prof. Loganathan R, CSE,HKBKCE 28
  29. 29. Ethnography discovers 2 types of requirements• 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. Prof. Loganathan R, CSE,HKBKCE 29
  30. 30. 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. Prof. Loganathan R, CSE,HKBKCE 30
  31. 31. 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? Prof. Loganathan R, CSE,HKBKCE 31
  32. 32. 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. – If test is difficult or impossible to design for the requirement means it is difficult to implement that requirement Prof. Loganathan R, CSE,HKBKCE 32
  33. 33. 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. Prof. Loganathan R, CSE,HKBKCE 33
  34. 34. 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? Prof. Loganathan R, CSE,HKBKCE 34
  35. 35. 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. Prof. Loganathan R, CSE,HKBKCE 35
  36. 36. Requirements change• The priority 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.• The business and technical environment of the system changes during its development. Prof. Loganathan R, CSE,HKBKCE 36
  37. 37. Requirements evolution Initial ChangedUnderstanding of Understanding of Problem Problem Initial Changed Requirements Requirements Time Prof. Loganathan R, CSE,HKBKCE 37
  38. 38. Enduring and volatile requirements• Enduring requirements: Stable requirements derived from the core activity of the customer organisation. E.g. a hospital will always have doctors, nurses, etc. May be derived from domain models• Volatile requirements: Requirements which change during development or when the system is in use. In a hospital, requirements derived from health-care policy Prof. Loganathan R, CSE,HKBKCE 38
  39. 39. Requirements classificationRequirement DescriptionType Requirements that change because of changes to the environment inMutable which the organisation is operating. For example, in hospital systems,requirements the funding of patient care may change and thus require different treatment information to be collected. Requirements that emerge as the customers understanding of theEmergent system develops during the system development. The design processrequirements may reveal new emergent requirements. Requirements that result from the introduction of the computerConsequential system. Introducing the computer system may change therequirements organisations processes and open up new ways of working which generate new system requirements Requirements that depend on the particular systems or businessCompatibility processes within an organisation. As these change, the compatibilityrequirements requirements on the commissioned or delivered system may also have to evolve. Prof. Loganathan R, CSE,HKBKCE 39
  40. 40. Requirements management planning• During the requirements engineering process, you have to plan: – Requirements identification • How requirements are individually identified; – A change management process • The process followed when analysing a requirements change; – Traceability policies • The amount of information about requirements relationships that is maintained; – CASE tool support • The tool support required to help manage requirements change; Prof. Loganathan R, CSE,HKBKCE 40
  41. 41. 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;• Design traceability – Links from the requirements to the design; Prof. Loganathan R, CSE,HKBKCE 41
  42. 42. A traceability matrixReq. id 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2 1.1 D R 1.2 D D D 1.3 R R 2.1 R D D 2.2 D 2.3 R D 3.1 R 3.2 R Prof. Loganathan R, CSE,HKBKCE 42
  43. 43. 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. Prof. Loganathan R, CSE,HKBKCE 43
  44. 44. Requirements change management• Should apply to all proposed changes to the requirements.• Principal stages – Problem analysis: Discuss requirements problem and propose change; – Change analysis and costing: Assess effects of change on other requirements; – Change implementation: Modify requirements document and other documents to reflect change. Prof. Loganathan R, CSE,HKBKCE 44
  45. 45. Change managementIdentified Revised Problem Problem Analysis Change Requirements Change and Change Analysis and Implementation Specification costing Prof. Loganathan R, CSE,HKBKCE 45

×