Table o content

1. Assignment8FinalDraftSRS………………………………………………………...……..2
2. Complete SRS Section E.1 FCS Class Diagram…………………………………........
…...2
Class diagram………………………………………………………………………...……2
Attributes............................................................................................................………......2
Operations………………………………………………………………………................5
Relationship……………………………………………………………………....……….5
Thus the requirements for your UML class diagram include the
following……………......5
Class diagram……………………………………………..…………………………….....5
Classes……………………...…………………………………………………..……….…6
Relationships with multiplicity limitations, including named relationships…………….…
7
2. Complete SRS Section E.2 Class Definitions by defining each class in the Class
Definitions table. …………………………...………………...
………………………………………..8
UML Diagrams……………………………………………………………………………8
Figured-out structur ……..………………………………………………………………..8
Diagram of behavior……………………………………….………………..
……………..9
Relationship
……………………………………………………………………………….9
3. Discussion of Section E.3 Class
Diagram……………………………………………………………..……………………10
Specifications for software…………….…………………………………………………
10
Characteristics of good
SRS……………………………………………………………...11

1
2
 1. Assignment8FinalDraftSRS
2. Complete SRS Section E.1 FCS Class Diagram

Class diagram: A diagram, which depicts the system's classes, properties, and relationships
between the classes, shows the structure of a system.

Attributes:

Quality can be defined in a variety of ways. Let's now examine the methods for evaluating a
product or application's quality attributes.

 The member Ends of Associations;

3
  Classifier characteristics (where a property is held by a Classifier rather than an
Association);
 Component parts of structural classifiers.

The following variables are used to gauge the quality of software development. The performance
of a product can be evaluated using each attribute. Both Quality control and Quality assurance
can make use of these characteristics.

Activities for quality assurance are focused on preventing the introduction of flaws, whereas
those for quality control are meant to find flaws in goods and services.

 Dependability

Make sure the product is robust enough to endure any challenges. ought to consistently deliver
the desired outcomes. The performance of a project in diverse working environments and
conditions is used to assess a product's dependability.

 Reliableness

It should be easy to maintain the product's numerous revisions. An established system should be
easy to upgrade and add code to for new features as they become available.

It should be low-cost and easy to maintain. The programme can be updated, errors can be fixed,
and system maintenance is easy.

 Usability

The ease of usage can be used to gauge this. The software should be simple to use. It ought to be
simple to learn. It should be easy to navigate.

 It is simple to operate, prepare the input, and evaluate the result.

 Give our other regularly used systems comparable user interface guidelines and
standards.
 The system is simple to learn to utilise for new or occasional users.

 Portability

4
This can be assessed in terms of cost-related porting challenges, technical porting issues, and
behavioral porting issues.

 Correctness

The navigation, calculations utilised internally, and functioning of the application should all be
correct. This indicates that the application must follow the functional specifications.

 Effectiveness

It is a significant aspect of system quality. It is determined by how long it takes for the system to
finish any given task. For instance, the system should effectively use memory, disc space, and
CPU power.

The user will experience decreased performance if the system is using all of the resources,
making it inefficient. Real-time applications cannot be employed with an inefficient system.

 Integrity or Security

Integrity and security go together. System integrity or security should be adequate to prevent
data loss, illegal access to system functionalities, software infection by viruses, and protection of
the confidentiality of data input into the system.

 Testability

Defects in the system should be simple to test for and locate. It ought to be simple to separate
into several testing modules if necessary.

 Susceptibility

Must be adaptable enough to change. capable of being modified to interact with different items.
Should be simple to connect to other common third-party components.

 Reusability

Reusing existing software is an excellent time and money-saving development strategy. Different
code library classes must to be sufficiently general to be used quickly in various application
modules. The application should be divided up into many modules to allow for module reuse.

5
  Interoperability

It should be simple for a product to communicate data or services with other systems via
interoperability of one system to another. Different system modules ought to function well under
various operating system environments, database configurations, and protocol situations.

Operations:

 a characteristic of a classifier's behavior that details the class's name, type, parameters,
and restrictions
 The type of the return parameter might have preconditions and post conditions,
 for example: + create Window (location: Coordinates): Window

Relationships

 The relationship between a classifier that is generic and one that is particular
 The more specialised classifier carries over the traits of the more generic classifier.
 Every instance of the specialised classifier also functions as an indirect instance of the
general classifier.

Thus the requirements for your UML class diagram include the following:

 class diagram

6
Demonstrates a system's classes, properties, and relationships between the classes to describe the
structure of the system.

Classes:

 is a unique classifier

7
  Explains a group of objects having a common set of characteristics (attributes and
operations).
 A class instance is an object.

Relationships with multiplicity limitations, including named relationships

 Between the lowest and greatest numbers, there is a range.

 Specifies how many objects of the opposing type may be connected to a specific item
using the syntax number or min..max.

Multiplicity example:

Multiplicity - order and uniqueness

• Multiplicity specifies the arrangement and individuality of the collection's pieces.

• The uniqueness and/or ordering of the values can be specified using this option.

• Sequential ordering of the values in the collection constitutes order (default: not ordered)

• Uniqueness: Every value in the collection of values ought to be different (default: is unique)

Property = attribute or end

8
2. Complete SRS Section E.2 Class Definitions by defining each class in the Class
Definitions table.

UML Diagrams

Figured-out structure

The software architecture of software systems is often explained with the use of diagrams that
show the structure.

9
• Class diagram: Displays the system's classes together with their traits and links between them
in order to demonstrate how the system is set up.

• Component diagram: Shows how a software system is broken down into its individual
components and how those components are connected.

• Composite structure diagram: Outlines the internal organisation of a classifier and the
collaborations enabled by this organisation.

• Deployment diagram: This displays the system's hardware, together with the execution
environments and artefacts that were installed on it.

• Object diagram: Shows the structure of a sample-modelled system at a certain time, either
whole or in part.

• A package diagram shows how logically a system is split by visually depicting the linkages
between several groupings.

• Profile Diagram: Displays stereotypes as classes with the stereotype stereotype at the
metamodeling level and profiles as packages with the stereotype stereotype.

Diagram of a behavior

As a result of their ability to portray how a system works, behaviour diagrams are commonly
used to illustrate the operation of software systems.

The administrative and operational routines of system components are thoroughly described in
activity diagrams.

 Use Case Diagram: This diagram shows how a system works in terms of actors, the
objectives they are working toward (represented by use cases), and any relationships
between those use cases.
 The state machine diagram describes state transitions and the system’s states.

Relationships in a graph:

An interaction diagram, a subclass of behaviour diagrams, is used to highlight the data and
control flow among the system's components:

10
• Sequence diagram: Shows how several elements interact via a series of events. In relation to
such messages, also provide the object lifespans.

• Communication diagram: Shows the interactions between different parts or objects through a
series of messages.

• The interaction overview diagram provides a summary, with the nodes serving as placeholders
for communication diagrams.

• Time diagrams are a particular kind of interaction diagram where the primary topic is the
timing constraints.

3. Discussion of Section E.3 Class Diagram

Specifications for software

The functional and non-functional requirements for a software system that needs to be created
are thoroughly outlined in a software requirements specification (SRS). The SRS is created in
accordance with the contract between the customer and the contractors. It might also offer
examples of how consumers might interact with software. The project's specifications are all
contained in the software requirement specification paper. In order to create software systems,
we must fully comprehend how they work. We must have continual communication with our
customers in order to learn about all of their needs in order to achieve this.

In a variety of real-world settings, a strong SRS specifies how a software system will interact
with all internal components, hardware, other programmes, and users. The Software
requirements specification (SRS) document, which is maintained by the QA lead, is used by
managers to establish a test plan. To prevent mistakes in test cases and intended results, testers
must be knowledgeable about every subject discussed in this document.

It is strongly encouraged to study or evaluate SRS documents before starting to write test cases
or make any plans for testing. Let's examine SRS testing procedures and important factors to
keep in mind.

Characteristics of good SRS

11
To describe the classes, properties, operations (or methods), and relationships between objects in
a system, software engineers utilise class diagrams in the Unified Modeling Language (UML).

For object-oriented modelling, the class diagram acts as the cornerstone. It is used for both
precise modelling, which converts the models into computer code, and broad conceptual
modelling of the application's structure. Another instrument for data modelling is the class
diagram. [1] All of the important components, interactions, and classes that need to be coded are
represented by the classes in a class diagram.

The graphic shows classes as boxes with three sections each:

 The top compartment contains the class name. The first letter is written in capital letters,
bold type, and the centre.
 The centre container is where the class characteristics are held
 The class operations are in the bottom compartment, with the beginning letter in
lowercase and left aligned. They are left-aligned and have a lowercase initial.

12
To identify several classes and group them together to help understand the static connections
between them, a class diagram is used in system design. Thorough modelling usually breaks out
the classes in the conceptual design into subclasses.

References:

1.   Sparks, Geoffrey. "Database Modeling in UML". Retrieved 8 September 2011.

2. ^ Scott W. Ambler (2009) UML 2 Class Diagrams. Webdoc 2003-2009. Accessed Dec 2,
2009
3. ^ UML Reference Card, Version 2.1.2, Holub Associates, August 2007, retrieved 12
March 2011
4. ^ "UML derived property is property which value is produced or computed from other
information, for example, by using other properties". www.uml-diagrams.org.
Retrieved 2019-01-24.
5. ^ OMG Unified Modeling Language (OMG UML) Superstructure, Version 2.3: May
2010. Retrieved 23 September 2010.
6. ^ Fowler (2003) UML Distilled: A Brief Guide to the Standard Object Modeling
Language
7. ^ "UML Tutorial part 1: class diagrams" (PDF). Archived from the original (PDF) on
2007-01-03. Retrieved 2015-07-18.
8. ^ Goodwin, David. "Modelling and Simulation, p. 26" (PDF). The University of
Warwick. Retrieved  28 November 2015

13