Module 2 - Software Requirement Analysis & Modeling

Requirement Engineering: Feasibility & Elicitation

Requirement Engineering is the process of defining, documenting and maintaining the requirements. It involves gathering and defining the services provided by the system, as well as the constraints under which it operates and is developed. A requirement mandates that something be accomplished, transformed, produced, or provided. Making design decisions without understanding all constraints results in a system that fails to meet customer expectations. Furthermore, the cost of correcting errors increases as the design process advances; an error detected in the maintenance phase is 20 times as costly to fix as an error detected in the coding stage.

1. Feasibility Study

Feasibility Studies aim to objectively and rationally uncover the strengths and weaknesses of the existing business or proposed venture, the opportunities and threats, the resources required, and ultimately the prospects for success. The two criteria to judge feasibility are the cost required and the value to be attained.

• Technical Feasibility: Determines whether the company has the capability in terms of software, hardware, personnel, and expertise to handle the completion of the project.
• Operational Feasibility: Analyzes the degree of providing service to requirements, how easy the product will be to operate and maintain after deployment, and overall usability.
• Economic Feasibility: Decides whether the necessary software can generate financial profits for an organization.
• Legal Feasibility: Analyzes the project from a legality point of view, including barriers like data protection acts, social media laws, licenses, and copyrights.
• Schedule Feasibility: Analyzes timelines and deadlines to determine how much time teams will take to complete the final project, ensuring the purpose of the project does not fail due to delays.

2. Requirements Elicitation

This is the process of discovering the requirements for a system by communicating with the customers, system users, and others who have a stake in the system development. The success of an elicitation technique depends on the maturity of the analyst, developers, users, and the customer involved.

3. Requirements Specification

The process by which a document is developed which clearly communicates the requirements. The requirements are captured and expressed in a software requirements specification (SRS).

4. Requirements Verification & Validation

The process of ensuring that the requirements and the SRS are in compliance with the needs of the clients and the system. Techniques include reviews, inspections, walkthroughs, and prototyping.

Requirement Engineering: Analysis & Specification

Requirements Analysis is the essential process of studying and analyzing the customer and stakeholder needs to arrive at a definition of software requirements. It involves refining and scrutinizing gathered requirements to make them consistent and unambiguous. This step is critical because customers may provide requirements that are impossible to implement due to dependencies, and business analysts might interpret needs differently than programmers would.

Activities Involved in Analyzing Requirements

• Problem Recognition: Fully understanding the main objective of the requirement, why it is needed, and if it adds value to solve business problems.
• Evaluation and Synthesis: Defining all necessary functions and data objects, evaluating data flow, understanding overall system behavior, discovering constraints, and establishing system interfaces.
• Modeling: Establishing functional and behavioral models after checking the system's function and behavior using a domain model (conceptual model).
• Specification: Developing the Software Requirement Specification (SRS) to specify functional and non-functional requirements.
• Review: Reviewing the developed SRS to check for improvements, refining it to increase quality.

Requirements Specification & Perspectives

Requirements are documented from two primary perspectives: User Requirements (statements in natural language plus diagrams of services and constraints, written for customers) and System Requirements (structured documents setting out detailed descriptions of functions and constraints, forming part of the contract).

Requirement Modeling

A model is a representation of some aspect of the system being built. Requirements modeling is an approach used in projects where the requirements keep on evolving throughout the project. Creating a model helps ensure the project's exact requirements are documented clearly, creates a strong foundation for the overall needs, clarifies and refines the design, and simplifies complex aspects of systems.

Models can be in a variety of graphical representations and forms, including structured approaches (like Entity Relationship Diagrams and Data Flow Diagrams) and Object-Oriented approaches (UML Diagrams such as Use Case, Class, Sequence, Collaboration, Activity, and State Diagrams).

The Requirements modeling action results in one or more of the following types of models, each examining the system from a different perspective:

Scenario Based Model (Use Cases & Activity)

Scenario-based elements depict how the user interacts with the system and the specific sequence of activities that occur as the software is used. The primary objective of scenario-based modeling is to look at a system from the user's perspective and produce a use case. It makes sense to start with this step as other requirements modeling stages will make reference to these use cases.

Unified Modeling Language (UML) & Use Case Diagrams

Requirement modeling with UML begins with the creation of scenarios in the form of use cases, activity diagrams, and swim lanes to develop the understanding of how the system would be used. Because a single diagram cannot capture the different elements of a system in its entirety, UML is made up of nine diagrams used to model a system at different points in its life cycle.

Use Case Diagrams are used to identify the primary elements and processes that form the system. When a system is analyzed to gather its functionalities, use cases are prepared and actors are identified.

Elements of a Use Case Diagram

A use case diagram consists of several fundamental elements that map out the system's behavior and its interacting external entities.

Relationships Between Use Cases

A relationship defines how use cases interact with one another. There are three primary types of relationships in a Use Case Diagram:

• 1. Generalization:
  • Represents an inheritance relationship between elements of the same type.
  • Has a parent-child relationship where the child use case enhances the parent use case.
  • Shown as a directed arrow with a triangle arrowhead pointing from the child to the parent.
• 2. Include (<<include>>):
  • Shows that the behavior of the included use case is part of the base (including) use case, helping to reuse common actions.
  • The base use case is incomplete without the included use case; it is mandatory, not optional.
  • Denoted by a dotted line with an arrowhead pointing from the parent use case to the child use case.
• 3. Extend (<<extend>>):
  • The child use case adds to the existing functionality and characteristics of the parent use case.
  • The extending use case is usually optional and conditionally triggered, while the parent use case must be meaningful and independent on its own.
  • Depicted with a dotted arrow where the tip points from the child to the parent use case.

Activity Diagram

An activity is a particular operation of the system, and an activity diagram is a behavioral diagram that depicts the behavior of a system. It portrays the control flow from a start point to a finish point, showing the various decision paths that exist while the activity is being executed. Instead of implementation details, it demonstrates the flow of control, emphasizing the condition of flow and the order in which it occurs (which can be sequential, branched, or concurrent). It is also termed an object-oriented flowchart.

Elements of an Activity Diagram

• Activity: The categorization of behavior into one or more actions. Activities are initiated at the initial node and terminated at the final node. Represented by a rounded rectangle.
• Initial & Final Activity: The Initial Activity (solid black circle) depicts the beginning of the set of actions. The Final Activity (solid black circle inside a hollow circle) is the stage where all control flows end.
• Decision Box & Merge: A Decision Box (diamond shape) makes sure that the control flow will follow only one path based on conditions. A Merge notation (also a diamond) merges two or more non-concurrent activities back into one control flow.
• Transition / Control Flow: Lines with arrowheads used to show the transition from one activity state to another.
• Guards: A statement written next to a decision node on an arrow (often in square brackets `[ ]`) that specifies the constraint to be adhered to while making the transition.
• Fork & Join: A Fork (rounded solid rectangular bar) splits the activity into two parts that execute concurrently without a decision. A Join notation (solid rectangular bar with multiple incoming edges and one outgoing edge) is used to support concurrent activities converging back into one.

How to Draw an Activity Diagram

An activity diagram is an enhancement of a flowchart that represents the workflow among various activities, encompassing unique skills like modeling concurrent flows. When drawing an activity diagram, the following rules should be followed:

• A meaningful name should be given to each and every activity.
• Identify all of the constraints and decision conditions.
• Acknowledge the activity associations and ensure the control flow is logical from the initial state to the final state.

Example: Activity Diagram for Railway Ticket Booking

Below is a practical example of an Activity Diagram illustrating the flow of a commuter booking a ticket (adapted from a ticket vending or booking system). It demonstrates the sequential flow, a decision node for payment types, and the merging of those paths to finalize the booking.

• Control Flow: The solid lines with arrows direct the user from providing trip info to processing the payment.
• Decision & Guards: After the payment info is processed, the flow reaches a Decision Box. The guards [pay with cash] and [pay with card] dictate which path the system will take.
• Merge: Once the card payment is authorized (or bypassed if paying with cash), the two paths converge at the Merge Node to continue the singular flow of dispensing the ticket.

Software Requirement Specification (SRS)

A Software Requirements Specification (SRS) is a document that describes what the software will do and how it will be expected to perform. It describes the functionality the product needs to fulfill all stakeholder (business, user) needs, providing a detailed overview of the software product, its parameters, goals, target audience, user interface, and hardware/software requirements. An SRS minimizes the time and effort required by developers and reduces the overall development cost.

Characteristics of a Good SRS

For an SRS to be effective and reliable, it must exhibit the following twelve characteristics:

SRS Document Format (IEEE Standard)

When writing an SRS, organizations often rely on standard outlines, such as the IEEE template, to ensure all critical details are captured systematically. The standard structure includes:

Section	Subsections & Details
1. Introduction	1.1 Purpose: Sets expectations and defines the product's goal. 1.2 Intended Audience & 1.3 Intended Use: Defines who accesses the SRS (developers, testers, stakeholders) and how. 1.4 Scope: Benefits, objectives, and overall business goals. 1.5 Definitions and Acronyms: Includes risk definitions for safety-critical teams.
2. Overall Description	2.1 User Needs: Defines primary/secondary users and buyers, detailing how they will use the product. 2.2 Assumptions and Dependencies: Lists factors impacting fulfillment, assumptions that could be false, and external software component dependencies.
3. System Features and Requirements	3.1 Functional Requirements: Essential requirements and risks to build the product. 3.2 External Interface Requirements: How the product interfaces with other users, hardware, software, or communications (critical for embedded systems). 3.3 System Features: Required features for the system to function. 3.4 Nonfunctional Requirements: Performance, safety, security, and quality constraints.

Data Flow Diagram (DFD)

A Data Flow Diagram (DFD) is a traditional visual representation of the information flows within a system. A neat and clear DFD can graphically depict the right amount of the system requirement, showing what kind of data will be input to the system and what data is received as the output. It can be manual, automated, or a combination of both. The objective of a DFD (also called a data flow graph or bubble chart) is to show the scope and boundaries of a system as a whole by illustrating where data comes from, where it goes, what changes the information, and where it is stored.

Elements of Data Flow Diagram

Data Flow Diagrams are composed of four basic symbols:

• External Entity (Source or Sink): Sharp-cornered rectangles (boxes) that represent sources of data to the system or destinations of data from the system (e.g., Doctor, Customer, Manager).
• Process: Rounded-cornered rectangles or circles/bubbles that represent an activity transforming or manipulating data (e.g., Grading System, Reservation System).
• Data Store: Open-sided rectangles indicating a repository of data where delayed data is at rest. Data can be read from or written to the store, but external entities cannot directly read or write to it, and two data stores cannot be directly connected by a data flow.
• Data Flow: A line with an arrow showing the movement of data into or out of a process or data store. A flow carries only one type of packet and is represented by the flow name.

Levels of DFD: Level 0 (Context Diagram)

An entire system is depicted by a single data flow diagram which gives the complete system overview, known as the context diagram. Successive expansion of processes is done to show the operations in detail, which is called levelling. Generally, the maximum level of DFD is 3 (Level 0, 1, and 2).

Level 0 DFD (Context Level Diagram) is the simplest DFD. The outermost level is concerned with how the system interacts with the outside world, representing the entire system as a single bubble with its relationships to external entities.

Levels of DFD: Level 1 DFD

In a 1-level DFD, the context diagram is decomposed into multiple bubbles/processes. The entire system is divided into modules, representing how data moves through different modules. This level highlights the main functions of the system and breaks down the high-level process of the 0-level DFD into subprocesses, providing a high-level view that identifies the major processes and data stores.

Levels of DFD: Level 2 DFD

A Level 2 DFD goes one step deeper into the parts of a 1-level DFD. Each process from level 1 is exploded even more into sub-processes, and this decomposition continues for each level as needed. It can be used to plan or record the specific, necessary details about the system's functioning, and the total number of levels possible depends entirely on the complexity of the system.