Unit 2-1

Unit I
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.
I. 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.
II. 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

III. 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.
IV. Quality Function Deployment:

• In this technique customer satisfaction is of prime concern, hence it emphasizes on the requirements
which are valuable to the customer.
Three 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 unauthorized access.
• Exciting requirements – It includes features that are beyond customer’s expectations and prove to be
very satisfying when present. Example – when an unauthorized access is detected, it should backup
and shutdown all processes.
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 categorized 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
V. 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.
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 diagram 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 and 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, we may also
use the interaction with the customer to clarify
points of confusion and to understand which
requirements are more important than others.
• The various steps of requirement analysis are
shown in given figure.
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:
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.
Development of a Prototype (optional):
• 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.

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.
Finalize 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, scientific principles and
methods.
Management of User Needs
• 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.

Management of User Needs
• 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.
Data Flow Diagrams
• 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 in 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 process that
transforms data inputs into data outputs.
• Data Flow: A curved line shows 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.
• Source or Sink: Source or Sink is an external
entity and acts as a source of system inputs or sink
of system outputs.
Levels in Data Flow Diagrams (DFD)
• The DFD may be used to perform a system or software at any level of abstraction. In fact, 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.
Levels in Data Flow Diagrams (DFD)
• 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 sub processes.
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
Data Dictionaries
• 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 data items e.g., total_marks must always equal to
internal_marks plus external_marks.
• Range of values records all possible values, e.g. total marks must be positive and between 0 to 100.

Data Dictionaries
• 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:
Data Dictionaries
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 data perspective which consists of these
components:
Entity, Entity Type, Entity Set –

• An Entity may be an object with a physical
existence – a particular person, car, house, or
employee – or it may be an object with a
conceptual existence – a company, a job, or a
university course.
• An Entity is an object of Entity Type and set of
all entities is called as entity set. e.g.; E1 is an
entity having Entity Type Student and set of all
students is called Entity Set. In ER diagram,
Entity Type is represented as:
• 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.

• 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, multi-valued 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.

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.
Cardinality
• 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.
Relationship
• 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 specification (SRS) is a document
that captures complete description about how the system is Types of Requirements: The below diagram
expected to perform. It is usually signed off at the end of depicts the various types of requirements that
requirements engineering phase. are captured during SRS.
Qualities of SRS:
• Correct
• Unambiguous
• Complete
• Consistent
• Ranked for importance and/or stability
• Verifiable
• Modifiable
• Traceable
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 other OS does not create any problem.
• Privacy of information, the export of restricted technologies, intellectual property rights, etc. should be audited.
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 use d 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, relationships and
operations.
• An information model provides formalism to the description of a problem domain without constraining how that description is mapped to an
actual implementation in software. There may be many mappings of the information model. Such mappings are called data models, irrespective of
whether they are object models (e.g. using UML), entity relationship models or XML schemas.
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.
• A decision table is basically an outstanding technique used in both testing and requirements management.
• It is a structured exercise to prepare requirements when dealing with complex business rules.
• It is also used in model complicated logic.
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 requirements,
software quality attributes of the project etc.
• A Software requirements specification document describes the intended purpose, requirements and nature of a software to
be developed. It also includes the yield and cost of the software.
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.
• This model describes a strategy that should be followed by moving through 5 different levels.
• Each level of maturity shows a process capability level. All the levels except level-1 are further described by Key Process Areas
(KPA’s).
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.
• Defect Prevention- It focuses on identification of causes of defects and to prevent them from recurring in future projects by
improving project defined process.
THANK YOU

Unit 2-1

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit 2-1

Uploaded by

Copyright:

Available Formats

Unit I

Software Requirement Analysis and

II. Brainstorming Sessions:

Introduction to Software Engineering 5

III. Facilitated Application Specification Technique:

IV. Quality Function Deployment:

Three types of requirements are identified –

The major steps involved in this procedure are –

V. Use Case Approach:

The context diagram is a simple model that

Introduction to Software Engineering 13

Introduction to Software Engineering 15

• Software is more than just a program code. A program

• Engineering on the other hand, is all about developing

Introduction to Software Engineering 17

Introduction to Software Engineering 18

Introduction to Software Engineering 20

• 1-level DFD: In 1-level DFD, context diagram is

•2-level DFD:2-level DFD goes one step deeper into

• The name of the data item is self-explanatory.

Introduction to Software Engineering 26

Entity, Entity Type, Entity Set –

Introduction to Software Engineering 32

Introduction to Software Engineering 34

Introduction to Software Engineering 40

Example of Functional Requirements

Stepwise approach to design a software prototype.

Software Prototyping - Application

• Importance of Decision Table:

Advantage of Decision Table:

• Why Use an SRS Document?

• IEEE Standard SRS Template

Benefits of Software Quality Assurance (SQA):

You might also like