Software Requirements Specification for Single Pendulum

Olu Owojaiye

Table of Contents

An outline of all sections included in this SRS is recorded here for easy reference.

• Table of Contents
• Reference Material
  • Table of Units
  • Table of Symbols
  • Abbreviations and Acronyms
• Introduction
  • Purpose of Document
  • Scope of Requirements
  • Characteristics of Intended Reader
  • Organization of Document
• General System Description
  • System Context
  • User Characteristics
  • System Constraints
• Specific System Description
  • Problem Description
    • Terminology and Definitions
    • Physical System Description
    • Goal Statements
  • Solution Characteristics Specification
    • Assumptions
    • Theoretical Models
    • General Definitions
    • Data Definitions
    • Instance Models
    • Data Constraints
    • Properties of a Correct Solution
• Requirements
  • Functional Requirements
  • Non-Functional Requirements
• Traceability Matrices and Graphs
• Values of Auxiliary Constants
• References

Reference Material

This section records information for easy reference.

Table of Units

The unit system used throughout is SI (Système International d’Unités). In addition to the basic units, several derived units are also used. For each unit, the Table of Units lists the symbol, a description, and the SI name.

Table of Units

Table of Symbols

The symbols used in this document are summarized in the Table of Symbols along with their units. Throughout the document, symbols in bold will represent vectors, and scalars otherwise. The symbols are listed in alphabetical order. For vector quantities, the units shown are for each component of the vector.

Table of Symbols

Abbreviations and Acronyms

Abbreviations and Acronyms

Introduction

A pendulum consists of mass attached to the end of a rod and its moving curve is highly sensitive to initial conditions. Therefore, it is useful to have a program to simulate the motion of the pendulum to exhibit its chaotic characteristics. The document describes the program called Single Pendulum , which is based on the original, manually created version of Double Pendulum.

The following section provides an overview of the Software Requirements Specification (SRS) for Single Pendulum. This section explains the purpose of this document, the scope of the requirements, the characteristics of the intended reader, and the organization of the document.

Purpose of Document

The primary purpose of this document is to record the requirements of SglPend. Goals, assumptions, theoretical models, definitions, and other model derivation information are specified, allowing the reader to fully understand and verify the purpose and scientific basis of SglPend. With the exception of system constraints, this SRS will remain abstract, describing what problem is being solved, but not how to solve it.

This document will be used as a starting point for subsequent development phases, including writing the design specification and the software verification and validation plan. The design document will show how the requirements are to be realized, including decisions on the numerical algorithms and programming environment. The verification and validation plan will show the steps that will be used to increase confidence in the software documentation and the implementation. Although the SRS fits in a series of documents that follow the so-called waterfall model, the actual development process is not constrained in any way. Even when the waterfall model is not followed, as Parnas and Clements point out parnasClements1986, the most logical way to present the documentation is still to “fake” a rational design process.

Scope of Requirements

The scope of the requirements includes the analysis of a two-dimensional (2D) pendulum motion problem with various initial conditions.

Characteristics of Intended Reader

Reviewers of this documentation should have an understanding of undergraduate level 2 physics, undergraduate level 1 calculus, and ordinary differential equations. The users of SglPend can have a lower level of expertise, as explained in Sec:User Characteristics.

Organization of Document

The organization of this document follows the template for an SRS for scientific computing software proposed by koothoor2013, smithLai2005, smithEtAl2007, and smithKoothoor2016. The presentation follows the standard pattern of presenting goals, theories, definitions, and assumptions. For readers that would like a more bottom up approach, they can start reading the instance models and trace back to find any additional information they require.

The goal statements are refined to the theoretical models and the theoretical models to the instance models.

General System Description

This section provides general information about the system. It identifies the interfaces between the system and its environment, describes the user characteristics, and lists the system constraints.

System Context

Fig:sysCtxDiag shows the system context. A circle represents an entity external to the software, the user in this case. A rectangle represents the software system itself (SglPend). Arrows are used to show the data flow between the system and its environment.

The interaction between the product and the user is through an application programming interface. The responsibilities of the user and the system are as follows:

• User Responsibilities
  • Provide initial conditions of the physical state of the motion and the input data related to the Single Pendulum, ensuring no errors in the data entry.
  • Ensure that consistent units are used for input variables.
  • Ensure required software assumptions are appropriate for any particular problem input to the software.
• SglPend Responsibilities
  • Detect data type mismatch, such as a string of characters input instead of a floating point number.
  • Determine if the inputs satisfy the required physical and software constraints.
  • Calculate the required outputs.
  • Generate the required graphs.

User Characteristics

The end user of SglPend should have an understanding of high school physics, high school calculus and ordinary differential equations.

System Constraints

There are no system constraints.

Specific System Description

This section first presents the problem description, which gives a high-level view of the problem to be solved. This is followed by the solution characteristics specification, which presents the assumptions, theories, and definitions that are used.

Problem Description

A system is needed to predict the motion of a single pendulum.

Terminology and Definitions

This subsection provides a list of terms that are used in the subsequent sections and their meaning, with the purpose of reducing ambiguity and making it easier to correctly understand the requirements.

• Gravity: The force that attracts one physical body with mass to another.
• Cartesian coordinate system: A coordinate system that specifies each point uniquely in a plane by a set of numerical coordinates, which are the signed distances to the point from two fixed perpendicular oriented lines, measured in the same unit of length (from cartesianWiki).

Physical System Description

The physical system of SglPend, as shown in Fig:sglpend, includes the following elements:

PS1: The rod.

PS2: The mass.

Goal Statements

Given the mass and length of the rod, initial angle of the mass and the gravitational constant, the goal statement is:

Motion-of-the-mass: Calculate the motion of the mass.

Solution Characteristics Specification

The instance models that govern SglPend are presented in the Instance Model Section. The information to understand the meaning of the instance models and their derivation is also presented, so that the instance models can be verified.

Assumptions

This section simplifies the original problem and helps in developing the theoretical models by filling in the missing information for the physical system. The assumptions refine the scope by providing more detail.

twoDMotion: The pendulum motion is two-dimensional (2D).

cartSys: A Cartesian coordinate system is used.

cartSysR: The Cartesian coordinate system is right-handed where positive \(x\)-axis and \(y\)-axis point right up.

yAxisDir: The direction of the \(y\)-axis is directed opposite to gravity.

startOrigin: The pendulum is attached to the origin.

Theoretical Models

This section focuses on the general equations and laws that SglPend is based on.

General Definitions

This section collects the laws and equations that will be used to build the instance models.

Detailed derivation of the \(x\)-component of velocity:

At a given point in time, velocity may be defined as

\[\boldsymbol{v}\text{(}t\text{)}=\frac{\,d\boldsymbol{p}\text{(}t\text{)}}{\,dt}\]

We also know the horizontal position

\[{p_{\text{x}}}={L_{\text{rod}}}\,\sin\left({θ_{p}}\right)\]

Applying this,

\[{v_{\text{x}}}=\frac{\,d{L_{\text{rod}}}\,\sin\left({θ_{p}}\right)}{\,dt}\]

\({L_{\text{rod}}}\) is constant with respect to time, so

\[{v_{\text{x}}}={L_{\text{rod}}}\,\frac{\,d\sin\left({θ_{p}}\right)}{\,dt}\]

Therefore, using the chain rule,

\[{v_{\text{x}}}=ω\,{L_{\text{rod}}}\,\cos\left({θ_{p}}\right)\]

Detailed derivation of the \(y\)-component of velocity:

At a given point in time, velocity may be defined as

\[\boldsymbol{v}\text{(}t\text{)}=\frac{\,d\boldsymbol{p}\text{(}t\text{)}}{\,dt}\]

We also know the vertical position

\[{p_{\text{y}}}=-{L_{\text{rod}}}\,\cos\left({θ_{p}}\right)\]

Applying this,

\[{v_{\text{y}}}=-\left(\frac{\,d{L_{\text{rod}}}\,\cos\left({θ_{p}}\right)}{\,dt}\right)\]

\({L_{\text{rod}}}\) is constant with respect to time, so

\[{v_{\text{y}}}=-{L_{\text{rod}}}\,\frac{\,d\cos\left({θ_{p}}\right)}{\,dt}\]

Therefore, using the chain rule,

\[{v_{\text{y}}}=ω\,{L_{\text{rod}}}\,\sin\left({θ_{p}}\right)\]

Detailed derivation of the \(x\)-component of acceleration:

Our acceleration is:

\[\boldsymbol{a}\text{(}t\text{)}=\frac{\,d\boldsymbol{v}\text{(}t\text{)}}{\,dt}\]

Earlier, we found the horizontal velocity to be

\[{v_{\text{x}}}=ω\,{L_{\text{rod}}}\,\cos\left({θ_{p}}\right)\]

Applying this to our equation for acceleration

\[{a_{\text{x}}}=\frac{\,dω\,{L_{\text{rod}}}\,\cos\left({θ_{p}}\right)}{\,dt}\]

By the product and chain rules, we find

\[{a_{\text{x}}}=\frac{\,dω}{\,dt}\,{L_{\text{rod}}}\,\cos\left({θ_{p}}\right)-ω\,{L_{\text{rod}}}\,\sin\left({θ_{p}}\right)\,\frac{\,d{θ_{p}}}{\,dt}\]

Simplifying,

\[{a_{\text{x}}}=-ω^{2}\,{L_{\text{rod}}}\,\sin\left({θ_{p}}\right)+α\,{L_{\text{rod}}}\,\cos\left({θ_{p}}\right)\]

Detailed derivation of the \(y\)-component of acceleration:

Our acceleration is:

\[\boldsymbol{a}\text{(}t\text{)}=\frac{\,d\boldsymbol{v}\text{(}t\text{)}}{\,dt}\]

Earlier, we found the vertical velocity to be

\[{v_{\text{y}}}=ω\,{L_{\text{rod}}}\,\sin\left({θ_{p}}\right)\]

Applying this to our equation for acceleration

\[{a_{\text{y}}}=\frac{\,dω\,{L_{\text{rod}}}\,\sin\left({θ_{p}}\right)}{\,dt}\]

By the product and chain rules, we find

\[{a_{\text{y}}}=\frac{\,dω}{\,dt}\,{L_{\text{rod}}}\,\sin\left({θ_{p}}\right)+ω\,{L_{\text{rod}}}\,\cos\left({θ_{p}}\right)\,\frac{\,d{θ_{p}}}{\,dt}\]

Simplifying,

\[{a_{\text{y}}}=ω^{2}\,{L_{\text{rod}}}\,\cos\left({θ_{p}}\right)+α\,{L_{\text{rod}}}\,\sin\left({θ_{p}}\right)\]

Detailed derivation of force on the pendulum:

\[\boldsymbol{F}=m\,{a_{\text{x}}}=-\boldsymbol{T}\,\sin\left({θ_{p}}\right)\]

Detailed derivation of force on the pendulum:

\[\boldsymbol{F}=m\,{a_{\text{y}}}=\boldsymbol{T}\,\cos\left({θ_{p}}\right)-m\,\boldsymbol{g}\]

Detailed derivation of the angular frequency of the pendulum:

Consider the torque on a pendulum defined in TM:NewtonSecLawRotMot. The force providing the restoring torque is the component of weight of the pendulum bob that acts along the arc length. The torque is the length of the string \({L_{\text{rod}}}\) multiplied by the component of the net force that is perpendicular to the radius of the arc. The minus sign indicates the torque acts in the opposite direction of the angular displacement:

\[\boldsymbol{τ}=-{L_{\text{rod}}}\,m\,\boldsymbol{g}\,\sin\left({θ_{p}}\right)\]

So then

\[\boldsymbol{I}\,α=-{L_{\text{rod}}}\,m\,\boldsymbol{g}\,\sin\left({θ_{p}}\right)\]

Therefore,

\[\boldsymbol{I}\,\frac{\,d\frac{\,d{θ_{p}}}{\,dt}}{\,dt}=-{L_{\text{rod}}}\,m\,\boldsymbol{g}\,\sin\left({θ_{p}}\right)\]

Substituting for \(\boldsymbol{I}\)

\[m\,{L_{\text{rod}}}^{2}\,\frac{\,d\frac{\,d{θ_{p}}}{\,dt}}{\,dt}=-{L_{\text{rod}}}\,m\,\boldsymbol{g}\,\sin\left({θ_{p}}\right)\]

Crossing out \(m\) and \({L_{\text{rod}}}\) we have

\[\frac{\,d\frac{\,d{θ_{p}}}{\,dt}}{\,dt}=-\left(\frac{\boldsymbol{g}}{{L_{\text{rod}}}}\right)\,\sin\left({θ_{p}}\right)\]

For small angles, we approximate sin \({θ_{p}}\) to \({θ_{p}}\)

\[\frac{\,d\frac{\,d{θ_{p}}}{\,dt}}{\,dt}=-\left(\frac{\boldsymbol{g}}{{L_{\text{rod}}}}\right)\,{θ_{p}}\]

Because this equation, has the same form as the equation for simple harmonic motion the solution is easy to find. The angular frequency

\[Ω=\sqrt{\frac{\boldsymbol{g}}{{L_{\text{rod}}}}}\]

Detailed derivation of the period of the pendulum:

The period of the pendulum can be defined from the general definition for the equation of angular frequency

\[Ω=\sqrt{\frac{\boldsymbol{g}}{{L_{\text{rod}}}}}\]

Therefore from the data definition of the equation for angular frequency, we have

\[T=2\,π\,\sqrt{\frac{{L_{\text{rod}}}}{\boldsymbol{g}}}\]

Data Definitions

This section collects and defines all the data needed to build the instance models.

Instance Models

This section transforms the problem defined in the problem description into one which is expressed in mathematical terms. It uses concrete symbols defined in the data definitions to replace the abstract symbols in the models identified in theoretical models and general definitions.

Detailed derivation of angular displacement:

When the pendulum is displaced to an initial angle and released, the pendulum swings back and forth with periodic motion. By applying Newton’s second law for rotational motion, the equation of motion for the pendulum may be obtained:

\[\boldsymbol{τ}=\boldsymbol{I}\,α\]

Where \(\boldsymbol{τ}\) denotes the torque, \(\boldsymbol{I}\) denotes the moment of inertia and \(α\) denotes the angular acceleration. This implies:

\[-m\,\boldsymbol{g}\,\sin\left({θ_{p}}\right)\,{L_{\text{rod}}}=m\,{L_{\text{rod}}}^{2}\,\frac{\,d\frac{\,d{θ_{p}}}{\,dt}}{\,dt}\]

And rearranged as:

\[\frac{\,d\frac{\,d{θ_{p}}}{\,dt}}{\,dt}+\frac{\boldsymbol{g}}{{L_{\text{rod}}}}\,\sin\left({θ_{p}}\right)=0\]

If the amplitude of angular displacement is small enough, we can approximate \(\sin\left({θ_{p}}\right)={θ_{p}}\) for the purpose of a simple pendulum at very small angles. Then the equation of motion reduces to the equation of simple harmonic motion:

\[\frac{\,d\frac{\,d{θ_{p}}}{\,dt}}{\,dt}+\frac{\boldsymbol{g}}{{L_{\text{rod}}}}\,{θ_{p}}=0\]

Thus the simple harmonic motion is:

\[{θ_{p}}\left(t\right)={θ_{i}}\,\cos\left(Ω\,t\right)\]

Data Constraints

The Data Constraints Table shows the data constraints on the input variables. The column for physical constraints gives the physical limitations on the range of values that can be taken by the variable. The uncertainty column provides an estimate of the confidence with which the physical quantities can be measured. This information would be part of the input if one were performing an uncertainty quantification exercise. The constraints are conservative to give the user of the model the flexibility to experiment with unusual situations. The column of typical values is intended to provide a feel for a common scenario.

Input Data Constraints

Properties of a Correct Solution

The Data Constraints Table shows the data constraints on the output variables. The column for physical constraints gives the physical limitations on the range of values that can be taken by the variable.

Output Data Constraints

Requirements

This section provides the functional requirements, the tasks and behaviours that the software is expected to complete, and the non-functional requirements, the qualities that the software is expected to exhibit.

Functional Requirements

This section provides the functional requirements, the tasks and behaviours that the software is expected to complete.

Input-Values: Input the values from Tab:ReqInputs.

Verify-Input-Values: Check the entered input values to ensure that they do not exceed the data constraints. If any of the input values are out of bounds, an error message is displayed and the calculations stop.

Calculate-Angular-Position-Of-Mass: Calculate the following values: \(θ\) and \({θ_{p}}\) (from IM:calOfAngularDisplacement).

Output-Values: Output \({L_{\text{rod}}}\) (from IM:calOfAngularDisplacement).

Required Inputs following FR:Input-Values

Non-Functional Requirements

This section provides the non-functional requirements, the qualities that the software is expected to exhibit.

Correctness: The outputs of the code have the properties of a correct solution.

Portability: The code shall be portable to multiple environments, particularly Windows, Mac OSX, and Linux.

Traceability Matrices and Graphs

The purpose of the traceability matrices is to provide easy references on what has to be additionally modified if a certain component is changed. Every time a component is changed, the items in the column of that component that are marked with an “X” should be modified as well. Tab:TraceMatAvsA shows the dependencies of the assumptions on each other. Tab:TraceMatAvsAll shows the dependencies of the data definitions, theoretical models, general definitions, instance models, requirements, likely changes, and unlikely changes on the assumptions. Tab:TraceMatRefvsRef shows the dependencies of the data definitions, theoretical models, general definitions, and instance models on each other. Tab:TraceMatAllvsR shows the dependencies of the requirements and goal statements on the data definitions, theoretical models, general definitions, and instance models.

Traceability Matrix Showing the Connections Between Assumptions and Other Assumptions

Traceability Matrix Showing the Connections Between Assumptions and Other Items

Traceability Matrix Showing the Connections Between Items and Other Sections

Traceability Matrix Showing the Connections Between Requirements, Goal Statements and Other Items

The purpose of the traceability graphs is also to provide easy references on what has to be additionally modified if a certain component is changed. The arrows in the graphs represent dependencies. The component at the tail of an arrow is depended on by the component at the head of that arrow. Therefore, if a component is changed, the components that it points to should also be changed. Fig:TraceGraphAvsA shows the dependencies of assumptions on each other. Fig:TraceGraphAvsAll shows the dependencies of data definitions, theoretical models, general definitions, instance models, requirements, likely changes, and unlikely changes on the assumptions. Fig:TraceGraphRefvsRef shows the dependencies of data definitions, theoretical models, general definitions, and instance models on each other. Fig:TraceGraphAllvsR shows the dependencies of requirements and goal statements on the data definitions, theoretical models, general definitions, and instance models. Fig:TraceGraphAllvsAll shows the dependencies of dependencies of assumptions, models, definitions, requirements, goals, and changes with each other.

For convenience, the following graphs can be found at the links below:

• TraceGraphAvsA
• TraceGraphAvsAll
• TraceGraphRefvsRef
• TraceGraphAllvsR
• TraceGraphAllvsAll

Values of Auxiliary Constants

There are no auxiliary constants.

References

[1]: Hibbeler, R. C. Engineering Mechanics: Dynamics. Pearson Prentice Hall, 2004. Print.

[2]: Koothoor, Nirmitha. A Document Driven Approach to Certifying Scientific Computing Software. McMaster University, Hamilton, ON, Canada: 2013. Print.

[3]: Parnas, David L. and Clements, P. C. “A rational design process: How and why to fake it.” IEEE Transactions on Software Engineering, vol. 12, no. 2, Washington, USA: February, 1986. pp. 251–257. Print.

[4]: Smith, W. Spencer and Koothoor, Nirmitha. “A Document-Driven Method for Certifying Scientific Computing Software for Use in Nuclear Safety Analysis.” Nuclear Engineering and Technology, vol. 48, no. 2, April, 2016. http://www.sciencedirect.com/science/article/pii/S1738573315002582. pp. 404–418.

[5]: Smith, W. Spencer and Lai, Lei. “A new requirements template for scientific computing.” Proceedings of the First International Workshop on Situational Requirements Engineering Processes - Methods, Techniques and Tools to Support Situation-Specific Requirements Engineering Processes, SREP’05. Edited by PJ Agerfalk, N. Kraiem, and J. Ralyte, Paris, France: 2005. pp. 107–121. In conjunction with 13th IEEE International Requirements Engineering Conference,

[6]: Smith, W. Spencer, Lai, Lei, and Khedri, Ridha. “Requirements Analysis for Engineering Computation: A Systematic Approach for Improving Software Reliability.” Reliable Computing, Special Issue on Reliable Engineering Computation, vol. 13, no. 1, February, 2007. https://doi.org/10.1007/s11155-006-9020-7. pp. 83–107.

[7]: Wikipedia Contributors. Acceleration. June, 2019. https://en.wikipedia.org/wiki/Acceleration.

[8]: Wikipedia Contributors. Cartesian coordinate system. June, 2019. https://en.wikipedia.org/wiki/Cartesian_coordinate_system.

[9]: Wikipedia Contributors. Velocity. June, 2019. https://en.wikipedia.org/wiki/Velocity.