SE _ Mo d u le _ 2 :

Software Req ui re m e n t s
Analysis and M o de l i ng
Compiled By:
Ms. Priti Rumao
Content

• Requirement Engineering
• Requirement Modeling
• Data flow diagram
• Scenario based model
• Software Requirement Specification document format(IEEE)
Requirement Engineering
• To ensure that specified system properly meets the customer’s needs and satisfies the customer’s expectations, a solid
requirements engineering process is the best solution.

• Requirements engineering provides the appropriate mechanism for understanding what the customer wants,
analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously,
validating the specification, and managing the requirements as they are transformed into an operational system.

• The requirements engineering process can be described in five distinct steps:

• requirements elicitation
• requirements analysis and negotiation
• requirements specification
• system modeling
• requirements validation
• requirements management
Requirement Engineering (Cont…)
• Requirement Elicitation:

• Sommerville and Sawyer suggest a set of detailed guidelines for requirements elicitation, which are summarized in the following
steps:

• Assess the business and technical feasibility for the proposed system.

• Identify the people who will help specify requirements and understand their organizational bias.

• Define the technical environment (e.g., computing architecture, operating system, telecommunications needs) into which the system
or product will be placed.

• Identify “domain constraints” (i.e., characteristics of the business environment specific to the application domain) that limit the
functionality or performance of the system or product to be built.

• Define one or more requirements elicitation methods (e.g., interviews, focus groups, team meetings).

• Solicit participation from many people so that requirements are defined from different points of view; be sure to identify the
rationale for each requirement that is recorded.

• Identify ambiguous requirements as candidates for prototyping.

• Create usage scenarios to help customers/users better identify key requirements.

Requirement Engineering (Cont…)
• Requirements analysis and negotiation:

• Analysis categorizes requirements and organizes them into related subsets; explores each requirement in relationship to
others; examines requirements for consistency, omissions, and ambiguity; and ranks requirements based on the needs of
customers/users.

• As the requirements analysis activity commences, the following questions are asked and answered:

• Is each requirement consistent with the overall objective for the system/product?

• Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of
technical detail that is inappropriate at this stage?

• Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the
system?

• Is each requirement bounded and unambiguous?

• Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement?

• Do any requirements conflict with other requirements?

Requirement Engineering (Cont…)

• Requirements analysis and negotiation:

• Is each requirement achievable in the technical environment that will house the system or product?
• Is each requirement testable, once implemented?
• Customers, users and stakeholders are asked to rank requirements and then discuss conflicts in priority.
• Risks associated with each requirement are identified and analyzed.
• Rough guestimates of development effort are made and used to assess the impact of each requirement on
project cost and delivery time.
• Using an iterative approach, requirements are eliminated, combined, and/or modified so that each party
achieves some measure of satisfaction.
Requirement Engineering (Cont…)
• Requirements specification:
• The System Specification is the final work product produced by the system and requirements engineer.
• It serves as the foundation for hardware engineering, software engineering, database engineering, and
human engineering.
• It describes the function and performance of a computer-based system and the constraints that will govern
its development.
• The specification bounds each allocated system element.
• The System Specification also describes the information (data and control) that is input to and output from
the system.
• A specification can be a written document, a graphical model, a formal mathematical model, a collection of
usage scenarios, a prototype, or any combination of these.
Requirement Engineering (Cont…)
• System Modelling:

• In order to fully specify what is to be built, there is a need of a meaningful model, a blueprint or three-dimensional rendering.

• It is important to evaluate the system’s components in relationship to one another, to determine how requirements fit into this
picture, and to assess the “aesthetics” of the system as it has been conceived.

• Requirements Validation:

• The work products produced as a consequence of requirements engineering are assessed for quality during a validation step.

• Requirements validation examines the specification to ensure that all system requirements have been stated unambiguously;
that inconsistencies, omissions, and errors have been detected and corrected; and that the work products conform to the
standards established for the process, the project, and the product.

• The primary requirements validation mechanism is the formal technical review. The review team includes system engineers,
customers, users, and other stakeholders who examine the system specification looking for errors in content or interpretation,
areas where clarification may be required, missing information, inconsistencies, conflicting requirements, or unrealistic
(unachievable) requirements.
Requirement Engineering (Cont…)
• Requirements Management:
• Requirements management is a set of activities that help the project team to identify, control, and track
requirements and changes to requirements at any time as the project proceeds.

• Once requirements have been identified, traceability tables are developed. Each traceability table relates
identified requirements to one or more aspects of the system or its environment. Among many possible
traceability tables are the following:

• Features traceability table: Shows how requirements relate to important customer observable system/product
features.

• Source traceability table: Identifies the source of each requirement.

• Dependency traceability table: Indicates how requirements are related to one another.
• Subsystem traceability table: Categorizes requirements by the subsystem(s) that they govern.
• Interface traceability table: Shows how requirements relate to both internal and external system interfaces.
Requirement Engineering (Cont…)
• Before software development is started, it becomes quite essential to understand and document the exact requirement of the customer.

• Experienced members of the development team carry out this job. They are called as analysts.

• The analyst starts requirements gathering and analysis activity by collecting all information from the customer which could be used to
develop the requirements of the system.

• He then analyzes the collected information to obtain a clear and thorough understanding of the product to be developed, with a view to
remove all ambiguities and inconsistencies from the initial customer perception of the problem.

• The following basic questions pertaining to the project should be clearly understood by the analyst in order to obtain a good grasp of the
problem:

• What is the problem?

• Why is it important to solve the problem?

• What are the possible solutions to the problem?

• What exactly are the data input to the system and what exactly are the data output by the system?

• If there are external software or hardware with which the developed software has to interface, then what exactly would the data
interchange formats with the external system be?
Requirement Modeling
• Requirements Modeling:

• Requirements modeling in software engineering is essentially the planning stage of a software application or system. Generally, the
process will begin when a business or an entity (for example, an educational institution) approaches a software development team to
create an application or system from scratch or update an existing one.

• Requirements modeling comprises several stages, or 'patterns': scenario-based modeling, data modeling, flow-oriented modeling,
class-based modeling and behavioral modeling. Each of these stages/patterns examines the same problem from a different perspective.

• Identifying Requirements:

• Requirements in this context are the conditions that a proposed solution or application must meet in order to solve the business
problem.

• Identifying requirements is not an exclusively technical process, and initially involves all the stakeholders, like the representatives of the
entity that has commissioned the software project, who may not necessarily be from a technical background, as well as the software
developers, who are not necessarily the technical team.

• Together, they discuss and brainstorm about the problem, and decide what functions the proposed application or system must perform
in order to solve it.
Requirement Modeling (Cont…)

• Functional vs. Non-Functional Requirements:

• A functional requirement specifies something that the application or system should do. Often, this is defined
as a behavior of the system that takes input and provides output. For example, a traveler fills out a form in an
airline's mobile application with his/her name and passport details (input), submits the form, and the
application generates a boarding pass with the traveler's details (output).
• Non-functional requirements, sometimes also called quality requirements, describe how the system should
be, as opposed to what it should do. Non-functional requirements of a system include performance (e.g.,
response time), maintainability and scalability, among many others. In the airline application example, the
requirement that the application must display the boarding pass after a maximum of five seconds from the
time the traveler presses the 'submit' button would be a non-functional requirement.
Requirement Modeling (Cont…)

• Requirement modeling strategies:

• Following are the requirement modeling strategies:
• Flow Oriented Modeling
• Class-based Modeling
• Scenario-based Modeling
• Behavior-based Modeling
Flow Oriented Modeling
• It shows how data objects are transformed by processing the function. The Flow oriented elements are:
Requirement Modeling (Cont…)
• Requirement modeling strategies: (Cont…)
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.
Requirement Modeling (Cont…)
• Requirement modeling strategies: (Cont…)
Behavior-based Modeling:
• It represents the behavior of the system.
• The state diagram in behavior-based modeling is a sequential specification of the behavior.
• 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.
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.
Requirement Modeling (Cont…)
• Requirement modeling strategies: (Cont…)
Class-based Modeling:

• 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.
Requirement Modeling (Cont…)
• Requirement modeling strategies: (Cont…)
Class-based Modeling:

• 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 behavior 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.
Requirement Modeling (Cont…)
• Requirement modeling strategies: (Cont…)
Class-based Modeling:
• 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.
Requirement Modeling (Cont…)
• Requirement modeling strategies: (Cont…)
Behavioral patterns 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.
Requirement Modeling (Cont…)
Scenario-based modeling:
• While developing a computer based system, the customer satisfaction cab be done by presenting him the
scenario based models during the software design process.
• The scenario based modeling can be done by developing the scenarios in the form of use cases, activity
diagram and swim lane diagrams.
• The use case diagram intended to capture the interaction between producer and consumer of the system. All
the required functionalities can be exposed by creating the use case diagrams.
• Activity Diagram: The activity diagram is a graphical representation for representing the flow of interaction
within specific scenarios. It is similar to a flow chart in which various activities that can be performed in the
system are represented. This diagram must be read from top to bottom. It consists of forks and branches. The
fork is used to remember that many activities can be parallel carried out. This diagram also consists of merge,
where multiple branches get combined.
Requirement Modeling (Cont…)

Scenario-based modeling:
• Swim lane Diagram: The activity diagram shows various activities performed, but it does not tell you who is
responsible for these activities. In swim lane diagram the activity diagram is partitioned according to the class
who is responsible for carrying out these activities.
• Use case diagram: Use case diagram is the primary form of system/software requirements for a new software
program underdeveloped. Use cases specify the expected behavior (what), and not the exact method of
making it happen (how). Use cases once specified can be denoted both textual and visual representation (i.e.
use case diagram). A key concept of use case modeling is that it helps us design a system from the end user's
perspective. It is an effective technique for communicating system behavior in the user's terms by specifying
all externally visible system behavior.
Requirement Modeling (Cont…)

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.
Requirement Modeling (Cont…)

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.