Unit II: Software Specification - Software Engineering - BCA Notes (Pokhara University)

Breaking

Friday, September 6, 2019

Unit II: Software Specification - Software Engineering

Introduction of Software Specification:

Software Specification or Software Requirements Specification (SRS) is a detailed description of a software system to be developed with its functional and non-functional requirements. The SRS is developed based on the agreement between customer and contractors. It may include the use cases of how a user is going to interact with the software system. The software requirement specification document consists of all necessary requirements required for project development. To develop the software system we should have a clear understanding of Software system. To achieve this we need to continue communication with customers to gather all requirements.

Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

A good SRS defines how Software System will interact with all internal modules, hardware, and communication with other programs and human user interactions with a wide range of real-life scenarios. Using the Software requirements specification (SRS) document on Quality Assurance lead managers to create a test plan. It is very important that testers must be cleared with every detail specified in this document in order to avoid faults in test cases and its expected results. It is highly recommended to review or test SRS documents before start writing test cases and making any plan for testing.

Various Purposes Served By SRS Are:

1. Feedback:

Provides feedback, which ensures the user that the organization (which develops the software) understands the issues or problems to be solved and the software behaviour necessary to address those problems.

2. Decompose Problem Into Components:

Organizes the information and divides the problem into its component parts in an orderly manner.

3. Validation:

Uses validation strategies applied to the requirements to acknowledge that requirements are stated properly.

4. Input to Design:

Contains sufficient detail in the functional system requirements to devise a design solution.

5. Basis For Agreement Between The User And The Organization:

Provides a complete description of the functions to be performed by the system. In addition, it helps the users to determine whether the specified requirements are accomplished.

6. Reduce The Development Effort:

Enables developers to consider user requirements before the designing of the system commences. As a result, 'rework' and inconsistencies in the later stages can be reduced.

7. Estimating Costs And Schedules:

Determines the requirements of the system and thus enables the developer to have a 'rough' estimate of the total cost and schedule of the project.

The Usage of Software Specification:

Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

A Statement of the User Requirements or Needs:

A good set of user requirements are needed for any project, especially computer system projects, to be successful. This is where many projects fail, in that they do not specify correctly what the system should do. In fact, many systems have just been given a deadline for delivery, a budget to spend, and a vague notion of what it should do.
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

The Root of This Problem Is:

a) Computer systems developers rarely have good ideas of how a business runs and should run, compared with a business user.
b) Business users have little idea of what a computer system could achieve for them.

As a result paralysis sets in and business management time is concentrated on meeting timescales and budgets, rather than what is going to be delivered.

A requirement for a computer system specifies “What we want or desire from a system”. For a business, in particular, this is, "What we want or desire from a system, which we believe will deliver us a business advantage".

This advantage need not just be a reduction in costs, in fact, many systems justified on a reduction in operating costs, fail to deliver as low skilled but relatively cheap staff, have to be replaced by high skilled, and more expensive staff. The advantage can be a reduction in time to process something, which will lead to a reduction in costs, or being able to better use the unique knowledge base belonging to a business.

As we start to specify what we want or desire, we hit up against the technical language of requirements. Fear not, this is quite straightforward:
a) Functional requirements - are what we want a system to do.
b) Non-functional requirements - are restrictions on the types of solutions that will meet the functional requirements.
c) Design objectives - Are the guides to use in selecting a solution.

A Statement of the Interface between the Machine and the Control Environment:

In HMI (Human Machine Interface), the interactions are basically of two types, i.e., human to machine and machine to human. Since HMI technology is ubiquitous, the interfaces involved can include motion sensors, keyboards and similar peripheral devices, speech-recognition interfaces and any other interaction in which information is exchanged using sight, sound, heat and other cognitive and physical modes are considered to be part of HMIs.
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

Although considered as a standalone technological area, HMI technology can be used as an adapter for other technologies. The basis of building HMIs largely depends on the understanding of human physical, behavioural and mental capabilities. In other words, ergonomics forms the principles behind HMIs. Apart from enhancing the user experience and efficiency, HMIs can provide unique opportunities for applications, learning and recreation. In fact, HMI helps in the rapid acquisition of skills for users. A good HMI is able to provide realistic and natural interactions with external devices.

The advantages provided by incorporating HMIs include error reduction, increased system and user efficiency, improved reliability and maintainability, increased user acceptance and user comfort, reduction in training and skill requirements, reduction in physical or mental stress for users, reduction in task saturation, increased economy of production and productivity, etc.

Touchscreens and membrane switches can be considered as examples of HMIs. HMI technology is also widely used in virtual and flat displays, pattern recognition, Internet and personal computer access, data input for electronic devices, and information fusion.

Professional bodies like GEIA and ISO provide standards and guidelines applicable to human-machine interface technology.

A Statement of the Requirement for the Implementation:

System Implementation uses the structure created during architectural design and the results of system analysis to construct system elements that meet the stakeholder requirements and system requirements developed in early life cycle phases. These system elements are then integrated to form intermediate aggregates and finally the complete System-Of-Interest (SOI).
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

Implementation is the process that actually yields the lowest-level system elements in the system hierarchy (system breakdown structure). System elements are made, bought, or reused. Production involves the hardware fabrication processes of forming, removing, joining, and finishing, the software realization processes of coding and testing, or the operational procedures development processes for operators' roles. If implementation involves a production process, a manufacturing system which uses the established technical and management processes may be required.

The purpose of the implementation process is to design and create (or fabricate) a system element conforming to that element’s design properties and/or requirements. The element is constructed employing appropriate technologies and industry practices. This process bridges the system definition processes and the integration process. Figure below portrays how the outputs of system definition relate to the system implementation, which produces the implemented (system) elements required to produce aggregates and the System of Interest.
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

A Reference Point During Product Maintenance:

The technical meaning of maintenance involves functional checks, servicing, repairing or replacing of necessary devices, equipment, machinery, building infrastructure and supporting utilities in industrial, business, governmental, and residential installations. Over time, this has come to include multiple wordings that describe various cost-effective practices to keep equipment operational; these activities take place either before or after a failure.
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

Together, these functions are referred to as Maintenance, Repair and Overhaul (MRO). MRO is also used for Maintenance, repair and operations. Over time, the terminology of maintenance and MRO has begun to become standardized. 

The United States Department of Defence Uses The Following Definitions:

a) Any activity such as tests, measurements, replacements, adjustments, and repairs intended to retain or restore a functional unit in or to a specified state in which the unit can perform its required functions.

b) All action is taken to retain material in a serviceable condition or to restore it to serviceability. It includes inspections, testing, servicing, and classification as to serviceability, repair, rebuilding, and reclamation.

c) All supply and repair action is taken to keep a force in condition to carry out its mission.

d) The routine recurring work required to keep a facility (plant, building, structure, ground facility, utility system or other real property) in such condition that it may be continuously used, at its original or designed capacity and efficiency for its intended purpose.

Maintenance is strictly connected to the utilization stage of the product or technical system, in which the concept of maintainability must be included. In this scenario, maintainability is considered as the ability of an item, under stated conditions of use, to be retained in or restored to a state in which it can perform its required functions, using prescribed procedures and resources.

A Legal Contract:

The core purpose of a software development agreement (a legal contract) is to regulate the production of software. Very often, it will also contain a licence allowing the customer to use the software. Quite often, it will include maintenance and support services as well.
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

We also, draft bespoke development agreements for both software developers and their customers. In addition to the matters dealt with in a software licence, the development agreement will usually need to cover most of the following matters.

a) Specification: Will the software be specified in detail at the outset, or will a rough specification be elaborated during the development process?

b) Development Process: Different styles of the development process (e.g. waterfall, spiral, agile) require different levels of developer-customer interaction, and therefore legal terms. Version control, consultations, and changes to both specification and pricing will usually, need to be dealt with here.

c) Testing: What testing must the developer perform before delivering the software? What about the customer? What are the consequences of test failures?

d)Customer cooperation: What does the customer need to provide to the developer to ensure that the development process runs smoothly? Will customer default here have an impact upon billing?

e) Intellectual Property: Will any copyright is assigned to the customer, or will it merely be licensed?

Software Specification Qualities:

NASA’s Software Assurance Technology Center has identified the following as the ten important criteria that any SRS (Software Requirements Specifications) should satisfy:
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

1. Complete:

A complete requirements specification must precisely define all the real-world situations that will be encountered and the capability’s responses to them. It must not include situations that will not be encountered or unnecessary capability features.

2. Consistent:

System functions and performance level must be compatible and the required quality features (reliability, safety, security, etc.) must not contradict the utility of the system. For example, the only aircraft that is totally safe is one that cannot be started, contains no fuel or other liquids, and is securely tied down.

3. Correct:

The specification must define the desired capability’s real-world operational environment, its interface to that environment and its interaction with that environment. It is the real-world aspect of requirements that is the major source of difficulty in achieving specification correctness. The real-world environment is not well known for new applications and for mature applications the real world keeps changing. The Y2K problem with the transition from the year 1999 to the year 2000 is an example of the real world moving beyond an application’s specified requirements.

4. Modifiable:

Related concerns must be grouped together and unrelated concerns must be separated. Requirements document must have a logical structure to be modifiable.

5. Ranked:

Ranking specification statements according to stability and/or importance is established in the requirements document’s organization and structure. The larger and more complex the problem addressed by the requirements specification, the more difficult the task is to design a document that aids rather than inhibits understanding.

6. Testable:

A requirement specification must be stated in such a manner that one can test it against pass/fail or quantitative assessment criteria, all derived from the specification itself and/or reference information. Requiring that a system must be “easy” to use is subjective and therefore is not testable.

7. Traceable:

Each requirement stated within the SRS document must be uniquely identified to achieve traceability. Uniqueness is facilitated by the use of a consistent and logical scheme for assigning identification to each specification statement within the requirements document.

8. Unambiguous:

A statement of a requirement is unambiguous if it can only be interpreted one way. This perhaps is the most difficult attribute to achieve using natural language. The use of weak phrases or poor sentence structure will open the specification statement to misunderstandings.

9. Valid:

To validate a requirements specification all the project participants, managers, engineers and customer representatives must be able to understand, analyse and accept or approve it. This is the primary reason that most specifications are expressed in natural language.

10. Verifiable:

In order to be verifiable, requirement specifications at one level of abstraction must be consistent with those at another level of abstraction. Most, if not all, of these attributes, are subjective and a conclusive assessment of the quality of a requirements specification requires review and analysis by technical and operational experts in the domain addressed by the requirements.

Classification of Software Specification Styles:

1. Informal:

Not formal, more flexible, leave more decision space to an implementer.

2. Formal:

Use of formalisms make specifications precise and augmented automatic verification possibilities. They have syntax, their semantics fall in one domain and they are able to be used to take useful information.

3. Semi-Formal:

Often we use notation which semantics has not been defined so precisely (example: UML)

4. Operational:

Describe the system in terms of the expected behaviour generally providing a model. Describes the operational detail. Example: DFD, FSM (Finite State Machine), etc.

5. Descriptive Specification:

Describe the system in terms of desired properties for the system. Example: collaboration diagram, sequence diagram, etc.

Verification and Validation of Software Specification:

The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase is known as verification.

Verification is a static practise of verifying documents, design, code and program. It includes all the activities associated with producing high-quality software: inspection, design analysis and specification analysis. It is a relatively objective process.

Verification will help to determine whether the software is of high quality, but it will not ensure that the system is useful. Verification is concerned with whether the system is well-engineered and error-free.
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

Methods of Verification: Static Testing

a. Walkthrough
b. Inspection
c. Review

Verification is the process of checking that the software meets the specification.  “Did I build what I need?”

The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements is known as validation.

Validation is the process of evaluating the final product to check whether the software meets the customer expectations and requirements. It is a dynamic mechanism of validating and testing the actual product.

Methods of Validation: Dynamic Testing

a. Testing
b. End Users

Validation is the process of checking whether the specification captures the customer’s needs. “Did I build what I said I would?”

Difference:

Verification
Validation
The verifying process includes checking documents, design, code, and program.
It is a dynamic mechanism of testing and validating the actual product.
It does not involve executing the code.
It always involves executing the code.
Verification uses methods like reviews, walkthroughs, inspections, and desk- checking etc.
It uses methods like Black Box Testing, White Box Testing, and non-functional testing.
Whether the software conforms to specification is checked.
It checks whether the software meets the requirements and expectations of a customer.
It finds bugs early in the development cycle.
It can find bugs that the verification process cannot catch.
Target is application and software architecture, specification, complete design, high level, and database design etc.
Target is an actual product.
QA team does verification and make sure that the software is as per the requirement in the SRS document.
With the involvement of testing team validation is executed on software code.
It comes before validation.
It comes after verification.

Types of Software Specification:

Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

Performance Specifications:

Specifications describe the product without mentioning the manufacturer. Requirements might include meeting a specific wind load, colour range, or structural loading. These types of specifications required results with the criteria to verifying compliance without unnecessary limiting the method of achieving those results. Examples might be specifications for fabricated exit stairway or fire-resistant joint sealants. Simply stated, the specifications specify an end result.

Descriptive Specifications:

Specification formed as a detailed written description of the required properties of a product, materials, or equipment and the workmanship required for its proper installation. They define the exact properties of materials and methods of installation without using proprietary product names.

Prescriptive Specifications:

A prescriptive specification is one that includes clauses for means and methods of construction and composition of the concrete mix or a traditional plaster mix rather than defining performance requirements.

Reference Specifications:

These specifications refer to an authority, trade association, government or other industry reference standards; provide a generic description in terms of an assembly meeting those standards, such as ASTM, TCNA, ANSI, etc.

Proprietary Specifications:

There are both Closed and Open versions of the Proprietary specifications defined as follows:
a. Closed: Only one Product is named and no substitutions would be accepted.
b. Open: One product may be named as a basis of design, with multiple other products named as acceptable products or list the proprietary brand names of one or more manufacturers. 

Operational Specifications:

A Functional Specification or Operational Specification in systems engineering and software development is a document that specifies the functions that a system or component must perform.

The documentation typically describes what is needed by the system user as well as requested properties of inputs and outputs (e.g. of the software system). A functional specification is a more technical response to a matching requirements document, e.g. the Product Requirements Document "PRD". Thus it picks up the results of the requirements analysis stage. On more complex systems multiple levels of functional specifications will typically nest to each other, e.g. on the system level, on the module level and on the level of technical details.

1. Data Flow Diagram:

Data flow diagram is a graphical representation of the flow of data in an information system. It is capable of depicting incoming data flow, outgoing data flow and stored data. The DFD does not mention anything about how data flows through the system.

There is a prominent difference between DFD and Flowchart. The flowchart depicts the flow of control in program modules. DFDs depict the flow of data in the system at various levels. DFD does not contain any control or branch elements.

Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

Types of DFD:
Data Flow Diagrams are either Logical or Physical.
a. Logical DFD:

This type of DFD concentrates on the system process, and flow of data in the system. For example in a Banking software system, how data is moved between different entities.

b. Physical DFD:
This type of DFD shows how the data flow is actually implemented in the system. It is more specific and close to the implementation.

DFD Components:
DFD can represent Source, destination, storage and flow of data using the following set of components:

a) Entities: Entities are the source and destination of information data. Entities are represented by a rectangles with their respective names.

b) Process: Activities and action were taken on the data are represented by Circle or Round-edged rectangles.

c) Data Storage: There are two variants of data storage - it can either be represented as a rectangle with the absence of both smaller sides or as an open-sided rectangle with only one side missing.

d) Data Flow: Movement of data is shown by pointed arrows. Data movement is shown from the base of the arrow as its source towards the head of the arrow as the destination.
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine
Levels of DFD:
a. Level 0:
Highest abstraction level DFD is known as Level 0 DFD, which depicts the entire information system as one diagram concealing all the underlying details. Level 0 DFDs are also known as context level DFDs.
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine
b. Level 1:
The Level 0 DFD is broken down into more specific, Level 1 DFD. Level 1 DFD depicts basic modules in the system and flow of data among various modules. Level 1 DFD also mentions basic processes and sources of information.

Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine
c. Level 2:
At this level, DFD shows how data flows inside the modules mentioned in Level 1.

Higher level DFDs can be transformed into more specific lower-level DFDs with deeper level of understanding unless the desired level of specification is achieved.

Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

2. UML Diagram:

UML stands for Unified Modelling Language. It’s a rich language to model software solutions, application structures, system behaviour and business processes. UML is intentionally processed independent and could be applied in the context of different processes. Still, it is most suitable for use case driven, iterative and incremental development processes. An example of such a process is the Rational Unified Process (RUP).

UML is not complete and it is not completely visual. Given some UML diagram, we can't be sure to understand depicted part or behaviour of the system from the diagram alone. Some information could be intentionally omitted from the diagram, some information represented on the diagram could have different interpretations, and some concepts of UML have no graphical notation at all, so there is no way to depict those on diagrams.

For example, the semantics of multiplicity of actors and multiplicity of use cases on use case diagrams are not defined precisely in the UML specification and could mean either concurrent or successive usage of use cases.

Types of UML Diagrams:
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

1. Class Diagram:
Class diagrams are the main building block of any object-oriented solution. It shows the classes in a system, attributes, and operations of each class and the relationship between each class.

In most modelling tools, a class has three parts. Name at the top, attributes in the middle and operations or methods at the bottom. In a large system with many related classes, classes are grouped together to create class diagrams. Different relationships between classes are shown by different types of arrows.
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

2. Component Diagram:
A component diagram displays the structural relationship of components of a software system. These are mostly used when working with complex systems with many components. Components communicate with each other using interfaces. The interfaces are linked using connectors. The image below shows a component diagram.

Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine
3. Deployment Diagram:
A deployment diagram shows the hardware of our system and the software in that hardware. Deployment diagrams are useful when our software solution is deployed across multiple machines with each having a unique configuration. Below is an example deployment diagram.

Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine
4. Object Diagram:
Object Diagrams, sometimes referred to as Instance diagrams are very similar to class diagrams. Like class diagrams, they also show the relationship between objects but they use real-world examples. They show how a system will look like at a given time. Because there is data available in the objects, they are used to explain complex relationships between objects.
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine
5. Package Diagram:
As the name suggests a package diagram shows the dependencies between different packages in a system. Check out this wiki article to learn more about the dependencies and elements found in package diagrams.

Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

6. Profile Diagram:
Profile diagram is a new diagram type introduced in UML 2. This is a diagram type that is very rarely used in any specification.
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

7. Composite Structure Diagram:
Composite structure diagrams are used to show the internal structure of a class.
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine
8. Use Case Diagram:
As the most known diagram type of the behavioural UML types, Use case diagrams give a graphic overview of the actors involved in a system, different functions needed by those actors and how these different functions interact. It’s a great starting point for any project discussion because we can easily identify the main actors involved and the main processes of the system.
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

9. Activity Diagram:
Activity diagrams represent workflows in a graphical way. They can be used to describe the business workflow or the operational workflow of any component in a system. Sometimes activity diagrams are used as an alternative to State machine diagrams.
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

10. State Machine Diagram:
State machine diagrams are similar to activity diagrams, although notations and usage change a bit. They are sometimes known as state diagrams or state chart diagrams as well. These are very useful to describe the behaviour of objects that act differently according to the state they are in at the moment. The State machine diagram below shows the basic states and actions.
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine
11. Sequence Diagram:
Sequence diagrams in UML show how objects interact with each other and the order those interactions occur. It’s important to note that they show the interactions for a particular scenario. The processes are represented vertically and interactions are shown as arrows. This article explains the purpose and the basics of Sequence diagrams.

Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine
12. Communication Diagram:
In UML 1 they were called collaboration diagrams. Communication diagrams are similar to sequence diagrams, but the focus is on messages passed between objects. The same information can be represented using a sequence diagram and different objects.

Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine
13. Interaction Overview Diagram:
Interaction overview diagrams are very similar to activity diagrams. While activity diagrams show a sequence of processes, Interaction overview diagrams show a sequence of interaction diagrams. They are a collection of interaction diagrams and the order they happen. As mentioned before, there are seven types of interaction diagrams, so anyone of them can be a node in an interaction overview diagram. 
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine
14. Timing Diagram:
Timing diagrams are very similar to sequence diagrams. They represent the behaviour of objects in a given time frame. If it’s only one object, the diagram is straightforward. But, if there is more than one object is involved, a Timing diagram is used to show interactions between objects during that time frame.
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

3. Finite State Machine:

A finite state machine (sometimes called a finite state automaton) is a computation model that can be implemented with hardware or software and can be used to simulate sequential logic and some computer programs. Finite-state automata generate regular languages. Finite state machines can be used to model problems in many fields including mathematics, artificial intelligence, games, and linguistics.

Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

There are two types of finite state machines (FSMs): deterministic finite-state machines often called deterministically finite automata, and non-deterministic finite state machines often called non-deterministic finite automata. There are slight variations in ways that state machines are represented visually, but the ideas behind them stem from the same computational ideas. By definition, deterministic finite automata recognize, or accept, regular languages, and a language is regular if a deterministic finite automaton accepts it.

FSMs are usually taught using languages made up of binary strings that follow a particular pattern. Both regular and non-regular languages can be made out of binary strings. An example of a binary string language is the language of all strings that have a 0 as the first character. In this language, 001, 010, 0, and 01111 are valid strings (along with many others), but strings like 111, 10000, 1, and 11001100 (along with many others) are not in this language.

We can walk through the finite state machine diagram to see what kinds of strings the machine will produce, or we can feed it a given input string and verify whether or not there exists a set of transitions we can take to make the string (ending in an accepting state).

Deterministic Finite Automata:
A deterministic finite automaton (DFA) is described by a five-element tuple: (Q, Σ, δ, q0​, F).
Q = a finite set of states
Σ = a finite, nonempty input alphabet
δ = a series of transition functions
q0 ​= the starting state
F = the set of accepting states

There must be exactly one transition function for every input symbol in Σ from each state. DFAs can be represented by diagrams of this form:
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine
Non-Deterministic Finite Automata:
Similar to a DFA, a nondeterministic finite automaton (NDFA or NFA) is described by a five-element tuple: (Q, Σ, δ, q0, F).
Q = a finite set of states
Σ = a finite, nonempty input alphabet
δ = a series of transition functions
q0​ = the starting state
F = the set of accepting states

Unlike DFAs, NDFAs are not required to have transition functions for every symbol in Σ, and there can be multiple transition functions in the same state for the same symbol. Additionally, NDFAs can use null transitions, which are indicated by ϵ. Null transitions allow the machine to jump from one state to another without having to read a symbol. An NDFA accepts a string x if there exists a path that is compatible with that string that ends in an accept state. NDFAs can be represented by diagrams of this form:
Software Specification, Introduction of Software Specification, Various Purposes Served By SRS, The Usage of Software Specification, A Statement of the User Requirements or Needs, A Statement of the Interface between the Machine and the Control Environment, A Statement of the Requirement for the Implementation, A Reference Point during Product Maintenance, A Legal Contract, Software Specification Qualities, Classification of Software Specification Styles, Verification and Validation of Software Specification, Types of Software Specification, Performance Specifications, Descriptive Specifications, Prescriptive Specifications, Reference Specifications, Proprietary Specifications, Operational Specifications, Data Flow Diagram, UML Diagram, Types of UML Diagrams, Finite State Machine

No comments:

Post a Comment

If you have any doubt, then don't hesitate to drop comments.