Tag: Elicitation

A Business Analyst’s Experience With Agile

Written by Leslie Munday on November 27, 2019. Posted in Articles.

I recently wrote a book detailing a customizable extension to the Scrum framework.

The following diagram provides an overview of the process described in that book.

Figure 1: Extension To The Scrum Framework

This article provides an overview of the process and the reasons why I created it. If you find this information useful and want to learn more, I provide a reference to my book at the end.

1. Introduction

Working as a business analyst on agile projects for 6 years, I have learned that the Scrum process framework does not describe the complete story.

I emphasized the word agile, to indicate that the one thing all of these projects have in common is short time-boxed development cycles (or sprints).

Scrum identifies three roles. The development team, product owner and Scrum Master. Scrum does not identify roles for the business analyst, solution architect, quality assurance team, tester, UI designer, deployment manager or writer. (These are roles that I am used interacting with on an agile project.) Instead, with Scrum, the development team is responsible for the work normally performed by these roles. Scrum assumes that the development team includes people with all of the skills normally associated with these roles.

Quoted from Scrum.org: Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment. Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person. Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations or business analysis. Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

A problem with this Scrum organization is that all of the work performed by the development team happens within a sprint cycle. However, the artifacts produced by the product owner, business analyst, solution architect, quality assurance, writer and deployment manager, are not sprint based. In addition, the UI designer and tester activities are sometimes independent of a sprint.

This article describes activities performed outside of the sprint cycle and identifies the benefits that they bring to the implementation of a deliverable product.

My Experience With Agile Projects

In my experience, some agile projects included a Scrum Master and other times project team members perform the Scrum Master activities. The roles that all of these projects had in common are, a product owner (sometimes known as the product manager), a development team, and of course, a business analyst.

Most development teams were supported by a separate user interface design team and an independent quality assurance (QA) or testing team. Other roles that are outside of development include deployment and operations, solution architects and document writers. These roles may be assigned specific responsibilities that support software development, even when an agile process is employed.

This article contains an overview of the activities, deliverables and best practices for these roles as they relate to agile systems development. Each role is responsible for one or more activities. These activities are described from a business analyst’s point of view.

A Brief Overview Of The Scrum Framework Process

Scrum identifies five activities (ceremonies), Hold Scrum Standup, Plan Sprint, Develop Sprint, Review Sprint and Learn Lessons From Sprint (Sprint Retrospective). The artifacts identified by Scrum are, user stories, software components and an incremental build. User stories are managed with the product backlog and the sprint backlog. All of this work is performed within two time-boxed cycles (Daily and Sprint).

Figure 2: Scrum Framework

User stories are entered into a product backlog. The product backlog is managed by the product owner. User stories are taken into the next sprint cycle during a sprint planning meeting. During the sprint cycle, the development team develops components for an incremental build. When all user stories in the sprint backlog are done, the incremental build is reviewed with project stakeholders. After the sprint is complete, a sprint retrospective meeting is conducted to identify lessons learned from the previous sprint. A standup meeting is held every day, for the development team to plan the next day’s work and review the status of user stories in the sprint backlog.

User stories may be generated as a result of the sprint review or sprint retrospective and entered into the product backlog.

Development of sprint backlog user stories includes building user and system interfaces, updating the system architecture, writing user documentation, testing software components, testing the incremental build and deploying software to the customer.

The Scrum framework does not show activities that are the responsibility of the product owner, such as eliciting business needs as user stories and grooming the backlog, in order to prioritize work for upcoming sprints. These activities occur outside of the development sprint cycle.

Epics are user stories that are too large for a single sprint. Tasks are the breakdown of user stories into manageable pieces of work.

2. My Agile Experience As A Business Analyst

The process that is described below includes artifacts, roles, and activities that I have been involved with when working as a business analyst on ‘agile’ projects.

As a business analyst, I generally support the product owner by:

Eliciting business needs
Maintaining the user stories in the product backlog
Writing and maintaining project documentation
Modeling business processes and system requirements, architecture and data

In addition, the business analyst may be expected to support development by:

Assisting with testing, by writing acceptance criteria and confirming test case results
Attending Scrum ceremonies, including the daily standup
Supporting development as requested

As you can see, the BA may be expected to provide support to all activities in an agile development process. (I have even been asked to sign-off incremental builds prior to delivery to a customer.)

Team Logistics

A major factor that affects the Scrum process is the logistics (or organization) of the project team and its stakeholders. I have worked in environments with the following logistical makeup:

The customer is remote – When the development team does not have direct access to the customer, the product owner (or similar role) acts as a proxy for the customer. The product owner may be the only person on the team who has direct contact with the customer. In this case, they are fully responsible for identifying customer needs and priorities and for confirming the accuracy of the product details. The customer may only get to see the product when it is released.
The development team is remote – Many projects do not have access to a co-located IT department. Software development may be subcontracted to a development team at a remote location. If the development team is located in a different country, then direct communication may be restricted to a few hours a week.

I have worked with a development team whose working hours were offset from the customer by 36 hours per week. By the time I arrived at work on a Monday morning, the developers had been working for a day and a half.

Quality assurance is a separate department – The project does not have dedicated testers. Testers are part of a QA department that is a shared resource across all departments. The development team will test each incremental build, but no software can be released to a customer until QA has validated that the product meets the customer needs. Product acceptance testing occurs after the sprint is complete and prior to product release.
A team of UX experts designs user interfaces – To ensure that customers experience a common look and feel across the enterprise, all user interface design work is performed by an independent UX department. Product UI specifications (or mockups) are included with the user stories that are taken into sprint planning. The UI specifications may change during development, with the approval of the UI designers.
Product deployment is on a separate release cycle – The customer does not want any disruption to their business due to defects or problems with deployment. Therefore, deployment occurs at the customer’s convenience and only after user acceptance testing is done.
Product documentation is part of the product release – User manuals and release notes are only written against a release. Documentation is not necessary for an incremental build, and therefore it does not need to occur as part of a sprint.

Assuming the worst case, where all of these traits are affecting your development process, I documented the following extensions to the Scrum process to show how they affected my experience with Agile.

3. Overview Of The Process

The process diagram assumes that all the above logistical items are affecting the development process. The process is customized according to your development environment. For example, if UI design is performed during a sprint as part of development of a user story, then the Define User Experience activity may be removed from the process.

The Activities

In the following paragraphs, I describe how to read the process diagram shown in figure 1.

There are 3 time-boxed cycles shown in the process; Daily Cycle, Sprint Cycle, Release Cycle, and a 4^th region where activities are performed on a continuous basis. The activities shown in these regions are connected by flows that indicate artifacts passed between them. The flow of information is continuous and it is passed in increments. (The diagram does not indicate any hand-offs from one role or department to another.) Four repositories of information are shown. Information may be added to, updated and extracted from these repositories at any time.

Continuous activities:

Elicit Business Needs – Business needs are elicited from the customer and captured in the product backlog as epics. Epics are analyzed to derive use cases and user stories. User stories are managed within the product backlog. Use cases are maintained within the project model.
Groom Backlog – The product backlog is reviewed on a regular basis and user stories are prioritized. Backlog items may be approved for development, or removed from the backlog.
Maintain Requirements – Requirements are continuously maintained within the Model. Use cases are analyzed, user stories updated in the product backlog and acceptance criteria are derived.
Design Architecture – The system architecture is maintained as new technology is introduced and interfaces are changed. A model architecture view captures the system architecture. User stories are maintained in the product backlog to capture architectural changes. Model architecture diagrams may be used during development of sprint user stories.
Define User Experience – System user interfaces are updated from product backlog user stories. Mockups of the user interface design are taken into the sprint and may be updated as developers work on the user stories.
Test Build – Test cases are continuously developed from user story acceptance criteria, so that an incremental build may be tested as soon as it is available. Test results are captured as a result of testing an incremental build.

Sprint cycle activities:

Plan Sprint – User stories are taken into the next sprint backlog during sprint planning, according to their priority in the product backlog.
Develop Sprint – Each user story impacts one or more components of the product build. During a sprint cycle, all stories in the spring backlog are developed and an incremental build is produced.
Review Sprint – When an incremental build has been produced, it is reviewed with the project stakeholders. User stories may be updated in the product backlog as a result of demonstrating the results from the sprint.
Learn Lessons From Sprint – The final activity in a sprint is to hold a lessons learned meeting with all members of the project team. The results of the sprint are input to the meeting and action items may be created as user stories in the product backlog.

Release cycle activities:

Document Release – Each release includes instructions for the users and release notes. These documents, inform the customer what has changed since the previous release. Release notes and updates to user manuals are derived from a combination of the developed user stories that make up the release and from exposure to the software user interfaces.
Deploy Build – The product is delivered to the customer on an agreed schedule, so that deployment does not interfere with their business activities. Deployment may involve, stopping running software, installing to the customer environment, interfacing with existing systems, validating that the installation was successful and restarting the system.

Daily cycle activities:

Hold Scrum Standup – Members of the project team present their work since the last standup, their plans for the coming day’s work and impediments to progress. User stories statuses are updated in the sprint backlog.

The Artifacts

Artifacts are the things that are produced within the process. Artifacts may be maintained within a project repository, such as the Model, Product Backlog or Sprint Backlog. Other artifacts may be temporary and used to distribute information between team members. Artifacts contribute towards producing a product release.

Not shown in the diagram, are repositories for documentation, code, and test cases, amongst others.

The process diagram shows the following artifacts as input to or output from one or more activities:

Needs – Elicited from the customer, business needs are analyzed into user stories for the product backlog.
Epic – Business needs are captured in the product backlog as epic type user stories. Epics are broken into user stories. They are not pulled into a development sprint.
User Story – All work performed in a sprint is the result of a user story. User stories result from; the analysis of epics, defects found during testing or may be created by the project team to capture work that needs to be done.
Use Case – Captures the business processes that are derived from business needs. They are maintained in the project model. Use cases are analyzed to produce product requirements, data and user stories.
Requirement – This is a generic term for behavior the system must exhibit. Requirements are documented with use cases, acceptance criteria, user stories and any other means the team uses to capture requirements.
Architecture – The combination of software, hardware and their interfaces that will host an incremental build. The system architecture is captured in the project model and used by developers during the sprint in order to understand the impacts software changes. The solution architect works with the development team to identify impacts to sprint user stories.
UI Design – Normally in the form of user interface mockups, the user interface design is attached to user stories in the product backlog. The UI Designer works with the development team during the sprint.
Acceptance Criteria – Derived from use cases, they detail behavior that the product will exhibit in order to meet its requirements. Acceptance criteria are used to create and maintain product test cases.
Component – A piece of software that is created or updated from a user story. Components are added to an incremental build during a sprint.
Build – An instance of the software application that is updated every sprint.
Build Test Results – Captured in the product test cases as the results of applying the test case to a product build. Each incremental build is tested against the user stories that were developed during the sprint.
Product – A validated software build that and can be deployed to a customer.
Usage – Refers to the customer experience with a product release.
User Instructions – Documentation is written for anyone who needs access to the deployed product.

The People

A role encapsulates a set of responsibilities performed by one or more people. A person may perform several roles. The roles that were previously identified, are the business analyst, product owner, solution architect, UI designer, development team, tester, writer and deployment manager. Each role is responsible for one or more activities in the process.

The Scrum Master is considered out of scope. Responsibilities of the Scrum Master as they relate to the process, are distributed across other roles on the project team.

The business analyst is responsible for the Elicit Business Needs and Maintain Requirements activities. They ensure that user stories are ready for the next sprint. They update user stories from the system architecture and UI design and provide support to development, testing and anyone using requirements. The business analyst works closely with the product owner to ensure the success of the project. The business analyst creates and maintains a model of the Requirements and the model Architecture view. They create User Stories, Acceptance Criteria.

The deployment manager is responsible for the Deploy Build activity. They support customer and product deployment at the customer location. The deployment manager creates the Product Release.

The development team ensures the success of each sprint. They are responsible for the Develop Sprint, Plan Sprint, Review Sprint, Learn Lessons From Sprint and Hold Scrum Standup activities. The development team creates Components for an Incremental Build and may create work items in the form of User Stories, for the product backlog.

The product owner is responsible for the Groom Backlog activity. They prioritize and ensure the accuracy of business needs and serve as a proxy for the customer and subject matter experts, and remove obstructions to development. The product owner creates Epics.

The solution architect is responsible for the Design Architecture activity. They maintain the hardware and software architecture of the complete solution. The solution architect creates the product Architecture, which is captured in the model Architecture view.

Quality assurance is a separate department within the organization that includes testers. They are responsible for the Test Build activity. QA ensures the quality of every artifact that is produced during the process including validation of all software builds. QA creates test cases from acceptance criteria and user stories. During validation of an incremental build, they populate test cases with Build Test Results.

The UI designer is a member of an independent User Experience (UX) design team. They are responsible for the Design User Interface activity. The UI designer produces user interface mockups (UI Design) that provide a consistent and efficient look and feel to the product user interfaces.

The writer documents clear, understandable and accurate user documentation that supports a product release. The writer is responsible for the Document Release activity. They create User Instructions for a product release.

4. Summary

This article provided a summary of a process that extends Scrum by introducing roles that are responsible for business analysis, solution architecture, UI design, quality assurance, documentation, and deployment. It defines the artifacts that are the responsibilities of these roles and the activities used to generate these artifacts.

These activities are only necessary when the role exists in the project team. Where a role is not applicable to your situation, that role’s work may be performed by the development team instead.

Even if your project does not explicitly identify the artifacts described in this process, the development team probably performs the work described by the activity that produces the artifact.

The process may be customized for projects using Kanban, SAFe or LEAN project. Details are documented in my book, Using Agile In A Quality Driven Environment (A Business analysts Experience With Scrum).

For more information, you may download my book from Lulu.com as a free PDF file.

Improve Collaboration by Understanding Natural Human Instincts

Written by Deena Chadwick on November 7, 2019. Posted in Articles.

Last January, I was lucky to have an article posted right here at BA Times.

How To Get Requirements From Resistant SMEs Part 3. It is about what to do when your SMEs clam up. It mentions using a person’s natural human instincts to get them talking. One of the hardest things to do as a professional is to put theory into practice. I have been asked several times this year to elaborate on what I shared, by giving examples or case studies on How.

First let’s do a quick refresher, the FBI and Homeland Security states that these are the natural human instincts that trigger people to share information.

A desire to appear well informed, especially about our profession
A desire to feel appreciated and believe we are contributing to something important
A tendency to expand on a topic when given praise or encouragement; to show off
A tendency to correct others
A desire to convert someone to our opinion

Part of the reason people struggle with practical application is because you have to create a scenario that triggers someone to act on their instincts. I will share several examples or case studies that show you how others have successfully applied these techniques.

A Desire To Appear Well Informed

1. In larger groups, meetings, or messages

“Jack, it has been a few weeks since our last show and tell, before our developer shows you wants coming up, why don’t you give us a quick summary of how our last release helped your team?”
“Today is all about coming up with new ways to help our production support team reduce their backlog of support tickets, before we get started, Harry can you tell us what solutions or bandaids your team is already using?”

2. In small group conversations

“James, have you met Nicki? Nicki you can explain what your team does better than I can…”
“Ok I include the two of you in a half an hour meeting before the brain storming session. I was hoping that the two of you, who have a vast amount of knowledge, would mind talking through the most important points before the team got here, so that the meeting has a bit of a head start.”
“Milly, we are about to go into another grooming session…which is going to end in you having to make all of the decisions any way. Can you do a quick pass before the meeting so that we don’t waste time going into detailed conversation for something you already know the priority for?”

A Desire To Contribute or Be Appreciated

“Jonas, I just got out of a planning meeting and they finally approved us to start working on the improvements you guys have been asking for. Would you mind being my goto expert? I need someone who can help me focus on this from a user’s point of view.”
Meeting Invite: I know we normally have James, Calvin, and Sanya in our kick off meetings but I have also added Stacey. I have noticed that when a lead from UX is involved from the beginning, we spend less time reworking usability issues from user acceptance.

A Tendency to Expand On A Topic

“Greg that seems important to talk about, but not here in stand up. Why don’t we finish up the daily meeting and then can most of you guys stay on the line so Greg can explain the issue in detail and we can decide as a team what to do.”
“Jeremy, let’s switch gears for just a minute. Instead of starting with a list of changes, can you tell me a little about what your team has accomplished recently and what they are looking to accomplish and improve on in the next cycle?”…”Ok now can we map those goals and accomplishments to the items in the list to see which ones should float to the top?”

A Tendency to Correct Others

“So I hear your team would rather start from scratch learning a new system, than deal with the issues you are dealing with today.”
“I am telling you the report is wrong, everytime I rerun it, it looks exactly the same!” “Oh so you are saying the report should always change each time you run it?”
“James, can you do me a favor? Can you job shadow Erica and then share with me what she could do in her processes to be more efficient?”

A desire to convert someone to our opinion

“Harry, can you tell Madu what you told us the other day. I may not have explained it right, but Madu completely disagreed with us.”
“Why is this so important that my team has to work 10 hours plus a day and work on the weekends?”

These are just a few examples, but I hope they inspire you to engage that reluctant SME or Stakeholder by triggering their Natural Human Instincts.

BA As Detective

Written by Elizabeth Larson on July 15, 2019. Posted in Articles.

Some of you know that I am a big fan of mystery fiction.

There are many aspects of this genre that I enjoy, but what I find the most interesting is watching the detective look for clues to help identify the problem, investigate alternatives, and finally offer the solution. In past articles I’ve noted some of my favorite detectives –Louise Penny’s Armand Gamache, Philip Kerr’s Bernie Gunther, Michael Connelly’s Harry Bosch and Tana French’s various detectives, to name just a few. They are all flawed, but amazingly talented at solving the fundamental problem of “who done it.” What is it that enables them to put seemingly disparate puzzle pieces together to solve the case? Characteristics that are also needed to succeed at doing business analysis work.

In my past articles I have drawn comparisons between the BA and detective. I have explored the need for both to connect the dots and solve problems creatively. I have discussed the need to rely not only on their intuition, but also their rational mind. I have discussed the importance of recognizing patterns, creating structure from chaos, and feeling comfortable with ambiguity. However, one comparison I haven’t explored is perhaps the most obvious and relevant one—the ability to ask good questions.

As BAs we ask a lot of questions. As Penny’s Chief Inspector Gamache says, “The question that haunted every investigation was ‘why,’” also an important question for all BAs to ask in one form or another. But Gamache knew, as do BAS, that asking ‘why’ by itself is not enough. We need to ask contextual questions. Consider the quote from Dashiell Hammett’s famous detective Sam Spade: “Who shot him,” Spade asks a witness … The witness “scratched the back of his neck and said, someone with a gun.” Experienced BAs know that when we ask vague questions, we’ll get vague answers.

Not only do we need to ask good questions, but we need to be able to understand the answers provided. What happens when we want to ask follow-up questions, but are absolutely “clueless” about what the stakeholder is saying? This can be particularly unnerving when that stakeholder uses highly technical language such as a data scientist describing the algorithms that will be used in the latest AI effort. Like our detectives, we need to clarify. And if we don’t understand, we need to admit so. And if that technical guru asks us questions that make no sense to us (what ETLs need to be developed, for example), we need to admit that we don’t know. One of the tips Chief Inspector Gamache gives each new recruit, is to get clarification when needed. He says that one of the most important things “that leads to wisdom” is saying “I don’t know.” We need to have the courage to say those words modified, of course, for our own situation.

Of course it gets trickier in the digital world. As BAs we cannot simply say, “I don’t know what you’re talking about,” or words to that effect. We can try the old standby, “Help me understand…” which is great, but we run the risk of still not understanding the explanation. What do we do when we don’t have experience even vaguely related to the stakeholder’s answer? As BAs we often find ourselves asking questions about all manner of things unfamiliar to us, but the world of AI can present new and unforeseen challenges. Yes, we can—and need to– prepare questions in advance. But how can we ask good questions, not just the fundamentals like “why” and “what,” when we know nothing about the subject?

For example, let’s say I want to ask about algorithms, a subject that I know almost nothing about and therefore am terrified of. Sure, I do research, but when confronted with an answer that makes no sense to me, I might freeze. I want to ask about why one type of algorithm was used instead of another. I want to ask about built-in biases. But answers like “I chose a non-parametric algorithm which uses this method for classification and regression…” might give me pause. What helps me is to go back to the basics and start asking contextual questions, which provide a business context and can set the tone for other questions and answers. Once I establish a business perspective, I can put all my further questions into a business context as well. And importantly, it helps me say “I don’t know” without actually saying it. Remember those ETLS? We can rephrase our answer into a question about what the alternatives are and how each alternative provides the business what they’re looking for.

We can also start out at a high-level discussion about the AI effort, what business problem it solves, and how it aligns with the organization’s strategic direction. Even if we’ve heard the answers from sponsors and other business stakeholders, we can encourage technical gurus to frame their answers in business terms. Once we have established the business context, we can move to more detailed questions about how a chosen algorithm helps the business, risks of built-in biases, and, as needed, ask about the data, its source, when it was cleansed, and so forth. Or start with a lower level of detail and work upwards. As good detectives, BAs know that solutions rarely occur when we try to investigate in a straight line. Detectives and BAs know that a question that leads to unexpected answers is a source of a myriad additional questions that take us in unexpected directions, but ultimately solve the problem more quickly.

And that’s where some of the skills discussed in previous articles come in. These competencies. like the ability to connect the dots, help us solve problems and come up with creative solutions. These competencies allow us to follow unusual lines of questions, even if we have no idea what the outcome will be. They allow us to prioritize our work and the questions to ask each stakeholder. They allow us to uncover implicit and hidden requirements. And they enable us to make creative yet practical recommendations. In other words, they help us find “clues” that may seem meaningless at first, but which ultimately help us solve even the most difficult business problems.

Top 6 Process Modeling Mistakes and How To Avoid Them

Written by Edmund Metera on April 16, 2019. Posted in Articles.

There are many examples of very good business process models out there.

They can be found in textbooks, online, tutorials, and product demonstrations. However, in the real world …

Too many business process models fall short of expectations.

Despite significant investments of time and well-intended stakeholder effort, many business process models still end up being not very useful for their intended purposes. Too many don’t accurately enough reflect the business to be useful, or lack sufficient key stakeholders’ buy-in for real decision making, or don’t include the kinds of process information that the model’s readers are looking for, or even confuse their readers with complex or incongruous graphical notation.

Root Causes

None of these types of complaints should be blamed on environmental or project constraints like modeling tools at hand, the level the knowledge or capabilities of business subject matter experts who may be called upon to participate in the model’s development, or even time and effort constraints. Projects are by definition unique temporary endeavours, so these variables are present to varying degrees in all projects. Yes, they influence or constrain any process modeling activity, but a competent business analyst or process analyst is capable of managing and working with or around them.

The root cause of a business process model that does not fit the bill is a business analyst’s or process analyst’s own competence for producing the model while navigating through the typical project dynamics.

Business analysts and process analysts who prepare business process models using ad-hoc methods or past experience are prone to making at least some of these common 6 business process modeling mistakes and having to suffer through their symptomatic process model quality complaints.

The top 6 business process modeling mistakes:

1. Undefined Process Modeling Approach
2. Unclear Model Purpose
3. Not Asking the Right Questions
4. Weak Process and Activity Definition
5. Insufficient Key Stakeholder Participation
6. Insufficient Model Validation

If producing a high quality business process model is not key to your role or your project, then you don’t really need to a high level of process modeling competence. Leave that up to the project’s business analyst. But if it is, then you should be expected to bring a high level of process modeling competence to the table so that you can facilitate and achieve a model that is fit for its project’s intended purpose.

How to Avoid These (and most other) Process Modeling Mistakes

Here are the 6 skills or behaviours that demonstrate a high level of business process modeling competence. They will cause you to steer clear most of the common business process modeling mistakes:

1. Have a defined process modeling approach.

Like other types of analysis, process modeling is a journey of discovery. As a competent business analyst it’s up to you to identify the modeling activities you will perform to lead or facilitate your process model’s journey of discovery. If you don’t already have one then you should adopt and practice a defined process modeling approach.

2. Establish a clear mission for each model.

Process models are typically products of business process improvement/management or information technology projects and all projects are by definition unique, temporary endeavours. As a competent business analyst you deliberately identify the purpose of the process model within your project’s lifecycle and other key mission parameters. You use clear mission parameters to guide your process model elicitation and validation activities.

3. Know what questions you will ask.

It’s not nearly as important to ask a lot of questions as it is to ask the right questions. You should know what few but key questions you will doggedly elicit the answers to as you are eliciting your process model’s content. You should understand why you need to ask and answer those questions. You should be able to prepare and communicate your elicitation agenda in advance of engaging key stakeholders in events like workshops or interviews.

4. Know how to unambiguously identify, normalise and define all processes and activities.

You are able to consistently perceive business processes at any scale and degree of abstraction. You should also know how to normalise any candidate process and once normalised write an unambiguous definition. Further, you understand and have a process definition framework that reflects how today’s network enabled business processes work. You are able to perceive processes as assemblies of activities that are initiated by business events and deliver outcomes. This understanding leads you to define processes and activities that lend themselves as reusable services and you are able to explain why. In this way, you walk the service oriented architecture talk.

5. Know who, when and how you will engage key stakeholders

You identify who the key stakeholders in your process model are. You are clear and deliberate about when and how you engage them in process model elicitation and validation activities. You know how to deliberately engage key stakeholders in the elicitation of the model’s content. You engage key stakeholders in model reviews and resolve their feedback before completing your process models. As a result you are virtually guaranteed to have your models accepted by the business.

6. Know how you will validate your model’s quality.

You know how to identify what the most important quality factors for your model are. You know how you will measure them. You know what questions to ask and of whom to ensure they are sufficiently present in your completed model.

Establish or Improve Your Process Modeling Competency

The Universal Process Modeling Procedure is a step-by-step guide for producing a business process model that will meet its project’s intended purpose. It guides a business analyst or process analyst to establish a clear mission for every process model. It provides you clear elicitation agendas so that you can be asking the right questions at the right times in your model’s development. It tells you what to look for and how to accurately and unambiguously identify, normalise and define any business process and or activity. It includes a validation comprehensive and tailorable process model quality criteria. It informs you about key process model stakeholders and how to engage them in the model’s development. It also includes reusable BPMN modeling patterns for the most common types of process model refinements.

Requirement Analysis for E-commerce Projects

Written by Poorti Mehta on February 25, 2019. Posted in Articles. 1 Comment on Requirement Analysis for E-commerce Projects

E-Commerce – A platform that has revolutionized the way we shop.

From clothing merchandize to grocery items, almost all our daily requirements are now met by such platforms. Such an application plays a crucial role in many businesses these days.

For an e-commerce project, the main business requirement is the same – A user comes to the platform and purchases products. The challenge for a business analyst is to visualize all the processes in between. The scope of an e-commerce application is large. At the micro level, the requirements can vary depending on the nature of the products being sold. At the macro level, a business analyst can make an outline of the following requirements – business and functional that hold true for a majority e-commerce platforms. A checklist can include the following pointers:

1. User actions on the website

What all actions can a user perform on the website besides making a purchase? These include:

Searching for products on the home page or throughout the website and on what basis. Products can be searched on the basis of product name, categories, brands etc.
Sorting products based on the filters provided. Which filters need to be placed? For clothes these can be colours, sizes and types. For grocery these can be fruits, vegetables, frozen foods and dairy products. For health insurance products these can be age group, premium limit, waiting period, maternity cover etc.
Adding products to a wish-list. If these products can indefinitely remain in the wish list till their respective stocks last or can remain for a definite period of time.
Making use of available promotional offers and discounts and the business logics behind them.
Creating an account. Is an account mandatory for making a purchase? Is buying as a guest user an option?

2. Admin Console

This is an important module of any e-commerce application. A business analyst should clearly determine the aspects that an admin can control from the backend. These include:

Product Management – All the metadata of the products – Product images, description, seller information, prices etc. Admin should be able to manage this data i.e. add, remove and edit a product.
Content management – The design aspect of the website i.e. the static pages a user sees at the front end. It’s important to create an attractive and effective website to attract and retain traffic. The answers that a business analyst should seek here are – How will these pages be maintained? Will these pages be uploaded or a provision has to be made for the admin user such that pages are created through the system?
Master Management – Besides the product data, there are other masters that need to be managed at the back end. Country, State and city masters, seller masters etc. are just a few examples. For instance pin code masters help in extracting a city when the user enters the pin code while adding the shipping address.
Admin should be able to carry out promotional activities. Admin user should be able to create promo codes and offers as per the business requirements.

3. Inventory and logistics Management and Order Fulfilment

Remember how we add some products to our wish lists and when it’s time to buy them, some of the products go out of stock. Or the time when a sale is announced at mid-night but you log in early morning only to see that the products in sale were brought overnight. We have all been through such times. At the backend, this management is crucial to keep the website up to date with the latest numbers. Whether new products are added, products are returned or exchanged, dispatched, all the logistics and stock details should be maintained in a robust system. Additionally once the products are purchased, some businesses require fulfilment systems that can be used by the dispatch and customer services teams. A business analyst should capture all the business requirements around this piece.

4. User checkout and payment

Generally users can check out as registered users or as guest users. An option of creating a new account is also available. Some businesses require customers to make an account in order to place orders. The information required to create an account needs to be considered.
Payment options can vary – Cash on Delivery, E-Wallets, 3rd Party Payment Gateways. Vendors are selected as per the requirement of the business.
The shipping charges and methods. These can be either maintained at the backend or made static.

5. Promo code application

It’s important for a business analyst to clarify the application area of these codes. At what point of the user journey can a user apply a promo code?

6. Mailers

Automated mails are triggered to customers on a majority of actions – when an order is placed, when an order is returned or an exchange request is placed, when complaints are logged, when new accounts are created, etc. Besides the standard practices, promotional campaigns are also run. Requirements should capture the mails to be sent for every action and the content for each mailer.

7. Reports

Analytics is an integral part of e-commerce in today’s date. A lot of third party tools are used by businesses to curate reports that’ll help the businesses to make informed decisions and plan further actions. The type of reports should be added to the business requirements.