CS 425/625 Software Engineering Software Requirements Based on Chapter 6 of the textbook [SE-8] Ian Sommerville, Software Engineering, 8th Ed., Addison-Wesley, 2006 and on Ch6 PowerPoint presentation from the book’s web-site September 24, 2007

Outline Requirements: User Requirements Systems Requirements Functional Non-functional Domain User Requirements Systems Requirements The Software Requirements Document

Requirements: Introduction…. Requirements = services the system is expected to provide + constraints placed on the system Requirements engineering = gathering, negotiating, analyzing, and documenting requirements The requirements could be expressed at various levels of abstraction The way requirements are defined has a major impact on the development of the software product

Requirements: .Introduction… “If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organisation’s needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.” [Davis]

Requirements: ..Introduction.. A classification of requirements: User requirements: higher level description of services requested and constraints imposed System requirements: a more detailed, structured description of services and constraints. Usually included in the contract between the developer and the client An even more detailed description of requirements can be provided in a software design specification (closer to implementation)

Requirements: …Introduction. Examples of user requirements definition and system requirements specification [Fig. 5.1, Sommerville 2000]. See also Fig. 6.1 [SE-8]

Requirements: ….Introduction Types of software system requirements: Functional requirements, describe the requested functionality/behaviour of the system: services (functions), reactions to inputs, exceptions, modes of operations Non-functional requirements, represent constraints on the system and its functionality: performance constraints, compliance with standards, constraints on the development process Domain requirements, can be either functional or non-functional and reflect the particularities of the application domain

Requirements: Functional Functional requirements: Depend on the system, the software, and the users Can be expressed at different levels of detail (user/system requirements) For a system, it is desirable to have a complete and consistent set of functional requirements Completeness: all required system facilities are defined Consistency: there are no contradictions in requirements

Requirements: Non-functional.. Non-functional requirements: Many apply to the system as a whole More critical than individual functional requirements More difficult to verify Kinds of non-functional requirements: Product requirements Organizational requirements External requirements

Requirements: .Non-functional. A classification of non-functional requirements [Fig. 6.3, SE-7]:

Requirements: ..Non-functional Metrics that can be used to quantitatively specify and verify non-functional requirements [Fig. 6.6, SE-8]

Requirements: Domain Domain requirements indicate specific computations, additional functionality, or constraints on other requirements Example [Fig.6.7, SE-8]: The deceleration of the train shall be computed as: Dtrain = Dcontrol + Dgradient where Dgradient = 9.81ms2 * compensated gradient/alpha and where the values of 9.81ms2/alpha are known for different types of train.

User Requirements… User requirements: Should be understood by the user, and should not address design and implementation aspects Should focus on the key facilities required Problems with requirements written in natural language: Lack of clarity, ambiguity, various interpretations possible Confusion, lack of separation between different types of requirements Mixture of several requirements in the same statement Hard to modularize and thus hard to find connections between requirements

.User Requirements.. Example of improperly stated requirement [Fig. 6.9, SE-8] 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.

..User Requirements. Another example of requirements statement, well structured and more precise [Fig. 6.10, SE-08]

…User Requirements Guidelines for writing requirements: Create and use a standard format for the entire software requirements specification Highlight important parts of the requirement statements Use consistently the language (difference between “should” and “shall”) Avoid computer jargon

System Requirements…… More detailed specifications of user requirements Included in the contract with the client Used by developers as basis for design May be specified using various models (object-oriented models, data-flow diagrams, formal specs, etc.) Should indicate WHAT the system is required to do (not HOW) and under what conditions and constraints

.System Requirements.…. There is nevertheless a blurred line between specification and design because: A system architecture may be needed to structure the requirements specification Design constraints may be part of the system requirements Factors such as interoperability may also impose design constraints

..System Requirements…. Modalities for specifying requirements [Fig. 6.11, SE-8]:

…System Requirements… Standard templates for structured natural language specification should include, as applicable: Description of the function/service Inputs and their sources Outputs and their destinations Dependencies (other elements required) Pre-conditions Post-conditions Side-effects

….System Requirements.. Example of a system requirement specified using structured natural language [Fig. 5.13, Sommerville 2000] – see also [Fig 6.12, SE-8]

…..System Requirements. Another alternative to natural language (NL) for software specification is Program Description Languages (PDL) Derived from programming languages May contain more abstract constructs Their syntax and semantics could be checked Recommended for describing sequences of actions whose order is important & for specifying software interfaces However, PDL specification require advised readers, can be taken as design specs, and may not be expressive enough

……System Requirements Example of PDL requirements specification [Fig. 5.14, Somm2000], See also Fig. 6.15 [SE-7]

The Software Requirements Document.. This document, also called Software Requirements Specification (SRS), is the official description of the system’s requirements (includes user and system reqs.) Heninger (1980) recommends that an SRS should: Specify only external system behaviour Specify constraints on implementation Be easy to change Serve as a reference for maintainers Record forethought about the software life cycle Describe acceptable responses to undesired events

.The System Requirements Document. SRS structure according IEEE/ANSI 830-1993 standard (overview only, many more details are given in the standard): Introduction General description Specific requirements Appendices Index This structure needs to be tailored for each particular organization

..The System Requirements Document A more detailed structure suggested in [Fig. 5.17, Somm00]: Table of contents Preface Introduction Glossary User requirements definition System architecture System requirements specification System models System evolution Appendices Index