UNIT-IIChapter : Software Requirement Specification(SRS)

Requirements Engineering

Requirement: A function, constraint or other property that the system must provide to fill the needs of the system’s intended user(s).

Engineering: implies that systematic and repeatable techniques should be used

Requirement Engineering means that requirements for a product are defined, managed and tested systematically

Requirements Engineering

The basic goal of requirements phase in the SDLC is to produce the Requirements Specification Document(RSD) or Software Requirement Specification (SRS) which describes the complete external behavior of the proposed software system. The process of developing this document is Requirements Engineering.

Requirements Engineering can be defined as

“The systematic process of documenting requirements through an interactive co-operative process of analyzing the problem, documenting the resulting observations in a variety of representation format and checking the accuracy of the understanding gained.”

“ The systematic use of proven principles, techniques, tools and languages for the cost effective analysis, documentation and ongoing evolution of user needs and the specification of the external behavior of the system in order to satisfy these needs.”

Input to this activity of requirements engineering are requirements which are informal and fuzzy and output is clear, well defined and consistent requirements written in formal notation RSD or SRS as shown -

Requirements Engineering

Informal and Fuzzy

Requirement

RequirementsEngineering

Well Defined Complete and Consistent Requirements

It is essential that the software engineering team understand the requirements of a problem before the team tries to solve the problem.

RE is software engineering actions that start with communication activity and continues into the modeling activity.

RE establishes a solid base for design and construction. Without it, resulting software has a high probability of not meeting customer needs.

Requirements Engineering (RE)

The requirements engineering is the most crucial and most important activity in the software development life cycle because the errors introduced at this stage are the most expensive errors requiring lot of rework if detected late in the software life cycle. The SRS document produced as an output of this activity is used by successive stages of life cycle i.e. for generating design document for coding, for generating test cases in software testing and also plays a lead role in acceptance testing.

Requirements Engineering (RE)

Requirement

According to IEEE , a requirement is defined asi.a condition or capability needed by a user to solve a problem or to achieve an objective.

ii.A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed document;

iii.A document representation of a condition or capability as in (i) and (ii).

Characteristics of a Good Requirement Clear and Unambiguous

standard structure has only one possible interpretation Not more than one requirement in one sentence

Correct A requirement contributes to a real need

Understandable A reader can easily understand the meaning of the

requirement Verifiable

A requirement can be tested Complete

Contains all required information Consistent

Does not conflict with other requirements Traceable

Has unique identity, cannot be broken into parts

Requirements readersClient managersSystem end-usersClient engineersContractor managersSystem architects

System end-usersClient engineersSystem architectsSoftware developers

Client engineers (perhaps)System architectsSoftware developers

User requirements

System requirements

Software designspecification

Statements in natural language + diagrams

System’s functions, services and operational constraints

Detailed software description

Types of Requirements

Functional requirements Statements of services the system should provide,

how the system should react to particular inputs and 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 RequirementsAs the name implies, functional requirements

focus on the functionality of the software components that build the system.

High level FR are expressed in terms of:- Inputs Outputs Processing input data in some way

In simple words functional requirements are the services which the end users expect the final product to provide.

Documenting Functional Requirements Steps:-

Identify the set of services supported by the system

Specify each of the services or functionality by identifying the input data, output data and processing done on input in order to get the output.

Identify all the sub requirements for a high level requirement corresponding to the different user interactions

Non-functional requirements (NFRs)

NFRs are the constraints imposed on the system and deal with issues like maintainability, security, performance , reliability, probability, scalability, response time and storage requirements.

Non-functional requirements are also called as Quality attributes Constraints Goals Non-behavioral requirements

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. execution speed, reliability, etc.

Organisational requirements Requirements which are a consequence of

organisational policies and procedures e.g. process standards used, implementation requirements, etc.

External requirements Requirements which arise from factors which are

external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.

Non-functional requirement types

Performancerequirements

Spacerequirements

Usabilityrequirements

Efficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements

Domain requirements Derived from the application domain and

describe system characteristics and features that reflect the domain

May be new functional requirements, constraints on existing requirements or define specific computations

For a satisfactory working of the system these are mandatory requirements to be implemented or satisfied.

Domain requirements problems

Understandability Requirements are expressed in the language

of the application domain. This is often not understood by software engineers developing the system

Implicitness Domain specialists understand the area so

well that they do not think of making the domain requirements explicit

Why is Getting Good Requirements Hard?

Stakeholders don’t know what they really want.

Stakeholders express requirements in their own terms.

Different stakeholders may have conflicting requirements.

Organisational and political factors may influence the system requirements.

The requirements change during the RE process. New stakeholders may emerge and the business environment change.

RequirementsManagement

Validation

Inception

Elicitation

Elaboration

Negotiation

Specification

Requirements Engineering Process

Requirements Engineering Process Inception —Establish a basic understanding of the problem

and the nature of the solution. Elicitation —Draw out the requirements from stakeholders. Elaboration (Highly structured)—Create an analysis model

that represents information, functional, and behavioral aspects of the requirements.

Negotiation—Agree on a deliverable system that is realistic for developers and customers.

Specification—Describe the requirements formally or informally.

Validation —Review the requirement specification for errors, ambiguities, omissions, and conflicts.

Requirements management — Manage changing requirements.

Inception

Inception— Ask “context-free” questions that establish … Basic understanding of the problem The people who want a solution The nature of the solution that is desired,

and The effectiveness of preliminary

communication and collaboration between the customer and the developer

Elicitation Elicitation - elicit requirements from customers,

users and others. Find out from customers, users and others

what the product objectives are what is to be done how the product fits into business needs,

and how the product is used on a day to day

basis Also called as Requirement Analysis.

The Volere requirements process model suggests some additional sources for requirements.

Why Requirement elicitation is difficult?

Problems of scope: The boundary of the system is ill-defined. Customers/users specify unnecessary technical detail that may confuse

rather than clarify objectives. Problems of understanding:

Customers are not completely sure of what is needed. Customers have a poor understanding of the capabilities and limitations

of the computing environment. Customers don’t have a full understanding of their problem domain. Customers have trouble communicating needs to the system engineer. Customers omit detail that is believed to be obvious. Customers specify requirements that conflict with other requirements. Customers specify requirements that are ambiguous or not able to test.

Problems of volatility: Requirement change over time.

Tasks of Requirements Elicitation Fact Finding – studies the organization in which the

final system will be installed and defines the scope of the proposed system

Collecting Requirements – captures information from different users viewpoint

Evaluation – focuses on identifying inconsistencies in the requirements collected

Prioritization – prioritizes the requirements depending upon cost, user needs, ease of development etc.

Consolidation – consolidates the requirements from the information gained in a way that can be analyzed further and ensures that they are consistent with the goals of the organization.

Requirement Eliciting Techniques

Techniques for eliciting requirement:1. Interviews2. Brainstorming3. Task Analysis4. Form Analysis5. User Scenarios and use case based requirement

elicitation6. Delphi Technique7. Domain Analysis8. Joint Application Design (JAD)9. Facilitated Application Specific Technique (FAST)10. Prototyping

1. Interviews May take the form of questionnaire, open ended

interviews and focus groups. Questions must be created carefully so as to extract

maximum knowledge about true requirements. Interviews can be conducted on phone, personally or

even over the internet. Steps:

create the questions select the interviewers plan contacts conduct the interviews close the meeting determine where to go next

2. Brainstorming Is a group technique to promote creative

thinking and can be used during requirements elicitation process to generate new ideas and solve problems.

Session consists of a group of people who are free to say whatever comes to their mind irrespective of their relevance.

People are not criticized for the ideas. Session normally last for two to three hours.

2. Brainstorming Session is attended by a group of 5 to 10 people.

Three types of participants with different roles: Leader: lead the brainstorming session by encouraging the

participants to come up with new ideas and helping the scribe.

Scribe: capture the ideas, write down each idea briefly in such a way that it is visible to all the participants present in the session. He can use tools like flip charts, overhead projectors and white boards.

Participants: produce new ideas.

3. Task Analysis Is a technique of decomposing the problem

domain into a hierarchy of tasks and subtasks performed by the users.

Eg: Donate Blood Donor approaches the blood bank Staff takes the sample of the blood Staff checks for any infection in the blood and

the blood group If found OK, takes the blood and stores it Staff updates the quantity of the blood group in

the inventory Blood bank issues a card to the donor for later

use

4. Form Analysis

Forms play an important role in any organization and contain lot of meaningful information about data objects of the domain.

Faculty Registration Form

Name :Address : Position : Department :Date of Joining :Salary :

Forms are used as an input to the process of constructing ER model.

Faculty DepartmentWorks

in

Name Address

Position

ER Diagram based on previous form

4. Form Analysis

5. User Scenario and Use case Based Requirements Elicitation Technique for capturing requirements from users point

of view. This technique is based on notion of scenario.

Use case scenarios are unstructured descriptions of the user requirements.

Use cases are structured descriptions of the user requirements. It is a narrative text which describes the sequence of events from users’ perspective.

Use case diagrams are graphical representation to show the system at different levels of abstraction.

5. User Scenario and Use case Based Requirements Elicitation

Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way.

Use case scenario is a story about how actor interacts with the system.

Once actors are identified, then this information is used to draw Use Case Diagrams. These diagrams are supported by activity diagrams to show workflow view of activities.

5. User Scenario and Use case Based Requirements Elicitation Benefits of Use case models:

1. Easily understandable by managers, developers, users and other stakeholders of the project.

2. Supports validation and implementation testing.

3. Supports traceability

4. Easily converted into object models

5. Describes the existing system under development accurately.

6. Delphi Technique In delphi technique session, participants

are made to write the requirements.

These requirements are then exchanged among participants who give their comments to get a revised set of requirements.

This process is repeated till a final consensus is reached.

7. Domain Analysis This technique focus on reuse of requirements from similar

domain. It is the process of identifying, collecting, organizing and

representing the relevant information in a domain. In this technique, within a domain, existing systems are

studied and a generic domain model which is an abstraction of main features of applications of that domain is produced.

This is just like representing the requirements at another higher level of abstraction called meta level.

These requirements at meta level can then be modified to fit the problem domain.

This technique will not give good results for immature or evolving domains.

Steps of Domain Analysis

① Selection of reusable requirements.② Adaptation of requirements selected in (1) for

incorporating in the new model.

Existing System 1 Existing System 2 Existing System 3

META-SYSTEM REQUIREMENT SPECIFICATIONS

New System Requirement

Domain Analysis

Generates

8. Joint Application Design (JAD) JAD is a registered trademark of IBM and was developed

by IBM in 1970's. It is also a type of extremely effective, structured and

disciplined session because it is represented by people who are well informed and knowledgeable. They are: users customers functional experts system experts stakeholders of the project

It can last upto three days and can even produce high level software models like DFDs, Use case diagrams etc. instead of documenting only ideas.

JAD sessions are attended by: Sponsor: represents the top management and

always available to resolve any issue which has come up during the sessions. He may not attend all the sessions.

Facilitator: ensures that sessions are carried out smoothly and all participants attend the session with an open mind.

Developers: inform the participants in the meeting about the latest tools and technology that can be used to meet the requirements.

Scribe: capture and record the ideas properly. Users: explain their requirements.

8. Joint Application Design (JAD)

9. Facilitated Application Specification Technique (FAST)

FAST was developed specifically for collecting requirements and is similar to brainstorming and JAD.

Attended by developers & customers/end users.

The meeting is controlled by facilitator and an informal agenda is published.

Before starting of session, list of objects, functions and constraints is made and is presented in the session for discussion.

Participants agree not to debate. After discussion some of the entries from the list is eliminated and new entries are also added to the list. This process is continued till a consensus is reached.

Following activities take place additionally: Identification of external data objects. Detailed description of software functionality. Understanding the behavior of software. Establishing the interface characteristics. Describing the design constraints.

9. Facilitated Application Specification Technique (FAST)

10. Software Prototype

Prototype constructed for customer and developer assessment. In some circumstances construction of prototype is require in

beginning of analysis. (To derive requirement effectively)Selecting Prototype Approach1. Close ended (Throwaway Approach)2. Open ended (Evolutionary Approach)Close Ended – It serves as a rough demonstration of requirement.

It is then discarded, and the software is engineered using a different paradigm.

Open Ended - uses the prototype as the first part of an analysis activity that will be continued into design and construction. The prototype of the software is the first evolution of the finished system.

Approaches to prototyping

Evolutionaryprototyping

Throw-awayPrototyping

Deliveredsystem

Executable Prototype +System Specification

OutlineRequirements

Evolutionary prototyping

Build prototypesystem

Develop abstractspecification

Use prototypesystem

Deliversystem

Systemadequate?

YES

N

Evolutionary prototyping advantages

Accelerated delivery of the system Rapid delivery and deployment are

sometimes more important than functionality or long-term software maintainability

User engagement with the system Not only is the system more likely to

meet user requirements, they are more likely to commit to the use of the system

Evolutionary prototyping problems

Management problems Existing management processes assume a

waterfall model of development Specialist skills are required which may not be

available in all development teams

Maintenance problems Continual change tends to corrupt system

structure so long-term maintenance is expensive

Contractual problems Due to cost or time line agreed

Throw-away prototyping

Outlinerequirements

Developprototype

Evaluateprototype

Specifysystem

Developsoftware

Validatesystem

Deliveredsoftwaresystem

Reusablecomponents

Throw-away prototyping Used to reduce requirements risk The prototype is developed from an initial

specification, delivered for experiment then discarded

The throw-away prototype should NOT be considered as a final system Some system characteristics may have been

left out There is no specification for long-term

maintenance The system will be poorly structured and

difficult to maintain

Elaboration Focuses on developing a refined technical model of

software functions, features, and constraints using the information obtained during inception and elicitation

Create an analysis model that identifies data, function and behavioral requirements.

It is driven by the creation and refinement of user scenarios that describe how the end-user will interact with the system.

Each event parsed into extracted. End result defines informational, functional and

behavioral domain of the problem

Negotiation Negotiation - agree on a deliverable system that is

realistic for developers and customers

Requirements are categorized and organized into subsets

Relations among requirements identified Requirements reviewed for correctness Requirements prioritized based on customer needs Negotiation about requirements, project cost and

project timeline. There should be no winner and no loser in effective

negotiation.

Specification OR Documentation Specification – Different things to different people. It can be –

Written Document A set of graphical models, A formal mathematical models Collection of usage scenario. A prototype Combination of above.

The Formality and format of a specification varies with the size and the complexity of the software to be built.

For large systems, written document, language descriptions, and graphical models may be the best approach.

For small systems or products, usage scenarios

Validation Requirements Validation - formal technical

review mechanism that looks for Errors in content or interpretation Areas where clarification may be required Missing information Inconsistencies (a major problem when

large products or systems are engineered) Conflicting or unrealistic (unachievable)

requirements.

Requirement Management Set of activities that help project team to identify, control, and track requirements and changes as project proceeds Requirements begin with identification. Each requirement is assigned a unique identifier. Once requirement have been identified, traceability table are developed.

Traceability Table: Features traceability table - shows how requirements relate to customer observable featuresSource traceability table - identifies source of each requirementDependency traceability table - indicate relations among requirementsSubsystem traceability table - requirements categorized by subsystemInterface traceability table - shows requirement relations to internal and external interfaces

It will help to track, if change in one requirement will affect different aspects of the system.

Software Requirement Specification (SRS) or Requirement Specification Document

SRS document is generated as output of requirement analysis.

A SRS is a document which contains the complete description of software without talking much about implementation details. It is a set of precisely stated properties and constraints which final product must satisfy.

Clearly and accurately describes each of the essential requirements (functions, performance, design constraints, and quality attributes) of the system / software and its external interfaces

Defines the scope and boundaries of the system / software

Software Requirement Specification (SRS) or Requirement Specification Document

Each requirement must be described in such a way that it is feasible and objectively verifiable by a prescribed method (e.g., by inspection, demonstration, analysis, or test)

Basis for contractual agreements between contractors or suppliers and customers

Specifications are intended to a diverse audience Customers and users for validation, contract, ... Systems (requirements) analysts Developers, programmers to implement the system Testers to check that the requirements have been met Project Managers to measure and control the project

Components of SRS Document Functional Requirements Non - Functional Requirements Static Requirements Execution Constraints eg. Response time, throughput

time Standards to be followed Security requirements Company Policies Interface with other external agents ie. persons, software

or hardware

1. Feedback to customer : It is the customer’s assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems.

2. Problem Decomposition: SRS helps to break down the problem into its component parts in an orderly fashion.

3. Input to Design Specification : SRS contains sufficient detail in the functional system requirements so that a design solution can be devised.

4. Product Validation Check: SRS serves as the parent document for testing and validation strategies that will be applied to the requirements for verification.

GOALS OF SRS DOCUMENT

Characteristics of an SRS

1. Correct2. Complete3. Unambiguous4. Consistent5. Verifiable6. Traceable7. Modifiable8. Ranked for importance and/or stability9. Design Independent10.Testability11.Understandable by Customer12.Right level of abstraction

Characteristics…

Correctness Each requirement accurately represents some

desired feature in the final system Completeness

All desired features/characteristics specified Hardest to satisfy Completeness and correctness strongly related

Unambiguous Each requirement has exactly one meaning Without this errors will creep in Important as natural languages often used

Characteristics…

Verifiability There must exist a cost effective way of checking if

software satisfies requirements Consistent

two requirements don’t contradict each other Modifiable

Any necessary change can be made easily while preserving completeness and consistency

Ranked for importance/stability Needed for prioritizing in construction To reduce risks due to changing requirements

Right Level of Abstraction Details in SRS must be represented at right level of

abstraction

Characteristics…

Traceable The origin of the requirement, and how the

requirement relates to software elements can be determined

Design Independent Provision for multiple design alternatives

Testability It should be easy to generate test cases & test plans

from the document Understandable By Customer

Avoid using formal notations to represent requirements

IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications -Description Abstract: The content and qualities of a good

software requirements specification (SRS) are described and several sample SRS outlines are presented. This recommended practice is aimed at specifying requirements of software to be developed but also can be applied to assist in the selection of in-house and commercial software products. Guidelines for compliance with 12207.1-1997 are also provided.

Keywords: contract, customer, prototyping, software requirements specification, supplier, system requirements specifications

IEEE 830-1998 Standard

Title of Standard « IEEE Recommended Practice for

Software Requirements Specifications »

Describes the content and qualities of a good software requirements specification (SRS)

Presents several sample SRS outlines

IEEE 830-1998 Standard – Objectives Help software customers to accurately describe what

they wish to obtain

Help software suppliers to understand exactly what the customer wants

Help participants to: Develop a template (format and content) for the

software requirements specification (SRS) in their own organizations

Develop additional documents such as SRS quality checklists or an SRS writer’s handbook

IEEE 830-1998 Standard – Benefits Establish the basis for agreement between the

customers and the suppliers on what the software product is to do

Reduce the development effort Forced to consider requirements early reduces

later redesign, recoding, retesting Provide a basis for realistic estimates of costs and

schedules Provide a basis for validation and verification Facilitate transfer of the software product to new users

or new machines Serve as a basis for enhancement requests

IEEE 830-1998 Standard– Considerations Section 4 of IEEE 830 (how to produce a good SRS)

Nature (goals) of SRS Functionality, interfaces, performance, qualities, design constraints

Environment of the SRS Where does it fit in the overall project hierarchy

Characteristics of a good SRS Generalization of the characteristics of good requirements to the

document Evolution of the SRS

Implies a change management process Prototyping

Helps elicit software requirements and reach closure on the SRS Including design and project requirements in the SRS

Focus on external behavior and the product, not the design and the production process (describe in a separate document)

IEEE 830-1998 Standard – Structure of the SRS

Section 5 of IEEE 830

Contents of SRS Introduction General description of the software

product Specific requirements (detailed) Additional information such as

appendixes and index, if necessary

Title Table of Contents 1. Introduction

1.1 Purpose 1.2 Scope 1.3 Definitions. Acronyms, and Abbreviations 1.4 References 1.5 Overview

2. Overall Description 3. Specific Requirements 4. Other Requirements Appendices

IEEE 830-1998 Standard – Section 1 of SRS

•Describe purpose of this SRS•Describe intended audience

•Identify the software product•Enumerate what the system will and will not do•Describe user classes and benefits for each

•Define the vocabulary of the SRS (may reference appendix)

•List all referenced documents including sources(e.g., Use Case Model and Problem Statement; Experts in the field)

•Describe the content of the rest of the SRS•Describe how the SRS is organized

IEEE 830-1998 Standard – Section 2 of SRS

Title Table of Contents 1. Introduction 2. Overall Description

2.1 Product Perspective 2.2 Product Functions 2.3 User Characteristics 2.4 Constraints 2.5 Assumptions and Dependencies

3. Specific Requirements 4. Other Requirements Appendices

•Present the business case and operational concept of the system•Describe how the proposed system fits into the business context•Describe external interfaces: system, user, hardware, software, communication•Describe constraints: memory, operational, site adaptation

•Describe and justify technical skills and capabilities of each user class

•Summarize the major functional capabilities•Include the Use Case Diagram and supporting narrative(identify actors and use cases)•Include Data Flow Diagram if appropriate

•Describe other constraints that will limit developer’s options; e.g., regulatory policies; target platform, database, network software and protocols, development standards requirements

IEEE 830-1998 Standard – Section 3 of SRS

… 1. Introduction 2. Overall Description 3. Specific Requirements

3.1 External Interfaces 3.2 Functions 3.3 Performance Requirements 3.4 Logical Database Requirements 3.5 Design Constraints 3.6 Software System Quality Attributes 3.7 Object Oriented Models

4. Other Requirements Appendices

Specify software requirements in sufficient detail to enable designers to design a system to satisfy those requirements and testers to verify requirements

State requirements that are externally perceivable by users, operators, or externally connected systems

Requirements should include, at a minimum, a description of every input (stimulus) into the system, every output (response) from the system, and all functions performed by the system in response to an input or in support of an output

(a) Requirements should have characteristics of high quality requirements(b) Requirements should be cross-referenced to their source.(c) Requirements should be uniquely identifiable(d) Requirements should be organized to maximize readability

… 1. Introduction 2. Overall Description 3. Specific Requirements

3.1 External Interfaces 3.2 Functions 3.3 Performance Requirements 3.4 Logical Database Requirements 3.5 Design Constraints 3.6 Software System Quality Attributes 3.7 Object Oriented Models

4. Other Requirements Appendices

IEEE 830-1998 Standard – Section 3 of SRS

•Detail all inputs and outputs(complement, not duplicate, information presented in section 2)•Examples: GUI screens, file formats

•Include detailed specifications of each use case, including collaboration and other diagrams useful for this purpose

•The main body of requirements organized in a variety of possible ways:a) Architecture Specificationb) Class Diagramc) State and Collaboration Diagramsd) Activity Diagram (concurrent/distributed)

•Include:a) Types of information usedb) Data entities and their relationships

•Should include:a) Standards complianceb) Accounting & Auditing procedures

IEEE 830-1998 Standard – Section 4 of SRS Title Table of Contents 1. Introduction 2. Overall Description 3. Specific Requirements 4. Other Requirements

Apportioning of requirements Database Schedule & budgets

Appendices

give the details of requirements which are given to the third party for development.

describes the details of the database which will be developed as a part of the project.

describes the detailed project plan and schedule and budget estimate.

Requirements vs. Design

Requirements Design

Describe what will be delivered

Describe how it will be done

Primary goal of analysis:UNDERSTANDING

Primary goal of design:OPTIMIZATION

There is more than one solution

There is only one (final) solution

Customer interested Customer not interested (Most of the time) except for external