Hi:

Systems Dev Life Cycle is the same thing as Software Dev Life Cycle.

The two currently popular methodologies are Waterfall and Agile.    From a developers standpoint, they are different.  That is, Waterfall is: Complete all analysis for the total project, next, complete all design, next complete all test, etc (nothing firm here.)   And Agile is:  Complete all analysis, design, test, etc. on a small set of the project's functionality; then complete all analysis, design, test, etc. on another  small set of functionality; and on and on.

However, we are Business Analysts, not developers.    It is important to remember that the primary purpose of a BA is to come up with the bigger picture.  This is done up front on both a Waterfall and an Agile project.  Also, what is done in big picture analysis is essentially the same for both methodologies:   Come up with a minimal, yet adequate quality of the systems required behavior and - especially - the interrelationships between the "chunks" of required behavior.

Do not let the common myths like:  Waterfall involves lots of up front requirements documentation, or Agile does not require an up front big picture cause confusiion.  Such myths confuse bad Waterfall with Waterfall and bad Agile with Agile.

Tony

Trainingspecialist gave a nice description of SDLC (the "S" usually stands for 'software' but some do refer to 'systems' instead - but means the same in both cases). As Tony noted, general methodologies fall typically under two umbrella categories - waterfall or Agile. Agile actually covers a number of different methodologies - Scrum, XP, Kanban, etc.

Relevance to the Business Analyst is described nicely in the Agile Extension to the Business Analysis Book of Knowledge (BABOK) - available free to IIBA and Agile Alliance members. Note that it is an 'extension' - not a 'replacement' of BABOK knowledge areas, techniques and tools. Much of the basic BA principles apply regardless of methodology - but there are some differences and key considerations for BAs working in an Agile environment.

Here is a link to another Forum discussion about documenting requirements on an Agile project. This discussion thread contains some additional links to material that might provide some insight into the specifics of Agile methodologies and impacts from a BA perspective.

http://www.modernanalyst.com/Community/Forums/tabid/76/forumid/17/threadid/8711/scope/posts/Default.aspx

Sandy

I don't know if I would agree that they're exactly the same, in that "Software" is just about Software and "Systems" includes Software, Computing Devices, non-Computing Devices,e tc.   However, your point that they are treated pretty much the same is accurate because the SDLC is really about a virtual assembly line for the Release of a single version of Software or Systems.  Software and Systems virtually move from phase to phase, from Strategic Inception through to the delivery and finally the closing of a Release.

The SDLC Phases, as per The International Foundation for Information Technology are:

1. Strategy (and Inception)
2. Research (and Analysis)
3. Planning
4. Requirements
5. Design
6. Procurement & Build (Federated Build)
7. Common/Centralized Build (Merging of all Federated Builds)
8. Systems Integration Testing
9. User Acceptance Testing
10. Production (Release & Operations)
11. Closing (which is implied and not often made explicit)

If you compare this to SDLCs like the one on Wikipedia, you'll see that each phase has very specific and clear purpose.  There are no vague phases that are called "Development" (which really means what you do across all phases) or "Implementation" (which happens in all phases that have correlating Environments).

Actually, it's important to keep in mind that most IT leaders would argue that the purpose of a Business Analyst is to gather and manage Requirements and to help validate those requirements against the design and implementation.  They look to Asset/Product Owners and to Architects for Strategy.

This is a very accurate statement.  In fact, I have to say that in the years of following SDLC topics online, you're one of the few people that has made this point very clearly.  I know companies that automate so much of their waterfall processes that they can move through a waterfall faster and with higher quality than many other companies can move through Agile based SDLC implementations.

Anyhow, I hope this helps.