Entries for April 2015

17548 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?
17346 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.
16123 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”.

11880 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...
30699 Views
41 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.” 

12150 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.

18347 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.

 



 

Copyright 2006-2021 by Modern Analyst Media LLC