Software RequirementsObjectivesTopics coveredRequirements engineeringWhat is a requirement?Requirements abstraction (Davis)Types of requirementDefinitions and specificationsRequirements readersFunctional and non-functional requirementsFunctional requirementsThe LIBSYS systemExamples of functional requirementsRequirements imprecisionRequirements completeness and consistencyNon-functional requirementsNon-functional classificationsNon-functional requirement typesNon-functional requirements examplesGoals and requirementsExamplesRequirements measuresRequirements interactionDomain requirementsLibrary system domain requirementsTrain protection systemDomain requirements problemsUser requirementsProblems with natural languageLIBSYS requirementEditor grid requirementRequirement problemsStructured presentationGuidelines for writing requirementsSystem requirementsRequirements and designProblems with NL specificationAlternatives to NL specificationStructured language specificationsForm-based specificationsForm-based node specificationTabular specificationSlide 43Graphical modelsSequence diagramsSequence diagram of ATM withdrawalInterface specificationPDL interface descriptionThe requirements documentUsers of a requirements documentIEEE requirements standardRequirements document structureKey pointsSlide 54©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 6 Slide 1Software Requirements©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 6 Slide 2ObjectivesTo introduce the concepts of user and system requirementsTo describe functional and non-functional requirementsTo explain how software requirements may be organised in a requirements document©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 6 Slide 3Topics coveredFunctional and non-functional requirementsUser requirementsSystem requirementsInterface specificationThe software requirements document©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 6 Slide 4Requirements engineeringThe process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process.©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 6 Slide 5What is a requirement?It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.This is inevitable as requirements may serve a dual function•May be the basis for a bid for a contract - therefore must be open to interpretation;•May be the basis for the contract itself - therefore must be defined in detail;•Both these statements may be called requirements.©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 6 Slide 6Requirements abstraction (Davis)“If a company wishes to let a contract for a large software development project, itmust define its needs in a suf ciently abstract way that a solution is not pre-defned.The requirements must be written so that several contractors can bid for the contract,ofering, perhaps, diferent ways of meeting the client organisation’s needs. Once acontract has been awarded, the contractor must write a system definition for the clientin more detail so that the client understands and can validate what the software willdo. Both of these documents may be called the requirements document for thesystem.”©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 6 Slide 7Types of requirementUser requirements•Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.System requirements•A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 6 Slide 8Definitions and specifications1. The software must provide a means of representing and1. accessing external fi les created by other tools.1.1 The user should be provided with facilities to define the type of1.2 external files.1.2 Each external fi le type may have an associated tool which may be1.2 applied to the file.1.3 Each external fi le type may be represented as a specific icon on1.2 the user’s display.1.4 Facilities should be provided for the icon representing an1.2 external fi le type to be defi ned by the user.1.5 When a user selects an icon representing an external file, the1.2 effect of that selection is to apply the tool associated with the type of1.2 the external fi le to the file represented by the selected icon.User requirement definitionSystem requirements specifi cation©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 6 Slide 9Requirements readersClient managersSystem end-usersClient engineersContractor managersSystem architectsSystem end-usersClient engineersSystem architectsSoftware developersClient engineers (perhaps)System architectsSoftware developersUserrequirementsSystemrequirementsSoftware designspecifi cation©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 6 Slide 10Functional and non-functional requirementsFunctional requirements•Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.Non-functional requirements•constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.Domain requirements•Requirements that come from the application domain of the system and that reflect characteristics of that domain.©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 6 Slide 11Functional requirementsDescribe functionality or system services.Depend on the type of software, expected users and the type of system where the software is used.Functional user requirements may be high-level statements of what the system should do but functional system requirements should