Software Requirements Analysis and Specifications Guide

Unit II
Software Requirement Analysis and

Specifications
Software Engineering 1
Table of Contents
• Requirement Engineering Process:
• Elicitation
• Requirement Analysis, Documentation
• Review and Management of User Needs
• Data Flow Diagrams, Data Dictionaries
• Entity-Relationship diagrams
• Software Requirement and Specifications
• Functional and non-Functional requirements
• Software Prototyping
• Feasibility Study
• Information Modelling
• Decision Tables
• SRS Document
• IEEE Standards for SRS, Software Quality Assurance (SQA),SEI-CMM Model.
Requirements Elicitation
• Requirements elicitation is perhaps the most difficult, most error-prone and most
communication intensive software development. It can be successful only through an
effective customer-developer partnership. It is needed to know what the users really
need.
There are a number of requirements elicitation methods. Few of them are listed below –
I. Interviews
II. Brainstorming Sessions
III. Facilitated Application Specification Technique (FAST)
IV. Quality Function Deployment (QFD)
V. Use Case Approach
The success of an elicitation technique used depends on the maturity of the analyst,
developers, users and the customer involved.
Contd.
1. Interviews:
• Objective of conducting an interview is to understand the customer’s expectations
from the software.
It is impossible to interview every stakeholder hence representatives from groups
are selected based on their expertise and credibility.
• Interviews maybe be open ended or structured.
• In open ended interviews there is no pre-set agenda. Context free questions may be
asked to understand the problem.
• In structured interview, agenda of fairly open questions is prepared. Sometimes a
proper questionnaire is designed for the interview.
2. Brainstorming Sessions:
• It is a group technique
• It is intended to generate lots of new ideas hence providing a platform to share
views
• A highly trained facilitator is required to handle group bias and group conflicts.
• Every idea is documented so that everyone can see it.
• Finally a document is prepared which consists of the list of requirements and their
priority if possible.
Introduction to Software Engineering 5

Contd.
3. Facilitated Application Specification Technique:

• It’s objective is to bridge the expectation gap – difference between what the developers
think they are supposed to build and what customers think they are going to get.
A team oriented approach is developed for requirements gathering.
Each attendee is asked to make a list of objects that are-
• Part of the environment that surrounds the system
• Produced by the system
• Used by the system
• Each participant prepares his/her list, different lists are then combined, redundant entries
are eliminated, team is divided into smaller sub-teams to develop mini-specifications and
finally a draft of specifications is written down using all the inputs from the meeting.
Contd.
4. Quality Function Deployment:

• In this technique customer satisfaction is of prime concern, hence it emphasizes on the
requirements which are valuable to the customer.
3 types of requirements are identified –
• Normal requirements – In this the objective and goals of the proposed software are
discussed with the customer. Example – normal requirements for a result management
system may be entry of marks, calculation of results etc
• Expected requirements – These requirements are so obvious that the customer need not
explicitly state them. Example – protection from unauthorised access.
• Exciting requirements – It includes features that are beyond customer’s expectations
and prove to be very satisfying when present. Example – when an unauthorised access is
detected, it should backup and shutdown all processes.
Contd.
The major steps involved in this procedure are –

1. Identify all the stakeholders, eg. Users, developers, customers etc
2. List out all requirements from customer.
3. A value indicating degree of importance is assigned to each requirement.
4. In the end the final list of requirements is categorised as –
– It is possible to achieve
– It should be deferred and the reason for it
– It is impossible to achieve and should be dropped off
5. Use Case Approach:

• This technique combines text and pictures to provide a better understanding of the
requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence they only give a
functional view of the system.
Contd.
The components of the use case deign includes three major things – Actor, Use cases, use
case diagram.
• Actor – It is the external agent that lies outside the system but interacts with it in some
way. An actor maybe a person, machine etc. It is represented as a stick figure. Actors can be
primary actors or secondary actors.
– Primary actors – It requires assistance from the system to achieve a goal.
– Secondary actor – It is an actor from which the system needs assistance.
• Use cases – They describe the sequence of interactions between actors and the system.
They capture who(actors) do what(interaction) with the system. A complete set of use cases
specifies all possible ways to use the system.
• Use case diagram – A use case diiagram graphically represents what happens when an
actor interacts with a system. It captures the functional aspect of the system.
– A stick figure is used to represent an actor.
– An oval is used to represent a use case.
– A line is used to represent a relationship between an actor and a use case.
Requirement Analysis,
Documentation,
• Requirement analysis is
significant and essential activity
after elicitation. We analyze,
refine, and scrutinize the
gathered requirements to make
consistent and unambiguous
requirements. This activity
reviews all requirements and
may provide a graphical view of
the entire system. After the
completion of the analysis, it is
expected that the
understandability of the project
may improve significantly. Here,
(i) Draw the context diagram:
The context diagram is a simple

model that defines the
boundaries and interfaces of
the proposed systems with the
external world. It identifies the
entities outside the proposed
system that interact with the
system. The context diagram of
student result management
system is given below:
(ii) Development of a Prototype
(optional):
• One effective way to find out what the customer wants is to construct a prototype,
something that looks and preferably acts as part of the system they say they want.
• We can use their feedback to modify the prototype until the customer is satisfied
continuously. Hence, the prototype helps the client to visualize the proposed system
and increase the understanding of the requirements. When developers and users are
not sure about some of the elements, a prototype may help both the parties to take a
final decision.
• Some projects are developed for the general market. In such cases, the prototype
should be shown to some representative sample of the population of potential
purchasers. Even though a person who tries out a prototype may not buy the final
system, but their feedback may allow us to make the product more attractive to others.
• The prototype should be built quickly and at a relatively low cost. Hence it will always
have limitations and would not be acceptable in the final system. This is an optional
activity.
Contd.
(iii) Model the requirements: This process usually consists of various

graphical representations of the functions, data entities, external entities,
and the relationships between them. The graphical view may help to find
incorrect, inconsistent, missing, and superfluous requirements. Such
models include the Data Flow diagram, Entity-Relationship diagram, Data
Dictionaries, State-transition diagrams, etc.
(iv) Finalise the requirements: After modeling the requirements, we will
have a better understanding of the system behavior. The inconsistencies
and ambiguities have been identified and corrected. The flow of data
amongst various modules has been analyzed. Elicitation and analyze
activities have provided better insight into the system. Now we finalize the
analyzed requirements, and the next step is to document these
requirements in a prescribed format.
Review and Management of User
Needs
• Software is more than just a
program code. A program is an
executable code, which serves
some computational purpose.
Software is considered to be
collection of executable
programming code, associated
libraries and documentations.
Software, when made for a
specific requirement is
called software product.
• Engineering on the other
hand, is all about developing
products, using well-defined,
Contd.
• Software engineering is an engineering branch associated with development of software product
using well-defined scientific principles, methods and procedures. The outcome of software engineering
is an efficient and reliable software product.
Need of Software Engineering:The need of software engineering arises because of higher rate of
change in user requirements and environment on which the software is working.
• Large software - It is easier to build a wall than to a house or building, likewise, as the size of
software become large engineering has to step to give it a scientific process.
• Scalability- If the software process were not based on scientific and engineering concepts, it would be
easier to re-create new software than to scale an existing one.
• Cost- As hardware industry has shown its skills and huge manufacturing has lower down he price of
computer and electronic hardware. But the cost of software remains high if proper process is not
adapted.
• Dynamic Nature- The always growing and adapting nature of software hugely depends upon the
environment in which user works. If the nature of software is always changing, new enhancements
need to be done in the existing one. This is where software engineering plays a good role.
• Quality Management- Better process of software development provides better and quality software
product.

Data Flow Diagrams
• A Data Flow Diagram (DFD) is a traditional visual representation of the information flows within a system.
A neat and clear DFD can depict the right amount of the system requirement graphically. It can be manual,
automated, or a combination of both.
• It shows how data enters and leaves the system, what changes the information, and where data is stored.
• The objective of a DFD is to show the scope and boundaries of a system as a whole. It may be used as a
communication tool between a system analyst and any person who plays a part in the order that acts as a
starting point for redesigning a system. The DFD is also called as a data flow graph or bubble chart.
• The following observations about DFDs are essential:
• All names should be unique. This makes it easier to refer to elements in the DFD.
• Remember that DFD is not a flow chart. Arrows is a flow chart that represents the order of events; arrows
in DFD represents flowing data. A DFD does not involve any order of events.
• Suppress logical decisions. If we ever have the urge to draw a diamond-shaped box in a DFD, suppress
that urge! A diamond-shaped box is used in flow charts to represents decision points with multiple exists
paths of which the only one is taken. This implies an ordering of events, which makes no sense in a DFD.
• Do not become bogged down with details. Defer error conditions and error handling until the end of the
analysis.
Standard symbols for DFDs
• Circle: A circle (bubble) shows a • Source or Sink: Source or Sink
process that transforms data is an external entity and acts as
inputs into data outputs. a source of system inputs or sink
• Data Flow: A curved line shows of system outputs.
the flow of data into or out of a
process or data store.
• Data Store: A set of parallel
lines shows a place for the
collection of data items. A data
store indicates that the data is
stored which can be used at a
later stage or by the other
processes in a different order.
The data store can have an
element or group of elements.
Levels in Data Flow Diagrams (DFD)
• The DFD may be used to perform a system or software at any level

of abstraction. Infact, DFDs may be partitioned into levels that
represent increasing information flow and functional detail. Levels
in DFD are numbered 0, 1, 2 or beyond. Here, we will see primarily
three levels in the data flow diagram, which are: 0-level DFD, 1-
level DFD, and 2-level DFD.
• 0-level DFD:It is also known as context diagram.It’s designed to
be an abstraction view, showing the system as a single process
with its relationship to external entities. It represent the entire
system as single bubble with input and output data indicated by
incoming/outgoing arrows.
Contd.
• 1-level DFD:In 1-level DFD,

context diagram is decomposed
into multiple
bubbles/processes.in this level
we highlight the main functions
of the system and breakdown
the high level process of 0-level
DFD into subprocesses.
Contd.
•2-level DFD:2-level DFD goes

one step deeper into parts of 1-
level DFD.It can be used to plan
or record the specific/necessary
detail about the system’s
functioning.
Data Dictionaries
• A data dictionary is a file or a set of files that includes a database's metadata. The data
dictionary hold records about other objects in the database, such as data ownership, data
relationships to other objects, and other data. The data dictionary is an essential component
of any relational database. Ironically, because of its importance, it is invisible to most
database users. Typically, only database administrators interact with the data dictionary.
• The data dictionary, in general, includes information about the following:
I. Name of the data item
II. Aliases
III. Description/purpose
IV. Related data items
V. Range of values
VI. Data structure definition/Forms
• The name of the data item is self-explanatory.
• Aliases include other names by which this data item is called DEO for Data Entry Operator
and DR for Deputy Registrar.
• Description/purpose is a textual description of what the data item is used for or why it
exists.
• Related data items capture relationships between
Software Engineeringdata items e.g., total_marks must 21
Contd.
• Data structure Forms: Data flows capture the name of
processes that generate or receive the data items. If the data
item is primitive, then data structure form captures the physical
structures of the data item. If the data is itself a data aggregate,
then data structure form capture the composition of the data
items in terms of other data items.
• The mathematical operators used within the data
dictionary are defined in the table:
Contd.
Entity-Relationship Diagrams
• ER-modeling is a data modeling method used in software
engineering to produce a conceptual data model of an information
system. Diagrams created using this ER-modeling method are
called Entity-Relationship Diagrams or ER diagrams or ERDs.
• Purpose of ERD
• The database analyst gains a better understanding of the data to
be contained in the database through the step of constructing the
ERD.
• The ERD serves as a documentation tool.
• Finally, the ERD is used to connect the logical structure of the
database to users. In particular, the ERD effectively communicates
the logic of the database to users.
• ER Model is used to model the logical view of the system from data24
Software Engineering
Contd.
Entity, Entity Type, Entity Set • An Entity is an object of Entity

– Type and set of all entities is
• An Entity may be an object called as entity set. e.g.; E1 is
with a physical existence – a an entity having Entity Type
particular person, car, house, Student and set of all students
or employee – or it may be an is called Entity Set. In ER
object with a conceptual diagram, Entity Type is
existence – a company, a job, represented as:
or a university course.
Contd.
• Attribute(s):
Attributes are the properties which define the entity type. For example,
Roll_No, Name, DOB, Age, Address, Mobile_No are the attributes which defines
entity type Student. In ER diagram, attribute is represented by an oval.
• Key Attribute –
The attribute which uniquely identifies each entity in the entity set is called
key attribute.For example, Roll_No will be unique for each student. In ER
diagram, key attribute is represented by an oval with underlying lines.
• Composite Attribute –
An attribute composed of many other attribute is called as composite
attribute. For example, Address attribute of student Entity type consists of
Street, City, State, and Country. In ER diagram, composite attribute is
represented by an oval comprising of ovals.
Contd.
• Multivalued Attribute –
An attribute consisting more than one value for a given entity. For example,
Phone_No (can be more than one for a given student). In ER diagram,
multivalued attribute is represented by double oval.
• Derived Attribute –
An attribute which can be derived from other attributes of the entity type is
known as derived attribute. e.g.; Age (can be derived from DOB). In ER
diagram, derived attribute is represented by dashed oval.
Relationship Type and Relationship Set: A relationship type represents

the association between entity types. For example,‘Enrolled in’ is a
relationship type that exists between entity type Student and Course. In ER
diagram, relationship type is represented by a diamond and connecting the
entities with lines.
Contd.
• Cardinality:
The number of times an entity of an entity set participates in a
relationship set is known as cardinality. Cardinality can be of different types:
• One to one – When each entity in each entity set can take part only once in
the relationship, the cardinality is one to one. Let us assume that a male can
marry to one female and a female can marry to one male. So the relationship will
be one to one.
• Many to one – When entities in one entity set can take part only once in the
relationship set and entities in other entity set can take part more than
once in the relationship set, cardinality is many to one. Let us assume that a
student can take only one course but one course can be taken by many students.
So the cardinality will be n to 1. It means that for one course there can be n
students but for one student, there will be only one course.
Contd.
• Many to many – When entities in all entity sets can take part

more than once in the relationship cardinality is many to
many. Let us assume that a student can take more than one
course and one course can be taken by many students. So the
relationship will be many to many.
• Using sets, it can be represented as:
Contd.
• Degree of a relationship set

• The number of participating entities in a relationship describes
the degree of the relationship. The three most common
relationships in E-R models are:
• Unary (degree1)
• Binary (degree2)
• Ternary (degree3)
• 1. Unary relationship: This is also called recursive
relationships. It is a relationship between the instances of one
entity type. For example, one person is married to only one
person.
Contd.
• Binary relationship: It is a relationship between the instances of two entity

types. For example, the Teacher teaches the subject.
• 3. Ternary relationship: It is a relationship amongst instances of three entity

types. In fig, the relationships "may have" provide the association of three
entities, i.e., TEACHER, STUDENT, and SUBJECT. All three entities are many-to-
many participants. There may be one or many participants in a ternary
relationship.
• In general, "n" entities can be related by the same relationship and is known
as n-ary relationship.
Software Requirement and
Specifications
A software requirements • Ranked for importance and/or
specification (SRS) is a document stability
that captures complete • Verifiable
description about how the system • Modifiable
is expected to perform. It is • Traceable
usually signed off at the end of Types of Requirements: The below
requirements engineering phase. diagram depicts the various types of
Qualities of SRS: requirements that are captured during
SRS.
• Correct
• Unambiguous
• Complete
• Consistent
Functional and non-Functional
requirements
Functional Requirement?
• In software engineering, a functional requirement defines a system or its component. It describes the
functions a software must perform. A function is nothing but inputs, its behavior, and outputs. It can
be a calculation, data manipulation, business process, user interaction, or any other specific
functionality which defines what function a system is likely to perform.
• Functional software requirements help you to capture the intended behavior of the system. This
behavior may be expressed as functions, services or tasks or which system is required to perform.
• Non-Functional Requirement?
• A non-functional requirement defines the quality attribute of a software system. They represent a set
of standards used to judge the specific operation of a system. Example, how fast does the website
load?
• A non-functional requirement is essential to ensure the usability and effectiveness of the entire
software system. Failing to meet non-functional requirements can result in systems that fail to satisfy
user needs.
• Non-functional Requirements allows you to impose constraints or restrictions on the design of the
system across the various agile backlogs. Example, the site should load in 3 seconds when the number
of simultaneous users are > 10000. Description of non-functional requirements is just as critical as a
functional requirement.

Contd.
• Example of Functional Requirements

• The software automatically validates customers against the ABC
Contact Management System
• The Sales system should allow users to record customers sales
• The background color for all windows in the application will be
blue and have a hexadecimal RGB color value of 0x0000FF.
• Only Managerial level employees have the right to view revenue
data.
• The software system should be integrated with banking API
• The software system should pass Section 508 accessibility
requirement.
Contd.
• Examples of Non-functional requirements

• Here, are some examples of non-functional requirement:
• Users must change the initially assigned login password
immediately after the first successful login. Moreover, the initial
should never be reused.
• Employees never allowed to update their salary information.
Such attempt should be reported to the security administrator.
• Every unsuccessful attempt by a user to access an item of data
shall be recorded on an audit trail.
• A website should be capable enough to handle 20 million users
with affecting its performance
• The software should be portable. So moving from one OS to
Functional vs Non Functional Requirements
Contd.
Advantages of Functional Requirement

• Here, are the pros/advantages of creating a typical functional requirement
document-
• Helps you to check whether the application is providing all the functionalities that
were mentioned in the functional requirement of that application
• A functional requirement document helps you to define the functionality of a system
or one of its subsystems.
• Functional requirements along with requirement analysis help identify missing
requirements. They help clearly define the expected system service and behavior.
• Errors caught in the Functional requirement gathering stage are the cheapest to fix.
• Support user goals, tasks, or activities for easy project management
• Functional requirement can be expressed in Use Case form or user story as they
exhibit externally visible functional behavior.
Contd.
• Advantages of Non-Functional Requirement
• Benefits/pros of Non-functional testing are:
• The nonfunctional requirements ensure the software system follow legal and compliance rules.
• They ensure the reliability, availability, and performance of the software system
• They ensure good user experience and ease of operating the software.
• They help in formulating security policy of the software system.
• KEY DIFFERENCE
• A functional requirement defines a system or its component whereas a non-functional requirement defines the
performance attribute of a software system.
• Functional requirements along with requirement analysis help identify missing requirements while the
advantage of Non-functional requirement is that it helps you to ensure good user experience and ease of
operating the software.
• Functional Requirement is a verb while Non-Functional Requirement is an attribute
• Types of Non-functional requirement are Scalability Capacity, Availability, Reliability, Recoverability, Data
Integrity, etc. whereas transaction corrections, adjustments, and cancellations, Business Rules, Certification
Requirements, Reporting Requirements, Administrative functions, Authorization levels, Audit Tracking, External
Interfaces, Historical Data management, Legal or Regulatory Requirements are various types of functional
requirements.
Software Prototyping
• The Software Prototyping refers to building software application
prototypes which displays the functionality of the product under
development, but may not actually hold the exact logic of the
original software.
• Prototype is a working model of software with some limited
functionality. The prototype does not always hold the exact logic
used in the actual software application and is an extra effort to be
considered under effort estimation.
• Prototyping is used to allow the users evaluate developer proposals
and try them out before implementation. It also helps understand
the requirements which are user specific and may not have been
considered by the developer during product design.
Contd.
Stepwise approach to design a software prototype.
• Basic Requirement Identification:This step involves understanding the very basics product requirements
especially in terms of user interface. The more intricate details of the internal design and external aspects
like performance and security can be ignored at this stage.
• Developing the initial Prototype:The initial Prototype is developed in this stage, where the very basic
requirements are showcased and user interfaces are provided. These features may not exactly work in the
same manner internally in the actual software developed. While, the workarounds are used to give the same
look and feel to the customer in the prototype developed.
• Review of the Prototype:The prototype developed is then presented to the customer and the other
important stakeholders in the project. The feedback is collected in an organized manner and used for further
enhancements in the product under development.
• Revise and Enhance the Prototype:The feedback and the review comments are discussed during this
stage and some negotiations happen with the customer based on factors like – time and budget constraints
and technical feasibility of the actual implementation. The changes accepted are again incorporated in the
new Prototype developed and the cycle repeats until the customer expectations are met.
Software Prototyping - Types
There are different types of software prototypes used in the industry. Following are the major software
prototyping types used widely −
• Throwaway/Rapid Prototyping:Throwaway prototyping is also called as rapid or close ended prototyping. This
type of prototyping uses very little efforts with minimum requirement analysis to build a prototype. Once the actual
requirements are understood, the prototype is discarded and the actual system is developed with a much clear
understanding of user requirements.
• Evolutionary Prototyping:Evolutionary prototyping also called as breadboard prototyping is based on building
actual functional prototypes with minimal functionality in the beginning. The prototype developed forms the heart
of the future prototypes on top of which the entire system is built. By using evolutionary prototyping, the well-
understood requirements are included in the prototype and the requirements are added as and when they are
understood.
• Incremental Prototyping:Incremental prototyping refers to building multiple functional prototypes of the various
sub-systems and then integrating all the available prototypes to form a complete system.
• Extreme Prototyping:Extreme prototyping is used in the web development domain. It consists of three sequential
phases. First, a basic prototype with all the existing pages is presented in the HTML format. Then the data
processing is simulated using a prototype services layer. Finally, the services are implemented and integrated to
the final prototype. This process is called Extreme Prototyping used to draw attention to the second phase of the
process, where a fully functional UI is developed with very little regard to the actual services.
Advantages –
• The customers get to see the partial product early in the life cycle.
This ensures a greater level of customer satisfaction and comfort.
• New requirements can be easily accommodated as there is scope
for refinement.
• Missing functionalities can be easily figured out.
• Errors can be detected much earlier thereby saving a lot of effort
and cost, besides enhancing the quality of the software.
• The developed prototype can be reused by the developer for more
complicated projects in the future.
• Flexibility in design.
• Disadvantages –
• Costly w.r.t time as well as money.
• There may be too much variation in requirements each time the prototype is
evaluated by the customer.
• Poor Documentation due to continuously changing customer requirements.
• It is very difficult for the developers to accommodate all the changes demanded by
the customer.
• There is uncertainty in determining the number of iterations that would be required
before the prototype is finally accepted by the customer.
• After seeing an early prototype, the customers sometimes demand the actual product
to be delivered soon.
• Developers in a hurry to build prototypes may end up with sub-optimal solutions.
• The customer might lose interest in the product if he/she is not satisfied with the initial
prototype.
Contd.
Software Prototyping - Application

• Software Prototyping is most useful in development of systems
having high level of user interactions such as online systems.
Systems which need users to fill out forms or go through various
screens before data is processed can use prototyping very
effectively to give the exact look and feel even before the actual
software is developed.
• Software that involves too much of data processing and most of
the functionality is internal with very little user interface does not
usually benefit from prototyping. Prototype development could
be an extra overhead in such projects and may need lot of extra
efforts.
Feasibility Study
A feasibility study is carried out to select the best system that meets performance requirements.
The main aim of the feasibility study activity is to determine whether it would be financially and
technically feasible to develop the product. The feasibility study activity involves the analysis of the
problem and collection of all relevant information relating to the product such as the different data items
which would be input to the system, the processing required to be carried out on these data, the output
data required to be produced by the system as well as various constraints on the behaviour of the system.
Technical Feasibility
This is concerned with specifying equipment and software that will successfully satisfy the user
requirement. The technical needs of the system may vary considerably, but might include :
• The facility to produce outputs in a given time.
• Response time under certain conditions.
• Ability to process a certain volume of transaction at a particular speed.
• Facility to communicate data to distant locations.
In examining technical feasibility, configuration of the system is given more importance than the actual
make of hardware. The configuration should give the complete picture about the system’s requirements:
How many workstations are required, how these units are interconnected so that they could operate and
communicate smoothly.
What speeds of input and output should be achieved at particular quality of printing.
Contd.
Economic Feasibility
Economic analysis is the most frequently used technique for evaluating the effectiveness of a proposed
system. More commonly known as Cost / Benefit analysis, the procedure is to determine the benefits and
savings that are expected from a proposed system and compare them with costs. If benefits outweigh
costs, a decision is taken to design and implement the system. Otherwise, further justification or
alternative in the proposed system will have to be made if it is to have a chance of being approved. This is
an outgoing effort that improves in accuracy at each phase of the system life cycle.
Operational Feasibility
This is mainly related to human organizational and political aspects. The points to be considered are:
• What changes will be brought with the system?
• What organizational structure are disturbed?
• What new skills will be required? Do the existing staff members have these skills? If not, can they be
trained in due course of time?
This feasibility study is carried out by a small group of people who are familiar with information system
technique and are skilled in system analysis and design process.
Proposed projects are beneficial only if they can be turned into information system that will meet the
operating requirements of the organization. This test of feasibility asks if the system will work when it is
developed and installed.
Information Modeling
• An information model in software engineering is a representation of concepts and
the relationships, constraints, rules, and operations to specify data semantics for a
chosen domain of discourse. Typically it specifies relations between kinds of things,
but may also include relations with individual things. It can provide sharable, stable,
and organized structure of information requirements or knowledge for the domain
context.
• The term information model in general is used for models of individual things, such
as facilities, buildings, process plants, etc. In those cases the concept is specialised
to facility information model, building information model, plant information model,
etc. Such an information model is an integration of a model of the facility with the
data and documents about the facility.
• Within the field of software engineering and data modeling an information model is
usually an abstract, formal representation of entity types that may include their
properties, relationships and the operations that can be performed on them. The
entity types in the model may be kinds of real-world objects, such as devices in a
network, or occurrences, or they may themselves be abstract, such as for the
entities used in a billing system. Typically, they are used to model a constrained
domain that can be described by a closed set of entity types, properties,
Decision Tables
• Decision table is a brief visual representation for specifying which actions to
perform depending on given conditions. The information represented in decision
tables can also be represented as decision trees or in a programming language
using if-then-else and switch-case statements.
• A decision table is a good way to settle with different combination inputs with their
corresponding outputs and also called cause-effect table. Reason to call cause-
effect table is a related logical diagramming technique called cause-effect graphing
that is basically used to obtain the decision table.
• Importance of Decision Table:

• Decision tables are very much helpful in test design technique.
• It helps testers to search the effects of combinations of different inputs and other
software states that must correctly implement business rules.
• It provides a regular way of stating complex business rules, that is helpful for
developers as well as for testers.
• It assists in development process with developer to do a better job. Testing with all
combination might be impractical.
Decision Tables,
Contd.
Advantage of Decision Table:

• Any complex business flow can be easily converted into the test
scenarios & test cases using this technique.
• Decision tables work iteratively that means the table created at the first
iteration is used as input table for next tables. The iteration is done only
if the initial table is not satisfactory.
• Simple to understand and everyone can use this method design the test
scenarios & test cases.
• It provide complete coverage of test cases which help to reduce the
rework on writing test scenarios & test cases.
• These tables guarantee that we consider every possible combination of
condition values. This is known as its completeness property.
SRS Document
• A Software Requirements Specification (SRS) is a document that

describes the nature of a project, software or application. In
simple words, SRS document is a manual of a project provided it
is prepared before you kick-start a project/application. This
document is also known by the names SRS report, software
document. A software document is primarily prepared for a
project, software or any kind of application.
• There are a set of guidelines to be followed while preparing the
software requirement specification document. This includes
the purpose, scope, functional and nonfunctional
requirements, software and hardware requirements of the
project. In addition to this, it also contains the information about
environmental conditions required, safety and security
Table of Contents
Contd.
An SRS describes the functionality the product needs to fulfill all stakeholders
(business, users) needs.
A typical SRS includes:
• A purpose
• An overall description
• Specific requirements
• The best SRS documents define how the software will interact when embedded in hardware — or when
connected to other software. Good SRS documents also account for real-life users.
• Why Use an SRS Document?

• A software requirements specification is the basis for your entire project. It lays the framework that every
team involved in development will follow.
• It’s used to provide critical information to multiple teams — development, quality assurance, operations, and
maintenance. This keeps everyone on the same page.
• Using the SRS helps to ensure requirements are fulfilled. And it can also help you make decisions about your
product’s lifecycle — for instance, when to retire a feature.
• Writing an SRS can also minimize overall development time and costs. Embedded development teams
especially benefit from using an SRS.
IEEE Standards for SRS,
• IEEE Standard SRS

Template
Software Quality Assurance (SQA),
• Software Quality Assurance (SQA) is simply a way to assure quality in the

software. It is the set of activities which ensure processes, procedures as well as
standards suitable for the project and implemented correctly.
• Software Quality Assurance is a process which works parallel to development of a
software. It focuses on improving the process of development of software so that
problems can be prevented before they become a major issue. Software Quality
Assurance is a kind of an Umbrella activity that is applied throughout the software
process.
• Software Quality Assurance have:
• A quality management approach
• Formal technical reviews
• Multi testing strategy
• Effective software engineering technology
• Measurement and reporting mechanism
Major Software Quality Assurance
Activities:
• SQA Management Plan:
Make a plan how you will carry out the sqa through out the project. Think which set of software
engineering activities are the best for project.check level of sqa team skills.
• Set The Check Points:
SQA team should set checkpoints. Evaluate the performance of the project on the basis of collected
data on different check points.
• Multi testing Strategy:
Do not depend on single testing approach. When you have lot of testing approaches available use
them.
• Measure Change Impact:
The changes for making the correction of an error sometimes re introduces more errors keep the
measure of impact of change on project. Reset the new change to change check the compatibility
of this fix with whole project.
• Manage Good Relations:
In the working environment managing the good relation with other teams involved in the project
development is mandatory. Bad relation of sqa team with programmers team will impact directly
and badly on project. Don’t play politics.
Benefits of Software Quality
Assurance (SQA):
Benefits of Software Quality Assurance (SQA):
• SQA produce high quality software.
• High quality application saves time and cost.
• SQA is beneficial for better reliability.
• SQA is beneficial in the condition of no maintenance for long time.
• High quality commercial software increase market share of company.
• Improving the process of creating software.
• Improves the quality of the software.
Disadvantage of SQA:
There are a number of disadvantages of quality assurance. Some of them
include adding more resources, employing more workers to help maintain
quality and so much more.
SEI-CMM Model
• The Software Engineering Institute (SEI) Capability Maturity Model
(CMM) specifies an increasing series of levels of a software
development organization. The higher the level, the better the
software development process, hence reaching each level is an
expensive and time-consuming process.
• CMM was developed by the Software Engineering Institute (SEI) at
Carnegie Mellon University in 1987.
• It is not a software process model. It is a framework which is used to
analyse the approach and techniques followed by any organization
to develop a software product.
• It also provides guidelines to further enhance the maturity of those
software products.
• It is based on profound feedback and development practices
adopted by the most successful organizations worldwide.
Levels of CMM
• Key Process Areas (KPA’s):
Each of these KPA’s defines the basic requirements that should be met by a software process in order to satisfy the KPA and achieve that
level of maturity.
• The 5 levels of CMM are as follows:
• Level-1: Initial –
• No KPA’s defined.
• Processes followed are adhoc and immature and are not well defined.
• Unstable environment for software dvelopment.
• No basis for predicting product quality, time for completion, etc.
• Level-2: Repeatable –
• Focuses on establishing basic project management policies.
• Experience with earlier projects is used for managing new similar natured projects.
• KPA’s:Project Planning- It includes defining resources required, goals, constraints, etc. for the project. It presents a detailed plan to be
followed systematically for successful completion of a good quality software.
• Configuration Management- The focus is on maintaining the performance of the software product, including all its components, for the
entire lifecycle.
• Requirements Management- It includes the management of customer reviews and feedback which result in some changes in the
requirement set. It also consists of accommodation of those modified requirements.
• Subcontract Management- It focuses on the effective management of qualified software contractors i.e. it manages the parts of the
software which are developed by third parties.
• Software Quality Assurance- It guarantees a good quality software product by following certain rules and quality standard guidelines while
development.
Contd.
• Level-3: Defined –
• At this level, documentation of the standard guidelines and procedures takes place.
• It is a well defined integrated set of project specific software engineering and
management processes.
• KPA’s:Peer Reviews- In this method, defects are removed by using a number of review
methods like walkthroughs, inspections, buddy checks, etc.
• Intergroup Coordination- It consists of planned interactions between different
development teams to ensure efficient and proper fulfilment of customer needs.
• Organization Process Definition- It’s key focus is on the development and maintenance
of the standard development processes.
• Organization Process Focus- It includes activities and practices that should be followed
to improve the process capabilities of an organization.
• Training Programs- It focuses on the enhancement of knowledge and skills of the team
members including the developers and ensuring an increase in work efficiency.
Contd.
• Level-4: Managed –
• At this stage, quantitative quality goals are set for the
organization for software products as well as software processes.
• The measurements made help the organization to predict the
product and process quality within some limits defined
quantitatively.
• KPA’s:Software Quality Management- It includes the
establishment of plans and strategies to develop a quantitative
analysis and understanding of the product’s quality.
• Quantitative Management- It focuses on controlling the project
performance in a quantitative manner.
Contd.
• Level-5: Optimizing –
• This is the highest level of process maturity in CMM and focuses
on continuous process improvement in the organization using
quantitative feedback.
• Use of new tools, techniques and evaluation of software
processes is done to prevent recurrence of known defects.
• KPA’s:Process Change Management- Its focus is on the
continuous improvement of organization’s software processes to
improve productivity, quality and cycle time for the software
product.
• Technology Change Management- It consists of identification and
use of new technologies to improve product quality and decrease
the product development time.
THANK YOU

Software Requirements Analysis and Specifications Guide

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Software Requirements Analysis and Specifications Guide

Caricato da

Copyright:

Formati disponibili

Unit II

Software Requirement Analysis and

Introduction to Software Engineering 5

3. Facilitated Application Specification Technique:

4. Quality Function Deployment:

The major steps involved in this procedure are –

5. Use Case Approach:

The context diagram is a simple

(iii) Model the requirements: This process usually consists of various

Introduction to Software Engineering 15

• The DFD may be used to perform a system or software at any level

• 1-level DFD:In 1-level DFD,

•2-level DFD:2-level DFD goes

Entity, Entity Type, Entity Set • An Entity is an object of Entity

Relationship Type and Relationship Set: A relationship type represents

• Many to many – When entities in all entity sets can take part

• Using sets, it can be represented as:

• Degree of a relationship set

• Binary relationship: It is a relationship between the instances of two entity

• 3. Ternary relationship: It is a relationship amongst instances of three entity

Introduction to Software Engineering 33

• Example of Functional Requirements

• Examples of Non-functional requirements

Advantages of Functional Requirement

Software Prototyping - Application

• Importance of Decision Table:

Advantage of Decision Table:

• A Software Requirements Specification (SRS) is a document that

• Why Use an SRS Document?

• IEEE Standard SRS

• Software Quality Assurance (SQA) is simply a way to assure quality in the

Potrebbero piacerti anche