CS 425/625 Software Engineering Software Requirements

1. CS 425/625 Software EngineeringSoftware Requirements Based on Chapter 5 of the textbook [Somm00] Ian Sommerville, Software Engineering, 6th Ed., Addison-Wesley, 2000 and on Ch5 PowerPoint presentation from the book’s web-site: www.comp.lancs.ac.uk/computing/resources/IanS/SE6/Slides/index.html September 17, 2003

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

3. Requirements: Introduction… • Requirements = services the system is expected to provide + constraints placed on the system • Requirementsengineering = 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

4. 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)

5. Requirements: ..Introduction. • Examples of user requirementsdefinition and system requirementsspecification [Fig. 5.1, Somm00]

6. 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

7. 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

8. 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

9. Requirements: .Non-functional. • A classification of non-functional requirements [Fig. 5.3, Somm00]:

10. Requirements: ..Non-functional • Metrics that can be used to quantitatively specify and verify non-functional requirements [Fig. 5.6, Somm-6]

11. Requirements: Domain • Domain requirements indicate specific computations, additional functionality, or constraints on other requirements • Example [Fig.5.7, Somm00]: The deceleration of the train shall be computed as: Dtrain = Dcontrol + Dgradient whereDgradient =9.81ms2 * compensated gradient/alpha and where the values of9.81ms2/alphaare known for different types of train.

12. 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

13. .User Requirements... • Example of improperly stated requirement [Fig. 5.9, Somm00] 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.

14. ..User Requirements.. • Re-stated requirement [Fig. 5.10, Somm00]

15. …User Requirements. • Another example of requirements statement, well structured, more detailed and more precise [Fig. 5.11, Somm00]

16. ….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

17. System Requirements…… • 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

18. .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

19. ..System Requirements…. • Modalities for specifying requirements [Fig. 5.12, SE-6]:

20. …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

21. ….System Requirements.. • Example of a system requirement specified using structured natural language [Fig. 5.13, Somm00]

22. …..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

23. ……System Requirements • Example of PDL requirements specification [Fig. 5.14, Somm00]

24. 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

25. .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

26. ..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