BTECH III YEAR I SEMESTER (AR20)

QUESTION BANK(CSD-RIT)

(PREPARE QUESTION BANK TO COVER ALL THE TOPICS)

UNIT-II
1 Define Generalization and Specialization 4M
Ans:
Generalization and Specialization:

 Generalization is a process of defining a superclass from a given set of semantically for

subclass related entity set.
 Generalization is a mechanism for combining similar class of objects into single or more
general classes.
 Specialization is the reverse process of generalization means creating new subclasses from
existing classes.
 It is a mechanism for refining the definition of members of an object class.
 Specialization is the top down process. It is a process of defining one or more subclasses
for the superclass and forming Superclass-Subclass relationship.

2 Define “FURPS” 4M

Ans:
 FURPS-Functionality, Usability, Reliability, Performance, Supportability

Functionality is assessed by evaluating the feature set and capabilities of the program, the
generality of the functions that are delivered, and the security of the overall system.

Usability is the ease with which a user can learn to operate, prepare inputs for, and
interpret outputs of a system or component. Usability requirements include, for example,
conventions adopted by the user interface, the scope of online help, and the level of user
documentation. Often, clients address usability issues by requiring the developer to follow
user interface guidelines on color schemes, logos, and fonts.

Reliability is the ability of a system or component to perform its required functions under
stated conditions for a specified period of time. Reliability requirements include, for
example, an acceptable mean time to failure and the ability to detect specified faults or to
withstand specified security attacks. More recently, this category is often replaced by
dependability, which is the property of a computer system such that reliance can
justifiably be placed on the service it delivers. Dependability includes reliability,
robustness (the degree to which a system or component can function correctly in the
presence of invalid inputs or stressful environment conditions), and safety (a measure of
the absence of catastrophic consequences to the environment).

Performance requirements are concerned with quantifiable attributes of the system, such
as response time (how quickly the system reacts to a user input), throughput (how much
work the system can accomplish within a specified amount of time), availability (the
degree to which a system or component is operational and accessible when required for
use), and accuracy.

Supportability requirements are concerned with the ease of changes to the system after
deployment, including for example, adaptability (the ability to change the system to deal
with additional application domain concepts), maintainability (the ability to change the
system to deal with new technology or to fix defects), and internationalization (the ability
to change the system to deal with additional international conventions, such as languages,
units, and number formats).

3 How do you Maintain Traceability 4M

Ans:

 Traceability is the ability to follow the life of a requirement.

 This includes tracing where the requirements came from (e.g., who originated it, which
client need does it address) to which aspects of the system and the project it affects (e.g.,
which components realize the requirement, which test case checks its realization).
  Traceability enables developers to show that the system is complete, testers to show that
the system complies with its requirements, designers to record the rationale behind the
system, and maintainers to assess the impact of change.

 The simplest approach to maintaining traceability is to use cross-references among

documents, models, and code artifacts.

 Each individual element (e.g., requirement, component, class, operation, test case) is
identified by a unique number.

 Dependencies are then documented manually as a textual cross-reference containing the

number of the source element and the number of the target element.

 Tool support can be as simple as a spreadsheet or a word processing tool.

 This approach is expensive in time and person power, and it is error prone. However, for
small projects, developers can observe benefits early.

 For large-scale projects, specialized database tools enable the partial automation of the
capture, editing, and linking of traceability dependencies at a more detailed level

4 What is Client Sign-off 4M

Ans:

 The client sign-off represents the acceptance of the analysis model (as documented by the
requirements analysis document) by the client.
 The client and the developers converge on a single idea and agree about the functions and
features that the system will have. In addition, they agree on:

• a list of priorities
• a revision process
• a list of criteria that will be used to accept or reject the system
• a schedule and a budget.

 Prioritizing system functions allows the developers to understand better the client’s
expectations.

 It also allows developers to deliver the system in incremental chunks: essential functions
are delivered first, additional chunks are delivered depending on the evaluation of the
 previous chunk.

 Even if the system is to be delivered as a single, complete package, prioritizing functions

enables the client to communicate clearly what is important to her and where the emphasis
of the development should be

Each function shall be assigned one of the following priorities

• High priority—A high-priority feature must be demonstrated successfully during client
acceptance.
• Medium priority—A medium-priority feature must be taken into account in the system design
and the object design. It will be implemented and demonstrated in the second iteration of the
system development.
• Low priority—A low-priority feature illustrates how the system can be extended in the longer
term.

 After the client sign off, the requirements are baselined and are used for refining the cost
estimate of the project.

 Requirements continue to change after the sign-off, but these changes are subject to a more
formal revision process.

 The requirements change, whether because of errors, omissions, changes in the operating
environment, changes in the application domain, or changes in technology

5 Compare Functional and Non-Functional Requirements with Examples 7M

Ans:

Functional Requirements Non Functional Requirements

Help understand the functions of the system. Help understand the performance
of the system.
Explain the characteristics that a system Explain the way in which the product
is expected to have. should work (how it should behave).
Identify what the system must or must Identify how the system should do it.
not do.
Will allow the system to perform, even The system will not work with non-
if the non-functional requirements are functional requirements alone.
not met.
Ensures the system will meet Ensures the product meets user
user requirements. expectations.
Are essential to system operations. May be desirable but are not always
 essential.
Straightforward to define and agree on. Harder to define and agree on.
Meeting these requirements is obligatory. Meeting these requirements is not
obligatory but may be desirable.
Define the system or an element of it. Outline quality attributes of the system.
Usually defined by the user. Usually defined by software engineers,
developers, software architects or other
technical experts.
Can be documented and understood through a Can be documented and understood as a
use case. quality attribute.
6 Explain the Contributing factors in requirement elicitation 7M

Ans:

The task of communicating information is most challenging during requirements elicitation and
analysis. Contributing factors include

 Different backgrounds of participants. Users, clients, and developers have different

domains of expertise and use different vocabularies to describe the same concepts.
 Different expectations of stakeholders. Users, clients, and managements have different
objectives when defining the system. Users want a system that supports their current work
processes, with no interference or threat to their current position (e.g., an improved system
often translates into the elimination of current positions). The client wants to maximize
return on investment. Management wants to deliver the system on time. Different
expectations and different stakes in the project can lead to a reluctance to share
information and to report problems in a timely manner.
 New teams. Requirements elicitation and analysis often marks the beginning of a new
project. This translates into new participants and new team assignments, and, thus, into a
ramp-up period during which team members must learn to work together.
 Evolving system. When a new system is developed from scratch, terms and concepts
related to the new system are in flux during most of the analysis and the system design. A
term may have a different meaning tomorrow.

No requirements method or communication mechanism can address problems related to internal

politics and information hiding. Conflicting objectives and competition will always be part of
large development projects. A few simple guidelines, however, can help in managing the
complexity of conflicting views of the system:

 Define clear territories. This also includes the definition of private and public discussion
forums. For example, each team may have a discussion database , Project Organization
and Communication, and discussion with the client is done on a separate client database.
The client should not have access to the internal database. Similarly, developers should not
 interfere with client/user internal politics.
 Define clear objectives and success criteria. The codefinition of clear, measurable, and
verifiable objectives and success criteria by both the client and the developers facilitates
the resolution of conflicts. Note that defining a clear and verifiable objective is a nontrivial
task, given that it is easier to leave objectives open-ended. The objectives and the success
criteria of the project should be documented
 .Brainstorm. Putting all the stakeholders in the same room and to quickly generate
solutions and definitions can remove many barriers in communication. Conducting
reviews as a reciprocal activity (i.e., reviewing deliverables from both the client and the
developers during the same session) has a similar effect
7 Explain the types of User Scenarios 7M
Ans:
Scenarios
 A use case is an abstraction that describes all possible scenarios involving the described
functionality.
 A scenario is an instance of a use case describing a concrete set of actions.
 Scenarios are used as examples for illustrating common cases; their focus is on
understandability.
 Use cases are used to describe all possible cases; their focus is on completeness.
We describe a scenario using a template with three fields:
 The name of the scenario enables us to refer to it unambiguously. The name of a scenario
is underlined to indicate that it is an instance.
 The participating actor instances field indicates which actor instances are involved in
this scenario. Actor instances also have underlined names.
 The flow of events of a scenario describes the sequence of events step by step.
Scenarios can have many different uses during requirements elicitation and during other activities
of the life cycle. Below is a selected number of scenario types
 As-is scenarios describe a current situation. During reengineering, for example, the
current system is understood by observing users and describing their actions as scenarios.
These scenarios can then be validated for correctness and accuracy with the users.
 Visionary scenarios describe a future system. Visionary scenarios are used both as a point
in the modeling space by developers as they refine their ideas of the future system and as a
communication medium to elicit requirements from users. Visionary scenarios can be
viewed as an inexpensive prototype.
 Evaluation scenarios describe user tasks against which the system is to be evaluated. The
collaborative development of evaluation scenarios by users and developers also improves
the definition of the functionality tested by these scenarios.
 Training scenarios are tutorials used for introducing new users to the system. These are
step-by-step instructions designed to hand-hold the user through common tasks
In requirements elicitation, developers and users write and refine a series of scenarios in order to
gain a shared understanding of what the system should be. Initially, each scenario may be high
level and incomplete. The following questions can be used for identifying scenario
Questions for identifying scenarios
  What are the tasks that the actor wants the system to perform?
 What information does the actor access? Who creates that data? Can it be modified or
removed? By whom?
 Which external changes does the actor need to inform the system about? How often?
When?
 Which events does the system need to inform the actor about? With what latency?

8 Demonstrate Requirement Analysis Document 7M

Ans:

Requirements Analysis Document

1. Introduction
1.1 Purpose of the system
1.2 Scope of the system
1.3 Objectives and success criteria of the project
1.4 Definitions, acronyms, and abbreviations
1.5 References
1.6 Overview
2. Current system
3. Proposed system
3.1 Overview
3.2 Functional requirements
3.3 Nonfunctional requirements
3.3.1 Usability
3.3.2 Reliability
3.3.3 Performance
3.3.4 Supportability
3.3.5 Implementation
3.3.6 Interface
3.3.7 Packaging
3.3.8 Legal
3.4 System models
3.4.1 Scenarios
3.4.2 Use case model
3.4.3 Object model
3.4.4 Dynamic model
3.4.5 User interface—navigational paths and screen mock-ups
4.Glossary

 The results of the requirements elicitation and the analysis activities are documented in the
Requirements Analysis Document (RAD).
 This document completely describes the system in terms of functional and nonfunctional
requirements.
 The audience for the RAD includes the client, the users, the project management, the
system analysts (i.e., the developers who participate in the requirements), and the system
 designers (i.e., the developers who participate in the system design).
 The first part of the document, including use cases and nonfunctional requirements, is
written during requirements elicitation.
 The first section of the RAD is an Introduction. Its purpose is to provide a brief overview of
the function of the system and the reasons for its development, its scope, and references to
the development context (e.g., reference to the problem statement written by the client,
references to existing systems, feasibility studies). The introduction also includes the
objectives and success criteria of the project.
 The second section, Current system, describes the current state of affairs. If the new
system will replace an existing system, this section describes the functionality and the
problems of the current system. Otherwise, this section describes how the tasks supported
by the new system are accomplished now
 The third section, Proposed system, documents the requirements elicitation and the
analysis model of the new system. It is divided into four subsections:

 Overview presents a functional overview of the system.

 Functional requirements describe the high-level functionality of the system.
 Non-functional requirements describe user-level requirements that are not
directly related to functionality. This includes usability, reliability,
performance, supportability, implementation, interface, operational,
packaging, and legal requirements.
 System models describe the scenarios, use cases, object model, and dynamic models
for the system. This section contains the complete functional specification,
including mock-ups illustrating the user interface of the system and navigational
paths representing the sequence of screens. The subsections Object model and
Dynamic model are written during the Analysis activity

9 Analyse Completeness, Consistency, Clarity, Correctness, Realism, Verifiability, 10M

and Traceability of requirement with Examples
Ans:
 Requirements are continuously validated with the client and the user.

 Validation is a critical step in the development process, given that both the client and the
developer depend on the requirements specification.

 Requirement validation involves checking that the specification is complete, consistent,

unambiguous, and correct.

 It is complete if all possible scenarios through the system are described, including
exceptional behaviour (i.e., all aspects of the system are represented in the requirements
model).
 The requirements specification is consistent if it does not contradict itself.

 The requirements specification is unambiguous if exactly one system is defined (i.e., it is

not possible to interpret the specification two or more different ways).

 A specification is correct if it represents accurately the system that the client needs and
that the developers intend to build (i.e., everything in the requirements model accurately
represents an aspect of the system to the satisfaction of both client and developer).

 The requirements specification is realistic if the system can be implemented within

constraints.

 The requirements specification is verifiable if, once the system is built, repeatable tests
can be designed to demonstrate that the system fulfills the requirements specification

 The following requirements are additional examples of nonverifiable requirements:

 The product shall have a good user interface.—Good is not defined.

 The product shall be error free.—Requires large amount of resources to establish.
 The product shall respond to the user with 1 second for most cases.—“Most cases”
is not defined.

 A requirements specification is traceable if each requirement can be traced throughout the

software development to its corresponding system functions, and if each system function
can be traced back to its corresponding set of requirements.
Complete
 Traceability includes also the ability to track the dependencies among requirements,
Req:system
A professor
functions,user
andwill
the log into the design
intermediate system artifacts,
by providing his system
including username,
components,
password, and other relevant information
classes, methods, and object attributes (incomplete)
The above requirement should be written as
Examples:
Req: A professor user will log into the system by providing his username, password
and department code
Consistent
REQ1 Dates shall be displayed in the mm/dd/yyyy format.
REQ2 Dates shall be displayed in the dd/mm/yyyy format
Sometimes it is possible to resolve the conflict by analyzing the conditions under
which the requirement takes place. For example, if REQ1 was submitted by an
American user and REQ2 by a French user, the preceding requirements may be
rewritten as follows:
 REQ1 For users in the U.S., dates shall be displayed in the mm/dd/yyyy format.
REQ2 For users in France, dates shall be displayed in the dd/mm/yyyy format
This can eventually lead to the following requirement:
Dates shall be displayed based on the format defined in the user’s web browser.

Unambiguous
Ex 1:
REQ---The system shall be implemented using ASP.
Does ASP mean Active Server Pages or Application Service Provider? To fix
this, we can mention a full name and provide an acronym in parentheses:
REQ---The system shall be implemented using Active Server Pages (ASP).

Testable or verifiable:
Such a requirement might look something like this:
REQ--- The search facility should allow the user to find a reservation based on
Last Name, Date, etc.
In this requirement, all search criteria should be explicitly listed. The designer
and developer cannot guess what the user means by “etc.”
REQ-- The system shall resist concurrent usage by many users.
What number should be considered “many”—10, 100, 1,000?
10 Analyze the activities in Joint Application Design 10M

Ans:

 Joint Application Design (JAD) is a requirements method where its effectiveness lies in
that the requirements elicitation work is done in one single workshop session in which all
stakeholders participate.

 Users, clients, developers, and a trained session leader sit together in one room to present
their viewpoints, listen to other viewpoints, negotiate, and come to a mutually acceptable
solution.

 The outcome of the workshop, the final JAD document, is a complete requirements
specification document that includes definitions of data elements, work flows, and
interface screens.

 Because the final document is jointly developed by the stakeholders (that is, the
participants who not only have an interest in the success of the project, but also can make
substantial decisions), the final JAD document represents an agreement among users,
clients, and developers, and thus minimizes requirements changes later in the development
process.

 JAD is composed of five activities:

 Project definition. During this activity, the JAD facilitator interviews the project
manager and the client to determine the objectives and the scope of the project. The
findings from the interviews are collected in the Management Definition Guide.
 Research. During this activity, the JAD facilitator interviews present and future
users, gathers information about the application domain, and describes a first set of
high-level use cases. The JAD facilitator also starts a list of problems to be
addressed during the session. The results of this activity are a Session Agenda and a
Preliminary Specification listing work flow and system information.
 Preparation. During this activity, the JAD facilitator prepares the session. The JAD
facilitator creates a Working Document, which is the first draft of the final
document, an agenda for the session, and any overhead slides or flip charts
representing information gathered during the Research activity. The JAD facilitator
also selects a team composed of the client, the project manager, selected users, and
developers. All stakeholders are represented, and the participants are able to make
binding decisions.
 Session. During this activity, the JAD facilitator guides the team in creating the
requirements specification. A JAD session lasts for 3 to 5 days. The team defines
and agrees on the scenarios, use cases, and user interface mock-ups. All decisions
 are documented by a scribe.
 Final document. The JAD facilitator prepares the Final Document, revising the
working document to include all decisions made during the session. The Final
Document represents a complete specification of the system agreed on during the
session. The Final Document is distributed to the session participants for review.
The participants then attend a 1- to 2-hour meeting to discuss the reviews and
finalize the document.

11 Analyze about the activities involved in Requirement elicitation 10M

Ans:

Requirements Elicitation activities

1.Identifying Actors
Actors represent external entities that interact with the system. An actor can be human or an
external system

2.Identifying Scenarios

Four types of scenarios:

As-is scenarios describe the current situation.
Visionary scenarios describe a future system.
Evaluation scenarios describe user tasks to be used to evaluate the system.
Training scenarios are used for tutorials and other training aids.

3. Identifying Use Cases

 A scenario is an instance of a use case; that is, a use case specifies all possible scenarios
for a given piece of functionality.
 A use case is initiated by an actor. After its initiation, a use case may interact with other
actors, as well.
 A use case represents a complete flow of events through the system in the sense that it
describes a series of related interactions that result from its initiation

4.Refining Use Cases

The following aspects of use cases are detailed during refinement:

 The elements that are manipulated by the system are detailed.

 The low-level sequence of interactions between the actor and the system are specified.
 Access rights ( to initiate scenarios ) are specified
 Missing exceptions are identified and their handling specified.
 Common functionality among use cases are factored out.

5 Identifying Relationships among Actors and Use Cases

Communication relationships between actors and use cases

 Communication relationships between actors and use cases represent the flow of
information during the use case.
 The actor who initiates the use case should be distinguished from the other actors with
whom the use case communicates.
 By specifying which actor can invoke a specific use case, we also implicitly specify which
actors cannot invoke the use case.
 Similarly, by specifying which actors communicate with a specific use case, we specify
which actors can access specific information and which cannot.
 Thus, by documenting initiation and communication relationships among actors and use
cases, we specify access control for the system at a coarse level
Extend versus include relationships

 Use include relationships to factor out commonly occurring normal activities that are
common to multiple use-cases. Included use-cases are often capable of standing alone as
use-cases, and are usually invoked from other use-cases at predictable points. Example:
Printing.
 Use extend relationships to document unusual, exceptional, error, and rarely occurring use-
cases. Extend use-cases generally cannot stand alone, and in general could be invoked
from any point in a number of use cases. Example: Power failure.

6. Identifying Initial Analysis Object

 To establish a clear terminology, developers identify the participating objects for each use
case.
 Developers should identify, name, and describe them unambiguously and collate them into
a glossary.
 Building this glossary constitutes the first step toward analysis, The glossary is included in
the requirements specification and, later, in the user manuals.
 Developers keep the glossary up to date as the requirements specification evolves.
 The benefits of the glossary are manyfold: new developers are exposed to a consistent set
of definitions, a single term is used for each concept (instead of a developer term and a
user term), and each term has a precise and clear official meaning.
 The identification of participating objects results in the initial analysis object model.
 The identification of participating objects during requirements elicitation only constitutes a
 first step toward the complete analysis object model.
 The complete analysis model is usually not used as a means of communication between
users and developers, as users are often unfamiliar with object-oriented concepts.
However, the description of the objects (i.e., the definitions of the terms in the glossary)
and their attributes are visible to the users and reviewed.

7.Identifying Non functional Requirements

 Nonfunctional requirements describe aspects of the system that are not directly related to
its functional behaviour.
 Nonfunctional requirements span a number of issues, from user interface look and feel to
response time requirements to security issues.
 Nonfunctional requirements are defined at the same time as functional requirements
because they have as much impact on the development and cost of the system

12 Analyze about the activities involved in Analysis 10M

Ans:

 The analysis phase produces a preliminary model of the system, in terms that the client can
understand.
o Objects identified at this stage are limited to those that the client can see and
understand. Internal implementation details are not included at this time.
o Specifically three types of objects are identified:

 Entity objects represent entities in the client's problem domain, such as

memos, meetings, budgets, deadlines, etc., both tangible and intangible.
 Bondary objects provide the user interface for the system, such as forms,
menus, dialog boxes, etc. These are parts of the system which are visible to
the clients and users. ( Classes for interfacing with non-human external
systems would also fall into this category. )
 Control objects encapsulate the control logic for each use-case, ensuring
the right steps occur in the right order.
 The overall goal is to identify as many potential objects as possible, and to document the
relationships between them as they participate in acting out use-cases. ( E.g. inheritance,
aggregation, etc. )

1.Identifying Entity Objects

 One common approach to identifying entity objects involves grammatical analysis of the
project description, scenarios, and use-cases:
Heuristics for identifying entity objects

 Terms that developers or users need to clarify in order to understand the use case
 Recurring nouns in the use cases (e.g., Incident)
 Real-world entities that the system needs to track (e.g., FieldOfficer, Dispatcher,
Resource)
 Real-world activities that the system needs to track (e.g., EmergencyOperationsPlan)
 Data sources or sinks (e.g., Printer).

2.Identifying Boundary Objects

Boundary objects represent an interface as a whole, not the individual components that make it up.
For example a data entry form would be a boundary object, but the individual fields, radio
buttons, checkboxes, etc. on the form would not be modelled at this time.

Heuristics for identifying boundary objects

 Identify user interface controls that the user needs to initiate the use case (e.g.,
ReportEmergencyButton).
 Identify forms the users needs to enter data into the system (e.g., EmergencyReportForm).
 Identify notices and messages the system uses to respond to the user (e.g.,
AcknowledgmentNotice).
 When multiple actors are involved in a use case, identify actor terminals (e.g.,
DispatcherStation) to refer to the user interface under consideration.
 Do not model the visual aspects of the interface with boundary objects (user mock-ups are
better suited for that).
 Always use the end user’s terms for describing interfaces; do not use terms from the
solution or implementation domains

3.Identifying Control Objects

Control objects are responsible for coordinating boundary and entity objects. Control objects
usually do not have a concrete counterpart in the real world. Often a close relationship exists
between a use case and a control object; a control object is usually created at the beginning of a
use case and ceases to exist at its end

Heuristics for identifying control objects

 Identify one control object per use case.

 Identify one control object per actor in the use case.
 The life span of a control object should cover the extent of the use case or the extent of a user
session. If it is difficult to identify the beginning and the end of a control object activation,
the corresponding use case probably does not have well-defined entry and exit conditions.

4.Mapping Objects to Use-Cases with Sequence Diagrams

 Sequence diagrams document the classes / objects that participate in a particular use-case,
the sequence of actions that each one takes during the use-case, and the sequence of
messages that are passed ino order to execute the use-case.
 Modelling all use-cases as sequence diagrams helps:
 Clarify the responsibilities of classes.
 Identify missing classes.
 Identify unneeded classes.

Heuristics for drawing sequence diagrams

 The first column should correspond to the actor who initiated the use case.
 The second column should be a boundary object (that the actor used to initiate the use case).
 The third column should be the control object that manages the rest of the use case.
 Control objects are created by boundary objects initiating use cases.
 Boundary objects are created by control objects.
 Entity objects are accessed by control and boundary objects.
 Entity objects never access boundary or control objects; this makes it easier to share entity
objects across use cases

5.Modeling Object Interations with CRC Cards

 CRC ( Class, Responsibility, Collaborators ) cards are an alternative to sequence diagrams.

 Each potential class is represented by a separate ( 5 x 7 ) card, titled with the name of the
class.
 Use-cases are acted out, with each CRC card "playing their part", much like a multi-person
role-playing game.
 As this occurs, the responsibilities of each card ( class ) are clarified, and written down on
the cards, as are the list of other cards ( classes ) that this one collaborates with during the
use case.
 As with sequence diagrams, this approach helps to clarify the responsibilities of each class,
 identify missing or unneeded classes, and to identify associations between related classes.

6. Identifying and Documenting Associations, Including Aggregations and Inheritance

 As the relationships between classes participating in use-cases are determined, they can be
documented in preliminary class diagrams.
 Include information about roles, multiplicities, etc. to the extent that they are known.
 Inheritance relationships are more likely to be identified later, during system refinement.
 Try to avoid making diagrams that are overly cluttered. Use multiple separate diagrams as
necessary for clarity.

Associations and multiplicities

 Composition and Aggregations
7. Modelling State-Dependent Behaviour of Individual Objects

 In some cases it can be beneficial to concentrate on the behaviour of an individual object,

to see what state transitions it undergoes in response to what events.
 This may help identify missing use-cases and undocumented behaviour.
 In general this approach is most appropriate for control objects, less so for entity objects
and rarely if ever for boundary objects.

Besides state-machine diagrams, activity diagrams can also be helpful to illustrate responsibilities
and the order of events:
8.Reviewing the Analysis Model

 The analysis model (sequence diagrams, class diagrams, CRC cards, etc. ) is developed
iteratively over a long time period by many people working together.
 It is never completely right on the first pass, and in general requires several reviews with
the client to refine it.
 Initially the analysis model changes rapidly and significantly. Over time it matures, and
begins to stabilize.
 Avoid the temptation to put in too much detail before the model has stabilized.
 Periodically and certainly at the end the model must be reviewed for:
 Correctness
 Completeness
 Consistency
 Realism