Software Engineering

Unit II: Modeling-I

(In this section we are going to see various actions performed in Communication
Activity such as inception, elicitation, elaboration, negotiation, specification and
validation and also Task Set of each action. These six actions are collectively
called as Requirements Engineering)

Requirements Engineering
• The broad spectrum of tasks and techniques that lead to an understanding of
requirements is called requirement engineering.
• Requirements engineering builds a bridge to design and construction
• Requirements engineering provides the appropriate mechanism for
understanding what customer wants, analyzing needs, negotiating and
specifying solution, managing requirements.
• It encompasses the seven distinct tasks:
o Inception
o Elicitation
o Elaboration
o Negotiation
o Specification
o Validation
o Requirements management
• All strive to define what the customer wants
• All serve to establish a solid foundation for the design and construction of
the software

Inception:

• From where the software engineering activities begins.

• During inception, the requirements engineer asks a set of questions to
establish…
o A basic understanding of the problem
o The people who want a solution
 o The nature of the solution that is desired
o The effectiveness of preliminary communication and collaboration
between the customer and the developer
• Through these questions, the requirements engineer needs to…
o Identify the stakeholders
o Recognize multiple viewpoints
o Work toward collaboration
o Break the ice and initiate the communication

Elicitation:

• Requirements elicitation also called requirements gathering

• Eliciting requirements is difficult because of
o Problems of scope in identifying the boundaries of the system or
specifying too much technical detail rather than overall system
objectives
o Problems of understanding what is wanted, what the problem
domain is, and what the computing environment can handle
(Information that is believed to be "obvious" is often omitted)
o Problems of volatility because the requirements change over time
• Elicitation may be accomplished through two activities
o Collaborative requirements gathering
o Quality function deployment

Collaborative requirements gathering

• Basic Guidelines of Collaborative Requirements Gathering

o Meetings are conducted and attended by both software engineers,
customers, and other interested stakeholders
o Rules for preparation and participation are established
o An agenda is suggested that is formal enough to cover all important
points but informal enough to encourage the free flow of ideas
o A "facilitator" (customer, developer, or outsider) controls the meeting
o A "definition mechanism" is used such as work sheets, flip charts,
wall stickers, electronic bulletin board, chat room, or some other
virtual forum
 o The goal is to identify the problem, propose elements of the solution,
negotiate different approaches, and specify a preliminary set of
solution requirements

Quality function deployment

• This is a technique that translates the needs of the customer into technical
requirements for software

• It identifies three types of requirements

– Normal requirements: These requirements are the objectives and

goals stated for a product or system during meetings with the
customer

– Expected requirements: These requirements are implicit to the

product or system and may be so fundamental that the customer does
not explicitly state them

– Exciting requirements: These requirements are for features that go

beyond the customer's expectations and prove to be very satisfying
when present

Elaboration Task

• During elaboration, the software engineer takes the information obtained

during inception and elicitation and begins to expand and refine it

• Elaboration focuses on developing a refined technical model of software

functions, features, and constraints

• It is an analysis modeling task

– Use cases are developed

– Domain classes are identified along with their attributes and

relationships

– State machine diagrams are used to capture the life on an object

The end result is an analysis model that defines the functional, informational, and
behavioral domains of the problem

• Elements of the Analysis Model

o Scenario-based elements

Describe the system from the user's point of view using
scenarios that are depicted in use cases and activity diagrams
o Class-based elements

Identify the domain classes for the objects manipulated by the
actors, the attributes of these classes, and how they interact with
one another; they utilize class diagrams to do this
o Behavioral elements

Use state diagrams to represent the state of the system, the
events that cause the system to change state, and the actions that
are taken as a result of a particular event; can also be applied to
each class in the system
o Flow-oriented elements

Use data flow diagrams to show the input data that comes into a
system, what functions are applied to that data to do
transformations, and what resulting output data are produced

Negotiation Task

• During negotiation, the software engineer reconciles the conflicts between

what the customer wants and what can be achieved given limited business
resources

• Requirements are ranked (i.e., prioritized) by the customers, users, and other
stakeholders

• Risks associated with each requirement are identified and analyzed

• Rough guesses 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
Specification Task

• A specification is the final work product produced by the requirements

engineer

• It is normally in the form of a software requirements specification

• It serves as the foundation for subsequent software engineering activities

• It describes the function and performance of a computer-based system and

the constraints that will govern its development

• It formalizes the informational, functional, and behavioral requirements of

the proposed software in both a graphical and textual format

Validation Task

• During validation, the work products produced as a result of requirements

engineering are assessed for quality

• The specification is examined to ensure that

– all software requirements have been stated unambiguously

– inconsistencies, omissions, and errors have been detected and

corrected

– the work products conform to the standards established for the

process, the project, and the product

• The formal technical review serves as the primary requirements validation

mechanism

– Members include software engineers, customers, users, and other

stakeholders

Requirements Management Task

• During requirements management, the project team performs a set of

activities to identify, control, and track requirements and changes to the
requirements at any time as the project proceeds
 • Each requirement is assigned a unique identifier

• The requirements are then placed into one or more traceability tables

• These tables may be stored in a database that relate features, sources,

dependencies, subsystems, and interfaces to the requirements

• A requirements traceability table is also placed at the end of the software

requirements specification

Requirements Modeling
• Requirements modeling use a combination of text and diagrammatic forms
to describe requirements.
• To understand easily and to review for correctness, completeness, and
consistency.
• Requirements modeling is a “Elaboration phase” of the requirements
engineering
• The requirement model – actually a set of models and is first technical
representation of a system.

• Three primary objectives

– To describe what the customer requires

– To establish a basis for the creation of a software design

– To define a set of requirements that can be validated once the software

is built

Requirements Modeling Approaches

• Structured analysis
– Considers data and the processes that transform the data as separate
entities
– Data is modeled in terms of only attributes and relationships (but no
operations)
 – Processes are modeled to show the 1) input data, 2) the
transformation that occurs on that data, and 3) the resulting output
data
oriented analysis
• Object-oriented
– Focuses on the definition of classes and the manner in which they
collaborate with one another to fulfill customer requiremen
requirements

Scenario-based modeling

• Scenario-based
based modeling represents the system from the user’s point of view
• Scenario-based
based elements of the requirements model are often the first part of
the model
• Requirements modeling with UML begins with the creation of scenarios in
the form of:
o Use case text or stories
o Use case diagrams
o Activity diagrams
o Swim lane diagrams
Class-based Modeling:

• Class-based modeling represents the objects that the system will manipulate
• The operations (also called methods) that will be applied to the objects to
effect the manipulation
• Relationship between objects
• Collaboration between the classes
• The elements of class-based model include:
o Class Diagram
o Analysis Packages
o CRC Models
o Collaboration Diagrams

Behavioral Modeling

• The behavioral Modeling indicates how software will respond to external

events or stimuli.
• Identify events found within the use cases and implied by the attributes in
the class diagrams
• Build a state diagram for each class, and if useful, for the whole software
system
• Identifying Events in Use Cases
o An event occurs whenever an actor and the system exchange
information
o An event is NOT the information that is exchanged, but rather the fact
that information has been exchanged
• The behavioral model includes:
o State diagram
o Sequence diagram
Flow-oriented modeling

• It represents the functional elements of the system and how they transform
data as it moves through the system
• Information is transformed as it flow through a computer-based system
• The system accepts input in variety of forms and applies functions to
transform it, and produces output in a variety of forms
• The input may be control signal, a series of number, a packet of information
• The output may be LED light
• Flow-oriented modeling includes:
o Data –Flow diagram
o Data model or data structure
o Process narratives or specification
o Control-flow diagram or control specification

Data Modeling Concepts

• If software requirements include the need to create, extend, or interface with

a database, the software must choose to create a data model as part of overall
requirements modeling.
• Data objects:
o A data object is a representation of any composite information that is
processed or understood by software.
o A data object can be an external entity or a thing or an occurrence, or
an event, or a role, a place, a structure
o A person or a car can be viewed as a data object in the sense that
either can be defined in terms of a set of attributes.

Data object: Car

Make Model ID Body type Color Owner

Hyundai i20 AB123 Sedan Red RSP
Chevy Corvette X425 Sports Blue CCD
BMW 750iL Xz765 Coupe White BLF
• Data Attributes:
o Attributes name a data object
o Describe its characteristics, and in some cases, make reference to
another object.
• Relationships
o Relationships indicate the manner in which data objects are connected
to one another.