Entries for April 2015

16339 Views
8 Likes
4 Comments

This article looks at practical experiences of implementing business rules using TDM and SAP from several angles, while also raising some of the questions which I find asked most frequently and insistently in my work, such as:

  • Why do I need anything other than an existing rules engine to define and manage business rules?
  • Why would I want specialized tooling for business rules when I already have tooling for requirements gathering?
  • How does improved business rules definition help me with testing?
16565 Views
18 Likes
1 Comments
In parallel with my consulting work, I teach an online course for business analysts on writing better requirements. Invariably, the most skilled participants of the course are the ones who seem less confident when submitting their assignments. “Please let me know if this is not what you expected”, or “I hope I understood the assignment correctly” are phrases I typically get from these participants, while the weaker BAs typically write “here’s my assignment for Lesson 3”, without any caveats.
14888 Views
20 Likes
0 Comments

As far as the individual change is concerned, what we need to know and do –as business analysts- is “How to design the proper tactics and interventions that institutionalize the change (e.g. new ERP system, redesigned business processes, new organizational structure, new policies, etc.”) at an individual level”.

11052 Views
15 Likes
0 Comments
Based on requirements, ASE decomposes a system into its sub-systems (business processes), the procedural work flow for each, and determine what programs are necessary to implement the computer procedures (software specs). To do this, we determined there were three basic types of sub-systems...
28755 Views
40 Likes
4 Comments

People sometimes say that requirements are about “what” and design is about “how.” There are two problems with this simplistic demarcation.  This makes it sound as though there’s a sharp boundary between requirements and design. There’s not. In reality, the distinction between requirements and design is a fuzzy gray area, not a crisp black line. I prefer to say that requirements should emphasize “what” and design should emphasize “how.” 

11531 Views
1 Likes
0 Comments

I’ve had the great pleasure of working through audits with the business I support over the last 2 years. It’s been a journey for sure and as regulators, internal audit teams and testing teams work to ensure that are processes are solid. First, let’s start with what does this word compliance mean? Compliance means conforming to a rule, such as a specification, policy, standard or law.

16934 Views
15 Likes
3 Comments

 

In this article, we discuss three of the basic elicitation techniques used in business analysis in order to obtain the requirements for the system being designed: Interviewing, Job Shadowing and Facilitation.






Latest Articles

The Secret is in the Wings
Nov 29, 2020
0 Comments
I could not help but observe in awe the agility of this monstrous wing. My mind could not stop analyzing how an airplanes uses the agility of its wing...





Copyright 2006-2020 by Modern Analyst Media LLC