Skip to main content

Tag: Elicitation

Well-defined Data Part 2 – Generic Business Entities

We begin our journey down the path of well-defined data by looking at generic business entities.

These are entities such as General Ledger Account, Staff Member, and Asset. They are well-understood within any organization large enough to warrant one or more IT-based business systems supporting functions such as accounting, human resources, or asset management. These functions and business entities are well supported today by commercial off-the-shelf (COTS) packages. So well supported, it’s difficult to imagine any organization justifying a decision to ‘make’ in-house rather than buy.

In my previous series, Requirements in Context, a generic high-level business model was discussed. The model represents business functions applicable to any organization, regardless of it being in the public or private sector, for profit or not for profit. The business functions are seen categorized as management, line of business, or support.

The management and support functions are generic in that their processes and entities are common to any organization. The line-of-business functions are generic in that they describe the life cycle of any product or service an organization deals in. But the processes within those functions and the business entities supporting those processes vary by industry segment and even by organization within a given segment.

This article focuses on the generic business entities associated with management and support functions. Parts 3 and 4 of this series look at the line-of-business functions and their line-of-business-specific entities.

Generic Business Processes and Entities

Within each management and support function are a number of business processes. For example, human resources processes include organizational management, recruitment, and payroll. Each of these generic processes is described briefly below along with the generic business entities they create or reference.

NOTE: As you read these process descriptions, consider how each can apply to any organization in any industry sector. For example, a term such as ‘staff member’ is used in relation to a position within the organization. When a staff member is on an employment contract, they are part of the payroll process and eligible for benefits such as paid leave. If they are on a service contract, they are paid based on an invoice for their time and are not eligible for paid leave. Again, this is generic to any organization regardless of the line(s) of business the organization operates.

Organizational management is about maintaining the generic business entity Position and its relationship to other positions in the organization’s management structure.
Recruitment is about finding and engaging a suitable person to fill an existing, budgeted, vacant Position. When the process involves hiring from within the organization, existing instances of Staff Member will be referenced (those on employment contracts). If there are no suitable/available internal candidates the process will create new instances of Applicant as external people apply for the position.
The successful candidate will be an existing or new instance of Staff Member. If the position is filled by a person that has signed an Employment Contract the contract will have details of the agreed salary (or wage) and negotiated leave benefits. If the position has been filed based on a Service Contract, that contract will have been signed for an agreed rate, either with the individual or with an agent representing that individual.
Payroll involves referencing instances of Staff Member on a salary or wage. The process needs to adjust the periodic salary paid within the pay period based any unpaid Leave. For a person on a wage, it needs to calculate the total pay based on Hours Worked, factoring in overtime rates (where applicable) plus payment for any accumulated Leave taken.
The resulting Employee Payment will also need to be reduced by any withheld taxes and other deductions. NOTE: Payments against a service invoice are not managed by a payroll process.

Advertisement

The above three processes within the human resources function involved one or more of the following business entities:

  • Position
  • Staff Member
  • Applicant
  • Employment Contract
  • Service Contract
  • Leave
  • Hours Worked
  • Employee Payment

These entities are generic in that none of them are specific to a particular line of business.

Well-defined Generic Business Entities

The primary objective of a definition is to ensure that the thing being defined will be recognized and understood by those that need to deal with it. A classic example is the “Duck Test” (i.e. how to recognize a duck). The test goes, “If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.” From a data perspective the thing (a duck) is defined by a description attribute (an image of a duck), its relationship to an observed event (swimming), and a classification (the type of sound it makes).

From a business analysis perspective, the test for recognizing a Staff Member, and therefore its business definition, can be stated as: “A person engaged by the organization under an employment or services contract to fulfill the duties and responsibilities of a designated position.”

In addition to a name and definition for each entity, the following properties are commonly included for entities in a data dictionary template:

  • ID — an identifier unique within the context of the data dictionary
  • Alias(es) — other business terms that users of the data dictionary may know this concept as
  • Owner — typically the organizational position responsible for sourcing and/or maintaining instances of the entity (e.g. Head of Recruitment in the case of Staff Member).
  • Data Sources — operational and data migration (e.g. For Staff Member, details captured during the recruitment process such as name, contact details, skills).
  • Current Volume — order-of-magnitude number of instances of the entity. Of particular interest when numbers are low (under 100) or very high (above 10,000).
  • Expected Growth — order-of-magnitude additional instances (per day, week, month, or year). Of particular interest when growth will increase the total by one or more orders of magnitude.
  • Peak Volumes — Order of magnitude number of entity instance references and/or additions. Of interest when the number is an order of magnitude higher (or more) than the Current Volume value. Applies more to event-based line-of-business entities involved in sales-related processes.
  • Business Identifiers — [To be covered in Part 5 in this series]

COTS Generic Business Information Systems

There are numerous commercially-available business information systems covering one or more processes within a management or support function — for example, Accounting systems, HR systems, Asset Management systems. The advantage of acquiring multiple modules from the same vendor is that the data is integrated (i.e. entered once, referenced multiple times). The alternative is to either have interfaces between systems, copying data from one to the other, or re-entering data in each system as required.

ERP systems (Enterprise Resource Planning) offer an integrated set of modules that span multiple management or support functions.

Click here for Part 3 — Line-of-business-specific Entities

Requirements traceability: What, why and how

Traceability is one of the lesser understood aspects of business analysis. It is indeed quite hard to maintain good traceability unless automated.

This is why BABoK® warns us being theoretical about traceability.

In this article, I would like to explain traceability concepts with help of an example.

BABoK® definition of traceability:

Traceability is the ability to look at a requirement and others to which it is related, linking business requirements to stakeholder and solution requirements, to artifacts and to solution components.

Traceability identifies and documents the lineage of each requirement, including its backward traceability (derivation), forward traceability (allocation) and its relationship to other requirements.

Traceability ensures that the solution conforms to the requirements. It also helps in managing scope, risk, time, requirements changes, cost and communication. It can be used to detect missing functionalities or to identify whether the implemented functionality is supported by a specific requirement.

Reasons for creating traceability are:

Assist in impact analysis for requirements changes.

Ensure requirements coverage: Understand how business objectives are implemented. Business objectives not traced to detailed components have not been analyzed and hence not included in the solution.

Requirements allocation.

Relationships

Derive

When one requirement is derived from the other. Stakeholder requirements are derived from business requirements. Solution requirements are derived from stakeholder requirements.

Depends

One requirement can be implemented only if the other has been implemented or easier to implement if the other is implemented.


Advertisement

Satisfy

Relationship between an implementation element and the requirements it is satisfying.

Validate

A relation between a requirement and its test case to validate whether the solution fulfills the requirement.

Let’s take a practical example of a requirement to list all products on an eCommerce store (such as AdaptiveUS.com/eStore)

mishra 05292018a

Requirement

To list products in the ecommerce portal with their price

Derived from (Parent requirement)

Enable e-commerce for business

Dependent requirement (Prerequisite)

Payment gateway to collect payment from customers

Satisfied by (Allocated to Solution component)

Store front end

Validated by (Tested by test component)

Test cases to test store functionality.

This is a simple template to capture requirements traceability. You may transpose the same to handle multiple requirements in the template.

The Elaboration Formula

You have finished your requirements gathering and now need to convey your vision to the software development team, where do you begin?

I start with the following formula: View, Create, Edit, Delete, and Print. These are the five primary ways a user will interact with your software application.

Although this conversation is directed at the new software business analyst, even those with experience can occasionally face a bit of writer’s block. If you get the basic foundation laid then you can concentrate on the complexities of your feature.

View

Is this totally new or a modification to existing functionality? Can it be seen in your application today? What needs to be added here? An entire page, grid, report or just a field? How does the user navigate to the functionality? Do we need a new menu option or a button to launch a new page? Laying the framework for the new functionality is often the hardest thing to conceptualize. Take a step back and put yourself in the user’s shoes.

Create

Is the user going to create or add a new record? What fields are needed? Which ones are required, and which are optional? What happens when they save the results?

Edit

Can the user edit or modify an existing record? How do they tell the application that they want to make a change? Are the fields always enabled or do they have to select an option to edit?

Delete

Is the user allowed to delete a record or must it be marked as inactive? Is the record archived or does it persist in the database?

Print

Does the user need to print the results or just view them on the screen? How should the initial display be sorted? Do they need to option to filter the results in some way? Are we printing as a PDF, to Word or both? Is there a business reason to export to Excel?

If your feature is to create a new report, you may be looking at additional inputs to pull different subsets of data. Titles, dates, page numbers, headers and footers will come into play. How are sections grouped and totals displayed?

Other Considerations

What else do we need to consider? Permissions is the first one that comes to mind. Can any user complete all these actions? Are only certain users allowed to delete? Does your application have an existing permission module that needs to be modified?

What are the business rules or constraints that need to be implemented? Do we warn the user or block them from certain actions? Do your data entry fields have character limits or do they need to be unique?

Does this functionality impact or integrate with other areas of the application? If new fields are being added, do they also need to be added to existing reports or dashboards? If you are working with a robust or enterprise application, it may be handy to have a checklist of the potential areas of impact.


Advertisement

What does it look like?

Some teams may include a UX designer, but more often a business analyst must create a initial mock-up of the new functionality. This may be a drawing on a whiteboard with input from your team or be created digitally so that it can be sent to stakeholders for review. A picture says a thousand words can quickly convey your concept and generate insightful questions.

Putting it to paper

How you document this for your team depends on your current organization and methodology they use. A traditional functional spec or design document will spell out the solution in detail and typically includes a mock-up of the new screen/grid/fields/report. A use case document will detail the interaction between the software and the user. User Acceptance Criteria will speak to the basic requirements that the user needs to accomplish for the user story to be marked as DONE. They are all conveying the same vison in a different format.

  • Design: Add the new functionality button in the application location.
  • Use Case: The system displays the new functionality button in the application location. The user invokes the new functionality button. The system displays the new functionality page/grid/report.
  • User Acceptance Criteria: The user can view the functionality name in the application location.

Many organizations will have a combination of documents that are needed to get a requirement from concept to development complete. Elaboration is just one step in the development process.

Don’t reinvent the wheel

Unlike writing your college term paper, elaborating requirements and writing user stories is not graded on originality. It is actually more productive to borrow or re-use sections from similar functionality documented in a previous sprint or release. Your team will be more comfortable with the steps that were used before and you have a reference to ensure that all areas are covered. Review the defects, linked stories and documents to see if anything was overlooked in the previous endeavor that should be included upfront this time.

Create your own Formula

This formula might not be the best for your specific project, but it might help you create one that is. What steps come to mind when you receive a new feature? Is there a mental checklist that you follow or one at the back of your documentation template that covers impacted areas? Is there someone on your team that has a knack for taking a new feature and running with it? They probably have a formula in their head that they are unconsciously working through. Find your formula, rinse and repeat. Build better software.

Business Analysis for Regulatory Reporting

Regulatory Reporting is submission of raw or summary data to the Regulators who determine the Financial Institution’s overall health by assessing the compliance needs according to regulatory provisions especially post the financial crisis.

Business Analysts understanding these requirements and providing solution that automates and streamlines the process to generate these reports in timely fashion is the need of the hour.

KEY COMPONENTS OF REGULATORY REPORTING

As a business analyst understanding of these key components of a regulatory reporting is key to delivering the right solution:

Sarkar 030518a


Advertisement

In the Regulatory Reporting world which is ever changing, business analysts need to be up to date with regulations and be well versed with data space in a financial institution.

KEY ROLE OF BUSINESS ANALYST IN REGULATORY REPORTING

As a business analyst one can lead and direct in the regulatory space by:

Sarkar 030518b

Business analysts can translate these regulatory reports into business requirements and further advice data quality rules and control framework relevant to the financial institution. Challenging role as BA accelerate and excel in this ever changing world of regulations and become key drivers of meeting regulatory requirements.

Using prototypes to write requirements

When I started out as a Business Analyst, I worked on many small projects that dealt with internal application development.

Requirement elicitation was easy as the requirements were precise and the user navigation steps were simple. I didn’t have to think much from the design and spacing perspectives as all the stakeholders, and end users were from within the organization, and as long as the purpose of the application was being served, the design of the application would take a backseat.

But as I progressed and took up bigger projects – projects that were creating revenue for the organization and that were being used globally – I realized that I had to be very careful in writing the functional requirements. I had to be aware of each and every functionality on that screen to make the requirements more effective. The user management had to be explained in detailed, and I had to keep in mind the design of the application and be more though with the navigation flow.

Initially, I used to take the visualization approach in writing the functional requirements – Imagine the flow in my head and keep writing. However, when I reviewed these requirements, I observed that I did miss out on some aspect or the other. Eventually, I had to add more details to complete the requirements.

I then began to use prototypes to write the functional requirements. Remember how back in school we were told to use paper for rough work to do our mathematics calculations. In the same way, using prototypes to solidify the navigation flow can be a good approach.

As per many, a prototype or a mock-up is defined as the blueprint of screens or a visual guide that represents the skeletal framework of a website. A better version of a mock-up is a wireframe. Wireframes take into account the complete design aspect of the software. Mock-ups are rough drafts created in the beginning to put the elements of a website in place.

Take this for instance – you are required to spearhead a project in which an application has to be developed with which end users can buy fashion accessories. Some of the initial questions you may ask the stakeholders would be about:

  • Customer base
  • User journey
  • How will the payments be processed? The payment gateway integrations
  • If user can make a purchase as a guest user
  • Where will the user apply the promo codes?
  • Which filters can be used by a user?
  • Are we maintaining any order history?

The answers to these questions will help in drafting the high-level requirements. But what about the following questions?

  • What all can a user do in his / her account? – Change profile
  • How will the navigation between pages be? This may seem simple, but the stakeholders may have a different opinion. For example, you may think that when a user is on the review order page, and when the user clicks on continue shopping, s/he should land on the product listing page. But the stakeholders have a different requirement – They want the user to land on the home page of the website. BAM there’s a gap now!

Advertisement

Case – Requirements without a prototype

Let’s say you are to capture requirements for the order history page in the user’s account. You imagine the page in your head. You first write about the basics – The page will have the following details:

  • Order No
  • Product details
  • Total amount
  • Promo Code discount
  • Amount paid
  • Status

Case – Requirements with a prototype

Now, what about the details at the granular level. You make a mock-up with the information above and analyze the order history page further.

mehta 03012018

  • Can the user click on the product details and view the different products in list form? If yes, then can the user select each product to view its detailed page?
  • Can the user view the amount breakup and the mode of payment?
  • Will the status be a pictorial representation or just a text?
  • Where will the images of the products be placed?
  • Given the layout above, how will the space to the right be utilized? If the stakeholders request to add some banners how that will be done?
  • Does the return and exchange of a product happen on this page?

This is just a small module. When it comes to the entire application, the complexity may increase, and the requirements may have to write in much detail.

Mock-ups are the binding agents of the requirements. They help in understanding the user journey which can eventually help in effectively drafting the use cases. These are easy to make and are effective in identifying gaps. While various tools are available in the market, mock ups can be done in the basic pen paper mode too. One doesn’t need to be adept with the design aspect. However, a BA should consider each aspect of a screen and make sure if there’s a requirement associated with it. The main purpose of a mock-up is to have a complete picture of the user journey. Moreover, the feasibility of the features can also be assessed.

Having a mock-up for reference can be helpful in the following ways:

  • Functional requirements can be written in a modular way. As mock-ups deal with all the screens of the software, one can map the navigation amongst these pages and write details about the user journey.
  • It helps in filling up the requirement analysis gap. For example, during requirement elicitation, the stakeholders may skip a feature. However, if a rough structure is in place in these sessions, the chances of missing a detail are minimal.
  • One doesn’t miss out on a user story. For example, the order history is in place but as a user, can I sort/filter the records? If I click on an order, can I see the detailed page of a product purchased?
  • Requirements when coupled with mock-ups give a clearer idea to the developer who can consequently code with confidence.