1.0 Requirement Analysis & Specification

1.1 Requirements gathering and analysis

1.2 Software Requirement specification(SRS)

3.2.1 Contents of the SRS document

1.3 Functional Requirements

1.4 How to identify the functional requirements

1.5 How to Document the functional requirements Traceability

1.6 Characteristics of a good SRS document

1.7 Examples of Bad SRS Document

1.8 Organization of the SRS Document

1.9 Technique for Representing Complex Logic

Requirements Analysis and Specification

Many projects fail: because they start implementing the system: without determining whether they are building what the customer really wants. It is important to learn: requirements analysis and specification techniques thoroughly.
Goals of requirements analysis and specification phase:

fully understand the user requirements remove inconsistencies, anomalies, etc. from requirements

document requirements properly in an SRS document Consists of two distinct activities:

********************************************************************************
Assume that we got one project in a company we are the developers(programmers). We know that projects are of two types basically they are (i) implementation projects (ii) enhancement projects (iii) maintenance project. Suppose now we are going to develop implementation project( from scratch(begining) onwards we need to write)

A company(client side) has come to our organisation (our) to give the project
Clients asks us about his project
Once the deal is ok with the Client
SDLC(Software development Life Cycle) comes to the picture
Now the Project Manager(PM) involves, and he explains the project, and he identifies the Project Leaders(PL)
Once the Project Leaders(PLs) are identified by the Project Manager
Now the Project Leaders(PL) identifies the Team Leaders(TLs)
And Team Leader identifies the Developers (programmers)
Team Leaders(TLs) Reports to Project Leaders (PL)
Project Leaders (PLs) Reports to Project Manager(PM)
Now everything is ready i.e staffing has been structured
To start a project we know that there are phases, what are they? They are:

Software Engineers should follows the phases
If we want to start a project first Project Leader should identify the Clients Requirements
Project Leaders takes the requirements from the Clients
To gather the client requirements, PL/TL visits the Clients place to understand the project needs (this is also called as ONSITE visit)
PL/TL is the responsible to gather the clients requirements
Once the Requirements has been gathered, the PL/TL prepares a Document based on which he gathered
This document is known as SRS (Software Requirement and Specification) Document.
After preparation of the SRS document, PL /TL shows / sends the SRS document to the Client
Once the client approves the SRS Document, Designing phase starts
Now PL / TL gets the an idea on Project
Now the Designing Phase starts

Now you got the idea about the SRS Document I hope.
/* Let us we see priority for the phases

Requirement may take 25 days
Analysis may take 10 days
Design may take 30 days
Coding may take 10 days
Testing may take 25 days

You can understand that Design is the very important, which is done by the Experience persons like TL/ PL s only thus they draws the more salary (example 2 lakhs to 4 laksh per month)
Developers draws only 40k to 60 k per month, so once we get good experience programming , our goal should be Design means we have to achieve Team Leaders position */

*******************************************************************************

Requirements Gathering and Analysis

Specification

The person who undertakes requirements analysis and specification:

known as systems analyst:

collects data pertaining to the product

analyzes collected data:

to understand what exactly needs to be done.

writes the Software Requirements Specification (SRS) document.

Final output of this phase:

Software Requirements Specification (SRS) Document.

The SRS document is reviewed by the customer.

reviewed SRS document forms the basis of all future development activities.

Requirements Analysis

Requirements analysis consists of two main activities:

Requirements gathering

Analysis of the gathered requirements

Analyst gathers requirements through:

observation of existing systems,

studying existing procedures,

discussion with the customer and end-users,

analysis of what needs to be done, etc.

Requirements Gathering

If the project is to automate some existing procedures

e.g., automating existing manual accounting activities,

the task of the system analyst is a little easier

analyst can immediately obtain:

input and output formats

accurate details of the operational procedures

In the absence of a working system,

lot of imagination and creativity are required.

Interacting with the customer to gather relevant data:

requires a lot of experience.

Some desirable attributes of a good system analyst:

Good interaction skills,

imagination and creativity,

experience.

Analysis of the Gathered Requirements

After gathering all the requirements:

analyze it:

Clearly understand the user requirements, Detect inconsistencies, ambiguities, and incompleteness. Incompleteness and inconsistencies: resolved through further discussions with the end-users and the customers.

Inconsistent requirement

Some part of the requirement:

contradicts with some other part.

Example:

One customer says turn off heater and open water shower when temperature > 100 C

Another customer says turn off heater and turn ON cooler when temperature > 100 C

Incomplete requirement

Some requirements have been omitted:

due to oversight.

Example:

The analyst has not recorded:
when temperature falls below 90 C

heater should be turned ON

water shower turned OFF.

Requirements analysis involves:

obtaining a clear, in-depth understanding of the product to be developed,

remove all ambiguities and inconsistencies from the initial customer perception of the problem.

It is quite difficult to obtain:

a clear, in-depth understanding of the problem:

especially if there is no working model of the problem.

Experienced analysts take considerable time:

to understand the exact requirements the customer has in his mind.

Experienced systems analysts know -
often as a result of painful experiences ---

without a clear understanding of the problem, it is impossible to develop a satisfactory system.

Several things about the project should be clearly understood by the analyst:

What is the problem?

Why is it important to solve the problem?

What are the possible solutions to the problem?

What complexities might arise while solving the problem?

Some anomalies and inconsistencies can be very subtle:

escape even most experienced eyes.

If a formal model of the system is constructed,

many of the subtle anomalies and inconsistencies get detected.

After collecting all data regarding the system to be developed,

remove all inconsistencies and anomalies from the requirements,

systematically organize requirements into a Software Requirements Specification (SRS) document.

Software Requirements Specification

Main aim of requirements specification:

systematically organize the requirements arrived during requirements analysis

document requirements properly.

The SRS document is useful in various contexts:

statement of user needs

contract document

reference document

definition for implementation

1. What is SRS document?

Ans: SRS document is basically an organization’s
understanding (in writing) of potential system
requirements and dependencies at a
particular point in time (usually) prior to any
actual design or development work.

2. Need for SRS ?

There may not be clear understanding of what a system is
expected to do and its limitations.
System development process might lose focus over time.
Many people with variety of backgrounds are involved.
Different people might have different interpretations.
No clear communication between stakeholders and the
development team.
Requirements of the system might change.

3. Main goals of the SRS document

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.

4. What does SRS contain?

It contains functional and non-functional requirements only.
It states in precise and explicit language required functions and capabilities of a proposed software system (i.e., a software application, an eCommerce Web site, and so on) must provide.
It states any required constraints by which the proposed system must abide.
It doesn’t specify project requirements such as cost, delivery schedules, staffing, reporting procedures, etc.
It doesn't offer design suggestions/solutions such as choosing data structure, partition into modules, etc.
It doesn't offer possible solutions to technology or business issues.
It doesn’t contain any type of Product Assurance plans such as Quality Assurance procedures, Configuration Management procedures, Verification & Validation procedures, etc.
It doesn't offer any other information other than what the development team understands the customer's system requirements to be.

5. Benefits of the SRS Document

Provides communication between the (clients)stakeholders and the development team.
Provides a good foundation for the system design phase.
Enables planning of future phases such as validation,verification, and acceptance procedures.
Provides cross-check while conducting user-acceptance testing.
Helps in project planning eg. estimates of cost and time, resource scheduling.
Usable during maintenance phase.

6. Who Prepares the SRS or Who involved in SRS?

Almost everyone
Requirement team interview the clients
Requirements verification team ensure consistency in the document
Designers review the document to determine adequacy(satisfactory) for design and feasibility
Programmers look for technical challenges and feasibility(means possible or not?)
Testers look for traceability and testability
Project Managers/Sponsors look for risk
Clients/ End users

7. What kind of information should SRS
Include?

Several standards organizations (including the IEEE) have
identified nine topics that must be addressed when designing and
writing an SRS:

Interfaces
Functional Capabilities
Performance Levels
Data Structures/Elements
Safety
Reliability
Security/Privacy
Quality
Constraints and Limitations

8. Characteristics of a good SRS (short question)

Ans:

Complete
Consistent
Correct
Modifiable
Traceable
Unambiguous
Valid
Verifiable

9. Expalin about good srs document (long question)

Characteristics of a Good SRS

A good SRS document has certain characteristics that must be present. The

characteristics are:

1.C o r r e c t n e s s . An SRS is correct if every requirement included in the SRS

represents something required in the final system.

2.C o m p l e t e n e s s . An SRS is complete when it is documented after:

(i) The involvement of all types of concerned personnel.

(ii) Focusing on all problems, goals, and objectives, and not only on functions

and features.

(iii) Correct definition of scope and boundaries of the software and system.

3.U n a m b i g u o u s . An SRS is unambiguous if and only if every requirement

stated has one and only one interpretation. Requirements are often written in

a natural language. The SRS writer has to be especially careful to ensure that

there are no ambiguities. One way to avoid ambiguities is to use some formal

requirements specification language. The major disadvantage of using formal

languages is the large effort required to write an SRS, the high cost of doing

so, and the increased difficulty of reading and understanding formally stated

requirements (particularly by the users and clients).

4.V e r i f i a b l e . An SRS is verifiable if and only if there exists some cost-effective

process that can check whether the final product meets the requirements.

5.M o d i f i a b l e . An SRS is modifiable if its structure and style are such that any

necessary change can be made easily while preserving completeness and

consistency. The presence of redundancy is a major hindrance to modifiability,

as it can easily lead to errors. For example, assume that a requirement is

stated in two places and that the requirement later needs to be changed. If

only one occurrence of the requirement is modified, the resulting SRS will be

inconsistent.

6.T r a c e a b l e . The SRS is traceable if the origin of each of the requirements is clear

and if it facilitates the referencing of each requirement in future development

or enhancement documentation. Two types of traceability are recommended:

(i) Backward traceability. This depends upon each requirement explicitly

referencing its source in earlier documents.

(ii) Forward traceability. This depends upon each requirement in the SRS

having a unique name or reference number.

7.C o n s i s t e n c y . Consistency in the SRS is essential to achieve correct results

across the system. This is achieved by:

(i) The use of standard terms and definitions.

(ii) The consistent application of business rules in all functionality.

(iii) The use of a data dictionary.

INTRODUC

10. Characteristics of a bad SRS

Unstructured Specifications: Narrative essay- one of the worst types of specification document:, incompleteness, ambiguity.

Noise: Whatever presence of text containing information is not relates to the problem.
Silence: Aspects important to proper solution of the problem are omitted.
Over specification :Overspecification restricts the solution space for the designer. (overspecification: is well known in all industries: developing features that are not needed by the customer causes excess development efforts, missed due dates, terminated projects and higher lifecycle costs.)
Contradictions :If the same thing described at several places in different ways
Ambiguity :Literal expressions
Forward references :References to aspects of problem Defined only later on in the text.

Wishful / Unrealistic thinking

Descriptions of aspects, for which realistic solutions will be hard to find

11. Types of requirements included in the SRS

Types of requirements included in the SRS

Functional requirements
Non-functional requirements
constraints on the system.
Other requirements

12. What is Functional Requirements?

Functional Requirements: It is desirable to consider every system: performing a set of functions {fi}.Each function fi considered as: transforming a set of input data to corresponding output data.

Functional requirements describe:

A set of high-level requirements Each high-level requirement: takes in some data from the user outputs some data to the user Each high-level requirement: might consist of a set of identifiable functions For each high-level requirement: every function is described in terms of input data set output data set processing required to obtain the output data set from the input data set

Transformations (inputs, processing, outputs)

Requirements for sequencing and parallelism (dynamic requirements)
Data – Inputs and Outputs – Stored data – Transient data
Exception handling( error handling i.e we learn in java as we have a seperate chapter in java)
Nature of function: Mandatory/ Desirable/ Optional

/* just read the example for understandable purpus (no need to write the in the exam)
Example: Functional Requirement

F1: Search Book

Input: an author’s name:

Output: details of the author’s books and the locations of these books in the library.

List all functional requirements with proper numbering.

Req. 1:

Once the user selects the “search” option,

he is asked to enter the key words.

The system should output details of all books

whose title or author name matches any of the key words entered.

Details include: Title, Author Name, Publisher name, Year of Publication, ISBN Number, Catalog Number, Location in the Library.

Req. 2:

When the “renew” option is selected, the user is asked to enter his membership number and password. After password validation, the list of the books borrowed by him are displayed. The user can renew any of the books: by clicking in the corresponding renew box.

Req. 1:

R.1.1:

Input: “search” option,

Output: user prompted to enter the key words.

R1.2:

Input: key words

Output: Details of all books whose title or author name matches any of the key words.

Details include: Title, Author Name, Publisher name, Year of Publication, ISBN Number, Catalog Number, Location in the Library.

Processing: Search the book list for the keywords

Req. 2:

R2.1:

Input: “renew” option selected,

Output: user prompted to enter his membership number and password.

R2.2:

Input: membership number and password

Output:

list of the books borrowed by user are displayed. User prompted to enter books to be renewed or

user informed about bad password

Processing: Password validation, search books issued to the user from borrower list and display.

R2.3:

Input: user choice for renewal of the books issued to him through mouse clicks in the corresponding renew box.

Output: Confirmation of the books renewed

Processing: Renew the books selected by the in the borrower list.

Note:
What is the difference between

Functional and Nonfunctional Requirements

Many of the difficulties encountered in defining requirements relate to the functional-nonfunctional distinction. As so often happens, some of those difficulties are things of which people are aware, largely realizing after-the-fact that nonfunctional requirements were missed. However, perhaps more, and certainly the more insidious difficulties, involve other issues of which people may not be aware and often may be incurring intentionally due to mistaken understandings.

Functional Requirements

Most requirements definition focuses mainly on functional requirements, which are based upon the expected functioning of the product or system to be created. Functioning, typically is equated with product/system features for which you might have a menu or button choice, such as: identify a customer, select an item to order, and calculate the amount due.

All things considered, requirements definers probably are best at identifying functional requirements, although they often

13 What is Constaints?

Ans:

Constraints Constraints describe things that the system should or should not do.

For example, standards compliance how fast the system can produce results so that it does not overload another system to which it supplies data, etc.

Examples of constraints

Hardware to be used, Operating system or DBMS to be used Capabilities of I/O devices Standards compliance Data representations by the interfaced system

14. What Non-functional requirements?

Performance
Safety
Security
Software quality
Project documentation
User documentation
Design Constraints

(or)

Characteristics of the system which can not be expressed as functions: maintainability, portability, usability, etc. Nonfunctional requirements include: reliability issues, performance issues, human-computer interface issues, Interface with other external systems, security, maintainability, etc.

14. What is Other Non-Functional Requirements?

Performance requirements
Safety requirements
Security requirements
Software quality attributes
Business rules
Project documentation
User documentation

15. What is the Difference between Functional Requirements and Non Functional Requirements?

Functional requirement

non functional requirement

(1.)in simple requirements for activities such as

insertion, deletion updation are known as functional

requirements, and requirements for gui reuiremnts such

1)It's nothing only GUI(Graphical User Interface) testing

(2.)If we will go to the SRS (S/W Requirement Specification)

document then we can see some "Functionality" like 1.Add

2.Edit

3.Save

4.Close

5.TEXT Field ......etc. For those

functionality here it is written the event action for that particular field or Functionality.

means colour/Allignment/Shape/Size/DB size those things

will be there in the Non-Functional requirement.

(3) When ever need to give the data for to get the output is

always a functional requirement .(which makes seriousness

to the customer or technical person ).

(3)font, color ,size comes under non functional requirements

15. Explain about Software Requirements Document (SRS)? (long question)

ANS:

Software Requirement document is also called SRS Document. It is the official statement of what the software engineers (development tem)should implement(develop) the project or product.

It comprises (contains) of exact (precise) from of customers requirements and a detailed specification of the systems requirement.

As Software Requirements is a combination of customer as well as system requirements specifications.

This combination can be achieved in the following ways:

Both clients (customers) as well as system requirements specifications can be integrated to form one document

(or)

If there are a large number of requirements (system requirements) may be presented in a separate document.

Features of SRS:

Ø SRS Document should specify external system behaviour

Ø SRS Document specify constraints on the implementation

Ø SRS Document be easy to change

Ø SRS Document serve as reference tool(material) for maintenance project

Ø SRS Document should record motivation on the system life cycle

Ø SRS Document characterize acceptable behavior for undesired events.

Structure of SRS Doucment

1. Introduction

1.1 Purpose of the requirements document

1.2 Intended Audience and Reading Suggestions:

project managers, marketing staff, users, testers, and documentation writers. Describe what the rest of this SRS contains and how it is organized. Suggest a sequence for reading the document, beginning with the overview sections and proceeding through the sections that are most pertinent to each reader type.

1.4 Project Scope:

It's functions and how it interacts with other systems.

2. System Models:

· one or more models clearly showing the relationship between the system components, and the relationship between the system and its environment.

· A model is an abstract system view. Complementary types of model provide different system information.

· The models include the following:

(a) Object Models: dividing the problems (issues) into objects and the services they provide.

( for understanding purpose only don’t write in exam:

Object models describe the system in terms of object classes and their associations.

An object class is an abstraction over a set of objects with common attributes and the services (operations) provided by each object.

Various object models may be produced

• Inheritance models;

• Aggregation models;

• Interaction models

Object models describe logical system entities, their classification and aggregation.)

(b.) Dataflow Models: Showing the movement of the data and manipulation of information through the system.

Describing the system as entities and the relationships between them.

(just read it: Used to describe the logical structure of data processed by the system.

An entity-relation-attribute model sets out the entities in the system, the relationships between these entities and the entity attributes

Widely used in database design. Can readily be implemented using relational databases.

Semantic data models explains the logical structure of data which is imported to or exported by the systems.

(d.) Data Dictionaries:

Data dictionaries are lists of all of the names used in the system models. Descriptions of the entities, relationships and attributes are also included.

(Advantages

• Support name management and avoid duplication;

• Store of organisational knowledge linking analysis, design and implementation;

3. Functional Requirements:

The services provided for the user may be in multiple format(e.g: filled in forms, diagrams, plain text, etc) to provide complete and concise(brief) information of everyone associated with the project

5. Other Nonfunctional Requirements

Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors.

5.1 Performance Requirements

5.2 Safety Requirements

5.3 Security Requirements

5.4 Software Quality Attributes

4. Motivation and assumptions:

assumptions about the system and its environment, anticipated future changes, the reasons for decisions, etc.

5. Detailed Requirements Specifications:

For every task/function required for the system, might include interfaces for many parts of the process.

6. Other Requirements (Glossary):

Defining all technical terms used in the document. No assumption should be made about the reader having expertise or experience either in the problem domain or in aspects of computer design./ development.