Experiment No: 1

Type of problem SRS document

List of program All Prepare a SRS document in line with the IEEE
recommended standards.
Template of SRS in IEEE format

1. Introduction .......................................................... Error! Bookmark not defined.

1.1 Purpose .......................................................................... Error! Bookmark not defined.
1.2 Document Conventions ................................................. Error! Bookmark not defined.
1.3 Intended Audience and Reading Suggestions ............... Error! Bookmark not defined.
1.4 Product Scope ............................................................... Error! Bookmark not defined.
1.5 References ..................................................................... Error! Bookmark not defined.
2. Overall Description............................................... Error! Bookmark not defined.
2.1 Product Perspective ....................................................... Error! Bookmark not defined.
2.2 Product Functions ......................................................... Error! Bookmark not defined.
2.3 User Classes and Characteristics ................................... Error! Bookmark not defined.
2.4 Operating Environment ................................................. Error! Bookmark not defined.
2.5 Design and Implementation Constraints ....................... Error! Bookmark not defined.
2.6 User Documentation...................................................... Error! Bookmark not defined.
2.7 Assumptions and Dependencies .................................... Error! Bookmark not defined.
3. External Interface Requirements ........................ Error! Bookmark not defined.
3.1 User Interfaces .............................................................. Error! Bookmark not defined.
3.2 Hardware Interfaces ...................................................... Error! Bookmark not defined.
3.3 Software Interfaces........................................................ Error! Bookmark not defined.
3.4 Communications Interfaces ........................................... Error! Bookmark not defined.
4. System Features .................................................... Error! Bookmark not defined.
4.1 System Feature 1 ........................................................... Error! Bookmark not defined.
4.2 System Feature 2 (and so on) ........................................ Error! Bookmark not defined.
5. Other Nonfunctional Requirements ................... Error! Bookmark not defined.
5.1 Performance Requirements ........................................... Error! Bookmark not defined.
5.2 Safety Requirements ..................................................... Error! Bookmark not defined.
5.3 Security Requirements .................................................. Error! Bookmark not defined.
5.4 Software Quality Attributes .......................................... Error! Bookmark not defined.
5.5 Business Rules .............................................................. Error! Bookmark not defined.
6. Other Requirements ............................................. Error! Bookmark not defined.
Appendix A: Glossary................................................... Error! Bookmark not defined.
Appendix B: Analysis Models ...................................... Error! Bookmark not defined.
Appendix C: To Be Determined List........................... Error! Bookmark not defined.
 Experiment No:
Type of problem Use case Diagram
List of program All Draw the use case diagram and specify the
role of each of the actors.
Use Case Specification : <Use-Case Name>
1. Use Case Name

1.1 Brief Description

[ The description should briefly convey the role and purpose of the use case. A single paragraph
should suffice for this description.]
2. Flow of Events

2.1 Basic Flow

This use case starts when the actor does something. An actor always initiates use Cases. The use
case should describe what the actor does and what the system does in response. It should be
phrased in the form of a dialog between the actor and the system.
The use case should describe what happens inside the system, but not how or why. If information
is exchanged be specific about what is passed back and forth. For example, it is not very
illuminating to say that the Actor enters customer information; it is better to say the Actor enters
the customer’s name and address. A Glossary of Terms is often useful to keep the complexity of
the use case manageable; you may want to define things like customer information there, to keep
the use case from drowning in details.
Simple alternatives may be presented within the text of the use case. If it only takes a few
sentences to describe what happens when there is an alternative; do it directly within the flow of
events section. If the alternative flows are more complex, use a separate section to describe it. For
example An Alternative Flow describes how to describe more complex alternatives.
A picture is sometimes worth a thousand words (though there is no substitute for clean, clear
prose). If it improves clarity, feel free to paste graphical depictions of user interfaces, process
flows, or other figures into the use case to improve its clarity. If a flow chart is useful to present
a complex decision process, by all means use it! Similarly for state-dependent behavior, a state-
transition diagram often clarifies the behavior of a system better than pages upon pages of text.
Use the right presentation medium for your problem, but be wary of using terminology, notation
or figures that your audience may not understand. Remember that your purpose is to clarify, not
obscure.]

2.2 Alternative Flows

2.2.1 < First Alternative Flow>

[More complex alternatives should be described in a separate section, which is referred to in the
basic flow of events section. Think of the alternative flow sections like alternative behavior each
alternative flow represents alternative behavior (many times, because of exceptions that occur in
the main flow). They may be as long as necessary to describe the events associated with the
alternative behavior. When an alternative flow ends, the events of the main flow of events are
resumed unless otherwise stated.]
2.2.1.1 <An Alternative sub-flow>
[Alternative flows may in turn be broken down into sub-sections if it improves clarity.]
2.2.2 <Second Alternative Flow>

[There may be, and most likely will be, a number of alternative flows in a use case. Keep each
alternative separate to improve clarity. Using alternative flows improves the readability of the
use case, as well as preventing use cases from being decomposed into hierarchies of use cases.
Keep in mind that use cases are just textual descriptions, and their main purpose is to document
the behavior of a system in a clear, concise and understandable way.]

3. Special Requirements

[A Special Requirement is typically a non-functional requirement that is specific to a use case

but is not easily or naturally specified in the text of the use case’s event flow. Examples of
special requirements include legal and regulatory requirements, application standards, and
quality attributes of the system to be built, including usability, reliability, performance or
supportability requirements. Additionally, other requirements such as operating systems and
environments, compatibility requirements, and design constraints should be captured in this
section.]

3.1 <First special requirement>

4. Preconditions
[A precondition (of a use case) is the state of the system that must be present prior to a use case
being performed.]

4.1 <Precondition One>

5. Post Conditions
[A post condition (of a use case) is a list of possible states the system can be in immediately
after a use case has finished.]
5.1 <Post condition one>

6. Extension Points

[Extension points of the use case.]

6.1 <Name of extension point>

[Definition of the location of the extension point in the flow of events.]

Explain the ATM example which was made in StarUML.

Experiment No:
Type of problem Activity diagram.
List of program All Draw the activity diagram.
Activity diagram is another important diagram in UML to describe the dynamic aspects of the
system.

Activity diagram is basically a flowchart to represent the flow from one activity to another
activity. The activity can be described as an operation of the system.

The control flow is drawn from one operation to another. This flow can be sequential, branched,
or concurrent. Activity diagrams deal with all type of flow control by using different elements
such as fork, join, etc

Purpose of Activity Diagrams

The basic purposes of activity diagrams is similar to other four diagrams. It captures the dynamic
behavior of the system. Other four diagrams are used to show the message flow from one object
to another but activity diagram is used to show message flow from one activity to another.

Activity is a particular operation of the system. Activity diagrams are not only used for
visualizing the dynamic nature of a system, but they are also used to construct the executable
system by using forward and reverse engineering techniques. The only missing thing in the
activity diagram is the message part.

It does not show any message flow from one activity to another. Activity diagram is sometimes
considered as the flowchart. Although the diagrams look like a flowchart, they are not. It shows
different flows such as parallel, branched, concurrent, and single.

The purpose of an activity diagram can be described as −

● Draw the activity flow of a system.

● Describe the sequence from one activity to another.

● Describe the parallel, branched and concurrent flow of the system.

How to Draw an Activity Diagram?

Activity diagrams are mainly used as a flowchart that consists of activities performed by the
system. Activity diagrams are not exactly flowcharts as they have some additional capabilities.
These additional capabilities include branching, parallel flow, swimlane, etc.

Before drawing an activity diagram, we must have a clear understanding about the elements used
in activity diagram. The main element of an activity diagram is the activity itself. An activity is
a function performed by the system. After identifying the activities, we need to understand how
they are associated with constraints and conditions.

Before drawing an activity diagram, we should identify the following

elements −

● Activities

● Association

● Conditions

● Constraints

Once the above-mentioned parameters are identified, we need to make a mental layout of the
entire flow. This mental layout is then transformed into an activity diagram.

Following is an example of an activity diagram for order management system. In the diagram,
four activities are identified which are associated with conditions. One important point should be
clearly understood that an activity diagram cannot be exactly matched with the code. The activity
diagram is made to understand the flow of activities and is mainly used by the business users

Following diagram is drawn with the four main activities −

● Send order by the customer

● Receipt of the order

● Confirm the order

● Dispatch the order

After receiving the order request, condition checks are performed to check if it is normal or
special order. After the type of order is identified, dispatch activity is performed and that is
marked as the termination of the process.
Where to Use Activity Diagrams?
The basic usage of activity diagram is similar to other four UML diagrams. The specific usage is
to model the control flow from one activity to another. This control flow does not include
messages.

Activity diagram is suitable for modeling the activity flow of the system. An application can have
multiple systems. Activity diagram also captures these systems and describes the flow from one
system to another. This specific usage is not available in other diagrams. These systems can be
database, external queues, or any other system.

We will now look into the practical applications of the activity diagram. From the above
discussion, it is clear that an activity diagram is drawn from a very high level. So it gives high
level view of a system. This high level view is mainly for business users or any other person who
is not a technical person.

This diagram is used to model the activities which are nothing but business requirements. The
diagram has more impact on business understanding rather than on implementation details.

Activity diagram can be used for −

● Modeling work flow by using activities.

● Modeling business requirements.

● High level understanding of the system's functionalities.

● Investigating business requirements at a later stage.