DOC PREVIEW
Toronto ECE 450 - Topics on Requirements Engineering

This preview shows page 1-2 out of 6 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Spring 2005 ECE450H1S Software Engineering IILecture 3Topics onRequirements 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 Exam50-50or 60-40?• Midterm/Final Exam15-35or 0-50?• Final ExamOpen notesor Close notesor 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 legacyOmniEditor 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 asoftware, …?4. Why shall we do goal-orientedrequirements engineering? Goalmodels5. 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 applicationshould do. Sometimes business analysts create requirements andhand them to software developers. Other times software analystsinterview business people in order to determine the requirements fora software application development effort. Business peopleinvariably define requirements less formally than necessary.Business people tend to define requirements with written statementsor with process diagrams. Software developers are more likely todefine software requirements by means of Use Case Diagrams orClass Diagrams, which often aren't that clear to business analysts.Software Requirements constitute an important interface betweenbusiness managers and IT organizations. If the handoff isn't clearand precise then the resulting system is likely to disappoint thebusiness people who requested it.Spring 2005 ECE450H1S Software Engineering IIWhat are software requirements, then?• Requirements are expectations of the system bythe environment: what problem is solved?– Software refers to the software plus thesystem/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 developmentprocess– 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 minimaldemands (dependency) to the environment(hardware/software/people)“Windows 3.1/95/98/NT/XP, 256MB, English”“Platform independent”? …• Stakeholder Requirements specify theexpectations from different agents in the worldDomain engineers, End-Users, Developers, Managers, Testers, HCIdesigners, 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 theRequirementsSpring 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 isfound and unique, otherwise stock price = -1 if thestock doesn’t exist, or stock price = -2 if more thanone 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-orientedrequirements 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: goalmodelling to define the inter-dependencies amongrequirementsSpring 2005 ECE450H1S Software Engineering II4. Representation issues:Conceptual modelling• Each functional requirement has an associatedgoal, like the “@purpose” statement in theJavadoc, which defines the function: What is theacceptable input and what is


View Full Document
Download Topics on Requirements Engineering
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Topics on Requirements Engineering and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Topics on Requirements Engineering 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?