Manual Final

Experiment No 1
Write problem statement to define the project title with bounded scope of the project.
I Practical Significance
A properly defined and managed scope leads to delivering a quality product, in agreed cost and within
specified schedules to the stake-holders. Whilst there is a clear understanding of the need to achieve
project success, surprisingly little is published on significance of scope on project success. This study
discusses that scope should be properly defined and controlled and what can be the major factors behind
mismanagement of scope and how it can be overcome.
II Relevant Program Outcomes
All POs are listed.
III Relevant Course Outcomes
Identify the project needs, objectives and goals of the Project.
IV Practical Learning Outcomes
Define the project title with bounded scope of the project.
V Practical Skills
Learn how to write Scope of the project.
VI Relevant Affective domain related Outcomes
a) Identify the project needs

b) Project Scope description
c) Identify constraints
d) Identify necessary changes
VII Minimum Theoretical Background
Project scope is the part of project planning that involves determining and documenting a list of
specific project goals, deliverables, features, functions, tasks, deadlines, and ultimately costs. In other
words, it is what needs to be achieved and the work that must be done to deliver a project. It is important
to pin down the scope early in a project’s life cycle as it can greatly impact the schedule or cost (or both)
of the project down the track.
VIII Resources required
Sr No Instrument Specification Quantity Remarks

Any Desktop PC
1 Computer System with attached 10 No. Whichever is available
HardDisk
IX Procedure
1. Identify the project needs

2. Confirm the objectives and goals of the Project
3. Project Scope description
4. Expectations and acceptance
5. Identify constraints
6. Identify necessary changes
X Precautions
1. Change the requirement carefully.

2. Save changes if required under the guidance of teacher.
XI Description
A project scope is the first step in setting your project goals and objectives.
Project Scope Step 1:
1. Identify the project needs

When you are clearly able to identify the needs of a project, you are more likely to set a sound
benchmark from the beginning.
Understanding the ‘what and why’ of a project will enable you to set specific goals and objectives. It also
sets the groundwork for what tasks are to follow and how they are to be performed.
2. Confirm the objectives and goals of the Project

The basis of the project scope should entail your goals and objectives to be one that follows a SMART
guideline. That is, to be Specific, Measurable and Achievable. It should also be Realistic and completed
within a specific Timeframe.
Specific–This involves stating accurately what the project wants to achieve. That is, what, why and how
these will be done. Clarity will reduce the chances of ambiguities and misunderstandings.
Measurable –Are your goals and objectives able to provide feedback and be accountable for?
Achievable –Can your project’s goals and objectives be achieved, given the resources on hand?
Realistic –Are the goals and objectives easy to deliver, especially if you face problems or complications.
Will these reduce the overall quality of the project’s outcome and cause running over budget and not
meeting the set deadlines.
Time Frame –Can your project goals and objectives be met within the allocated time frame? Is it a key
criterion to meet these deadlines?
3. Project Scope description

You as a leader, need to be clear about the features and functioning required for your product or service.
For example, you are building a website. You need a list that provides how you will build your website,
the type of branding required and so on. In other words, what certain qualities will increase achieving
your project’s success.
4. Expectations and acceptance

Successful projects are ones that take into account the satisfaction of the end-user. Whether they meet
the end-users expectations and accept the product, service or process. The end-users could be your
customers or your internal team.
For customers, this includes pricing, value, and quality of products/services as well as availability, delivery
and return policies. For employees, this includes the effectiveness and efficiency of new operational
processes. Ultimately, your project scope is one that should be attuned to giving better outcomes to
whoever your end users may be.
5. Identify constraints
There are always roadblocks to achieving what you were set out to do. When being aware of possible
limitations along the way, it can help you minimize problems that may delay or constrain your ability to
achieve your project’s outcome.
These can be caused by dynamic environmental conditions (internal and external), technological glitches
and/or lack of resources. Communicating such problems with your team early on and taking steps to
overcome these hurdles will reduce delays in project completion and keep spending within budget.
Whether these are based on assumptions or uncertainty, analyzing their impact throughout the projects
timeline further reduces the risk of failure.
6. Identify necessary changes

It is always best to avoid reworking the scope of your project, as it means investing in more time, money
and resources.
However, at times these changes are inevitable and necessary. Limit changes by taking on the perspectives
of customers, stakeholders, and employees involved in the project. This minimizes disagreements later
on.
Experiment No 2
Select relevant process model to define activities and related tasks set for the assigned project.
A software process model is a simplified representation of a software process. Each model represents a
process from a specific perspective. Some methodologies are sometimes known as software development
life cycle (SDLC) methodologies, though this term could also be used more generally to refer to any
methodology.
All POs are listed.
Understand the Software Life Cycle.
Describes the sequence of phases for the entire lifetime of a product.
V Practical Skills
Learn Selection criteria for software Process Model.
a) Development of the product

b) Planning and organizing the project
c) Tracking and running the project
A software process model is a simplified representation of a software process. Each model

represents a process from a specific perspective. These generic models are abstractions of the process
that can be used to explain different approaches to the software development. A software process
model represents the order in which the activities of software development will be undertaken. It
describes the sequence in which the phases of the software lifecycle will be performed.
The software development models are the various processes or methodologies that are being
selected for the development of the project depending on the project’s aims and goals. There are many
development life cycle models that have been developed in order to achieve different required
objectives. The models specify the various stages of the process and the order in which they are carried
out. The selection of model has very high impact on the testing that is carried out. It will define the
what, where and when of our planned testing, influence regression testing and largely determines which
test techniques to use.

Any Desktop PC
HardDisk
IX Procedure
1. Learn the about Software Process Models.

2. Assess the needs of Stakeholders
3. Define activities and related tasks set for the project.
4. Define the selection criteria or arguments that use to select Software Process Models.
5. Decide which criteria fit for software Process Model.
X Precautions

XI Description
Choosing right model for developing of the software product or application is very important. Based
on the model the development and testing processes are carried out. Different companies based on the
software application or product, they select the type of development model whichever suits to their
application. But these days in market the ‘Agile Methodology‘ is the most used model.
Waterfall Model
It’s useful when the requirements are clear, or following a very structured process as in critical
systems which needs a detailed, precise, and accurate documents describes the system to be
produced.
Not good when requirements are ambiguous, and doesn’t support frequent interaction with the
customers for feedback and proposing changes. It’s not suitable for large projects that might take long
time to be developed and delivered.
Prototype Model
This is very useful when requirements aren’t clear, and the interactions with the customer and
experimenting an initial version of the software results in high satisfaction and a clearance of what
to be implemented.
It’s downsides are, good tools need to be acquired for quick development (like coding) in order
to complete a prototype. In addition, the costs for for training the development team on prototyping
may be high.
Incremental & Iterative Model
They’re suited for large projects, less expensive to the change of requirements as they support
customer interactions with each increment. Initial versions of the software are produced early, which
facilitates customer evaluation and feedback.
They don’t fit into small projects, or projects that waterfall are best suited for; A structured
process with a detailed, and accurate description of the system.
Spiral Model
It’s good for high risky or large projects where the requirements are ambiguous. The risks might
be due to cost, schedule, performance, user interfaces, etc.
Risk analysis requires highly specific expertise, and project’s success is highly dependent on the
risk analysis phase. It doesn’t work well for smaller projects.
Agile Model
It suits small-medium size project, with rapidly changes in the requirements as customer is
involved during each phase.
Very limited planning is required to get started with the project. It helps the company in saving time
and money (as result of customer physical interaction in each phase). The daily meetings make it
possible to measure productivity.
Difficult to scale up to large projects where documentation is essential. A highly skilled team is also
needed. If team members aren’t committed, the project will either never complete or fail. And there’s
always a limitation in time, like in increments, meetings, etc.
Experiment No 3
Prepare broad SRS (Software Requirements Software) for the above selected project.
A software requirements specification (SRS) is a document that captures complete description about how
the system is expected to perform. It is usually signed off at the end of requirements engineering phase.
A good SRS defines the how Software System will interact with all internal modules, hardware,
communication with other programs and human user interactions with wide range of real life scenarios.
All POs are listed.
Prepare software requirement specifications of project.
Detailed description of all aspects of the software to be built.
V Practical Skills
Learn software requirement specification document consistent of all necessary requirements required for
project development.
a) Consistent requirements
b) Verification of expected result
c) Testing environment
d) Security and Performance criteria
e) Deletion of irrelevant requirements
f) Freeze requirements
A software requirements specification (SRS) is a detailed description of a software system to be

developed with its functional and non-functional requirements. The SRS is developed based the
agreement between customer and contractors. It may include the use cases of how user is going to
interact with software system. The software requirement specification document consistent of all
necessary requirements required for project development. To develop the software system we should
have clear understanding of Software system. To achieve this we need to continuous communication
with customers to gather all requirements.
A good SRS defines the how Software System will interact with all internal modules, hardware,
communication with other programs and human user interactions with wide range of real li fe scenarios.
Using the Softwarerequirements specification (SRS) document on QA lead, managers creates test plan.
It is very important that testers must be cleared with every detail specified in this document in order to
avoid faults in test cases and its expected results.

Any Desktop PC
HardDisk
IX Procedure
1. If your organization does not have a standard Software Requirements Specifications document
template, create one now
2. Meet with the subject matter experts/clients to gather the requirements.
3. Define the functions of the software.
4. Create use cases for the major sub-processes. For example, if you're designing an order entry
system, use cases would consist of creating a new order, modifying an existing order and a
customer order search.
5. Define the user interface.
6. Define any other interfaces such as hardware interfaces or other software system interfaces.
7. Define the process flow.
8. Determine any specific business rules.
9. Define the performance specification.
10. Create any diagrams needed to illustrate the process flowor elaborate on key requirements.
11. Compile the SRS document and have all necessary parties review or sign i t.
X Precautions

XI Description
Software requirements specification (SRS) is a document that is created when a detailed

description of all aspects of the software to be built must be specified before the project is to
commence. It is important to note that a formal SRS is not always written. In fact, there are many instances in
which effort expended on an SRS might be better spent in other software engineering activities. However, when
software is to be developed by a third party, when a lack of specification would create severe business issues, or
when a system is extremely complex or business critical, an SRS may be justified. Karl Wiegers has developed a
worthwhile template that can serve as a guideline for those who must create a complete SRS. A topic outline
follows:
1. Introduction
1.1. Purpose
1.2. Document Conventions
1.3. Intended Audience and Reading Suggestions
1.4. Project Scope
1.5. References
2. Overall Description
2.1 Product Perspective
2.2 Product Features
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 Design and Implementation Constraints
2.6 User Documentation
2.7 Assumptions and Dependencies
3. System Features
3.1 System Feature 1
3.2 System Feature 2 (and so on)
4. External Interface Requirements
4.1 User Interfaces
4.2 Hardware Interfaces
4.3 Software Interfaces
4.4 Communications Interfaces
5. Other Nonfunctional Requirements
5.1. Performance Requirements
5.2. Safety Requirements
5.3. Security Requirements
5.4. Software Quality Attributes
6. Other Requirements
Appendix A: Glossary
Appendix B: Analysis Models
Appendix C: Issues List
Experiment No 4
Prepare the use-case and draw the use-case diagram using Software Modelling Tool.
A use case diagram is a dynamic or behavior diagram in UML. Use case diagrams model the
functionality of a system using actors and use cases. Use cases are a set of actions, services, and functions
that the system needs to perform.
All POs are listed.
Prepare use case diagram of project.
Detailed description of all aspects of the project to be built.
V Practical Skills
Learn use case diagrams: discovering actors and discovering use cases.
VI Minimum Theoretical Background
Use case diagrams are used to gather the requirements of a system including internal and external
influences. These requirements are mostly design requirements. Hence, when a system is analyzed to
gather its functionalities, use cases are prepared and actors are identified.
When the initial task is complete, use case diagrams are modelled to present the outside view.
In brief, the purposes of use case diagrams can be said to be as follows −
 Used to gather the requirements of a system.
 Used to get an outside view of a system.
 Identify the external and internal factors influencing the system.
 Show the interaction among the requirements are actors.

VII Resources required

Any Desktop PC
HardDisk
2 Any UML Software - 1 No. -
VIII Procedure
1. Select Diagram > New from the application toolbar.

2. In the New Diagram window, select Use Case Diagram.
3. Click Next.
4. Enter the diagram name and description. The Location field enables you to select a model to
store the diagram.
5. Click OK.
IX Precautions

X Description
Use case diagrams are used to gather a usage requirement of a system. Depending on your
requirement you can use that data in different ways. Beloware few ways to use them.
To identify functions and how roles interact with them – The primary purpose of use case diagrams.
For a high-level view of the system – Especially useful when presenting to managers or stakeholders.
You can highlight the roles that interact with the system and the functionality provided by the system
without going deep into inner workings of the system.
To identify internal and external factors – This might sound simple but in large complex projects a
system can be identified as an external role in another use case.
Notations used in use case diagram are:

1. 1. Use case:
Use case is the description of set of sequences of actions. It is graphically represented as an ellipse and
labeled with the name of the use case. Use case represents an action performed by a system.
Notation:
2. Actor:
An actor represents a coherent set of roles that users of use case can play while interacting with use
cases. An actor represents a role that a human, hardware device or another system plays when it
communicates with the system.
It is represented with the following notation.
Notation:
3. Association:
An association is a connection between an actor and use case. It indicates that both are communicating
with each other. Association is represented with a solid line.
Notation:
4. Generalization:
Generalization is used to show the relationship between two use cases. In this relationship the child use
case inherits the behavior and meaning of parent use case. It is represented with the solid line with a
large hollow triangle as an arrowhead. Arrow head indicates direction of generalization.
Notation:
5. Include Relationship:
An include relationship is the directed relationship between two use cases. Including a use case requires
forceful execution of included use case.
Notation/example:
6. Extend Relationship:
It is a directed relationship between two use cases that specifies extra actions in a system. Extend
relationship specifies optional behavior for extending use case.
Notation/example:
Experiment No 5
Develop the activity diagram to represent flow from one activity to another for software
development.
An activity diagram is a special kind of a state chart diagram that shows the flow from activity
to activity within the system. Activity diagram addresses the dynamic view of a system.
All POs are listed.
Prepare activity diagram of project.
V Practical Skills
Deeper understanding of UML activity diagrams.
Use case diagrams are used to gather the requirements of a system including internal and
external influences. These requirements are mostly design requirements. Hence, when a system is
analyzed to gather its functionalities, use cases are prepared and actors are identified.
When the initial task is complete, use case diagrams are modelled to present the outside view.
In brief, the purposes of use case diagrams can be said to be as follows −
 Used to gather the requirements of a system.
 Used to get an outside view of a system.
 Identify the external and internal factors influencing the system.
 Show the interaction among the requirements are actors.


Any Desktop PC
HardDisk
VIII Procedure

2. In the New Diagram window, select activity Diagram.
3. Click Next.
store the diagram.
5. Click OK.
IX Precautions

X Description
Activity diagrams illustrate the dynamic nature of a system by modeling the flow of control from
activity to activity. An activity represents an operation on some class in the system that results in a
change in the state of the system. Typically, activity diagrams are used to model workflow or business
processes and internal operation.
Action states cannot be decomposed. Action states are atomic, meaning that events may occur,
but the work of an action state is not interrupted. The work of an action state as a special case of an
activity case of an activity state that cannot be further decomposed.
Notations used in activity diagram:
Fig: Activity diagram for Library Management System
Experiment No 6
Develop data designs using DFDs (data flow diagram), Decision tables and E-R (entity –
relationship) diagram.
Data flow diagram is graphical representation of flow of data in an information system. It is capable of
depicting incoming data flow, outgoing data flow and stored data. The DFD does not mention anything
about how data flows through the system.
There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of
control in program modules. DFDs depict flow of data in the system at various levels. DFD does not contain
any control or branch elements.
All POs are listed.
Prepare Data flow diagram, Decision tables and E-R (entity –relationship) of project.
V Practical Skills
Deeper understanding of System modeling:
 Data model: entity-relationship diagram (ERD).

 Functional model: data flow diagram (DFD).
 Decision Table.
A data flow diagram shows the way information flows through a process or system. It includes
data inputs and outputs, data stores, and the various sub processes the data moves through. DFDs are
built using standardized symbols and notation to describe various entities and their relationships.
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. A decision table is basically an outstanding technique used in both testing and
requirements management.
An Entity Relationship (ER) Diagram is a type of flowchart that illustrates how “entities” such as
people, objects or concepts relate to each other within a system.

Any Desktop PC
HardDisk
VIII Procedure

2. In the New Diagram window, select Data Flow Diagram.
3. Click Next.
store the diagram.
5. Click OK.
IX Precautions

X Description
Data Flow Diagrams are either Logical or Physical.
 Logical DFD - This type of DFD concentrates on the system process, and flow of data in the
system.For example in a Banking software system, how data is moved between different
entities.
 Physical DFD - This type of DFD shows how the data flow is actually implemented in the system.
It is more specific and close to the implementation.
DFD Components
DFD can represent Source, destination, storage and flow of data using the following set of components
-
 Entities - Entities are source and destination of information data. Entities are represented by a
rectangles with their respective names.
 Process - Activities and action taken on the data are represented by Circle or Round-edged
rectangles.
 Data Storage - There are two variants of data storage - it can either be represented as a
rectangle with absence of both smaller sides or as an open-sided rectangle with onlyone side
missing.
 Data Flow - Movement of data is shown by pointed arrows. Data movement is shown from the
base of arrow as its source towards head of the arrow as destination.
Levels of DFD
 Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts the entire
information system as one diagram concealing all the underlying details. Level 0 DFDs are also
known as context level DFDs.
 Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD. Level 1 DFD depicts
basic modules in the system and flow of data among various modules. Level 1 DFD also
mentions basic processes and sources of information.
 Level 2 - At this level, DFD shows how data flows inside the modules mentioned in Level 1.
Higher level DFDs can be transformed into more specific lower level DFDs with deeper level of
understanding unless the desired level of specification is achieved.
Decision Tables
A Decision table represents conditions and the respective actions to be taken to address them, in a
structured tabular format.
It is a powerful tool to debug and prevent errors. It helps group similar information into a single table
and then by combining tables it delivers easy and convenient decision-making.
Creating Decision Table

To create the decision table, the developer must follow basic four steps:
 Identify all possible conditions to be addressed

 Determine actions for all identified conditions
 Create Maximum possible rules
 Define action for each rule
Decision Tables should be verified by end-users and can lately be simplified by eliminating duplicate rules
and actions.
 Example 1: How to make Decision Table for Login Screen

 Let's create a decision table for a login screen.
 The condition is simple if the user provides correct username and password the user will be
redirected to the homepage. If any of the input is wrong, an error message will be displayed.
 Conditions  Rule 1  Rule 2  Rule 3  Rule 4
 Username (T/F)  F  T  F  T
 Password (T/F)  F  F  T  T
 Output (E/H)  E  E  E  H
 Legend:
 T – Correct username/password
 F – Wrong username/password
 E – Error message is displayed
 H – Home screen is displayed
Interpretation:
Case 1 – Username and password both were wrong. The user is shown an error message.
Case 2 – Username was correct, but the password was wrong. The user is shown an error message.
Case 3 – Username was wrong, but the password was correct. The user is shown an error message.
Case 4 – Username and password both were correct, and the user navigated to homepage
While converting this to test case, can create 2 scenarios ,
Enter correct username and correct password and click on login, and the expected result will be the user
should be navigated to homepage
And one from the below scenario

 Enter wrong username and wrong password and click on login, and the expected result will be
the user should get an error message
 Enter correct username and wrong password and click on login, and the expected result will be
 Enter wrong username and correct password and click on login, and the expected result will be
Entity-Relationship Model
Entity-Relationship model is a type of database model based on the notion of real world entities and
relationship among them. We can map real world scenario onto ER database model. ER Model creates
a set of entities with their attributes, a set of constraints and relation among them.
ER Model is best used for the conceptual design of database. ER Model can be represented as follows :
 Entity - An entity in ER Model is a real world being, which has some properties called attributes.
Every attribute is defined by its corresponding set of values, called domain.
For example, Consider a school database. Here, a student is an entity. Student has various
attributes like name, id, age and class etc.
 Relationship - The logical association among entities is called relationship. Relationships are
mapped with entities in various ways. Mapping cardinalities define the number of associations
between two entities.
Mapping cardinalities:
o one to one
o one to many
o many to one
o many to many
Experiment No 7
Draw class diagram, Sequence diagram, Collaboration diagram, State Transition diagram
for the assigned project.
Class diagram describes the attributes and operations of a class and also the constraints imposed on the
system. Sequence diagrams describe how and in what order the objects in a system function.
Collaboration diagrams are used to describe the structural organization of the objects taking part in the
interaction. In state transition diagram we represent that what actions are leads to change the state of
the object.
All POs are listed.
Prepare class diagram, Sequence diagram, Collaboration diagram, State Transition diagram of
project.
V Practical Skills
Deeper understanding of System modeling: class diagram, Sequence diagram, Collaboration diagram,
State Transition diagram.
Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic aspect can be
further described as the changing/moving parts of a system.
UML has the following five types of behavioral diagrams −
Use case diagram
Sequence diagram
Collaboration diagram
State chart diagram
Activity diagram

Any Desktop PC
HardDisk
VIII Procedure

2. In the New Diagram window, select the Diagram.
3. Click Next.
store the diagram.
5. Click OK.
IX Precautions

X Description
Class diagrams describe the static structure of a system or how it is structured rather than how it
behaves.
These diagrams contain the following element with their symbol.
1) Class– It represents entity with common characteristics or features. These features can include
attributes, operations and associations.
The symbol used to denote class is rectangle with three compartments.
First contains the name of the class, second contains the attributes of the class and third contains the
operations of that class.
Notation:
2) Association – It represents relationships that relate to two or more other classes where the
relationships have common characteristics.
The symbol used to denote association is solid line.
Notation:
3) Multiplicity -Multiplicity in an association specifies how many objects participate in a relationship.

Multiplicity decides the number of related objects. Multiplicity is generally explained as “one” or
“many,” but in general it is a subset of the non-negative integers.
Indicator and Meaning
0..1 Zero or one
1 One only
0..* Zero or more
1..* One or more
n Only n (where n > 1)
0..n Zero to n (where n > 1)
1..n One to n where n > 1)
Notation:
4) Association Class: An association class is an attribute of an association. It is also
a class.
Notation:
5) Generalization: It is a relationship between a class (superclass) and its derived classes (subclasses).
Notation:
6) Qualified association: It uses the special attribute qualifier which reduces the effective multiplicity of
an association.
Notation:
Fig: Class Diagram for Hotel Management System
Notations used to draw sequence diagram.
1) Object: Class roles describe the way an object will behave in context. Use the UML object
symbol to illustrate class roles, but don't list object attributes.
2) Activation or Execution Occurrence: Activation boxes represent the time an object needs to
complete a task. When an object is busy executing a process or waiting for a reply message, use
a thin gray rectangle placed vertically on its lifeline.
3) Messages: Messages are arrows that represent communication between objects. Use half-
arrowed lines to represent asynchronous messages. Asynchronous messages are sent f rom an
object that will not wait for a response from the receiver before continuing its tasks.
4) Lifelines: Lifelines are vertical dashed lines that indicate the object's presence over time.
5) Destroying Objects: Objects can be terminated early using an arrow labeled "<< destroy >>"
that points to an X. This object is removed from memory. When that object's lifeline ends, you
can place an X at the end of its lifeline to denote a destruction occurrence.
6) Loops: A repetition or loop within a sequence diagram is depicted as a rectangle. Place the
condition for exiting the loop at the bottom left corner in square brackets [ ].
Fig: sequence diagram for hotel management system
A collaboration Diagram is an interaction diagram which emphasizes the structural organization of the
objects that send and receive messages.
Collaboration Diagram Notations:

Objects are model elements that represent instances of a class or of classes.
Multi-object represents a set of lifeline instances.
Association role is optional and suppressible.
Delegation is like inheritance done manually through object composition.

Link to self is used to link the bjects that fulfill more than one role.
Constraint is an extension mechanism that enables you to refine the semantics of a UML model
element.
Fig : Collaboration diagram for Online Hospital Management

State Transition diagram
Statechart diagrams are used to model the states and also the events operating on the
system. When implementing a system, it is very important to clarify different states of an object
during its life time and Statechart diagrams are used for this purpose. When these states and
events are identified, they are used to model it and these models are used during the
implementation of the system.
Notations :
State defines current condition of an event or activity. State diagram is often used to describe
state changes triggered by events.
Start state symbol signals the first step of a process.
End state symbol stands for the result of a process.
Transition takes operation from one state to another and represents the response to a
particular event. A single transition comes out of each state or activity, connecting it to the next
state or activity.
Decision were introduced in UML to support conditionals in activities.
History refers to the development of object-oriented methods and notation.
Constraint is an extension mechanism that enables you to refine the semantics of a UML model
element.
Note contains comments or textual information.

Fig: State Diagram for online reservation system
Experiment No 8
Write test cases to validate requirements of assigned project from SRS document.
A test case is a specification of the inputs, execution conditions, testing procedure, and expected
results that define a single test to be executed to achieve a particular software testing objective, such as
to exercise a particular program path or to verify compliance with a specific requirement.
All POs are listed.
Study SRS document and designing test cases.
Detailed description of all aspects of the project to be built with test case design.
V Practical Skills
Deeper understanding of System Requirement Specification of a software system, test cases formulation
strategy.
A Test Case is defined as a set of actions executed to verify a particular feature or functionality of
the software application. A test case is an indispensable component of the Software Testing LifeCycle that
helps validate the AUT (Application Under Test).
Test scenarios are rather vague and cover a wide range of possibilities. Testing is all about being
very specific.

Any Desktop PC
HardDisk
VIII Procedure
1. Detailed study of the System under test

2. Written in simple language
3. Use Test case template
IX Precautions

X Description
Test case template

It looks like:
i) Test Case ID: This field is defined by what type of system we are testing. Standard rules are as follows:
 If we are making test case for a general application which doesn’t belong to any specific module then
ID would start as TC001.
 If we are making test cases for a module specific system then ID would start from MC001.
 If test case has more than one expected result then we make it as version number wise. E.g. TC001.1,
TC001.2 etc. All these test cases are sub part of TC001.
ii) Test Case Name: This filed can contain

 Name of the feature you are testing
 Requirement number from the specifications
 Name of a particular Button or input box
 Requirement name as classified in client’s document
The main advantage of maintaining this field is, if a requirement gets changed in future then we can
easily estimate how many test cases that change will affect and we change/remove the corresponding
test cases accordingly.
iii) Description: This field has the summary what respective test case is going to do. It explains what
attribute is under test and under what condition. E.g. If a text box is under provigil onlinetest, which
allows only number and alphabets then description can be written as “Random special characters (@, #,
%,$,^,*) are entered”, if we want to test a negative scenario.
iv) Pre-Conditions: when the system needs to be in a particular base state for the function to be tested,
these pre conditions should be defined clearly.
Pre-conditions could be:
 A certain page that a user needs to be on
 A certain data that should be in the system
 A certain action to be performed before “execution steps” can be executed on that particular
system.
Pre-conditions should be satisfied before the test case execution starts.
v) Execution steps: These are the steps to be performed on the system under test to get the desired
results. Steps must be defined clearly and must be accurate. They are written and executed number
wise.
vi) Expected Results: These are the desired outcomes from the execution steps performed. Expected
results should be clearly defined for each step. It specifies what the specification or client expects from
that particular action.
vii) Actual result: This field has the actual outcomes after the execution steps were performed on the
system under test. If the results match with the expected ones then we can just write “As expected”,
otherwise we need to mentioned the exact result observed.
viii) Status: This field can have following values based on the actual result we got, they are:
 “Passed” – The expected and actual results match

 “Failed”- The actual result and expected result do not match
 “Not tested”- The test case has not been executed
 “Not Applicable”-The test case does not apply to the feature any more since the requirement
changed or modified
 “Cannot be tested” – This may be because precondition is not met. There could be a defect in one of
the steps leading up to the function under test.
ix) Comments: This column is for additional information. So for e.g. if status is set to “cannot be tested”
then tester can give the reason in this column.
Fig: sample test case to login form of Twitter social site.

Experiment No 9
Evaluate size of the project using Function point metric for the assigned project.
Function points are one of the most widely used measures of software size. The basis of
function points is that the "functionality” of the system that is; what the system performs, is the
measure of the system size. In function points, the system functionally is calculated in terms of the
number of function it implements, the number of inputs, the number of output etc.
All POs are listed.
Calculate the size of the project using Function point metric for the assigned project.
Detailed descriptions of all aspects of the project to be understand.
V Practical Skills
Deeper understanding of various measures is used in project size estimation.
The initial design criteria for function points were to provide a mechanism that both software
developers and users could utilize to define functional requirements. It was determined that the best way
to gain an understanding of the users' needs was to approach their problem from the perspective of how
they view the results an automated system produces. Therefore, one of the primary goals of Function
Point Analysis is to evaluate a system's capabilities from a user's point of view. To achieve this goal, the
analysis is based upon the various ways users interact with computerized systems. From a user's
perspective a system assists them in doing their job by providing five basic functions.
Two of these address the data requirements of an end user and are referred to as Data Functions. The
remaining three addresses the user's need to access data and are referred to as Transactional Functions.
The Five Components of Function Points
Data Functions
 Internal Logical Files

 External Interface Files
Transactional Functions
 External Inputs
 External Outputs
 External Inquiries
Internal Logical Files - The first data function allows users to utilize data they are responsible for
maintaining. For example, a pilot may enter navigational data through a display in the cockpit prior to
departure. The data is stored in a file for use and can be modified during the mission. Therefore the pilot
is responsible for maintaining the file that contains the navigational information. Logical groupings of data
in a system, maintained by an end user, are referred to as Internal Logical Files (ILF).
External Interface Files - The second Data Function a system provides an end user is also related to
logical groupings of data. In this case the user is not responsible for maintaining the data. The data resides
in another system and is maintained by another user or system. The user of the system being counted
requires this data for reference purposes only. For example, it may be necessary for a pilot to reference
position data from a satellite or ground-based facility during flight. The pilot does not have the
responsibility for updating data at these sites but must reference it during the flight. Groupings of data
from another system that are used only for reference purposes are defined as External Interface Files
(EIF).
The remaining functions address the user's capability to access the data contained in ILFs and EIFs. This
capability includes maintaining, inquiring and outputting of data. These are referred to as Transactional
Functions.
External Input - The first Transactional Function allows a user to maintain Internal Logical Files (ILFs)
through the ability to add, change and delete the data. For example, a pilot can add, change and delete
navigational information prior to and during the mission.
In this case the pilot is utilizing a transaction referred to as an External Input (EI). An External Input gives
the user the capability to maintain the data in ILF's through adding, changing and deleting its contents.
External Output - The next Transactional Function gives the user the ability to produce outputs. For
example a pilot has the ability to separately display ground speed, true air speed and calibrated air speed.
The results displayed are derived using data that is maintained and data that is referenced. In function
point terminology the resulting display is called an External Output (EO).
External Inquiries - The final capability provided to users through a computerized system addresses the
requirement to select and display specific data from files. To accomplish this a user inputs selection
information that is used to retrieve data that meets the specific criteria. In this situation there is no
manipulation of the data. It is a direct retrieval of information contained on the files. For example if a pilot
displays terrain clearance data that was previously set, the resulting output is the direct retrieval ofstored
information. These transactions are referred to as External Inquiries (EQ).
FPs of an application is found out by counting the number and types of functions used in the
applications. Various functions used in an application can be put under five types as shown in Table.
Types of FP Attributes

Any Desktop PC
HardDisk
http://groups.umd.umich.edu/cis/course.des/cis375/projects/fp99/main.html use for Function

Point Calculator.
VIII Procedure
In Function Point Analysis method, the number and type of functions supported by the software
are utilized to find FPC(function point count). The steps in function point analysis are:
1. Count the number of functions of each proposed type.

2. Compute the Unadjusted Function Points(UFP).
3. Find Total Degree of Influence(TDI).
4. Compute Value Adjustment Factor(VAF).
5. Find the Function Point Count(FPC).
IX Precautions

X Description
The functional complexities are multiplied with the corresponding weights against each function and the
values are added up to determine the UFP (Unadjusted Function Point) of the subsystem.
Fig: Computing FPs
The weighing factor will be simple, average or complex for a measurement parameter type.
The Function Point (FP) is thus calculated with the following formula
FP = Count-total * [0.65 + 0.01 * S(Fi ) ]
where Count-total is obtained from the above Table.
and
S(Fi ) is the sum of all 14 questionnaires and show the complexity adjustment value/ factor-CAF (where i
ranges from 1 to 14). Usually, a student is provided with the value of S (Fi ).
Also note that S (Fi ) ranges from 0 to 70,
i.e., 0 <= S (Fi) <=70.
Based on the FP measure of software many other metrics can be computed:
(a) Cost per function = cost/ productivity
(b) Cost=$/FP.
(c) Quality=Number of Faults/FP
(d) Documentation=Pages of documentation/FP
(e) Productivity = FP/PM (effort is measured in person-months).

Experiment No 10
Estimate cost of the project using COCOMO (Constructive Cost Model) / COCOMO II approach for the
assigned project.
COCOMO (Constructive Cost Model) is a regression model based on LOC, i.e number of Lines
of Code. It is a procedural cost estimate model for software projects and often used as a process of
reliably predicting the various parameters associated with making a project such as size, effort, cost,
time and quality. It was proposed by Barry Boehm in 1970 and is based on the study of 63 projects,
which make it one of the best-documented models.
According to Boehm, software cost estimation should be done through three stages: Basic
COCOMO, Intermediate COCOMO, and Complete COCOMO. Each of the models initially estimates
efforts based on the total estimated KLOC.
All POs are listed.
Calculate the size of the project using COCOMO approach for the assigned project.
Detailed descriptions of all aspects of the project to be understand.
V Practical Skills
Deeper understanding of various measures is used in project size estimation.
There are also different "flavors" of COCOMO in use for business estimates. For example, in a model
known as "detailed COCOMO," a step-by-step process includes attention to planning and requirements,
system design, detail design, module code and testing, integration and testing, and estimation. Ingeneral,
COCOMO provides a helpful framework to try to determine the cost and scope of a software project.
The key parameters which define the quality of any software products, which are also an
outcome of the Cocomo are primarily Effort & Schedule:
Effort: Amount of labor that will be required to complete a task. It is measured in person-months units.
Schedule: Simply means the amount of time required for the completion of the job, which is, of course,
proportional to the effort put. It is measured in the units of time such as weeks, months.
COCOMO (Constructive Cost Model) was proposed by Boehm. According to him, there could be three
categories of software projects: organic, semidetached, and embedded. The classification is done
considering the characteristics of the software, the development team and environment. These product
classes typically correspond to application, utility and system programs, respectively. Data processing
programs could be considered as application programs. Compilers, linkers, are examples of utility
programs. Operating systems, real-time system programs are examples of system programs. One could
easily apprehend that it would take much more time and effort to develop an OS than an attendance
management system.
The concept of organic, semidetached, and embedded systems are described below.
Organic: A development project is said to be of organic type, if The project deals with developing a well
understood application The development team is small. The team members have prior experience in
working with similar types of projects.
Semidetached: A development project can be categorized as semidetached type, if The team consists of
some experienced as well as inexperienced staff Team members may have some experience on the type
of system to be developed.
Embedded: Embedded type of development project are those, which Aims to develop a softwarestrongly
related to machine hardware Team size is usually large.
Boehm suggested that estimation of project parameters should be done through three stages: Basic
COCOMO, Intermediate COCOMO, and Complete COCOMO.
Any Desktop PC
HardDisk
http://csse.usc.edu/tools/cocomoii.php or
http://csse.usc.edu/csse/research/COCOMOII/cocomo2000.0/CII2000.exe use for COCOMO II -
Constructive Cost Model.
VIII Procedure
a. Read the exercise enclosed scenario. This scenario describes the software product you are
estimating, your work setting and much of the pertinent information required for establishing
the model parameters.
b. You should initially set the parameters based solely on the information provided in the
scenario. In cases where the scenario description provides no direct information regarding a
particular factor, you should assume that the nominal setting is appropriate. However, after
you have completed the exercise described below, you are encouraged to adjust other factors
based on your experience or curiosity. You will then be in a position to observe their impact
on effort and schedule.
IX Precautions

X Description
Estimation of Effort: Calculations –
Basic Model –
E = a * (KLOC)b
D= c*(E)d
P=E/D
Where,
E- Effort applied in person-months

D – Development time in duration-in-month
P- Total number of persons required to accomplish the project
KLOC ... kilo lines of code
a, b, c, d depend on the project type
The above formula is used for the cost estimation of for the basic COCOMO model, and also is used in the
subsequent models. The constant values a and b for the Basic Model for the different categories of system:
Intermediate Model –
The effort calculation:
E = a * (KLOC)b * EAF (person-months)
D= c*(E)d
P=E/D
Where,
E- Effort applied in person-months
D – Development time in duration-in-month (use c and d coefficient from basic model)
P- Total number of persons required to accomplish the project
KLOC ... kilo lines of code
a, b, c, d depend on the project type
Detailed Model –
Detailed COCOMO incorporates all characteristics of the intermediate version with an assessment of the
cost driver’s impact on each step of the software engineering process.
The Four phases of detailed COCOMO are:

1. Requirements Planning and Product Design
2. Detailed design
3. Code and unit test
4. Integration and test
Effort(E) = ab * (KLOC)bb(in Person-months)
DevelopmentTime(D) = cb * (E) db(in month)
Average staff size(SS) = E/D (in Person)
Productivity(P) = KLOC / E (in KLOC/Person-month)

Experiment No 11
Use CPM (critical path method)/PERT (Programme evaluation and review technique) for
scheduling the assigned project.
PERT (Program Evaluation and Review Technique) and CPM (Critical Path Method) are two closely - related
operations research techniques that use networks to coordinate activities, develop schedules, and
monitor progress of projects. PERT and CPM were developed independently in the 1950s. While the
original versions differed in some important ways, the two techniques had much in common. Over
time, the techniques have merged and, for the most part, the names are used interchangeably or
combined in a single acronym, PERT/CPM.
All POs are listed.
Develop Time-line chart and project table using PERT or CPM project scheduling methods.
V Practical Skills
Deeper understanding of PERT or CPM project scheduling methods.
The program evaluation review technique (PERT) and critical path method (CPM) are tools useful
in planning, scheduling, and managing complex projects. PERT/CPM (sometimes referred to as network
analysis) provides a focus around which managers and project planners can brainstorm. It is useful for
evaluating the performance of individuals and teams. The key concept in CPM/PERT is that a small set of
activities, which make up the longest path through the activity network, control the entire project.Ifthese
critical activities can be identified and assigned to the responsible persons, management resources can be
optimally used by concentrating on the few activities that determine the fate of the entire project.
Noncritical activities can be replanned or rescheduled, and resources for them can be reallocatedflexibly,
without affecting the whole project.
There are many variations of CPM/PERT which have been useful in planning costs and scheduling
manpower and machine time. CPM/PERT can answer the following important questions:
1) How long will the entire project take? What are the risks involved?
2) Which are the critical activities or tasks in the project which could delay everything if they are
not completed on time?
3) Is the project on schedule, behind schedule, or ahead of schedule?
4) If the project must be finished earlier than planned, what is the best way to do this at the least
cost?
Any Desktop PC
HardDisk
VIII Procedure
Six steps of PERT and CPM:
1. Define the project and prepare WBS
2. Develop relationships
3. Draw the network connecting all activities
4. Assign time and cost estimated
5. Compute the longest time path through the network = critical path
6. Use network to help plan, schedule, monitor, and control the project
IX Precautions

X Description
PERT-CPM Method
• Task interdependency represents the dependency relationship or the

sequence of tasks between a pair of activities.
• An activity network diagram (AND) that shows the task interdependency in the project.
• The activity network diagram is designed using
– Project Evaluation and Review Technique (PERT)
– Critical Path Method (CPM).
• PERT is a network-based representation of tasks or activities to

determine the task interdependency.
• It represents the precedence or parallel relationships among the tasks in a project.
• A PERT diagram has the following construction rules:
• Each task or activity is represented as a node in boxes.
• Arrow shows the dependencies between tasks or activities.
• There is a start node, which has only an outgoing arrow, and an end
node, which has only incoming arrows.
• An arrow pointing to a node comes from its predecessor activity,

which must be completed before a task can begin.
• Arrows pointing out of a task box go to its successor tasks, which

cannot start until at least this task is complete.
• For example, T1 is the predecessor of T2 in the following diagram. T2

cannot start until T1 is completed.
• Based upon the details of WBS and the sequence of activities, an activity
network diagram is drawn which shows the sequence of serial and parallel
activities in the project.
• There is no cycle in the activity network diagram.
• The expected completion time in days is shown inside the nodes, along with
the activities.
• The duration of the project is equal to the longest path from the start to the
finish node of the network.
• A path in the network diagram is one of the routes following the arcs from the
start to the finish node.
• The length of a path is the sum of the expected estimated durations of the
activities on the path.
• The duration of the project must be at least the length of the longest path.
• Thus, the estimated project duration equals the length of the longest path
through the project network.
• This longest path is called the critical path.
• For larger projects, it may be helpful to determine the following values for each activity:
• Earliest Start time (TES): It is the earliest time an activity may begin after
allowing the preceding activities to finish. Earliest start time (TES) = max
(TEF of immediate predecessors).
• Earliest Finish time (TEF): It is the earliest time an activity may finishafter
allowing the preceding activities to finish. Earliest finish time (TEF) = TES
+ Activity duration.
• TES and TEF are calculated in the forward pass through the network diagram.
• Sometimes activities take longer than the expected time duration that
may delay project completion.
• So, to determine how much late an activity can start or finish

without delaying project completion as:
• Latest Start time (TLS): It is the latest time an activity may begin
without delaying project completion. Latest start time (TLS) = TLF -
Activity duration.
• Latest Finish time (TLF): It is the latest time an activity may finish
without delaying project completion. Latest finish time = TLF = min (TLS
of immediate successors).
• Slack time (TS): The slack time for an activity is the difference
between its latest finish time and its earliest finish time. Slack time
(TS) = TLF – TEF = TLS – TES.
• The backward pass through the network diagram is made starting with
the final activities and moving backward in time toward the initial
activities to calculate TLS and TLF.
• There are some activities having no slack and other activities have slack time. The
critical path then is the path through the network in which none of the activities
have slack.
• Each activity with zero slack is on the critical path through the project network
such that any delay along this path will delay project completion.
• The critical path is shown in Figure with dark arrows in the network diagram.
• The critical path is:
Start node > Architectural design > Database design > Output design > Finish
node
• Advantage:
• PERT is useful to determine the expected project completion time, the

probability of completion before a specified date, and the start and end
dates.
• It helps to find the critical path activities that directly influence the completion
time.
• Limitation:
• The time estimates for activities are somewhat subjective and depend on
judgment.
• If there is little experience in performing an activity, the time is fixed

only by an educated guess.
Experiment No 12
Use Timeline charts/Gantt charts to track progress of the assigned project.
Gantt charts are widely used in business to describe and monitor all kinds of projects according to the
rules of project management. Different Gantt applications have different features and capabilities.
All POs are listed.
Prepare Gantt charts for tracking the utilization of the resources in the project.
V Practical Skills
Learn Gantt charts to track the progress of the entire project which is required for project development.
a) Follow precautionary measures.

b) Demonstrate working as a team member.
c) Follow ethical practices.
A Gantt chart is a bar graph of a project’s tasks. A typical Gantt chart has the name of individual tasks or
group of tasks in the project on the Y-axis. The X-axis has a timeline divided into days or weeks. Colorbars
indicate when a task is expected to start. Different colors indicate how much of an activity has been
completed and how much remains unfinished.
The ability to grasp the overall status of a project and its tasks at once is the key advantage in using a
Gantt chart tool. Therefore, upper management or the sponsors of the project can make informed
decisions just by looking at the Gantt chart tool.
The software-based Gantt charts are able to show the task dependencies in a project schedule. Thishelps
to identify and maintain the critical path of a project schedule. Gantt chart tools can be used as the single
entity for managing small projects. For small projects, no other documentation may be required; but for
large projects, the Gantt chart tool should be supported by other means of documentation.
For large projects, the information displayed in Gantt charts may not be sufficient for decision making.
Fig: A simple Gantt chart with multiple activities and their respective dependencies
Any Desktop PC
HardDisk
Gantt Chart
2 1 No.
Template
IX Procedure
1. Develop a Work Breakdown Structure
2. Assign Tasks
3. Evaluate Task Dependencies
4. Share & Evaluate the Plan with Your Team
X Precautions

XI Description
A Gantt chart can be very useful in planning and carrying out a project. There are a number of ways to
create a Gantt chart: from pen and paper or whiteboard to very complex software programs.
Step 1: Develop a Work Breakdown Structure

What is a Work Breakdown Structure (WBS)? It is a process by which a project is planned by breaking it
into easily definable and understandable goals, milestones and tasks. Listing the major componentsfirst is
the first step in developing a WBS. This can be done by in a word processor, spreadsheet, or using a Gantt
chart program.
A key element in the WBS is to plan for intended outcomes, rather than planning actions. That is,
understand what the goals of the project are, define key milestones, and then start the processofbreaking
those pieces down into tasks. If there are fixed dates that need to be met, make sure those are shown in
the Gantt chart. This way, as the topics are broken into tasks, it will become clear upfront whether more
resources will need to be added to meet these deadlines.
After the major topics are determined, the process of breaking these into tasks is next. Dependingonthe
complexity of each task, the project planner may find it necessary to continue breaking these items into
sub-tasks until they are very specific.
For many project planners, a visual model of the WBS is easier to work with than the "laundry list"dictated
by the Gantt chart format. A mind map is ideal for this because it lets you easily see the work breakdown.
A good Gantt chart software program, such as SmartDraw, will allow you to work in Gantt chart or mind
map view, with relational data that automatically updates both views when changes are made in either
one.
It is estimated that more than 90% of projects are late. The primary reason for this is that they weren't
properly planned with a well-thought-out work breakdown structure. The more detailed the breakdown,
the easier it is to plan, organize and schedule a project accurately.
Step 2: Assign Tasks
One of the most critical pieces in how to build a Gantt chart is the distribution of work. There are several
things to consider.
 Who is most qualified to complete this task?

 What is their availability vis-à-vis their currently scheduled workload?
 What is a reasonable expectation of their time needed to complete the task(s)?
 Will additional people or resources be necessary to get these tasks completed on time?
Step 3: Evaluate Task Dependencies

One of the benefits of creating a Gantt chart for project planning is that it makes it easier to see
dependencies. This is a situation where one task is dependent upon the completion or outcome of
another. For example, a webmaster can't build a web page unless the copywriter and illustrator have
finished their tasks. Identifying these dependent relationships is critical, as delays in theprimarystepswill
almost certainly ripple throughout the entire project. Automated software will allow you to add
dependencies as you create your Gantt chart. If you're doing this by hand or using a less sophisticated
program, you'll need to remember to do this crucial step manually.
Step 4: Share & Evaluate the Plan with Your Team
When the Gantt chart is complete, distribute it to team members for review and
feedback. It's importantthat each member of the project buys off on the plan upfront.
This helps to ensure that the planisaccurate and reasonable. It's much easier to allow
for contingencies, plan additional resources, or even proposea revised schedule at this
stage, rather than at a critical juncture later.

Manual Final

Uploaded by

Document Information

Original Title

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

Manual Final

Uploaded by

Copyright:

Available Formats

Experiment No 1

II Relevant Program Outcomes

All POs are listed.

III Relevant Course Outcomes

Identify the project needs, objectives and goals of the Project.

IV Practical Learning Outcomes

Define the project title with bounded scope of the project.

Learn how to write Scope of the project.

VI Relevant Affective domain related Outcomes

a) Identify the project needs

VII Minimum Theoretical Background

Sr No Instrument Specification Quantity Remarks

1. Identify the project needs

1. Change the requirement carefully.

Project Scope Step 1:

1. Identify the project needs

Project Scope Step 2:

2. Confirm the objectives and goals of the Project

Project Scope Step 3:

3. Project Scope description

4. Expectations and acceptance

Project Scope Step 6:

6. Identify necessary changes

II Relevant Program Outcomes

All POs are listed.

III Relevant Course Outcomes

Understand the Software Life Cycle.

IV Practical Learning Outcomes

Describes the sequence of phases for the entire lifetime of a product.

Learn Selection criteria for software Process Model.

VI Relevant Affective domain related Outcomes

a) Development of the product

VII Minimum Theoretical Background

A software process model is a simplified representation of a software process. Each model

VIII Resources required

Sr No Instrument Specification Quantity Remarks

1. Learn the about Software Process Models.

1. Change the requirement carefully.

Incremental & Iterative Model

II Relevant Program Outcomes

All POs are listed.

III Relevant Course Outcomes

Prepare software requirement specifications of project.

IV Practical Learning Outcomes

Detailed description of all aspects of the software to be built.

VI Relevant Affective domain related Outcomes

VII Minimum Theoretical Background

A software requirements specification (SRS) is a detailed description of a software system to be

VIII Resources required

Sr No Instrument Specification Quantity Remarks

1. Change the requirement carefully.

Software requirements specification (SRS) is a document that is created when a detailed

II Relevant Program Outcomes

All POs are listed.

III Relevant Course Outcomes

Prepare use case diagram of project.

IV Practical Learning Outcomes

Detailed description of all aspects of the project to be built.

VI Minimum Theoretical Background

In brief, the purposes of use case diagrams can be said to be as follows −

 Used to gather the requirements of a system.

 Used to get an outside view of a system.

 Identify the external and internal factors influencing the system.