Software Requirement Modeling

Requirement modeling strategies

Following are the requirement modeling strategies:
1. Flow Oriented Modeling
2. Class-based Modeling

1. Flow Oriented Modeling

It shows how data objects are transformed by processing the function.

The Flow oriented elements are:

i. Data flow model
  • It is a graphical technique. It is used to represent information flow.
  • The data objects are flowing within the software and transformed by processing the elements.
  • The data objects are represented by labeled arrows. Transformation are represented by circles called as bubbles.
  • DFD shown in a hierarchical fashion. The DFD is split into different levels. It also called as 'context level diagram'.
ii. Control flow model
  • Large class applications require a control flow modeling.
  • The application creates control information instated of reports or displays.
  • The applications process the information in specified time.
  • An event is implemented as a boolean value.
    For example, the boolean values are true or false, on or off, 1 or 0.
iii. Control Specification
  • A short term for control specification is CSPEC.
  • It represents the behaviour of the system.
  • The state diagram in CSPEC is a sequential specification of the behaviour.
  • The state diagram includes states, transitions, events and activities.
  • State diagram shows the transition from one state to another state if a particular event has occurred.
iv. Process Specification
  • A short term for process specification is PSPEC.
  • The process specification is used to describe all flow model processes.
  • The content of process specification consists narrative text, Program Design Language(PDL) of the process algorithm, mathematical equations, tables or UML activity diagram.

2. Class-based Modeling

  • Class based modeling represents the object. The system manipulates the operations.
  • The elements of the class based model consist of classes and object, attributes, operations, class – responsibility - collaborator (CRS) models.
Classes
Classes are determined using underlining each noun or noun clause and enter it into the simple table.

Classes are found in following forms:
  • External entities: The system, people or the device generates the information that is used by the computer based system.
  • Things: The reports, displays, letter, signal are the part of the information domain or the problem.
  • Occurrences or events: A property transfer or the completion of a series or robot movements occurs in the context of the system operation.
  • Roles: The people like manager, engineer, salesperson are interacting with the system.
  • Organizational units: The division, group, team are suitable for an application.
  • Places: The manufacturing floor or loading dock from the context of the problem and the overall function of the system.
  • Structures: The sensors, computers are defined a class of objects or related classes of objects.
Attributes
Attributes are the set of data objects that are defining a complete class within the context of the problem.
For example, 'employee' is a class and it consists of name, Id, department, designation and salary of the employee are the attributes.

Operations
The operations define the behaviour of an object.

The operations are characterized into following types:
  • The operations manipulate the data like adding, modifying, deleting and displaying etc.
  • The operations perform a computation.
  • The operation monitors the objects for the occurrence of controlling an event.
CRS Modeling
  • The CRS stands for Class-Responsibility-Collaborator.
  • It provides a simple method for identifying and organizing the classes that are applicable to the system or product requirement.
  • Class is an object-oriented class name. It consists of information about sub classes and super class.
  • Responsibilities are the attributes and operations that are related to the class.
  • Collaborations are identified and determined when a class can achieve each responsibility of it. If the class cannot identify itself, then it needs to interact with another class.

Behavioral patterns for requirement modeling

Behavioral model shows the response of software to an external event.

Steps for creating behavioral patterns for requirement modeling as follows:
  • Evaluate all the use cases to completely understand the sequence, interaction within the system.
  • Identify the event and understand the relation between the specific event.
  • Generate a sequence for each use case.
  • Construct a state diagram for the system.
  • To verify the accuracy and consistency review the behavioral model.

Software Requirement Specification (SRS)

  • The requirements are specified in specific format known as SRS.
  • This document is created before starting the development work.
  • The software requirement specification is an official document.
  • It shows the detail about the performance of expected system.
  • SRS indicates to a developer and a customer what is implemented in the software.
  • SRS is useful if the software system is developed by the outside contractor.
  • SRS must include an interface, functional capabilities, quality, reliability, privacy etc.

Characteristics of SRS

  • The SRS should be complete and consistence.
  • The modification like logical and hierarchical must be allowed in SRS.
  • The requirement should be easy to implement.
  • Each requirement should be uniquely identified.
  • The statement in SRS must be unambiguous means it should have only one meaning.
  • All the requirement must be valid for the specified project.
▲