Requirements specificationRequirements analysis and system specification"Editor with undo"Functional and non-functional requirementsDesiderata for a requirements specificationUse casesText and DiagramsExample use case (from Fowler and Scott, UML Distilled)Use case diagramHeuristics for writing use case textMore use case pointersAdvantages of use casesSlide 13Requirements Requirements specificationspecificationCSE432CSE432Object-Oriented Object-Oriented Software EngineeringSoftware EngineeringRequirements analysis and Requirements analysis and system specificationsystem specificationWhy is this the first stage of most life cycles?Why is this the first stage of most life cycles?Need to understand what customer wants first!Need to understand what customer wants first!Requirements analysis says: “Make a list of the guidelines we will use to Requirements analysis says: “Make a list of the guidelines we will use to know when the job is done and the customer is satisfied.” know when the job is done and the customer is satisfied.” Some call this step Some call this step requirements gatheringrequirements gatheringRequirements are a Requirements are a contractcontract between you and the customer (OOSE theme) between you and the customer (OOSE theme)System specification says: “Here’s a description of System specification says: “Here’s a description of whatwhat the program the program will do (not will do (not howhow) to satisfy the requirements.” ) to satisfy the requirements.” Some distinguish requirements gathering and system analysis stepsSome distinguish requirements gathering and system analysis stepsA top-level exploration into the problem and in some sense a discovery A top-level exploration into the problem and in some sense a discovery of whether it can be done and how long it will takeof whether it can be done and how long it will takeGoal of requirements elicitation is to understand the customer’s problemGoal of requirements elicitation is to understand the customer’s problemThough customer may not fully understand it!Though customer may not fully understand it!""Editor with undoEditor with undo" " A very simple, initial requirements specA very simple, initial requirements specWhy might a small and concise initial spec be a good idea?Why might a small and concise initial spec be a good idea?Fosters initial buy-in and agreement by everyone on the teamFosters initial buy-in and agreement by everyone on the teamReal-world specsReal-world specs are usually much longer, though are usually much longer, thoughWhat’s the purpose of a What’s the purpose of a purposepurpose statement? statement?Why is Why is scopescope important? important?Why Why definitionsdefinitions??Other possible general requirements:Other possible general requirements:Business contextBusiness context: organization sponsoring the development of : organization sponsoring the development of the productthe productUser characteristicsUser characteristics: profile of user community, expected : profile of user community, expected expertise with system & domainexpertise with system & domainUser objectivesUser objectives: “wish list” from user’s perspective, in line with : “wish list” from user’s perspective, in line with business objectivesbusiness objectivesInterface requirementsInterface requirements: GUI, API, communication interfaces, : GUI, API, communication interfaces, software interfacessoftware interfacesFunctional and non-functional Functional and non-functional requirementsrequirementsFunctionalFunctional requirements describe system behavior requirements describe system behaviorPriority: Priority: rank order the requirements in importancerank order the requirements in importanceCriticalityCriticality: how essential is each requirement to the overall : how essential is each requirement to the overall system?system?RisksRisks: when might a requirement not be satisfied? What can be : when might a requirement not be satisfied? What can be done to reduce this risk?done to reduce this risk?Non-functionalNon-functional requirements describe other desired requirements describe other desired system attributessystem attributesProduct costProduct cost (how do measure cost?) (how do measure cost?)PerformancePerformance (efficiency, response time? startup time?) (efficiency, response time? startup time?)PortabilityPortability (target platforms?), binary or byte-code compatibility? (target platforms?), binary or byte-code compatibility?AvailabilityAvailability (how much down time is acceptable?) (how much down time is acceptable?)SecuritySecurity (can it prevent intrusion?) (can it prevent intrusion?)SafetySafety (can it avoid damage to people or environment?) (can it avoid damage to people or environment?)Maintainability Maintainability (in OO context: extensibility, reusability)(in OO context: extensibility, reusability)Desiderata for Desiderata for a requirements specificationa requirements specification Should say Should say whatwhat, not , not how.how. Why?Why?Correct: does what the client wants. Correct: does what the client wants. This quality is like motherhood and apple pie—This quality is like motherhood and apple pie—How can you accomplish this?How can you accomplish this?Ask the client: keep a list of questions for the clientAsk the client: keep a list of questions for the clientPrototyping: explore the risky aspects of the system with the clientPrototyping: explore the risky aspects of the system with the clientVerifiable: can determine whether the requirements have been metVerifiable: can determine whether the requirements have been metBut how do verify a requirement like “user-friendly” or “it should never crash”?But how do verify a requirement like “user-friendly” or “it should never crash”?Unambiguous: every requirement has only one interpretationUnambiguous: every requirement has only one interpretationConsistent: no internal conflictsConsistent: no internal conflictsIf you call an input "Start and Stop" in one place, don't call it "Start/Stop" in anotherIf you call an input "Start and Stop" in one place, don't call it "Start/Stop" in anotherComplete: has everything designers need to create the softwareComplete: has everything designers need to create the softwareUnderstandable: stakeholders understand it well enough to buy into itUnderstandable: