software engineering unit 2

05/01/2023 Abhimanyu Mishra(CSE) JETGI 1

SOFTWARE ENGINEERINGUNIT-II

ABHIMANYU MISHRAASSISTANT PROF.(CSE)

JETGI


Requirement Engineering Processes. Feasibility Study. DFD & ER Diagrams. Decision Tables. SRS Document. IEEE Standard For SRS. SQA:Verification & Validation. SQA Plans & Attributes. ISO 9000 Models,SEI-CMM Model.

CONTENTS:


“Requirement elicitation is the activity during which software requirement are discovered, expressed, and revealed from system requirements”. Its sources may be system requirement documentation, customer or market analysis.Various technologies are used to involved the user on the basis of level of involvement required.The range of variation can be classified in three main styles:a) Consultative Design.b) Representative Design.c) Consensus Design.

Software requirement specification:


Requirement Gathering

SRS

Requirement Engineering Requirement

Analysis

Requirement Document

Requirement Review

Problem Solving

Fig-Software Elicitation


Requirement Gathering-In this phase requirement are going to identified.Requirement Analysis- Analysis of requirement are done in order to identify in consistency, defect or missing requirement.Requirement Process-Review process is followed for correct out or improved the quality of SRS.

CLASSIFICATION OF COMPONENT;


This is a process in which people from client &contractor organization both involved for checking the requirements for omission. Different parts of document are checked by different people involved in this type of activities. Various activities performed during user needs review process are: Plan a review Review meeting Follow-up actions Checking for redundancy Completeness Consistency

Review & Management of User needs:


“Management of user needs is not a simple task it depends upon various issues of different organization”. This can be done in following steps:

Collecting organization history-The performance of organization, future plan, organization goal.

Current problem understanding-There must be clear understanding of the currently known issues and what are the expectations of management.

Know your user profile-It is important to know user who operate the system. Most organization charts do not give information pertaining the user. The profile of each of these user group is vastly different as far as capability and exposure of technology concerned.

Management Needs:


Feasibility study:

When we are developing a system we know weather proposed system will be feasible or not i.e. practically implementable or not? It may be possible that the proposed system may not be implementable due to many reasons like it may take long time in development than the specified time limit, cost may increase than proposed. There may be several types of feasibility depending on the aspects they covers. Some of them are:• Technical Feasibility• Operation Feasibility• Economical Feasibility


Phases of Feasibility:

Technical feasibility-The technical feasibility study basically centers on alternatives for hardware, software and design approach to determine the functional aspects of system.The technical issues raised during feasibility are:a) Does the necessary technology exist.b) Does the proposed equipment have technical capacity to hold data.c) Can the system be expended, if developed?d) Are there technical guarantee of accuracy, reliability and security of dataOperational feasibility-Operational feasibility is a measure of how people are able to work with system. This type of feasibility demands if the system will work when developed and installed.


Data Flow Diagram:

A DFD is also known as “bubble sort” has the purpose of clarifying system requirements and identifying major transformation. It shows the flow of data through a system. It is a graphical tool because it present a picture. It present a system or software at any level of abstraction.Four simple notation are used to complete a DFD-i. Data Flow-The data flow is used to describe the movement of information from a

part of system to another part.ii. Process-A circle or bubble represents a process that transform incoming data to

outgoing data. iii. External Entity- A square defines a source or destination of system data. External

entities represents any entity that supplies information from the system.iv. Data Store- The data store is used to collect data at rest or a temporary repository

of data.


Curved arrow

Sources & sink

Process

Data resolved wire/ data storage


Entity Relationship Diagram:

The entity relationship data model is based on a perception of a real word that consist of a basic objects, called entity, and of relationships among these objects.An entity is a object or thing in the real world that is distinguishable from other objects.An entity have a set of attributes. A relationship is an association among several entities.ER diagram consist of following major component-i. Rectangle-which represent entity sets.ii. Ellipse-which represent attributes.iii. Diamond-which represent relationship sets.iv. Lines-which link attributes to entity set and to relationship sets.


Rectangle

Ellipses

Diamond

Lines

Fig- E-R Representation


Advantages of E-R Model- It is easy and simple to understand with minimal training. Therefore the model

can be used by the db designer to communicate design to end user. It has explicitly linkages between entities. In the ER model it is possible to find a connection from one node to all the

other nodes.

Disadvantages of E-R Model- Limited constraint representation. Limited relationship representation. No representation of data. Loss of information.


Decision Table:

A major drawback to decision tree is the lack of information in its format to tell us what other combination of conditions of test. To overcome from this drawback decision table is used. A decision table is a table of contingencies for defining a problem and the action

to be taken. It is a single representation of the relationships between conditions and action. A Decision table consist two parts:-i. Stub- The stub part is divided into “upper quadrant” and “lower quadrant” called

condition and action stub.ii. Entry- The entry part are also divided into “upper quadrant” and “lower

quadrant”.


Post paid

condition RulesPrepaid

Full talk time

Pay before service

Pay after serviceReduction of

service

T

F

T

F

T

F

T

F

F

Fig- Decision table


IEEE Standards of SRS:

The SRS development is a collaborative effort for designing a software project which is further converted into SRS document. Several organizations have a proposed their basic structure and the components for SRS. IEEE has given basic structure for software development.Sample of a basic SRS outline:i. Introduction- purpose Document convention Intended audiences References Additional information


Overall description- Product perspective Product function User environment Design Assumptions & dependedExternal interface requirement- User interface Hardware interface Software interface Communication protocols and interfacesSystem features- Description and priority Action/result Functional requirements


Software Quality Assurance:Software Quality assurance plan is a standard activity which ensure the quality goals of the organization. It gives details and template on all activities, which have become part of the

standard implementation.The SQA plan include the following: • Project planning• Models of data, classes and object, processes, design architecture• SRS• Test plans for testing SRS• User manuals online help etc.• Audit & ReviewIn SQA plan 3 kinds of activities performed:• Organization specific• Software specific• Customer Specific


Software verification refers to a set of activities that ensure that software correctly implements a specific function i.e. “Are we building the product right”.Software validation is concerned with showing that the requirements actually define the system that the customer wants. It refers to a set of activities that ensure that the software that is going to be build is traceable to customer requirements. “Are we building the right product”.

Traditionally software verification & validation is define as system engineering methodology to ensure that quality is built into software during development. The analysis and test activities are performed by V & V evaluates and assess the software product.

Verification & Validation:


ISO Certificate 9000

ISO 9000 certification serves as reference for contact between independent parties. The ISO 9000 standard specifies the guidelines for maintaining for a quality system. The ISO standard mainly addresses operational aspects and organizational aspects .

Such as responsibility, reporting, etc. It is important to realize that ISO 9000 standard is a set of guideline for the

production process and is not directly concerned with product itself. ISO 9000 is a series of three standards:ISO 9001, ISO 9002 and ISO 9003. The different types of software industries to which the different ISO standard apply are as:i. ISO 9001-This standard applies to the organization engaged in design,

development and servicing of goods.ii. ISO 9002- This organization applies to those which do not design product but are

only involved in production.iii. ISO 9003- This standard applies to organizations involved only in installation and

testing of the product.


Capability Maturity Model:

The capability maturity model is not a software life cycle model. Instead it is a strategy for improving the software process, irrespective of actual life cycle model used. The CMM has been developed by Software engineering institute(SEI) at Carnegie Mellon university in 1987. There are five level of maturity:i. Initialii. Repeatableiii. Defineiv. Managev. Optimizing


Classification of levels of maturity:

i. Initial- At the level 1 the process followed by the organizations are not well defined. They are immature. As aresult of stable environment is not available for software development.

ii. Repeatable- The level 2 focuses on establishing basic project management policies.

iii. Design- At this level standard process to be used across the organization are defined and documented.

iv. Manage- At this level of CMM quantitative quality goals are set for the organization for the software product as well as software processes.

v. Optimizing- Establishing strategies and plan for quantitative understanding of software project.