Dr. Thomas Hicks Computer Science Department Trinity University

1. Software EngineeringCSCI 3321 Requirements Engineering Dr. Thomas Hicks Computer Science Department Trinity University 7 1

2. Chapter 7 Software Engineering : A Practitioner’s Approach RequirementsEngineering Dr. Thomas E. HicksComputer Science DepartmentTrinity University Thanks To Ian Sommerville & Roger Pressman For Much Of The Slide Content

3. RequirementsEngineering

4. Requirements Engineering Can’t Be Too Hard Can It? • Creating the Requirements/Specifications can’t be too hard can it? • After All the user does know what he/she wants don’t they? YES NO Pressman “It Is Your Worst Nightmare!”

5. What Is Requirements Engineering? • Requirements Engineering is the set of processes used to discover, analyze and validate system requirements. • Requirements Engineering helps software engineers to better understand the problem they will work to solve. • Requirements Engineering encompasses the set of tasks that leads to an understanding of what the business impact of the software willbe, what the customer wants, and howthe end user will interact with the software.

6. Requirements Elicitation Process Activities • Domain Understanding • Requirements Collection • Classification • Conflict Resolution • Prioritization • Requirements Checking

7. RequirementsEngineeringProcesses

8. Requirements Engineering & Management • 4 Analysis & Design Processes • Inception - ask questions to understand people & problem • Elicitation - elicit requirements from all stakeholders • Elaboration - create an analysis model that identifies data, function and behavioral requirements • Negotiation - agree on a deliverable system that is realistic for developers and customers • 2 Post Analysis & Design Processes • Validation- demonstrating that the requirements define the system that the customer really wants • Requirements Management - managing changing requirements

9. Requirements Engineering & Management • The Processes used for Requirements Engineeringcan vary widely depending on the application domain, the people involved and the organization developing the requirements • They can vary like the processes in the Waterfall Model. • For purposes of our exams, we shall use the • 4 Analysis & Design Processes & • 2 Post Analysis & Design Processes illustrated in these slides.

10. Requirements Engineering4 Analysis & Design Processes Inception

11. Requirements Engineering – Inception - 1 • It is the function of the Inception stage/function of Requirements Engineering to ask a set of questions that establish … • Basic understanding of the problem • The people who want a solution • The nature of the solution that is desired • The effectiveness of preliminary communication and collaboration between the customer and the developer Important Stage – Get In Or Get Out!

12. Requirements Engineering – Inception - 2 • Identify stakeholders • “who else do you think I should talk to?” • Recognize multiple points of view • Work toward collaboration • The first questions • Who is behind the request for this work? • Who will use the solution? • What will be the economic benefit of a successful solution • Is there another source for the solution that you need?

13. Requirements Engineering4 Analysis & Design Processes Elicitation

14. Requirements Engineering – Elicitation - 1 • Requirements Elicitation is the process of combining the technical staff with the customers to work out • the User Requirements [Customers], • the System Requirements [Contract], and • the Software Specification [Developers] • Requirements Elicitation is also called “Requirements Discovery” • Objectives Of Requirements Elicitation • Determine the application domain • Determine the services that the system should provide • Determine the system’s operational constraints

15. Elicitation Meeting GuidelinesRequirements Engineering • Meetings are conducted and attended by both software engineers and customers • Rules for preparation and participation are established • An agenda is suggested • A "facilitator" (can be a customer, a developer, or an outsider) controls the meeting • A "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used • The goals are • To identify the problem • To propose elements of the solution • Negotiate different approaches, and • Specify a preliminary set of solution requirements

16. Requirements Elicitation Participants • Requirements Elicitation participants may involve • End-Users - receivers of system services • Managers • Engineers involved in Maintenance • Domain Experts • Trade Unions, etc. • Those individuals have a stake in the system; they are called Stakeholders

17. Eliciting Requirements Flowchart

18. Elicitation Work Products Might Include • A statement ofneed and feasibility. • A bounded statement of scope for the system or product. • A list of customers, users, and other stakeholders who participated in requirements elicitation • A description of the system’s technical environment. • A list of requirements (preferably organized by function) and the domain constraints that apply to each. • A set of usage scenarios that provide insight into the use of the system or product under different operating conditions. • Any prototypesdeveloped to better define requirements.

19. Feasibility Study – Designer Questions • A Feasibility Studydecides whether or not the proposed system is a worthwhile venture • A Designer Portion of the Feasibility Study is 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[can the critical specifications can be met?] • If the system can be integrated with other systems that are used

20. Feasibility Study – Stakeholder Questions • A Stakeholder Portion of the Feasibility Study is a short focused study that checks • 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? • Will new user training be necessary?

21. Viewpoint-Oriented Elicitation • Stakeholdersrepresent different ways of looking at a problem or problem viewpoints • This multi-perspective analysis is important as there is no single correct way to analyze system requirements • Viewpoints are a natural way to structure requirements elicitation • It is relatively easy to decide if a viewpoint is valid

22. ATMBankingExample

23. Banking ATM System Example • Auto-Teller - provides some automated banking services • Simplified System - offers some services to customers of the bank • Narrower range of services to customers • Services include cash withdrawal, message passing (send a message to request a service), ordering a statement and transferring funds

24. Auto Teller ViewpointsWho Would Be The Stakeholders Others? – You Do! • Bank Customers • Representatives Of Other Banks • Hardware & Software Maintenance Engineers • Marketing Department • Bank Managers & Counter Staff • Database Administrators & Security Staff • Communications Engineers • Personnel Department

25. Method-Based Analysis • There are Structured Methods to help the project manager to organize and categorize views. VORD • Methods have different emphases. Some are designed for requirements elicitation, others are close to design methods • A Viewpoint-Oriented Requirements Definition (VORD) is one of the more common models. • Widely used approach to requirements analysis.

26. You Need Know No Specifics About VORD! VORD Method Flow4 Basic Steps VORD is an acronym for _____________________________ Viewpoint-Oriented Requirements Definition Viewpoint-Oriented Requirements Definition

27. You Need Know No Specifics About VORD! 4 Step 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 – Use Case

28. You Need Know No Specifics About VORD! Viewpoint Identification - ATMMany Can Views Which Help Determine Others

29. You Need Know No Specifics About VORD! Viewpoint Structuring - Hierarchy

30. You Need Know No Specifics About VORD! Viewpoint Documentation VORD Standard Forms

31. You Need Know No Specifics About VORD! Viewpoint Documentation Customer/Cash Withdrawal VOID Templates

32. You Need Know No Specifics About VORD! Viewpoint DocumentationVOID Data/Control

33. Requirements Engineering4 Analysis & Design Processes Negotiation

34. 3 Major Steps In Negotiating Requirements • Identify the key stakeholders • These are the people who will be involved in the negotiation • Determine each of the stakeholders “win conditions” • Win conditions are not always obvious • Negotiate • Work toward a set of requirements that lead to “win-win”

35. Requirements Engineering4 Analysis & Design Processes Elaboration

36. Requirements Engineering – Elaboration • Elaboration - create an analysis model that identifies data, function and behavioral requirements • We have already examined, briefly, a number of different models.

37. Building the Analysis Model • Elements of the analysis model • Scenario-based elements • Functional - processing narratives for software functions • Use-case - descriptions of the interaction between an “actor” and the system • Class-based elements • Implied by scenarios • Behavioral elements • State diagram • Flow-oriented elements • Data flow diagram

38. Requirements Engineering Scenarios

39. ScenariosHelp To Describe Exceptions • Scenariosare 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 • Scenariosare particularly useful for adding detail to an outline requirements description • Scenarios map nicely to Use-Case Diagrams

40. Exception DescriptionProblem In Most Structured Methods • Most Structured Scenarios Methods do notinclude facilities for Describing Exceptions • In the ATM 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

41. Scenario Descriptions & Inclusions • System State at the Beginning of the scenario • Normal Flow of Events in the scenario • What can go wrong and how this is handled [Early Risk Analysis] • Other Concurrent Activities • System State on Completion of the scenario

42. Event Scenarios • Event scenarios are 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 & Delivered • Control Information • Exception Processing • The Next Expected Event

43. You Need Know No Specifics This Diagram Event Scenario - Start TransactionVORDDiagrammatic Convention

44. Scenario Notation #1 Data & Control Analysis • Ellipses. data provided from or delivered to a viewpoint • Control informationenters and leaves at the top of each box

45. Scenario Notation #2 Data & Control Analysis • Dataleaves 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

46. Use Cases #1Object Oriented Notations • Use-Cases are a scenario based technique in the UML which identify the Actors in an interaction and which describe the interaction itself Your Group May Have Different Names For The Actors – OK If Descriptive Teachers? UML is an acronym for ? Unified Modelling Language

47. Use Cases #2Object Oriented Notations Use–Cases have become a fundamental feature of UMLIntroduced by Jacobson in 1993 • A set of use casesshould describe all possible interactions with the system Actors The Stick Figures Are Called ______________________ Interactions The Ellipses Represent __________________________

48. Use Cases #3Object Oriented Notations The Stick Figures Are Called ______________________ Actors The Ellipses Represent __________________________ Interactions

49. Library Use-Cases

50. Catalogue ManagementUML Sequence Diagram Who Are The Actors? What Are The Objects? The Sequence Of Actions Is From The Top To The Bottom