Spring 2005 ECE450H1S Software Engineering IILecture 3 Topics on Requirements EngineeringSome material taken from the Tropos project at U of TCopyright © Yijun Yu, 2005Spring 2005 ECE450H1S Software Engineering IICourse informationLet’s vote …• Course Project/Final Exam 50-50 or 60-40?• Midterm/Final Exam15-35 or 0-50?• Final ExamOpen notes or Close notes or Aid SheetSpring 2005 ECE450H1S Software Engineering IILast tutorial …Web Services• Why we use Web Services? • Key standards: SOAP, WSDL and UDDI• Tomcat/Axis implementation of a legacy OmniEditor web service• Architectures of the OmniEditor• Requirements specificationsSpring 2005 ECE450H1S Software Engineering IILast lecture …Software Reengineering• Reasons to reengineering• The horseshoe process model• “Overloaded” words …reengineering, reverse engineering, restructuring and refactoring• There is another RE*ING in SE: Requirements engineeringSpring 2005 ECE450H1S Software Engineering IIToday …Topics on Requirements Engineering1. What are Software Requirements?2. Why are they important? 3. How to engineer the requirements of a software, …? 4. Why shall we do goal-oriented requirements engineering? Goal models5. SummarySpring 2005 ECE450H1S Software Engineering II1. What are software requirements?• Definition from Google: define:Software Requirements• The set of functions, performance measures, and constraints thatsoftware must satisfy. • A more or less formal statement of what a software application should do. Sometimes business analysts create requirements and hand them to software developers. Other times software analysts interview business people in order to determine the requirements for a software application development effort. Business people invariably define requirements less formally than necessary. Business people tend to define requirements with written statements or with process diagrams. Software developers are more likely todefine software requirements by means of Use Case Diagrams or Class Diagrams, which often aren't that clear to business analysts. Software Requirements constitute an important interface between business managers and IT organizations. If the handoff isn't clear and precise then the resulting system is likely to disappoint the business people who requested it.Spring 2005 ECE450H1S Software Engineering IIWhat are software requirements, then?• Requirements are expectations of the system by the environment: what problem is solved?– Software refers to the software plus the system/platform where it is running• Requirements to the software product– Functionalities: functional requirements– Qualities: non-functional requirementsReliability, Correctness, Usability, Performance, Security, Privacy, …• Requirements to the software development process– Productivity: How fast you deliver functionalities?– Maintainability, Understandability, Reusability, etc.: How good you can maintain the product qualities?Spring 2005 ECE450H1S Software Engineering IIRelated Requirements• System requirements specify the minimal demands (dependency) to the environment (hardware/software/people)“Windows 3.1/95/98/NT/XP, 256MB, English”“Platform independent”? …• Stakeholder Requirements specify the expectations from different agents in the worldDomain engineers, End-Users, Developers, Managers, Testers, HCI designers, Administrators, Partners, Competitors, Lawyers, Artists, you name it …• Business RequirementsMarket, ROI, Profit margin, Market share, OrganizationsSpring 2005 ECE450H1S Software Engineering IIExample system requirementsnot everyone can be an astraunautSpring 2005 ECE450H1S Software Engineering IIRequirements have dependenciesand Reengineering needs to know about the RequirementsSpring 2005 ECE450H1S Software Engineering II2. Why are requirements important?The Waterfall process modelIT SAVES DOLLARS, IT SAVES LIFESSpring 2005 ECE450H1S Software Engineering II3. How to obtain requirements?Rapid Prototyping processSpring 2005 ECE450H1S Software Engineering II3. How to specify FR?• A functional requirement– Goal: query [stock quote]– Inputs: stock quote [string]– Outputs: stock price [float]– Precondition: stock quote is not empty– Postcondition: stock price >=0 if the stock quote is found, otherwise stock price = -1• Relation to other requirements– To make profit of investment (why?)– To invoke an XMETHODS web service (how?)– Investor (brokers), Stock analysts (who?)– 9am – 5pm EST (when?)– Stock portfolio (what?)– Sometimes Helps, sometimes Hurts the profit goal (how much?)Spring 2005 ECE450H1S Software Engineering IIAn alternative requirement• An alternative functional requirement– Goal: query [stock name]– Inputs: stock name [string]– Outputs: stock price [float]– Precondition: stock name is not empty– Postcondition: stock price >=0 if the stock name is found and unique, otherwise stock price = -1 if the stock doesn’t exist, or stock price = -2 if more than one stock is found• Relate to other requirements– To make profit of investment (why?)– Do not need to remember the stock quote (why?)– To invoke another XMETHODS web service (how?)Spring 2005 ECE450H1S Software Engineering II3. How to specify a NFR?• A non-functional requirement– Quality attribute: responsiveness [query]– Metric: elapsed time to get response– Satisfaction criteria: elapsed time < 1 second• Another non-functional requirement– Quality attribute: usability [query]– Metric: time to memorizing the name– Satisfaction criteria: memorizing the name < 1 second• Quality attribute, metrics, satisficing criteriaSpring 2005 ECE450H1S Software Engineering II3. How to obtain requirements?Goal-oriented requirements engineering• What is a goal? Desired state of the system. Captures intentions or objectives– Either true (satisfied) or false (denied)– Partially/Fully satisfied/denied? Soft-goal: Satisficed• Reveal the rationale behind the requirements, called “early requirements”– Goal-oriented requirements elicitation (asking why, how, who, what, when, where and how much …)– Goal-oriented requirements specification: goal modelling to define the inter-dependencies among requirementsSpring 2005 ECE450H1S Software Engineering II4. Representation issues:Conceptual modelling• Each functional requirement has an associated goal, like the “@purpose” statement in the Javadoc, which defines