Software Requirements Description and Specifications of a system

Software Requirements Description and Specifications of a system Definition: Topics – – – – 1 covered: Functional and Non-functional requirement User Requirements System requirements The software requirements document

Software Requirements 2 The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed Requirements may be functional or non-functional – Functional requirements describe system services or functions – Non-functional requirements is a constraint on the system or on the development process

What 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 – – – 3 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

Types of requirements User requirements – System requirements – A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor Software specification – 4 Statements in natural language (NL) plus diagrams of the services the system provides and its operational constraints. Written for customers A detailed software description which can serve as a basis for a design or implementation. Written for developers

Requirements Targets User Requirements System Requirements Software Specification 5 Client Managers System end-users Contract managers System architects System end-users Client engineers System architects Software developers Client engineers System architects Software developers

Requirements Types: 1. 2. 3. 6 Functional requirements: services the system should provide Non-functional requirements: constraints on the services of functions offered by the system. e.g. speed, time to market Domain requirements: related to the application domain of the system (may be functional or non-functional requirements)

Functional requirements Functionality or services that the system is expected to provide. Functional requirements may also explicitly state what the system shouldn’t do. Functional requirements specification should be: – – 7 Complete: All services required by the user should be defined Consistent: should not have contradictory definition (also avoid ambiguity don’t leave room for different interpretations)

Functional requirements: Example Functional requirements for a university library system for ordering books and documents from other libraries: 1. 2. 3. 8 The user shall be able to search either all of the initial set of databases or select a subset from it. The system shall provide appropriate viewers for the user to read documents in the document store. Every order shall be allocated a unique identifier (ORDER ID) which the user shall be able to copy to the account’s permanent storage area.

Non-Functional requirements Requirements that are not directly concerned with the specific functions delivered by the system Typically relate to the system as a whole rather than the individual system features Often could be deciding factor on the survival of the system (e.g. reliability, cost, response time) 9

Non-Functional requirements classifications: Non-Functional Requirements Product requirements External requirements Efficiency Reliability Portability Usability Performance 10 Space Interoperability Organizational requirements Delivery Implementation Standards Ethics Legislative Privacy Safety

Domain requirements 11 Domain requirements are derived from the application domain of the system rather than from the specific needs of the system users. May be new functional requirements, constrain existing requirements or set out how particular computation must take place. Example: tolerance level of landing gear on an aircraft (different on dirt, asphalt, water), or what happens to fiber optics line in case of sever weather during winter Olympics (Only domain-area experts know)

Domain requirements problems Understandability – – Requirements are expressed in the language of the application domain This if often not understood by software engineers developing the system Implicitness – 12 Domain specialists understand the area so well that they do not think of making the domain requirements explicit

User requirements Should describe functional and non-functional requirements so that they are understandable by system users who don’t have detailed technical knowledge User requirements are defined using natural language, tables and diagrams 13

Problems with natural language Lack – of clarity Precision is difficult without making the document difficult to read Requirements – Functional and non-functional requirements tend to be mixed-up Requirements – 14 confusion amalgamation Several different requirements may be expressed together

Editor grid requirement : example in Natural Language (NL) 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. 15

Requirement problems in NL Grid requirement mixes three different kinds of requirement – – – 16 Conceptual functional requirement (the need for a grid) Non-functional requirement (grid units) Non-functional UI requirement (grid switching)

Structured presentation 2.6 – – – Grid facilities 2.6.1 The editor shall provide a grid facility where a matrix of horizontal and vertical lines provide a background to the editor window. 2.6.2 This grid shall be a passive grid where the alignment of entities is the user’s responsibility. 2.6.3 other related requirements Requirements 17 document Id: FS/Section 5.6

Guidelines for writing requirements Invent a standard format and use it for all requirements Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements Use text highlighting to identify key parts of the requirement Avoid the use of computer jargon 18

System requirements More detailed specifications of user requirements Serve as a basis for designing the system May be used as part of the system contract System requirements may be expressed using system models discussed in Chapter 7 19

Problems with NL specification Ambiguity – Over-flexibility – The same thing may be said in a number of different ways in the specification Lack of modularisation – 20 The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult NL structures are inadequate to structure system requirements

Alternatives to NL specification 21 Structured Natural language (via standard forms & templates) Program Description Language (PDL) Use-Cases (scenario-based technique covered in chapter 6) Mathematical specification (notations based on mathematical concepts such as finite-state machines or set. To be discussed in Chapter 9)

Structured language specifications A limited form of natural language may be used to express requirements This removes some of the problems resulting from ambiguity and flexibility and imposes a degree of uniformity on a specification Often best supported using a form-based approach 22

Form-based specification ECLIPSE/Workstation/Tools/DE/FS/3.5.1 Function: Add node Description: Adds a node to an existing design. Inputs: Node type, Node Position Outputs: Design identifier Pre/Post conditions: Other attributes: 23 Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1

PDL-based requirements definition Requirements may be defined operationally using a language like a programming language but with more flexibility of expression Most appropriate in two situations – – – 24 Where an operation is specified as a sequence of actions and the order is important When hardware and software interfaces have to be specified Example: ATM machine

PDL disadvantages PDL may not be sufficiently expressive to express the system functionality in an understandable way Notation is only understandable to people with programming language knowledge The requirement may be taken as a design specification rather than a model to help understand the system 25

ATM Specification: a PDL example Class ATM { 26 // declaration here public static void main (string args[]) InvalidCard { try { thisCard.read(); //may throw Invalid card exception pin KeyPaD.READpIN(); attempts 1; While (!thisCard.pin.equal(pin) & attempts 4) pin KeyPad.readPin(); attempts 1; . . .

The requirements document The requirements document is the official statement of what is required of the system developers Should include both a definition and a specification of requirements It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it 27

Requirements document structure 28 Introduction Glossary User requirements definition System architecture System requirements specification System models System evolution Appendices Index