2 Software Requirements Descriptions and specifications of a system
3 Objectives To introduce the concepts of user and system requirements To describe functional and non-functional requirementsTo explain two techniques for describing system requirementsTo explain how software requirements may be organized in a requirements document
4 What is a requirement?Range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specificationRequirements may serve a dual functionMay be the basis for a bid for a contract - therefore must be open to interpretationMay be the basis for the contract itself - therefore must be defined in detailBoth these statements may be called requirements
5 Requirements engineering The requirements are the descriptions of the system services and constraintsThe requirements engineering is the process of establishing the customer services and addressing system constraints
6 Types of requirement User requirements System requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customersSystem requirementsA structured document setting out detailed descriptions of the system services. Written as a contract between client and contractorSoftware specificationA detailed software description which can serve as a basis for a design or implementation. Written for developers
8 Topics covered Functional and non-functional requirements User requirementsSystem requirementsThe software requirements document
9 Functional and non-functional requirements Statements of services the system should provide, how the system should react and behave in a certain condition.Non-functional requirementsEmergent properties such as reliability, response time, availability, not concerned with any specific functions delivered by the system.Domain requirementsRequirements that come from the application domain of the system and that reflect characteristics of that domain
10 Functional requirements Describe functionality or system servicesFunctional user requirements are high-level statementsFunctional system requirements describe system services in detail
11 Examples of functional requirements The user shall be able to search either all databases or specify a subset.The system shall provide appropriate viewers for the user to read documents.Every order shall be allocated a unique identifier (ORDER_ID).
12 Requirements imprecision Problems arise when requirements are not precisely statedAmbiguous requirements may be interpreted in different ways by developers and usersConsider the term ‘appropriate viewers’User intention - special purpose viewer for each different document typeDeveloper interpretation - Provide a text viewer that shows the contents of the document
13 Requirements completeness and consistency Typically, requirements should be both complete and consistent but may have difficulty in practiceCompleteThe requirements should include descriptions of all facilities requiredConsistentThere should be no conflicts or contradictions in the descriptions of the system facilities
14 Non-functional requirements Define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc.Process requirements may also be specified mandating a particular CASE system, programming language or development methodNon-functional requirements may be more critical than functional requirements. If these are not met, the system is useless
15 Non-functional classifications Product requirementsRequirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.Organizational requirementsRequirements which are a consequence of organizational policies and procedures e.g. process standards used, implementation requirements, etc.External requirementsRequirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.
17 Non-functional requirements examples Product requirementPerformance requirements on how fast the system must executeOrganizational requirementProcess standards which must be used in the organizationExternal requirementLegislative requirements which must be followed
18 Goals and requirements Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify.GoalA general intention of the user such as ease of useVerifiable non-functional requirementA statement using some measure that can be objectively testedGoals are helpful to developers as they convey the intentions of the system users
19 Examples A system goal A verifiable non-functional requirement The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimised.A verifiable non-functional requirementExperienced controllers shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day.
21 Requirements interaction Conflicts between different non-functional requirements are common in complex systemsSpacecraft system – an exampleTo minimise weight with few chipsTo minimise power consumption with low power chipsHowever, using low power chips need more chipsWhich is the most critical requirement?
22 Domain requirementsRequirements and features are for a specific domain.Domain requirements have specific functions, constraints or computationsThe system may not work if domain requirements are not satisfied
23 Train protection system A specific computation function for train domain:The deceleration of the train shall be computed as:Dtrain = Dcontrol + Dgradientwhere Dgradient is 9.81ms2 * compensated gradient/alpha and where the values of 9.81ms2 /alpha are known for different types of train.
24 Domain requirements problems UnderstandabilityRequirements are expressed in the language of the application domain, resulting in understanding problems for software engineersImplicitnessDomain specialists understand the area so well that they do not think of making the domain requirements explicit
25 Topics covered Functional and non-functional requirements User requirementsSystem requirementsThe software requirements document
26 User requirementsDescribe functional and non-functional requirements for users who don’t have technical knowledgeUse natural language, tables and diagrams
27 Problems with natural language AmbiguityReaders and writers may interpret the same words differently.Requirements confusionFunctional and non-functional requirements tend to be mixed-upRequirements amalgamationSeveral different requirements may be expressed togetherOver-flexibilityThe same thing may be described in different ways in the specificationLack of modularizationNL structures are inadequate to structure system requirements
28 Editor grid requirement 2.6 Grid facilities To assist in the positioning of entities on a diagram, the user may turn on a grid in either centimetres or inches, via an option on the control panel. Initially, the grid is off. The grid may be turned on and off at any time during an editing session and can be toggled between inches and centimetres at any time. A grid option will be provided on the reduce-to-fit view but the number of grid lines shown will be reduced to avoid filling the smaller diagram with grid lines.
29 Guidelines for user requirements Invent a standard format and use it for all requirementsUse language in a consistent way.Use text highlighting to identify key parts of the requirementAvoid the use of computer jargon
30 Structured presentation 2.6 Grid facilities2.6.1 The editor shall provide a grid facility where a matrix of horizontal and vertical lines provide a background to the editor window. This grid shall be a passive grid where the alignment of entities is the user's responsibility.Rationale: A grid helps the user to create a tidy diagram with well-spaced entities. Although an active grid, where entities 'snap-to' grid lines can be useful, the positioning is imprecise. The user is the best person to decide where entities should be positioned.Specification: ECLIPSE/WS/Tools/DE/FS Section 5.6
31 Topics covered Functional and non-functional requirements User requirementsSystem requirementsThe software requirements document
32 System requirements More detailed specifications of user requirements Serve as a basis for designing the systemMay be used as part of the system contractSystem requirements may be expressed using system models (data-flow model, object model, etc.)
33 Requirements and design Requirements care about “what the system should do”Design cares about “how to fulfill the requirements”
34 Two Alternatives to NL specification Structured natural language specificationsPDL-based definitions
35 Structured NL specifications A limited form of natural language may be used to express requirementsThis removes the problems of ambiguity and flexibility and supports uniformity
37 PDL-based requirements definition A programming language like description but with more flexibility of expressionAppropriate in two situationsWhere an operation is specified as a sequence of actions and the order is importantWhen interfaces have to be specified
39 PDL disadvantagesPDL may not be sufficiently expressive to express the system functionality in an understandable wayNotation is only understandable to people with programming language knowledgeThe requirement may be taken as a design specification rather than a model to help understand the system
40 Topics covered Functional and non-functional requirements User requirementsSystem requirementsThe software requirements document
41 IEEE requirements standard IntroductionGeneral descriptionSpecific requirementsAppendicesIndexThis is a generic structure that must be instantiated for specific systems
43 Requirements Specification – Volere Template Table of ContentsProject DriversThe Purpose of the ProductClient, Customer and StakeholdersUsers of the ProductProject ConstraintsMandated ConstraintsNaming Conventions and DefinitionsRelevant Facts and AssumptionsFunctional RequirementsThe Scope of the WorkThe Scope of the ProductFunctional and Data Requirements
44 Requirements Specification – Volere Template Non-Functional RequirementsLook and Feel RequirementsUsability RequirementsPerformance RequirementsOperational RequirementsMaintainability and Portability RequirementsSecurity RequirementsCultural and Political RequirementsLegal RequirementsProject ConstraintsOpen IssuesOff-the-Shelf SolutionsNew ProblemsTasksCutoverRisksCostsUser Documentation and TrainingWaiting RoomIdeas for Solutions
45 Key pointsRequirements set out what the system should do and define constraints on its operation and implementationFunctional requirements set out services the system should provideNon-functional requirements constrain the system being developed or the development processUser requirements are high-level statements of what the system should do
46 Key pointsUser requirements should be written in natural language, tables and diagramsSystem requirements are intended to communicate the functions that the system should provideSystem requirements may be written in structured natural language, a PDL or in a formal languageA software requirements document is an agreed statement of the system requirements