Question

MOST POPULAR : Business Analyst Interview Question:

1.What is process modeling?

2.How do you capture functional requirements?

3.What is a use case Framework?

4.Explain Use Cases?

Answer 1

Process Modeling -

Process modeling is the concise description of the total variation in one quantity, y, by partitioning it into

1. a deterministic component given by a mathematical function of one or more other quantities, x1, x2, ... , plus
   
2. a random component that follows a particular probability distribution.

For example, the total variation of the measured pressure of a fixed amount of a gas in a tank can be described by partitioning the variability into its deterministic part, which is a function of the temperature of the gas, plus some left-over random error. Charles' Law states that the pressure of a gas is proportional to its temperature under the conditions described here, and in this case most of the variation will be deterministic. However, due to measurement error in the pressure gauge, the relationship will not be purely deterministic. The random errors cannot be characterized individually, but will follow some probability distribution that will describe the relative frequencies of occurrence of different-sized errors.

2. Capturing functional requirements -

Functional requirements are product features or functions that developers must implement to enable users to accomplish their tasks. So, it’s important to make them clear both for the development team and the stakeholders. Generally, functional requirements describe system behavior under specific conditions. For instance:

A search feature allows a user to hunt among various invoices if they want to credit an issued invoice.

Requirements are usually written in text, especially for Agile-driven projects. However, they may also be visuals. Here are the most common formats and documents:

• Software requirements specification document
• Use cases
• User stories
• Work Breakdown Structure (WBS) (functional decomposition)
• Prototypes
• Models and diagrams

Use cases -

Use cases describe the interaction between the system and external users that leads to achieving particular goals.

Each use case includes three main elements:

Actors. These are the users outside the system that interact with the system.

System. The system is described by functional requirements that define an intended behavior of the product.

Goals. The purposes of the interaction between the users and the system are outlined as goals.

There are two formats to represent use cases:

• Use case specification structured in textual format
• Use case diagram

A use case specification represents the sequence of events along with other information that relates to this use case. A typical use case specification template includes the following information:

• Description
• Pre- and Post- interaction condition
• Basic interaction path
• Alternative path
• Exception path

A use case diagram doesn’t contain a lot of details. It shows a high-level overview of the relationships between actors, different use cases, and the system.

The use case diagram includes the following main elements:

Use cases. Usually drawn with ovals, use cases represent different use scenarios that actors might have with the system

System boundaries. Boundaries are outlined by the box that groups various use cases in a system.

Actors. These are the figures that depict external users (people or systems) that interact with the system.

Associations. Associations are drawn with lines showing different types of relationships between actors and use cases.

User stories

A user story is a documented description of a software feature seen from the end-user perspective. The user story describes what exactly the user wants the system to do. In Agile projects, user stories are organized in a backlog, which is an ordered list of product functions. Currently, user stories are considered to be the best format for backlog items.

User stories must be accompanied by acceptance criteria. These are the conditions that the product must satisfy to be accepted by a user, stakeholders, or a product owner. Each user story must have at least one acceptance criterion. Effective acceptance criteria must be testable, concise, and completely understood by all team members and stakeholders. They can be written as checklists, plain text, or by using Given/When/Then format.

All user stories must fit the INVEST quality model:

•         I – Independent
•         N – Negotiable
•         V – Valuable
•         E – Estimable
•         S – Small
•         T – Testable