1. UNIT-II Chapter : Software Requirement Specification(SRS)

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

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

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

5. Requirements Engineering
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 -
Informal and Fuzzy Requirement
Requirements
Engineering
Well Defined Complete and Consistent Requirements

6. Requirements Engineering (RE)
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.

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

8. Requirement According to IEEE , a requirement is defined as
a condition or capability needed by a user to solve a problem or to achieve an objective.
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;
A document representation of a condition or capability as in (i) and (ii).

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

10. Requirements readers Statements in natural language + diagrams
System’s functions, services and operational constraints
Detailed software description

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

12. Functional Requirements
As 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.

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

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

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

16. Non-functional requirement types

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

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

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

20. Requirements Engineering Process
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management

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

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

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

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

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

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

27. Requirement Eliciting Techniques
Techniques for eliciting requirement:
Interviews
Brainstorming
Task Analysis
Form Analysis
User Scenarios and use case based requirement elicitation
Delphi Technique
Domain Analysis
Joint Application Design (JAD)
Facilitated Application Specific Technique (FAST)
Prototyping

28. 1. Interviews Steps: create the questions select the interviewers
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

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

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

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

32. Faculty Registration Form
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 :

33. 4. Form Analysis
Forms are used as an input to the process of constructing ER model.
Name
Address
Works in
Faculty
Department
Position
ER Diagram based on previous form

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

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

36. 5. User Scenario and Use case Based Requirements Elicitation
Benefits of Use case models:
Easily understandable by managers, developers, users and other stakeholders of the project.
Supports validation and implementation testing.
Supports traceability
Easily converted into object models
Describes the existing system under development accurately.

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

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

39. 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
Generates
New System Requirement
Domain Analysis

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

41. 8. Joint Application Design (JAD)
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.

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

43. 9. Facilitated Application Specification Technique (FAST)
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.

44. 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 Approach
Close ended (Throwaway Approach)
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.

45. Approaches to prototyping

46. Evolutionary prototyping

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

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

49. Throw-away prototyping

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

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

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

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

54. Validation Errors in content or interpretation
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.

55. 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 features
Source traceability table - identifies source of each requirement
Dependency traceability table - indicate relations among requirements
Subsystem traceability table - requirements categorized by subsystem
Interface 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.

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

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

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

59. GOALS OF SRS DOCUMENT
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.
Problem Decomposition: SRS helps to break down the problem into its component parts in an orderly fashion.
Input to Design Specification : SRS contains sufficient detail in the functional system requirements so that a design solution can be devised.
Product Validation Check: SRS serves as the parent document for testing and validation strategies that will be applied to the requirements for verification.

60. Characteristics of an SRS
Correct
Complete
Unambiguous
Consistent
Verifiable
Traceable
Modifiable
Ranked for importance and/or stability
Design Independent
Testability
Understandable by Customer
Right level of abstraction

61. Characteristics… Correctness Completeness Unambiguous
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

62. Characteristics… Verifiability Consistent Modifiable
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

63. Characteristics… Traceable Design Independent Testability
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

64. 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 are also provided.
Keywords: contract, customer, prototyping, software requirements specification, supplier, system requirements specifications

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

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

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

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

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

70. IEEE 830-1998 Standard – Section 1 of SRS
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
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

71. IEEE 830-1998 Standard – Section 2 of SRS
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
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
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 and justify technical skills and capabilities of each user class
Describe other constraints that will limit developer’s options; e.g., regulatory policies; target platform, database, network software and protocols, development standards requirements
States assumptions about availability of certain resources that, if not satisfied, will alter system requirements and/or effect the design.

72. IEEE 830-1998 Standard – Section 3 of SRS
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

73. 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
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
Include:
Types of information used
Data entities and their relationships
Should include:
Standards compliance
Accounting & Auditing procedures
The main body of requirements organized in a variety of possible ways:
Architecture Specification
Class Diagram
State and Collaboration Diagrams
Activity Diagram (concurrent/distributed)‏

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

75. Requirements vs. 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