Presentation is loading. Please wait.

Presentation is loading. Please wait.

UNIT-II Chapter : Software Requirement Specification(SRS)

Similar presentations


Presentation on theme: "UNIT-II Chapter : Software Requirement Specification(SRS)"— Presentation transcript:

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


Download ppt "UNIT-II Chapter : Software Requirement Specification(SRS)"

Similar presentations


Ads by Google