Post 5_ Business Rules

So where do we place Business rules? In the use case or separately?

Well its at the discretion of the Business Analyst. According to me, Business rules should be kept separate because:

1. Business rules can be used across many use cases
2. They change often than the Use Cases

Use cases are about user - system interaction. Business rules are more about logic and reasoning.

If use Cases are documented in Word then business rules can be written as a part of Use case.
However creating a matrix of Business Rules and Use Cases enables the business analyst to maintain and avoid rework on each use case.

An effective way of presenting a business rule is to emphasize on only 1 concept. They govern an organization regardless of the process/work flow followed to achieve them. For example achieving sales target. Business Rules can be:

1. Access control issues
2. Derivation: Pertaining to business calculation
3. Policies of the organization
4. Constraints: enables or prohibits action

Components of Business Rules:
- Name: One liner.
For example: Minimum funds required for investment.
- Unique Identifier
For example: BR 001
- Description: It describes the rule in detail. This can be explained in text or UML activity diagram if there is an algorithem required.
For example: The investor needs to maintain minimum funds of $100,000 for investing in new hedge fund strategy. If investing in an existing strategy then minimum requirement is $50,000.
- Source : It can be reference document or any business user name.
- Related rules : To maintain tracebility.
- Revision History : Description of the change, who made the change and when was it made.
- Effective Date: Date from which it is valid.
- Expiration date: Till when its valid

Maintaining Business Rules

Best way to maintain business rules is in X - Y Matrix. This Matrix creates a link between FR ID and UC ID. So anytime business analyst needs to update a business rule, it just have to go to the matrix rather than eah individual use case.


FR - UC Matrix











If we talk about Agile methodology then UML Activity diagrams are the best way to communicate requirements. In the previous post we mentioned UML Use case diagrams as well.

So it makes sense to move to UML Diagrams.

Post 4_Writing Use Cases.

Okay Now lest focus on writing Use Cases.

So What do you understand by Use Cases? and why do we write them at all ?

Use Case is a step by step description how the user and system interact to accomplish a goal, where user can be human or another system. They are part of System Requirement Specification (SRS) document.

Use Cases provide the writer and reader with following benefits:

1. Simple to write
2. Easy to understand for stakeholders to validate requirements
3. Scenario's mentioned can be easily converted into test cases

Type of Use Cases:

• Primary / Sunny day Use Cases : 20% of the use cases are used by 80% of the activity
• Rainy day Use Cases : Prioritize them as per the development cost in something not likely to happen.

Use Case has the following parts to it :

- Descriptive Name

- Description: This is the purpose of Use case to exist.

- Trigger: Initiator of the use case. It need not happen for sure. Its just that this particular event triggers the start of the use case. This can be a business rule or it can be an external event. for example: Providing customer support periodically OR Customer calling for customer service.

- Precondition: There are two types of precondition:

1. A precondition is the state of the system and its environment that is required before the use case can be started. For example:: Appointment should exist in the system before the patient can visit the Doctor.
2. CRUD ( Create, Retrieve, Update and Delete). These are trivial requirements. Define them but dont spend to much time on them.

- Actor: Its a role performed by the user. It could be a buyer, seller, paypal (another system), agent. Actors are outside the system and must interact with atleast one use case. There are two type of actors:

1. Primary Actor: For whom the system is build
2. Secondory Actor: They exist for the Primary actor.

- Postcondition: The state of the system after the use case is executed. There can be multiple Post conditions depending upon whether al business rules have been or how the system acts.

- Basic Flow: Course of events that happens when everything goes well. Happy Flow. No errors, no exceptions.

- Alternate Flow:

1.  Error or exceptional flow that occurs at any step of the basic flow. Example: Session time out.
2. Additional flow not necessarily error based,  a flow that could happen. Example: While investor trying to invest, system gives a warnings that Stock Market will close in 10 minutes.

- Assumptions: They can be easily confused with Pre-condition. They are outside the scope of any requirement. Assumption is a condition which system assumes to be true (or false) since it does not have a way of verifying them at run time when the Use Case is executed. For example: (a) User authentication information is maintained within the authentication system. (b) All Actors communicate in English.

Use Case Diagram :

• Actor
• Use Case
• Genernalization : Reusing Use Cases
• Extends
• Includes
• Show type and sub type of actors
• Relationships
1. Between Use Cases
2. Between Actor and Use case

We will cover Use cse diagram in UML post.

Post 3_ Project Scope

Lets understand what do we mean by Project Scope ?

Its that analysis which enables the team to identify the project start or end point. Project scope covers the following aspects:

1. Why the project is initiated i.e. project statement of purpose. For example: "To make customer payment methods as per industry standards and user friendly."
2. Goals of the project: For example: "This enhancement is to add the mode of payment to customer payment option produced by customer invoicing system."
3. Identify Stakeholders
4. In scope. For example: " This project will only work on invoicing module"
5. Out of scope. For example: "This project will not cover order entry and inventory manageemnt system"
6. Constraints and Assumptions:
• Asumptions: It is important to document the project asumptions as they are based on experience, knowledge and information shared by the team members. For exmple: ' Funding will be provided before te project starts" ; "All licenses will be procured by the client".
• Constraints are the limitations within which the team needs to work in. Forexample: Schedule, Cost , Scope, resources. Each of it will have an impact on the other and will affect the quality of the delivery.
7. Project deliverables.
8. Project risk
9. Project plan/ schedule

Its mainly done by Project Manager but requirement gathering  analysis begins with understanding the Project Scope, where the role of Business Analyst comes into picture.

Business Analyst needs to have two important tools:

- Context Diagram : It describes the information exchange  between the users and the potential business system. It reveals 3 things:

• Users of the system (both human and other system)
• Boundary of the system
• High level flow of data between the systems.

- Use Case Model: It  reveals the following:

• Major units of Functionality which the system will provide - Use cases 
• Humans and systems benefitted out of those services - Actors.

The project scope is the "do to" list. Brainstorming of all the team members along with the stakeholders will be able to refer to the project scope throughout the completion of the project.

Post 2_Types of SDLC lifecycle

First I would want to cover What a BA should know. To start with lets do the type of SDLC methodologies

We would primarily focus on the below ones.

- Waterfall model

- Iterative Model

- Latest one - Agile Methodology.

Brief about each of them

Waterfall model: Also known as Sequential software development approach. It follows the sequence of steps for full requirements together. So how does it work ?

- BA finishes the Requirement Gathering phase.

- Then comes Desgin stage

- Development stage

- Integration

- Testing

- Production

- Maintanence

Once each stage is passed. Its closed. Waterfall model is good for the project where :

- Client is thorough with the requirements,

- Team is working with well understood technical tools, architecture and infrastructure.

Iterative Model: It doesnt start with full set of requirements from the beginning. Each set of requirement goes throguh design, development , testing integration and production. We develop specific part of the software, which is then reviewed in order to identify next set of requirements. produce a new version of software for each cycle in the model.

Success if Iterative model is rigorous validation of requirements and testing of each  version of the software.

Agile Model: Its an approach for effective modeling and documentation of software system. Its applied on Requirements, analysis, architecture and design.

Agile focus on shorter iterations. This helps in maintaining quality, reduced integration risk, frequent evidence of progress, good status visibility and customer relations.

The pre-determined iteration length serves as a timebox for the team.  Scope is chosen for each iteration to fill the iteration length.  Rather than increase the iteration length to fit the chosen scope, the scope is reduced to  fit the iteration length.  A key difference between agile methods and past iterative methods is the length of each iteration.  In the past, iterations might have been three or six months long.  With agile methods, iteration lengths vary between one to four weeks,  and intentionally do not exceed 30 days. 

There are further 4 types of Agile development methodolgies

- Extreme programming (XP)

- Crystal

- Scrum

- Feature driven development

Please feel free to add if you have experience in any of the agile methods.