Document
Software Engineering
JYOTSNA
ASSISTANT PROFESSOR
CSE DEPARTMENT
INTRODUCTION TO SOFTWARE
ENGINEERING 1
Software Requirements
Engineering
INTRODUCTION TO SOFTWARE
ENGINEERING 2
Software Requirements Engineering
Process of establishing the:
◦ services that the customer requires from a software system.
◦ constraints under which the software operates.
◦ constraints under which the software is developed.
INTRODUCTION TO SOFTWARE
ENGINEERING 3
Activities
Elicitation
Specification
Verification
Validation
Feasibility discovery documentation does it mak e sense?
is it exactly what is needed?
can it be done?
INTRODUCTION TO SOFTWARE
ENGINEERING 4
Requirement Elicitation
Sometimes called requirements elicitation or requirements discovery.
Involves technical staff working(developers) with customers(clients) to find out about the application domain, the services that the system should provide and the system’s operational constraints.
May also involve end-users, managers, domain experts, trade unions, etc. These are called stakeholders.
Sources of information may also include documentation, and the specifications of similar systems.
INTRODUCTION TO SOFTWARE
ENGINEERING 5
Definition and Specification
Requirements definition
◦ Customer-oriented descriptions of the system’s functions and constraints.
Requirements specification
◦ Detailed descriptions of the system’s functionality and constraints.
◦ Written as a contract between client and contractor.
◦ Written for contractors or developers.
INTRODUCTION TO SOFTWARE
ENGINEERING 6
Types of Requirements
Functional Requirements
Non-Functional Requirements
INTRODUCTION TO SOFTWARE
ENGINEERING 7
Functional Requirements
Describe the interactions between the system and its environment independent from implementation
A functional requirement defines a function of a system and its components.
Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish.
INTRODUCTION TO SOFTWARE
ENGINEERING 8
Non-Functional Requirements
Non-functional requirements define system properties and constraints e.g., reliability, response time and storage requirements, quality etc.
Functional requirements are supported by nonfunctional requirements (also known as quality requirements), which impose constraints on the design or implementation (such as performance requirements, security, or reliability).
For Example:
◦
◦ The response time must be less than 1 second from 2:00am-2:01am and 3:00am-3:01am
INTRODUCTION TO SOFTWARE
ENGINEERING 9
INTRODUCTION TO SOFTWARE
ENGINEERING 10
Difference between Functional and
Non-Functional requirements
In general, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be.
Functional requirements are usually in the form of "system shall do <requirement>", while nonfunctional requirements are "system shall be
<requirement>“.
Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless.
INTRODUCTION TO SOFTWARE
ENGINEERING 11
Difference between Functional and
Non-Functional requirements(Cont.)
A Functional Requirement is a requirement that, when satisfied, will allow the user to perform some kind of function. For example:
“The customer must place an order after registering”
INTRODUCTION TO SOFTWARE
ENGINEERING 12
Difference between Functional and
Non-Functional requirements(Cont.)
A Non-Functional Requirement is usually some form of constraint or restriction that must be considered when designing the solution. For example:
“The customer must be able to access his/her account 24 hours a day, seven days a week.”
INTRODUCTION TO SOFTWARE
ENGINEERING 13
Constraints
Imposed by the client or the environment in which the system will operate.
For Example:
◦ The implementation language must be Java.
◦ The project must be completed within 2 weeks.
o Project must be economic.
INTRODUCTION TO SOFTWARE
ENGINEERING 14
Requirement gathering techniques
Interviews – One-on-one Interviews
– Group Interviews
Documentation via e-mail
Questionnaires and Surveys
INTRODUCTION TO SOFTWARE
ENGINEERING 15
Interviewing
In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they use and the system to be developed.
There are two types of interview
◦ Closed interviews where a pre-defined set of questions are answered.
◦ Open interviews where there is no predefined agenda and a range of issues are explored with stakeholders.
INTRODUCTION TO SOFTWARE
ENGINEERING 16
Effective interviewers
Interviewers should be open-minded, willing to listen to stakeholders and should not have pre-conceived ideas about the requirements.
They should prompt the interviewee with a question or a proposal and should not simply expect them to respond to a question such as ‘what do you want’.
INTRODUCTION TO SOFTWARE
ENGINEERING 17
Problems of requirements elicitation and analysis
Customers don’t know what they really want.
Customers express requirements in their own terms.
They may have conflicting requirements.
Organisational factors may influence the system requirements.
INTRODUCTION TO SOFTWARE
ENGINEERING 18
Requirements Validation and
Verification
Verification and Validation are independent procedures that are used together for checking that a product or software system meets specifications and that it fulfils its intended purpose.
INTRODUCTION TO SOFTWARE
ENGINEERING 19
Validation Vs Verification
Validation – “Are we building the right product?? ”
Checking a work product against the authorities that frame this particular product.
Validation is the process of evaluating software at the end of the development process to determine whether software meets the customer expectations and requirements.
Verification – “Are we building the product right??”
Checking a work product against some standards and conditions imposed on this type of product and the process of its development.
Verification is the process of evaluating products of a development phase to find out whether they meet the specified requirements.
INTRODUCTION TO SOFTWARE
ENGINEERING 20
Validation ensures that "you built the right thing". Verification ensures that "you built it right".
It is sometimes said that validation can be expressed by the query "Are you building the right thing?” and verification by "Are you building it right?".
"Building the right thing" refers back to the user's needs, while "building it right" checks that the specifications are correctly implemented by the system.
INTRODUCTION TO SOFTWARE
ENGINEERING 21
Validation process describes whether the software will be accepted by the user or not. It is computer based execution of program.
Verification process explains whether the outputs are according to inputs or not. It is human based checking of documents and files.
INTRODUCTION TO SOFTWARE
ENGINEERING 22
Verification Validation
Are we building the system right?
Verification is the process of evaluating products of a development phase to find out whether they meet the specified requirements.
Are we building the right system?
Validation is the process of evaluating software at the end of the development process to determine whether software meets the customer expectations and requirements.
The objective of Verification is to make sure that the product being develop is as per the requirements and design specifications
Following activities are involved in Verification: Reviews,
Meetings and Inspections.
The objective of Validation is to make sure that the product actually meet up the user’s requirements, and check whether the specifications were correct in the first place.
Following activities are involved in Validation: Testing like black box testing, white box testing, gray box testing etc.
Validation is carried out by testing team.
Verification is carried out by QA team to check whether implementation software is as per specification document or not .
Verification process explains whether the outputs are according to inputs or not.
Verification is carried out before the Validation.
Validation process describes whether the software is accepted by the user or not.
Validation activity is carried out just after the Verification.
Following items are evaluated during Verification: Plans,
Requirement Specifications, Design Specifications, Code, Test
Cases etc
Cost of errors caught in Verification is less than errors found in Validation.
It is basically manually checking the of documents and files like requirement specifications etc -
Following item is evaluated during Validation: Actual product or Software under test.
Cost of errors caught in Validation is more than errors found in Verification.
It is basically checking of developed program based on the requirement specifications documents & files. 23
Feasibility
An analysis and evaluation of a proposed project to determine if it (1) is technically feasible, (2) is feasible within the estimated cost , and (3) will be profitable .
Operational Feasibility
Economic Feasibility
Technical Feasibility
Schedule Feasibility
INTRODUCTION TO SOFTWARE
ENGINEERING 24
SOFTWARE REQUIREMENTS
SPECIFICATION
(SRS)
SRS
Goal is not to create great specifications but to create great products or great software .
Can you create a great product without a great specification?????
NO…..
What is SRS?
Software Requirements Specification is basically an organization's understanding (in writing) of a customer or potential client's system requirements and dependencies at a particular point in time (usually) prior to any actual design or development work.
It functions as a blueprint for completing a project with as little cost as possible.
What is SRS (cont’d)
Includes:
◦ Problem definition (what is the problem)
◦ Solution Statement (how to solve the problem)
SRS contains functional and nonfunctional requirements
It doesn't offer design suggestions, possible solutions to technology or business issues, or any other information other than what the development team understands the customer's system requirements to be.
Who would use?
Customers
◦ To define the software requirements [in fact, what actually they want/need]
Suppliers/Developers
◦ To understand what customers want
[then to give solutions]
What should the SRS address?
◦ Functionality
What is the software supposed to do?
◦ External interfaces
How does the software interact with people, the system’s hardware, other hardware, and other software?
◦ Performance
What is the speed, availability, response time, recovery time of various software functions
◦ Attributes
What are the portability, correctness, maintainability, security etc.
◦ Constraints imposed on an implementation
Are there any required standards, implementation language, policies for database integrity, resource limits, operating environment etc.
What are the characteristics of good SRS?
An SRS should be a) Correct b) Unambiguous c) Complete d) Consistent e) Ranked for importance and/or stability f) Verifiable g) Modifiable h) Traceable
Correct
Of course you want the specification to be correct.
No one writes a specification that they know is incorrect.
The discipline is keeping the specification up to date when you find things that are not correct.
Unambiguous
An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation .
Find ambiguities fix them
Complete
Requirements in SRS must be
COMPLETE
Consistent
The SRS should be consistent within itself and consistent to its reference documents.
Big NO to Contradiction
Example:
If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in another.
Ranked for Importance
Every requirement has its own priority.
Some may not be achievable.
It is useful to provide this information in the SRS.
Verifiable
Don't put in requirements like - "It should provide the user a fast response."
It is much better if you provide a quantitative requirement like: "Every key stroke should provide a user response within 100 milliseconds."
Modifiable
The logical, hierarchical structure of the SRS should facilitate any necessary modifications
Grouping related issues together and separating them from unrelated issues makes the SRS easier to modify.
Traceable
In most organizations, it is sometimes useful to connect the requirements in the SRS to a higher level document.
Each requirement in an SRS must be uniquely identified to a source .
Goals
It provides feedback to the customer.
It decomposes the problem into component parts.
It serves as an input to the design specification.
It serves as a product validation check.
Goals (cont’d)
It provides feedback to the customer.
An SRS 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.
Therefore, the SRS should be written in natural language, in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on.
Goals (cont’d)
It decomposes the problem into component parts.
The simple act of writing down software requirements in a welldesigned format organizes information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion.
Goals (cont’d)
It serves as an input to the design specification.
As mentioned previously, the SRS serves as the parent document to subsequent documents, such as the software design specification and statement of work.
Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design solution can be devised.
Goals (cont’d)
It serves as a product validation check.
The SRS also serves as the parent document for testing and validation strategies that will be applied to the requirements for verification.
SRS Template
Based on the IEEE Standard:
IEEE STD 830-1998 (Guide to
Software Requirements
Specification)
1.
1.1
1.2
1.3
1.4
1.5
2.
2.1
2.2
2.3
2.4
2.5
2.6
2.7
3.
3.1
3.2
SRS Template
Introduction
Purpose
Document Conventions
Intended Audience and Reading Suggestions
Project Scope
References
Overall Description
Product Perspective
Product Features
User Classes and Characteristics
Operating Environment
Design and Implementation Constraints
User Documentation
Assumptions and Dependencies
System Features
System Feature 1
System Feature 2 (and so on)
SRS Template
4.
External Interface Requirements
4.1
User Interfaces
4.2
Hardware Interfaces
4.3
Software Interfaces
4.4
Communications Interfaces
5.
Other Nonfunctional Requirements
5.1
Performance Requirements
5.2
Safety Requirements
5.3
Security Requirements
5.4
Software Quality Attributes
6.
Other Requirements
Appendix A: Glossary
Appendix B: Analysis Models
Appendix C: Issues List
