SOFTWARE ENGINEERING

(KDS 063)

Lecture Notes

UNIT II – SOFTWARE REQUIREMENT

SPECIFICATIONS(SRS)

By
Ms.Pallavi Shukla
U.C.E.R.
 UNIT II – SOFTWARE REQUIREMENT
SPECIFICATIONS(SRS)

REQUIREMENT-
• We define requirement as :

• Conduction of capability needed by a user to solve a problem or achieve an objective

• A Condition or capability that must be met or posses by a system to satisfy a contract,

standard, specification or other formally imposed document.

SRS(SOFTWARE REQUIREMENT SPECIFICATION) –

• It is a document that completely describes what the proposed software should do
without describing what the proposed software should do without describing how
the software will do it.

Requirement Engineering –
• It can be defined as the “Systematic process of documenting requirement through an
interactive co operative process of analyzing the problem, documenting the resulting
observations in a variety of representation format & checking the accuracy of the
understanding gained”

or

It is defines as “ the systematic use of proven principles techniques , tools & languages for the cost
effective analysis, documentation and ongoing evolution of user needs & the specification of the
external behaviors of the system in order to satisfy these needs.

INFORMAL & REQUIREMENT WELL DEFINED COMPLETE &

FUZZY CONSISTENT
REQUIREMENT
ENGINEERING REQUIREMENTS
 There are wide variety of methodologies which are proposed for expressing
requirements specification.
Eg. Natural Language descriptions. Structured Analysis techniques. Object oriented ,
requirements analysis Techniques etc.

Classification of Requirements –
• Functional Requirements
• Non Functional Requirements
• Domain Requirements
FUNCTIONAL REQUIREMENTS-
• They focus on the functionality of the software components that build the system.
• Functional requirements are the services which are the end users expect the final
product to provide.
• There are many ways of expressing functional requirements eg. Natural language,
structured or formatted language. With no rigorous syntax, formal specification
language with proper syntax.

NON FUNCTIONAL REQUIREMENTS –

• These are constraints imposed on the system and deal with issues like
maintainability , security, performance reliability etc.

• Other terms used to specify NFRs are –

• Quality attributes

• Constraints

• Goals

• Non behavioral Requirement

• NFRs can be classified as:

• Interface constraints

• Performance Constraints : response time, security , reliability storage space etc.

• Operating constraints.

• Life cycle Constraints : maintainability , reusability ,portability, flexibility etc.

• Economic Constraints.

DOMAIN REQUIREMENTS-
• These are the requirements that are specific to an application domain eg. Banking , Hospital etc.

• These requirements are therefore identified from domain model and are not user specific.
NEED OF SRS –

• A Basic purpose of software requirements specification is to bridge the communication gap between
user & developer.

• To help the clients to understand their own needs as it forces the client and users to think, visualize ,
interact & discuss with others.

• An SRS establishes the basis for agreement between the client & the supplier on what the software
product will do this basis for agreement is frequently formalized into a legal contract between the
client and the developer. So through SRS, the client clearly describes what it expects from the
supplier, & the developer clearly understands what capabilities to build in the software.

• An SRS provides a reference for validation of the final product.

• A high quality SRS is prerequisite to high quality software.

• A high Quality SRS reduces the development Cost. Hence the Quality of the SRS impacts customer
satisfaction , system validation quality of the final Software & software development cost.

Correctness-
• An SRS is said to be correct if every requirement stated in the document is correct.

• For ensuring Correctness users may be asked to review the document

• Further, it can be compared with some proceedings documents or with applicable standards.

Completeness-

• It is said to be complete if –

• All the significant functional & non functional requirements to be satisfied by the software
are included in the SRS.

• Response to all valid and invalid class of data is included. It means for every valid and invalid
inputs defined in SRS, appropriate output is also mentioned.

• All figures , tables & pages are numbered. They are also properly named and referenced.

• Sections in the SRS should avoid the label ”to be determined” as far as possible.

Consistency –
 • It is said to be consistent if there is no conflict between the requirements in the documents.

• Different types of conflict may exist between the requirements. Some of them are:

• Conflicts between characteristics of real world entities.

• Temporal or logical Conflicts between two items

• Conflicts can also arise if different terminology is used to describe same real world object or
event.

Unambiguousness-

• Unambiguousness in the SRS document is supported only if each and every requirement started in it
has only one interpretation.

• It can be best achieved by using requirements specification languages, requirements analysis &
modelling techniques & reviewing the document written in natural language by a third process.

Modifiability-

• Requirements keep changing and changes must be reflected properly in the SRS.

• An SRS is said to be modifiable if changes can be made to the requirements easily, completely and
consistently while retaining its structure & style.

Verifiability-

An SRS is said to be verifiable if for each requirement written in SRS, there exists some cost effective
process using which a person or tool can ensure that software meets the requirements.

Traceability –

• It can be further classified into 2 types:

• a) Forward Traceability – Which is achieved by assigning a unique name or number to each

requirement.

• b) Backward Traceability – Which is achieved by each requirement referring explicitly to its source in
previous documents.

Design Independent –

• It is said to be design independent if it does not include any implementation details.

REQUIREMENT PROCESS-
• It is the sequence of activities that need to be performed in the requirements in the requirements
phase nad that culminate in producing high quality document containing the software requirements
specification(SRS).

• Requirements Phase consists of 3 basic activities :

• Problem or Requirement Analysis /Requirements Elicitation.

• Requirement Specification.

• Requirement Validation.

Requirement Analysis / Requirement Elicitation-

• It is concerned with understanding of problem domain at the beginning of the project because
requirements are fuzzy and are not clearly understood by the analyst.
 • This process of acquiring information/ knowledge about a specific problem domain through various
techniques to build the requirements model is called Requirement Elicitation.

• This activity of requirement elicitation helps the analyst to gain knowledge about the problem domain
which in turn is used to produce formal specification of software to be developed to meet the
customer.

Requirement Specification –

• The purpose is to produce formal software requirements model.

• These models specify the functional and non functional properties of the system along with the
constraints imposed on the system.

Requirement Validation –

• It is defined as process to ensure the consistency of requirements model with respect to customers'
needs.

• The validation is done not only for the final model but also for all intermediate models generated.

• If requirements are not validated , errors in the requirements definition would propagate to the
successive stages resulting into lot of modification & rework.

• Following steps should be followed while validating requirements

• Ensure that requirements are consistent. They are not conflicting with other requirements.

• Ensure that requirements are complete in all respect.

Ensure that requirements are realistic and realizable.

ER model
o ER model stands for an Entity-Relationship model. It is a high-level data model. This
model is used to define the data elements and relationship for a specified system.
o It develops a conceptual design for the database. It also develops a very simple and
easy to design view of data.
o In ER modeling, the database structure is portrayed as a diagram called an entity-
relationship diagram.

For example, Suppose we design a school database. In this database, the student will be an
entity with attributes like address, name, id, age, etc. The address can be another entity with
attributes like city, street name, pin code, etc and there will be a relationship between them.

Component of ER Diagram
Entity:

An entity may be any object, class, person or place. In the ER diagram, an entity can be
represented as rectangles.

Consider an organization as an example- manager, product, employee, department etc. can be

taken as an entity.

a. Weak Entity
An entity that depends on another entity called a weak entity. The weak entity doesn't contain
any key attribute of its own. The weak entity is represented by a double rectangle.

2. Attribute

The attribute is used to describe the property of an entity. Eclipse is used to represent an
attribute.

For example, id, age, contact number, name, etc. can be attributes of a student.

a. Key Attribute

The key attribute is used to represent the main characteristics of an entity. It represents a
primary key. The key attribute is represented by an ellipse with the text underlined.

b. Composite Attribute

An attribute that composed of many other attributes is known as a composite attribute. The
composite attribute is represented by an ellipse, and those ellipses are connected with an
ellipse.

c. Multivalued Attribute

An attribute can have more than one value. These attributes are known as a multivalued
attribute. The double oval is used to represent multivalued attribute.

For example, a student can have more than one phone number.

d. Derived Attribute

An attribute that can be derived from other attribute is known as a derived attribute. It can be
represented by a dashed ellipse.

For example, A person's age changes over time and can be derived from another attribute
like Date of birth.

Relationship
The association among entities is called a relationship. For example, an employee works_at a
department, a student enrolls in a course. Here, Works_at and Enrolls are called relationships.
Relationship Set
A set of relationships of similar type is called a relationship set. Like entities, a relationship
too can have attributes. These attributes are called descriptive attributes.
Degree of Relationship
The number of participating entities in a relationship defines the degree of the relationship.

• Binary = degree 2
 • Ternary = degree 3
• n-ary = degree
ER Model is represented by means of an ER diagram. Any object, for example, entities,
attributes of an entity, relationship sets, and attributes of relationship sets, can be represented
with the help of an ER diagram.
Entity
Entities are represented by means of rectangles. Rectangles are named with the entity set they
represent.

Attributes
Attributes are the properties of entities. Attributes are represented by means of ellipses. Every
ellipse represents one attribute and is directly connected to its entity (rectangle).

If the attributes are composite, they are further divided in a tree like structure. Every node is
then connected to its attribute. That is, composite attributes are represented by ellipses that are
connected with an ellipse.

Multivalued attributes are depicted by double ellipse.

Derived attributes are depicted by dashed ellipse.

Relationship
Relationships are represented by diamond-shaped box. Name of the relationship is written
inside the diamond-box. All the entities (rectangles) participating in a relationship, are
connected to it by a line.
Binary Relationship and Cardinality
A relationship where two entities are participating is called a binary relationship. Cardinality
is the number of instance of an entity from a relation that can be associated with the relation.
• One-to-one − When only one instance of an entity is associated with the relationship,
it is marked as '1:1'. The following image reflects that only one instance of each entity
should be associated with the relationship. It depicts one-to-one relationship.

• One-to-many − When more than one instance of an entity is associated with a

relationship, it is marked as '1:N'. The following image reflects that only one instance
of entity on the left and more than one instance of an entity on the right can be
associated with the relationship. It depicts one-to-many relationship.

• Many-to-one − When more than one instance of entity is associated with the
relationship, it is marked as 'N:1'. The following image reflects that more than one
instance of an entity on the left and only one instance of an entity on the right can be
associated with the relationship. It depicts many-to-one relationship.

• Many-to-many − The following image reflects that more than one instance of an entity
on the left and more than one instance of an entity on the right can be associated with
the relationship. It depicts many-to-many relationship.
Participation Constraints
• Total Participation − Each entity is involved in the relationship. Total participation is
represented by double lines.
• Partial participation − Not all entities are involved in the relationship. Partial
participation is represented by single lines.

Keys
o Keys play an important role in the relational database.
o It is used to uniquely identify any record or row of data from the table. It is also used
to establish and identify relationships between tables.

For example: In Student table, ID is used as a key because it is unique for each student. In
PERSON table, passport_number, license_number, SSN are keys since they are unique for
each person

Types of key:
1. Primary key
o It is the first key which is used to identify one and only one instance of an entity
uniquely. An entity can contain multiple keys as we saw in PERSON table. The key
which is most suitable from those lists become a primary key.
o In the EMPLOYEE table, ID can be primary key since it is unique for each employee.
In the EMPLOYEE table, we can even select License_Number and Passport_Number
as primary key since they are also unique.
o For each entity, selection of the primary key is based on requirement and developers.

2. Candidate key
o A candidate key is an attribute or set of an attribute which can uniquely identify a
tuple.
o The remaining attributes except for primary key are considered as a candidate key.
The candidate keys are as strong as the primary key.
For example: In the EMPLOYEE table, id is best suited for the primary key. Rest of the
attributes like SSN, Passport_Number, and License_Number, etc. are considered as a
candidate key.

3. Super Key

Super key is a set of an attribute which can uniquely identify a tuple. Super key is a superset
of a candidate key.

For example: In the above EMPLOYEE table, for(EMPLOEE_ID, EMPLOYEE_NAME)

the name of two employees can be the same, but their EMPLYEE_ID can't be the same.
Hence, this combination can also be a key.

The super key would be EMPLOYEE-ID, (EMPLOYEE_ID, EMPLOYEE-NAME), etc.

4. Foreign key
o Foreign keys are the column of the table which is used to point to the primary key of
another table.
o In a company, every employee works in a specific department, and employee and
department are two different entities. So we can't store the information of the
department in the employee table. That's why we link these two tables through the
primary key of one table.
o We add the primary key of the DEPARTMENT table, Department_Id as a new
attribute in the EMPLOYEE table.
o Now in the EMPLOYEE table, Department_Id is the foreign key, and both the tables
are related.

Reduction of ER diagram to Table

The database can be represented using the notations, and these notations can be reduced to a
collection of tables.

In the database, every entity set or relationship set can be represented in tabular form.

The ER diagram is given below:

There are some points for converting the ER diagram to the table:

o Entity type becomes a table.

In the given ER diagram, LECTURE, STUDENT, SUBJECT and COURSE forms individual
tables.

o All single-valued attribute becomes a column for the table.

In the STUDENT entity, STUDENT_NAME and STUDENT_ID form the column of

STUDENT table. Similarly, COURSE_NAME and COURSE_ID form the column of
COURSE table and so on.

o A key attribute of the entity type represented by the primary key.

In the given ER diagram, COURSE_ID, STUDENT_ID, SUBJECT_ID, and LECTURE_ID

are the key attribute of the entity.

o The multivalued attribute is represented by a separate table.

In the student table, a hobby is a multivalued attribute. So it is not possible to represent

multiple values in a single column of STUDENT table. Hence we create a table
STUD_HOBBY with column name STUDENT_ID and HOBBY. Using both the column, we
create a composite key.

o Composite attribute represented by components.

In the given ER diagram, student address is a composite attribute. It contains CITY, PIN,
DOOR#, STREET, and STATE. In the STUDENT table, these attributes can merge as an
individual column.

o Derived attributes are not considered in the table.

In the STUDENT table, Age is the derived attribute. It can be calculated at any point of time
by calculating the difference between current date and Date of Birth.

Using these rules, you can convert the ER diagram to tables and columns and assign the
mapping between the tables. Table structure for the given ER diagram is as below:
REQUIREMENT PROCESS-

• It is the sequence of activities that need to be performed in the requirements in the

requirements phase and that culminate in producing high quality document containing the
software requirements specification(SRS).

• Requirements Phase consists of 3 basic activities :

• Problem or Requirement Analysis /Requirements Elicitation.

• Requirement Specification.

• Requirement Validation.

Requirement Analysis / Requirement Elicitation-

• It is concerned with understanding of problem domain at the beginning of the project because
requirements are fuzzy and are not clearly understood by the analyst.

• This process of acquiring information/ knowledge about a specific problem domain through
various techniques to build the requirements model is called Requirement Elicitation.

• This activity of requirement elicitation helps the analyst to gain knowledge about the problem
domain which in turn is used to produce formal specification of software to be developed to
meet the customer.

Requirement Specification –

• The purpose is to produce formal software requirements model.

• These models specify the functional and non functional properties of the system along with
the constraints imposed on the system.

Requirement Validation –

• It is defined as process to ensure the consistency of requirements model with respect to

customers' needs.

• The validation is done not only for the final model but also for all intermediate models
generated.

• If requirements are not validated , errors in the requirements definition would propagate to
the successive stages resulting into lot of modification & rework.

• Following steps should be followed while validating requirements

• Ensure that requirements are consistent. They are not conflicting with other
requirements.

• Ensure that requirements are complete in all respect.

• Ensure that requirements are realistic and realizable.

•
 • Requirement process is seen as linear sequence of 3 activities , but it is not so to most
real activities, there is considerable overlap and feedback between these activities.

REQUIREMENT ELICITATION TECHNIQUES -

INTERVIEWS –

• It is popular technique for understanding the problem domain and quite successful.

• It may take the form of questionnaire , open ended interviews & focus groups.

• Structured Interview- Analysist can simplify ask the users about their expectations from the
system but the main problem is that users can bypass their limitations so analysts can probe
the user through a set of questions thus avoiding the above mentioned problem this type of
interview is called Structured Interview.

Focus Group –

• It is a kind of group interview where groups are brought together to discuss some topic of
research to the researcher & allow more natural interactions than open ended interviews.

• Steps for interviews are :

a) Create the Questions

b) Select the interviews

c) Plan Contracts

d) Conduct the interview

e) Close the meeting

f) Determine where to go next

• Brainstorming –

It is a group technique to promote creative thinking and can eb used during requirements
elicitation process to generate new ideas.

• Task Analysis –

It is a technique of decomposing the problem domain into a hierarchy of tasks & subtasks.

It is an effective technique for elicititating requirements concerned with Human – Computer

Interaction (HCI)

Form Analysis –

• Forms plan an important role in any organization and contain lot of meaningful information
about data objects of the domain.

• Forms are important source of information for modeling the static view or data aspect of the
system.

Delphi Technique –
 • In this session , participants are made to write the requirements .

• These requirements are then exchanged among participants who give their comments to
get a revised set of requirements .

• This process is repeated till a final consensus is reached.

Use Scenario and Use Case Based Requirements Elicitation-

• Use Scenario are unstructured descriptions of the user requirements.

• Use Cases are structured descriptions of the user requirements

• Use case diagrams are graphical representation to show the system at different levels of
abstraction.

Domain Analysis –

• This technique focuses on reuse of requirements from similar domain.

• Therefore starting from one or more existing systems requirements for the new system can
be formulated.

• This is just like representing the requirements at another higher level of abstraction called
Meta Level.

Facilitated Application Specification Techniques(FAST)-

FAST was developed specifically for collecting requirements & is similar to brainstorming.

Challenges in Eliciting Requirements –

• Understanding large/ complex system requirements.

• Undefined System Boundaries

• Users not clear about their needs

• Representing requirements in suitable form

• Conflicting requirements.

• Requirements changing quite often.

• Resolving TBD( To be determined)

• Partitioning the system suitably in order to reduce complexity

• Validating & tracing requirements

• Proper documentation of the requirements.

• Meeting the time and budget , constraints of the customer.

• Identifying the critical requirements

Basic Principle –

• Used in analysis or elicitation is the same as in any complete task: Divide and Conquer.

• Partition the problem into subproblems and then try to understand each subproblem and its
relationship to other subproblems in an effort to understand the total problem.

• This is an applied recursively by treating each subsystem as a system in its own right.

• During analysis Partitioning is done with respect to objects or functions.

Object –

• It is an entity in the real world that has clearly defined boundaries and an independent
existence . By considering real world objects , the focus of the analysis stays on the problem
domain , rather than the solution domain.

Function –

It is a task, service, process ,mathematical function, or activity that is now being performed in the
real world has to be performed by the system that will be built to solve the real world problem.

State –

• A state of a system represents some conditions about the system.

• When using state , a system is first viewed as operating in one if the several possible states ,
and then object based or function based analysis is performed for each state. This approach
is sometimes used in real time software or process control software.

Projection –

• A system is defined form multiple points of view projecting a 3 dimensional object on the 3
different 2 dimensional planes is a similar process.

• While using projection , different viewpoints of the system are defined and the system is
analyzed from these different perspectives separately using an object based or function
based approach.

Basic Approaches to Problem Analysis –

• 1) Informal Approach – Based on Structured Communication

• 2) Conceptual Modelling Based Approach

• 3) Prototyping

• Informal Approach – It is one where no defined methodology is used.

• The information about the system is obtained by interaction with the client , end users,
Questionnaires , study of existing documents , brainstorming etc.

• In such an approach, the analyst will have a series of meetings with the clients & end users.
 • In the early meetings , the clients & end users will explain to the analyst about their work,
their environment & their needs as they perceive them.

• Any documents describing the work or the organization may be given, along with outputs of
the existing methods of performing the task.

• Once the analyst understands the system to some extent, he uses the new few meetings to
seek clarifications of the parts he does not understand.

• In the final few meetings , the analyst essentially explains to the client what he understands
the system should do & uses the meetings as a means of verifying if what he proposes the
system should do is indeed consistent with the objectives of the clients.

Structured Analysis –
• Structured Analysis Techniques uses function based decomposition while modeling
the problem domain & the data consumed & produced by these functions.
• The structured analysis ,method helps an analyst decide what type of information to
obtain at different points in analysis & it helps organize information so that the
analyst is not overwhelmed by the complexity of the problem.
• It is a top down refinement approach , which was originally called Structured
Analysis & Specifications.
• Structured Analysis Techniques result in graphical representation of the software
system development.
• 1) Entity Relationship Diagram
• 2) Function Decomposition Diagram
• 3) Data Flow Diagram
• 4) State Transition Diagram
• 5) Data Dictionary
• 6) Process Specifications
• 7) Context Diagram
• 8) Decision Trees
DATA FLOW DIAGRAM (DFD) –
• It is a modelling tool used to model the functional view of the system in terms of
processes & flow of data between these processes.
• The techniques for modelling flow of data between processes is also called Process
Modeling.

PROCESS-
• It is used to show some kind of transformations on data.
• It is represented by a circle with name of process written inside it.
Process names should be meaningful verb object phrases not nouns.

Compute
Salary

Data Flow –
• Data flows show data in motion between different processes , process and store or
external agent or process.
• They are represented by arrows which are labelled
• A data flow represents –
• 1) Data input to a process
• 2) Output form a process
• 3) Insertion of new data in the store or retrieval of existing data
• 4) Updating existing data in the store.
• 5) Deletion of existing data form the store
• A data flow can be further classified as
• Convergent Data Flow- It is formed by merging multiple data flows into a single data
flow.
• Divergent Data Flow – it is one which breaks up into multiple data flows.
STORE –
• It represent data at rest and can be shown graphically by the symbol.
Employees

Normally stores correspond to entities in the ER diagram.

• They are named as plural of corresponding data model entities,
• It means that if in ER diagram an entity student exists , there must be a store called
students in the DFD.
EXTERNAL AGENT-
• They are also called Terminators and represent people, organization or other
systems external to the system being development.
• They are represented graphically by a rectangular box.
• External Agents provide input to the system & also receive output from the system.

BANK

CONTEXT DIAGRAM:
Context Diagram is also called a level 0 data flow diagram.

It is a diagram in which working of the whole organization is represented by a single process and its
interaction with external agents is shown through exchange of data.
DATA DICTIONARY:
• It is the most important part of structured analysis model.
• It is the organized listing of all data elements of the system with their precise and
unambiguous definitions.
• Data dictionary contains information about.
o Meaning of aggregate item with comments.
o Units of elementary items
o Definition of data/control flows.
o Definition of data stores
o Definition of entities, relationships , attributes, external agents.
o Definition of external control /data flows.
o Local data elements used in writing process specifications any more.

= is defined as / composed of
+ and
{ } iteration (0 or more occurrences)
Min { } max iteration with min & max values specified.
( ) optional data elements
[ ] selection of one data from several choices separated by |
@ store identifier
** Comment
SOME EXAMPLES ARE: =

a) Order = Company_ name + Address + 1 {ordered item} 10

Order is composed of Company_Name, address and minimum one and
maximum 10 ordered_items.

b) Student = [Undergraduate| post graduate ]

Student is an undergraduate or post graduate student.

c) Student_name = first_name + (middle_name)+last_name.

APPROACHES TO BUILD DFDs-

1)Classical Approach –
In this analyst starts with level 0 DFD or context diagram and using top down decomposition
arrives at level 1.
Function decomposition diagram is also used for identifying process at various levels.
Problem with this approach is that there is no guidelines to decompose a process at nth
level of DFD at (n+1) th level.
As a result the whole process is very time consuming.

2) Event Partitioning Approach –

This approach tries to streamline the process drawing DFDs.
The focus of the whole approach is the notion of event because events play very important
role in any organization.
Steps followed are:
1) Identify and the compile the list of events taking place in the organization.
2) For each event draw a event response process model consisting of single process.
3) Join the event response models to arrive at level1
4) If necessary perform upward /downward levelling.

EVENTS –

It is anything which happens in the system & causes system to change state.

1) Flow Oriented Events – they are accompanied by some kind of data. Customer places
Order in this event accompanies data about the order placed by the customer.
2) Temporal Events – They occur on a fixed date and time. Ex every Friday at 5 PM, a
report is to be generated to view the weekly sales.
3) System Events – these events are internal to the system and occur based on the system
status.eg. whenever the inventory level goes below certain value, event is generated to
place order with the supplier.
GUIDELINES FOR DRAWING DFDs –

PROCESS –
1) All the processes must be numbered.
2) Use meaningful verb object phrases for process names eg Compute salary, generate
Reports.
3) Avoid processes with only inputs, They are called Sinks .
4) Avoid processes with the outputs
5) If necessary redraw the DFD as many times as required.

DATA FLOW -
1) Make sure that all data flows are labelled.
2) Data flows cannot move from a store to another store or store to an external
agent.it must mov through a process.
3) A data flow does not move back to the same process it leaves.
4) A fork can be shown in a data flow to indicate that same data is going from a
location to one or more destinations.

EXTERNAL AGENT -
1) Use noun phrases to label external agents
2) External agents cannot interact directly with a store or any other external agent
through data flows.

DATA STORE -
1) Use Meaningful noun phrases to label data stores.
2) Data cannot move directly from data stores to other data stores or external agents . it
must move through process.

STATE TRANSITION DIAGRAM (STD)

It models the dynamic view i.e time dependent behaviour of the system

Major components of the diagram are :

1) State
2) Action
3) Arrow
4) Condition

State – A state is described by a set of attribute values at a particular instant of time and is
represented by a rectangle or an oval sign.
Ex – Person depending upon his age can be in one of the following states - infant, child ,
adult , middle age.

Infant
Adult

State can be either initial / start date, end/final state or in between state.
A system can have only one initial state and single or multiple final states.

Action –
Whenever system changes state in response to a condition it performs one or more actions.
It is also possible that it may not perform any action
Some of the actions can be displaying a message,

Arrows –
Arrows connect two or more states indicating that S1 changes to state s2 as a result of some
condition c being satisfied.

S1 S2
C/A

Condition –
A condition is some event in the external environment which causes the system to change
from say state s1 to s2.
This event can be anything, say an interrupt , signal or arrival of some data.

Child Adult
Age = 18 years

PROCESS SPECIFICATIONS-
In a DFD processes are shown as black boxes.
Logic Modelling pr process Specification is used to give the description of logic contained ina
process at the lowest level of decomposition.
Higher level processes which are decomposed into detailed DFD’s do not have Process
specification
Process Specification can be written using
a) Structured Language
b) Pre/ Post Conditions
c) Decision Tables
d) Decision Trees
e) Flow charts
f) Nessi Sheindermann Diagrams etc.

STRUCTURED LANGUAGE –
It is a subset of English language that supports language constructs to represent sequence,
repetition and conditional statements in order to specify the process details.

It can be called Structured English.

Alternate names for Structured English are Program Design Language (PDL)

Program statement / Specification Language (PSL)

SENTENCE – A sentence in the structured English can be a simple verb object phrase or it can take
the form of an algebraic equation.

VERBS – They are normally chosen from a small set of action oriented verbs & vary fron
organization.

Ex – ADD, DELETE, GET, READM UPDATE, SORT, VALIDATE etc.

OBJECTS – Objects in these verb object phrases are the data elements already defined in the data
dictionary.

Some of the constructs are –

1) IF Condition
Sentence 1
ELSE

Sentence 2

End if

2) DO WHILE Condition
Sentence 1
End do
3) REPEAT
Sentence 2

Until Condition
4) DO CASE
Case variable = value 1:
Sentence 1;
Case variable = value 2:
 Sentence 2;
.
.
.
Case variable = value n :
Sentence _n;
Default:
Sentence n+1;
END CASE

DECISION TABLE –
When the process logic is very complicated , involving multiple conditions , it is not possible to
represent the process logic efficiently with structured English . In such type of scenario, decision tables
are used to represent the logic.

Main parts of Decision Table are –

1) Condition Stubs
2) Action Stubs
3) Rules
CONDITION STUBS - It list all the conditions relevant to the decision

ACTION STUBS – Action stubs are part of the table lists all possible actions that will take place for a
valid set of conditions.

RULES – Rules part of the table specifies which set of conditions will trigger which action.

STEPS FOLLWOED TO CONSTRUCT DECISION TABLES ARE :

1) List all conditions and the values conditions can have

2) List all possible actions
3) List all possible rules in terms of combination of various conditions
4) For each rule define the action.
1 2 3 4 5
C1 N N Y Y Y
C2 N N Y Y
C3 N Y N
A1 X
A2 X X
A3 X

C1 – Account number is Correct

C2 – Signature Matches
C3 – There is enough money in the account
A1 – Give Money
A2 – Give statement that not enough money is there
A3 – Call the vigilance department to check for fraud

Y – YES
N – NO
 BLANK – either true or false

If an action is to be taken for a particular combination of the conditions , it is shown by

an X
If there is no mark – it means that action is not performed,

REGULAR EXPRESSION –
It can be used to specify the structure of symbol strings formally.
String specification is useful for specifying things as input data, Command sequence &
contents of a message.
Regular expressions can be considered as grammar for specifying the valid sequences in a
languages and can be automatically processed.
They are routinely used in Compiler Construction for recognition of symbols & Tokens.

VALIDATION –
Development of software starts with the requirements document , which is also use to determine
eventually weather or not the delivered software system is acceptable.

It is therefore important that the requirements specification contains no errors and specifies the
client’s requirements correctly.

It is extremely desirable to detect errors in the requirement before the design and development of
the software design.

Basic objective of the requirements validation activity is to ensure that the SRS reflects the actual
requirements accurately and clearly

A related objective us to check that the SRS document is itself of good quality

Many type of errors are possible , but the most common errors are

OMISSION- It is a common error in requirements in this some user requirement is simply not included
in the SRS , the omitted requirements may be related to the behavior of the system, its constraints ,
or any other factor.

It directly affects the external completeness of the SRS.

INCONSISTENCY – It can be due to contradictions within the requirements themselves or to

incompatibility of the stated requirements with the actual requirements of the client or with the
environment in which the system will operate.

INCORRECT FACT - Errors of this type occur when some fact recorded in the SRS is not correct.

AMBIGUITY – Errors of this type occur when there is some requirements that have multiple
meanings i.e their interpretation is not unique.
IEEE SOFTWARE PROJECT MANAGEMENT PLAN(SPMP) –
1. Introduction
1.1 Project Overview
1.2 Project Deliverables
1.3 Evolution of the software Project Management Plans
1.4 Reference Materials
1.5 Definitions and Acronyms
2. Project Organization
2.1 Process Model
2.2 Organizational Structure
2.3 Organizational Boundaries & Interfaces
2.4 Project Responsibilities
3. Managerial Process
3.1 Management Objectives & Priorities
3.2 Assumptions , Dependencies & Constraints
3.3 Risk Management
3.4 Monitoring & Controlling Mechanisms
3.5 Staffing Plans
4. Technical Process
4.1 Methods, Tools & Techniques
4.2 Software Documentation
4.3 Project Support Functions
5. Work Packages , Schedule & Budget
5.1 Work Packages
5.2 Dependencies
5.3 Resource Requirement
5.4 Budget & Resource Allocation
5.5 Schedule
 6. Additional Components
7. Index
8. Appendices

INTRODUCTION :

Project Overview : Brief description is given of the project objectives, the product to be delivered ,
the activities & their resulting work products.

Project Deliverables : All the items to be delivered to the client are listed here together with the
delivery dates.

Evolution of the software Project Management Plan: The SPMP requires continual updating in the
light of experience and of change within both the client organization and the software development
organization.

Reference Materials: All documents referenced in the SPMP are listed here.

Definitions and Acronyms: this information ensures that the SPMP will be understood the same way
by everyone.

PROJECT ORGANISATION:

It specifies how the product is to be developed both from the viewpoint of the software process & the
organization structure of developers

Process Model – It is specified in terms of the activities such as designing the product or performing
product testing , and the project functions , such as Project Management or configuration
Management

Organizational Structure : Management structure of the development organization is described.

Organizational Boundaries & Interfaces – Project Members have to interact with the client
organization & with other members of this own organization Administrative & Managerial Boundaries
between the project itself and other entities must be laid down.

Project Responsibilities – for each project function such as SQA and for each activity such as Product
testing , the responsible individual must be identified.

S/W Documentation – Contains the documentation requirements

Project Support Functions – It details plans for the supportive functions such as Configuration
Management & Quality Assurance , Including Test plans.

WORK PACKAGES , SCHEDULE AND BUDGET –

Work Packages- Work Packages are specified , with their associated work products broken down into
activities & tasks.

Dependencies- Dependencies between packages & external events are specified.

Resource Requirements- To complete the project , a wide variety of resources will be required.
Budget & resource Allocation – the allocation of resources & budget to the various project functions,
activities & task is presented.

Schedule – A detailed schedule is given for each component of the project. This master plan will then
be followed, it is hoped that the project will be completed on time & within budget.

MANAGERIAL PROCESS –

Management Objectives and priorities- The philosophy , goals & priorities for management are
described. This include frequency & mechanisms of reporting , relative priorities among requirements
, schedule & budget for the project , Risk management procedures.

Assumptions, Dependencies & Constraints - Any assumptions & Constraints in the specification
document appear here.

Risk Management – Various risks factors associated with the project are listed in this subsection as
well as the mechanisms used for tracking these risk factors.

Monitoring & Controlling Mechanisms – Reporting Mechanisms for the project are described in
detail, including review and audit mechanisms.

Staffing Plan – the numbers and type of Personnel required are listed , together with the durations
for which they will be needed.

TECHNICAL PROCESS –

Methods, Tools & Techniques- Technical aspects of Hardware and software sre described in detail.

ADDITIONAL COMPONENTS :

They includes –

a) Subcontractor Management Plans

b) Security Plans
c) Independent Verification & validation plans
d) Training Plans
e) Hardware Procurement Plans
f) Installation Plans
g) Product Maintenance Plan.

BENEFITS OF IEEE SPMP –

1) It is a standard drawn up by representative of many different organisations involved in

software development.
2) This standard reflects the efforts of the people from both software industry & academia.
3) The IEEE SPMP is designed for use with all types of software product , irrespective of size.
4) New personnel hired by organizations will not require any training.

SOFTWARE QUALITY
It is the “Conformance to explicit stated functional & performance requirements , explicitly
documented development standards, & implicit characteristics that are expected of all professionally
developed software”

Software Product Quality –

The product Quality describes the attributes of the products of the software process. It can be :

a) Completeness of the design documents.

b) Traceability of the design
c) Reliability & Maintainability of the code.
d) Coverage of the tests.

Software Process Quality –

Process quality describes the attributes of the software development process itself, Following are
software environment elements that are present in all the software projects are :

Process Quality mainly focuses in

a) Correct implementation of a techniques.

b) Productivity of a tool
c) Abilities of a tool
d) Communicativeness of an organization
e) How well suited are the installation & facilities.
SOFTWARE QUALITY ASSURANCE (SQA) –
It consists of those procedures , techniques and tools applied by software professional to ensure that
software product meets or exceeds prespecified standards during a development cycle

and without specific prescribed standards , Quality Assurance entails ensuring that a software product
meets or exceeds a minimal industrial or commercially acceptable level of excellence.

Purpose of SQA is to provide management with appropriate visibility into the orocess being used by
the software Project and of the products being developed,

SQA involves reviewing & auditing the software products & activities to verufy that they comply with
the applicable procedures & standards & providing the software project and other appropriate
managers with the results of these reviews & audits.

OBJECTIVES OF SOFTWARE QAUALITY ASSURANCE –

1) A Quality Management Approach

2) Effective Software Engineering Technology
3) Formal technical reviews that are applied throughout the software process
4) A multi testing startgey is drawn
5) Control of software documentation & the changes made to it.
6) A procedure to assure compliance with software development standards when
applicable.
7) Measurement & reporting mechanisms.

GOALS OF SOFTWARE QUALITY ASSURANCE –

 1) Software Quality Assurance Activities are planned.
2) Adherence of software products & activities to the applicable standards , procedures &
requirements is verified objectively
3) Affected groups & individuals are informed of software Quality Assurance activities &
results.
4) Non Compliance issues that cannot be resolved within the software project are
addressed by senior management.

SQA Activities -

1. Applications of Technical Methods- software quality is designed into the software but
not added after ward implies must have set of technical methods & tools to help analyst
generate high quality specifications & designs.
2. Formal Technical Reviews – A formal technical review is a stylized meeting by
technical staff to uncover Quality Problems.
3. Soaftware Testing – Appropriate strategies for software testing should be applicable.
4. Enforcement of standards – There are several Quality standards such as ISO 9000, SEI
CMM etc meant for ensuring software quality if these standards are used, can be applied
by developers as a part of formal view.
5. Control of change – Change control includes – Formalised Requests for change,
Evaluates the nature of the change, Controls the impact of the change,
6. Measurement – Software metrices are needed to track Quality & access impact of
methodological and procedural changes.
7. Record Keeping & Reporting – Collection & dissemination of software Quality
Assured information is required. Results of audits , reviews , change control, testing
and other SQA activities are part of record of the project.

ISO 9000 MODELS

International Standards : International Standards are documented agreements containing
technical specifications or other precise criteria can be used consistently as rules, guidelines
or definitions of characteristics , to ensure that materials , products , processes & services
are fit for their purpose.
they contribute to making life simpler and to increasing the reliability & effectiveness of the
goods & services we use.
International standardization is well established for many technologies in such diverse fields
as information processing and communications, textiles, packaging, distribution of goods,
energy production & utilization , ship building, banking and financial services.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION(ISO) –
It is an international, non governmental organization that promotes the development and
implementation of voluntary international standards. This is done through a cooperative ,
consensus building process that results in the creation of product & process management
standards.
ISO STANDARDS – ISO Standards are written specification and guidance documents that
establish internationally harmonized conventions for the operation , design, performance or
management of products(technical standards) and processes (management standards)
ISO 9000 is a series of standards dealing with Quality management systems.
Conformance standards are ISO 9001, ISO 9002 & ISO 9003 and state the requirements for
an effective Quality System. Guidance standards recommend how to use the series, develop
Quality systems, and apply the requirements in various industries.

ISO Standard Series –

ISO 9000 – Quality Management & Quality Assurance standards Guidelines for selection &
use.
ISO 9001 - Model for Quality assurance in design/development production installation &
servicing.
ISO 9002 – Model for Quality Assurance in Production & Installation.
ISO 9003 – Model for Quality Assurance in Final Inspection and Test.
ISO 9004 – Generic Guidelines FOR Management & systems
ISO 9004 – 2 – Guidelines for services
ISO - 14001 – Environment Management Systems Guidelines Principles, Systems &
Supporting techniques.

ELEMENTS OF ISO 9000 STANDARDS –

1) Management Responsibility –
First Requirement is for management to formulate a Quality Policy & provide the
necessary organization & resources for the Quality System.

Management must review the overall health of the Quality System on a regular basis
to ensure its suitability & effectiveness.

2) Quality System – it must be documented in a Quality Manual and Operational

Procedures.
It must be effectively implemented & maintained in accordance with these Quality
documents.

3) Control Review – Contracts and orders must be reviewed to verify the customer
needs are adequately defined & well understood.

4) Design Control – customer requirements for new or modified products must be

translated into an appropriate design. Design activities must be planned & the design
inputs defined and approved.
 5) Document & Data Control – Documents must be approved before they are issued &
be identified with a revision level. Documents changes must be authorized & sent to
all identified recipients.

6) Purchasing – Suppliers must be evaluated and selected based on their ability to meet
Quality requirements. Purchase orders must precisely describe the ordered product &
services.

7) Control of Customer – Supplied Product – This requirement applies when a customer

furnishers items for incorporation into their products or for related support,

8) Product Identification & Traceability - Product must be identified by suitable means

during all stages of production. If traceability is required , individual products or
batched must be identified during production & for shipment to the customer.

9) Process Control – Production must be planned & scheduled. Personnel be provided

with work instructions for complex operations.

10) Inspection & Testing – Received items must be inspected or otherwise verified as
being acceptable prior to production use.

11) Inspection, Measuring & Test Equipment – All measuring equipment used to verify
prodcuts must be identified and checked for accuracy. The equipment must be
calibrated on a prescribed interval against re cognized standards. This requirement also
applies to less tangible tools, such as software used to verify conformance to
specifications.

12) Inspection & Test Status- The inspection & test status of items must clearly indicate
if they have been inspected or not, put on hold, or rejected.

13) Control of Non Conforming Product – Defective or non conforming products must
be identified and the defect recorded.

14) Corrective & Preventive Action – Causes of product or process problems must be
investigated and corrective actions taken to prevent recurrence.

BENEFITS OF ISO 9000 CERTIFICATION -

1) Improved Customer Satisfaction

2) Greater Quality Awareness
3) Higher Real & Perceived Quality
4) Positive Cultural Change
5) Competitive Edge
6) Increased Market Share
7) Increased Productivity
8) REDUCED Costs
9) Improved Communication
10) Better Product & Services
11) Increased Employee Participation
 12) Boost Employee Morale
13) Eliminate Variation
14) Continuous Improvement

LIMITATATIONS OF ISO 9000 CERTIFICATION –

1. ISO 9000 does not automatically leas to total Quality Management i.e Continuous
Improvement.
2. ISO 9000 does not provide any guideline for defining an appropriate process.
3. ISO 9000 certification process is not foolproof & thus variations in the certification
norms may exist.

CAPABILITY MATURITY MODEL –

There are number of process improvement models for organization attempting to

mature their processes.
The models are developed by the Software Engineering Institute (SEI).
Goal of SEI is to provide leadership in the state if Software engineering to improve
Quality of systems throughout the lifecycle.
Capability Maturity Model(CMM) provides the means to measure an organization
process maturity against a set of common feature that are specified at each of the maturity
levels.
The SEI CMM is also used as a guideline for software process Improvement (SPI)
initiatives.
The Capability Maturity Model is based on the following premises.
a) Software Quality of an information technology system in large stem from quantity
of the processes used to create it.
b) The level of technology used in information technology systems must be
appropriate to the maturity of the processes.
c) System delivery is a process that can be managed, measured and progressibvely
improved.

STRUCTURE OF SEI CMM –

The SEI CMM is a framework of key processes defines a 5 level of evolutionary path
of software process maturity.
The level of maturity indicates the process capability of an organization.

Key processes Areas (KPAs) are defined for each of the maturity levels from level 2 to level 5.

Within each of the KPAs , a number of goals & activities are defined.

Within each of the KPAs the activities are grouped into 5 common features.
 a) Commitment to perform
b) Ability to perform
c) Activities Performed
d) Measurement & Analysis
e) Verifying Documents

LEVELS OF SEI CMM –

The CMM defines 5 levels of maturity for an Organization.
Each of these levels focuses on a set of process goals.
As an organization moves through the levels , the processes introduced build on the
maturity established in the previous levels.

Level 1 : Initial -
Processes are ad-hoc and success depends on individual heroics.
As a result, organizations at level 1 are unlikely to be able to accurately predict schedules ,
budgets , or quality.

Level 2 : Repeatable –
At level 2, basic management planning & tracking processes are established at the project
level.
Process discipline is starting which enables the organization to repeat successes.

Level 3 : Defined –
Software process are defined at the organization level. Each project starts with the
organizations processes and tailors them for their specific needs.
The software processes are integrated with the management processes.

Level 4 – Managed –
When an organization reaches level 4 , the processes have been well established and
measured.
Metrices that have been gathered since level1 are analyzed to form the basis for setting of
quantitative quality goals.

Level 5 – Optimized – Level 5 is the top level of Maturity and these organizations are
focused on continuous improvement.
 LEVEL 2 REPATABLE LEVEL –

Requirements Management – The purpose is to establish an agreed to requirements

specification that will from the basis for the project plan.

Goals of Requirements management are stated as

• System Requirements allocated to software are controlled to establish a
baseline for software engineering and management use.
• Software plans, products and activities are kept consistent with the system
requirements allocated to software.

b) Software Project Planning –

Goals are –

• Software estimates are documented for use in planning and tracking the software
project.
• Software project activities and commitments are planned & documented.
• Affected groups and individuals agree to their commitments related to the software
projects.

Software Project Tracking & Oversight –

Purpose is to provide management with accurate information on the progress of the project & to
identify deviations from the plan as early as possible.

Goals are –

• Actual results & performances are tracked against the software plans.
• Corrective actions are taken & managed to closure when actual results & performance
deviate significantly from the software plans.
• Changes to software commitments are agreed to by affected groups & individuals.

Software Sub Contract Management –

Purpose is to select & manage sub contractors.

Goals are :

• Prime Contractor selects Qualified Software Subcontractors

• Prime Contractor & the software subcontractor agree to their commitments to each
other.
• Prime contractor & the software subcontractor majintain ongoing communications.
• Prime Contractor tracks the software Subcontarctors actual results & performance
against its commitments.

Software Quality Assurance -

Purpose is to monitor the software processes used on the project Goals are –

• SQA are planned.

• Adherence of software products & activities to the applicable standards , procedures &
requirements is verified objectively.
• Affected groups & individuals are informed of software Quality Assurance activities &
results.

Software Configuration Management -

Purpose is to maintain the integrity of the system’s Configuration items throughout
the entire lifecycle of the product
Goals are :
• They are planned
• Selected software work products are identified, controlled and available.
• Changes to identified software work products are controlled.
• Affected groups and individuals are informed of the status & content of
software baselines.

LEVEL 3 THE DEFINED LEVEL –

Organization Process Focus –

Purpose is to establish the infrastructure for continuously improving the software process across the
organization.

Organization Process Definition –

 • Purpose is to develop & maintain the organization’s software processes.
• Information about the software process assets must be collected maintained and readily
available to the practitioners

Training Program –

• Purpose is to establish & maintain a planned organizational training program

• Through the program, the practitioners receive the skills & knowledge they require to perform
their software engineering roles.

Integrated Software Management –

• Purpose is to integrate the organization’s management software engineering processes into a

seamless set of coherent processes.

Software Product Engineering –

• Purpose is to produce correct & consistent software work products.

• This include development , maintenance, documentation & verification of
requirements , design , code , documentation & testing.

Inter Group Co ordination –

• Purpose is to provide a formal means for the software groups to activity participate
with other stakeholders departments,

Peer reviews –
Purpose is to plan & perform effective peer reviews to identify and remove defects as
early as possible in the products life cycle.

LEVEL 4 THE MANAGED LEVEL –

Quantitative Process Management –

Purpose is to control the software processes through Quantitative Metrices,

Software Quality Management –

It Involves defining Software Quality Goals for the products and processes defining plans to
achieve the goals and monitoring the programs.

LEVEL 5 OPTIMIZED LEVEL –

Defect prevention –
Purpose is to identify causes of defects , priorities the causes and plan the elimination
Technology Change Management -
Purpose is to systematically introduce new technologies.
This involves the identification of new technologies , evaluation to determine value & the controlled
introduction into the existing environment.

Process Change Management –

Purpose of process Change Management is the continuous improvement of the organization into
three groups-

a) Management Process
b) Organizational Processes
c) Software Engineering Processes