Structured Systems Analysis (DFDs, ERDs, etc.)

Jun 04, 2017
4813 Views
36 Likes
4 Comments
I take the approach that as Business Analysts, the line between requirements and design is an imaginary line. We need to be pragmatic (abandon purist thinking) and not be afraid to wear the design cloak, to adopt design thinking. 

 

So how do we incorporate design thinking in Business Analysis in a value-add way? Take the following thoughts into consideration when working on your next project that involves building or significantly updating a customer-centric application.


Author: Michael Roy, Business Analysis Professional / Requirements Leader

Michael is a solutions-focused Business Analysis professional with extensive experience leading change initiatives at a tactical and strategic level.

 

14682 Views
4 Likes
0 Comments

In the real world, good decision modeling is always a balance between science and art. The science is systematic decomposition of a structure (of data or logic) into a set of smaller structures based on the definitions of successive normal forms. The art, on the other hand, is a general decomposition into a set of smaller structures based on factors not related to detecting and correcting normalization errors.

18243 Views
21 Likes
1 Comments

This article describes the Entity Relationship Diagram that allows you to document the structure of a database in terms of persistent entities and the relationships between them.  The Entity-Relationship Diagram (ERD) provides a way of graphically representing the logical relationships between entities in order to create a database schema to persist those entities.

27335 Views
8 Likes
9 Comments

A data flow diagram (commonly abbreviated to DFD) shows what information is needed within a process, where it is stored, and how it moves through a system to accomplish an objective. As its name implies, a data flow diagram depicts the flow of data within a system.

133141 Views
432 Likes
5 Comments

 The Data Flow Diagram (DFD) provides a graphical representation of the flow of data through a system. It shows logically what information is exchanged by our system processes and external interfaces or data stores, but it does not explicitly show when or in what sequence the information is exchanged.

30761 Views
30 Likes
1 Comments

This article is all about putting your systems analysis into context; literally and metaphorically. It’s all about drawing and interpreting the not-quite-UML Context Diagram that is sometimes referred to as the System Context Diagram.

8658 Views
2 Likes
0 Comments

In I.T., are we really spending too much time on "maintenance"?  Within any systems development organization, there are but three types of work effort: new systems development, maintenance, and modification/improvements. A mature development organization will spend approximately 5% of its time on new development, 10% on maintenance, and 85% of its time on modification/improvements.

132313 Views
80 Likes
4 Comments

Context diagrams are instrumental in unearthing unknown requirements during the discovery phase, both by forcing an analyst to think through the context (thus the moniker context diagram) of a project methodically and by enabling stakeholders to do so as well.

15222 Views
9 Likes
1 Comments

Systems work is not as hard as you might think. However, we have a tendency in this business to complicate things by changing the vocabulary of systems work and introducing convoluted concepts and techniques, all of which makes it difficult to produce systems in a consistent manner. Consequently, there is a tendency to reinvent the wheel with each systems development project. I believe I owe it to my predecessors and the industry overall to describe basic systems theory, so that people can find the common ground needed to communicate and work. Fortunately, there are only four easy, yet important, concepts to grasp which I will try to define as succinctly as possible.

8315 Views
2 Likes
2 Comments

Also called abstract or business modelling, essential modelling can be an extremely valuable tool for the business analyst. Instead of modelling how things are done (the current system), or how they might be done (a proposed system), we model what is done, or what might be done. For example the purpose of a Customer Service Department is to provide customers with a level of service they expect (or the company defines). Things like call centres and customer relationship management systems are the how of customer service.

This switch in thinking is not always easy as we have to ignore the very practical matters of procedures, methods, people, technology etc. The more involved we are in the system that we are looking at, the more difficult it may be to look at things conceptually. We have to look at what business objective we are trying to achieve. The business analyst who can do this - and explain it to clients and management - becomes a most valuable asset to the business.

Author: Derrick Brown

12716 Views
5 Likes
5 Comments

Many people on our Business Analysis workshop ask why we use dataflow diagrams (DFDs). Why not Use Case…or even BPMN? After all DFDs have been around for 20 years, surely the world has moved on?

Well, has it? The primary purpose of a business analyst is to communicate – to stakeholders and to solution providers – and when it comes to communication we all know that pictures (diagrams) are much more effective and less ambiguous than words. Remember the phrase "A picture is worth a thousand words". The question is – which type of diagram best suits our needs? In this article, written by IRM's Training Services Manager Jan Kusiak, we’ll look at using diagrams for stakeholder communications.

Author: Jan Kusiak

97957 Views
80 Likes
12 Comments

Every year, organizations around the world face startlingly high project failure rates. Some research has shown that less than 30 percent of software projects are completed on time and on budget—and barely 50 percent end up meeting their proposed functionality. If you’re a big league baseball player, failing five to seven times out of ten will get you an endorsement deal and a spot in the Hall of Fame. But, for the rest of us, these types of failure rates represent billions in cost overruns and project waste.

In 2005, ESI International surveyed 2,000 business professionals to try to find out why projects fail. The answers were numerous and varied and included such common thorns in the side as inadequate communication, risk management and scope control. But of all the answers, one showed up more than any other. Fifty percent of those surveyed marked “poor requirements definition” as their leading project challenge.

Failing to properly and accurately define requirements at the very beginning of the project lifecycle points to a distinct lack of business analysis competency. The role of the business analyst is an important one, and, sadly, one that is underutilized by many organizations around the world. In essence, a business analyst acts as a translator or liaison between the customer or user and the person or group attempting to meet user needs. But, that’s just speaking generally. What about the specifics?

Below, I’ve put together a list of eight key competencies that every business analyst—or every professional performing the duties of a business analyst—should possess. I’ve included specific emphasis on tasks associated with junior, intermediate and senior business analysts. If performed effectively, the items on this list could save organizations millions.

Author: Glenn R. Brûlé

16760 Views
4 Likes
0 Comments

I always find it amusing when I tell a young person in this industry that I worked with punch cards and plastic templates years ago. Its kind of the same dumbfounded look I get from my kids when I tell them we used to watch black and white television with three channels, no remote control, and station signoffs at midnight. It has been my observation that our younger workers do not have a sense of history; this is particularly apparent in the systems world. If they do not have an appreciation of whence we came, I doubt they will have an appreciation of where we should be going. Consequently, I have assembled the following chronology of events in the hopes this will provide some insight as to how the systems industry has evolved to its current state.

I'm sure I could turn this into a lengthy dissertation but, instead, I will try to be brief and to the point. Further, the following will have little concern for academic developments but rather how systems have been implemented in practice in the corporate world.

Author: Tim Bryce

25210 Views
16 Likes
2 Comments
What Is A Functional Specification? Functional specifications (functional specs), in the end, are the blueprint for how you want a particular web project or application to look and work. It details what the finished product will do, how a user will interact with it, and what it will look like. By creating a blueprint of the product first, time an...
6314 Views
0 Likes
0 Comments
As long as practitioners recognize that use case diagrams are optional and iconic (as opposed to schematic), they shouldn't have problems. The diagrams are useful, for example, on whiteboards as a way of sketching and framing an agenda while people are writing up and reviewing use case detail on index cards. The trouble starts, however, when pr...
Page 1 of 2First   Previous   [1]  2  Next   Last   




Latest Articles

Security Requirements Engineering
Jul 17, 2017
0 Comments
When security requirements are considered at all during the system life cycle, they tend to be general lists of security features such as password pro...

Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC