Software Requirements

Specification
for

Extensible Diagramming
Software (EDS)
Version 0.1-draft

Prepared by Rizky Januar Akbar

Department of Informatics

Institut Teknologi Sepuluh Nopember

October 1, 2015

Copyright1999byKarlE.Wiegers.Permissionisgrantedtouse,modify,anddistributethisdocument.

SoftwareRequirementsSpecificationforEDS

Pageii

TableofContents
1. Introduction..............................................................................................................................1
1.1
1.2
1.3
1.4

Purpose.......................................................................................................................................1
DocumentConventions..............................................................................................................1
ProjectScope..............................................................................................................................1
References..................................................................................................................................1

2.1
2.2
2.3
2.4
2.5
2.6
2.7

ProductPerspective....................................................................................................................2
ProductFunctions.......................................................................................................................2
UserClassesandCharacteristics................................................................................................3
OperatingEnvironment..............................................................................................................4
DesignandImplementationConstraints.....................................................................................4
UserDocumentation...................................................................................................................4
AssumptionsandDependencies.................................................................................................4

3.1
3.2
3.3

UserInterfaces............................................................................................................................5
HardwareInterfaces...................................................................................................................5
SoftwareInterfaces.....................................................................................................................6

4.1
4.2

SystemFeature1........................................................................................................................6
SystemFeature2(andsoon).....................................................................................................6

5.1
5.2
5.3
5.4
5.5

PerformanceRequirements.........................................................................................................6
SafetyRequirements...................................................................................................................7
SecurityRequirements................................................................................................................7
SoftwareQualityAttributes........................................................................................................7
BusinessRules............................................................................................................................7

2. OverallDescription..................................................................................................................2

3. ExternalInterfaceRequirements...........................................................................................5

4. SystemFeatures.......................................................................................................................6
5. OtherNonfunctionalRequirements.......................................................................................6

6. OtherRequirements................................................................................................................7

SoftwareRequirementsSpecificationforEDS

Pageiii

RevisionHistory
Name

Date

ReasonForChanges

Version

SoftwareRequirementsSpecificationforEDS

1.

Introduction

1.1

Purpose

Page1

This SRS describes the functional and nonfunctional requirements for software release 1.0 of
Extensible Diagramming Software (EDS). This document is prepared for the students of the
Software Construction Course in Department of Informatics, Institut Teknologi Sepuluh Nopember
(ITS). The students, who will implement and verify the system, will be arranged into several
project teams by the class instructor based on the systems functionalities described in this SRS.
Each team will get an assignment for one semester to implement certain system functionalities
that are part of release 1.0. During one-semester course, each team has to prepare a detailed
design based on this SRS, implement the design into working code, test the code, integrate the
code, and present the final result to the other teams.

1.2

DocumentConventions

No special typographical conventions are used in this SRS.

1.3

ProjectScope

Extensible Diagramming Software (EDS) is a standalone desktop application that acts as a

platform for various diagramming needs. Basically, the user can use this software to make any
kind of diagrams using mouse and keyboard devices, store the diagram into file systems and load
it later, and provide specific functionalities needed by a specific diagram. Users can also
contribute to the platform by developing a plugin that contains specific diagram implementation.
The release version 1.0 of EDS is expected to provide common functionalities such as user
interface, user interaction via mouse and keyboard devices, diagram viewers, undo-redo engine,
persistence engine, model checker, plugin engine, and code generator. It will also include basic
diagramming functionalities for Conceptual Data Model (CDM) and Physical Data Model (PDM)
only. However, the application shall provide extension points that can handle other diagram
notations.
Another expected outcome from this project is this system can be used as a case study for
students in learning software design patterns. Problems and solutions of software design during
the construction of EDS shall be documented and will be included as project deliverables.

1.4

References

<List any other documents or Web addresses to which this SRS refers. These may include user
interface style guides, contracts, standards, system requirements specifications, use case
documents, or a vision and scope document. Provide enough information so that the reader could
access a copy of each reference, including title, author, version number, date, and source or
location.>

SoftwareRequirementsSpecificationforEDS

2.

OverallDescription

2.1

ProductPerspective

Page2

The EDS is a new software system that provides common functionalities of diagramming needs.
The system is a standalone desktop application that does not require network connections. The
architecture of this system is illustrated in Figure 1. The system has several core components,
such as UI, undo-redo, persistence, and plugin manager. The other components such as the
diagram, the model checker, and the code generator are treated as plugins. The examples of
such plugin implementations for diagram, model checker, and code generator are CDM, CDM
checker, and PDM codegen, respectively. Any future functionalities are expected to be
implemented via plugin manager. In the software release 1.0 plugins that will be implemented are
CDM, PDM, CDM checker, PDM checker, and PDM codegen.

Figure1.EDSplatformarchitecture

2.2
#

ProductFunctions

Function
UI

1.1

Dynamic menubar

1.2

Dynamic toolbar

1.3

Dynamic toolbox

1.4

Dynamic view

1.4.1

Project explorer view

Description
Provides UI abstraction that should be separated from the UI
framework e.g. System.Windows.Forms.
Creates a menubar that can change dynamically based on the
plugin contents.
Creates a toolbar that can change dynamically based on the
plugin contents.
Creates a toolbox that can change dynamically based on the
active diagram type.
Creates view abstraction that can be docked onto the main
window and the content can be determined by its subclass.
Provides window containing information about project structures

SoftwareRequirementsSpecificationforEDS

1.4.2

Model checker view

1.4.3

Property view

1.5

Editor

1.5.1

Object drawing
mechanism
Object selection
menchanism

1.5.2

1.5.3

Zooming and panning

1.5.4

Object manipulation

1.5.5
1.5.6

Auto-layout
Dynamic popup

2
2.1

Undo-redo
Undo-redo API

2.2
3

Undo-redo integration
Persistence

3.1

Object-to-XML
serialization
XML-to-object
deserialization
Model checking

4.1

CDM checking

4.2

PDM checking

Plugin manager

5.1

CDM plugin

5.2

PDM plugin

6
6.1

Code generator
PDM-to-SQL (DDL)
generator

3.2

2.3

that are loaded into the application.

Provides window containing information about the result of
model checking process.
Provides window containing attribute information of selected
object(s).
Provides basic abstraction for object drawings and user
interactions.
Provides abstraction for drawing and storing objects on the editor
using mouse click and gesture.
Provides abstraction for selecting single or multiple objects and
reflects the changes affected by the selection on the editor.
Performs lookup from k-d tree data structure that holds drawing
objects.
Provides mechanisms for zooming and panning over objects on
the editor.
Provides mechanims for manipulating object states on the editor
and synchronizes the changes on the in-memory representation.
Provides algorithms for layouting objects selected on the editor.
Provides a dynamic window popup that will appear when the
users perform right-click on the editor. The location of click will
determine the content of the popup.
Provides implementation of undo and redo engine.
Provides abstraction for doing undo and redo. Stores and
retrieves the object states from undo-redo engine.
Integrates the API into the application.
Provides mechanisms for storing object states into file systems
and loading object from file systems into editor.
Serializes objects into XML representation defined by each
diagram.
Deserializes XML representation defined by each diagram into
memory or editor.
Provides abstraction to allow checking of model/diagram
correctness.
Provides algorithms to check the correctness of CDM and
defines items that will be checked on the process.
Provides algorithms to check the correctness of PDM and
defines items that will be checked on the process.
Provides mechanism for installing new plugins, managing
existing plugin lifecyle, and unloading plugins.
Provides abstraction for diagram plugins and implements the
abstraction in the CDM plugin.
Provides abstraction for diagram plugins and implements the
abstraction in the PDM plugin.
Provides mechanism for generating code based on model.
Creates implementation of DDL that convert PDM into SQL
scripts.

UserClassesandCharacteristics

User class

Page3

Description

SoftwareRequirementsSpecificationforEDS

2.4

Page4

OperatingEnvironment

OE-1: The EDS shall operate correctly with Windows operating system versions 7 through 10.
OE-2: The EDS shall operate correctly on a machine running a minimum .NET Framework version
4.

2.5

DesignandImplementationConstraints

CO-1: The EDS UI shall use Windows Forms framework provided by .NET Framework version 4.
CO-2: The EDS UI shall provide a consistent abstraction so that switching to another UI
framework can be easily done.
CO-3: The persistence mechanism shall conform to XML format.

2.6

UserDocumentation

DOC-1: The problems and solutions during development shall be documented in a .doc/.docx
format.

2.7

AssumptionsandDependencies

<List any assumed factors (as opposed to known facts) that could affect the requirements stated
in the SRS. These could include third-party or commercial components that you plan to use,
issues around the development or operating environment, or constraints. The project could be
affected if these assumptions are incorrect, are not shared, or change. Also identify any
dependencies the project has on external factors, such as software components that you intend
to reuse from another project, unless they are already documented elsewhere (for example, in the
vision and scope document or the project plan).>

SoftwareRequirementsSpecificationforEDS

3.

ExternalInterfaceRequirements

3.1

UserInterfaces

Page5

UI-1: The EDS UI shall conform to screen layout constraints described in the Figure 2.

Figure2.TheEDSmainwindow

3.2

HardwareInterfaces

HDI-1: User input is done via mouse and keyboard devices.

HDI-2: User can interact with the editor using mouse via click, double clicks, and gesture
(combination of clicks and drags).
HDI-3: Combination of keyboard keypress and mouse click/gesture can also be used as input
method.
HDI-4: The EDS provides shortcut to several functionalities using key combinations.
HDI-5: The input performed by users shall be rendered directly to the display devices and the
state changes of the objects on the editor shall be directly rendered to the display devices
following the input from the users (instant feedback).

SoftwareRequirementsSpecificationforEDS

3.3

Page6

SoftwareInterfaces

SWI-1: The EDS shall use .NET Framework for its graphical user interface by providing clear
separation on the EDS main UI abstraction and implementation using .NET Framework version 4.

4.

SystemFeatures

<This template illustrates organizing the functional requirements for the product by system
features, the major services provided by the product. You may prefer to organize this section by
use case, mode of operation, user class, object class, functional hierarchy, or combinations of
these, whatever makes the most logical sense for your product.>

4.1

SystemFeature1

<Dont really say System Feature 1. State the feature name in just a few words.>

4.1.1

DescriptionandPriority
<Provide a short description of the feature and indicate whether it is of High,
Medium, or Low priority. You could also include specific priority component ratings,
such as benefit, penalty, cost, and risk (each rated on a relative scale from a low of
1 to a high of 9).>

4.1.2

Stimulus/ResponseSequences
<List the sequences of user actions and system responses that stimulate the
behavior defined for this feature. These will correspond to the dialog elements
associated with use cases.>

4.1.3

FunctionalRequirements
<Itemize the detailed functional requirements associated with this feature. These
are the software capabilities that must be present in order for the user to carry out
the services provided by the feature, or to execute the use case. Include how the
product should respond to anticipated error conditions or invalid inputs.
Requirements should be concise, complete, unambiguous, verifiable, and
necessary. Use TBD as a placeholder to indicate when necessary information is
not yet available.>
<Each requirement should be uniquely identified with a sequence number or a
meaningful tag of some kind.>

REQ-1:
REQ-2:

SoftwareRequirementsSpecificationforEDS

4.2

SystemFeature2(andsoon)

5.

OtherNonfunctionalRequirements

5.1

PerformanceRequirements

Page7

PF-1: There shall be no noticeable lags or delays between user input and rendered output.

5.2

SafetyRequirements

SF-1: The EDS shall provide mechanism of auto saving document into file system in a periodical
way to prevent data loss during power outage.

5.3

SecurityRequirements

No security requirements have been identified.

5.4

SoftwareQualityAttributes

SQ-1: The EDS shall provide plugin mechanism to accomodate future features.
SQ-2: The design of EDS code shall provide extension points to increase maintainability.

5.5

BusinessRules

No business rules have been identified.

6.

OtherRequirements

<Define any other requirements not covered elsewhere in the SRS. This might include database
requirements, internationalization requirements, legal requirements, reuse objectives for the
project, and so on. Add any new sections that are pertinent to the project.>

AppendixA:Glossary
<Define all the terms necessary to properly interpret the SRS, including acronyms and
abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire
organization, and just include terms specific to a single project in each SRS.>

AppendixB:AnalysisModels
<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams,
state-transition diagrams, or entity-relationship diagrams.>

SoftwareRequirementsSpecificationforEDS

Page8

AppendixC:ToBeDeterminedList
<Collect a numbered list of the TBD (to be determined) references that remain in the SRS so they
can be tracked to closure.>