Structured Systems Analysis (DFDs, ERDs, etc.)

Jul 05, 2021
3888 Views
6 Likes
0 Comments

A diagram is a 2-dimensional representation of a story, which shows elements and their relationships on a single canvas. An element is shown on a single diagram. (To show the same element information on a 2 diagrams, the element is duplicated.) When the properties of a diagram element are changed, the change is reflected only on that diagram.

A model is a 3-dimensional representation of a collection of related stories, which captures diagram elements as model components. A component includes all element properties and relationships between different elements on all diagrams. A single model component can be shown as elements on several diagrams. A change to the properties of a diagram element or model component is reflected on every diagram where that component is displayed.

A model does not necessarily need to include any diagrams. Diagramming is the most common method for creating and maintaining model components, but the diagrams can be deleted without changing the model.

If a picture is worth a thousand words, then a diagram converts those words into a story. A model organizes those stories into a book.

16045 Views
32 Likes
3 Comments

Project Scope. We will see how scope statements, when making reference to business functionality, lead directly to High-Level requirements.  Gathering requirements for a business information system is most often done within the context of a project. Approval of a project includes its sponsors signing off on its scope. The scope for a business information system project is typically defined in functional terms. Items in scope make reference to (or should make reference to) business functions, processes and/or activities that are to be delivered.

19466 Views
60 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.

 

19204 Views
12 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.

44872 Views
29 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.

47677 Views
16 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.

170390 Views
452 Likes
6 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.

45867 Views
39 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.

14469 Views
9 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.

193051 Views
90 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.

21930 Views
15 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.

14430 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

142907 Views
100 Likes
12 Comments

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.

29770 Views
10 Likes
0 Comments

I have been very fortunate to see a lot of this history first hand. I have observed changes not just in terms of systems and computers, but also how the trade press has evolved and the profession in general. It has been an interesting ride.

Throughout all of this, there have been some very intelligent people who have impacted the industry, there have also been quite a few charlatans, but there has only been a handful of true geniuses, one of which was Robert W. Beamer who passed away just a couple of years ago. Bob was the father of ASCII code, without which we wouldn't have the computers of today, the Internet, the billions of dollars owned by Bill Gates, or this document.

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.

30386 Views
17 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...
Page 1 of 2First   Previous   [1]  2  Next   Last   

 



 

Copyright 2006-2021 by Modern Analyst Media LLC