Chapter: Requirement Engineering

Requirements Engineering
 Requirement: A function, constraint or
other property that the system must
provide to fill the needs of the system’s
intended user(s)
 Engineering: implies that systematic and
repeatable techniques should be used
 Requirement Engineering means that
requirements for a product are defined,
managed and tested systematically
Requirements Engineering

 It is essential that the software engineering team

understand the requirements of a problem before
the team tries to solve the problem.
 In some cases requirements engineering may be
abbreviated, but it is never abandoned.
 RE is software engineering actions that start with
communication activity and continues into the
modeling activity.
 RE establishes a solid base for design and
construction. Without it, resulting software has a
high probability of not meeting customer needs.
Characteristics of a Good Requirement
 Clear and Unambiguous
 standard structure
 has only one possible interpretation
 Not more than one requirement in one sentence
 Correct
 A requirement contributes to a real need
 Understandable
 A reader can easily understand the meaning of the
requirement
 Verifiable
 A requirement can be tested
 Complete
 Consistent
 Traceable
Why is Getting Good Requirements
Hard?
 Stakeholders don’t know what they really
want.
 Stakeholders express requirements in their
own terms.
 Different stakeholders may have conflicting
requirements.
 Organisational and political factors may
influence the system requirements.
 The requirements change during the RE
process. New stakeholders may emerge
and the business environment change.
Requirements Engineering Tasks
 Inception —Establish a basic understanding of the problem
and the nature of the solution.
 Elicitation —Draw out the requirements from stakeholders.
 Elaboration (Highly structured)—Create an analysis model
that represents information, functional, and behavioral
aspects of the requirements.
 Negotiation—Agree on a deliverable system that is realistic
for developers and customers.
 Specification—Describe the requirements formally or
informally.
 Validation —Review the requirement specification for errors,
ambiguities, omissions, and conflicts.
 Requirements management —Manage changing
requirements.
Inception
 Inception— Ask “context-free”
questions that establish …
 Basic understanding of the problem
 The people who want a solution
 The nature of the solution that is desired,
and
 The effectiveness of preliminary
communication and collaboration
between the customer and the developer
Elicitation
 Elicitation - elicit requirements from customers,
users and others.
 Find out from customers, users and others
what the product objectives are
 what is to be done
 how the product fits into business needs,
and
 how the product is used on a day to day
basis
Why Requirement elicitation is
difficult?
 Problems of scope:
 The boundary of the system is ill-defined.
 Customers/users specify unnecessary technical detail that may confuse
rather than clarify objectives.
 Problem of understanding:
 Customers are not completely sure of what is needed.
 Customers have a poor understanding of the capabilities and limitations
of the computing environment.
 Customers don’t have a full understanding of their problem domain.
 Customers have trouble communicating needs to the system engineer.
 Customers omit detail that is believed to be obvious.
 Customers specify requirements that conflict with other requirements.
 Customers specify requirements that are ambiguous or not able to test.
 Problems of volatility:
 Requirement change over time.
Elaboration
 Focuses on developing a refined technical model of
software functions, features, and constraints using the
information obtained during inception and elicitation
 Create an analysis model that identifies data, function
and behavioral requirements.
 It is driven by the creation and refinement of user
scenarios that describe how the end-user will interact
with the system.
 Each event parsed into extracted.
 End result defines informational, functional and
behavioral domain of the problem
Negotiation
 Negotiation - agree on a deliverable system
that is realistic for developers and customers
 Requirements are categorized and organized
into subsets
 Relations among requirements identified
 Requirements reviewed for correctness
 Requirements prioritized based on customer
needs
 Negotiation about requirements, project cost
and project timeline.
 There should be no winner and no loser in
effective negotiation.
Specification
 Specification – Different things to different people.
 It can be –
 Written Document
 A set of graphical models,
 A formal mathematical models
 Collection of usage scenario.
 A prototype
 Combination of above.
 The Formality and format of a specification varies with
the size and the complexity of the software to be built.
 For large systems, written document, language
descriptions, and graphical models may be the best
approach.
 For small systems or products, usage scenarios
Validation
 Requirements Validation - formal technical
review mechanism that looks for
 Errors in content or interpretation
 Areas where clarification may be required
 Missing information
 Inconsistencies (a major problem when
large products or systems are engineered)
 Conflicting or unrealistic (unachievable)
requirements.
Requirement Management
 Set of activities that help project team to identify, control, and track
requirements and changes as project proceeds
Requirements begin with identification. Each requirement is
assigned a unique identifier. Once requirement have been identified,
traceability table are developed.
Traceability Table:
 Features traceability table - shows how requirements relate to
customer observable features
Source traceability table - identifies source of each requirement
Dependency traceability table - indicate relations among
requirements
Subsystem traceability table - requirements categorized by
subsystem
Interface traceability table - shows requirement relations to
internal and external interfaces
It will help to track, if change in one requirement will affect different
aspects of the system.
Initiating Requirements Engineering Process
 Identify stakeholders
 Stakeholder can be “anyone who benefits in a direct or indirect
way from the system which is being developed”
Ex. Business manager, project manager, marketing people,
software engineer, support engineer, end-users, internal-
external customers, consultants, maintenance engineer.
 Each one of them has different view of the system.
 Recognize multiple points of view
 Marketing group concern about feature and function to excite potential
market. To sell easily in the market.
 Business manager concern about feature built within budget and will be
ready to meet market.
 End user – Easy to learn and use.
 SE – product functioning at various infrastructure support.
 Support engineer – Maintainability of software.
Role of RE is to categorize all stakeholder information in a way that
there could be no inconsistent or conflict requirement with one
another
 Work toward collaboration
 RE identify areas of commonality (i.e. Agreed requirement) and
areas of conflict or inconsistency.
 It does not mean requirement defined by committee. It may
happened they providing just view of their requirement.
 Business manager or senior technologist may make final
decision.
 Asking the first questions
 Who is behind the request for this work?
 Who will use the solution?
 What will be the economic benefit of a successful
solution
 Is there another source for the solution that you need?
These questions will help – stakeholder interest in the software
& measurable benefit of successful implementation.
Asking the question
Next set of questions – better understanding of the
problem.
 What business problem (s) will this solution address?
 Describe business environment in which the solution will
be used?
 will performance or productivity issues affect the solution
is approached?
Final set of questions – Effectiveness of communication
 Are my questions relevant to the problem?
 Am I asking too many questions?
 Can anyone else provide additional information?
 should I be asking you anything else?
Eliciting Requirement
Approach for eliciting requirement:
 Collaborative Requirement Gathering
 Quality Function Deployment
 User Scenarios
 Elicitation Work Products
Collaborative Requirement
Gathering
 Meetings are attended by all interested stakeholders.
 Rules established for preparation and participation.
 Agenda should be formal enough to cover all important points, but
informal enough to encourage the free flow of ideas.
 A facilitator controls the meeting.
 A definition mechanism (blackboard, flip charts, etc.) is used.
 During the meeting:
 The problem is identified.
 Elements of the solution are proposed.
 Different approaches are negotiated.
 A preliminary set of solution requirements are obtained.
 The atmosphere is collaborative and non-threatening.
 Flow of event – Outline the sequence of events occurs
 Requirement gathering meeting ( initial meeting)
 During meeting
 Follow the meeting.
Collaborative requirement
gathering (contd.)
 In initial meeting, distribute “Product request” (defined by
stakeholder) to all attendee.
 Based on product request, each attendee is asked to
make
 List of objects (Internal or external system objects)
 List of services( Processes or functions)
 List of constraints ( cost, size, business rules) and
performance criteria( speed, accuracy) are developed.
 Collect lists from everyone and combined.
 Combined list eliminates redundant entries, add new
ideas , but does not delete anything.
 Objective is to develop a consensus list in each topic area
(objects, services, constraints and performance).
 Based on lists, team is divided into smaller sub-teams :
each works to develop mini-specification for one or more
entries on each of the lists.
Collaborative requirement
gathering (Contd.)
 Each sub-team the presents its mini-specification to
all attendees for discussion. Addition, deletion and
further elaboration are made.
 Now each team makes a list of validation criteria for
the product and present to team.
 Finally, one or more participants is assigned the
task of writing a complete draft specification.
Quality Function Deployment
 It is a technique that translate the needs of the customer into technical
requirement for software.
 Concentrates on maximizing customer satisfaction.
 QFD emphasizes – what is valuable to the customer and then deploys
these values throughout the engineering process.
Three types of requirement:
1. Normal Requirements – reflect objectives and goals stated for product. If
requirement are present in final products, customer is satisfied.
2. Expected Requirements – customer does not explicitly state them.
Customer assumes it is implicitly available with the system.
3. Exciting Requirements- Features that go beyond the customer’s
expectation.
During meeting with customer –
Function deployment determines the “value” of each function required of the
system.
Information deployment identifies data objects and events and also tied with
functions.
Task deployment examines the behavior of the system.
Value analysis determines the priority of requirements during these 3
deployments.
User Scenario
 It is difficult to move into more software engineering
activities until s/w team understands how these
functions and features will be used by diff. end-users.
 Developers and users create a set of usage threads for
the system to be constructed
 A use-case scenario is a story about how someone or
something external to the software (known as an actor)
interacts with the system.
 Describe how the system will be used
 Each scenario is described from the point-of-view of an “actor”—a
person or device that interacts with the software in some way
Elicitation Work Products
Elicitation work product will vary depending upon the size of
the system or product to be built.
 Statement of need and feasibility.
 Statement of scope.
 List of participants in requirements elicitation.
 Description of the system’s technical environment.
 List of requirements and associated domain constraints.
 List of usage scenarios.
 Any prototypes developed to refine requirements.
Software Prototype
 Prototype constructed for customer and developer
assessment.
 In some circumstances construction of prototype is
require in beginning of analysis. (To derive requirement
effectively)
Selecting Prototype Approach
1. Close ended (Throwaway Approach)
2. Open ended (Evolutionary Approach)
Close Ended – It serves as a rough demonstration of
requirement. It is then discarded, and the software
engineered using a different paradigm.
Open Ended - uses the prototype as the first part of an
analysis activity that will be continued into design and
construction. The prototype of the software is the first
evolution of the finished system.
 Approaches to prototyping

Evolutionary Delivered
prototyping system
Outline
Requirements
Throw-away Executable Prototype +
Prototyping System Specification
Evolutionary prototyping

Develop abstract Build prototype Use prototype

specification system system

Deliver YES System

system adequate?
Evolutionary prototyping
advantages
 Accelerated delivery of the system
 Rapid delivery and deployment are
sometimes more important than
functionality or long-term software
maintainability
 User engagement with the system
 Not only is the system more likely to
meet user requirements, they are more
likely to commit to the use of the system
Evolutionary prototyping problems
 Management problems
 Existing management processes assume a
waterfall model of development
 Specialist skills are required which may not be
available in all development teams
 Maintenance problems
 Continual change tends to corrupt system
structure so long-term maintenance is expensive
 Contractual problems
 Due to cost or time line agreed
 Throw-away prototyping
Outline Develop Evaluate Specify
requirements prototype prototype system

Reusable
components

Delivered
Develop Validate software
software system system
Throw-away prototyping
 Used to reduce requirements risk
 The prototype is developed from an initial
specification, delivered for experiment then
discarded
 The throw-away prototype should NOT be
considered as a final system
 Some system characteristics may have been
left out
 There is no specification for long-term
maintenance
 The system will be poorly structured and
difficult to maintain
Prototyping Methods and Tools
 A prototype must be developed rapidly so that the customer may assess results and
recommend changes.
3 methods are available:
1. Fourth Generation Techniques (4GT)
 4GT enable the software engineer to generate executable code quickly, they are ideal for
rapid prototyping.
 Ex. Tool for Database query language or reporting language.
2. Reusable software components
 To rapid prototyping is to assemble, rather than build, the prototype by using a set of
existing software components.
 Should maintain library for existing software components
 An existing software product can be used as a prototype for a "new, improved"
competitive product
3. Formal specification and prototyping environments
 Enable an analyst to interactively create language-based specifications of a system or
software,
 Invoke automated tools that translate the language-based specifications into executable
code,
 Enable the customer to use the prototype executable code to refine formal requirements.
Specification
 Mode of specification has much to do with the quality of
solution.
 If specification incomplete, inconsistent, or misleading
specifications have experienced the frustration and
confusion that invariably results.
Specification Principles: May be viewed as
representation process.
1. Separate functionality from implementation.
2. Develop a model of the desired behavior of a system.
3. Establish the context in which software operates by
specifying the manner.
4. Define the environment in which the system operates and
indicate how.
Specification Principles (cont.)
5. Create a cognitive model rather than a design or
implementation model. The cognitive model describes a
system as perceived by its user community.
6. The specifications must be tolerant of incompleteness
and augmentable.
7. Establish the content and structure of a specification in a
way that will enable it to be amenable to change.
Specification Representation
Representation format and content should be relevant to
the problem.
 For example, a specification for a manufacturing automation system might
use different symbology, diagrams and language than the specification for
a programming language compiler.
Information contained within the specification should be
nested (layered).
 Paragraph and diagram numbering schemes should indicate the level of
detail that is being presented.
 It is sometimes worthwhile to present the same information at different
levels of abstraction to aid in understanding.
Diagrams and other notational forms should be restricted
in number and consistent in use.
 Confusing or inconsistent notation, whether graphical or symbolic,
degrades understanding and fosters errors.
Representations should be revisable.
Software Requirements Specification
 It contains a complete information description, a detailed functional
description, a representation of system behavior, an indication of
performance requirements and design constraints, appropriate
validation criteria, and other information pertinent to requirements.
Format of SRS:
Introduction of the software requirements specification states the goals
and objectives of the software, describing it in the context of the
computer-based system.
Information content, flow, and structure are documented. Hardware,
software, and human interfaces are described for external system
elements and internal software functions.
Functional Description A processing narrative is provided for each
function, design constraints are stated and justified & performance
characteristics are stated
Behavioral Description operation of the software as a consequence of
external events and internally generated control characteristics.
Software Requirements Specification (Cont.)
Validation Criteria is probably the most important and, ironically,
the most often neglected section of the Software Requirements
Specification (SRS). Testing or validating each user-scenario.

Finally, the specification includes a Bibliography and Appendix.

The bibliography contains references to all documents that
relate to the software. The appendix contains information that
supplements the specifications
Specification Review
 A review of the SRS (and/or prototype) is conducted by
both the software developer and the customer.
 Conducted at a macroscopic level
 Ensure that specification is complete
 Consistent
 Accurate (Information, functional and behavioral
domain considered).
 Review becomes more detailed while examining
Information, functional and behavioral domain.
 Examining not only broad descriptions but the way in
which requirement worded.
E.g. Terms like “Vague ” (some, sometimes, often, usually)
should be flag by reviewer for further clarification.
Review (cont.)
 Once review is complete – SRS “signed off” by both
customer and developer. ( “contract” for software
development)
 Requests for changes in requirements after the
specification is finalized will not be eliminated.
 Change is an extension of software scope and
therefore can increase cost and/or delivery of product.
 During the review, changes to the specification may
be recommended.
 It can be extremely difficult to assess the global
impact of a change; that is, how a change in one
function affects requirements for other functions
Chapter : Analysis Modeling
Requirements Analysis
 Requirements analysis
 Specifies software’s operational characteristics
 Indicates software's interface with other system elements
 Establishes constraints that software must meet
 Requirements analysis allows the software engineer (called an analyst
or modeler in this role) to:
 Elaborate on basic requirements established during earlier
requirement engineering tasks
 Build models that depict user scenarios, functional activities,
problem classes and their relationships, system and class behavior,
and the flow of data as it is transformed.
 Throughout analysis modeling, the SE’s primary focus is on what not on
how.
 Analysis model and the requirements specification provide the
developer and the customer with means to assess quality once
software is built.
Analysis Modeling Principles
 Analysis methods are related by a set of operational principles:
1. The information domain of a problem must be represented and
understood.
2. The functions that are software performs must be defined.
3. The behavior of the software must be represented.
4. The models that depict information, function and behavior
must be partitioned in a manner that uncovers detail in a
layered fashion.
5. The analysis task should move from essential information
toward implementation detail.
Analysis Modeling Principles

1. Information domain encompasses that the data flow into

the system, out of the system and data stored.
2. Functions provide direct benefit to end-users and also
provide internal support for those features that are user
visible.
3. Behavior driven by its interaction with the external
environment.
E.g. Input provided by end-users, control data provided
by an external system, or monitoring data.
Analysis Modeling Principles
4. Key strategy of analysis model, divide complex problem
into sub-problem until each sub-problem is relatively
easy to understood. This concept is called partitioning.
5. The “essence” of the problem is described without any
consideration of how a solution will be implemented.
E.g. Video game requires that player “instruct”

Implementation detail (design model) indicates how the

essence will be implemented
E.g. Keyboard command might be typed or a joystick
used.
Analysis Model Objectives
Three Primary Objectives:
 Describe what the customer requires.
 Establish a basis for the creation of a software design.
 Devise a set of requirements that can be validated once the software is built.
 Its bridges the gap between a system-level description that describes
overall system functionality and a software design.
Guidelines :
 Graphics should be used whenever possible.
 Differentiate between the logical (essential) and physical
(implementation) considerations.
 Develop a way to track and evaluate user interfaces.
Analysis Model - A Bridge
Analysis Rules of Thumb
 The model should focus on requirements that are visible within
the problem or business domain. The level of abstraction
should be relatively high. – Don’t get bogged into the details.
 Each element of the analysis model should add to an overall
understanding of software requirements and provide insight
into the information domain, function and behavior of the
system.
 Delay consideration of infrastructure and other non-functional
models until design.
 Minimize coupling throughout the system. - If level of
interconnectedness is high, efforts should be made to reduce
it.
 Assured that the analysis model provides value to all
stakeholders. – business stakeholder should validate
requirement, Designers should use the model as a basis for
design.
 Keep the model as simple as it can be. - No need to use
additional diagram and use notations.
Elements of Analysis model
 There are two approaches
1. Structured Analysis:-
 Data objects are modeled in a way that defines
their attributes and relationships.
 Processes that manipulate data objects in a
manner that shows how they transform data as
data objects flow through the systems.
2. Object Oriented Analysis :-
 Focuses on the definition of classes and the
manner in which they collaborate with one
another.
 UML is predominantly object oriented.
Elements of Analysis model
Scenario Based diagram

 Scenario-based elements
 Use-case—How external actors interact with the
system (use-case diagrams; detailed templates)
 Functional—How software functions are
processed in the system (flow charts; activity
diagrams)
 Activity – can be represented at many diff. level
of abstraction.
 Class diagram for sensor

 Class-based elements
 The various system objects (obtained from
scenarios) including their attributes and
functions (class diagram)
 Behavioral Element – State
Diagram

 Behavioral elements
 How the system behaves in response to
different events (state diagram)
Flow-oriented elements

 Flow-oriented elements
 How information is transformed as if flows
through the system (data flow diagram)
 System accepts input in a variety forms; applies
functions to transform it; and produces output in
variety forms.
Scenario based Modeling
 Creating a Preliminary use case
 use case describes a specific usage scenario in
straightforward language from the point of
view of a defined actor. But how do you know
 (1) what to write about, (2) how much to write
about it, (3) how detailed to make your
description, and (4) how to organize the
description? These are the questions that must
be answered if use cases are to provide value
as a requirements modeling tool.
Scenario based Modeling
 Refining a Preliminary Use Case
 A description of alternative interactions is essential for a
complete understanding of the function that is being
described by a use case. Therefore, each step in the primary
scenario is evaluated by asking the following questions
[Sch98a]:
 • Can the actor take some other action at this point?
 • Is it possible that the actor will encounter some error
condition at this point? If
 so, what might it be?
 • Is it possible that the actor will encounter some other
behavior at this point (e.g., behavior that is invoked by some
event outside the actor’s control)? If so, what might it be?
Scenario based Modeling
Data Modeling
 Analysis model often begin with data
modeling.
 Data model consists of three interrelated
pieces of information:
 The data object,
 The attributes that describe the data object,
and
 The relationships that connect data objects
to one another.
Data Object
 A data object is a representation of almost any
composite information that must be understood by
software.
 composite information - number of different properties or
attributes.
 A data object can be:-
 An external entity (e.g., anything that produces or
consumes information),
 A thing (e.g., a report or a display),
 An occurrence (e.g., a telephone call)
 Event (e.g., an alarm),
 A role (e.g., salesperson),
 An organizational unit (e.g., accounting department),
 A place (e.g., a warehouse),
 A structure (e.g., a file).
Data Attributes
 Define the properties of a data object.
 Attributes name a data object, describe
its characteristics, and in some cases,
make reference to another object.
 In addition, one or more of the
attributes must be defined as an
identifier( Key value or Unique value).
Ex. Data object Car has Id number as
identifier.
For Ex.- Set of attributes can be defined
for a person or a car (i.e. Data Object)
Relationships
 Data objects are connected to one another in different ways.
 Figure 6.8a. A connection is established between person
and car because the two objects are related.
 For example,
 • A person owns a car.
 • A person is insured to drive a car.
 The relationships owns and insured to drive define the
relevant connections between person and car.
 Figure 6.8b illustrates these object-relationship pairs
graphically.
 The arrows noted in Figure 6.8b provide important
information about the directionality of the relationship and
often reduce ambiguity or misinterpretations.
Relationships
Relationships
 Consider two data objects
 Book
 Bookstore
 A connection is established between book and
bookstore because the two objects are related.
Relationship
 To determine relationship between them, must
understand the role of book and bookstore.

For Example:
 A bookstore orders books.
 A bookstore displays books.
 A bookstore stocks books.
 A bookstore sells books.
 A bookstore returns books.
Cardinality and Modality
 Additional element of data modeling.
 Object X relates to object Y does not
provide enough information.
 How many occurrences of object X
are related to how many occurrences
of object Y called cardinality.
Cardinality
 Representing the number of occurrences objects in a
given relationship.
 Cardinality is the specification of the number of
occurrences of one [object] that can be related to the
number of occurrences of another.
 Cardinality is usually expressed as simply 'one' or
'many’.
 1:1 – One object can relate to only one other object.
 1:M – one object can relate to many objects.
 M:N – Some no. of occurrences of an object can
relate to some other no. of occurrences of another
object.
Modality
 Cardinality does not provide an indication of whether or
not a particular data object must participate in the
relationship.
 Modality of a relationship is 0 if there is no explicit need
for the relationship to occur or the relationship is
optional.
 The modality is 1 if an occurrences of the relationship is
mandatory.
Class based modeling
 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.
Class based modeling
 Identifying Analysis Classes
 Specifying Attributes
 Defining operations
 CRC modeling
Identifying Analysis classes
 Identify classes by examining the problem
statement or by performing a “Grammatical
Parse” on the use-cases or processing
narratives developed for the system.
How do analysis classes manifest?
 External entities (other system, people, devices) that
produce or consume information
 Things (reports, display, signals) that are part of the
information domain for the problem.
 Occurrences or events – occur within the context of
system operations.
Analysis classes (cont.)
 Roles ( manager, engineer, salesperson) played by
people who interact with the system.
 Organizational units (Division, group, team) that are
relevant to an application,
 Places – establish the context of the problem and overall
function of the system.
 Structures (sensors, computers) that define a class of
objects or related classes of objects.
Selecting Criteria - Classes
 Retained Information – Potential class must be
remembered so that system can function.
 Needed Services – Must have set of identifiable
operations that can change the value of its
attributes.
 Multiple Attributes – A class with single
attribute may, in fact, be useful during design,
but probably better represented as an
attributes of another class.
 Common Attributes – These attributes apply to
all instances of the class
Selecting Criteria - Classes
 Common operations - A set of operations can
be defined for the potential class and these
operations apply to all instances of the class.
 Essential requirements - External entities that
appear in the problem space and produce or
consume information essential to the operation
of any solution for the system will almost
always be defined as classes in the
requirements model.
Specifying Attributes
 Attributes are the set of data
objects that fully define the class
within the context of the problem.
 To develop attributes for class, a
s/w can study use-case and select
those “things” that reasonably
“Belong” to the class.
Defining operations
 Operations define the behavior of an object.
 Four broad categories
1. Operations that manipulate data in some way.
2. Operations that perform a computation.
3. Operations that inquire about the state of an object
4. Operations that monitor an object for the occurrence
of the controlling event.
 To derive a set of operations, analyst study a
use-case( or narrative) and select those
operations that reasonably belongs.
Defining operations
Class-Responsibility-collaborator
(CRC) modeling
 Simple means for identifying and organizing
the classes that are relevant to system or
product requirement.
 A CRC model is a collection of standard
index cards that represent classes. Cards
are divided into three sections.
 Top of the cards write class name
 In the body, list the class responsibility on left.
 Collaborator on the right
 It make use of actual or virtual index cards.
CRC – Classes Instantiation
 Three types classes:
1. Entity Classes (model or business classes):-
Represent things that are to be stored in a database
and persist throughout the duration of the
application.
2. Boundary class:- used to create interface. It
designed with the responsibility of managing the way
entity objects are represented to users.
3. Controller Class:- manage a “unit of work” from start
to finish.
1. Creation or update of entity objects.
2. Representation of boundary objects as they obtain
information from entity objects.
3. Complex communication between sets of objects.
4. Validation of data.
Responsibility – CRC modeling
 Guideline for allocating responsibility to classes:
1. System intelligence should be distributed across
classes to best address the needs of the problem.
2. Each responsibility should be stated as generally
as possible.
3. Information and the behavior related to it should
reside within the same class.
4. Information about one thing should be localized
with single class, not distributed across multiple
classes.
5. Responsibility should be shared among related
classes, when appropriate.
Collaborations – CRC modeling
 Collaborations represent request from client to
server in fulfillment of a client responsibility.
Ex. One object collaborate with another object if it
needs to send some msg to other object.
 It identifying relationships between objects.
 Collaborations are identified by determining
whether a class can fulfill each responsibility itself.
If it cannot, then it needs to interact with another
class.
CRC modeling
Class:
Class:
Description:
Class:
Description:
Class:FloorPlan
Description:
Responsibility:
Description: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
defines floor plan name/type
manages floor plan positioning
scales floor plan for display
scales floor plan for display
incorporates walls, doors and windows Wall
shows position of video cameras Camera
Reviewing CRC model
 All participants in the review (of the CRC model) are
given a subset of the CRC model index cards.
 Cards that collaborate should be separated (i.e.,
no reviewer should have two cards that
collaborate).
 All use-case scenarios (and corresponding use-case
diagrams) should be organized into categories.
 The review leader reads the use-case deliberately.
 As the review leader comes to a named object,
she passes a token to the person holding the
corresponding class index card.
 Cont.
 When the token is passed, the holder of the class card is
asked to describe the responsibilities noted on the card.
 The group determines whether one (or more) of the
responsibilities satisfies the use-case requirement.
 If the responsibilities and collaborations noted on the index
cards cannot accommodate the use-case, modifications are
made to the cards.
 This may include the definition of new classes (and
corresponding CRC index cards) or the specification of
new or revised responsibilities or collaborations on
existing cards.
Function Modeling & Information
Flow
 Information is transformed as it flows through a
computer-based system. The system accepts input in a
variety of forms; applies hardware, software, and human
elements to transform it; and produces output in a
variety of forms
 Structured analysis began as an information flow
modeling technique.
 A rectangle is used to represent an external entity
(software, hardware, a person)
 A circle (sometimes called a bubble) represents a
process or transform that is applied to data (or control)
and changes it in some way.
Function Modeling & Information
Flow
 An arrow represents one or more data items
(data objects) and it should be labeled.
 The double line represents a data store—stored
information that is used by the software.
 First data flow model (sometimes called a level
0 DFD or context diagram) represents the
entire system.
 It provides incremental detail with each
subsequent level.
Information Flow model
Creating a Data Flow Model
 It enables software engineer to develop
models of the information domain and
functional domain at the same time.
 Data flow diagram may be used to
represent a system or software at any level
of abstraction
 As DFD is refined into greater levels of
detail, the analyst performs an implicit
functional decomposition of the system.
 As DFD refinement results in corresponding
refinement of data as it moves through the
processes that represent the application
DFD Guidelines
 Depict the system as single bubble in level 0.
 Primary input and output should be carefully
noted
 Refine by isolating candidate processes and
their associated, data objects and data stores
 All arrows and bubbles should be labeled with
meaningful names.
 Information flow continuity must be
maintained from level to level.
 One bubble at a time should be refined.
Data flow models
 A level 0 DFD, also called a fundamental system
model or a context model, represents the entire
software element as a single bubble with input and
output data indicated by incoming and outgoing
arrows.
 Level 0 DFD refinement into level 1 DFD with all
relevant processes to the system.
 Level 1 DFD each processes can be refined into
level 2 DFD.
 Refinement of DFD continues until each bubble
performs a simple function.
Data flow models
Data flow models
Control flow model
 Application which contains collection of
classes are dependent on event rather
than data, produce control information
rather than reports or displays.
 Such application require the use of
control flow modeling in addition to data
flow modeling.
Guideline for control flow
 List all processes that are performed by the software.
 List all the interrupt conditions.
 List all activities that are performed by operator or
actor.
 List all data conditions.
 Review all the “Control items” as possible for control
flow inputs / outputs.
 Describe the behavior of a system by identifying its
states; identify how each state is reached; define the
transitions between states.
 Focus on possible omission – a very common error in
specifying control
Control Specification (CSPEC)
 CSPEC represent the behavior of the system in two
different ways.
 It contains a state diagram – sequential specification
of behavior.
 It also contain program activation table –
combinatorial specification of behavior.
 By reviewing the state diagram, a software engineer
can determine the behavior of the system and can
discover whether there are “holes” in specified
behavior.
 CSPEC describe the behavior of the system, but it
gives us no information about the inner working of the
processes that activated result.
Process Specification (PSPEC)
 Used to describe all flow model processes
that appear at the final level of refinement.
 It include narrative text, a program design
language (PDL) description of the process
algorithm, mathematical equations, tables,
diagrams or charts.
 By providing a PSPEC to accompany each
bubble in the flow model, the software
engineer creates a “mini-spec” that can
serve as guide for design of the software
component that will implement the process.
 Behavioral Modeling
 Behavioral model indicates how software will
respond to external events.
 To create model –
 Evaluate all use cases to understand the sequence of
interaction within the system.
 Identify events
 Create sequence for each use-case
 Build a state diagram for the system.
 Review the behavioral model to verify accuracy or
consistency.
Identifying events with the use-cases
 Use-case represents a sequence of activities that
involves actors and the system.
 An event occurs whenever the system and an actor
exchange information.
 An event is not the information that has been
exchanged, but rather the fact that information has been
exchanged.
 An actor should be identified for each event.
 Information that is exchanged should be noted.
 Any conditions or constraints should be listed.
State Representation
 2 diff. characteristics should be considered.
 Passive State
 Active State
 Passive state is simply the current status of all of an
object’s attributes.
Ex. Player – class
current position and orientation – attributes.
 Active State is current state of the object as it undergoes
a continuing transformation or processing.
Ex. Player – class
active state – moving, injured, trapped, lost etc.
An event must occur to force an object to make a transition
from one active state to another.
State diagram for analysis classes
 UML state diagram that represents
active states for each class and
events that causes changes between
these active state.
 An action occurs concurrently with
the state transition or as a sequence
of it and generally involves one or
more operations of the object.
Sequence diagram
 It indicates how events cause transitions from
object to object .
 Once event have identified by examining a use-
cases, the modeler creates a sequence diagram.
 It representation of how events cause flow from one
objects to another as function of time.
 Its shorthand version of use-case diagram that
represent key classes and the events that cause
behavior to flow from class to class.
 System objects and events will help in creation of
effective design.
Sequence diagram