1 / 26

CS 425/625 Software Engineering Software Requirements

This article discusses the importance of requirements engineering in software development and provides an overview of functional, non-functional, and domain requirements. It also highlights the challenges of capturing user requirements and provides examples of improperly stated requirements.

jenniferarmstrong
Download Presentation

CS 425/625 Software Engineering Software Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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… “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]

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

  6. Requirements: …Introduction. • Examples of user requirementsdefinition and system requirementsspecification [Fig. 5.1, Sommerville 2000]. See also Fig. 6.1 [SE-7]

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

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

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

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

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

  12. Requirements: Domain • Domain requirements indicate specific computations, additional functionality, or constraints on other requirements • Example [Fig.6.7, SE-7]: 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.

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

  14. .User Requirements.. • Example of improperly stated requirement [Fig. 6.9, SE-7] 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. ..User Requirements. • Another example of requirements statement, well structured and more precise [Fig. 6.10, SE-10]

  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. 6.11, SE-7]:

  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, Sommerville 2000] – see also Fig 6.12 [SE-7]

  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, Somm2000], See also Fig. 6.15 [SE-7]

  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

More Related