MODULE-2

Requirements Elicitation and Analysis

Requirements Elicitation:
 Requirements elicitation focuses on describing the purpose of the system. The client, the developers, and the
users identify a problem area and define a system that addresses the problem.
 Requirements elicitation and analysis focus only on the user’s view of the system. For example, the system
functionality, the interaction between the user and the system, the errors that the system can detect and handle,
and the environmental conditions in which the system functions are part of the requirements.
 During requirements elicitation, developers access many different sources of information, including client-
supplied documents about the application domain, manuals and technical documentation of legacy systems
that the future system will replace, and most important, the users and clients themselves. Developers interact
the most with users and clients during requirements elicitation.

Requirements Elicitation Concepts:

It includes,
1) Functional Requirements
2) Nonfunctional Requirements
3) Completeness, Consistency, Clarity, and Correctness
4) Realism, Verifiability, and Traceability
5) Greenfield Engineering, Reengineering, and Interface Engineering

Functional requirements:
Functional requirements describe the interactions between the system and its environment independent of its
implementation. The environment includes the user and any other external system with which the system
interacts.

Example for Online Banking:

1. User Authentication:
o Requirement: The system should allow users to log in using their username and password, and
authenticate them through multi-factor authentication (MFA) if required.
o Interaction: The user interacts with the login page, enters their credentials, and the system
verifies the credentials against the database to allow access.
2. Balance Inquiry:
o Requirement: The system must display the current account balance of the user when they
request to check their balance.
o Interaction: The user selects "Check Balance" from the menu, and the system retrieves the
account information from the database and displays the balance on the screen.
3. Fund Transfer:
o Requirement: The system should allow users to transfer money between accounts or to other
users' accounts by entering the recipient's account number, transfer amount, and confirming the
transaction.
o Interaction: The user fills in the transfer details, and the system processes the transaction by
interacting with the banking network and ensuring that funds are deducted from one account and
credited to the recipient's account.
 4. Transaction History:
o Requirement: The system should allow users to view a detailed list of their recent transactions,
including deposits, withdrawals, and transfers.
o Interaction: The user requests their transaction history, and the system fetches and displays a list
of transactions from the database based on the date range provided.

Nonfunctional Requirements:

 Nonfunctional requirements describe aspects of the system that are not directly related to the functional
behavior of the system. Nonfunctional requirements include a broad variety of requirements that apply to
many different aspects of the system, from usability to performance.

The following are the categories of nonfunctional requirements:

 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.
 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.
 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).

Here are some real-time examples of nonfunctional requirements:

1. Performance Requirement

 Example: An e-commerce website should load within 3 seconds for 95% of its users.
 Description: This requirement sets an expectation for how quickly the system responds under typical
conditions. It's crucial for user satisfaction and conversion rates.

2. Security Requirement

 Example: A banking mobile application should encrypt user data with AES-256 encryption and
require multi-factor authentication (MFA) for login.
 Description: This ensures that the data remains confidential and secure, protecting users from
unauthorized access or breaches.

3. Usability Requirement

 Example: A mobile app for food delivery must have a user-friendly interface with easy-to-navigate
menus, making it simple for customers to place an order within 2 minutes of opening the app.
  Description: This requirement focuses on the ease of use, ensuring that users can interact with the
system without difficulty.

4. Availability Requirement

 Example: A cloud-based customer support system should be available 99.9% of the time, with no
more than 4.38 hours of downtime per year.
 Description: This nonfunctional requirement defines the system’s uptime and is critical for systems
where availability is vital for business continuity.

5. Scalability Requirement

 Example: An online learning platform must support up to 100,000 simultaneous users without
degrading the user experience.
 Description: This requirement specifies that the system should be able to scale up to handle increasing
loads without significant performance loss, especially during peak usage.

6. Reliability Requirement

 Example: A healthcare records system should have a 99.99% reliability rate, meaning it should fail no
more than once every 10,000 hours of use.
 Description: This defines how reliable the system must be to ensure users can depend on it, especially
in critical environments like healthcare.

7. Compliance Requirement

 Example: An e-commerce website must comply with GDPR (General Data Protection Regulation) to
ensure users' personal data is handled according to European Union regulations.
 Description: This requirement ensures the system meets legal and regulatory standards, often important
for industries handling sensitive data.

8. Maintainability Requirement

 Example: A content management system (CMS) must be designed in such a way that it allows easy
updates to content and the addition of new features within 2 weeks.
 Description: This ensures that the system can be updated or modified with minimal effort and
downtime.

Completeness, Consistency, Clarity, and Correctness:

 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 behavior (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).

Completeness Real-time Example: In a hotel booking system:

 Incomplete: "The system should allow users to book rooms."

 Complete: "The system should allow users to search for rooms based on date, location, and number of
guests, display available rooms, allow users to select room type, and confirm booking with payment
processing."

Consistency Real-time Example: In a library management system:

 Inconsistent Requirement: "The system should allow users to borrow books for 14 days" and "The
system should allow users to borrow books indefinitely."
 Consistent Requirement: "The system should allow users to borrow books for up to 14 days, with the
option to extend for another 7 days if no other user has reserved the book."

Clarity Real-time Example: In an e-commerce website:

 Unclear Requirement: "The system should have a good user interface."

 Clear Requirement: "The system should have a responsive user interface that adjusts seamlessly for
different screen sizes (desktop, tablet, mobile) and loads within 2 seconds."

Correctness Real-time Example: In a real-time chat application:

 Incorrect Requirement: "The system should support unlimited messages in the chat history."
 Correct Requirement: "The system should support up to 10,000 messages in the chat history, with
older messages archived to optimize performance."

Realism, Verifiability, and Traceability:

 Three more desirable properties of a requirements specification are that it be realistic, verifiable, and traceable.
 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.
 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. Traceability includes also the ability to track the dependencies among
requirements, system functions, and the intermediate design artifacts, including system components, classes,
methods, and object attributes. Traceability is critical for developing tests and for evaluating changes.

Greenfield Engineering, Reengineering, and Interface Engineering:

 Requirements elicitation activities can be classified into three categories, depending on the source of the
requirements.
 In greenfield engineering, the development starts from scratch—no prior system exists—so the requirements
are extracted from the users and the client. A greenfield engineering project is triggered by a user need or the
creation of a new market.
 A reengineering project is the redesign and reimplementation of an existing system triggered by technology
enablers or by business processes. Sometimes, the functionality of the new system is extended, but the
essential purpose of the system remains the same. The requirements of the new system are extracted from an
existing system.
 An interface engineering project is the redesign of the user interface of an existing system. The legacy system
is left untouched except for its interface, which is redesigned and re-implemented. This type of project is a
reengineering project in which the legacy system cannot be discarded without entailing high costs.

Requirements Elicitation Activities:

Requirements elicitation activities include,

 Identifying Actors
 Identifying Scenarios
 Identifying Use Cases
 Refining Use Cases
 Identifying Relationships Among Actors and Use Cases
 Identifying Initial Analysis Objects
 Identifying Nonfunctional Requirements

Identifying Actors:
 Actors represent external entities that interact with the system. An actor can be human or an external system.
The first step of requirements elicitation is the identification of actors.
 This serves both to define the boundaries of the system and to find all the perspectives from which the
developers need to consider the system. When the system is deployed into an existing organization (such as a
company), most actors usually exist before the system is developed: they correspond to roles in the
organization.
 Once the actors are identified, the next step in the requirements elicitation activity is to determine the
functionality that will be accessible to each actor. This information can be extracted using scenarios and
formalized using use cases.

Real-Time Example: Let’s say we are developing an Online Banking System.

 Actors in this system might include:

o Customer: The person who logs into the bank’s system to check balances, transfer funds, and
view transaction history.
o Bank Teller: An employee who uses the system to assist customers with their banking
transactions in person.
o Admin: A system administrator who manages user accounts and system configurations.
o External Systems: For example, a Payment Gateway that processes credit card transactions.

Identifying Scenarios:
 A scenario is “a narrative description of what people do and experience as they try to make use of computer
systems and applications”.
 A scenario is a concrete, focused, informal description of a single feature of the system from the viewpoint of
a single actor. Scenarios cannot (and are not intended to) replace use cases, as they focus on specific instances
and concrete events (as opposed to complete and general descriptions). However, scenarios enhance
requirements elicitation by providing a tool that is understandable to users and clients.
 Scenarios can have many different uses during requirements elicitation and during other activities of the life
cycle.
 The emphasis for developers during actor identification and scenario identification is to understand the
application domain. This results in a shared understanding of the scope of the system and of the user work
processes to be supported. Once developers have identified and described actors and scenarios, they formalize
scenarios into use cases.

Real-Time Example: For the Online Banking System, scenarios could include:

 Scenario 1: A Customer logs into the system to check their account balance.
 Scenario 2: A Customer transfers money from one account to another.
 Scenario 3: A Bank Teller assists a customer by depositing a check into their account.
 Scenario 4: An Admin resets a customer’s password after a security breach.

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.
 Describing a use case entails specifying four fields. Describing the entry and exit conditions of a use case
enables developers to understand the conditions under which a use case is invoked and the impact of the use
case on the state of the environment and of the system. By examining the entry and exit conditions of use
cases, developers can determine if there may be missing use cases.
 Writing use cases is a craft. An analyst learns to write better use cases with experience. Consequently, different
analysts tend to develop different styles, which can make it difficult to produce a consistent requirements
specification.

Real-Time Example: Let’s define a few use cases for the Online Banking System:

 Use Case 1: Log in to the System

o Actor: Customer
o Goal: Customer successfully logs into their account to view their balance.
o Steps:
1. Customer enters username and password.
2. System validates credentials.
3. System displays account details.

Refining Use Cases:

 Refining use cases involves breaking down the use case into smaller, more detailed steps and identifying any
variations or alternative flows that might occur during the interaction.
 The focus of this activity is on completeness and correctness. Developers identify functionality not covered
by scenarios, and document it by refining use cases or writing new ones.

Real-Time Example: Let’s refine Use Case 1: Log in to the System. Here we would add:

 Basic Flow (Normal scenario):

1. Customer enters a valid username and password.
2. System authenticates and logs the customer in.
3. System displays the account dashboard.
  Alternative Flow (Error scenario):
1. Customer enters an invalid username or password.
2. System displays an error message and prompts the customer to try again.
3. If the customer fails after three attempts, the system locks the account for security purposes.

Identifying Relationships among Actors and Use Cases:

 Even medium-sized systems have many use cases. Relationships among actors and use cases enable the
developers and users to reduce the complexity of the model and increase its understandability.
 We use communication relationships between actors and use cases to describe the system in layers of
functionality. We use extend relationships to separate exceptional and common flows of events. We use
include relationships to reduce redundancy among 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.

Extend relationships between use cases

 A use case extends another use case if the extended use case may include the behavior of the extension under
certain conditions.

Real-Time Example: For the Online Banking System:

 Customer is involved in use cases like:

o Log in to the System.
o Transfer Funds.
o Check Balance.
 Admin is involved in use cases like:
o Reset Password.
o Manage User Accounts.

Identifying Initial Analysis Objects:

 One of the first obstacles developers and users encounter when they start collaborating with each other is
differing terminology. Although developers eventually learn the user’s terminology, this problem is likely to
be encountered again when new developers are added to the project.
 Misunderstandings result from the same terms being used in different contexts and with different meanings.
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.
 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.
Real-Time Example: In the Online Banking System, initial analysis objects could be:

 Account: A customer’s bank account, which has properties like balance, account number, account type
(savings, checking).
 Transaction: A record of money being deposited, withdrawn, or transferred.
 Customer: The person who holds the bank account, with properties like name, address, and contact
information.
 BankEmployee: Employees like tellers who interact with customers.

Identifying Nonfunctional Requirements:

 Nonfunctional requirements describe aspects of the system that are not directly related to its functional
behavior. 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.
 Nonfunctional requirements can impact the work of the user in unexpected ways. To accurately elicit all the
essential nonfunctional requirements, both client and developer must collaborate so that they identify
(minimally) which attributes of the system that are difficult to realize are critical for the work of the user.

Real-Time Example: For the Online Banking System, nonfunctional requirements could be:

 Performance: The system should be able to handle at least 10,000 simultaneous users without
noticeable slowdowns.
 Security: All customer passwords must be encrypted, and the system should require two-factor
authentication for high-value transactions.
 Usability: The system should allow customers to complete most transactions within 3 minutes.
 Scalability: The system should be able to scale to accommodate additional features, such as mobile
banking, in the future without major redesign.

Managing Requirements Elicitation:

It includes,
 Negotiating Specifications with Clients: Joint Application Design
 Maintaining Traceability
 Documenting Requirements Elicitation

Negotiating Specifications with Clients: Joint Application Design:

 Joint Application Design (JAD) is a requirements method developed at IBM at the end of the 1970s. 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.
Maintaining Traceability:
 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.

Documenting Requirements Elicitation:

 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 formalization of the specification in terms of object models is written during
analysis.

Analysis

Analysis results in a model of the system that aims to be correct, complete, consistent, and unambiguous.
Developers formalize the requirements specification produced during requirements elicitation and examine in
more detail boundary conditions and exceptional cases.

Developers validate, correct and clarify the requirements specification if any errors or ambiguities are found. The
client and the user are usually involved in this activity when the requirements specification must be changed and
when additional information must be gathered.

The analysis model is composed of three individual models: the functional model, represented by use cases and
scenarios, the analysis object model, represented by class and object diagrams, and the dynamic model,
represented by state machine and sequence diagrams.
 Analysis Model
Analysis Concepts:
It includes,
 Analysis Object Models and Dynamic Models
 Entity, Boundary, and Control Objects
 Generalization and Specialization

Analysis Object Models and Dynamic Models:

Analysis models:
 The analysis model represents the system under development from the user’s point of view. The analysis
object model is a part of the analysis model and focuses on the individual concepts that are manipulated by
the system, their properties and their relationships.
 The analysis object model, depicted with UML class diagrams, includes classes, attributes, and operations.
The analysis object model is a visual dictionary of the main concepts visible to the user.

Real-Time Example 1: Library Management System (LMS)

In a Library Management System, the analysis object model would depict the static entities involved in the
system and how they are related.

Objects (Classes) in the System:

 Book: Attributes could include title, author, ISBN, published year.

 Member: Attributes could include name, membership number, address.
 Loan: Attributes could include loan date, due date, return date.

Relationships:

 A Member can have multiple Loans.

 A Loan is associated with a specific Book.
 A Book can be associated with multiple Loans over time.
Example Object Model Diagram:

 Member has a one-to-many relationship with Loan.

 Loan has a many-to-one relationship with Book.

Dynamic Models:
 The dynamic model focuses on the behavior of the system. The dynamic model is depicted with sequence
diagrams and with state machines.
 Sequence diagrams represent the interactions among a set of objects during a single use case.
 State machines represent the behavior of a single object (or a group of very tightly coupled objects). The
dynamic model serves to assign responsibilities to individual classes and, in the process, to identify new
classes, associations, and attributes to be added to the analysis object model.

Real-Time Example 1: Library Management System (LMS)

In the Library Management System, a dynamic model could describe the checkout process when a member checks
out a book.
Sequence of Events (Dynamic Model with Sequence Diagram):

1. A Member sends a request to the LMS system to check out a book.

2. The LMS checks if the book is available for loan.
3. If the book is available, the system creates a Loan record, updates the availability status of the Book, and
updates the Member's loan record.
4. The Member is notified that the book is successfully checked out.
The interaction between Member, Book, and Loan classes over time is captured in this dynamic sequence of
events.
Entity, Boundary, and Control Objects:

 The analysis object model consists of entity, boundary, and control objects.
 Entity objects represent the persistent information tracked by the system.
 Boundary objects represent the interactions between the actors and the system.
 Control objects are in charge of realizing use cases.
 Modeling the system with entity, boundary, and control objects provides developers with simple heuristics to
distinguish different, but related concepts.
 This approach with three object types results in smaller and more specialized objects. The three object- type
approach also leads to models that are more resilient to change: the interface to the system (represented by
the boundary objects) is more likely to change than its basic functionality (represented by the entity and
control objects).

Example:

Let’s consider a Book Checkout Use Case in a Library Management System:

1. Boundary Object:
o The Book Checkout Interface is used by the librarian to input details of the book being checked
out and the member borrowing the book.
2. Control Object:
o The CheckoutController receives the input from the boundary object, processes the request,
checks if the book is available, and then creates a Loan record.
3. Entity Object:
o The Book object stores the information about the book (e.g., title, ISBN), and the Loan object
tracks the borrowing details (e.g., member, due date).

In this scenario, the Boundary Object handles user input, the Control Object manages the process, and the
Entity Objects hold and manage the data.
Generalization and Specialization:

Generalization is the modeling activity that identifies abstract concepts from lower-level ones. For example,
assume we are reverse-engineering an emergency management system and discover screens for managing traffic
accidents and fires. Noticing common features among these three concepts, we create an abstract concept called
Emergency to describe the common (and general) features of traffic accidents and fires.

Specialization is the activity that identifies more specific concepts from a high-level one. For example, assume
that we are building an emergency management system from scratch and that we are discussing its functionality
with the client. The client first introduces us with the concept of an incident, then describes three types of
Incidents: Disasters, which require the collaboration of several agencies, Emergencies, which require immediate
handling but can be handled by a single agency, and LowPriorityIncidents, that do not need to be handled if
resources are required for other, higher-priority Incidents.

Example: An example of a generalization hierarchy (UML class diagram). The top of the hierarchy represents
the most general concept, whereas the bottom nodes represent the most specialized concepts.
Analysis Activities: From Use Cases to Objects:
These are the activities that transform the use cases and scenarios produced during requirements elicitation into
an analysis model. Analysis activities include:

 Identifying Entity Objects

 Identifying Boundary Objects
 Identifying Control Objects
 Mapping Use Cases to Objects with Sequence Diagrams
 Modeling Interactions among Objects with CRC Cards
 Identifying Associations
 Identifying Aggregates
 Identifying Attributes
 Modeling State-Dependent Behavior of Individual Objects

Analysis Activities: From Use Cases to Objects

The analysis activities play a crucial role in transforming requirements (captured through use cases and
scenarios) into a structured object-oriented analysis model. These activities help in identifying key
components of the system and defining their interactions. Here's a brief explanation of each analysis activity:

1. Identifying Entity Objects

 Entity objects represent the core business data or domain objects that will persist in the system (e.g.,
Customer, Order, Product).
 These are typically the objects that are stored in a database or some form of persistent storage.
 The goal is to identify the objects that represent real-world entities and that are central to the
functionality of the system.

Example: In a Library Management System, Book, Member, and Loan could be identified as entity objects.

2. Identifying Boundary Objects

 Boundary objects manage interactions between the system and its external environment (users or other
systems).
 These objects define how the system communicates with actors (e.g., users, other systems) through user
interfaces or system interfaces.
 They serve as gateways for handling input and output.

Example: In the Library Management System, BookSearchUI, CheckoutForm, or ReceiptPrinter can be

identified as boundary objects.

3. Identifying Control Objects

 Control objects manage the system's behavior and the execution of use cases.
 These objects handle business logic, process flow, and coordination between entity and boundary
objects.
 Control objects are responsible for invoking methods on entity objects and coordinating their
interactions.
Example: In a Library Management System, CheckoutController could be a control object responsible for
managing the checkout process (validating member, checking book availability, updating loan records).

4. Mapping Use Cases to Objects with Sequence Diagrams

 Sequence diagrams help model the interactions between objects over time in response to a use case.
 These diagrams show the order of messages exchanged between objects to fulfill a specific use case.
 This helps identify which objects (entity, boundary, control) are involved in fulfilling a use case and
how they interact.

Example: In an E-Commerce System, a sequence diagram could show how the Customer, ShoppingCart,
OrderController, and PaymentGateway interact during the checkout process.

5. Modeling Interactions among Objects with CRC Cards

 CRC (Class-Responsibility-Collaboration) cards are used to model the roles and responsibilities of
objects and their collaborations.
 Each CRC card represents a class and outlines its responsibilities (what the class does) and its
collaborators (which other classes it interacts with).
 This method helps clarify the roles of different objects and their relationships in fulfilling a use case.

Example: A CRC card for the Order class in an E-Commerce System could describe its responsibility for
tracking the order status and collaborating with the Customer and Product classes.
6. Identifying Associations

 Associations describe the relationships between objects or classes.

 These associations can be one-to-one, one-to-many, or many-to-many, and they represent how objects
are linked and interact with each other in the system.

Example: In a Library Management System, the association between Member and Loan could be a one-to-
many relationship (one member can have multiple loans).

7. Identifying Aggregates

 Aggregates represent groups of related objects that are treated as a unit.

 An aggregate usually contains an object (called the aggregate root) that controls and manages the
lifecycle of other objects within the aggregate.
 Aggregates help define composite structures where complex relationships are managed at a higher
level.

Example: In an E-Commerce System, the Order object could be an aggregate that contains multiple Product
objects as part of the order.

8. Identifying Attributes

 Attributes define the data associated with an object or class.

 These are the properties that describe the state of an object and may include simple data types (e.g.,
integers, strings) or references to other objects.
 Identifying attributes is important for understanding the details of the object and ensuring that it contains
the necessary information.

Example: The Product class in an E-Commerce System could have attributes such as name, price,
stockQuantity, and description.

9. Modeling State-Dependent Behavior of Individual Objects

 This activity focuses on identifying and modeling the states of objects and how they change based on
events or conditions.
 State diagrams can be used to show how an object's state changes over time as it interacts with other
objects and receives stimuli.
 This is especially useful for modeling objects that have complex behavior or states, such as order status
or customer membership status.

Example: In an E-Commerce System, a Order object could have different states such as Pending, Paid,
Shipped, and Delivered. A state diagram could model these state transitions.
Summary of Activities:

Activity Description

Identifying Entity Objects Identify the objects that represent the core business data.

Identify objects that manage interactions between the system

Identifying Boundary Objects
and its environment.

Identify objects that manage system behavior and execute use

Identifying Control Objects
cases.

Mapping Use Cases to Objects with Use sequence diagrams to show interactions between objects
Sequence Diagrams for use cases.

Use CRC cards to define class responsibilities and

Modeling Interactions with CRC Cards
collaborations.

Identifying Associations Identify relationships (associations) between objects or classes.

Identifying Aggregates Identify groups of objects that are treated as a unit.

Identifying Attributes Identify properties (data) associated with an object.

Model how the state of objects changes based on events and

Modeling State-Dependent Behavior
interactions.
 Analysis activities (UML activities diagram)

Managing Analysis:
Managing Analysis in a multi-team development project is a crucial activity to ensure that all teams involved
work together efficiently and that the end result is a coherent, unified system. The primary challenge is to maintain
consistency and alignment across different teams, all of whom may be working on different aspects of the project.

In the end, the requirements analysis document should present a system that can be easily understood by all
stakeholders, including clients, team members, and decision-makers.

It includes,
 Documenting Analysis
 Assigning Responsibilities
 Communicating about Analysis
 Iterating over the Analysis Model
 Client Sign-Off
Documenting Analysis:

Documenting analysis involves clearly recording all the information related to the system’s requirements, its
behavior, and the relationships between different components. This documentation serves as the foundation for
communication and collaboration among teams.

 What it includes: The analysis document typically contains the detailed requirements, use cases,
object models, interaction diagrams, and other relevant information that describe how the system should
function.
 Purpose: It provides a reference point for all teams, ensuring that everyone has the same understanding
of what the system needs to achieve.

Example: In a Library Management System, the analysis documentation would describe the use cases for
borrowing books, adding books, searching for books, and generating reports.

Assigning Responsibilities:
 Assigning responsibilities is about ensuring that each team or individual is clear on their roles and what they
are responsible for. This helps avoid confusion, overlapping work, and ensures that the right people are
working on the right parts of the system.
 There are three main types of roles: generation of information, integration, and review.
 The end user is the application domain expert who generates information about the current system, the
environment of the future system, and the tasks it should support.
 The client, an integration role, defines the scope of the system based on user requirements. Different users
may have different views of the system, either because they will benefit from different parts of the system
(e.g., a dispatcher vs. a field officer) or because the users have different opinions or expectations about the
future system. The client serves as an integrator of application domain information and resolves
inconsistencies in user expectations.
 The analyst is the application domain expert who models the current system and generates information about
the future system. Each analyst is initially responsible for detailing one or more use cases.
 The architect, an integration role, unifies the use case and object models from a system point of view.
Different analysts may have different styles of modeling and different views of the parts of the systems for
which they are not responsible. Although analysts work together and will most likely resolve differences as
they progress through analysis, the role of the architect is necessary to provide a system philosophy and to
identify omissions in the requirements.
 The document editor is responsible for the low-level integration of the document and for the overall format
of the document and its index.
 The configuration manager is responsible for maintaining a revision history of the document as well as
traceability information relating the RAD with other documents.
 The reviewer validates the RAD for correctness, completeness, consistency, and clarity. Users, clients,
developers, or other individuals may become reviewers during requirements validation. Individuals that have
not yet been involved in the development represent excellent reviewers, because they are more able to identify
ambiguities and areas that need clarification.

Communicating about Analysis:

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.

Iterating over the Analysis Model:

 Analysis occurs iteratively and incrementally, often in parallel with other development activities such as
system design and implementation. Note, however, that the unrestricted modification and extension of the
analysis model can only result in chaos, especially when a large number of participants are involved.
 Iterations and increments must be carefully managed and requests for changes tracked once the requirements
are baselined. The requirements activity can be viewed as several steps (brainstorming, solidification,
maturity) converging toward a stable model.

Brainstorming
Before any other development activity is initiated, requirements is a brainstorming process. Everything—concepts
and the terms used to refer to them—changes. The objective of a brainstorming process is to generate as many
ideas as possible without necessarily organizing them. During this stage, iterations are rapid and far reaching.

Solidification
Once the client and the developers converge on a common idea, define the boundaries of the system, and agree
on a set of standard terms, solidification starts. Functionality is organized into groups of use cases with their
corresponding interfaces. Groups of functionality are allocated to different teams that are responsible for detailing
their corresponding use cases. During this stage, iterations are rapid but localized.

Maturity
Changes at the higher level are still possible but more difficult, and thus, are made more carefully. Each team is
responsible for the use cases and object models related to the functionality they have been assigned. A cross
functional team, the architecture team, made of representatives of each team, is responsible for ensuring the
integration of the requirements (e.g., naming).

Client Sign-Off:
 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. In its
simplest form, it allows developers to separate bells and whistles from essential features. 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.