Skip to content

Home

Jump to bottom
Emir Alaattin Yılmaz edited this page Apr 6, 2018 · 2 revisions

SOFTWARE REQUIREMENTS SPECIFICATION

What is SRS?

  1. A System Requirements Specification (SRS) (also known as a Software Requirements Specification) is a document that describes the features and behavior of a system or software application.
  2. SRS fully describes what the software will do and how it will be expected to perform. What is the Purpose of SRS?
  3. SRS exactly and precisely describes the software to be built.
  4. Provides feedback to the customer. How Should a SRS be?
  5. Specify external system behaviour
  6. Specify implementation constraints
  7. Be easy to change (but changes must be managed)
  8. Serve as a reference tool for maintenance
  9. Forsee about the life cycle of the system (i.e. predict changes)
  10. Characterise responses to unexpected events
  11. It is not a design document it should state what the system should do rather than how it should do Users of a requirements document

PROPERTIES OF SRS WITH TERMS Correct specifies every true requirement known at that time and no incorrect specifications - no wrong data Precise remember this must eventually turn to executable code, fuzzy words in requirements are not acceptable - fuzzy words Unambiguous each requirement has only one interpretation Complete everything included behavior (methods, use cases, systems, subsystems, business rules) and data (objects, attributes) Verifiable is the software built what was specified in the SRS Consistent No conflicting terms, characteristics Understandable question: are formal specifications understandable, are informal specifications understandable Modifiable changing requirements easily modified when specifying, designing, coding, implementing Traceable can I locate the SRS origin of software components. Design Independent SRS should not specify a particular design SRS Template (IEEE STANDART)

SRS STRUCTURE I. INTRODUCTION Definition of section contents

A. PURPOSE

  • The purpose of this Software Requirements Specification document
  • Intended audience of this document B. SCOPE
  • Origin of need
  • High-level functionality of the system functionality • defined for the system • usually in list separated by commas
  • Goals of proposed system
  • Goals are general purposes of a system. They are fuzzy and non measurable.
  • A typical goal would be things like • Increase customer satisfaction • Make xyz easier for the customer • Improve customer relationships C. DEFINITIONS, ABBREVIATIONS e.g. FSU – Florida State University CS - Computer Science MSES - Masters in Software Engineering Science DOE - Department of Education D. REFERENCES Many references may be used to define existing systems, procedures (both new and old), documents and their requirements. Customer - Anyone who uses online book store system Functional requirement - A service provided by the software system E. OVERVIEW This section defines the organization of the entire document. It is a guideline for reading the document.

Ex: OVERVIEW Section 2 of the SRS describes the product in more detail. Section 3 provides a complete list of the functional requirements of the intended system. Section 4 provides the non-functional requirements. Section 5 shows the class diagram Section 6 the use case diagram. The appendices appear next.

SECTION I

SECTION II A. Product Perspective B. Product Functions C. User Characteristics D. General Constraints E. Assumptions A. Product Perspective

  • 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. e.g. The online book store is a web-based system. The system interfaces with two other systems, the owner’s email system, the book seller’s panel system B. Product Functions
  • This section lists the major functions of the system.
  • It provides a summary of all the functions of the software.
  • The functions should be organized in a way that makes the list of functions understandable to the customer or to anyone else reading the document for the first time.
  • This section should be consistent with the functional requirements defined in Section III.

C. User Characteristics

  • List the responsibility of each type of user involved, if needed. eg. The store personnel are divided into two groups: the clerk-level personnel and owner-level personnel. Their educational level is unknown and both group needs little to no training.

D. General Constraints

  • constraints of the system are listed.
  • hardware, network, system software, and software constraint
  • also includes user constraints, processing constraints, timing constraints, and control limits. eg. This system provides web access for all customer and member functions. The user interface will be intuitive enough so that no training is required by customers, members, or store personnel.

E. General Constraints

  • List and describe each of the assumptions that is made in the SRS.
  • These factors are not design constraints on the software but any changes to them can affect the requirements in the SRS. eg., an assumption might be that a specific operating system will be available on the hardware designated for the software product. If, in fact, the operating system is not compatible, the SRS would then have to change. SECTION II

SECTION III III.Functional Requirements This concept is examined detailly among the report (check Background Information section). SECTION IV III.Non-Functional Requirements This concept is examined detailly among the report (check Background Information section).

SECTION V V. SYSTEM ARCHITECTURE

  • It shows the fundamental objects/classes that must be modeled with the system to satisfy its requirements.
  • Each class on the diagram must include the attributes related to the class.
  • All the relationships between classes and their multiplicity must be shown on the class diagram.
    SECTION VI VI. USE CASES
  • Presents the use case diagram for the system under development.
  • The use case diagram should show all the use cases needed to describe the functionality to be developed.

BACKGROUND INFORMATION REQUIREMENTS Types of Requirements User requirements

  1. Statements in natural language plus diagrams of the services the system is expected to provide and the constraints under which it must operate.
  2. Written for customers. System requirements
  3. A structured document setting out detailed descriptions of the system’s functions, services and operational constraints.
  4. Defines what should be implemented so may be part of a contract between client and contractor. Functional requirements
  5. Statements of services the system should provide, how the system should react to particular inputs
  6. How the system should behave in particular situations Non-functional requirements Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Domain requirements Requirements that come from the application domain of the system and that reflect characteristics of that domain

Functional Requirements Describes functionality or system service

  1. What inputs the system should accept
  2. What outputs the system should produce Ex: A library system that provides a page that shows articles from different libraries Users can search for, download and print these articles for personal study

Completeness & Consistency In principle, requirements should be both complete and consistent Complete They should include descriptions of all facilities required. Consistent There should be no conflicts or contradictions in the descriptions of the system facilities.

Non-Functional Requirements

  1. These define requirements on emergent system properties e.g., Quality requirements, Platform requirements, Process requirement
  2. Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless. Non-functional classifications Product requirements Requirements which specify that the delivered product must behave in a particular way e.g. how fast the system must execute and how much memory it requires Organisational requirements
  3. Requirements which are a consequence of customer’s and developer’s organisational policies and procedures, e.g., which standards used in process External requirement Requirements which arise from factors which are external to the system and its development process e.g: The system shall not reveal any personal information about customers apart from their name and reference number to the operators of the system User Requirements
  4. Should describe functional and non-functional requirements in such a way that they are understandable by system users who don’t have detailed technical knowledge
  5. User requirements are defined using natural language, tables and diagrams as these can be understood by all users System requirements
  6. More detailed specifications of system functions, services and constraints than user requirements
  7. They are intended to be a basis for designing the system.
  8. A software requirements document is an agreed statement of the system requirements
Clone this wiki locally