Chapter 4 ASE Slides ppt
- 2. Objectives • To describe the principal requirements engineering activities • To introduce techniques for requirements elicitation and analysis
- 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 organisation developing the requirements • However, there are a number of generic activities common to all processes – Requirements elicitation – Requirements analysis – Requirements validation – Requirements management
- 5. The requirements engineering process Feasibility Requirements study elicitation and analysis Requirements specification Feasibility Requirements report validation System models U and system ser requirements Requirements document
- 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 engineered using current technology and within budget – If the system can be integrated with other systems that are used
- 7. Feasibility study implementation • Based on information assessment (what is required), information collection and report writing • Questions for people in the organisation – 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. 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.
- 9. Requirements Elicitation Techniques • Interviewing and questionnaires. • Brainstorming and idea reduction. • Storyboarding. • Role Playing. • Requirements workshops. • Prototyping. • User Stories. • Viewpoint-oriented elicitation 9
- 10. Technique: Interviewing • Simple direct technique • Context-free questions about what system needs to do for the users • Convergence on some common needs will initiate a “requirements repository” • A questionnaire is no substitute for an interview, but may precede or follow interviews 10
- 11. Interview: Context-free questions • Goal is to prevent prejudicing the user’s response to the questions • Examples: – Who is the customer? – Who is the user? – Who is the user’s customer? – Are their needs different? – Where else can a solution to this problem be found? • After context-free questions are asked, suggested solutions can be explored 11
- 12. Technique: Brainstorming • Brainstorming involves both idea generation and idea reduction • The most creative, innovative ideas often result from combining seemingly unrelated ideas • Various voting techniques may be used to prioritize the ideas created • Although live brainstorming is preferred, web-based brainstorming may be a viable alternative 12
- 13. Rules for Brainstorming • Do not allow criticism or debate • Let your imagination soar • Generate as many ideas as possible • Mutate and combine ideas • Only then do Idea Reduction – Prune ideas that are not worthy of further discussion – Group similar ideas into one super topic • Prioritize the remaining ideas 13
- 14. Technique: Storyboarding • Scripted walkthrough of system activities and/ or screen mockups • Identify the players, explain what happens to them, and describes how it happens • Make the storyboard sketchy and easy to modify 14
- 15. Technique: Role Playing • Role playing allows developers to experience the user’s world from the user’s perspective • Live storyboard or unscripted walkthrough • Generate system activities and/or screen mockups as you go along 15
- 16. Technique: Requirements Workshop • Perhaps the most powerful technique for eliciting requirements • Gather all key stakeholders together for a short but intensely focused period • Use an outside facilitator experienced in requirements management • May combine interviewing, brainstorming, storyboards, role playing 16
- 17. Technique: Prototyping • Partial implementation of a software system, built to help developers, users and customers better understand system requirements • Focus on the “fuzzy” requirements: poorly defined and/or poorly understood 17
- 18. User Stories • Written by the customers (or end-users) as things that the system needs to do for them • About 3 sentences in the customer’s terminology, without technical detail • Written on index cards (!) • May be augmented by samples (e.g., formatted report) • Prioritize (high, medium, low) 18
- 19. Example Story Card 111 Ins truc tor View T inst uct v foragiv cour incl t he r or iew en se udes he cour number na a semest ; abuton t edit se , me nd er t o t int oduct abuton t designae l ayr v he r ion; t o t ibr r eser es; a abuton t a ustsetings fort cour nd t o dj t he se. Ot w t instuct v is t sa a her ise he r or iew he me s t st v . he udent iew Priority High 19
- 20. Continuing Example 222 S tudent View T st v foragiv cour incl t he udent iew en se udes he cour number na a semest ; gener lcour se , me nd er a se infor t a inst uct infor t maion; nd r or maion. T e ae butons t sel intoduct discussion, her r t o ect r ion, boad, cl ss e- il dict r not d a hel r a ma , ionay, epa nd p. Priority High 20
- 21. Continuing Example 123 Ins truc tor vs . S tudent View W a instuct sel s one oft cour hen n r or ect he ses he/ is t ching, t instuct v is show she ea he r or iew n. T instuct v shoul incl abuton t he r or iew d ude t o showt st v , a t t tspecia st he udent iew nd hen ha l udent v shoul incl abuton t sw ch ba t t iew d ude t o it ck o he inst uct v r or iew Priority Medium 21
- 22. Continuing Example 321 Login T useris pr ed t ent uni a pa or he ompt o er nd ssw d Ift uni a pa or mach daa se, he nd ssw d t t ba t useris show t defa tscr w h his/ he n he ul een it her l ofcurentcour ist r ses Priority High 22
- 23. Viewpoint-oriented elicitation • Stakeholders represent different ways of looking at a problem or problem viewpoints. • This multi-perspective analysis is important as there is no single correct way to analyse system requirements
- 24. Banking ATM system • The example used here is an auto-teller system which provides some automated banking services. • I 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.
- 25. Autoteller viewpoints • Bank customers • Representatives of other banks • Hardware and software maintenance engineers • Marketing department • Bank managers and counter staff • Database administrators and security staff • Communications engineers • Personnel department
- 26. The VORD method Viewpoint Viewpoint Viewpoint Viewpoint identification structuring documentation system mapping
- 27. VORD process model • Viewpoint identification – Discover viewpoints which receive system services and identify the services provided to each viewpoint • 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
- 28. VORD Standard Forms Viewpoint template Service template Reference: The viewpoint name. Reference: The service name. Attributes: Attributes providing Rationale: Reason why the service is viewpoint information. provided. Events: A reference to a set of event Specification: Reference to a list of service scenarios describing how specifications. These may the system reacts to be expressed in different viewpoint events. notations. Services A reference to a set of Viewpoints: List of viewpoint names service descriptions. receiving the service. Sub-VPs: The names of sub- Non-functional Reference to a set of non - viewpoints. requirements: functional requirements which constrain the service. Provider: Reference to a list of system objects which provide the service.
- 29. Viewpoint identification Query Get Customer Cash Transaction balance transactions database withdrawal log Manager Card Remote Machine Order returning software supplies cheques upgrade Account Message Software information log size Bank Invalid User teller user interface System cost Foreign customer Printe r Security Account Stolen Order Hardware card statement Card holder maintenance retention Message passing Remote Update Funds Card Reliability account transfer diagnostics validation
- 30. Viewpoint service information ACCOUNT FOREIGN BANK HOLDER CUSTOMER TELLER Service list Service list Service list Withdraw cash Withdraw cash Run diagnostics Query balance Query balance Add cash Or der cheques Add paper Send message Send message Transaction list Or der statement Transfer funds
- 31. Viewpoint data/control ACCOUNT HOLDER Control input Da ta input Start transaction Card details Cancel transaction PIN End transaction Am ount required Select service Message
- 32. Viewpoint hierarchy All VPs Services Query balance Withdraw cash Customer Bank staff Services Account Foreign Teller Manager Engineer holder customer Order cheques Send message Transaction list Order statement Transfer funds
- 33. Customer/cash withdrawal templates Reference: Customer Reference: Cash withdrawal Attributes: Account number Rationale: To improve customer service PIN and reduce paperwork Start transaction Events: Select service Specification: Users choose this service by Cancel pressing the cash withdrawal transaction button. They then enter the End transaction amount required. This is confirmed and, if funds allow, Services: Cash withdrawal the balance is delivered. Balance enquiry VPs: Customer Sub-VPs: Account holder Foreign Non-funct. Deliver cash within 1 minute customer requirements: of amount being confirmed Provider: Filled in later
- 34. Scenarios • Scenarios are descriptions of how a system is used in practice • They are helpful in requirements elicitation as people can relate to these more readily than abstract statement of what they require from a system • Scenarios are particularly useful for adding detail to an outline requirements description
- 35. Scenario descriptions • 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 • System state on completion of the scenario
- 36. Event scenarios • Event scenarios may be used to describe how a system responds to the occurrence of some particular event such as ‘start transaction’ • VORD includes a diagrammatic convention for event scenarios. – Data provided and delivered – Control information – Exception processing – The next expected event
- 37. Event scenario - start transaction Card present Valid card Card User OK Request PIN PIN Account Validate user Account number number Select PIN service Timeout Return card Incorrect PIN Re-enter PIN Invalid card Return card Incorrect PIN Stolen card Return card Retain card
- 38. Notation for data and control analysis • Ellipses. data provided from or delivered to a viewpoint. • Control information enters and leaves at the top of each box. • Data leaves from the right of each box. • Exceptions are shown at the bottom of each box. • Name of next event is in box with thick edges
- 39. Exception description • Most methods do not include facilities for describing exceptions • In this example, exceptions are – Timeout. Customer fails to enter a PIN within the allowed time limit – Invalid card. The card is not recognised and is returned – Stolen card. The card has been registered as stolen and is retained by the machine
- 40. The requirements analysis process Requirements definition and Requirem ents specification validati on Domain Prioritization understanding Process entry Requirements Conflict collection resolution Classification
- 41. System models • Different models may be produced during the requirements analysis activity. • Requirements analysis may involve three structuring activities which result in these different models. – Partitioning. Identifies the structural (part-of) relationships between entities. – Abstraction. Identifies generalities among entities. – Projection. Identifies different ways of looking at a problem.
- 42. Requirements Verification • 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
- 43. 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
- 44. 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
- 45. 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 change
- 46. Key points • The requirements engineering process includes a feasibility study, requirements elicitation and analysis, requirements specification and requirements management • Requirements analysis is iterative involving domain understanding, requirements collection, classification, structuring, prioritisation and validation • Systems have multiple stakeholders with different requirements
- 47. Key points • Social and organisation factors influence system requirements • Requirements validation is concerned with checks for validity, consistency, completeness, realism and verifiability • Business changes inevitably lead to changing requirements • Requirements management includes planning and change management