Requirements Modeling in Software Projects

Requirements gathering in software engineering is process of identifying requirements & real-world use-case of software system to be built. This modeling process consist of various type of modeling technique such as scenario based, class based, behavior oriented, flow oriented or data oriented modeling.

Scenario-Based Modeling

This is typically the first stage of requirements modeling where top-level requirements are collected; although there is no hard and fast rule to initiate modeling with this phase.

That is the phase where top-level use-cases are identified and described. The use case diagrams give overview of interactions of various actors with the system. This is preliminary user interactions with system, which shows how uses are going to use the system, which sort out any high-level ambiguities.

“Although the success of a computer-based system or product is measured in many ways, user satisfaction resides at the top of the list. If you understand how end users (and other actors) want to interact with a system, your software team will be better able to properly characterize requirements and build meaningful analysis and design models. Hence, requirements modeling with UML begins with the creation of scenarios in the form of use cases, activity diagrams, and swimlane diagrams.” Pressman (2015).

From the requirements engineering stand point, this phase of modeling provides two ways to document requirements, inception & elicitation. In some cases use-case diagram becomes the prime candidate for requirements.

Class-Based Modeling

Class based modeling enables identify system entities and operation in the form of classes, objects and relationship more like object-oriented terminology.

“Class-based modeling represents the objects that the system will manipulate, the operations (also called methods or services) that will be applied to the objects to effect the manipulation, relationships (some hierarchical) between the objects, and the collaborations that occur between the classes that are defined. The elements of a class-based model include classes and objects, attributes, operations, class responsibility collaborator (CRC) models, collaboration diagrams, and packages.” Pressman (2015).

The class identification process starts with identifying classes from description of the project, certain grammar entities helps categorize the classes. The very first thing to looks for in the description is people or devices that would potential create data in the system such as Customer, store manager, cashier and deliver person for Pizza system.

Behavioral Patterns-Based Modeling

Behavior based requirements modeling relies on system behaviors, and this analysis can be viewed as whole system objects interacting or collaborating with each other, all those use-case models collectively represents behavior model.

Behavior modeling helps in defining the software application as whole system, and paints blueprint of system showing various objects interacting with each other within system or its sub-systems.

The behavior modeling enables the internal view of system’s used-case, which makes it easier to identify any flaws in overall requirements. The creation of Behavior models is incremental or iterative process which may lead to changes to other models as system evolves. These changes typically due to any deficiency or change in the overall flow, which can impact class-based models and scenario-based models because you might need to change the classes as new behaviors identified or might have to change the entire scenario.

The behavior models typically consist of various types of UML diagrams, such as sequence diagrams and interaction diagrams each of them entails the detail flow of use-case. The sequence diagram in behavioral model represents the sequence of events or operations happens in response to an action of actor within the system.

Communication diagrams also plays important role in defining system behaviors as it shows message passing within and across the system, and group of objects interacting with each other within system.

Data-Oriented Modeling

Data oriented modeling deals with data aspect of the system and visualizes the system as data operated and processed within the system.

“If software requirements include the need to create, extend, or interface with a database or if complex data structures must be constructed and manipulated, the software team may choose to create a data model as part of overall requirements modeling. A software engineer or analyst defines all data objects that are processed within the system, the relationships between the data objects, and other information that is pertinent to the relationships. The entity-relationship diagram (ERD) addresses these issues and represents all data objects that are entered, stored, transformed, and produced within an application.” Pressman (2015).  

This kind of modeling represent every object in form of data which is composed of various properties. Each data items represents different objects in system with various characteristics and states of each object. Object can be anything belongs to system and it holds data only, and there isn’t any reference to its operations etc.

Flow-oriented Modeling

Flow oriented modeling focuses on workflow of overall system, and it acts like supplement to use-case models. Activity diagrams and swim-lane diagrams helps in most situations in this phase of modeling.

Activity diagram for the system gives nice visual for interactions to the system, each action or operation is represented in form of activity and the actors either internal or external to the system perform these activities to show control flow of system.

The activity diagram also show parallelism within the system, which can be used to optimize the pipeline of activities to perform optimally, for example mostly the activities of the system are synchronous one activity leads to another one only if it is completed.

But sometimes it can be parallelizing to scale the system and some activities can be converted to behave asynchronously, in order to make system efficient and scalable.