Module 2

Incepting enterprise application and business process

modelling

Enterprise analysis, business modelling, Case study of EM

Bank, requirements elicitation and analysis, use case
modelling, User prototypes, Nonfunctional requirements,
requirements validation, Planning and estimation.
The New Business Environment
•Digital companies like Amazon, eBay, and Google have seen tremendous
growth.
•"Brick-and-mortar" businesses (Walmart, Tesco) have adapted with multi-
channel commerce.
•Service industries (banks, telecom) use technology as a core backbone.
•All these companies rely on complex business processes and systems
•The Need for Complex Systems
•High-volume, complex businesses require sophisticated software systems.
•These systems must cater to the needs of customers and other
stakeholders.
•"Inception" is the critical first step in building these systems.
What is Inception?
•Inception is the initial phase of an enterprise application's lifecycle.
•Its purpose is to:
•Determine the problem and need for the application.
•Establish the project's scope.
•Analyze feasibility.
•Create a roadmap for future development.
• Core Inception Activities
• Enterprise analysis
• Business modeling
• Requirements elicitation and analysis
• Requirements validation
• Planning and estimation
Enterprise Analysis
•Continuity and sustained growth are of paramount important to any enterprise.
•Enterprise analysis deals with questions such as, "Why is a given system
needed?" or "Why does a given system need change?"
•As part of enterprise analysis, a business analyst performs the following
activities:
•Identifies the business opportunities and business changes.
•Identifies stakeholders across business units.
•Collects and prioritizes the business requirements.
•Defines the business roadmap with scope and exclusions.
•Determines the high-level investment needed for the enterprise.
•Conducts a feasibility study and risk and competitive analysis.
•Decides on a build-or-buy strategy.
•Creates "Return on Investment" (ROI) business cases.
•Gets the necessary approvals from the sponsors.
Business Modeling
•Business modeling helps to understand business processes and information in
detail.
•This can lead to two types of projects: "development" (creating a new system) or
"reengineering" (extending or changing an existing one).
•It is crucial to document and validate business processes so business users can
verify them.
•A key activity is creating "as-is" (existing) and "to-be" (desired) business process
models.
•These models help to identify deficiencies and provide insights for improvement.
•Tools for business modeling can range from a simple whiteboard to a sophisticated
tool like Enterprise Modeler®.
Case Study: EM Bank

•EM Bank (Easy Money Bank) is a leading

global bank headquartered in Europe.
•It offers services in core banking,
investment banking, mortgage, foreign
exchange, and wealth management.
•As depicted in Figure 2-1, EM Bank has
a single channel (only through bank
branch) to offer loans)
•EM Bank's core banking segment
provides loans to retail customers.
•In response to market trends, the bank is
expanding its loan offerings using multiple
channels.
Loan Management Process - "As-Is"
Model
•The process involves the following roles:
•Prospect/Customer: Enrolls or applies for a loan.
•Bank Representative: Collects customer information and documents.
•Credit Rating/Loan System: Validates credit history and provides a pre-
approved amount.
•The process concludes with the bank representative approving and
disbursing the loan amount.
 Loan Management Process - "To-Be"
Model
•After analyzing the "as-is" business process, the following "to-be" process (as
illustrated in Figure 2-2) is identified in order to meet the objective of expanding loan
offerings:
•Pre-approved loan amount is now based on a customer's credit rating, provided by
an external agency.
•Document submission can be done by customers online or by a bank representative
digitizing physical documents.
•A "Document Verification/Approval" role is introduced for a more streamlined
process.
•The system automatically checks credit history and retrieves the customer's credit
rating.
•The pre-approved amount is now based on the customer's credit rating.
•Customers can request to enhance their loan amount. The process ends with the
loan disbursement.
Introducing the Loan Management
System (LoMS)

•To accomplish the "to-be" process, a new Loan Management System (LoMS)
will be developed.
•LoMS will have functionalities from loan initiation to disbursement and will be
used by both bank customers and staff.
•The LoMS application will be used as a case study in subsequent chapters to
understand the lifecycle of raising enterprise applications.
Requirements Elicitation and Analysis
•After business modeling, the next step is to detail out the requirements.
•These detailed requirements will then be analyzed for completeness and validated for feasibility and
correctness.
•This is a systematic approach for capturing, analyzing, and documenting client requirements.
•It is based on the business process models and can be done through:
•Reviewing existing systems and documentation.
•Interviewing IT personnel.
•Prototyping.
•Good requirements are SMART:
•Specific
•Measurable
•Attainable
•Realizable
•Testable/Traceable/Time bound
•Types of Requirements:
•Functional Requirements: Define what the system is expected to do. Often depicted through "use
cases" and prototypes.
•Nonfunctional Requirements (NFRs): Define how the system should perform with respect to
quality and constraints, such as reliability, scalability, portability, usability, security, and performance.
Actors and Use Cases
•Functional requirements are determined by identifying the entities that use the system (actors) and
their reasons for using it (use cases).
•Actors represent a role, not a specific user, and can be humans, external systems, or external devices.
Identifying Actors:
•Ask, "Who is going to use the system?"
•In LoMS, actors include: Customer, Reviewer, Approver, Accounting System, and Credit Rating
System.
•Don't assume actors are only humans.
Identifying Use Cases:
•Ask, "Why does an actor need to interact with the system?"
•A use case is a functional reason for an actor to interact with the system.
•For LoMS, examples include "initiate loan" and "provide credit rating".
UML and Use Case Diagrams:
•Use Case diagrams are part of UML (Unified Modeling Language), a visual language for modeling
systems.
•They show the relationship between actors and use cases.
•The diagram's complexity should match the project's needs.
Use Case Relationships
•The LoMS Use Case Diagram 2.3 shows
several use cases and actors. The "initiate loan"
use case has an association relationship with
four actors: Customer, Bank Representative,
Credit Rating System, and Accounting System.
• Human Actors: customer, bank
representative
•External System Actors:Credit rating system,
accounting system
•An association relationship is the simplest
relationship, depicted with a straight line. For
example, the "initiate loan" use case is
associated with four actors: Customer, Credit
Rating System, Accounting System, and
•Relationship Type: Generalization relationship.
•Actors Involved:
•Generalized Actor (the "parent" or more general
type): bank executive
•Specialized Actors (the "children" or more
specific types):
•bank representative
•approver
•document verifier
•Meaning: The bank executive actor is a
generalization of the other three actors. This
implies that bank representative, approver,
and document verifier are all specific types of
A generalization relationship among use
cases exists when a specific use case is a
specialized version of a more general one .
•Generalized Use Case: Initiate Loan
•Specialized Use Cases:
•Initiate Loan by Customer
•Initiate Loan by Bank Representative
This relationship means that the specialized
use cases inherit the properties and behavior
of the Initiate Loan use case but also
contain their own specific
characteristics.
An "extends" relationship between use cases has the
following characteristics:
•When it exists: It occurs when the behavior of one use case
(the extension use case) can be optionally inserted into
another use case (the extended use case) under certain
conditions.
•Extended Use Case (the main use case): Initiate Loan
•Extension Use Case (the optional behavior): Provide
Credit Rating
•Condition for insertion: The Provide Credit Rating
behavior is inserted into the Initiate Loan process only if
the pre-approved loan amount has not been updated in the
last six months.
•Representation: The relationship is shown as a dashed
arrow that points from the extension use case (Provide
Credit Rating) to the extended use case (Initiate Loan).
An "includes" relationship (also known as a "uses" relationship)
between use cases has the following characteristics:

•When it exists: It occurs when the behavior of one use case (the
included use case) is always a part of another use case (the
including use case).
•Including Use Case (the main use case): Initiate Loan
•Included Use Case (the sub-process): Provide Customer
Information

•Condition: The Provide Customer Information use case is

always processed as part of the Initiate Loan use case.
•Representation: The relationship is shown as a dashed arrow
that points from the including use case (Initiate Loan) to the
included use case (Provide Customer Information).
•Best Practice: The text notes that it is only a good idea to extract
a use case as an "included" use case if it is shared and used by
more than one other use case. This promotes reusability and
modularity in the design.
Example - 1
Example - 2
 Use Case Specification (UCS) document is a textual description that
complements a use case diagram by providing a detailed breakdown of a use
case's functionality as shown in the Table 2.1.
UCS elements Description
Actors List of participating actors in the use case.
Description A brief description of the use case.
Preconditions List of prerequisites to start the use case.
Post-conditions List of things which are the outcome of the use case.
Priority Business criticality is quantified and presented in a relative manner.
Trigger The event that initiates the use case.
The primary flow of the use case. The primary scenario is the most frequently occurring
Primary scenario scenario in the entire use case.
Alternate scenario # number List of alternate flows. These typically occur less frequently than the primary flow.

The "significant" nouns are collected from various scenarios and are jotted down along
with the specifications such as size of the field, type of the field, possible values, and
Field definitions default values. These act as an input to design the data models in the successive phase.
Exceptions List of exceptional flows.
Assumptions Assumptions, if any.
User Interface Reference to the prototype(s)/wireframe(s).
List of related use cases. Use cases that are included or have an extension are listed
Related use cases here.
Nonfunctional requirements Capture NFRs specific to this particular use case.
User Prototypes
Purpose of Prototypes:
•Stakeholder Validation: They allow business users to validate the user interface early, helping to
manage expectations and secure "buy-in" to prevent last-minute issues.
•UI Design Blueprint: UI designers use them as a blueprint to achieve a consistent look and feel and
gain comfort with the design.
•Usability Requirements: They help business analysts and UI designers identify usability requirements,
such as navigability.
•Understanding Use Cases: They give business analysts a better tool for understanding exceptions and
variations within use cases.

Best Practices for Designing Prototypes

• Choose the Right Tool: While tools like Microsoft PowerPoint can be used, it's considered
a good practice to use HTML as the basis for prototyping.
• Use Realistic Data: The sample data used in a prototype should be representative of real
data.
• Focus on Primary Scenarios: Prototypes should primarily concentrate on the main
scenario of a use case. Only consider prototyping alternate scenarios if they are deemed
critical.
What are Nonfunctional Requirements (NFRs)?
• Nonfunctional requirements are characteristics and constraints of an
application, in contrast to its functional behavior.
• They are of paramount importance for any enterprise application and must be
carefully captured, documented, and considered during development.
• NFRs have a high impact on how a system is architected, designed, and
deployed.
Examples of NFRs for a Loan Management System (LoMS):
Performance: Ability to process 1,000 loan applications in a day.
Scalability: Support for a 20% average growth in the volume of loan
applications each year.
Usability: Support for Internet Explorer versions 6 and 7; availability of context-
sensitive help.
Maintainability: Having a maintainable code base.
Reliability: Ability to avert faults from underlying application servers and
database servers.
Security: Not being prone to injection attacks.
 Table 2-2: Key NFRs and Their
Descriptions
Key NFRs Description
Performance Constraints like throughput, response time, and refresh time under
requirements normal and peak loads.
Effective use of screen real estate, navigability, localization and
Usability requirements internationalization, browser support, and accessibility
requirements.
Resource utilization, data storage requirements, and projected
Scalability
growth metrics, which can be used for better capacity planning and
requirements
management.
Dictate the mechanisms followed for an application's
Interface requirements
interoperability or integration with existing enterprise applications.

Security, maintainability, and reliability requirements. Metrics

Operating captured for reliability include Recovery Time Objective (RTO),
requirements Recovery Point Objective (RPO), and Mean Time Between Failures
(MTBF).

Lifecycle requirements Testability, reusability, portability, and installability requirements.

Regulatory
Legal and licensing requirements.
 Performance Requirements
Performance requirements are constraints that must be identified for each critical
use case under specific conditions. They are crucial for ensuring the system
performs as expected.
Key Determinants of Performance:
The performance of an enterprise application is determined by three key factors:
[Link] of a system: This includes factors like the number of user requests,
think time (the time a user takes to perform an action), and the rate at which
requests arrive. These factors are used to specify the system's throughput, which
is defined as the amount of work a system can perform in a given period.
[Link] server software: This includes the operating system, application servers,
and database servers.
[Link] hardware: This includes components like processors, disks, memory,
and network.
 Perspectives for Categorizing Performance Requirements:
Performance requirements can be viewed from two main perspectives:
(a) Business perspective: This perspective captures requirements related
to the business context, such as:
• Types of transactions.
• Types of users.
• User usage patterns.
• Request arrival patterns.
These are used to measure the workload and throughput of the system.
(b) Technology perspective: This perspective captures requirements
related to the technical environment, such as:
• Operating environment details.
• System and interface details.
• Performance boundaries with external systems.
These are used to measure resource utilization and system response time.
 Example Performance Requirements for LoMS
(from the Technology Perspective):

The Loan Management System (LoMS) should be able to:

• Process a peak of 60 and an average of 40 concurrent transactions per
second.
• Support 250 concurrent user sessions.
• Process 1,000 loan applications in a day.
• Maintain a maximum page-refresh time of not more than 5 seconds for
online transactions.
Important Notes:
• Different types of transactions (user interaction, batch, report generation)
should have their throughput and response time metrics captured
separately.
• Performance requirements are used to conduct various tests, including
load tests, volume tests, stress tests, and endurance tests.
 Usability Requirements
Usability requirements dictate the user experience and can significantly
impact the acceptance of an application by end users. They are one of the
most important nonfunctional requirements (NFRs) from the perspective of
the user.
Example Usability Requirements for LoMS:
In the case of the Loan Management System (LoMS), the system should:
• Guided Process: Guide customers and prospects through the loan initiation
process.
• Pre-population: For existing customers, the loan information should be pre-
populated.
• Easy Navigation: Provide easy navigation combined with an easy workflow.
• Internationalization: Support internationalization so it can be localized for
different user bases.
• Context-Sensitive Help: Make context-sensitive help available to the user.
 Simple Rules for a Smooth User
Experience:
Several "thumb rules" to ensure a smooth user experience:
• Efficient Screen Usage: Use screen real estate properly by logically
grouping items and placing content in appropriate locations. This helps
users understand the screen better and reduces the time needed to
perform actions.
• Intuitive Navigation: Design an application with easy-to-use and
intuitive navigation. Avoid excessive switches between mouse and
keyboard or too many dialog boxes. Tab sequences should be clearly
defined for keyboard input.
• Automation: Use auto-populate and auto-complete features in forms to
save user time and reduce data entry mistakes.
• Internationalization: Carefully implement internationalization to
provide a "personalized" experience by allowing users to interact with the
application in their preferred language.
• Browser Support: Ensure the application supports popular browsers.
 Scalability Requirements
Scalability requirements define a system's ability to maintain its performance as the number of users
and the volume of data grow. Addressing scalability requires careful and detailed capacity planning
and management.
The Impact of Growth: In a typical enterprise application, user numbers and data volume will
increase over time. This growth can directly impact the system's throughput and overall
performance.
Example Scalability Requirements for LoMS:
For the Loan Management System (LoMS), the scalability requirements state that the system should
be able to support an average annual growth of 20 percent in the volume of loan applications.
To plan for this, the data storage requirements must be identified. The text provides a calculation
example:
• Average size of a loan application: 1 MB
• Applications processed per day: 1,000
• Daily data storage requirement: 1,000 applications/day * 1 MB/application = 1 GB/day
• Additional data: Requirements for attachments (verification documents) must also be captured.
These data storage requirements, combined with projected growth factors, help in determining the
optimal database size for the application.
Achieving Scalability: two main approaches to achieve scalability:
[Link] Scaling: "Topping up" resources (like adding more memory or faster processors) to the
existing system.
[Link] Scaling: Adding separate physical systems or machines to the existing ones.
Interface Requirements
Interface requirements define the interoperability and integration needs
of enterprise applications. Applications should not exist in isolation ("silos");
they must be able to coexist and interact within the broader enterprise
ecosystem by providing or consuming services to automate business
processes.
Common Integration Mechanisms:
Enterprises typically use the following mechanisms for integration:
• Integration at the application's User Interface level.
• Integration at the business data level.
• Integration at the business process level.
1. Integration at the Application's User Interface (UI) Level
• This is the most rudimentary and often the least desirable form of
integration.
• This method involves one application displaying or interacting with the
user interface of another application. It's often used when an application
lacks a programmatic API.
• Mechanisms:
• Screen Scraping: An application programmatically reads and extracts data
directly from the user interface (e.g., HTML or a desktop application's UI) of another
application.
• Portals: A centralized web portal or dashboard that embeds sections or frames
from different, isolated applications.
Example: A business analyst manually copying data from one
application's screen and pasting it into another's.
2. Integration at the Business Data Level
• This approach focuses on sharing data directly between applications,
bypassing their user interfaces.
• Applications exchange data through a common format or a shared
storage location.
• Mechanisms:
• Shared Databases: Multiple applications read from and write to the same
database. This is a very tight form of coupling.
• File Transfer: Applications exchange data by exporting and importing files (e.g.,
CSV, XML, or JSON files) via a shared network drive or FTP.
• Message Queues: Data is sent as messages to a shared queue, from which other
applications can consume it asynchronously.
• Example: A warehouse manager exporting a list of inventory items to a
spreadsheet for the sales department to import.
3. Integration at the Business Process Level
• This is the most modern, robust, and preferred method of enterprise
integration. It focuses on connecting the logic and functions of different
applications to automate a complete business process.
• Applications communicate with each other through well-defined and
standardized APIs (Application Programming Interfaces). These APIs act
as contracts, specifying how one application can request a service or
share information with another.
• Mechanisms:
• Web Services (SOAP/REST): Applications use standardized protocols (like HTTP)
to send requests to and receive data from each other.
• Event-Driven Architecture: Applications publish events (e.g., "New Order
Placed"), and other applications that are interested in that event (e.g., the
"Shipping" service) automatically react to it.
• Example: A restaurant's order system sends a request to the kitchen's
system to start cooking, and the kitchen's system sends a request to the
delivery service when the food is ready. Each system has its own
function but interacts seamlessly to complete the order.
Questions to Help Gather Interface Requirements:
A set of simple questions that can help in gathering these requirements:
• What are the trigger events for communication to happen between
applications?
• What are the methods to facilitate communication between applications? Is
there a constraint on using a specific communication protocol, device, or
format?
• What is the structure in which data has to be passed between applications?
• What are the mechanisms to handle errors during communication?
• Does the interface cross the technology domain?
Example Interface Requirements for LoMS:
In the case of the Loan Management System (LoMS), the interface requirements
state that the system needs to integrate with:
• A credit rating system that exists outside the organization's boundaries.
• An accounting system that is part of the organization's internal enterprise
application landscape.
Operating Requirements
Operating requirements are constraints on an enterprise application that define its security,

maintainability, and reliability. These are typically categorized into the following types:
1. Security Requirements
Security requirements are usually broken down into two types:
• Network Security Requirements: These include requirements related to firewalls,
routers, and intrusion detection systems to secure the application's deployment
infrastructure.
• Application Security Requirements: These cater to the implementation of "Security's
AAA" - Authentication, Authorization, and Auditing. For Internet-facing applications like
the Loan Management System (LoMS), additional requirements are needed to safeguard
against Web security vulnerabilities such as Cross-Site Scripting (XSS), SQL injection, etc.
They also include user-session-related requirements like configurable session timeouts,
preventing repeated unsuccessful login attempts, and rejecting concurrent logins by the
same user.
2. Maintainability Requirements
Maintainability relates to an application's manageability and analyzability. Required monitoring
facilities and configuration capabilities are documented as manageability requirements.
Requirements for things like log files, audit trails, and monitoring support are captured as
analyzability requirements.
3. Reliability Requirements
Reliability requirements include the system's availability and recoverability.
• Availability: An example is the LoMS availability requirement of 99.999
percent, which translates to fault tolerance and load balancing mechanisms.
• Recoverability: This is described using two key metrics:
• Recovery Time Objective (RTO): The maximum amount of time allowed for a system
to recover to a functional state after a failure. For LoMS, the RTO is set at 10 minutes.
• Recovery Point Objective (RPO): The maximum amount of data loss that is
acceptable after a failure. For LoMS, the system should recover with no more than 30
minutes of old transaction data.
• Mean Time Between Failures (MTBF): This is the average time between
system failures. For LoMS, the MTBF should be more than three months.
Lifecycle Requirements
Lifecycle requirements refer to the needs that an application must fulfill
during one or more stages of its lifecycle.
[Link] requirements: These define the quality of an application
that allows it to be tested comprehensively without requiring excessive
effort.
[Link] requirements: These capture aspects of a system that
should be designed for reuse, and for which reusable components
should be developed.
[Link] requirements: These specify the hardware and operating
system platforms on which the system must be capable of being
deployed.
[Link] requirements: These capture requirements related to
the installation process, such as the mode of installation (automated or
manual), and the need for installation guides and scripts. These
requirements are crucial for planning the rollout of an application.
 Regulatory Requirements
Regulatory requirements capture legal requirements and restrictions, especially
concerning:
• Handling of sensitive data: They specify how certain categories of
sensitive data must be processed.
• Data maintenance and archival: Some regulations require specific data to
be maintained within a country or to be archived for a specified duration.
The Software Requirement Specification (SRS) Document
• The SRS is a master document that serves as a starting point for the
development of an enterprise application. It provides assurance to both the
client and the development team.
• The SRS is derived from the system specification document by detailing how
the system under development will meet the functional requirements.
• It documents the functional and nonfunctional requirements that are identified
during the requirement elicitation and analysis phase.
• A template for an SRS is described by the IEEE Standard 830-1998.
Table 2-3: Typical Elements of a Software Requirement
Specification (SRS)
SRS elements Description
Business
A brief overview of what an enterprise does.
overview
System
An overview of the system under consideration.
overview
Functionality A list of the business functionality in an unambiguous
list form.
The list of identified use cases and their respective
Use cases
attached use case specification documents.
Prototypes Wireframes of the primary functionalities.
NFR list A list of nonfunctional requirements.
 Requirements Validation?

• It is a process, usually facilitated by business analysts, to ensure that the

documented requirements align with the business objectives.
• It is a crucial step that helps ensure the future adoption and usage of the
enterprise application by business users.
Key Activities of Requirements Validation:
Although requirements analysis and validation are often performed together,
the validation process itself typically involves three main activities:
[Link] Coverage: Verifying that all business needs identified during
the requirements elicitation phase are covered.
[Link] Sanctioning: Ensuring that the requirements documentation
is formally approved ("sanctioned") by subject matter experts (SMEs) and
end users.
[Link] Check: Ensuring the feasibility of the requirements to the
greatest extent possible.
 The Requirements Traceability Matrix
(RTM):

•Requirements that are elicited need to be

validated for completeness, ensuring that the Functiona
l Design
Use case Code Test case
target solution addresses all business needs. requirem
ent
element

This is typically done by creating an RTM. Req1.1-

UC01- Existing Loan Class
LoanInitiationTest
Initiate customers initiation LoanInitiatio
•A traceability matrix is a table that maps Loan can initiate design n
#1
the loan
requirements to different development artifacts, LoanInitiationTest
#2
providing a clear path from a requirement to its
LoanInitiationTest
#3
implementation and testing.
UC02- - - - -
Example (Table 2-4):
Feasibility Requirements
• Requirements validation also includes ensuring the feasibility of
requirements, from both a business and a technical perspective.
• This analysis checks if the proposed solution complies with
organizational technical standards and guidelines and if it can
coexist within the existing enterprise application landscape.
2. Proof of Concepts (PoC)
• A Proof of Concept (PoC) is a minimal solution developed to
validate the feasibility of a requirement, especially for complex
situations. It helps in articulating functional specifications and
converting them into software requirement specifications.
• Benefits:
• It helps validate requirements from multiple perspectives.
• Although time-consuming, it is a worthwhile effort for validating complex
requirements.
3. The Requirements Traceability Matrix (RTM)

• The RTM is a tool for managing requirements throughout the Software Development
Lifecycle (SDLC). It maps requirements to design, development, and deployment
artifacts.

• Benefits:
• It provides traceability from a coverage perspective: By mapping requirements to design,
code, and test cases, it guarantees that every business need is addressed and verified.
• It helps in managing requirements through the various phases of the SDLC: It provides
a clear way to track a requirement's journey from initial concept to final implementation and
deployment.
• It helps in precisely locating related software elements.
• It can save a significant amount of time during impact analysis and maintenance activities.

• Tools: An RTM can be created using simple tools like plain spreadsheets or
specialized software like Rational RequisitePro.
4. Validation Techniques

• Invalid Requirements: A requirement that is inconsistent, incorrect,

ambiguous, unacceptable, or non-testable is considered an invalid
requirement.

• Review by SMEs and End Users: A key validation technique is the thorough
review of requirements by Subject Matter Experts (SMEs) and end users.

• Prototypes and Wireframes: Requirements for specific artifacts like User

Interfaces (UI) are typically validated by end users using prototypes or
wireframes.

• User Acceptance Test (UAT) Cases: Another important technique is to

prepare UAT cases. A review of these cases helps end users validate the
requirements.
Planning and Estimation
Planning
• Initiation: The requirements analysis phase leads to the development
of a business case, which is the primary input for creating the project
charter.
• Process: Project planning is primarily done by a project manager,
with business analysts and architects playing a crucial role by
providing the necessary information.
• Activities: Detailed planning involves stakeholders making decisions
about the project. It answers key questions such as:
• Who is involved?
• When will the project start?
• What are the dependencies?
• What efforts are involved?
Estimation
•Definition: Estimation is the process of identifying the cost, schedule, size, and
effort required for project planning.
•Purpose: It strengthens planning and is a core component of it.
•Process: Project estimation is typically done by project managers with the help of
business analysts, technical architects, and SMEs. The earlier a phase is in the
lifecycle, the less information is available, and the less accurate the estimation.
•What is Estimated? Estimation focuses on the project's size and the required
effort.
•Project Size: Estimated in Lines of Code (LOC) or Function Points (FP).
•Project Effort: Typically measured in person-months. Effort is related to a
"productivity factor" which varies based on the team and organization.
Popular Estimation Techniques
There are several techniques for estimating time, effort, and scope:
[Link] estimation:
1. A typical "order of scale" estimation.
2. Used in the early stages when requirements are not yet clear and implementation details
are unavailable.
3. This technique relies on heuristics, past data from similar projects, and industry
standards.
[Link] Case Point estimation:
1. A popular software sizing and estimation technique.
2. It is based on the use case model developed during the requirements elicitation and
analysis phase.
[Link] Point (FP) estimation:
1. Based on FP counts.
2. A Function Point is a unit used to measure the functional size of the software.
3. This method requires a fully documented functional specification.
4. The way FP is applied to estimate a solution depends on the project's nature (e.g.,
enhancement vs. new greenfield project, client/server vs. GUI-intensive vs. object-
oriented systems).
Final Outcome of Estimation
• Effort to Duration: The estimated project effort is used to determine the
project's duration and schedule.

• Duration: A function of effort, resource availability, constraints, and

minimum elapsed time.

• Schedule: The schedule is typically prepared by the project manager with

assistance from business analysts, technical architects, and SMEs.

Once requirements are elicited, analyzed, and validated, and resources and
time have been planned and estimated, the project is ready to move to the
next phase of the SDLC: architecting and designing enterprise
applications.
 Summary of the Chapter
This chapter introduced several key concepts related to enterprise application analysis and business
process modeling:
• Business Process Modeling: The "as-is" and "to-be" business process modeling concepts were
introduced. The chapter used a sample LoMS (Loan Management System) case study to illustrate how
these concepts are applied to build a business case for an enterprise application.
• Requirements Elicitation and Analysis: The chapter covered the process of eliciting and analyzing
both functional and nonfunctional requirements.
• Use Case Diagrams: It explained use cases, use case diagrams, actors, and the various relationships
that exist in use case diagrams, using the LoMS application as an example.
• Prototypes: The importance of prototypes and the best practices for creating them were also
discussed.
• Nonfunctional Requirements (NFRs): The chapter introduced the concept of NFRs and their different
types.
• Software Requirement Specification (SRS) Document: A template for the SRS document was
presented.
• Requirements Validation: The concept of requirements validation was introduced. It discussed several
methods for ensuring proper documentation of requirements, including the requirements traceability
matrix (RTM), review and approval processes, and preparing user acceptance test cases. The use of a
Proof of Concept (PoC) as a key tool for validating requirements was also highlighted.
• Planning and Estimation: The chapter concluded with an introduction to the concepts of project
planning and estimation. It also introduced popular estimation techniques like Use Case Point
estimation and Function Point (FP) estimation.