Lecture Requirement engineering Chapter 5 Requirement specification

Lecture Requirement engineering Chapter 5 Requirement specification. This chapter presents the following content Introduction, general description, system features, external interface requirement, non functional requirements, other requirements.

 Requirement Specification Requirement specification systematically organize the requirements arrived during requirements analysis into a Software Requirements Specification (SRS) document document requirements properly  Developing Software Requirement Specification, focus of the project moves from the broad statement of user needs, goals and objectives, target markets and features of the system to the details of how these features are going to be implemented in the solution The SRS precisely states the functions and capabilities that a software system must provide and the constraints that it must respect SRS document is a contract between the development team and the customer The SRS is the basis for: validating the stated requirements and resolving stakeholder conflicts, if any Project planning Design for the development team Coding System testing User documentation … SRS document concentrates on: what needs to be done carefully avoids the solution (“how to do”) aspects The SRS document serves as a contract between development team and the customer Should be carefully written  Complete No requirements or necessary information should be absent  Consistent Consistent requirements don't conflict with other requirements of the same type or with higher-level business, system, or user requirements  Modifiable  changing requirements easily modified when specifying, designing, coding, implementing  Traceable A traceable requirement can be linked backward to its origin and forward to the design elements and source code that implement it and to the test cases that verify the implementation as correct  Every software development organization should adopt one or more standard SRS templates for its projects  Many people use templates derived from the one described in IEEE Standard 830-1998  This template is suitable for many kinds of projects, but it has some limitations and confusing elements I Introduction:The introduction presents an overview to help the reader understand how the SRS is organized and how to use it Purpose Scope Intended Audience and Reading Suggestions Document Conventions References I Introduction: Purpose: Identify the product or application whose requirements are specified in this document Ex: This SRS describes the software functional and nonfunctional requirements for release 1.0 of the Cafeteria Ordering System (COS) This document is intended to be used by the members of the project team that will implement and verify the correct functioning of the system Unless otherwise noted, all requirements specified here are high priority and committed for release 1.0 I Introduction: Project Scope:Provide a short description of the software being specified and its purpose Ex: The Cafeteria Ordering System will permit employees to order meals from the company cafeteria on-line to be delivered to specified campus locations A detailed project description is available in the Cafeteria Ordering System Vision and Scope Document [1] The section in that document is titled "Scope of Initial and Subsequent Releases" I Introduction: Document Conventions: Describe any standards or typographical conventions, including text styles, highlighting, or significant notations I Introduction: Intended Audience and Reading Suggestions: List the different readers to whom the SRS is directed Describe what the rest of the SRS contains and how it is organized Suggest a sequence for reading the document that is most appropriate for each type of reader I Introduction: References: List any documents or other resources to which this SRS refers, including hyperlinks to them if possible II Overall Description Product Perspective: Describe the product's context and origin Product features: the major features the product contains or the significant functions that it performs User Characteristics: identify the various user classes General Constraints: Describe any factors that will restrict the options available Assumptions and Dependencies II Overall Description Product Perspective: This defines the relationship this product has in the entire spectrum of products It defines who will be responsible for the product and what business purpose it serves It also defines what interfaces it may have to other systems II Overall Description Product Perspective sample The Cafeteria Ordering System is a new system that replaces the current manual and telephone processes for ordering and picking up lunches in the Process Impact cafeteria II Overall Description Product Features: List the major features the product contains or the significant functions that it performs It provides a summary of all the functions of the software A picture of the major groups of requirements and how they are related, such as a top-level data flow diagram, a use-case diagram, or a class diagram, might be helpful II Overall Description User Classes and Characteristics Identify the various user classes that you anticipate will use this product and describe their characteristics List the users involved with the proposed system including the general characteristics of eventual users (for example, educational background, amount of product training) III System features Functional Requirements IV External Interface Requirements :  User Interfaces References to GUI standards Screen layout or resolution constraints Message display conventions…  Hardware Interfaces: the characteristics of each interface between the software and hardware components of the system  Software Interfaces the connections between this product and other software components including databases, operating systems V Non-Functional Requirements: Non-Functional requirements are properties that the system must have such as performance, reusability, usability, user friendliness, etc V Other Requirements: Define any other requirements that are not covered elsewhere in the SRS Examples: internationalization requirements (currency, date formatting, language, international regulations, and cultural and political issues) and legal requirements  You could also add sections on operations, administration, and maintenance to cover requirements for product installation, configuration, startup and shutdown, recovery and fault tolerance, and logging and monitoring operations ... Requirement Specification Requirement specification systematically organize the requirements arrived during requirements analysis into a Software Requirements Specification (SRS)... systems V Non-Functional Requirements: Non-Functional requirements are properties that the system must have such as performance, reusability, usability, user friendliness, etc V Other Requirements:...  Complete No requirements or necessary information should be absent  Consistent Consistent requirements don't conflict with other requirements of the same type or with higher-level business,