The Community Blog for Business Analysts


Systems Analysis

NO Image:
Scope – the last frontier.  We are on a mission where no business analyst has gone before.  To explore strange new diagrams and to have the project scope clearly understood.  Extra credit to those who remember which TV show that was from!  Scope and context are the number one reason business expectations about a project ar...
0 Responses
Decision Model and Notation in short DMN is a novel way to model business decisions. DMN allows capturing and modeling business decisions in a way that is easy to understand with business people and subject matter experts. It is a combination of: Decision requirement diagram – DRD Decision table Boxed expressions Fr...
0 Responses
This entry was published on Aug 10, 2016 / Arash. Posted in Business Rules, Systems Analysis, Business Analysis, Domain Modeling. Bookmark the Permalink or E-mail it to a friend.
Use case modelling is the most powerful requirements modelling technique to model solution requirements if applied correctly. I have come across many BA teams (including my own) that made lot of common mistakes in use case modelling. By avoiding the top 10 mistakes identified in this paper, BA teams can not only save lot of efforts in use...
1 Responses
This entry was published on Jan 10, 2016 / Trividh Patel, CBAP. Posted in Requirements Analysis (BABOK KA) , Use Cases, Functional Specifications, Systems Analysis, Business Analysis. Bookmark the Permalink or E-mail it to a friend.
If you are managing a team of business analysts or systems analyst you probably have two main goals in mind:  - to make sure your team understand the requirements (the real ones)  - to make sure that you develop a solution which makes sense in the context of your constraints.  The chances are that one of your biggest constraints...
0 Responses
This entry was published on Jan 14, 2015 / Adrian M.. Posted in Systems Analysis, Leadership & Management, Agile Methods. Bookmark the Permalink or E-mail it to a friend.
Everyone knows what use cases are and their use in the software requirements process. We all know there are many ways to write them: logical, physical, to describe a manual procedure or an automated procedure. The purpose of State Diagrams is well-known to everyone in the field. They help us define the transitional lifecycle of an object moving and...
1 Responses
This entry was published on Sep 13, 2012 / Dahlia Biazid. Posted in Use Cases, Systems Analysis, Business Analysis, Getting Started as a Business Systems Analyst, Technical Topics. Bookmark the Permalink or E-mail it to a friend.
A Promise to have a Conversation I’ve been writing user stories for a couple of years now, and the best way I’ve heard how to describe them is that they are a promise to have a conversation.  Enough information should be written down to give the reader an idea of what the gist of the story is (and to be able to roughly estimate a story point ...
1 Responses
This entry was published on Nov 22, 2010 / Seilevel. Posted in Business Rules, Systems Analysis, Business Analysis, Agile Methods. Bookmark the Permalink or E-mail it to a friend.
  This model is provided by Don Firesmith of SEI.  Note the lack of an NFR category. More
4 Responses
This entry was published on Sep 24, 2009 / Craig Brown. Posted in Requirements Analysis (BABOK KA) , Functional Specifications, Systems Analysis, Business Analysis, Structured Systems Analysis (DFDs, ERDs, etc.). Bookmark the Permalink or E-mail it to a friend.
Following the lead of another forum, where the question was asked about the use of UML by Business Analysts, I would like to ask the same question when we come to Agile Analysis. The answer is NOT simple and like all professional questions needs analysis. This means, I shall post a series of these blog pages, expanding one point at a time. I will ...
1 Responses
This entry was published on Feb 26, 2009 / Gil. Posted in Unified Modeling Language (UML), Systems Analysis, Business Analysis, Agile Methods. Bookmark the Permalink or E-mail it to a friend.
User stories have a place in modern requirements management.  They may not be going to replace use cases but you shoulod know how to write them well. Invest In Good User Stories View SlideShare presentation or Upload your own. (tags: agile scrum)
0 Responses
This entry was published on Jan 09, 2009 / Craig Brown. Posted in Requirements Management and Communication (BABOK KA), Functional Specifications, Systems Analysis, Agile Methods. Bookmark the Permalink or E-mail it to a friend.
E R Diagram View SlideShare presentation or Upload your own. (tags: er diagram)
0 Responses
This entry was published on Aug 29, 2008 / Craig Brown. Posted in Data Analysis & Modeling, Systems Analysis, Business Analysis, Domain Modeling. Bookmark the Permalink or E-mail it to a friend.
Thirteen is all you need, at least in this point in time. I may add to them as time goes by, but I would also like to hear from readers if they have any suggestions or thoughts or their very own principles for IT Projects success. Pleae offer them and maybe we can get them into the second edition of the book...which you all remember is available at...
0 Responses
This entry was published on Jun 17, 2008 / David Wright. Posted in Systems Analysis, Business Analysis. Bookmark the Permalink or E-mail it to a friend.
13. Given many medium to small software Deliverables, use Architecture to manage and integrate the Deliverables into a complete system. This is a more specific statement of Principle #3; in Cascade, an Information System Architecture is used to integrate the two week deliverables, until a complete deliverable (component, sub-system) is assemble...
0 Responses
This entry was published on Jun 13, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.
12. Within the three month phase, parcel work into two-week periods; analyze for 2 weeks, then design and develop for 2 weeks (two developers), and then test for 2 weeks. When the first 2 weeks of analysis is done, start the next two weeks of analysis in parallel to the design/development; carry on in cascading 2 week periods until the entire proje...
0 Responses
This entry was published on Jun 09, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.
#11.   Partition large projects into 3 month phases, that is the longest period you can plan for without the chance of significant change to priorities, resourcing, etc. I was lucky to learn this early in the 90's as Project Management was getting a higher profile, accompanied by the increased use of Microsoft Project. Other PM tools wer...
0 Responses
This entry was published on Jun 05, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.
#10. Models are better than text. I would like to think that by this point in time, this principle no longer requires justification. It has been at least a few years since I last saw a dense “SRD” or “SDD” document (SYSTEM REQUIREMENTS DOCUMENT, SYSTEM DESIGN DOCUMENT).  I must offer my respect to the many talented people who labored to produ...
0 Responses
This entry was published on Jun 02, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.
#9. Leave a record of what you have done, so the project will not miss you if you leave. If change is the only constant, then resources on a project will change. The risk in such change is that a person’s contribution to a project will be lost, and that the new person assigned to the project will have to start over. This is a particular risk in...
0 Responses
This entry was published on May 29, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.
#8 -->   It’s the Deliverable (that matters), not the Task. The final deliverable is the Information System ready to be used effectively by the Business. If you can jump from ‘Start’ to this final deliverable in one “Task”, then power to you. Some people can do this; most cannot. This is again where a team of specialists is most effec...
0 Responses
This entry was published on May 28, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.
#7 One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio. This is actually one of those “rules of thumb” that have been borne out over time. (The ratio may vary a bit from case to case, like when the experience levels are different across the roles.) This ratio combines with...
0 Responses
This entry was published on May 27, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.
This principle supports #5. With limited resources, there is another strong tendency to have IT staff ‘wear multiple hats’ on a project, especially the Business Analyst who is asked to also be the Project Manager and/or Lead Tester. Rather than getting more than you are paying for, you get less as an IT Staffer skilled in one role spends more time ...
0 Responses
This entry was published on May 22, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.
Principle #4 - Pick the right project(s) for the business. At any one time, the IT department of an average company is running multiple projects. How did they get started? How were they even defined as a project that needed to be carried out? No one may actually know. In more chaotic environments, projects can start as a seed of an idea, pic...
0 Responses
This entry was published on May 21, 2008 / David Wright. Posted in Systems Analysis. Bookmark the Permalink or E-mail it to a friend.
Page 1 of 2First   Previous   [1]  2  Next   Last   


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.



Modern Analyst Blog Latests

Jarett Hailes
Jarett Hailes
As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
2 Responses
Howard Podeswa
Howard Podeswa
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
11 Responses
Adrian M.
Adrian M.
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN
1 Responses
Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC