CS 501: Software EngineeringAdministrationQuiz 1 -- Part of Question 1Lectures on Requirements Analysis and SpecificationRequirements Analysis and DefinitionWhy are Requirements Important?Requirements in Software DevelopmentPowerPoint PresentationRequirements in Iterative RefinementGoals During the Requirements PhaseThe Requirements ProcessRequirements AnalysisRequirements Documentation (continued on next slide)Requirements Documentation (continued)Slide 15Realism and VerifiabilityEvolution of RequirementsNew and Old SystemsFunctional RequirementsNon-Functional RequirementsExamples of Functional and Non-Functional RequirementsSlide 22Example of Non-Functional RequirementsUnspoken RequirementsRequirements Analysis: Interviews with ClientsRequirements AnalysisSlide 27Viewpoint AnalysisSlide 29From an Exam QuestionFrom an Exam Question (Answer)Slide 32Slide 331CS 501 Spring 2006CS 501: Software EngineeringLecture 7Requirements I2CS 501 Spring 2006AdministrationQuiz 1• Collect after class or from reception at 301 College Avenue• Average grade was 17 out of 20 Assignment 1: Feasibility studyDue Friday at 5:00 p.m.Remember to send a copy to your client3CS 501 Spring 2006Quiz 1 -- Part of Question 1What are the visibility requirements of your project? How does your process provide visibility?Visibility is an aspect of the software development process -- keeping everybody informed of the progress, e.g. with schedules, milestones, presentations, reports, etc.What risks do you see for your project? How does your process manage risk?Risks can be categorized by (a) function, (b) timeliness, (c) resources.4CS 501 Spring 2006Lectures on Requirements Analysis and SpecificationRequirements I: Requirements AnalysisRequirements II: Models -- Scenarios and Use CasesRequirements III: Informal Methods of SpecificationRequirements IV: Formal Methods of Specification5CS 501 Spring 2006Requirements Analysis and DefinitionFrom Lecture 2The requirements analysis and definition establish the system's services, constraints and goals by consultation with users. They are then defined in a manner that is understandable by both users and development staff.This phase can be divided into:• Requirements analysis• Requirements definition• Requirements specificationRequirements define the function of the system FROM THE CLIENT'S VIEWPOINT.6CS 501 Spring 2006Why are Requirements Important?Causes of failed software projects (Standish Group study, 1994)Incomplete requirements 13.1%Lack of user involvement 12.4%Lack of resources 10.6%Unrealistic expectations 9.9%Lack of executive support 9.3%Changing requirements & specifications 8.8%Lack of planning 8.1%System no longer needed 7.5%The commonest mistake is to build the wrong system!7CS 501 Spring 2006Requirements in Software DevelopmentRequirementsOperation andMaintenanceImplementationDesignFeasibility andPlanningAll process models include a requirements activity8CS 501 Spring 2006RequirementsSystem designTestingOperation & maintenanceProgram designCodingAcceptance & releaseWaterfall model with feedback Feasibility studyRequirements in the Modified Waterfall Model9CS 501 Spring 2006Requirements in Iterative RefinementOutlineDescriptionConcurrentActivitiesRequirementsDesignImplementationInitialVersionIntermediateVersionsFinalVersion10CS 501 Spring 2006Goals During the Requirements Phase• Understand the requirements in detail (analysis).• Describe the requirements in a manner that is clear to the client. Ensure that the client understands the description of the requirements and their implications.• Describe the requirements in a manner that is clear to the people who will design and implement the system.The Requirements Documentation is the defining document that describes the goals of the system that is being built.It may form a legal contract between client and software developers.11CS 501 Spring 2006The Requirements ProcessFeasibilityStudyRequirementsAnalysisRequirementsModelRequirementsSpecificationFeasibilityReportDocumentation ofRequirementsWork with the client to understand the requirementsOrganize the requirements in a systematic and comprehensible mannerRequirements Analysis (optional)12CS 501 Spring 2006Requirements AnalysisHigh-level abstract description of requirements:• Specifies external system behavior• Comprehensible by customer, management and usersShould reflect accurately WHAT THE CUSTOMER WANTS:• Services that the system will provide• Constraints under which it will operateOften described in a separate document for consultation with the client. "Our understanding of your requirements is that ..."13CS 501 Spring 2006Requirements Documentation (continued on next slide)The form of documentation varies, but is likely to contain the following:GeneralPurpose and scope of systemObjectives and criteria for successList of terminology, organizations involved, etc.Description of current system(s)14CS 501 Spring 2006Requirements Documentation (continued)Requirements of proposed systemOverviewFunctional RequirementsUsability requirementsNon-functional requirementsSystem models ScenariosUse casesModels used during analysis15CS 501 Spring 2006Requirements Documentation (continued)Detailed specificationsBusiness rules, specifications, etc. (e.g., reference to an accounting standard)Data flow, sources of data, data validationetc., etc.,A common fault in requirements documentation is to gloss over the details. This results in misunderstandings between the client and the developers.16CS 501 Spring 2006Realism and VerifiabilityRequirements must be realistic, i.e., it must be possible to meet them.Wrong: The system must be capable of x (if no known computer system can do x at a reasonable cost).Requirements must be verifiable, i.e., it must be possible to test whether a requirement has been met.Wrong: The system must be easy to use.Right: After one day's training an operator should be able to input 50 orders per hour.17CS 501 Spring 2006Evolution of Requirements• If the requirements definition is wrong, the system will be wrong.• With complex systems, understanding of requirements always continues to improve.Therefore...• The requirements definition must evolve.• Its documentation must be kept current (but clearly identify versions).18CS 501 Spring 2006New and Old SystemsIn requirements analysis it is important to distinguish:• features of the current system•
View Full Document
Unlocking...