LAB MANUAL

of
Software Engineering Laboratory
(CS331)

Bachelor of Technology (CSE)

By
Student Name (Enrollment ID)
Third Year, Semester 5

Department of Computer Science and Engineering

School Engineering and Technology
Navrachana University, Vadodara
Autumn Semester
(2022-2023)
Enrollment ID Software Engineering Laboratory (CS331) Student Name

List of Experiments
Sr. Name of Experiment Performance Submission Page
No. Date Date No.
1 Design the software requirement specification
document for given problem statement.
2 Design the Use case diagram for given problem
statement.

2
Enrollment ID Software Engineering Laboratory (CS331) Student Name

Lab Experiment - 1
Aim: Design the software requirement specification document for given problem statement.
(Name of your project)
Objective: To find the requirement specification (both functional and nonfunctional) of a given
Problem.
Description:
An SRS is basically an organization's understanding (in writing) of a customer or potential
client's system requirements and dependencies at a particular point in time (usually) prior to any
actual design or development work. It's a two-way insurance policy that assures that both the
client and the organization understand the other's requirements from that perspective at a given
point in time.
The SRS document itself states in precise and explicit language those functions and capabilities a
software system (i.e., a software application, an eCommerce Web site, and so on) must provide,
as well as states any required constraints by which the system must abide. The SRS also
functions as a blueprint for completing a project with as little cost growth as possible. The SRS is
often referred to as the "parent" document because all subsequent project management
documents, such as design specifications, statements of work, software architecture
specifications, testing and validation plans, and documentation plans, are related to it.
It's important to note that an SRS contains functional and nonfunctional requirements only; it
doesn't offer design suggestions, possible solutions to technology or business issues, or any other
information other than what the development team understands the customer's system
requirements to be.
A well-designed, well-written SRS accomplishes four major goals:
•It provides feedback to the customer. An SRS is the customer's assurance that the development
organization understands the issues or problems to be solved and the software behavior
necessary to address those problems. Therefore, the SRS should be written in natural language
(versus a formal language, explained later in this article), in an unambiguous manner that may
also include charts, tables, data flow diagrams, decision tables, and so on.
•It decomposes the problem into component parts. The simple act of writing down software
requirements in a well-designed format organizes information, places borders around the

3
Enrollment ID Software Engineering Laboratory (CS331) Student Name

problem, solidifies ideas, and helps break down the problem into its component parts in an
orderly fashion.
•It serves as an input to the design specification. As mentioned previously, the SRS serves as the
parent document to subsequent documents, such as the software design specification and
statement of work. Therefore, the SRS must contain sufficient detail in the functional system
requirements so that a design solution can be devised.
•It serves as a product validation check. The SRS also serves as the parent document for testing
and validation strategies that will be applied to the requirements for verification.
SRSs are typically developed during the first stages of "Requirements Development," which is
the initial product development phase in which information is gathered about what requirements
are needed--and not. This information-gathering stage can include onsite visits, questionnaires,
surveys, interviews, and perhaps a return-on-investment (ROI) analysis or needs analysis of the
customer or client's current business environment. The actual specification, then, is written after
the requirements have been gathered and analyzed.
SRS should address the following
The basic issues that the SRS shall address are the following:
a) Functionality: What is the software supposed to do?
b) External interfaces: How does the software interact with people, the system’s hardware,
other hardware, and other software?
c) Performance: What is the speed, availability, response time, recovery time of various
software functions, etc.?
d)Attributes: What are the portability, correctness, maintainability, security, etc. considerations?
e) Design constraints imposed on an implementation: Are there any required standards in
effect, implementation language, policies for database integrity, resource limits, operating
environment(s) etc.
Characteristics of a good SRS
An SRS should be
a) Correct
b) Unambiguous
c) Complete
d) Consistent
e) Ranked for importance and/or stability
f) Verifiable
g) Modifiable
h) Traceable

4
Enrollment ID Software Engineering Laboratory (CS331) Student Name

Correct - This is like motherhood and apple pie. Of course you want the specification to be
correct. No one writes a specification that they know is incorrect. We like to say - "Correct and
Ever Correcting." The discipline is keeping the specification up to date when you find things that
are not correct.
Unambiguous - An SRS is unambiguous if, and only if, every requirement stated therein has
only one interpretation. Again, easier said than done. Spending time on this area prior to
releasing the SRS can be a waste of time. But as you find ambiguities - fix them.
Complete - A simple judge of this is that is should be all that is needed by the software designers
to create the software.
Consistent - The SRS should be consistent within itself and consistent to its reference
documents. If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in another.
Ranked for Importance - Very often a new system has requirements that are really marketing
wish lists. Some may not be achievable. It is useful provide this information in the SRS.
Verifiable - Don't put in requirements like - "It should provide the user a fast response." Another
of my favorites is - "The system should never crash." Instead, provide a quantitative requirement
like: "Every key stroke should provide a user response within 100 milliseconds."
Modifiable - Having the same requirement in more than one place may not be wrong - but tends
to make the document not maintainable.
Traceable - Often, this is not important in a non-politicized environment. However, in most
organizations, it is sometimes useful to connect the requirements in the SRS to a higher level
document. Why do we need this requirement?
A sample of basic SRS Outline
1. Introduction
1.1 Purpose
1.2 Document conventions
1.3 Intended audience
1.4 Additional information
1.5 Contact information/SRS team members
1.6 References

2. Overall Description
2.1 Product perspective
2.2 Product functions
2.3 User classes and characteristics
2.4 Operating environment
2.5 User environment
2.6 Design/implementation constraints
2.7 Assumptions and dependencies

5
Enrollment ID Software Engineering Laboratory (CS331) Student Name

3. External Interface Requirements

3.1 User interfaces
3.2 Hardware interfaces
3.3 Software interfaces
3.4 Communication protocols and interfaces

4. System Features
4.1 System feature
4.1.1 Description and priority
4.1.2 Action/result
4.1.3 Functional requirements
4.2 System feature B

5. Other Nonfunctional Requirements

5.1 Performance requirements
5.2 Safety requirements
5.3 Security requirements
5.4 Software quality attributes
5.5 Project documentation
5.6 User documentation

6.Other Requirements
Appendix A: Terminology/Glossary/Definitions list Appendix B: To be determined

Software Requirement Specification for (Your Project Name)

SRS Document designed by you

Conclusion: The SRS was made successfully by following the steps described above.

6
Enrollment ID Software Engineering Laboratory (CS331) Student Name

Lab Experiment - 2
Aim: Design the use case diagram for given problem statement.
Objective: To get familiar with the use case diagram.
Description:
According to the UML specification a use case diagram is “a diagram that shows the
relationships among actors and use cases within a system.” Use case diagrams are often used to:
•Provide an overview of all or part of the usage requirements for a system or organization in the
form of an essential model or a business model
•Communicate the scope of a development project
•Model your analysis of your usage requirements in the form of a system use case model
Use case models should be developed from the point of view of your project stakeholders and
not from the (often technical) point of view of developers. There are guidelines for:
Use Cases Actors Relationships
System Boundary Boxes
1.Use Cases
A use case describes a sequence of actions that provide a measurable value to an actor. A use
case is drawn as a horizontal ellipse on a UML use case diagram.
1.Use Case Names Begin with a Strong Verb
2.Name Use Cases Using Domain Terminology
3.Place Your Primary Use Cases in The Top-Left Corner of the Diagram
4.Imply Timing Considerations by Stacking Use Cases.
2.Actors
An actor is a person, organization, or external system that plays a role in one or more interactions
with your system (actors are typically drawn as stick figures on UML Use Case diagrams).
1.Place Your Primary Actor(S) In The Top-Left Corner of the Diagram

7
Enrollment ID Software Engineering Laboratory (CS331) Student Name

2.Draw Actors to The Outside of a Use Case Diagram

3.Name Actors with Singular, Business-Relevant Nouns
4.Associate Each Actor with One Or More Use Cases
5.Actors Model Roles, Not Positions
6.Use <<system>> to Indicate System Actors
7.Actors Don’t Interact with One Another
8.Introduce an Actor Called “Time” to Initiate Scheduled Events
3.Relationships
There are several types of relationships that may appear on a use case diagram:
•An association between an actor and a use case
•An association between two use cases
•A generalization between two actors
•A generalization between two use cases
Associations are depicted as lines connecting two modeling elements with an optional open-
headed arrowhead on one end of the line indicating the direction of the initial invocation of the
relationship. Generalizations are depicted as a close-headed arrow with the arrow pointing
towards the more general modeling element.
1.Indicate an Association Between an Actor and A Use Case If the Actor Appears Within the
Use Case Logic
2.Avoid Arrowheads On Actor-Use Case Relationships
3.Apply <<include>> When You Know Exactly When to Invoke the Use Case
4.Apply <<extend>> When A Use Case May Be Invoked Across Several Use Case Steps
5.Introduce <<extend>> associations sparingly
6.Generalize Use Cases When a Single Condition Results in Significantly New Business Logic
7.Do Not Apply <<uses>>, <<includes>>, or <<extends>>
8.Avoid More Than Two Levels of Use Case Associations
9.Place an Included Use Case to The Right of the Invoking Use Case
10.Place an Extending Use Case Below the Parent Use Case
11.Apply the “Is Like” Rule to Use Case Generalization
12.Place an Inheriting Use Case Below the Base Use Case
13.Apply the “Is Like” Rule to Actor Inheritance
14.Place an Inheriting Actor Below the Parent Actor
4.System Boundary Boxes
The rectangle around the use cases is called the system boundary box and as the name suggests it
indicates the scope of your system – the use cases inside the rectangle represent the functionality
that you intend to implement.
1.Indicate Release Scope with a System Boundary Box.
2.Avoid Meaningless System Boundary Boxes.

8
Enrollment ID Software Engineering Laboratory (CS331) Student Name

Creating Use Case Diagrams

we start by identifying as many actors as possible. You should ask how the actors interact with
the system to identify an initial set of use cases. Then, on the diagram, you connect the actors
with the use cases with which they are involved. If actor supplies information, initiates the use
case, or receives any information as a result of the use case, then there should be an association
between them.
Software: GenMyModel
Procedure:
Draw use case diagram by using GenMyModel software and write the steps you followed to
design use case diagram for your project
Conclusion: The Use Case diagram was made successfully by following the steps described
above.